[Spoon]

BTW, what background is that?

[Colonol Dekker]

They look like arachnid space plops.


I approve, is there any footage?

[T-LoW]

They look like arachnid space plops.


I approve, is there any footage?

Or like plasma spikes from Halo

[Nuke]

Yes it is. I very much would like this to get into trunk. The only thing it really, really needs is +Index or equivalent for tbm's.

there are also a couple of other bugs that need to be resolved. theres a rather serious performance busting one with helical spews, where if the framerate slows down, the effect tries to compensate by making more particles, further busting the framerate. i plan to force a limit on how many particles will be spawned on a frame, if a frame takes longer than expected the particles will be spread out to cover more area (since time is distance). this will be self balancing in that as the fps goes down fewer particles per second will be created. theres another bug but its more of a quality concern, that something that would slow the game down. theres also a matter of wanting to make a few more spew types.

since ive managed to stir up new intrest in this peice of code, im considering working on it some more next month, after the holiday booze runs out.

[Jessnec]

oh...
Thanks a lot of this!   

I get this:
http://imgur.com/UyELC.jpg
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg

Thanks!

 ......

i find so long as you dont go completely overboard, these spewers look awesome. going overboard means your framerate will drop by half. but if you can fit 8 wings of fighers, half hostile and half friendly with this weapon and stay at 60 youve probibly struck a good balence. also note that you can use different bitmaps for each spewer. but other than that its not a bad looking effect.

only, I did a testing, and not problems, exept with the flash of capital explosion. (My screen in total white + crash... only one time)

But, now I can extend this effect, so Thanks! 

[Fury]

Nuke, any update on this? I'd really, really like to get this into trunk, pwetty pwease?

[Nuke]

well i was just gonna go play starcraft but really i dont have anything planned for a couple days, so il take a go at the code.

heres the roadmap so far:
-dont let helical spews spawn more particles on a slow frame (performance bug)  fixed some time ago and forgotten about
-interpolate distance from center in a helical spew segment (quality issue)
-implement other planned spew types (namely plume and jet turns out plume and default could accomplish the same effect)
-add +index, +remove, and +nocreate field for xmt support
-write new documentation to replace lost documentation (if anyone has the readme from the first release let me know) (this will be wikified post-commit)

did i leave anything out?

[Fury]

Nothing in particular comes in mind that I'd add. Except a note about tbm support. For it to work, you need to be able to replace, remove and add specific pspew entries. +Index works for replacing existing pspew, but to remove a pspew you probably need both +Index and +Remove. When adding you use neither, as adding should be default behavior. $Section under $Beaminfo uses +Index and +Remove, so those could be used as an example I imagine.

[Nuke]

Nothing in particular comes in mind that I'd add. Except a note about tbm support. For it to work, you need to be able to replace, remove and add specific pspew entries. +Index works for replacing existing pspew, but to remove a pspew you probably need both +Index and +Remove. When adding you use neither, as adding should be default behavior. $Section under $Beaminfo uses +Index and +Remove, so those could be used as an example I imagine.

ive been looking at the beam section code to try to figure out what it did. looks like in addition to +index i need to add +remove and +nocreate tags. im still trying to figure out how the beam section code works. then i can apply what i learned to the particle spewers. i will make this thing the first thing i work on. after fixing this and the 2 helix bugs, the code should be ready to commit. other spew types could always be coded later and patched in.

so far if you use the "particle spew" flag by itself (as is typical in the retail tables) without any of the other tags, the default values are loaded and only the first spewer is used. the effect behaves like the retail flak effect. all settings are now optional and if any tags are omitted the default value is used in its place. on a new tbl or tbm entry, spews are stored in the order they appear to a maximum of 4.

i figure the tbm behavior is something like this:

if you want to remove a spewer, you need to specify +index, and +remove. im not sure what should be done internally. say you have 3 spewers and you delete the 2nd one, should the 3rd one be downcopied to the 2nd's slot, and defaults restored to slot 3, or should i simply flag it as unused and use it the next time a pspew is added?

i figure replacement or editing requires an +index: and a +nocreate. this explicitly states to use whatever index the user wants (the user should be yelled at if they go over the limit). they could then change any value within, even the type. if the next entry is your typical additive entry, it goes in the next slot. id like to be able to dump the +nocreate flag all together but i want to be consistent with the way beam weapon sections work.

ive added a new type called PSPEW_NONE, and im kinda thinking of making it the default, rather than the retail-compatible PSPEW_DEFAULT that is being used now. on an additive load instead of just counting the number of passes in the loop and using that as the index, to instead loop through the array that stores the particle spew struct, find the first PSPEW_NONE, and store it there. of course id have to consider what to do if the parser found a "particle spew" flag and no pspew tags. i figure so long as none of the spewers are used, you could in that case set the type of the first entry to PSPEW_DEFAULT, and that will handle retail tables. of course what would happen if it encountered the flag in a modular table used in the same way? i figure the best way to deal with that is only change anything if the array is "empty" of any enabled spewers.

just thinking about it gives me headaches. really i just kinda need to know whats expected and the way things should work to be consistent.

[Fury]

I don't know if +nocreate is needed for pspew's. In the case of beam sections which contain a lot of information it is handy to overwrite only specific parts of the section, but pspews don't have that much. Yet at least. Whichever works for me.

[Nuke]

i really dont see a need for it. technically using an +index tag should have exactly the same effect. its saying "hey, this is the index i want to use. put all these settings there!". you dont also need to say "i want to change this". it doesnt make any sense to say what your gonna do, and then say youre gonna do it.

*edit*

k i think ive got this figured out. i finished the parse code. i have to change all the other loops now to reflect the change. as it was the number of particle spewers that were used were in the weapon_info stuct. i have removed this number, since slots will now have a random access capability. instead i added a particle spew type, PSPEW_NONE. so instead of iterating through 0 to num_spewers, i simply iterate through all of them, and skip anything if its type is PSPEW_NONE. it was somewhat tricky to preserve reverse compatibility with both existing particle spew tags and the flag-only implementation used in the retail tables, but i think it will work. so heres how things should work when its done:

ommitting both +index: and +remove will add the pspew to the first available slot, starting at 0.
you may add to an existing effect with a modular table in this manor so long as there are free slots available

you may edit an existing tag with a modular table by specifying an index, you may change one value or all of them, including the type or any combination there of. any edits build on the original entry, so the effect is cumulative.

to remove a spewer you need both an +index: and a +remove tag and nothing else. removing a pespew sets its type to none and restores retail defaults.
you can also remove a tag to reset defaults, and then replace it in the same tbm entry.

using the "particle spew" weapon flag without any other tags results in using the defaults and the first spewer only, this may be expanded with tbms. so you can use tbms with new flags on retail weapons while preserving the old spews. omitting the type tag will also use default values with the default spew type unless the type was set by a previous table, in which case that type is used, if you want some other type you must use a type tag.

all slots are filled on a first come first serve basis, lower numbered slots are filled first. they wont ever change places on you, but if you delete a spewer with one modular table, and another in another table, and you add 2 more and delete one, good luck trying to figure out what spew youre editing with +index:. i suggest doing all xmt editing explicitly, if you delete slot 2 in the first xmt, place the next new one in slot 2 just so you know where its going. worst case scenario, you have to run the game up to four times to figure out the correct index.

as usual with fs tables order is not optional. examples of the correct tag order will be made available when i have a new build good to go.

of course i got some more code to rewrite before i release any code/builds. still need to make the rest of the particle spew code work with the new way data is parsed.

[Nuke]

well i managed to finish implementing what i think is functional xmt compatability. i only tested it as far as using my existing particle mod, the fact that it worked predictably was a good sign. all let you guys go throught the trouble of making sure you can add, edit, and delete particle spewers.

the tags pretty much go the same way they do in the test mod, except now it goes
$Pspew:   
 +Index:
 +remove
 +Type:   
and so on

so heres the build, diff, and test mod in rar form:
particles!

things to test:
+compatibility with retail particle spews
+compatibility with particle spews in existing mods
+spew deletion with xmts
+spew creation with xmts
+spew modification with xmts
+debug messages (information given in warnings should be helpful in debugging mods)

also note that no changes have been made to the spew types, and that helical spews are still subject to be changed for performance and appearance reasons.

[Fury]

+compatibility with retail particle spews
+compatibility with particle spews in existing mods

No debug errors, but didn't check for visual errors.

+spew deletion with xmts
+spew creation with xmts
+spew modification with xmts

Deletion, creation and modification works via tbm as expected.

Do you still want to work on this before I harass someone to review the code?

[Nuke]

if only to fix those bugs with helical spews

as it stands they work, but the change im planning involves changing the meaning of one of the variables and i really dont want people getting used to it the way it is. of course i should have all the other features and bugfixes by tonight if i can avoid getting distracted for a few hours today.

*edit*

looking at my rather mind-splitting maths involved in creating helical spews it does indeed seem that the particle counts are per frame and not per rotation. so there's no reason to change that. so if a frame takes more time than usual the code will spawn the exact same number of particles as under a fast frame, meaning fewer particles are being generated per unit of time while the game is slowing down. now that i think about it i fixed that a long time ago. so i can strike that from the road map. this also means the way things are now is how they will be.

i do still want to add the apearance fix. the helix ix cut up into segments which is spawned at each frame. particles are created along the weapon path between the previous and current position of the weapon. so all the particles are created at the same time and use their velocity to move away from the axis to create the helical effect. problem is that particles created at the back end need to be made to look like theve had time to move while the ones up front barely have time to move at all. not doing this creates a jagged stepping pattern when the effect is viewed from the side. and thats what i aim to fix.

*edit again*

turned out it was a 2 line job. since velocity is essentially distance traveled in unit time all i had to do is take the velocity that i had already calculated and multiply it by frame time and that by one minus the scaler/iterator i was using. and what do you know, immediate results, helical spews look much smoother from the side now. at this point id greenlight commit, but i figure it would just be a few lines of code. better to implement a couple more types while im still familiar with the code than it is to wait a year and have to re-familiarize myself with stuff.

[Nuke]

ok, new build updated. all bugs i knew about were fixed. i added a new spew type, plume. scale controls the initial width of the spew. z scale controls con/divergence. values greater than 0 will cause the effect to spread out, negative values will mace it converge or cross over. this effect is meant mostly to use with missiles, but should work in primary weapons too. see example.

clicky

its ready to commit, unless you can find something wrong with it.

[Echelon9]

Compiled fine on Mac, and I had a play through a few missions okay with the effects.

Would be good to get a few more eyes over it.

[Fury]

This has been committed to trunk in 6995 by Zacam.

[Rodo]

Probably not usefull now but... I played a few missions from the FS2 campaign, found no problems so far.

[Nuke]

now i can work on other things in weapons.cpp without causing loads of merge conflicts. thanks fer the commit.

[Dragon]

Amazing work, these improvements are really great.
Could you try to do the same for thrusters (and, if possible, collision and weapon hit spews)?