ZDoom

What I mean is the hardware that supports GL 3.x. The spec was quite late and the first drivers had to make do with 2.x and extensions. My first GL3 compatible graphics card was purchased in 2007, and it had been on the market for a few months:

https://en.wikipedia.org/wiki/GeForce_8_series
https://en.wikipedia.org/wiki/Radeon_HD_2000_series

[quote="Graf Zahl"]GL 3.x is neither modern nor recent. [/quote]
There's a reason I made OpenGL 3.0 a link. :P The first thing shown if you follow it is "Release date: August 11, 2008" :wink:

[quote="Gez"]but many people in the community have old computers that can't run something so [u]modern and recent[/u].[/quote]

GL 3.x is neither modern nor recent. From the looks of it (i.e. the reports and feedback I get) the problem exclusively comes from Intel graphics hardware which was fashionably late with GL 3 support. Any real graphics cards with GL 2 only support are long gone by now.
Oh, and let's not forget Apple which decided to screw GL over by skipping the important transition phase and either leave the choice between old and crusty (GL 2 with compatibility profile) and new and useless (GL3 with core profile, which for GZDoom's use case is as good as a hardware decelerator.)

The 2.0 (2.1-pre is still 2.0) branch of GZDoom features a new renderer based on [url=https://en.wikipedia.org/wiki/OpenGL#OpenGL_3.0]OpenGL 3.0[/url] code; but many people in the community have old computers that can't run something so modern and recent. So instead they have to keep using the old 1.8 version. _mental_ volunteered to maintain the 1.8 branch with the new non-renderer features, so that's why there are 1.8 builds now.

I nuked the wiki page. What you see is not what the current GZDoom has, it holds the older one. You'll have to wait for Graf to update GZDoom first.

1.8 is for people with older hardware compatibility, maintained by _mental_ because the hardware cannot run the newer versions of GZDoom.

I just downloaded the most recent 2.1 GZDoom build to give this one a try, but it seems I'm constantly expected to specify more parameters when using this function. For example: if I only specify the color parameter, I get [i]expected ",", got ")"[/i] crash on startup. I tried with a few more parameters but stopped soon as it didn't seem to be going anywhere, and there is supposed to be working defaults, after all.

And can I ask; what is the purpose of these 1.8 GZDoom builds that have been cropping up since January 13?

To be blunt: None. But we will see how much of a point remains there to make new DECORATE functions before the scripting branch is merged. Then this directive will disappear anyway.

Well, at the moment it's rather inconsistent when compared to other DECORATE functions. (And yes, you're right, it is a moot point, but my OCD [s]screams[/s] says otherwise. >_< )

Also...
[quote="Graf Zahl"]This was meant to be some advance preparation for scripting but Randi chose to do it differently...[/quote]
Out of curiosity, does this mean all ACTION_PARAM_STARTs will be removed at some point? If yes, then what's the point of using it when making new DECORATE functions?

If it actually did something - yes. This was meant to be some advance preparation for scripting but Randi chose to do it differently, so it's rather moot to care.

Since there are 16 parameters (for the DECORATE version) numbered 0 to 15, shouldn't ACTION_PARAM_START be 16?

That wouldn't allow spawning stuff at multiple points with one call.

I haven't looked through the function, but shouldn't using getactorx(TID) and getactory(TID) + eventual offsets be enough?
Very excited for this anyway.
Edit: I see. An alternate function sounds like a great idea then.

Merged.

But this makes me think:

The ACS version uses absolute coordinates. I wonder if it makes sense to add a second variant that uses a map spot tid instead. As it is it can only be used for effects that are placed in the world - not for effects that are tied to an actor.

[quote="Eevee"]you can't choose a string at random (for the color),
[/quote]

I thought it'd parse an int as well. But apparently it doesn't. Well, this will have to wait for the scripting branch to get merged. I'm not going to mess around with the old parser for this.

No I sure didn't. This time...