Related to #1970 and 5fc07df757
This replaces the very hacky implementation just for the dynamite with a more general solution (and e.g. also works with the grenade launcher).
This reverts commit 8698aa25cf.
Tackling #1970. The implementation in the reverted commit was incorrect (i.e. only one out of two "GetStackCount" were replaced with GetInteractionMenuAmount, leading to weird behaviour). If you want to replace it, please do it in a way that no call to IsInfiniteStack will be required. And this hack would probably require so much more bloat code that nothing would be gained (i.e. what happens when you put two infinite arrow stacks in one container?).
The bug report complains about the "display stopping at 999" *in some situations*, which was due to Stackable_Max_Display_Count. It's gone now. And that it was not limited to 999 in all situations (like the code would have suggested) is probably due to the things I described above.
# Conflicts:
# planet/Objects.ocd/Libraries.ocd/LiquidControl.ocd/Liquid.ocd/Script.c
# planet/Objects.ocd/Libraries.ocd/Stackable.ocd/Script.c
The matching had a few issues:
Items with the same symbol were supposed to be stacked, but the "symbol" changed from ID to object at some point. So same-type objects were no longer correctly matched.
Items with different text (e.g. amount) but everything else the same should be stacked. But simple proplist equality is obviously not sufficient to determine whether the contents of the proplist changed.
The order of the items is generally more stable now. I hope this doesn't introduce other issues.
Showing the definition means that objects can not modify their display in the extra-slot. E.g. the arrows would always show their "full" state. Now the arrow count is correctly displayed in the extra-slot.
Extracted the basic functionality for HUDs from GUI_Controller to a library. This way, if you want to create a new HUD, you only have to include the library and all the desired components. Previously you had to copy the script from GUI_Controller, too. This holds of course only if you want to actually remove components from the HUD, and not just add to it.
Currently the GUI_Controller is referenced as the ID for the HUD, will change this to a callback.
With the highest items being in the front, the tight grid layout has less reason to resort a major amount of the items every time items are added or removed. This results in a generally more stable layout.
This makes extra-slot containers not block an extra row anymore. However, they might jump around a bit. It might be a good idea to set their priority lower to make them always appear first.
When they would be in front, the tight grid layout would likely not move them around.
The callbacks from PlayerControl aren't used anywhere right now and there's only two unrelated internal functions in the GUI list menu with the same name. So the parameter checker emits a warning here.
Solve it by renaming the internal functions.
This will prepare the quick switch system according to Maikel's suggestion (http://forum.openclonk.org/topic_show.pl?pid=31070). The highlighting method is open to discussion. Currently, font colour and style are similar to the interaction key above the action bar icon. But it is very well possible that this will look bad when the key name is very long.
The original implementation is ok, but why check the value if it would not change anyway? In the new implementation the variable lives only where it can actually change, and so does the if-clause.
Maikel de Vries