Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / Overview: HUD changes
1 2 Previous Next
Parent - By Matthias [de] Date 2015-10-03 21:39
Good thinking. I also thought that those - as the only round element - were disrupting the visuals
Reply
Parent - - By Marky Date 2016-10-05 16:02 Edited 2016-10-05 16:14
Recently I found that I want to customize the HUD for certain scenarios (such as Hazard), but that is not really possible at the moment: I'd have to copy and paste the code to my scenario and change some graphics or only certain IDs in the definitions. Overloading the menu icons (the rings) leads to the graphics changing everywhere, not just in the HUD. The crew selector graphics cannot be overloaded without overloading the whole script. What is, in your opinion, the best way to go about this?

My current proposal consists of the following steps:
1.) Remove the crew selector graphics entirely and replace it with the Icon_Menu_RectangleRounded (and a darker version for the background graphics). The other graphics in this definition are not used, apparently. You can test the changes at https://github.com/gitMarky/openclonk/commit/2072cf8a93db7340e217621163ea84d35accd21b
2.) Change the HUD proplist definitions, so that the individual elements of the proplist are functions that can be overloaded. For example:

  frame =
  {
    Target = this,
    Symbol = GUI_Controller_CrewBar,
    Priority = 2
  },

Would become:

  frame = ElementNextClonkFrame(),
  ...;

func ElementNextClonkFrame()
{
  return {
    Target = this,
    Symbol = GUI_Controller_CrewBar,
    Priority = 2
  },
}

In this case it probably makes more sense just to define the icon via function call, but I think you get my idea.
Parent - - By Clonkonaut [de] Date 2016-10-05 16:17
I am all in favour of making the HUD more customisable. So tell what you'd like to overload (functions, perferably). I don't like overloading definitions and I guess it's unnecessary in this case.
Reply
Parent - - By Marky Date 2016-10-05 16:39
I'd like to be able to change:
- the frame graphics of the crew bar
- the "event" icons of the crew bar, such as the heart when the clonk is damaged
- the frame graphics of the interaction selection
- the circles of the inventory icons at the top
- the circles of the extra slots for inventory icons
more or less related:
- the frames in the object interaction menu (when pressing [E]).

I could do most of this myself, but if you offer to do this I'll vote for that option. After all you created the new HUD in the first place.

[Edit]
I did not name functions here on purpose, because for the crew bar I'd have to overload the whole Construction()-function, for example. I do not see how this would help you.
Parent - By Clonkonaut [de] Date 2016-10-05 16:53
Yeah, that's alright. I can do that. Not that you wouldn't be allowed to do it though, it's not my baby or something. ;)
Reply
Parent - - By Clonkonaut [de] Date 2016-10-05 17:22

> I'd have to overload the whole Construction()-function


What if I just change it so the whole GUI proplist is returned by another function? That way you could overload everything you need and inherit everything else.
Reply
Parent - By Marky Date 2016-10-05 18:08
It's an option, but that still means that I have to maintain the whole menu definition, and not just the things that I want to have changed.
Parent - - By Clonkonaut [de] Date 2016-10-06 00:51
I pushed everything but the interaction menu now. Your overloads should look something like this:

#appendto GUI_Controller

func AssembleActionBar()
{
  var gui = _inherited(...);
  gui.Symbol = Something;
  return gui;
}

func AssembleCrewBar()
{
  ...
}

func CrewDeathIcon()
{
  return Something;
}


And so on. I know that this is not so great if the proplist structure of the HUD ever changes but it grants more freedom in customisation. For the proplist structure you can hold me personally accountable for any changes!
Reply
Parent - By Marky [de] Date 2016-10-06 04:31
Cool, thanks!
Parent - - By Marky [de] Date 2016-11-22 21:23
I am currently doing a few adjustments, but I am not quite sure if I solved it the best way and I want a review of the following commits:
Number 1
Number 2

The idea is that you can have an entirely new HUD or without having to copy from/overload GUI_Controller. Still, getting the ID for the HUD from GUI_Controller seems more charming/appealing to me, but it would make the code more confusing imo.
Parent - - By Clonkonaut [de] Date 2016-11-23 20:08
I'm definitely not against these changes but then I wasn't aware this was a big problem. Just moving code around doesn't seem like the best solution though (doesn't it just mean you'll probably have to copy code from the library?).
Reply
Parent - - By Marky [de] Date 2016-11-23 20:46
I can include the library with the basic functionality, as well as all components that I want to have:


