New A_SpawnItemEx flags: SXF_SPAWNTARGET/MASTER/TRACER

[Fishytza]

There have been situations in the past where I wanted the calling actor to set whatever it spawns as its target, master or tracer. Sometimes even spawning two actors, one being a minion (SXF_SETMASTER), another a spot to teleport back to.

Now, of course the workaround for that is to have the spawned actor do a A_TransferPointer call, and while that's all well and good, it becomes tedious after a while.
Basically, having the caller have a direct reference to what it spawns with one A_SpawnItemEx call would be sweet.

So, hopefully there's room for three more flags?

SXF_SPAWNTARGET:
The spawned actor becomes the calling actor's target. (If the spawn fails, then don't touch the caller's target pointer.)

SXF_SPAWNMASTER:
The spawned actor becomes the calling actor's master. (If the spawn fails, then don't touch the caller's master pointer.)

SXF_SPAWNTRACER:
The spawned actor becomes the calling actor's tracer. (If the spawn fails, then don't touch the caller's tracer pointer.)

[Major Cooke]

Okay, now that's something useful I can do.

[Major Cooke]

Done.

[Fishytza]

Thank you!

There's just one tiny little, itsy-bitsy issue. Shouldn't the new flags take 'originator' into account much like how SXF_SETTARGET/MASTER/TRACER do? It would make this slightly more flexible. (There's SXF_ORIGINATOR for if I really wanted a missile's pointers to get changed.) I should have brought this up in the first post, but I didn't think of it at the time. Sorry about that.

Looking at the code I noticed the possibility of 'originator' being null, but it still shouldn't be a problem.

Basically, change this:

Code: Select all

	if (flags & SIXF_ISTARGET)
	{
		self->target = mo;
	}
	if (flags & SIXF_ISMASTER)
	{
		self->master = mo;
	}
	if (flags & SIXF_ISTRACER)
	{
		self->tracer = mo;
	}

into this:
EDIT: Modified

Code: Select all

	if (flags & SIXF_ISTARGET)
	{
		if( originator )
			originator->target = mo;
		//Do nothing if there's no originator
	}
	if (flags & SIXF_ISMASTER)
	{
		if( originator )
			originator->master = mo;
	}
	if (flags & SIXF_ISTRACER)
	{
		if( originator )
			originator->tracer = mo;
	}

[Fishytza]

Just to be clear, SXF_ORIGINATOR is not the issue, if that's what you think.

I just wanted to see if it's possible that if the caller is a missile then it's the missile's owner who gets its pointers changed, much like how SXF_SETTARGET/MASTER/TRACER sets the spawned actor's pointers to point to the missile's owner.

EDIT: Oh, I just noticed your post it gone.

[Major Cooke]

On second thought, that seems like a dangerous idea that can easily backfire.

The point of ISMASTER and the likes is to make the calling actor set the spawned actor as the calling actor's target.

That's just asking for too many troublesome events and messing with the secondary actor in case if the originator disappears. This can have serious repercussions and making a mess out of things. You're better off just doing a pointer exchange with A_TransferPointers at the start, otherwise people will have to constantly call a check for class ownership.

[Fishytza]

But if the originator disappears (is null) then can't you just fallback to 'self'? Like in the example code above?

[Major Cooke]

That's the problem I'm trying to point out. If the originator vanishes, it'll modify the one who spawned it instead, and that can cause some serious issues. You'd constantly have to check for the class of the originator to ensure you don't get a secondary actor to modify in its place once the originator stops existing.

[Fishytza]

Alright, last compromise. If the originator is gone, do nothing as if SXF_ISTARGET/MASTER/TRACER aren't specified.

EDIT: modified example code above.

[Major Cooke]

I still don't think that's a good idea, because that's actually more limiting than to have A_TransferPointer do that for you. If it sets the originator's target as itself instead of the calling actor's, you have no links to use for the calling actor. To put it in simpler terms, cuts out the middle man, and I've thought of a few neat tricks involving the middle man just now thanks to that.

[Fishytza]

Well, I guess there's no point complicating it any further.

Thanks again for adding this!