A_SpawnItemEx TID flags

[FDARI]

Original suggestion: http://forum.zdoom.org/viewtopic.php?f=15&t=30425

Patch features

New flag: SXF_TRANSFERTID
Effect: Copy the spawning actor's TID to the spawned actor.

New flag: SXF_LOSETID
Effect: Clear the spawning actor's TID if the spawning was successful. This occurs after the effect of SXF_TRANSFERTID.

Presumed bug, fixed:
The post-processing on the spawned actor checks that an actor was actually spawned, but the success state for the function does not require an actor to have been spawned.
If Spawn() fails, there is no object for post-processing, and no spawned actor, but the result is set to success.
If InitSpawnedObject(I think that's its name) fails, post-processing occurs (probably quite unnecessary, the actor is removed before it can have any effect) but the result state is set correctly.

I changed success state and post processing both to depend on successful creation and initialisation of spawned actor.

Patch 2 adds another enhancement to the function:

New flag: SXF_THINGSPEED
Effect: The speeds set on the spawned thing are multiplied with its normal speed, so that a speed vector of [1.0,0,0] means moving straight ahead at normal speed.

Benefits: Allows you to use A_SpawnItemEx to create moving actors without having to let the spawning actor decide the actual speed.

This short decorate sample does very little work with the feature, but it's something.

Code: Select all

actor TestImp : DoomImp replaces DoomImp
{
	states
	{
		Missile:
			TROO EF 8 A_FaceTarget
			TROO G 6 A_SpawnItemEx("DoomImpBall", 300,0,40, -1, 0, 0, 0, SXF_THINGSPEED)
			Goto See
	}
}

UPDATE: SXF_TRANSFERSCALE was suggested. http://forum.zdoom.org/viewtopic.php?f=15&t=32566

[Major Cooke]

@bug: What does this cover by chance? What do you mean by success state?

[FDARI]

That which I presume is a bug, exists in the code prior to this patch.

There are two steps that may fail in the creation of a new actor.

1: Spawn the actor.
Success: Return the spawned actor.
Failure: Return no actor.

2: Verify the spawned actor.
Success: Return TRUE.
Failure: Destroy the actor immediately. Return FALSE.
No actor provided: Return TRUE.

The process runs both step one and two regardless of success state. If step 1 fails, step 2 always reports success (TRUE).

In the unmodified function, only the result of step 2 is used to determine success. Not spawning an actor in the first place thus reports success. I don't think there is a spawn function that successfully spawns with no resultant actor.

Your flags require a correct determination of success and failure, so I made the presumed fix as part of the code submission.

EDIT: Success state is used primarily by custom inventory items. If any function sets success to true during the pickup-processing, pickup is successful when it reaches STOP. (No pickup is successful if it reaches FAIL.) A custom inventory with a use state will be stored when successfully picked up. (A custom inventory without a pickup state is stored if it has a use state)

[FDARI]

New flag: SXF_THINGSPEED
Effect: The speeds set on the spawned thing are multiplied with its normal speed, so that a speed vector of [1.0,0,0] means moving straight ahead at normal speed.
Separate patch, added in first post.

[Major Cooke]

OH... MY... LAWD! Downloading!

But can you give a better example about the SXF_THINGSPEED flag? I'm slightly confused there...

[Lioyd_Irving]

So...I guess I'm gonna have to make my own fork then. This is exciting and daunting at the same time. On one hand, I get to further optimize the executable itself to do exactly what my engine would need; on the other hand, I know exactly jackshit about programming.

[Major Cooke]

The only daunting part about it is the fact that the compilation and setting up can be a pain at times, but other than that applying patches is rather straight forward.

http://zdoom.org/wiki/Compile_ZDoom_on_Windows

Pray this is added.

[Nightfall]

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.

[Major Cooke]

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

[FDARI]

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.

[FDARI]

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.

[Lioyd_Irving]

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?

[FDARI]

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

[Major Cooke]

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

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

[FDARI]

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.