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
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 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.
This was used inconsistently and without regard to correctness, so it is better removed altogether. In case of incomplete objects, the incomplete object always returns the reduced amount.
The liquid objects cannot be converted from one to another. The fuel object will be removed again, it does not make sense that "burnt fuel" can be transferred from one object to another.
The steam engine treats barrels the same as itself when it comes to extracting liquids. This removes the need for the callback OnFuelRemoved() in the barrel, as well as the stupid definition call from the barrel to the steam engine.
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.
The pipe can be connected from the interaction menu now, too. Expanded the disconnection logic, because more problems arise when the pipe can still be connected to other structures - it would be sufficient to remove the line, but that could be annoying:
- if the pipe is connected to a container, then you can disconnect the pipe from that liquid tank and it will still be connected to the pump
- if you disconnect the pipe from the pump, then it will disconnect from the liquid tank as well
Maybe this is confusing to the user, we can still kick that out later again.
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.
Added a new library for liquid containers that is based on the original barrel script.
Library_LiquidContainer
- Extracted the interface from the barrel. The function names and argument types are not final yet.
- Fixed an inconsistency in the script: There were two ways of determining whether a barrel is suited
for a material. Either by name, or material index.
- renamed argument names to "liquid_name" for liquids, "amount" for quantities, so that the code is more easily understandable
- replaced comparison 'fill level > 0' with 'is not empty?'
- moved storage variables to a local proplist, so that names do not clash
- Ordered the methods by application and documented each section
Barrel:
- The original barrel functions delegate to Library_LiquidContainer-functions now, so that the original functionality is not disturbed. Obsolete functions are marked with "TODO: deprecated".
- Moved barrel value change to the update function
- Moved hit sound effect to separate function
- Replaced uses of the magic number '3' with a runtime-overloadable call to GetBarrelIntakeY()
- Replaced comparison 'fill level > 0' with 'is not empty?'
MetalBarrel:
- Adjusted the hit function. The difference between this and the normal barrel is the hit sound and material position. These should be constants or functions, instead of magic numbers
- Moved hit sound effect to separate function
- Removed the Hit()-function, because the hit sound is played in a separate function now
- With this change the y-offset of the barrel checking for other liquids on a hit is now 3 instead of 7. This should be ok, because the barrels have the same dimensions, it seemed strange that they would have different offsets
The steam engine treats barrels the same as itself when it comes to extracting liquids. This removes the need for the callback OnFuelRemoved() in the barrel, as well as the stupid definition call from the barrel to the steam engine.
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.
The pipe can be connected from the interaction menu now, too. Expanded the disconnection logic, because more problems arise when the pipe can still be connected to other structures - it would be sufficient to remove the line, but that could be annoying:
- if the pipe is connected to a container, then you can disconnect the pipe from that liquid tank and it will still be connected to the pump
- if you disconnect the pipe from the pump, then it will disconnect from the liquid tank as well
Maybe this is confusing to the user, we can still kick that out later again.
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.
Previously, it was checked incorrectly whether the action was "Dig". Then the check was thrown out completely in https://git.openclonk.org/openclonk.git/commit/39e86474fccbd54eb357175d2b8fbec5c60639ab - which did remove the warning but not solve the defect.
This should be a proper fix. The shovel only does stuff when the user is digging AND actually using this very shovel for it.
Added a new library for liquid containers that is based on the original barrel script.
Library_LiquidContainer
- Extracted the interface from the barrel. The function names and argument types are not final yet.
- Fixed an inconsistency in the script: There were two ways of determining whether a barrel is suited
for a material. Either by name, or material index.
- renamed argument names to "liquid_name" for liquids, "amount" for quantities, so that the code is more easily understandable
- replaced comparison 'fill level > 0' with 'is not empty?'
- moved storage variables to a local proplist, so that names do not clash
- Ordered the methods by application and documented each section
Barrel:
- The original barrel functions delegate to Library_LiquidContainer-functions now, so that the original functionality is not disturbed. Obsolete functions are marked with "TODO: deprecated".
- Moved barrel value change to the update function
- Moved hit sound effect to separate function
- Replaced uses of the magic number '3' with a runtime-overloadable call to GetBarrelIntakeY()
- Replaced comparison 'fill level > 0' with 'is not empty?'
MetalBarrel:
- Adjusted the hit function. The difference between this and the normal barrel is the hit sound and material position. These should be constants or functions, instead of magic numbers
- Moved hit sound effect to separate function
- Removed the Hit()-function, because the hit sound is played in a separate function now
- With this change the y-offset of the barrel checking for other liquids on a hit is now 3 instead of 7. This should be ok, because the barrels have the same dimensions, it seemed strange that they would have different offsets
Extracted the dig speed modification part to a separate function, so that other scenarios can easily overload this. Setting the value to 75% of the input speed provided a good handling in my tests. This is not included in this commit, feel free to experiment with it first.
Mark