Cheep Particle Tricks

#21 Caylo is correct about the textures, I have them defined and it works really well for me.

#22 @Edward
What files did you change to get it working with AFX? The particle functions are so different between stock Torque and AFX, that I can't get this in my game properly!

#23 You need to simply use winmerge. The texture issues still i havent fixed yet. But simply look for the // particle tricks lines and recompile. should be pretty straight forward.

#24 This looks pretty cool. What uses does it have, obviously apart from making bouncy particle effects? Could I use it to make a flamethrower out of particles? Sparks that bounce sounds good. What about like in Halo, which had those dripping Flood gooey things? Or spawning decals where particles hit (for blood and stuff)?

#25 What do I merge the ParticleEngine.cc with? Should I just copy it over, because the ParticleEngine.cc in AFX is empty?

#26 Well Daniel, unless you can get it to transfer the client over from the porjectile code, it is not really going to work for flamethrowers because you would never give the client the score for a kill. But it is nice for fire that actually burns and poisonous gas that can kill.

#27 Im not 100% sure what 'tricks' that version of 'Cheep Particle Tricks' have in it, but im thinking it DO have a script callback for when the particle hit something (might be what you need for flamethrowers).
One small problem some may run into is the fact that for the sake of MORE particles at LESS system load, i am 'killing' any particles that go below terrain level, this cause any ungerground particles (caves and sub terrain buildings) to NOT have particles. It is quite easy to plug a toggle in for times that a sub terrain particle system is needed....

#28 Well I did manage to get it to pass the client info from a projectile throught the explosion to the particleEmitter and it gets passed in the onCollision call now.

Caylo your code almost fixes an issue for me with particles that pass through objects they shouldn't but I need to adjust the direction they travel to be more opposite or actually have a variable to adjust the collision detection distance like it is done for vehicles and rigidshapes.

#29 Ron, im not 100% in understanding this part of your comment:

Quote:Well I did manage to get it to pass the client info from a projectile throught the explosion to the particleEmitter and it gets passed in the onCollision call now.

Is it that my emitter.onCollision was not reacting proper when it is a network multiplayer situation? If this is so, your improvements could be helpful to me for fixing a bug i have not yet explored(my project is solo play, but i have done my best to retain multiplayer continuity with any of my code additions).



In offering a clue as to what may solve your remaining quandaries:
This is bit of code who deals with WHAT will rebound a particle,

if(gServerContainer.castRay(particle->pos, particle->pos + particle->vel * t, 
		   TerrainObjectType | StaticObjectType | ItemObjectType
		   |InteriorObjectType | ShapeBaseObjectType | ProjectileObjectType, &rInfo))

Add any other ObjectType you may need.



Also for changing the collision test distance modify this first bit,

if(gServerContainer.castRay([b]particle->pos, particle->pos + particle->vel * t[/b],

specifically this particle->pos + particle->vel * t part, parhapes with something like, particle->pos + (particle->vel * t)+adjust_the_collision_detection_distance.
Then if you follow how particle->dataBlock->PBounceDOpercent is plugged into the code, you should find it easy example to add your own datablock modifiable adjust_the_collision_detection_distance variable.

Is this type of what information you seek, or am i misunderstanding your query?


Now, if it is an issue of weak or/and erratic rebounding particle, simple modifications to the elasticity or friction settings should solve such. Last what one may be viewing as undesirable behaver is a reflection of the PBounceDOpercent setting, as by default only a few percent of the particles are even being considered for collision calculations per particle cycle.

#30 As for my earlier comment as to the client identity, yeah your script is wrong for determining the controlling client identity in that it is identifying the struct particle and the particle emitter. Neither of these is client-controlled, there is no real way to ascertain a client ID from that method.

However, with my method what I have done simply is used something that has always been done in a different way. You might notice in every onFire method the projectile's client is identified yet it is not in the projectiles code or listed in initPersistFields. Well I made it so it was. Then gave both the explosion and particleEmitter an S32 mControlClient and at the time the projectile's explosion is created I made

pExplosion->mControlClient = mControlClient

and in in Explosion::explode when we make our particleEmitter(I think there is one more place too) I did the same as above for the emitter and explosion.

After that it was a simple matter of just adding mControlClient to your onCollision call. It works flawlessly and you get a client ID for the guy that shot the gun.

As for PBounceDOpercent I actually changed that to be more of an On/Off switch since I would rather just have collision detection or not.

I do like your idea on the datablock entry for distance and will be trying it.

#31 I made this work with some minor code changes that really work well for me. It also kills the problem with particles passing through objects. Thanks Caylo.

With the distance modifier you suggested I also added one other datablock entry to the particle called killedByCollision.

If you would like I would be willing to collaborate to make an official resource using your code and my updates. However my version is TGEA so I will have to update both I suppose.

#32 That sounds good, Ron. Im 100% busy with work until late Thursday NEXT WEEK, but toss me an email and I will help out during breaks and off time.

#33 I would really like to get hold of this, but the links dont work no more
8o(

#34 Yes, i took it down to update, but never got back to it. Contact me at porkcow@comcast.net to receive the zip.

#35 Caylo, I need to talk to you in regards to this code. If you check my profile I have all of the Instant messengers I use and my email.

#36 Does this work with 1.5.2?
Someone said that getting it working with 1.5.x is hard.

#37 Does anyone happen to have this code available still?

Id like to possibly see about making this work w T3D.

thanks!

#38 @Paul - I have this code, but its embedded deep inside my kit for 1.2, it works really well. I can see if I can extract it out.

#39 @Sean
if you would, that would be absolutely wonderful.

thank you much!

#40 @Paul - Just an FYI, mine is slightly different then the original resource. I have moved the stuff to the emitter rather then the particle itself. In addition I have also added GUI functionality, so that you can edit the emitter in the engine itself. This means that any scripts that were based on the older format won't function properly.