Piston
-
Here is an idea which improves creators ability to micromanage simulations.
PIST, Piston. When recieves a spark it turns the empty space next to it (Up, Down, Left, Right) into METL. After not recieving a spark for a length of time (Use life value) the piston will retract, removing the spawned metal.
NPST, Same as piston but inverted. Extends when not recieving a spark.
(By filling the space next to the piston I am talking about a 1 pixel space not a flood fill)
-
lol, but this is a good idea.
-
Just sounds like a cheap compromise for movable solids to me...
-
Yes, but this could have some interesting uses, like a plug for pipe that is destructable, and maybe somemore that i can't think of
-
Doesn't PPIP already do that? It stops flowing if it's deactivated by NSCN, and reverses direction if sparked with INST?
-
That might mess up the pipe though, like if you had multiple paths steming from the main PPIP and you wanted to cap only 1 path then your SOL because you'd have to shut it all down or do it manually, and that is not how most things work, so this has at least 1 use
-
You can create pipes without the pipe element, which can be sealed and reopened at will. They can also be breakable.
Injection of fluids can be done under pressure, if the advanced fluid thingy is turned on. Therefore liquids can move a lot faster than pipe will allow.
This element will be implemented in a smaller way than an equivelant method in the current TPT.
A pipe does not have to be 1px in width, although PIPE can be used with greater widths, fluid dynamics are removed from the simulation while they are in the pipe.
PIPE still has a use, for transporting solids horizontally or positive on the Y axis.
The-Fall:
You could make this with some Pcln, powered void, and some DLAY. So, in other words, No.
Not within the same space as this element can do it in. And your method cannot keep 100% of the material. So in other words, Yes.
therocketeer:
Just sounds like a cheap compromise for movable solids to me...Erm. No. Just no.
Uberness:
Suggested by me originally on IRC
Along with FRME and FRMM (Frame and Frame Motor)
Never implimented.
Probably never will.
I'm never on IRC, so seeing as I made the post its my idea now :P. I do agree that frames and framemotors are bad things as massive pixel manipulation in TPT doesn't play well on our poor overclocked processors.
