Movable Solids now simple
-
I can't try this. Someone else has to. Someone who can compile AND RUN their own TPT.
I can compile (but can't run) my own TPT. I don't think anyone's tried this yet... it would be a shame if nobody tried this because this is the first I've seen that anyone has actually posted code that has a reasonable chance of making movable solids in a format (mostly) compatible with current TPT. I'm trying to figure out how to upload the data for the void*, I think that there will need to be some sort of function that takes the particle type and void* and packets this information because you cannot send a void* over the network. Hmmmmmmmmmmmmmmmmmmmmmmmmmmm.
Does anyone know how VOID deletes particles? Like do particles detect that they move into VOID
or does VOID detect that particles move into it? In any case, maybe entering VOID could trigger a release of whatever is in the void* data and setting that pointer to null and then when it's checking if the particle it's connected to (which in turn is connected to the first one so it's void* is NOT NULL) has a null pointer there then it knows that that particle got pwned! YES! WIN!
now to just get that set up...
and also to networkify it -
@meep2000 (View Post)
It must be frustrating for you not being able to run it.
I hope someone tries this... I would try it, but I don't have the software, and can't be bothered getting it. -
@The-Con (View Post)
I. K. Fareaking. R. I have all these ideas about stuff that would make TPT better (w/o slowing it down too much) but none of them can be done... and I'm thinking that actually there shouldn't be
a sqrt() call in the calculation. I should prolly check this. -
while this is a good start, it is missing a lot to be a real 'moving solid'
linking particles is good and all, but you are only linking the surrounding particles, it doesn't take into account the entire size of the object. Another thing, the particles around a particle will always have the same distance from each other, causing no movement at all. This may keep particles together, but does not take into account center of mass, gravity, momentum, or any velocity transfer. -
@cracker64 (View Post)
It doesn't need to take into account the entire object. It takes into account that particle
which takes that particle which takes that particle which takes that particle (so on and so forth).cracker64:
Another thing, the particles around a particle will always have the same distance from each other, causing no movement at all.
uh, yeah. if the particles are the same distance from eachother then there should be no movement between any of them. Center of mass is taken care of by the recursive property.
I don't get why you say that gravity is not incorporated. In the current implementation if gravity would normally act on the particle, then gravity will act on the solid. I used += for the velocities.
Same thing for momentum.
as for velocity transfer, does that normally happen in TPT? One particle of dust smacking into another results in the moving one stopping, in my experience.
This method would be good for 'squishy' solids like rubber, and not very real for say metal.
Do the particles have a 'weight' value or something?
then you could multiply the effect by
otherweight/(myweight+otherweight)
when you're calculating velocity change, so that way you could connect different particle types. -
You can't assume the code does things automatically.
There is no velocity transfer, things do stop if something is in the way, but nothing is transferred.
Center of mass is needed to distribute the velocity at the correct angle.
Gravity isnt much of an issue, not sure why I mentioned it. -
What is it that you are saying that I'm thinking the code is already doing but it's not?
Is it the center of mass that you're talking about?
I don't quite understand what you are saying... could you be a bit less short on words?
How does the center of mass distribute the velocity?
:s
you are quite likely correct, I just don't understand what you mean by distributing the velocity.
a block of metal (we're IRL because I didn't say METL) is made of a huuuuuuuuuuuuuuuge
number of atoms that are all connected to *drumroll* adjacent atoms.
They do not directly affect atoms far away. They affect the atoms in between.
and this is what the code does. If it works IRL, it should work TPT.
and I'd like someone to please try this... cracker64, since you're the most experienced here
(as far as I know), could you compile AND RUN it because I can't?
no copy and paste directly, you'll have to make some modifications,
but I did write it as best as I could in this web browser... and it messed up some of my formatting.
you have to fix the for loops because some of the parenthesis got messed up.
and you'll need to replace new with malloc() because I normally use C or Java.
There are prolly a few other things, and the issues I mentioned, yet the code is there
waiting for someone to compile AND RUN it. (yes I am very long worded) -
