[Droid803]

...could i get some non retarded documentation that actually lists what each of the values actually does (or what each of the types are)?...

something like the xxx.tbl pages on the wiki >.>

EDIT: wtf nvm must have been looking at an old version. somehow the description field is now filled in! disregard.

[m!m]

I have uploaded a new version which mostly contains new options to create more complex configuration files. It's now possible to control the definition of specific definitions via an If-Then-Else construct. I also added functionality to include lua code and files in the parsing process if you have to initialize some important things.
The documentation contains information about built-in functions for the $If construct. Currently there is only the "inMission" function which does not work as it depends on this patch (the second one) but when the patch is present it will be possible to add effects on a per-mission basis

[StargateSpankyHam]

Oooooh, I will definitely be keeping an eye on this! Great work!

 

Who else wants to see this in a future mediavps release?

[m!m]

I added a "+Reflection" option to type "Weapon" to get better visuals and to simulate the way it works in the real world™.It only works when you have set "+Use normal"  to YES as that vector is required to compute the resulting reflection vector.
Have fun

[m!m]

Again there's a new version in the first post, it's now possible to better specify the time when particles are spawned for a weapon as you can now specify the emistate (meaning that you can now also trigger the effect when the weapon gets intercepted) and you can control whether the weapon has to be armed or not so you can create little explosions when a bomb gets intercepted before it is armed and a bigger explosion when it impacts or you can change the effect when the weapon impacts unarmed.

[Dragon]

It seems that I've encountered a problem with applying your script to high-speed mods.
Namely, it seems that maximum density of a trail is one particle per frame. This is not enough, as mods like Wings make their missiles go several meters each frame (at 60FPS, a dogfight missile moves about 40m each frame). If, say, smoke particle radius is less than 60m (unlikely in case of dogfight missiles), the trail looks really bad.
Could you find some solution to get around this problem? Ideally, particle emission would be completely detached from the framerate (like it seems to be in ArmAII), so the appearance of trails wouldn't change at all, regardless of framerate.

[Aardwolf]

Problem then is that unless the particles have a very short lifetime, you get way too many particles at once.

[Dragon]

Well, of course you'd have to be careful with this feature. For example, a smoke trail done that way will consist of 1-2 particles spewed multiple times per frame. Short lifetime is another solution, but trails should last a while before vanishing.

[m!m]

Well, your request may (that is a huge may) be possible to implement. Maybe as something like "+PPS" (particles per second) option that overrides density settings. I have a theoretical solution that should be able to allow a trail density that is higher than one particle per frame but I don't know how it will affect the performance as I will have have to do a few more mathematical steps which shouldn't be too expensive but I really don't want to disappoint you in case it doesn't work.

[Dragon]

