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.
David Dormagen