Hi. When testing the particles system (since it's been awhile)
I had just 4 emitters, but in running the test, after a while
one of the sprite sheets didn't activate. This is NOT one that
I had modified script on. And another emitter defaulted to the
default sprite (smoke I think). Just wondering if there is a memory
concern or something to that effect?

The 'emitter' that I had changed parameters on kept going, just
not some others. BTW this happened after placing down a light...?!

This is gg running out of memory when using particles.

It is best to save the level and reload the map to get a reliable test for the particles.

But you need to turn them off and destroy them in Script some how.
And turn them on only when the player is facing there general direction.

Okay. Thanks Pirate Myke. Good to know.
How often do you think a person needs to reset emitters?
Every 10 seconds or 15 maybe?

For the preliminary goal, 4 emitters will be the plan...

BTW @ LEE! It would be nice to have a ParticlesSetScale for all Three(3)
dimensions of the sprite individually, and not all together!! or at least 'Y'
because 'Z' probably wouldn't amount to any use. But there could be
some really useful effects with at least 'X' and 'Y' separated.
If I'm missing something with the scale- let me know.

That means keeping track of them might be essential!
Update; at least got a basic turning on emitters, and deleting all emitters.
There seems to be no "list" of emitter id's, you just have to check if those
which are active or not active.
But this is GGJr- let's hope the new one is easier to work with.

You create the emitters yourself so just keep your own list !

You can create and delete but you can also change the number of particles spawned (both per frame and total), the life of the particles, scale. alpha value, rotation rate, animation rate, animation range, speed, position and angle all on the fly.

Currently you can have 25 different particle sheets loaded and 100 emitters active at the same time.

Oh and you can change the shader used by an emitter.

When you add to that the fact that each particle sheet can have up to 4096 frames and you can spawn particles manually if you so wish, like I did for the bullet holes script I showed off, then it is already an extremely powerful and flexible system.

Hi AmenMoses " then it is already an extremely powerful and flexible system."

Yeah, it's pretty decent- it's not atrocious!
A couple things as I mentioned would make the current particles system
shine and more 3-D (there is no horizontally flat options for the sprites,
or 'Y' scale options that would permit faking that.)

[[ Did I see someone in GG do a rising smoke-ring particle ]] or another place?!

Also as we are speaking of, there's still the trick and challenge of figuring out
where the emitters you are currently activating will be assigned. Or to say it better,
there's not enough information to easily go straight to an emitter and change those
attributes clearly. With only GetFreeEmitter, and not ModifyEmitter(ID), or something
to that effect. Anyhow, maybe I just need to understand it more clearly, but my
work on the game is at a halt because I either require this control or no particles
at all...

So where I'm at right now, I can either spawn a group of emitters (on the same entity/
script), and also delete all spawned emitters-- but to keep track of what's going on with
what (for other entities), is what's pickling my brain!

ParticlesGetFreeEmitter() returns an emitter Id, that Id is then used in all the other commands to control aspects of the emitter at runtime.

If you don't care about GG's default emitters (i.e. if you aren't using weapons that make use of them like the wizards staff or RPG) then simply assign your own ids.

i.e. start at 10 and simply call ParticlesAddEmitterEx( ... ) with it then increment it, so for example assign your first emitter 10 the second one 11 etc.
Then you will always know which id goes with which effect.

Aha-- ? you don't have to only use the current available emitter ID
that is returned by ParticlesGetFreeEmitter() -- ?

Okay. Then that will make it much more easy to figure out- I thought
that was kinda an automatic requirement. Will test!

Don't understand your "more 3-D" comment btw, what is "less 3-D" about the effect in the video?

I'm not sure if "more 3D" is the best remark, but more flexible scale uses
would be. Or being able to flip the sprite flat horizontally.

Go back to smoke rings rising up into the sky- something which is flat like
a plate or a hoola hoop laying horizontally, and rising up, NOT facing
directly toward the player but laying flat. Where as currently by default
scale is possible only in full + or -

So I don't see how we could make a horizontal hoola- hoop rise straight up
(or down) with particles... and this is just an example suggestion. SCI- FI
looking circular exhaust rings thrusting downward is the goal actually.

I could move an actual entity via script- but would be nice with particles.

You would need to create a ring of particles for this sort of thing, problem is for performance reasons particles are spawned within a box relative to the emitter position (either the entity origin or the current player position) and the box is orientated relative to the world coordinates.

So you would have to script it such that each frame you change the spawn position to be a segment of the circles circumference, as you can only do this at the frame rate it probably have too many gaps to be very effective. At 60 FPS with 6 degree segments you would only spawn from each segment of the circle once a second, not a problem for say circular smoke or fog but not very effective for a "SCI- FI
looking circular exhaust rings thrusting downward" sort of thing.

I'm waiting to see what Lee has done in MAX particles wise, i.e. will we have the old system for backward compatibility and a new one to take advantage of whatever Wicked gives us or has he replaced the existing system with a new rendering system but the same functionality?

Things I've wanted to add to the existing system, but can't as we've lost access to the code while MAX is developed, are:

1) Particles spawned relative to Terrain/Water. (I had implemented this and was testing it)
2) Particles spawned using a provided function or had some pre-canned ones which are selectable.
3) Particles spawned relative to entity/player rotation rather than world based.
4) Particles on-death action, i.e. at the point one particle dies have the ability to specify some precanned actions from that point, maybe spawn two new particles at that point or spawn a new one with new random values. (I actually started to implement this but didn't finish it).
5) Allow spawned particles to be positioned and rotated automatically with the entity they are attached to, performance might be an issue though and I couldn't figure out a way of taking animation into account (mainly as that appears to be done using shader tricks).

Point I've always made though is that no-one uses even a fraction of the existing system so why bother adding even more functionality that no-one will make use of? It's like the physics stuff, I'm the only one who uses it so basically everything I've added is for my own benefit and I'm not even making a game!

That would make for a decent rocket exhaust.

Pretty cool vid effect. Makes me think you could make a Firefighter game
shooting the burning building with the firetruck-- your bucket could be the
fill-up spout!
(Then when the Zombies come out of the building- hose them down!) LOL

You are right- no one as far as I see in the WIP's has used particles much
at all. And yeah- we will have to see what the MAX entails.

If you have some thing started like you mention- that would be nice to see
them completed. I don't see why at this point that GGjr is closed out as MAX
has gained the 64 bit and Wicked link- and should be in it's own segment.
I can't get or run MAX at this point (computer constraints) but it's fun to
watch it progress.

You know when they have rocket launches and the main engines are burning Hydrogen with Oxygen for thrust, have a guess what the 'exhaust' mainly consists of.

Water vapour and unburnt hydrogen.

Same @ Catalytic Converter + nitrogen.

So it looks like --ParticlesSetLife( ) is broken.
Every time I use it, it kills the emitter.
ParticlesSetLife( 1, emittpower[e]*25, emittpower[e]*40, 100, 0, 50 ) -- BROKEN!

But I did get ParticlesSetScale( ) to work.
ParticlesSetScale( 1, emittpower[e]/6, emittpower[e]/4, emittpower[e]/2, emittpower[e] )


--ParticlesSetLife( emitterId, lifeMin, lifeMax, maxParticles, 0, maxPerFrame )
-- maxParticles default is 100, maxPerFrame default is 50

I need best way to dynamically lower and increase the particle output....

It is actually ParticlesSetLife( emitterId, frequency, lifeMin, lifeMax, maxParticles, 0, maxPerFrame ).

Oh and the reason it killed the emitter is because you were setting maxparticles to 0. That's a handy way of turning emitters on and off so keep a note of it.

https://forum.game-guru.com/thread/220055#msg2622747

Btw, a better guide to using these commands would be to look at the particles tester script.

Hey nice! That's a huge help! Great script.

Here's one thing that would be very handy to have in GG particles;
We already have ParticlesSetSpeed( )-- which are constant values until the end,
but if you could add to that-- or add to a separate control and that would be
to have speed diminish to the end until it was zero or near zero.
ParticlesSetExhaust( 0, 10, 0) -- X,Y,Z <ending speed> (percentage of starting speed)

I think this would allow a great realistic effect for engine exhaust particles;
exhaust would come out at speed, and then as in reality, if you set the end low,
the particles would just eventually hover in the air and dissipate...

With your controller, I tried to make a type of this work with a negative 'Y' factor
combined with a negative gravity factor-- just didn't seem to take.

That would have to be a start_speed/end_speed sort of thing, which would basically add another 6 parameters but could be doable.