That sounds amazing. This would actually eliminate a major drawback of all particle spewers I ever seen in FSO, namely dependency on framerate (currently, particle trails tend to start looking ugly at high speeds or in big battles where there's an FPS drop, even one not normally problematic).

[m!m]

There is a new version which has experimental support for sub-frame particle creation™ which can be enabled for both Ship and weapon trails. As this is a experimental feature I haven't documented it but you just need to specify the absolute number of particles spawned per second using the "+PPS" option and it should work fine. I have tested it and it seemed to work fine but please test it and say if it works (also with enabled time compression). When it proves to work then I'll also add it to the particle and debris trails.

[Nighteyes]

does this new PPS thing also works for normal spews on weapons? like missile trails? or only for the death particles? this script has so much data in it now its hard to keep track of it all... I haven't had the chance to test the latest builds, but it seems promising, I knew this kind of script would spread its wings 

[Dragon]

So far, it's implemented on ship engine and weapon engine trails.

[Nighteyes]

what I mean it dosent affect stuff in weapons.tbl right? it needs its own table file to add it to weapons...

I strongly suggest you take the burning debris script and incorporate it into this one(with wanderer's permission of course), and add some easy optimizing functions such as effect to use, FPS for effect(basically lifetime for effect), size and how dense it should spew the particles, this would make it possible to have different burning debris effects for different species, and having it all in one big script makes it easier to mod and manage.

same for the explosion script, the one generating the bright flash as a ship dies, and all the particles on the hull of the ship when its in its death roll.

another suggestion is to split the different functions of the script to different named tbms, with a naming scheme like: prt-deathroll.tbm, prt-explosion, prt-engine.tbm, prt-weapons, prt-debris.tbm(did I forget any other functions of the script?)

and lastly, add for each a PDF file with instructions of use, if possible include a part of a working table file to start with.

having an all in one particle script, all using the new PPS would change the way particles look and help the moddability of particles tremendously, I don't know if its too much to ask one person, but I'm sure if such a thing would happen it would go straight into the newest mediavps.

sorry for the long post, its just that I was thinking about this for a while now, keep up the great work 

[Dragon]

Heh heh heh... 
Maybe you should update your copy of the script before posting?
ALL you described is already in (minus Wanderer's flashes).

[Dragon]

EDIT: After some testing, I found that PPS doesn't work as intended, or at least works really strange.
This config:

Code: [Select]

$Type: WeaponTrail
$Class: AIM-92 Talon
+Effect: exp_smoke
+Speed: 0
+Size: 120, 125
+Number: 1
+Use thrusters: YES
+Variance: 0
+Emitstate: Normal
+FPS: 1
+PPS:                480
Causes the trail to look like this:

You can clearly see "packets" of smoke bitmaps, their "inner" density is right, but the gaps shouldn't be there.

BTW, when we're be done with PPS, I already have another idea. When I started to play around with the feature, I found how enormous the amount of particles on-screen needs to be for missiles in hi-speed mods. So, I'd like to know if it's possible to make use of single bitmap particles usable with your script. Ideally, I'd like an option to use a single bitmap (or looping anim, after having thought about that a bit) and define lifetime separately. Maybe you could also make it possible for particles slowly fade at the end of their lifetime (an effect which would take an enormous amount of frames to pull off with an anim). Also, I'd like to see an option to make particles rotate around their center axis, with a randomized speed (for instance, you could enter negative and positive speed values, positive would rotate clockwise), like they do in modern games. These effects would help adding a lot of variety and realism to particles, without the need to make multiple large effect files (and thus clog the memory).

[m!m]

Ok...
@Nighteyes:
As Dragon pointed out the pps feature is currently only active on ship and weapon trails and you can specify the debris effect on a per shipclass basis (also works for debris from subsystems) but a per species setup could also be possible.

Incorporating the explosion script is most likely not going to happen as the effort to porting Wanderers setup to the internal structures of this script would not be worth the effort, sorry for this one.

Concerning splitting it to individual tables: The scripting table this script uses is actually mostly the bare minimum as it only includes the main script file particleScript.lua and then notifies the global instance of the script of the things that happen. This means that splitting the tables to the parts you pointed out is not possible but I'd still like to hear why you want to do it, maybe I can offer another solution if there is a problem .

The PDF splitting is something I should have done some time ago, will happen.

I hope that answers your questions

@Dragon:
I attached a patch which may fix your problem put it into data/scripts and see if it changes anything. Overwrite the existing file by renaming the extension to "lua", I'm not allowed to upload lua files .

Sadly the your feature request are simply not possible with the current particle system. Animated particles will just play their frames and the vanish, there is not possibility to make it loop. Also fading the particles out at the end of their lifetime requires rather big code and maybe also a custom shader to get it working. Rotating particles is also not possible as currently the particles are simply planes that are rotated to face the camera and to face upwards. No possibility to specify a custom orientation, I'm sorry.
But if you go get the coders to implement a system that is capable of doing this I will add it to the script .

[attachment deleted by ninja]

[Dragon]

Ok. Maybe someday we'll have that (I'll ask Valathil if such things are among his plans).
Allowing not animated particles would still come in handy, especially for long-lasting smoke trails (making them animated usually either looks dodgy, is barely noticeable or requires an atrocious number of frames, since we're talking about 15 second or longer lifetimes).

[m!m]

You can still have an effect with two (or even one frame I'm not sure if that works) and set the FPS in the effect definition to something very low which will results in longer lasting particles.

[Dragon]

I don't think one frame anims work, and two frames mean that there's still one unnecessary thing in memory (which could start to matter with such loads of particles trails can require). Also, it'd be easier for the end user to customize lifetime of such particle with a singe, intuitive parameter, instead of fiddling with FPS.