Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / New LiquidPump System
- - By ST-DDT [de] Date 2011-10-09 15:36 Edited 2011-10-11 23:40
I think we should give up the old liquidpipe system.

I developed a liquid tanks for CR.
But i found it very ugly because i had to override the Liquid functions of CR because they only allow putting liquid into barrels.
And does not allow blocking inputs or limiting them very well.

So i invented a new functionality.

It should exist only one type of liquidpipe (not both source and drainpipe). And an engine/default function for liquid transportation.
The pump pumps liquid into the pipe and the structure connected gets an LiquidInput(int dMat, ind dAmount, object pSource, object pPipe) call

Here is my fast implemented code for the pump, pipe and 2 sample buildinds (Tank and Barrelcontainer). (maybe the last one should be made availiable for #include like the Door
http://pastebin.com/Fu6eZCPS

Pump->Timer()
#SourcePipe->GetLiquid(int dnMat, int dnMaxAmount, object pPump)
##SourceObject->LiquidOutput(int dnMat, int dnMaxAmount, object pPump, object pPipe)
#TargetPipe->PutLiquid(int dnMat, int dnMaxAmount, object pPump)
##TargetObject->LiquidInput(int dnMat, int dnMaxAmount, object pPump, object pPipe)

I finished coding and appended the .patch file bellow. Testing this was really hard, because there were no structures to test with.
Attachment: LiquidPipeSystem.patch - Liquid Pipe System (23k)
Parent - - By Maikel Date 2011-10-11 16:58
First of all, take care of this. I think this system makes sense, maybe you can work it out completely and provide a patch where you give the pump, pipe and pipeline your new functionality? Also consider giving the foundry/steamengine the functionality of obtaining oil(Tank in your example?). I'll probably then add the possibility of burning that fuel.

On another note: We need oil!
Parent - - By ST-DDT [de] Date 2011-10-11 18:05
I will make all the script.c files.
But DefCore/Picture/Mesh and all this have to be done by other people.
Maybe i write down some required DefCore-Options, but the rest is up to you (others)
Parent - By Maikel Date 2011-10-11 18:08
Yes that's fine of course, though if you know how to operate tortoiseHg providing a patch where you only change scripts of existing objects would be easier for us.
Parent - - By Clonkonaut [ie] Date 2011-10-11 18:31
As Maikel said, a .patch or .diff file from tortoisehg would be better to handle (and your name would appear in the repository).
You can use the graphics you need from CR to test your stuff and we will see to replace them in the future.
Reply
Parent - By ST-DDT [de] Date 2011-10-11 19:35 Edited 2011-10-11 23:41
I'll try.
And i'll change the metal barrel graphics via PowerPaint!^^ for oil because i love oil

If Tortoise doesn't take to much time i'll finish it today.

Finished see first post
Parent - By Newton [de] Date 2011-10-11 18:55
Yeah, placeholder graphics are completely fine.
Parent - Date 2011-10-11 18:54
Parent - - By Maikel Date 2011-10-12 13:27
Okay, pumping works. But you provide us with the unused libraries, without telling what they can be used for. So it looks like the patch is only half finished.
Also don't use names like
LiquidOutput(string sznMaterial, int inMaxAmount, object pnPump, object pnPipe, bool bnWildcard)
but rather
LiquidOutput(string mat, int max, object pump, object pipe, bool wild_card).
Parent - - By Clonkonaut [ie] Date 2011-10-12 14:39
To explain this: C4Script Style Guidelines
Reply
Parent - - By ST-DDT [de] Date 2011-10-12 15:31 Edited 2011-10-12 15:55

>generally, use meaningful identifiers which are self explanatory: e.g. weapon_strength rather than iStr
>don't use hungarian notation, preferably use lowercase_separated_by_underscores for variables


lowercase ok ill change that
hungarian notation vs meaningful identifiers, what identifiers are more meaningfull than sznMaterial? this var tells me its a string (sz), its declared as input (n) and its a material
-mat could be anything, but you can guess its material
-and max? ...
-why is wild_card sperated via _?
Somewhere in that code I've read sz.... and i never used sz before (s only)

>use CamelCase() for functions


i did

>use PREFIX_Identifier for static constants


I didn't use any

>But you provide us with the unused libraries, without telling what they can be used for.


BarrelFiller:
"Author: ST-DDT
Import this to allow the structures to
-fill liquids which has been pumped into the building into barrels
-extract liquids from barrels and pump it somewhere else"


what else should i write there?
should i write that if you import this via #include into your structures and also objects in common,
that all inserted materials (via pipe or other ways) are put into barrels and that all extracted materials are extracted from barrels?
(you also can declare this as global func to add this functionality to every object connected to a pipline)

the tank lib does nearly the same but it doesn't fill liquids into and extract liquids from barrels, it provides an internal tank.
if you limit the liquids to oil this lib could be used to put fuel into steamengine and this very very easyly.
LiquidInput(string mat......)
{
if (mat!="oil")
return 0;
return _inherited(...);
}

Maybe i missed something when reading libary but in java I include libaries to add additional functions to an object.
And this two libaries does nothing else than adding additional features to (selected) objects which aren't developed so far.
Maybe call it samplecode, but somewhere this functions have to be writen otherwise people won't know how to use.
Maybe i have chosen the wrong expressions/words, because i didn't use english for ages. and i have trusted my translation tool.

btw:
if i have to change this all, please tell me:
Shall i use int mat or string mat as parametre?
int does not support wildcard, but would be less complex for code readers
Parent - - By Clonkonaut [ie] Date 2011-10-12 16:08

> hungarian notation vs meaningful identifiers, what identifiers are more meaningfull than sznMaterial?


Unfortunately, this is the convention. "material" is as helpful as "szMaterial" since to determine the proper type, you look into the function call anyway (where it is either string material or int material).
Please consider not using abbreviations like "mat" if "material" would do as well.

> i did


Please don't see this as a general critique on your work, I just wanted to give a reason why Maikel made such an appeal.

> what else should i write there?


You might want to have a look at the PowerConsumer and PowerGenerator libraries. They are good examples of well documented libraries. You don't have to do this since there are still many libs badly documented but I would be helpful for all other developers.

> Shall i use int mat or string mat as parametre?


That's up to you. I myself would prefer string because it's more likely human readable and people will end up using LiquidInput(Material("Water"), ...) anyway.
Reply
Parent - - By PeterW [gb] Date 2011-10-12 16:52

> Please consider not using abbreviations like "mat" if "material" would do as well.


To be fair, that was Maikel's suggestion. And we aren't really making a few name prefixes a reason for rejecting patches, are we? Just as with the engine I'd vote that anything that isn't part of an interface to other parts of the game is probably not worth having a big discussion over. Local variable names are firmly in that category.
Parent - - By Maikel Date 2011-10-12 16:54
No, but I am still in the dark on how these libraries come into play.
Parent - - By ST-DDT [de] Date 2011-10-12 17:21 Edited 2011-10-12 17:33
i hope i don't miss the point

but the liquidtank libary could be used within the steamengine or powerplant.
Steamengine.c:
#include Libary_LiquidTank

FuelCheck(){
if (iLiquidAmount<=0)
  return false;
iLiquidAmount--;
return true;
}

and the LiquidBarrelFiller lib could be used in base/basis/castle

You avoid doublicate code, and with one eye on the beginning of the file you can see, this building does .... + ... and handles liquid like X
Parent - - By Maikel Date 2011-10-12 18:17
May the two libraries be combined into one, or is that impossible?
Parent - By ST-DDT [de] Date 2011-10-12 19:42
i could change that, but this will lead to functions like AllowBarrelExtractLiquid, AllowBarrelInsertLiquid, and the buildings without internal tanks will get a useless tank variable.
Parent - - By ST-DDT [de] Date 2011-10-12 17:32 Edited 2011-10-12 17:40

>You might want to have a look at the PowerConsumer and PowerGenerator libraries. They are good examples of well documented libraries. You don't have to do this since there are still many libs badly documented but I would be helpful for all other developers.


Maybe i'm a bad documentor, but i really don't know how to put more into documentation. (Maybe because its english)
Everything else would be.
//search barrel
var barrel=FindObject(Barrel)
//found barrel?
if (!barrel)
return false;
//get material
var new_mat=barrel->GetMaterial();
//already extracted
var extracted=0;
//search barrels
for (barrels with liquid new_mat)
//get liquid
extracted+=barrel->Extract(new_mat);

maybe i could add a sentence like "object pump: if you don't like the pump you can restrict liquid flow"
Parent - By Clonkonaut [ie] Date 2011-10-12 18:11
I didn't take a look at your code yet but Maikel probably meant a short sentence about what every function does  (in the Power* libs these are the comments beginning with /**) not commenting inside the funcs. But remeber that this is a voluntary task. We're not forcing you to do this.
Reply
Parent - By Sven2 [de] Date 2011-10-12 19:32

> Please consider not using abbreviations like "mat" if "material" would do as well.


I'd always be a bit afraid of using names like "material", because they might become type names in the future. But maybe I'm overly afraid here...
Parent - - By Clonkonaut [ie] Date 2011-10-14 13:52
By now I found time to have a look at your patch. Very well done, I don't see any problems with either understanding the purpose nor with the style. (As Peter stated there is no problem with Hungarian notation if the use is for mere internal variables)

I will see to include the patch into the repository. Unfortunatey I wasn't able to proper import the patch so your name as creator of the changeset is lost along the way. I hope you don't mind.

Thanks for contributing!
Reply
Parent - - By boni [at] Date 2011-10-14 14:03
Doesn't Author.txt still exist? :I
Parent - By Clonkonaut [ie] Date 2011-10-14 14:09
It's authors.txt nowadays but it is used to keep proper licensing for media files.
Reply
Parent - By Maikel Date 2011-10-14 14:09
I pushed it with the correct author and some minor changes (added empty Graphics.png to the Libraries).
Parent - By Ringwaul [ca] Date 2011-10-14 18:06

>Unfortunatey I wasn't able to proper import the patch so your name as creator of the changeset is lost along the way.


You can temporarily change your name in the repository settings so as to attribute a changeset to anyone. :)
Reply
Parent - - By PeterW [gb] Date 2011-11-21 16:07
By the way, how many changes do we considered so far to how pumps worked in CR? Given that there's always a lot of confusion about the topic with newbies, we might think about a few simplifications.