Probably the neatest way would be to have a separate ParticlesSetEndSpeed command, that way the default would be as now but if you did call it under the covers it could trigger the tailing off of the speed over time.

I envisaged handling this with the on-death action parameter I mentioned earlier, i.e. on-death action 3 for example would be speed fade such that instead of actually dying the particles life is reset to the current value and the speed values would gradually reduce to zero for that particle.

Several way of doing it really, I would have to experiment to see which would be more suitable performance wise, but I'm not going to bother doing that until I find out what Lee has in mind for Max.

Okay- for these set of particles, it's working, then I modified a sprite sheet,
so that I could have a custom one.
But the default sprite sheet- 64smoke2.dds seems to always load no matter
what I change this;
local imageFile = imageFile or ParticlesLoadImage( "effectbank\\particles\\64smoke2.dds" )
to.

So... wondering what gives? What can I do now? Also tried;
local imageFile = ParticlesLoadImage( "effectbank\\particles\\flame.dds" )
Also put ParticlesLoadImage( "effectbank\\particles\\flame.dds" ) running every frame-
still getting default smoke...!? Hmmmm..,

Show the whole script, snippets don't help as the problem probably isn't in the snippet but where you use imageFile (or more likely don't use it).

Alright, thanks for the tip. I rearranged how the sheet is loaded, (sometimes
thinking is imperative!) -- from after setscale, speed and alpha to before that.
BUT whether that is totally important I don't know== it seems that you
must always close down and reload GG for a new sheet to load up and
test-- which is a time consuming step. Any way to get away from that?

So- I was testing all different stock sheets thinking my sheet was bad,
**none of them loaded** - until...
but after a RESTART of GG, it loaded.

Give it a number, i.e. ParticlesLoadImage( "effectbank\\particles\\stonebh2.dds" , 10 )

That way it will always be in loaded in the same 'slot'.

The way you were doing it every time you run test game it will eat up another free slot and you only have 25 available.

In fact your _main script is repeatedly loading the flame one!

And why are you overwriting emitterId 1? By default that is used by GG so will already have been set up with an image etc, start your emitterIds at 10 or something to give breathing space between GG base ones and any that custom weapons may create.

Okay, thanks for the help. I was just following the examples that have been given.
Seems I must have missed some documentation.

"In fact your _main script is repeatedly loading the flame one!"
These where all the testing changes I made to see if I could get anything to work...

?? > So don't run --
ParticlesSetScale( )
ParticlesSetAlpha( )
ParticlesLoadImage( "effectbank\\particles\\--" )
and other changes
?

every frame- that was a question I had - been meaning to ask. Thanks.

No you can run any of the particle commands to update the parameters every frame if you so wish, not much point unless they are actually changing values though.

Loading the image sheet though should only ever happen once, same with any other static file you load in a game!

Creation of emitters should only happen when you need them and when you are finished with them you should delete them.

All pretty standard and common sense I would have thought.

Awesome. Let me get on to the tests!

AmenMoses; Well, I'm back after those changes... not good news.
I made some changes you suggested, but the new sprite sheet still did not load,
until a restart of GG. Why this happens, I'm not sure?

I'm concerned how it's difficult to know what will break the loading of your
custom particle sprite- sometimes it will work a few times (you can test, modify,
retest), but sometimes after just one change, it resets right back to smoke!

If I had to test particles 10 times, it would take an hour just to do that (5 minutes
from restart GG and load map again.) That would take forever to get what you
wanted.

This is getting frustrating, maybe particles are a little too finicky and delicate to
incorporate for GGjr? I'm also worried also what will happen in a Standalone?!

......In the end I was able to get a little more working time with particle tweaks
before the custom sheet disappears by using a Delete before a Start;
I put ParticlesDeleteEmitter(10) -- before
ParticlesAddEmitterEx( 10, 1, 1,
and that worked for a while on an empty map.
On my main map, I got 3 or 4 tries before it reverted back to default smoke.

Seems memory is retained on some functionality for map tests-- memory that
as far as I believe should be completely freed up each time. This was essentially
verified when I had wind effect turned on, but then commented out the wind
line (--) and the wind was still in effect! Then I turned wind zero; wind (0,0),
where it did shut off the wind.

>>Cant' GG just reset all memory parameters each time when "Test Level" is ran?

It does on a standalone, i.e. between levels allegedly, but not when testing from the editor.