Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / Liquid container branch
1 2 3 Previous Next
Parent - - By Sven2 [us] Date 2016-02-29 14:57

> 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.
Parent - - By Marky [de] Date 2016-02-29 22:18
I completely forgot about the original idea and I hesitated with changing the interfaces of the existing objects.

>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.
Parent - - By Sven2 [us] Date 2016-03-01 02:15

>  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.
Parent - - By Marky [de] Date 2016-03-01 05:45
Why not have the other objects have a function "IsSubstituteForComponent(){ return [Earth];}" or something like that. It could be handled by script entirely.
Parent - By Sven2 [us] Date 2016-03-01 06:09
Yes, that's also an option.
Parent - By Clonkonaut [de] Date 2016-03-01 10:29
That's actually a very old feature wish!
http://bugs.openclonk.org/view.php?id=1148
Reply
Parent - - By Zapper [de] Date 2016-03-01 12:58
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.
Parent - - By Sven2 [us] Date 2016-03-01 13:54
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.
Parent - By Zapper [de] Date 2016-03-01 20:40
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.
Parent - - By Marky [de] Date 2016-03-01 22:02
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?)
Parent - - By Zapper [de] Date 2016-03-01 22:33

>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
Parent - By Marky [de] Date 2016-03-01 22:47
Put a stack of 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.
Parent - - By Marky [de] Date 2016-03-17 22:14
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.
Parent - By Marky [de] Date 2016-03-23 22:23
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.
Parent - By Marky [de] Date 2016-03-16 22:46
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 :)
Parent - - By Marky [de] Date 2016-03-25 13:46
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?
Parent - - By Sven2 Date 2016-03-25 15:57
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) ...)
Parent - - By Marky [de] Date 2016-03-25 16:14
That is a problem with the existing Earth object, too, isn't it?
Parent - - By Sven2 [us] Date 2016-03-25 17:00
Hm, right.

Maybe if we add materials, we should just put them into a namespace then and rename the definitions as you suggested.

(CastPXS(Materials.Acid))
Parent - By Marky [de] Date 2016-03-25 17:21
Sounds good. I am merging the master branch into my branch now.
Parent - - By Marky [de] Date 2016-03-25 20:10
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.
Parent - - By Zapper Date 2016-03-25 23:47
I will have a look when I am back in Germany (in April)!
Parent - - By Marky [de] Date 2016-04-20 17:29
Did you get a chance to test the branch yet?
Parent - By Zapper [de] Date 2016-04-24 16:29
No, not yet
Parent - - By Marky [de] Date 2016-04-06 20:15
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.
Parent - - By Zapper [de] Date 2016-04-06 20:47

>- 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?
Parent - - By Marky [de] Date 2016-04-08 20:25
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.
Parent - - By Zapper [de] Date 2016-04-08 22:06

>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)?
Parent - - By Marky [de] Date 2016-04-08 22:07
That effect is already there, because that is part of the script that dumps objects from the lorry when you tilt it.
Parent - By Zapper [de] Date 2016-04-08 22:17
Ah, ok - as long as you keep that in the lorry, why not. I guess if it's intended for every object exiting the lorry, you could just add the effect in Ejection to every object that is not contained after Ejection
Parent - - By Marky [de] Date 2016-05-01 09:43
Is there actually still anything that prevents us from merging this? Zapper wanted to test it, but it isn't totally broken.
Parent - - By Maikel Date 2016-05-01 15:57
Not that I know of, go ahead with the merge if you are around to do some fixes for issues that pop up.
Parent - By Marky [de] Date 2016-05-01 18:47
Yep, merged it now. Running the unit test for object interaction menu I noticed that I wanted to merge the two transfer functions used there into one function. I will do this later.
Parent - By Zapper [de] Date 2016-05-01 16:56
Yes, I didn't really have enough free time to look at it in the last weeks :(
- - By Maikel Date 2016-05-01 20:07
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?
Parent - - By Maikel Date 2016-05-22 17:26
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.
Parent - - By Marky [de] Date 2016-05-22 19:19
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.
Parent - By Maikel Date 2016-05-22 19:38
Please to the liquid container library directly.
Parent - - By Maikel Date 2016-05-31 11:20
Could you push these changes?

Also: please fix this bug and potentially other scenarios with barrels that broke.
Parent - - By Marky [de] Date 2016-05-31 19:45
Yes, I will do that once I get better. Sorry for the inconvenience.
Parent - - By Maikel Date 2016-05-31 21:29
Don't worry, it is very minor so take your time, just wanted to remind you of it.
Parent - - By Marky [de] Date 2016-06-01 19:50
Done. Only the option for creating a full barrel is missing yet, sort of. There are three inconventient options at the moment:


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?
Parent - By Maikel Date 2016-06-01 20:00
Then it should take both the string and the definition maybe? The nil thing sounds good.
Parent - By Zapper [de] Date 2016-06-01 20:43

>Second, the function PutLiquid could automatically insert as much as possible if the second parameter is nil. What do you think?


Yes, please.
Parent - - By Sven2 [us] Date 2016-06-01 23:14
Are full barrels saved correctly in Objects.c? (i.e. is SaveScenarioObject implemented?)
Parent - - By Marky [de] Date 2016-06-02 04:44
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.
Parent - - By Sven2 Date 2016-06-02 05:13
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.
Parent - - By Marky [de] Date 2016-06-04 09:59
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?
Parent - - By Sven2 Date 2016-06-04 15:35
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.
Parent - - By Marky [de] Date 2016-06-05 10:36
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.
Up Topic Development / Scenario & Object Development / Liquid container branch
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill