Spawning Actors with Preset Args/Variables

[Zhs2]

It's 2014 and we don't have a way to spawn actors on command via ACS with given args (and potentially declared user variables, as weird as I imagine initialization procedure to be)? What gives?

An extension to Spawn, perhaps? (I suggest this but perhaps someone can imagine a fully sensible way of implementation.)

[Demolisher]

Couldn't you use [wiki]SetThingSpecial[/wiki]?

[Nash]

Declaring variables and args without the use of States would be nice, yes.

[Zhs2]

Demolisher: Isn't it just a little uncanny to start setting properties on an actor that has already spawned in the world with a state that is currently unknown (or probably possibly non-existent again because the script couldn't reliably catch up with it) over setting the properties at initialization of that actor? In this regard, SetThingSpecial and SetUserVariable/Array are, in all fairness of their implementation, 'too slow'. I know you can do this on a per-map per-actor basis but there is simply no way to do it on the fly for things that probably won't be sensible for map placement.

Personally, just args so far would be perfectly fine. User variables are a bit less predefined...

[Xaser]

If you're already using ACS, this can be done with existing features and nicely wrapped up in a custom function for easy use.

Code: Select all

function bool SpawnSpotSpecial(str actorClass, int spotTID, int actorTID, int angle, int special, int arg0, int arg1, int arg2, int arg3, int arg4)
{
	int tempTID = UniqueTID(0);
	SpawnSpot(actorClass, spotTID, tempTID, angle);
	if(ThingCount(0, tempTID) > 0)
	{
		SetThingSpecial(tempTID, special, arg0, arg1, arg2, arg3, arg4);
		Thing_ChangeTID(tempTID, actorTID);
		return true;
	}
	else
		return false;
}

Code is untested+uncompiled, but the idea still stands. If your worry is performance, my philosophy here is to try it and see. Give the function a good stress test with more actors than you'll realistically use; chances are it'll be more performant* than you think.

Declaring user variables can be done in the same way if you know which uservars you're using -- which, as the modder, you should. :P

*Is "performant" actually a word, or just a Xaserism? :P

[edward850]

No need to use thingcount. SpawnSpot itself is sufficient:

Code: Select all

function bool SpawnSpotSpecial(str actorClass, int spotTID, int actorTID, int angle, int special, int arg0, int arg1, int arg2, int arg3, int arg4)
{
	int tempTID = UniqueTID(0);
	
	// Don't spawn anything if tempTID is somehow 0.
	if(tempTID && SpawnSpot(actorClass, spotTID, tempTID, angle))
	{
		SetThingSpecial(tempTID, special, arg0, arg1, arg2, arg3, arg4);
		Thing_ChangeTID(tempTID, actorTID);
		return true;
	}
	
	// ACC requires a return in the main branch.
	// Also, seeing as we will only reach this if spawnspot fails, there is no real need for 'else'.
	return false;
}

[Xaser]

Oh cool -- didn't know SpawnSpot itself returned a value, so that helps. Also hooray for comments.

[Gez]

Spawn functions all return the number of successfully spawned things.

[Xaser]

Hmm... it's probably worth transferring that behavior then. Using Ed's as a base:

Code: Select all

function int SpawnSpotSpecial(str actorClass, int spotTID, int actorTID, int angle, int special, int arg0, int arg1, int arg2, int arg3, int arg4)
{
	int tempTID = UniqueTID(0);
	int spawnCount = SpawnSpot(actorClass, spotTID, tempTID, angle);
	if(spawnCount > 0)
	{
		SetThingSpecial(tempTID, special, arg0, arg1, arg2, arg3, arg4);
		Thing_ChangeTID(tempTID, actorTID);
	}
	return spawnCount;
}

I skipped the "tempTID == 0" check, since we're calling UniqueTID without a limit. It won't return zero barring any catastrophic nuclear failures of ZDoom.

[On second thought, maybe we should put it back in, then. D: ]

[Nash]

Hey, sorry for the bump.

Took a look at Xaser's and Edward's workaround, and while I don't usually prefer workarounds, this will just have to do for now.

Anyway, my main concern is the "guranteed-ness" (that's probably not a word) of "initializing" (putting in quotes because workaround) args and especially user variables this way.

If I "initialize" a variable using this workaround, will the variable actually be set BEFORE the actor has a chance go into the Spawn state? Let's say I have a bunch of complex stuff going on in Spawn, but I want to conditionalize it with a user variable (so if the variable is set, the complex stuff doesn't happen).

Will the complex stuff have a chance to execute and complete (therefore making this workaround pretty useless in my case), or will the variable be able to "initialize" so that the complex Spawn stuff has a chance to be skipped?

TLDR basically echoing OP's concerns about the workaround being "too slow"

[edward850]

The actor will do all of its first tic stuff pretty much on the spot (i.e all frames until a frame with a non-zero delay). Otherwise it runs the risk of being in an invalid state if something else interacts with it before the end of the tic.

[Nash]

So I'm guessing if a I insert a 1-tic delay somewhere before my "complex Spawn stuff" happens, there's a chance to intercept all of it with this fake initializing workaround, right?

[edward850]

Sans the chance part. It's a definitive. The moment it reaches a delay, it wont do anything else for the rest of the tic (unless prompted by something else, say if it was damaged and put into a pain state). Seeing as the very next thing to happen in this scenario is ACS setting its args, that's pretty much what's going to happen next.

[Graf Zahl]

Even with 'nodelay' set on the first state, you are guaranteed that the only thing that will get called right at spawn time is the BeginPlay method.
And for a regular monster the only thing it'll do is to check the dormant state. This method only does something real for special actors.

[edward850]

Huh. So it is. It just sets the object frame and calls it a day. And I was even sure it tic'd them properly as they were spawned at some point. And now I'm not sure why I thought that, looking at BeginPlay.
... I'm not sure if I need to drink more coffee or less.

On the other hand, now I know why this method "not being fast enough" didn't make any sense to me.