![[us]](/mwf/flags/us.png "United States")
> Having another "non-limited, but not infinite" mode for stackable objects seemed to be strange, too.
I think having one library for "small stacks" and one library for "large stacks" seems more weird. Why not just increase the limit of 999 objects? Worst case, just limit the display to 999 but allow larger stacks internally.
> You can put oil into it, but then you would not be able to put any water into it (as a reserve) until the oil is used up
Why is that? If the liquids are objects, you can have a stacked water object and a stacked oil object both sitting in the foundry.
> This is somewhat hindered by the fact that the producer handles fuel and liquid completely different from normal components.
I thought the whole idea of the "liquids are objects"-change was to unify this interface. I.e.: Remove the special handling of liquids from the producer library.
> - what is the benefit of having, say 100 water items in the kitchen, instead of a barrel that contains 100 water?
You do not need to route stuff through the barrel. You just look for components directly in the producer.
> - would barrel empty into the kitchen if you transfer a water barrel to the kitchen, leaving the empty barrel in the Clonk?
Yes, just like earth in the foundry right now.
![[de]](/mwf/flags/de.png "Germany")
I completely forgot about the original idea and I hesitated with changing the interfaces of the existing objects.
Did so.
It's not a problem for producers, but a barrel with both water and oil, or oil and lava might be weird. As a nice side effect the barrel could have an extra slot then, and it would display the contained liquid.
Forgot about that, as I already said. I am rewriting that part again, but I still keep a small special handling: Producers will still convert wood/coal to "fuel", or ice to "water" (<- is this still necessary? Ice could be converted to water right on entrance. Wood not so much, because it may be an actual resource component) if the contained amount of liquid objects is insufficient.
>Worst case, just limit the display to 999 but allow larger stacks internally.
Did so.
>Why is that? If the liquids are objects, you can have a stacked water object and a stacked oil object both sitting in the foundry.
It's not a problem for producers, but a barrel with both water and oil, or oil and lava might be weird. As a nice side effect the barrel could have an extra slot then, and it would display the contained liquid.
>I thought the whole idea of the "liquids are objects"-change was to unify this interface. I.e.: Remove the special handling of liquids from the producer library.
Forgot about that, as I already said. I am rewriting that part again, but I still keep a small special handling: Producers will still convert wood/coal to "fuel", or ice to "water" (<- is this still necessary? Ice could be converted to water right on entrance. Wood not so much, because it may be an actual resource component) if the contained amount of liquid objects is insufficient.
> but I still keep a small special handling: Producers will still convert wood/coal to "fuel", or ice to "water"
Yes, I don't think there's need for a "fuel" object because it can just be a property of existing objects. I.e. IsFuel (or GetFuelValue?) and IsWater.
Another (maybe unrelated) idea we had was that definition components should accept strings as callback functions. I.e. stuff like Components=Wood=1,"IsEarth"=5,"IsWater"=10.
Why not have the other objects have a function "IsSubstituteForComponent(){ return [Earth];}" or something like that. It could be handled by script entirely.
That's actually a very old feature wish!
Then we will have to problem about how to communicate that to the player. I want to be able to show the possible construction components in a menu - ideally WITHOUT having to iterate through every definition to check whether it replaces anything.If that is not possible, I would probably iterate through every definition once and then create a mapping for the replacement parts. That might imply that they would not be able to change at runtime.
Yes, creating the mapping at startup should be no problem. Definition values can generally not be changed at runtime so that shouldn't be a problem.
Well, you could do the callback on objects in-vivo. That means, you could (as a scenario designer) decide to make the sand an alternative to earth IFF you have taked to a certain NPC - that wouldn't work then. Or you'd have to somehow force the system to update. Anyway, details.
Something else: At the moment I am struggling with the fact that the stacks can contain any amount of items, but the barrel has an upper limit for the contained amount.
At first I overloaded MaxStackCount() in the liquid object, so that it regards the liquid container capacity. This still lets the object enter an empty liquid container with the capacity exceeded (i.e. put a stack 500 water into a barrel, the barrel should contain a stack with 300 water and the other water should be reduced to 200 -> now the 500 water simply enter the barrel).
Is it ok if I implement this in the stackable library right away, because it could also be a use case in other objects (infinite arrow dispenser or whatever?)
At first I overloaded MaxStackCount() in the liquid object, so that it regards the liquid container capacity. This still lets the object enter an empty liquid container with the capacity exceeded (i.e. put a stack 500 water into a barrel, the barrel should contain a stack with 300 water and the other water should be reduced to 200 -> now the 500 water simply enter the barrel).
Is it ok if I implement this in the stackable library right away, because it could also be a use case in other objects (infinite arrow dispenser or whatever?)
>Is it ok if I implement this in the stackable library right away, because it could also be a use case in other objects (infinite arrow dispenser or whatever?)
What exactly? Don't forget that this might have implications for the interaction menu and other things, too
Put a stack of
Would not have an effect on containers that have no limit for specific items.
x objects into an empty container that can hold up to y < x items => the container now holds a stack of y items, and the original object still exists outside the container with now x - y in the stack.Would not have an effect on containers that have no limit for specific items.
I got to the part where ice is the only object that is not a liquid object, but *could* be converted to water. I can think of a few options, but I do not know which one is best. Any opinions?
- Convert ice to water on collection. Not a bad option in my opinion: Ice can enter the producer only if one of its products needs ice or water. I cannot think of many products that need ice. In that case the producer would convert ice to water as a first option, then collect ice if there is sufficient water and other products need ice.
- Remove the ice to water conversion entirely. I am neutral on this.
- Make ice collectible, and have it convert to water object when it melts (on its own?) inside the container. May be a little weird for the player.
- Convert ice to water on collection. Not a bad option in my opinion: Ice can enter the producer only if one of its products needs ice or water. I cannot think of many products that need ice. In that case the producer would convert ice to water as a first option, then collect ice if there is sufficient water and other products need ice.
- Remove the ice to water conversion entirely. I am neutral on this.
- Make ice collectible, and have it convert to water object when it melts (on its own?) inside the container. May be a little weird for the player.
Concerning the ice and "ice as water" problem that I am still facing, I'll implement it the following way: When ice enters a producer that needs water, then the producer will convert it to water. My favored solution would be to not have ice convertable to water at all (because this needs a special handling in the producer again). However, I do not know if the ice to water conversion is important in existing scenarios.
Good news! I made progress with the stackable items again and now I am rounding up the remaining stuff: Liquid objects have to be handled properly by producers :)
After the latest changes I consider the branch (nearly) finished. Please test this branch again. I playtested it and found one issue that I will fix: When I take water from a producer, then it also enters the Clonk, although that was not intended to be possible. All the other cases that I could think of are covered by unit tests.
Furthermore, I want to rename the liquids. At the moment their IDs are Liquid_Water, Liquid_Acid, etc., but I think that Water or Acid is better. Any opinions on this?
Furthermore, I want to rename the liquids. At the moment their IDs are Liquid_Water, Liquid_Acid, etc., but I think that Water or Acid is better. Any opinions on this?
Renaming may be a conflict if we ever decide to put all loaded materials as proplists into the global namespace. (e.g. to be able to write CastPXS(Acid) or if (GetMaterial(x,y).Corrosive) ...)
That is a problem with the existing Earth object, too, isn't it?
I am, for my part, done with the work and will push the branch to the repository now, without merging it. This makes it a lot easier for everyone to test, I think.
I ran into a new issue a few days ago, this exists on the master branch, too, and will be fixed on liquid_container. The gist of it:
- the object interaction menu transfers items differently when you clicking a single item in the inventory and when clicking the "transfer all" arrow/button between the both sides
- this results in a particularly annoying border case: say you have 50 single arrows in a lorry (which is unlikely, how should they get there?) if you transfer all at once, this leaves you with 50 single arrows in the surrounding. If you transfer the arrows by clicking each arrow separately, then the arrows would form stacks.
- the lorry seems to collect certain items that are transferred from it again. This was the case if I have a large number of arrow packs inside the lorry.
This is all tested by yet another unit test. I extracted the transfer to two functions, so that I can test them and see the difference. My aim is to use one function for transferring items in the end and have the unit tests still pass. It is not my intention to test other aspects of the interaction menu, this can be done by someone else later if the need arises.
- the object interaction menu transfers items differently when you clicking a single item in the inventory and when clicking the "transfer all" arrow/button between the both sides
- this results in a particularly annoying border case: say you have 50 single arrows in a lorry (which is unlikely, how should they get there?) if you transfer all at once, this leaves you with 50 single arrows in the surrounding. If you transfer the arrows by clicking each arrow separately, then the arrows would form stacks.
- the lorry seems to collect certain items that are transferred from it again. This was the case if I have a large number of arrow packs inside the lorry.
This is all tested by yet another unit test. I extracted the transfer to two functions, so that I can test them and see the difference. My aim is to use one function for transferring items in the end and have the unit tests still pass. It is not my intention to test other aspects of the interaction menu, this can be done by someone else later if the need arises.
>- this results in a particularly annoying border case: say you have 50 single arrows in a lorry (which is unlikely, how should they get there?) if you transfer all at once, this leaves you with 50 single arrows in the surrounding. If you transfer the arrows by clicking each arrow separately, then the arrows would form stacks.
Yes. I guess I assumed that when transferring "all" items of a stack into another objects, the objects would merge themselves appropriately. That's obviously not true if you transfer to a non-container (i.e. "surrounding")
>- the lorry seems to collect certain items that are transferred from it again. This was the case if I have a large number of arrow packs inside the lorry.
That sounds like a real bug. Is the object directly recollected because it is ejected inside the collection zone of the lorry?
Yes, the situation is as follows: The object is in the lorry. Transferring it to the surrounding makes the Clonk that you control drop the item as if it were in his inventory. The item then appears directly in the collection zone of the lorry and it gets recollected. My solution would be to add a "BlockCollectionByLorry" effect to that item for a few frames, so that it can safely drop to the ground.
>My solution would be to add a "BlockCollectionByLorry" effect to that item for a few frames, so that it can safely drop to the ground.
Why don't you just set
Collectible = false for a few frames (probably exactly 1)?
That effect is already there, because that is part of the script that dumps objects from the lorry when you tilt it.
Is there actually still anything that prevents us from merging this? Zapper wanted to test it, but it isn't totally broken.
Not that I know of, go ahead with the merge if you are around to do some fixes for issues that pop up.
Very cool stuff with the steam engine, some stuff I noticed:
* Oil and water liquid objects do not have a Description.
* I would expect it to be possible to connect the pump to the foundry as well.
What is the other stuff that needs testing?
* Oil and water liquid objects do not have a Description.
* I would expect it to be possible to connect the pump to the foundry as well.
What is the other stuff that needs testing?
Marky? Are you still working on this?
Also: There should be a function for barrels which fills it fully with a new liquid, i.e. for scenario scripts.
Also: There should be a function for barrels which fills it fully with a new liquid, i.e. for scenario scripts.
Yes, I expanded the unit test and the functionality of the foundry, so that you can pump oil into it, too. I will add that function to the barrel.
Could you push these changes?
Also: please fix this bug and potentially other scenarios with barrels that broke.
Also: please fix this bug and potentially other scenarios with barrels that broke.
Yes, I will do that once I get better. Sorry for the inconvenience.
Don't worry, it is very minor so take your time, just wanted to remind you of it.
Done. Only the option for creating a full barrel is missing yet, sort of. There are three inconventient options at the moment:
First, I'd like to replace the string input with a definition input:
a) CreateObject(Barrel)->PutLiquid("Water", 300);
b) CreateObject(Barrel)->PutLiquid("Water", Barrel->GetLiquidContainerMaxFillLevel());
c) Water->CreateLiquid(300, CreateObject(Barrel));
First, I'd like to replace the string input with a definition input:
barrel->PutLiquid(Water, 300); Second, the function PutLiquid could automatically insert as much as possible if the second parameter is nil. What do you think?
Then it should take both the string and the definition maybe? The nil thing sounds good.
>Second, the function PutLiquid could automatically insert as much as possible if the second parameter is nil. What do you think?
Yes, please.
Are full barrels saved correctly in Objects.c? (i.e. is SaveScenarioObject implemented?)
What exactly do I have to save? The only thing that comes to mind is the barrel skin, because the contents are separate stackable objects anyway.
I would say you should not save the liquid objects, but convert them to one of the convenience calls you mentioned in the posting above instead. That interface may be more stable than the internal objects.
How do I remove the internal objects from the savegame then? After reading the documentation I think that I have to remove the liquid object from "props", if it is contained in a container, and let the container handle the creation. That also means that you have various special cases in the liquid object. How is this better or more stable than the liquid object, which is the same as an arrow pack, after all?
I would assume it's more stable just in case e.g. we re-decide at some point to not have liquid objects. A call can always be reimplemented to do something different, but the liquid objects can not.If you think the objects are stable enough that we stick with them, I guess we could keep saving as objects.
Btw: To not save an object, you can just return false in SaveScenarioObject.
Are you concerned about causing bugs in case we change the implementation again, or are you thinking about backwards compatibility?
At the moment, saving a barrel with liquid is the same as saving a bow with arrows internally, so that works. Replacing the working system with a call, while making sure that the contained liquid objects are not saved means both effort and possibly more confusion (i.e. why was that added??). In case we want to remove the liquid objects again we will just have to implement SaveScenarioObject() in the barrel again, however we like.
On the other hand, I understand that we cannot forget implementing SaveScenarioObject() again if we already have that call there. This, however, also means that the liquid objects have to decide when they should be saved and when not. This makes things more complicated than necessary, in my opinion, so I'd just leave it as it is.
At the moment, saving a barrel with liquid is the same as saving a bow with arrows internally, so that works. Replacing the working system with a call, while making sure that the contained liquid objects are not saved means both effort and possibly more confusion (i.e. why was that added??). In case we want to remove the liquid objects again we will just have to implement SaveScenarioObject() in the barrel again, however we like.
On the other hand, I understand that we cannot forget implementing SaveScenarioObject() again if we already have that call there. This, however, also means that the liquid objects have to decide when they should be saved and when not. This makes things more complicated than necessary, in my opinion, so I'd just leave it as it is.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