What just sprang to my mind: How about we remove "output" pipes? So you can only ever connect input pipes to the pump? We could simply have the pump as the place where you fill barrels - it doesn't really make much sense in arbitrary containers... It would make it a lot harder to just pump stuff into nothingness as well. And lastly, this would force you to put the pumps where you want to put the liquid - which means pumping water to the surface forces you to put the pump into a less guarded place.
Parent - - By Sven2 [de] Date 2011-11-21 16:27 Edited 2011-11-21 16:29
I think it would be sufficiently less confusing if a) you didn't need a power line and b) input/output pipes were labeled somehow. So once you connect the line, you know if the end is input or output. Right now, in CR, the confusion stems mostly from having three lines, all of which have an identically-looking end (the line kit) and just the line color differs for the power line. Funny enough, the internal line objects used for pumping and power transfer have nice pictures. But they are just there for the developers :-)

Another idea would be that you just lay down the water pipes, which should be a bit larger than the CR ones, and they always transport liquid from the higher end to the lower end. A pump can be placed anywhere on the line path to set the pump direction of the attached pipe.

Even better would be if you didn't need pipes at all. You just dig tunnels and build loam bridges for water and place a pump anywhere to build up the pressure. IT would certainly make water transportation interesting and allow for complicated settlement goals. But we don't have that amount of physics in the landscape, unfortunately.
Parent - - By PeterW [gb] Date 2011-11-21 17:43
Well, we are already about to remove the power line, which I think is already a significant step towards making it acceptable.

