spawnid above 255?

[Enjay]

I've been looking in some mods and, as far as I can tell, everyone tries to give spwnids no greater than 255 to things defined in DECORATE. Now, I know, or rather assume, that the 255 limit makes sense for any spawning that needs to be done via line types or by giving things a special, but would numbers > 255 be acceptable when I know that certain items are only ever going to be manipulated via spawnid using scripts or is this a limit?

[The Unmaker]

You probably caN, AND IF YOU WANTED TO ACTIVATE VIA LINES YOU CAN have a script with two arguments the tag, and the hibyte.

sry bout the caps

[TheDarkArchon]

I've been looking in some mods and, as far as I can tell, everyone tries to give spwnids no greater than 255 to things defined in DECORATE. Now, I know, or rather assume, that the 255 limit makes sense for any spawning that needs to be done via line types or by giving things a special, but would numbers > 255 be acceptable when I know that certain items are only ever going to be manipulated via spawnid using scripts or is this a limit?

[wiki=Spawn numbers]The wiki says[/wiki] that 255 is the limit

[Gez]

And the wiki is correct. Even internally, the spawnid is represented by a byte.

Code: Select all

struct FActorInfo
{

<snip>
	PClass *Class;
	FState *OwnedStates;
	FActorInfo *Replacement;
	FActorInfo *Replacee;
	int NumOwnedStates;
	BYTE GameFilter;
	BYTE SpawnID;
	SWORD DoomEdNum;
	...<snip>
}

And of course the parser makes sure that it's a byte whose value is between 1 and 255.

Code: Select all

static void ActorSpawnID (FScanner &sc, AActor *defaults, Baggage &bag)
{
	sc.MustGetNumber();
	if (sc.Number<0 || sc.Number>255)
	{
		sc.ScriptError ("SpawnID must be in the range [0,255]");
	}
	else bag.Info->SpawnID=(BYTE)sc.Number;
}

While this could be changed in UDMF, the SpawnID is a bit a deprecated way of doing things, ACS and DECORATE offering more possibilities.

[Graf Zahl]

... and that's the reason why it hasn't been changed yet. Since there are functions that take actor names directly there's little point beyond keeping them for compatibility.

[Zippy]

So, short version: Stop using spawn IDs and use the [wiki=SpawnSpot]other[/wiki] [wiki=SpawnSpotFacing]functions[/wiki] [wiki=SpawnProjectile]instead[/wiki].

[Slasher]

So SpawnIDs are deprecated, basically?

[Gez]

So SpawnIDs are deprecated, basically?

Yeah. The only place where they're useful is for things like the Hexen breakable objects, so you don't have to make a script or a custom decorate object that can create various stuff when broken. It's a quite limited field.

Outside of their possible use in DiH mapthings args, what can you do with them that you can't do in a simpler and better way?

Plus, they're confusing. There's the ThingNum and the SpawnID, and of course they're not the same. And they're crossover incompatible (you can't spawn a Hexen thing in a Doom map using them).

So, they're impractical, limited, and confusing; and kept only for compatibility purpose. Seems to fit the description of a deprecated thing...

[Enjay]

I was only using them because the Stronghold scripts depend on them for their various spawning routines. I was trying to figure my way through the Stronghold scripts and the best way for me to try and learn how they were working was to add some stuff of my own. I thought it would be nice and neat to add my own series of spawnids with numbers clearly outwith the range being used elsewhere.

[Slasher]

stuff about spawnids...

Fine with me, I've never used them anyway. I only mentioned it because it seems like a perfect candidate to be marked deprecated on the wiki.

[HotWax]

I only mentioned it because it seems like a perfect candidate to be marked deprecated on the wiki.

My only concern is this... If we deprecate spawnid, doesn't that mean we also have to deprecate every function that makes use of them as well? ([wiki]Thing_Spawn[/wiki], [wiki]ThingCount[/wiki], etc.)

[Enjay]

And those functions are still in very common use.

Thing_Count is an unusual one because it uses spawnids, but doesn't have to (ie it can use tids instead).

Is there any other function that does the spawnid-based job of Thing_Count without having to set tids etc? ie can anything else count all the items on a level by type? Or, indeed, by tid for that matter?

[HotWax]

Well there's [wiki]ThingCountName[/wiki], which can count by TID and/or type name...

[Zippy]

All SpawnID based functions have a classname equivalent. Gez is really correct in saying that the only place SpawnIDs have a real use left with is Hexen style breakable objects. The fact people are still using the almost completely deprecated SpawnID functions is a testament to the fact that we haven't been spreading the information on the classname functions and promoting proper usage thereof as well as we should be. In my mind it is even more of an incentive to mark SpawnIDs and functions as deprecated to encourage people to use the new ones. They shouldn't be using the old ones anymore.

[Slasher]

I agree with Zippy. Because we have functions that use classnames and such, the ones that use spawnids aren't necessary, and could be marked deprecated.