Would this work? moveable solids idea
-
CLST actually has no code that dictates its exact movement. Its code is basically like this:
If room temperature, and touching CLST particle, set speed x/y to speed x/y * 0.1
If hot, and touching CLST particle, set speed x/y to speed x/y * 0.5
If cold, and touching CLST particle, set speed x/y to speed x/y * 0.01
If very cold, and touching CLST particle, set speed x/y to speed x/y * 0.001
In a nutshell, the colder CLST is, the more it slows down in mid-air when it touches other CLST particles. As a side effect, clumps of two or three particles will wiggle around due to oddness in speed calculations in the almost-stopped particles. -
@craZchick (View Post)
It may, but when you're familiar with various programming concepts, it all starts to make sense.
@Catelite (View Post)
If it's in the SC_POWDER category, wouldn't it get the powder property by default? -
If each particle had an ID then there could be an array of IDs and a piece of code that after each frame checks all the particles in the ID list and calculates the speed and check if all the particles could move(if they had a space to move to) and then move all the particles by the same amount.This would be a way to have movable but non rotate able solids (If TPT works like I think)
but this would possibly be very complex to code.
as far as I know rotate-able movable solids wont get added to tpt as for realistic solid physics you would need very complex code. also TPT works having a grid of particles like @boxmein (View Post) said but physics engines work using positions of shapes (example(rectangle) ):
TPT:
000000
011100
011100
011100
000000
physics engine:
(type:rectangle,xpos:1,ypos:1,width:3,height:3)
converting from one to another would probably be very complex as the two has completely different ways of representing shapes(for example with physics engines the position is usually decimal not integer)
If movable solids were to be added they would have to be non accurate physics(Probably no bouncing and no rotation) and would only be a collection of particles moving up/down a bit like spng but with some extra code somewhere that stops connected ones when one stops.
Particles probably(I say probably because I don't know how the particles system works) wont be able to have a list in them as each one has only a small set of data type,life,temp,tmp,ctype,x,y,xvelocity,yvelocity,color and maby a few others and for each particle it would read the data ,make changes(like changing the position based on the speed)then write it back and move to the next.
It wouldn't be able to tell what particles may be connected to it for clumping shapes together for movable solids as it would only know what data was available which I think is at a fixed size so you cant just have a vairible length list added to it.
sorry if I make no sense or I have made a mistake(If I had then please correct me)
I was basing what I said from my small experience with java and as far as I know there is a is difference between java and C
also sorry for any spelling/grammer mistake As I don't have anytime to proof read it at the moment -
-
-
@asdf123 (View Post)
Other games don't use particles, they use "props" like Garry's Mod. Props are like larger boxes / other arbitrary shapes to build stuff out of. They also don't usually have particle simulation, because the two different concepts have to be linked together somehow, and that is really speed consuming. -
@asdf123 (View Post)
By the way I did some checking, turns out this is probably the most oversuggested idea in the history of tPT. The first person to do so was probably andrbarlow in https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=4&PageNum=1
That's 13711 topics back. I think it's best to let the matter rest now...