// Include the basic functionality of the HUD
#include Library_HUDController
// Include the different subsystems of the HUD. They all handle their part
// themselves via overloading of callbacks.
#include GUI_Controller_InventoryBar
#include GUI_Controller_ActionBar
//#include GUI_Controller_CrewBar // There will be only one crew member! No need for that
#include GUI_Controller_Goal
#include GUI_MyCustomComponent // I want some more elements
//#include GUI_Controller_Wealth // No money necessary!


With the original script I can only add more elements to the existing HUD, but not remove the existing elements.
Parent - - By Clonkonaut [de] Date 2016-11-23 20:54

> but not remove the existing elements.


You could overload the Construction/Destruction calls, I think? But as I said, I'm fine with the change. One thing though, I'm not particularly fond splitting up the HUD definitions between folders. Having the 'library' in libraries isn't of much help since it's heavily dependent on everything in /HUD/ and not really a standalone library. Best to keep it together with its friends then.
Reply
Parent - - By Marky [de] Date 2016-11-23 21:37
The HUD Adapter that is responsible for creating the library and redirecting all callbacks from the Clonk to the HUD is also in that folder. Should I move it to the HUD folder, too?
Parent - By Clonkonaut [de] Date 2016-11-23 21:53
Not sure. I'd say that one is part of the clonk's libraries and should maybe someday be moved into the clonk.
Reply
- - By Clonkonaut [de] Date 2015-09-30 10:57
Oh btw, I removed all those dummy objects from the HUD structure. Those could easily have been 10 objects / player!

The HUD only uses one object now, the HUD controller itself.
Reply
Parent - - By Zapper [de] Date 2015-09-30 11:02
wasn't me
Parent - By Clonkonaut [de] Date 2015-09-30 11:03
wasn't blaming anyone!
Reply
- - By Maikel Date 2015-10-01 19:30
In general it looks good and functions well. However, I don't like the fact that the inventory is shown at the top. I'd much prefer the bottom of the screen, I have the feeling the middle of the top of the screen is where more action happens than the middle bottom somehow (Meteorites, airplanes, air attacks, objects falling down).
Parent - - By Clonk-Karl [us] Date 2015-10-01 19:34
How about showing everything at the bottom then? I like how with Clonkonaut's HUD everything is at a single place.
Reply
Parent - By Maikel Date 2015-10-01 19:49
I am not sure, I like how the HUD before this iteration only covered to corners and a small part of the bottom of the screen, but we can try.

Even better would be three elements (goal+wealth / clonks / inventory) which one can place themselves somehow.
Parent - - By Sven2 [us] Date 2015-10-01 21:00
I agree that everything at the bottom might be worth a try. The top also conflicts with dialogue messages, and dialogues at the bottom don't capture attention as well.

When moving stuff to the bottom, we might also consider offsetting the viewport center to the top so clonks are centered slightly above the middle of the screen.
Parent - By Clonkonaut Date 2015-10-01 21:25
I thought dialogue messages had a 'standard margin' applied to them?
Reply
Parent - By Marky [de] Date 2015-10-01 21:29 Edited 2015-10-01 21:32

>dialogues at the bottom don't capture attention as well.


Zelda did it wrong all the time :'( Still, dialogues at the bottom would feel wrong for Clonk, it is sort of standard since Clonk Rage.
Parent - - By Clonkonaut Date 2015-10-01 21:25
Curious. When moving everything to the top, I felt quite differently, that I always wanted to see the bottom of the screen because that's where I'm digging towards and want to see what's coming while the top was always of noc interest! :D

But in the end, top or bottom is the same to me. I just liked everything in one space.
Reply
Parent - - By Sven2 [us] Date 2015-10-01 21:42

> Curious. When moving everything to the top, I felt quite differently, that I always wanted to see the bottom of the screen because that's where I'm digging towards


Yes, you need the ground more than you need the sky. That's why I'd suggest offsetting the viewport center.
Parent - - By Clonkonaut Date 2015-10-01 21:48
Would the HUD be able to go offscreen so you could see all the way to the bottom edge of the landscape?
Reply
Parent - By Sven2 [us] Date 2015-10-01 23:26
There are scroll border sizes that allow scrolling past the landscape. These are pretty small at the moment (probably based on the previous HUD), but can be enlarged if needed.
Up Topic Development / Scenario & Object Development / Overview: HUD changes
1 2 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill