Pressurized liquid/gas.
-
Its been a while since I last sugested anything... When I go back to look at my old sugestions I can hardly help wondering if it was really me who posted such badly spelt and terribly explaind posts.
Hopefully I have improved a bit since then. Anyway, onto my sugestion.
While thinking to myself about pipes and pumping liquid arround I came up with an idea for a posible method of having presurized substances allowing higer flow rate in pipes and multiple other possible new mechanics.
With my idea it should be possible to have presureised pipes with a high rate of flow, presurised tanks which store a large amount of gas, a method of having pipes that dont use the PIPE element that can transport water uphill without needing large ammounts of air blasting through and many more.
This is mainly a mechanic and not an element sugestion although an element or two might need to be added in order to use the system. (valves and other usefull things which I have added below)
This mechanic is based apon the possibility of having stacked particles on top of each other (an existing example would be particles in E-hole).
This system would modify the behavour of stacked particles.
A presurised liquid or gas would basicly be multiple particles of the gas or liquid stacked on each other.
The way this will work is stacked particles will be able to move in the same way as gases into any space around them and into any space with the same amount of stacked particles or a space with less.
Example uses:
Pumping water up without PIPE element or air presure in TTAN pipes.
High presure gas tanks with large capacity.
Faster flow of liquid/gas in pipeing systems.
I'm sure you all will be able to come up with many uses for this.
In order for this to work, there will need to be ways to create stacked gas/liquid particles without using the console.
One way would be a secial type of PIPE that will output particles even if there are already particles there thus stacking them up. There are probably many ways that this could be done, one example is particles with enought velocity will be able to move onto existing particles of the same type. Another example would be high presure pusing particles could push them onto other particles of the same type thus stacking them higher. Then you could use air presure to compress gas into a tank or pipe system.
As well as ways of creating this high presure system it would be helpfull to have other methods of interacting with the presure system.
Extra elements that could be used with this idea:
Pump Pipe
Name: PMPE
Short description: PIPE that can stack particles on top of each other at its outlet.
Description: acts like PIPE, but can release particles on top of existing ones providing they are a liquid/gas.
tmp/tmp2 could be used to set the maximun stack size.
Uses: Creating presurised liquid/gas. (about the only use, but an important one for the presure system)
Note:
Could be added as a mode to PIPE instead of adding a new element.
Valve
Name: VALV
Short description: Valve. lets off high presure.
Description: Lets particles flow through it if they come of a stack with a size greater than its life value.
tmp = 0. Normal mode
tmp = 1. Generator mode. Creates spark for each particle let through
Uses:
- Letting high presure liquid/gas out
- Slowly releasing liquid/gas from a high presure system
- Detecting presure(stack size) of liquid/gas
- Generating power for a power plant that creates energy when high presure steam goes through.
- I'm sure there would be many more
Sorry for the spelling mistakes I know are in there. It seems that it won't auto detect spelling mistakes in this text box so I ran ith through a spell checker I found online. It ruined all my paragraphes/spacing, removed all bold and deleated the numbered list so I gave up on it. :(
I hope you understood my sugestion, feel free to give your opinion or ideas for improvement or ask any questions.
-
I love this. seriously. but they kinda "fixed" compression. I wish they didn't, but you could try convincing them to retract those changes. but for those people concerned about lag, you could set a limit to the number of "stacked" particles. seriously, i love this idea. I hope it gets implemented!
-
With the current way interactions work in tpt, stacking could only work if it was all particles of the same type. But i'm actually lying, there would still be some problems since things like explosives might not explode completely and generally things under other particles wouldn't react. That is why we removed stacking in the first place, particles don't react correctly since pmap[][] only contains the top particle in each position.
jacksonmj did a rewrite of pmap to fix this, although it's not completely finished, and it also isn't for tpt++, so it can't be put in. Without that, stacking isn't possible and I don't want to add the bug as a feature until it can be handled properly.
If we did make stacking work properly though, those two elements look like great suggestions, although it's hard to imagine tpt getting to that point where we rewrote enough to allow it. -
Yeah, wouldn't work with the current pmap. There's not even a fast enough way of counting how many particles are in a particular spot at the moment. The only way you could do it would be to combine multiple particles into one, like DEUT does, and then expand that when there's space (and only allow one element in each spot). That sounds a bit complicated to me though - pretty much all reactions involving liquids would need to be changed. And if there are layered liquids, such as compressed water under a layer of oil, the water would never expand.
Also, another issue: if there is some liquid which contains stacked particles, in a box with empty space above the liquid, ideally those stacked liquid particles should immediately move into the empty space (or cause other particles in the liquid to move into the empty space). However, with the idea in this thread, you would have to wait for those stacked particles to move by diffusion to the edge of the liquid before this would happen. The alternative would be to search, by a flood fill method, for the edge of the liquid for each stacked particle and try to move there. However, I suspect that would be very slow (probably similar speed to water equalisation).
That's one of the other reasons why stacking was removed - there isn't an easy way of making the particles move in the way that they might reasonably be expected to move.
-
Thanks for the explinations about the technical side of this :)
I wish that could be added as an option, possibly a varible changeable in the options. And to prevent lag caused by trolls stacking things prehaps a warning if opening saves that have the max stack varible above a certian limit.
That would be one issue with this, I'm not sure the best way of preventing this. Prehaps limiting this to the same particle type as jacob1 said.
Thanks for the explination about pmap it helped me understand the technical problems that this idea could have. I did some experimenting with stacked particles and came up with some interesting results... there were a few noticible bugs but some things worked as expected. I never knew about the pmap rewrite that was being made. Is it worth rebuilding for the c++ version and improving for an actual release? it soudns like it oculd open up new posibilitys for game mechanics.
Thanks for the feedback on the elements even if my idea is currently tricky to implement with current game coding..
so counting particles in the same place is slow? That would probably be a limiting factor for this implementaion of presure
Ideally stacked particles would be able to jump to the edge of the liquid, but as you said that might be a bit slow and laggy. That is why I sugested they only do it when they difuse to the edge. This would be less realistic than instantly doing it but is probably better than no way at all.
Thanks for all the feedback! Its a shame that it is currently imposible with the current pmap implemention.
Maby it will be rewriten sometime and then this idea could be considered?
-
With the current pmap implementation, yes it is slow, because no record is kept of how many particles are in each location. A count of how many particles are in each location could be added, but I seem to remember there are quite a few places in the code where pmap is modified, so it'd be a fair amount of work to change all those places to update the count, but should be possible. Though if a count is added, there's still the problem of iterating through the particles in a particular location, and deciding what to set the pmap entry to after a particle moves (since the IDs of the other particles in that location are unknown).
The stacking->BHOL check counts how many particles are in each location once per frame, but this count isn't updated when particles move, and doesn't include all particles.
My pmap rewrite fixes these problems - it records how many particles are in each location, and iterating through the particles in a particular location is easy. The pmap rewrite is not something I plan to add to TPT++ though, I'm quite happy working on my own little fork. Even with the pmap rewrite, there's still the issue of getting particles to move to the edge. I have a little idea about how to do pressure in liquids (which would go some way towards meeting this request, and also improve water equalisation), but I have no idea whether it will work, and I won't attempt it for a while yet.
-
Would my variable pmap system help? It can actively change the detection range of particles. This would shrink as the pressure goes up, and expand on low pressure.
