Good thinking. I also thought that those - as the only round element - were disrupting the visuals
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:
Would become:
In this case it probably makes more sense just to define the icon via function call, but I think you get my idea.
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.
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.
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.
- 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.
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. ;)
> 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.
I pushed everything but the interaction menu now. Your overloads should look something like this:
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!
#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!
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.
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.
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?).
I can include the library with the basic functionality, as well as all components that I want to have:
With the original script I can only add more elements to the existing HUD, but not remove the existing elements.
// 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.
> 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.
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?
Not sure. I'd say that one is part of the clonk's libraries and should maybe someday be moved into the clonk.
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.
The HUD only uses one object now, the HUD controller itself.
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).
How about showing everything at the bottom then? I like how with Clonkonaut's HUD everything is at a single place.
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.
Even better would be three elements (goal+wealth / clonks / inventory) which one can place themselves somehow.
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.
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.
I thought dialogue messages had a 'standard margin' applied to them?
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.
But in the end, top or bottom is the same to me. I just liked everything in one space.
> 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.
Would the HUD be able to go offscreen so you could see all the way to the bottom edge of the landscape?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill