DarkPlaces effectinfo.txt

[Baker]

[Irritant]

Yup, that is pretty clever.

[taniwha]

The concept is great, but the file format is ick: no structure (I like curly brackets), though it does have the plus of not needing anything other than id's (crappy) command-line parser.

[revelator]

tenebraes flex based particle parser could probably be modified to handle stuff like this, the syntax is a bit icky though so im not sure whether it would be a gain.

[Baker]

[Spike]

most decent effects depend upon weird engine-specific edge cases. Some of seven's effects also seem to be heavily framerate dependant, and can drop framerates from 2000 to 300 just on their own (less noticable at low framerates, so its okay if you've got rtlights enabled).
I know this from trying to convert seven's effects to fte's custom particle system.

dp's effectinfo stuff is still pretty hardcoded, all you can really do is specify randomized colours+origins+velocities. Basically what I'm saying is 'make a tracer with it'. Also, 'type smoke' is rather ambiguous, and the sort of legacy behaviour that you're probably best without.
Its generally not practical to reimplement, without copy+pastaing the entire gl_rpart.c file or whatever it is.

There's also the fact that it doesn't work with QW-style content downloads, where the mod and all of its content is automatically downloaded from a server file-by-file (as far as I'm aware, dp also has this limitation), while (more vanilla) modified nq clients still only support maps. This limits the use to only single-player mods/content packages.
The network protocol LH added for spawning custom effects from ssqc is also flawed, limiting its reliability and thus usefulness (its based upon csqc, so uses client-specific indexes in the server, which is vile when you consider custom content packages - it should have used precaches).

Also, I like curly brackets too.
They help break up the words and give it structure, instead of it just being a huge great splurge. Makes it so much easier to find the effect you're looking for as you can look directly at the names instead of having to first figure out if it is a name.

No system is perfect, but its at least a step in the right direction.

[mh]

[Baker]

[szo]

[taniwha]

mh: QF added just the one new text format: OpenStep style property lists. Quake's entity data format is actually very close. Actually, building plists from normal enity data was pretty trivial, and going from this to plists (internally) looks like it would be fairly trivial.

Baker: curlies (or other punctuation) often help (though admittedly not always).

[mh]

[taniwha]

Well, QF actually uses property lists in all sorts of places (including saved game data, but reads either). While it's an existing standard, it's rather obscure, not helped by OpenStep having moved on to XML (now that's something I don't want to put into QF. ick).

[Baker]

XML is what happens when you pursue perfection. It becomes a hideous, grotesque failed paradigm. But a "standardized" hideous, grotesque failed paradigm.

The original goal was user-friendly, human readable that even your grandma would feel comfortable editing. *snicker*

So how'd that all work out? *puke*

[leileilol]

[Spirit]

Don't forget to check out what purplehaze did with FTEQW's particle system: http://www.quakeworld.nu/forum/topic/71 ... le-effects

It looks fairly similar in style but in my memory those effects were much more advanced and custom than DP's.