[m!m]

Theoretically yes, but the problem is that you will hit the SEXP length limit when making the necessary function call. But I've been playing with this idea for some time and I'll put some work in it when someone needs is

[Deadly in a Shadow]

Will there be SSE1 builds?

[Nighteyes]

so, whats keeping this from going into trunk? I'd really like to use this in Diaspora... this script can create some nice looking fireworks

[Fury]

Well, there is one outstanding issue with particles when game is paused (via pause or esc keys).
http://scp.indiegames.us/mantis/view.php?id=2446

For example, if you pause while a capship is exploding and you use this script, then wait a while and resume the game will take significant time before it gets from apprent freeze to jerky fps and finally to smooth fps as it tries to catch up the time that was spent while game was paused.

This is apparent with Wanderer's flashy explosion script as well. If you pause a game for a moment, you will see that upon resuming FSO attempts to create significant number of particles the next frame(s) to catch up. As far as I can tell, the issue happens with tabled particles as well.

Now, this is the first script that effectively can freeze a PC for very long time if you pause at the wrong moment. During testing this script I've had to kill FSO process many times because I couldn't be arsed to wait until it finally resumes for real.

I'd go as far as to say that this script is unusable beyond testing due to the problem with pause and particles.

[m!m]

so, whats keeping this from going into trunk?

Most likely just the not existing free time of a coder...

I'd really like to use this in Diaspora... this script can create some nice looking fireworks

<snip>

Well, there is one outstanding issue with particles when game is paused (via pause or esc keys).
http://scp.indiegames.us/mantis/view.php?id=2446

For example, if you pause while a capship is exploding and you use this script, then wait a while and resume the game will take significant time before it gets from apprent freeze to jerky fps and finally to smooth fps as it tries to catch up the time that was spent while game was paused.

This is apparent with Wanderer's flashy explosion script as well. If you pause a game for a moment, you will see that upon resuming FSO attempts to create significant number of particles the next frame(s) to catch up. As far as I can tell, the issue happens with tabled particles as well.

Now, this is the first script that effectively can freeze a PC for very long time if you pause at the wrong moment. During testing this script I've had to kill FSO process many times because I couldn't be arsed to wait until it finally resumes for real.

I'd go as far as to say that this script is unusable beyond testing due to the problem with pause and particles.

I'm sorry to hear that (although I wasn't able to reproduce this myself) and I don't know any way to work around this bug

Also: First post updated with new Build for SSE2 and SSE1

[Deadly in a Shadow]

Lol, when the Orion (in the testing mission) is going to explode, it crashes. I thought due to my computer:D

[m!m]

Could you play with a debug build and post the log here? Maybe it's not your computer

[Fury]

I further tested the pause problem and I have to correct myself. This doesn't occur with pause, only with esc menu.

You see, if you press pause, you get Got event GS_EVENT_PAUSE_GAME (6) in state GS_STATE_GAME_PLAY (2)
If you press it again, you get Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_GAME_PAUSED (3)

But if you press esc instead, game state does not change. I suspect this means all scripts are left in running state and when you resume the game, everything that your scripts have been working while esc menu was on, is getting thrown in at once. No idea at this time if this is limited to scripts or whether it does affect tabled particle generation too.

[Commander Zane]

*BOOM*

[m!m]

I further tested the pause problem and I have to correct myself. This doesn't occur with pause, only with esc menu.

You see, if you press pause, you get Got event GS_EVENT_PAUSE_GAME (6) in state GS_STATE_GAME_PLAY (2)
If you press it again, you get Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_GAME_PAUSED (3)

But if you press esc instead, game state does not change. I suspect this means all scripts are left in running state and when you resume the game, everything that your scripts have been working while esc menu was on, is getting thrown in at once. No idea at this time if this is limited to scripts or whether it does affect tabled particle generation too.

Confirmed, just ran a test and I can confirm that script execution does not stop when the ESC menu is opened. This way the script will continue to generate particles which leads to the mentioned slowdown.

[Deadly in a Shadow]

Could you play with a debug build and post the log here? Maybe it's not your computer

Here we go.

[attachment deleted by ninja]

[m!m]

Could you play with a debug build and post the log here? Maybe it's not your computer

Here we go.

Doesn't seem to be an error of the script, I'm sorry.

[Deadly in a Shadow]

Could you play with a debug build and post the log here? Maybe it's not your computer

Here we go.

Doesn't seem to be an error of the script, I'm sorry.

Ah, good to know. In this case, I hope there will be some improvements.(Especially in performance.)
BTW: I didn't used the revision 7217 because it crashes on startup. I used the Revision 7151.

[Fury]

m!m, are you familiar with Wanderer's flashy explosions script and how it uses rays for collision detection and to spawn explosion effects on hull where rays have successfully collided? Could this be used to generate these particles effects as well?

http://www.hard-light.net/wiki/index.php/Script_-_Flashy_Deaths_(new)

[Fury]

Ah, good to know. In this case, I hope there will be some improvements.(Especially in performance.)
BTW: I didn't used the revision 7217 because it crashes on startup. I used the Revision 7151.

Errr, you seem to have missed the point in the very first post in this topic that this feature is not supported by trunk builds and requires the build m!m provided in the same post. Unless you have had someone to compile builds for you.

[Nighteyes]

I further tested the pause problem and I have to correct myself. This doesn't occur with pause, only with esc menu.

You see, if you press pause, you get Got event GS_EVENT_PAUSE_GAME (6) in state GS_STATE_GAME_PLAY (2)
If you press it again, you get Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_GAME_PAUSED (3)

But if you press esc instead, game state does not change. I suspect this means all scripts are left in running state and when you resume the game, everything that your scripts have been working while esc menu was on, is getting thrown in at once. No idea at this time if this is limited to scripts or whether it does affect tabled particle generation too.

Confirmed, just ran a test and I can confirm that script execution does not stop when the ESC menu is opened. This way the script will continue to generate particles which leads to the mentioned slowdown.

so does this mean there is a problem with FSO not pausing correctly when pressing ESC? if so then its not the script fault, and we should look into a way of using the pause way of pausing() instead of the ESC way...
as this affects all other scripts this problem is quite big, as with time weapons, thrusters and explosions are going to be using more and more particles, its just natural...

Fury: with the ray collision method, do you want the particles to emmit from the shape of the hull? if so then it would replace the BOX emmiter nicely, but I would still like the option to have them emmit from the center of the ship

[m!m]

m!m, are you familiar with Wanderer's flashy explosions script and how it uses rays for collision detection and to spawn explosion effects on hull where rays have successfully collided? Could this be used to generate these particles effects as well?

http://www.hard-light.net/wiki/index.php/Script_-_Flashy_Deaths_(new)

That would be an option but how should it work? I would propose that the rays are sent from the center of the effect (can be moved) to the borders of the specified box (with +Box Min,...) or just in all direction when "+Box Min" is not set. Would that suit your needs?

BTW: I posted a patch for your bug report, Fury.

[Fury]

That would be an option but how should it work? I would propose that the rays are sent from the center of the effect (can be moved) to the borders of the specified box (with +Box Min,...) or just in all direction when "+Box Min" is not set. Would that suit your needs?

I would rather have +Box optional, by default I think particles could spawn from impact outwards in 90 degree angle (or whatever is the default when none is given). It'd basically just provide some randomization without having to use +Box option.

BTW: I posted a patch for your bug report, Fury.

Cool, thanks. I've pointed it to The E on #scp. It's in 7219.

[Spoon]

Okay, for every one of those three values you can specify either one or two numbers. When a particle gets created a vector is created where every value of the vector (x, y, z) is randomized to be between the specified values or the exact value is used when only value was specified for an axis. After that the vector will be normalized to be of length one (standard mathematical operation) and after that multiplied by the "+Speed" value as specified before. This way you can force the particle to fly in one specific direction, especially useful for weapon-impacts where you want the particles fly in exactly one direction.
I hope that helped, I'm aware that the documentation is lacking at some points but I'm planing to improve the documentation

I think I somewhat understand.

These values are specific to a particle bitmap as these values are computed based on the number of frames and the specified FPS of an effect. I could modify "+Effect" to accept multiple effects where one will be chosen randomly thus creating some diversity.

Ah yeah thats how thruster particles work too, weapon particles have life time though so I figured it could be implented for this as well. Cause having to rely on the framerate for each file is kinda icky. If you want to have the same particlesmoke effect, you'd need to have duplicate file entries with different framerates assigned in the .eff files. slightly less than desirable.

[Nighteyes]

Spoon is right, controlling the particle life through the EFF file is not very convenient, making the script decide at what FPS an EFF is played would allow for a lot of diversity...