Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / Liquid container branch
1 2 3 Previous Next
Parent - - By Sven2 Date 2016-06-05 14:30

>  In case we want to remove the liquid objects again we will just have to implement SaveScenarioObject() in the barrel again, however we like.

No. In case we remove the liquid objects again, all scenarios that were saved with the objects will be broken.
Parent - By Marky [de] Date 2016-06-05 15:14
So you are actually talking about the way you design scenarios, more so than you are talking about savegames? This problem never occurred to me, because when creating a new scenario I never actually save it, but rather change something in the script and start it again. In such a case I use a method call of course. Now I see what you mean. This is a lot different than keeping backwards compatibility for old savegames!
Good, I'll change it then.
Parent - - By Maikel Date 2016-06-02 09:11 Edited 2016-06-02 12:07
Can you also make the foundry accept water for loam production?

Edit: I have implemented this myself.

Currently the foundry accepts both water and oil, and both max 300 pixels, the max liquid count is per material type which for me is fine.

Two more issues I found:

* Why is public func Disperse(int angle, int strength) not defined in Library_Liquid, but instead repeated for each liquid type.

* Is there a problem when pumping durolava cause it does not have its own material? I.e. does this system change durolava to lava?

I like the new system a lot as loam production is really easy now, and we should really make a scenario which involves a lot of pumping different materials.
Parent - - By Marky [de] Date 2016-06-04 10:24

>Is there a problem when pumping durolava cause it does not have its own material? I.e. does this system change durolava to lava?

Yes. The pump does not change the durolava, it will pump it to the drain and either exit material or tries filling it into a container. The container searches for a definition "DuroLava", cannot find it, and inserts nothing, clogging the pump. The effect is that DuroLava is not filled into containers.

>Why is public func Disperse(int angle, int strength) not defined in Library_Liquid, but instead repeated for each liquid type.

The basic liquid object is just an abstract concept. This liquid object implements a function "Disperse" that removes the object, because this is the only thing that all liquids should have in common. The rest is up to the liquid itself: Currently we have liquids that become material pixels when they disperse. However, you can have other liquids, that dissolve into a particle effect, or maybe into objects. Think of an inflammable liquid that casts flame objects, or a "instable magical liquid" that turns into smoke.
Currently we have only liquid objects that turn into material pixels though.
Parent - - By Maikel Date 2016-06-05 09:46
So then we need a durolava object I suppose?

The default disperse functionality can still be defined in Library_Liquid and fancy liquids can overload it in my opinion.

I am working on a scenario where a big tank has to be filled with oil, in order to speed up matters players should be able to connect several pumps. I think in general we should allow connecting several pipes to a tank (e.g. foundry supplied with water and oil at the same time). Can you do this? Or should I add this feature myself to the tank library?
Parent - - By Marky [de] Date 2016-06-05 10:20
The default disperse functionality removes the object. The other fancy functionality, such as DisperseMaterial() and DisperseParticles() are already part of the library and you just have to add a line in the new material objects. I'd rather go for a new definition that includes Library_Liquid and implements the DisperseMaterial() by default, then have the liquid objects include that new definition, if you do not like the way it is done now.

The problem with completely overloading the function is the following: If Disperse() should do more, gets more parameters, or whatever, then you have to adjust all the overloads accordingly. With the current implementation you can have specific functionality per liquid object by doing another function call, which is standardized by the library, and inherit all changes with the inherited(...) call.

I can add the multiple connections, sure. Your example for the foundry makes sense. Are there any more use cases? I am thinking about giving the foundry a maximum of 600 units of liquid, but having it reject one liquid if its amount is at 300 units.
Why did you introduce this limit? I see that unlimited amounts are a problem for pumps, but usually you'd like to put more than one barrel into the foundry, right?
Parent - - By Maikel Date 2016-06-05 12:38
The foundry has the same limit as the steam engine, we can make it more. I do like the limit per liquid type though, so that you don't block production of loam when the foundry is filled with oil. So please keep that as it is.

