ZDoom

Added in [rev]4188[/rev].

Indeed. Unlike some of the other code submissions, I have reason to believe this is still compatible. I just hope FDARI's willing to update the rest, those are some good decorate functions I can use.

The patch probably requires bumping the flag numbers since SXF_USEBLOODCOLOR has been added since submission, but that's probably the easiest possible edit anyhow. ;)

I'd say bump for great justice, because these are things I very much would like to have!

SXF_TRANSFERSCALE (http://forum.zdoom.org/viewtopic.php?f=34&t=30623&p=579867#p579867) included in new submission. Untested as of right now.

Last time I asked, checked or anything like that, I think the ACS-thinker was the last event on a tick, but I could be wrong. However... I don't really see what you're trying to do. Do you launch script 250 in the end-state? If you want an ACS-operation to start immediately, the "ExecuteWithResult"-variant is for you.

Or.... Are you trying to run script 250 to change some stuff, and wanting the whole script to complete before decorate kicks in? Decorate processing does not start when the actor is spawned, but the next time the thinker runs, and you're in the ACS-thinker at the moment, so you should be home-free. You can kickstart it with SetActorState(), as that forces normal state-processing on the state you set until the first greater-than-0-duration frame.

You can run print statements and logs to check.

Script 250 (void) // Plasma Gun
{
Thing_remove(250);
delay(10);
Thing_SpawnNoFog(10, T_CHAINGUY, 0, 402);
SetActorProperty(402, APROP_Health, (GetActorProperty(402, APROP_Health))*10);
delay(35*15);
Thing_SpawnNoFog(10, T_CHAINGUY, 0, 402);
SetActorProperty(402, APROP_Health, (GetActorProperty(402, APROP_Health))*10);
}

Actor ZombieReplacerMod replaces Zombieman
{
	var int user_Type;
	Monster
	+NONSHOOTABLE
	-SHOOTABLE
	+NOINTERACTION 
	-COUNTKILL
	States
	{
	Spawn:
		TNT1 A 0
	Aliens:
	TNT1 a 0 A_Jump(256,"Al01","Al02","Al03","Al04")
	Al01:	TNT1 A 0 A_SpawnItemEx("Alien1",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG)	Goto End
	Al02:	TNT1 A 0 A_SpawnItemEx("Alien2",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG)	Goto End
	Al03:	TNT1 A 0 A_SpawnItemEx("Alien3",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG)	Goto End
	Al04:	TNT1 A 0 A_SpawnItemEx("Alien4",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG)	Goto End
.....

I've got a question...

[code]Script 250 (void) // Plasma Gun
{
Thing_remove(250);
delay(10);
Thing_SpawnNoFog(10, T_CHAINGUY, 0, 402);
SetActorProperty(402, APROP_Health, (GetActorProperty(402, APROP_Health))*10);
delay(35*15);
Thing_SpawnNoFog(10, T_CHAINGUY, 0, 402);
SetActorProperty(402, APROP_Health, (GetActorProperty(402, APROP_Health))*10);
}[/code]

[code]Actor ZombieReplacerMod replaces Zombieman
{
var int user_Type;
Monster
+NONSHOOTABLE
-SHOOTABLE
+NOINTERACTION
-COUNTKILL
States
{
Spawn:
TNT1 A 0
Aliens:
TNT1 a 0 A_Jump(256,"Al01","Al02","Al03","Al04")
Al01: TNT1 A 0 A_SpawnItemEx("Alien1",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG) Goto End
Al02: TNT1 A 0 A_SpawnItemEx("Alien2",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG) Goto End
Al03: TNT1 A 0 A_SpawnItemEx("Alien3",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG) Goto End
Al04: TNT1 A 0 A_SpawnItemEx("Alien4",0,0,0,0,0,0,0,SXF_TRANSFERTID|SXF_LOSETID|SXF_SETMASTER|SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG) Goto End
.....[/code]

If I read properly somewhere, or someone told me, DECORATE usually has the last say as far as execution order goes, am I right? So would this method work or would I need to add a Delay(1) in the ACS script?

I want to spawn the monster immediately with the TID, and have it's health changed instead of the spawner itself. I take it that'd be the best assurance method?

Thread name... yeah, but that's just one of three submitted versions.
All versions have SXF_LOSETID, and I'd let you know if I would, for any reason, remove it.

Might want to rename this thread. It's got a lot more to it now than before. :P

Anyway, SXF_LOSETID is still there, right? (Haven't tested it yet, just now starting to download it)

No: It will no longer be conditional (A_SpawnItemEx only clears your TID if the spawning was successful).

Now that I think of it...Wouldn't we get the same thing as SXF_LOSETID by making the spawner set its own TID to 0 (via [wiki]Thing_ChangeTID[/wiki]) in the same tic?

I felt up for it today, so I wrote what I hope and believe is a version of a_spawnitemex with tid (newtid) as a separate parameter. I have only tested that it doesn't crash on startup, and I ask that you people test a lot of normal use, as well as use of the added functionality (particularly setting tid for the spawned actor).

Also... To get an idea how little the change is, check the difference between patches 2 and 3.

Other people can also do it. I would add this as a more powerful alternative for the developers, with the tradeoff of requiring an additional parameter. Although it is simple, I cannot do it at this time, for reasons I will not be getting into.

Feel free to use my patch as a starting point for the proposed variant. You would have to remove the definition of the transfertid -flag, in both C plus plus and zdoom.pk3. The patch file should show you where this must be done.

You'd have to add the parameter in pk3 with a default value of zero. Increase the declared number of parameters in C plus plus, and add the parameter, using other integer parameters as a template.

Remove the test for the flag, and set the new actor's tid according to the parameter you have created, unconditionally. By default you will assign zero, which I recall has no effect; at least not when the tid is already zero.

Feel free to give it a try. I can't guarantee that my instructions are accurate, complete, or properly understood by you, but they should be enough to give you a fair chance; whoever you may be.

It's up to FDARI how he wants to do it, but SXF_LOSETID is a necessity to me.

Maybe instead of a SXF_TRANSFERTID flag, add a tid parameter to spawnitemex? That'd be infinitely more useful IMO, and can cover the needs of SXF_TRANSFERTID too, just set this parameter as "tid" and the tid will be passed on.