The problems here were:
- the foundry cannot take 400 water from ice if it has a fill limit
- the pump cannot pump anything into the object if it has no fill limit
The function RejectEntrance() has two more callbacks to the object it should enter:
- CollectFromStack(object stack): The object can grab items from the stack, before the stack tries to merge with stacks in the object. This is necessary for barrels, so that a large liquid stack can fill an empty barrel.
- RejectStack(object stack): This is called after the stack is merged. Currently, the stack merging counts as handled only if the stack is removed. This callback allows the object to still reject the stack, for example if it accepts only one item, such as the barrel does.
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.
Added parameter to 'GetFuelAmount' that specified how much fuel is requested from this object. Oil is now fuel and only the needed amount is removed instead of removing the entire stack when a producer requests fuel.
Previously, sharing the logic made sense, because both objects used variables to store the liquid. Now, the liquid container stores liquid in an object - this is not desirable in the pump because it would create and remove objects for no good reason (only so that it has a virtual liquid storage) every time it pumps. Consequently, liquid objects cannot enter a pump anymore.
Unit test 3 still fails, because the functions are not runtime overloadable. Test 12 fails, because liquid transfer does not work correctly yet. This fill be fixed in the next checkin.
Added debug logging, this has to be removed again later.
Unfortunately, now the object is not actually transferred, but removed, and a new one is created or an existing one is filled in the liquid container. The logic could use a rework actually, because everything was more clear when the container stored things in variables.
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.
The liquid container now stores liquid objects, instead of volume and liquid type. Liquid objects can have be of a specific type, such as Liquid_Water, Liquid_Oil, etc..., but they can also just stay Library_Liquid for other liquids.
The liquid container logic has become more complex now, but still works as before. Transferring liquids to other objects may still need some improvements:
- at the moment, transferring liquids between liquid containers is possible
- maybe liquids objects, such as oil, can enter a liquid container while another liquid is in that container already - will need a unit test for that
- transferring liquid from a liquid container to a structure or crew member should be possible (but is not yet), if the target is not a liquid container but contains liquid containers
Sven Eberhardt