Another use case is in my scenario where you connect multiple pumps to a drain structure which counts the pumped pixels and then fulfills the goal.
Parent - By Marky [de] Date 2016-06-05 14:02
If the foundry can take 300 of each material, then this is a bug, in the sense that I did not intend it like that: the amount of all liquids should add up to 300. My proposed change was to introduce exactly what you are suggesting though: not blocking loam production.
Parent - - By Marky [de] Date 2016-06-05 11:03
I forgot about the duro lava object. Yes, what should we do with that? I think it will look strange for the player if there are two types of lava.
Parent - By Maikel Date 2016-08-07 09:21
Maybe the lava object should turn into ashes like normal lava for a given temperature?
- - By Maikel Date 2016-06-11 20:46
Another issue: when a pump has its source in an oil field and its drain connected to the steam engine, the steam engine will fill itself, but then still the pump tries to pump every second or so using a bit of oil. This is unnecessary and leads to useless consumption of oil.
Parent - - By ala [de] Date 2016-06-11 22:11
Cool, we have oil now?
Parent - By Maikel Date 2016-06-12 08:27
Yes, and it even burns correctly. I am working on a settlement scenario about oil pumping which is not too hard. It will also serve as a good test of the new liquid system.
Parent - By Marky [de] Date 2016-06-12 20:34
Yes, the pump could stop pumping if the target says so. I'll implement that.
- - By Maikel Date 2016-08-07 09:20
Some more feedback, the system can be a bit slow with a lot of pumps:

[10:01:18] Profiler statistics:
[10:01:18] ==============================
[10:01:18] 02279ms  Pump.Pumping
[10:01:18] 01526ms  Pump.InsertMaterialAtDrain
[10:01:18] 01518ms  RefineryDrain.PutLiquid
[10:01:18] 01396ms  Library_Power.VisualizePowerChange
[10:01:18] 01381ms  Library_Power.FxVisualPowerChangeRefresh
[10:01:18] 01347ms  Library_Power.CheckPowerBalance
[10:01:18] 01345ms  GUI_BarProgressBar.Close
[10:01:18] 01318ms  Oil.RejectEntrance
[10:01:18] 01318ms  Oil.MergeWithStacksIn
[10:01:18] 01301ms  Oil.UpdateStackDisplay
[10:01:18] 01293ms  Oil.TryAddToStack
[10:01:18] 01281ms  Oil.DoStackCount
[10:01:18] 00990ms  Library_Power.RefreshProducers
[10:01:18] 00970ms  Pump.CheckState
[10:01:18] 00880ms  GUI_BarProgressBar.Destruction
[10:01:18] 00834ms  Pump.UpdatePowerUsage
[10:01:18] 00817ms  Library_Power.AddPowerConsumer
[10:01:18] 00817ms  Pump.RegisterPowerRequest

We should at least look at the easy optimizations.
Parent - - By Marky Date 2016-08-18 16:10
Thanks. Did you add a test for this?
Parent - By Maikel Date 2016-08-18 21:15
Not yet, it is not my highest priority.
- - By Maikel Date 2016-12-18 12:28 Edited 2016-12-18 12:33
The system now seems to work very nicely apart from and the system starts to get slow with more than 25 pumps or so. One way to resolve the last issue is maybe to give an option to upgrade the pump with a better engine which would cost some metal and increases the power consumption a bit but then gives twice the pumping speed.

Also what is annoying now is supplying for example steam engines from an oil field. It would be nice if one pump can have multiple drains connected to multiple steam engines and fills all of them. In general allowing multiple drains could not be bad, the interaction menu might even allow for giving them priorities. But I have to think about this a bit more.

