This revealed a bug: Transferring single arrows to the surrounding with the "transfer all button" leaves single arrows in the environment, instead of actual stacks.
Transferring them with single clicks stacks the arrows though.
The trick was that the Clonk does not exit the object right away, but gets a drop command instead. Furthermore, it was confusing that the Collection2-callback never actually happens in this situation.
Added tests for adding to the queue and clearing the queue. The other tests are dummies for now. Found out that the parameter 'abort' in ClearQueue() was never used.
This special case is a relic, because I do not know whether this is actually a use case that is required in a scenario. All unit tests in the producers test pass now.
The earth object did not include _inherited(...) in the Construction() callback. Thus it was not initialized as a stackable object correctly. Fortunately the other stackable objects did not have this problem.
Nonetheless I added a unit test, so that we can identify similar problems in the future.
The callback happens in every call to MergeWithStacksIn() now, instead of RejectEntrance(). Otherwise the following use case does not work: Liquid enters crew/building and fills the contained barrels. Added a unit test for that use case. Stackable unit tests still pass.
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.
This got removed by accidet (checking if the object was added to another stack seemed logical). However, this whole function does not really make sense. It returns true if the object got removed only. That means that the object would not enter the other object anyway.
Removed the UpdateStackDisplay(), because that happens in TryAddToStack() if the count changes, anyway.
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 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
The steam engine can burn oil as fuel now. Added test to power system unit test. Still needs support for actually getting oil into the engine.
Fixed a bug in LiquidContainer that would return no liquid if the entire contents are removed. Added unit test for said bug.
Fixed overspilling of connected liquid containers. Pump no longer counts as a liquid container/tank, so that it still spills liquid if no drain is connected.
The steam engine does not remove the barrels, it just empties them. Made power system unit test 19 end if both pumps are pumping, this seems to be the intention of the unit test. Added power system unit test 20: Steam engine fueled by oil barrels.
Now it is possible to connect lines from a pump to the steam engine. This is achieved by the steam engine being a liquid tank. It did not seem good to allow connection from pumps to all liquid containers (i.e. barrels). A liquid tank is also a liquid container, they share the same interface, but it is also a structure.
It is not yet possible to fill the steam engine with any liquid though, because it is not defined what kind of liquid it accepts. This will be oil in the future. Furthermore, the behaviour when the pump adds incompatible liquid is not defined yet.
This messes up so many things as one could have expected. Instead we do the sensible thing and enable it only in the test scenario. For future reference all sequences involving an elevator and NPC clonks are broken with this feature.
Scenario that tests SetGraphics() in various ways: Setting graphics of meshes/sprites to other objects, overlaying objects onto other objects.
The scenario is not in the Issues.ocf folder, because it addresses multiple issues #1458 and #1538 and the status of the issues has not been acknowledged yet.
Mark