A few more flags for A_SpawnItemEx

[Major Cooke]

A few flags I would like to recommend:

SXF_TRANSFERTID - Transfer's the thing's TID to the actor that it is spawning. It won't lose it's TID unless combined with:

SXF_LOSETID - Upon successfully spawning the actor, this actor will lose it's TID, but only if successful.

SXF_SETPRIORITY - The actor spawning a different actor with this flag set will no longer hold priority for monitoring, in case if a script is watching the actor through TID or some other method. Instead, the actor being spawned will be set as priority so long as the monster in question doesn't call A_BossDeath before the original monster spawns it (Useful for making multi-staged monsters, for instance). I'm taking a guess as to this being usable only once to help avoid breaking anything.

[FDARI]

Transfertid is feasible.
Losetid is feasible.

Setpriority is probably not feasible. Priority may be a real and predictable concept in the engine as it is implemented, but I don't think it is a feature, and I doubt it will be. TIDs are not designed to distinguish in any way between equal-numbered actors.

[Major Cooke]

Fair enough. I'll stick with the first two then.

It should be noted though, that once it loses it's TID it ignore both of the flags after that point on unless it suddenly performed Thing_ChangeTID again either via decorate or acs.

[FDARI]

I'm not sure what you're saying. The two feasible flags should be implemented as follows (flow description/pseudocode):

if SXF_TRANSFERTID is specified: Transfer the caller's current TID to the spawned object.
If spawn is successful and SXF_LOSETID is specified: Set the caller's TID to 0. This has no influence on the spawned object.

That way SXF_TRANSFERTID|SXF_LOSETID means to pass the TID on to any successfully created actor.

[Major Cooke]

You nailed it on the head.

[Lioyd_Irving]

...but I'd like to know what happened to this suggestion, or at least if anything like it got implemented between then and now. I stumbled upon this topic through Google and everything points to it having simply been forgotten -- which I find baffling considering not only the apparent ease of implementation, but also the sheer potential of what's being suggested. Ignoring the fact that it's pretty much a godsend for my fighting engine, I'm convinced that these two flags would make a whole lot of stuff a whole lot easier for a whole lot of people.

TL;DR: Bump.

[FDARI]

Since bumped: http://forum.zdoom.org/viewtopic.php?f=34&t=30623

[Major Cooke]

...but I'd like to know what happened to this suggestion, or at least if anything like it got implemented between then and now. I stumbled upon this topic through Google and everything points to it having simply been forgotten -- which I find baffling considering not only the apparent ease of implementation, but also the sheer potential of what's being suggested. Ignoring the fact that it's pretty much a godsend for my fighting engine, I'm convinced that these two flags would make a whole lot of stuff a whole lot easier for a whole lot of people.

TL;DR: Bump.

Your wish has been granted. Now, just wish that it gets implemented into Zdoom sometime, which I have a good feeling about.

[Cjk10000]

I wish it was something like this:

A few more flags for A_SpawnItemExTid(...old parameters, [int newTID])

[Major Cooke]

...Or you could just perform a Thing_ChangeTID right before the A_SpawnItemEx with the transferTID flag instead.

[NeuralStunner]

...Or you could just perform a Thing_ChangeTID right before the A_SpawnItemEx with the transferTID flag instead.

Assuming you want to change the original actor's TID.

[FDARI]

I don't think I would go for a separate parameter to make an actor define its own tid. It is not really within the realm of decorate to assign a specific tid, although it gains the ability through the ability to access specials. Decorate is for the generic definition of an actor, and the tid is more of a specific detail, more suited to ACS. (So, one reason is style, or the feel and focus of the language.)

Also, it would end up after the "random chance of not spawning an actor"-parameter, which is really far to the right. If a more appropriate and obviously useful feature is proposed at a later point again, it will have to go to the right of that again. If anything is to be added, I don't think it is tid-assignment.

If you want your actor to set an explicit tid anyway, you can work around it. Using the submitted feature, you could do:

Code: Select all

actor Something
{
var int user_tid;
states
{
   spawnWithTID:
      TNT1 A 0 A_SetUserVar("user_tid", tid)
      TNT1 A 0 Thing_ChangeTID(0, 2000)
      TNT1 A 0 A_SpawnItemEX("SomethingElse", 0,0,0, 0,0,0, 0, SXF_TRANSFERTID)
      TNT1 A 0 Thing_ChangeTID(0, user_tid)
      goto See
}
}

[Lioyd_Irving]

I think Cjk is on to something. Since decorate's "tid" expression returns the user's own TID, I think a simpler, more flexible implementation would be to keep SXF_LOSETID, but replace SXF_TRANSFERTID with an extra parameter defining the spawned actor's TID.

[FDARI]

Granted, it is more flexible. Perhaps take it to the code submission thread?

http://forum.zdoom.org/viewtopic.php?f=34&t=30623

I could provide an alternate code submission and let the developers make the final decision. (One, the other, or none)