> Another idea would be that you just lay down the water pipes, which should be a bit larger than the CR ones, and they always transport liquid from the higher end to the lower end. A pump can be placed anywhere on the line path to set the pump direction of the attached pipe.


I'm not sure I understand the idea. Can you explain more?

> But we don't have that amount of physics in the landscape, unfortunately.


Yeah. I really need to get back to that someday. "Given a pixel in the landscape, give me the lowest connected air pixel in the landscape"... how hard could it be.
Parent - - By Sven2 [de] Date 2011-11-21 18:26

> Can you explain more?


It would work like a line kit, but you can freely place start and end anywhere in the landscape. Liquid then automatically flows from one end to the other if there is liquid at the top end and no liquid at the bottom end. Think of it like a water hose. It's the equivalent of just digging a path to let the water flow, but it would also work over hills and doesn't disrupt your mining so much.

You then walk up to any position on the pipe with a hammer and build a pump. The pump then allows the pipe to also work from the bottom end to the top end. So if there's water at the bottom end and sky at the top end, it would get transported.
Parent - By PeterW [gb] Date 2011-11-21 18:32
Having a function for lines/tubes even when they're not connected to a pump would be nice indeed. Even though I would try to go into the opposite direction - have even more explicit "tubes" in the landscape so it disrupts mining more :)
Up Topic Development / Scenario & Object Development / New LiquidPump System

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill