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.
Transfer of items from one container to another is handled differently between the following actions: a) select items for transfer in the inventory box; b) transfer all items with the transfer-all-arrows.
This should be made consistent, especially since action a) seems to have an unnecessary special case (marked with TODO).
As a first step the methods were simply extracted.
Conflicts will be merged in the next commit:
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/PipeLine.ocd/Script.c
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/Script.c
The previous name suggested that the object actually gets put into another object. In fact it merges the stack count with other stacks, and it does not only try to (and reverts the state if it fails), but it actually changes other objects even if the function returns false.
The special handling of the stackable library was moved from the interaction menu to that library. The reasoning behind this is that the menu should not have to know each and every object, but the objects should tell the menu how they are displayed.
Liquids are displayed by their liquid count now. It would be even better, if the max. capacity would be displayed without having to hover the description field.
Previously, text windows would just change their own size and leave cropping and scrolling to their parent. This made the code easier, but was apparently unintuitive for scripters.
Now text windows do not change their size but show a scrollbar themselves (unless GUI_FitChildren or GUI_NoCrop of course).
This implied some other changes, because now parents without a scroll bar need to clip, too. (Or the clipping needs to be moved to the child window. But then it would have to be made sure that menu decoration can still go out of the bounds.)
And this also needed some script fixes where scripters assumed the text windows would not scroll (and thus made them smaller than 1em).
related to https://git.openclonk.org/openclonk.git/commit/46ad28ea652fad34814a866f3b9c305aa7cc6faa
The interaction with IsContainer objects is still flawed in a way: when a lorry is inside a (IsContainer-)hut, you can take the lorry into your hands. Since we don't have that possibility in the normal game, I leave it unchanged for now.
However, it is now possible to add a Chest (or a cupboard!) into a WoodenCabin and then store stuff inside of it.
Some objects need to accept items (be IsContainer) but want a custom way to display their contents (e.g. because you can't take stuff out). For example the sawmill.
Objects that prevent interaction just in some situations (hostility, dead Clonks, ..) should always be shown in the interaction menu (because otherwise players might suspect bugs) and TELL the player WHY they want no interaction.
For that, they might need to specify own error messages.
Known issues:
* The "OnOpen" callback is done even if interaction is disallowed, however just simply removing the callback might not be sufficient, because we might get a callback disbalance if objects change their attitude while the menu is opened and the menu is closed again.
* Some objects (which should) do not include the Library_Ownable. However, we have no base melees atm and since this might introduce new errors, postpone it to 8.0.
OnContentMenuOpen is not used anymore.
There is a small issue: the callback is also done when the object can actually not be interacted with (e.g. because it's hostile / unfinished). Gotta think about that. But this should solve all our issues for now.
The count was displayed twice in certain situations: in the picture AND as a number.
Now the responsibility for displaying the count is solely on the menus' side. The objects only show an additional overlay when their count is infinite (to not display an arbitrary "50" there).
This can e.g. be used for the water barrel to show the fill-level. Or by an adventure scenario to highlight quest items.
Or by third-party packs to do other cool stuff.
This happened to me ingame. I don't know why and I don't know how to reproduce.
So this is a quick in-place fix instead of a solution to the underlying issue of "entries" not being there.
Objects now stack iff CanBeStackedWith returns true. The displayed symbol is now the first object of the stack (instead of the definition).
Also fixed barrel to not overwrite the custom name just after setting it.
One of Sven's private functions. I also renamed the control to CON_ModifierMenu1 (from CON_ModifierInventory1), because it's actually supposed to be the menu modifier in general - even if it's mapped on the inventory key.
Or more generally: added support for any modifier key for any other command without the requirement to define a new command based on the old one plus the key. This can be helpful in situations where the player commands are decoupled from the script engine control handling (e.g. with menus).
Currently Shift+Click is only used by the inventory menu to transfer all items of a certain kind.
The surrounding tab now uses the standard, mainstream contents display. That means that e.g. no ugly hacks are necessary to enable the "transfer all" buttons.
Previously, the surrounding menu was completely separate and always collected into the Clonk. Now you can also just put stuff directly from your surrounding into your lorry (i.e. just take everything around you into the lorry).
This is mainly to get rid of IsContainerEx, because wtf.
The only reason why the categories were restricted was to prevent HasExtraSlot-objets from being found. Some C4D_Objects (or with wrong category in general) wanted to be found however. They are now found just like that.. like it was supposed to be.
The clonk opening the menu should always have higher priority so the clonk is predictably selected on the left side even if standing behind e.g. a crate.
Other clonks should be behind because interaction with them is rare but having your fellow players stand in front of a building is very common. Allies also tend to run in front just when you opened that menu.
I am still not 100% sure in which situation this occurs (see also old comment in line 168). I suspect it happens when an object is removed from the menu and the object check timer ticks just before the inventory timer.
It is possible that this should rather be resolved by removing the inventory check effects when the right conditions are met (aka the menu is removed). IF that is even the cause. Right now I don't think the current situation is too bad, because the check is very lightweight and superflous content check effects will be removed when a new menu is opened on either side anyway.
Previously, the em <-> pixels conversion was a hardcoded value. Now the GUI scales with the font size that can be selected in the options.
Sadly, all scales were off since the hardcoded value was too low.
Clonkonaut