A_SpawParticles (X,Y,Z,XYZSpeeds,Color)

[Blzut3]

That's a "lets discuss this a little bit first." I don't really have a problem with the proposed function outside of your concern that calling it 30 times or whatever to create a splash effect might defeat the purpose a little (at least on the DECORATE side, on the ACS side it doesn't seem as crazy), so would like to have a little discussion on a splash function at least.

[Gez]

It'd be better if the function spawned a number of particles at once, yes.
A_SpawnParticles(color, number, other parameters)

If you'll let me bikeshed the order for the parameters, I think the most important one should be first, and the most likely to be kept at useful defaults be last. The xyz spawning offsets, for example, could very well stay 0 in most cases, so they can be shuffled at the end of the function call; whereas the particle color (or type, if you go to the length of creating a derivable particle class) ought to be the first parameter.

[Xaser]

A "number" field indeed ought to cover the general use case of 'splosions since all you need to do is frandom the direction they travel and it's good to go. Anything else beyond that is likely to fall into the "special case" category.

I'm surprisingly pumped about this being a thing for some reason.

[Major Cooke]

I know one reason I'd like this function, because it supports zdoom's limitation of particles.

[edward850]

It'd be better if the function spawned a number of particles at once, yes.
A_SpawnParticles(color, number, other parameters)

A "number" field indeed ought to cover the general use case of 'splosions since all you need to do is frandom the direction they travel and it's good to go.

There in lies the problem. Can such a thing be done without adding ~12 additional parameters in both decorate and ACS? Remember you can't just add a count, everything else needs to be ranged.

Edit: Actually I might have a simple solution to this. Watch this space.

[Ravick]

Just a quickly opinion about the amount of arguments, I rly don't think it is bad if they are many. More 'moddable' arguments means more flexibility, more 'modding power' for the modders to work with. In this case, I rly believe that "the more, the best".

[edward850]

Not if you have to multiply the present arguments by two. Keep in mind that whatever is available has to be translated into code. We equally don't want too much internally either.

Edit: I haven't forgotten about this, by the way, just that this request came unfortunately close to the Christmas holidays.

[Eevee]

This is an argument for named arguments in DECORATE/ACS if I've ever seen one.

Perhaps a good test of the interface would be to port the particle fountains to DECORATE?

This is amazing though, I love particles and have always been a bit sad that they're only available in hardcoded form

[Hellser]

So uh. It's been close to a month. Any update, Edward? Spawning Particles would be so nifty, and great for many - many effects!

[Graf Zahl]

That's what happens if nobody wants to make a decision.

For the record, I have no fundamental issues with thr function as it is . It may be a bit unwieldy but I haven't come up with a better solution yet.

[Xaser]

At present, one can do loops with uservars or repeat the state with a zero-delay (for random explosions), so yep, it's already better than nothing.

[edward850]

Still haven't forgotten about it, but I still need a proper idea for grouped spawning if we still want that (the one I had before didn't really solve anything). Otherwise the current method is still solid if nobody has any immediate problems with it.

[Blzut3]

What was the idea you had before? You just kind of left it at "hang on, I got this."

[edward850]

It kind of melted over the Christmas holidays when I was stuck with my laptop. I was going to try and set everything up with variance variables but it quickly become too bloated as well (which seems to be the problem with most ideas), especially if you only wanted to spawn 1 particle at a time.
The way I see it at the moment, it shouldn't matter as is. As long as it's named A_SpawnParticle (which it is), if a good idea comes in the future, you still have room for a plural A_SpawnParticles.

[Major Cooke]

There is one more thing. Perhaps a flag for velocity setting similar to CVF_RELATIVE from A_ChangeVelocity? You could convert the bool in there to flags.