Edit: Also a liquid tank which can have multiple connections would be a nice structure to have. It can have an upgrade to hold to different liquid types for example.
Parent - - By K-Pone [de] Date 2016-12-18 14:34
Another cool thing would be if you could connect a pipe to a steam engine that acts as an output pipe if the steamengine is filled with oil, so liquid will be pumped to the next steamengine or whatever it is connected to.
Parent - By Marky [de] Date 2016-12-18 16:43
I wanted to suggest  this, too :)
- - By Maikel Date 2016-12-24 15:45
Question: why are liquids allowed to enter normal containers? A lorry can hold infinite amounts of liquids now.
Parent - - By Marky Date 2016-12-24 18:55
They should not be able to enter all containers, but only specific ones (including lorries). The lorry should be able to hold 300 units or so, like a barrel. Maybe I gave it the capacity of 10 barrels? Anyway the idea was that you can fill a lorry with liquid and spill it on enemies by tipping it over.
Parent - - By Maikel Date 2016-12-24 22:47
Well, then that has to be correctly implemented, because it is now buggy. The same with holding multiple liquids at the same time in the liquid container. But I am looking at that.
Parent - - By Marky Date 2016-12-24 23:30
What container are you referring to? A few hints: MaxStackCount should be called on liquid objects, not on their definition. How a container handles multiple liquids has to be defined by that container, because the libraries offer the interface only, not a default behaviour. The barrel can, for example hold only one type of liquid.
Parent - By Maikel Date 2016-12-25 11:42
Because the lorry can hold an infinite amount of liquids, so that is buggy.
Parent - - By Marky Date 2016-12-25 19:01
Concerning your latest change: Adding the liquid name as a parameter to GetLiquidContainerMaxFillLevel() is not what I intended. If a container has a limit of 300, for example, its capacity for the sum of all liquids is 300. So you could have 300 water in it, or 150 water and 150 oil. Was this what caused the confusion, what you deemed as buggy behaviour? Now you can have, for example, 300 of each type of liquid in a container (which is kind of strange, isn't it?)

Your changes could cause problems with filling barrels - could you please run the Tests.ocf\LiquidContainer.ocs to see if it still works?

Further comments:
* Library_Liquid: You used GetID() a couple of times, you should replace this with GetLiquidType()
* Could you please commit formatted code and actual changes separetely? This makes reviews a lot more easier.
Parent - - By Maikel Date 2016-12-26 17:54
For the barrel that is indeed strange. But for the foundry it is better to have space for X water, but infinite concrete since it produces that. So we have to go over everything and adapt accordingly. Work in progress and also needs some testing in actual scenarios to what feels best.

Test 5 failed, but that was to be expected with these changes, we can fix this later, as it only concerns the pump.

* Yes I can, just a question, why does it work with both id and string then?
* Yes, but only if I feel like using -i and this was not the case for the latest commits.
Parent - - By Marky [de] Date 2016-12-26 19:29
In the first draft I did not think about liquid objects and started implementation via string. Since all liquids are also objects now, we could actually remove the support for strings and restrict it to IDs entirely. Still, the function is/can be usesul for objects that are a different liquid type then their own ID. For example a "muddy water" object could still have the same liquid type as a normal water object, but a different ID.

Ok. Can I help you with anything?
Parent - By Maikel Date 2016-12-26 20:32
You can take any of these: (except maybe the multiple drains for the pump, that sounds like a change we should do after some more careful thinking, at least I want to think about it more).

I won't touch the liquid system for a while then. It is better not to both edit it I think.
Parent - - By Marky Date 2016-12-24 21:12
Why did you remove the string constants for certain effect names, for example the liquid dispersion effect? This was done intentionally: Scripts can rely on the constant, so if the effect name is ever changed you do not have to adjust other scripts, only the constant.
Parent - - By Maikel Date 2016-12-24 22:46
Because it was not so readable to me, and I don't see that advantage. Why would you change the effect name? The same now holds for the constant name.
Parent - - By Marky Date 2016-12-24 23:07
If an external pack references the constant name and the constant name is changed you get an error in the log.
If an external (or internal) object searches for a string, but the effect name is changed, then this change is hard to detect because the functions will most likely just return nil.
Effect name changes can happen, it is just more safer that way.
Parent - - By Maikel Date 2016-12-25 11:41
I don't agree, it is more lines of code which adds to unreadability. Maybe the engine should produce some sensible warning when trying to create or call an effect which is defined nowhere.
Parent - By Luchs Date 2016-12-25 13:19
It will, if you use CreateEffect. For AddEffect, a warning would be no good as those are useful as markers.
Up Topic Development / Scenario & Object Development / Liquid container branch
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill