A_SpawnParticle... Reogrenized.

[Major Cooke]

https://github.com/rheit/zdoom/pull/498
https://github.com/rheit/acc/pull/39

...Do I even need to comment on this?

I will say one thing though. if this gets in, I'm nuking the wikipage. The date of entry will point to this git in particular.

[Gez]

You fault for creating it so soon.

[Xaser]

This is still highly un-optimal, as the flags/lifetime parameters are buried behind all the position/movement ones. I don't want to have to type 'A_SpawnParticle("#FFFFFF', 0, 0, 0, 0, 0, 0, 0, 35, SPF_FULLBRIGHT)' if all I want is a non-moving glowy particle.

My suggestion:
A_SpawnParticle(color, flags, lifetime, size, xoff, yoff, zoff, velx, vely, velz, accelx, accely, accelz, startalpha, fadestep)

This puts all the x/y/z ones in order, puts flags near the beginning, and leaves startalpha/fadestep at the end since they have nonzero defaults and (IMO) are likely to be the least-used ones.

Probably a good idea to make zero for lifetime and size mean "use default" if it doesn't yet, since a value of 0 wouldn't make sense for either. Can maybe say the same for startalpha/fadestep, so feel free to do so and move those earlier in the list.

Thinking on it, defaults for everything except color is probably a good idea as well. Just whatever order allows me to not have to type a zillion zeroes for the position/velocity params.

[Major Cooke]

Done.

Yes, the angle parameter on the decorate version is before the offsets. I'll need more access to that than you think...

[Eevee]

Hm! I rewrote the particle fountains in DECORATE — this should be exactly identical to native, except for some minor precision and RNG details. This uses the current arg order on master, of course.

Main source of ugliness is that you can't choose a string at random (for the color), so the entire call has to be duplicated. Alas, you can't have string user vars either, so each color of fountain would have to duplicate all of this as well.

Code: Select all

ACTOR TestRedParticleFountain
{
	Height 0
	+NOBLOCKMAP
	+NOGRAVITY
	+INVISIBLE

	var int user_angle;
	var int user_dist;

	states
	{
	Spawn:
		TNT1 A 2
		TNT1 A 0 A_SetUserVar("user_angle", random(0, 360))
		TNT1 A 0 A_SetUserVar("user_dist", frandom(0.0, 1.0 * radius))
		TNT1 A 0 A_JumpIf(random(0, 255) < 30, "Color2")
	Color1:
		TNT1 A 0 A_SpawnParticle(
			/* offset */ user_dist * cos(user_angle), user_dist * sin(user_angle), (height + 1) * 1.0,
			/* velocity */ frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0 + 3.0 + ((user_dist < radius / 8) * 0.333),
			/* color */ "ff 00 00",
			/* lifetime */ 51,
			/* flags */ 0,
			/* alpha */ 255,
			/* size */ 6,
			/* fadestep */ -1.0,
			/* accel */ frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0 - 0.0909,
			/* angle */ 0)
		Goto Spawn
	Color2:
		TNT1 A 0 A_SpawnParticle(
			/* offset */ user_dist * cos(user_angle), user_dist * sin(user_angle), (height + 1) * 1.0,
			/* velocity */ frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0 + 3.0 + ((user_dist < radius / 8) * 0.333),
			/* color */ "ff 7f 7f",
			/* lifetime */ 51,
			/* flags */ 0,
			/* alpha */ 255,
			/* size */ 4,
			/* fadestep */ -1.0,
			/* accel */ frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0 - 0.0909,
			/* angle */ 0)
		Goto Spawn
	}
}

Screenshot_Doom_20160121_182044.png

[Major Cooke]

Nothing I can do about it, sadly. I think that has to wait for doomscript, for strings anyway.

[Nash]

Yo don't forget about us ACS folks

[Major Cooke]

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

[Graf Zahl]

you can't choose a string at random (for the color),

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.

[Graf Zahl]

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.

[kodi]

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.

[Graf Zahl]

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

[Fishytza]

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

[Graf Zahl]

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.

[Fishytza]

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 screams says otherwise. >_< )

Also...

This was meant to be some advance preparation for scripting but Randi chose to do it differently...

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?