spawnid above 255?

[Enjay]

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

Oooh, I hadn't spotted (or maybe remembered) about that one. Thanks.

Personally, I haven't used Thing_Spawn (etc) for some time now (but obviously I have been using Thing_Count).

I think that the continued use of the spawnid versions could be down to lack of publicity for the classname based versions as Zippy said. Perhaps a bit of a publicity campaign, including marking the spawnid based ones as deprecated might help.

However, as has been said, spawnids are still useful for getting an item dropped by something when it is destroyed. This is not just limited to Hexen as it is a quick and easy way to make a Doom enemy drop a key (or something) on its death. So, spawnids are not fully replaced because that can't be done by other non script methods (I don't think) so spawnids themselves should not be deprecated, only the scripting functions that use them.

... actually, thinking about it, the others shouldn't all be deprecated either. Why? Because they have line special numbers and numeric arguments that allow them to be used directly via a linedef (sans scripting) whereas the ones using classnames cannot.

[Zippy]

So, spawnids are not fully replaced because that can't be done by other non script methods (I don't think)

It can be replicated through non-scripted means. For example, DECORATE. Also, I'm not sure being non-scripted can really be held up as a valuable asset. I have not once come across a wad where all 999 scripts have been used, making use of a script inhibitive. Trying to cater to people who can't figure out scripting also doesn't cut it for me either. Learning is par for the course. So, just because the old, basically deprecated versions can be used in a way which the new ones cannot (for now, UDMF may change that) does not really save them from deprecation. The point is that the superceding functions are (supposed to be) better, and this is arguably true in this case.

I honestly don't think we'd be hurt in the long run by marking things deprecated now and getting people educated on the new material.

[Enjay]

I dunno, setting a thing to have a special and setting a couple of arguments in an editor is a lot easier (IMO) than scripting an enemy to drop an item or making a special DECORATE actor to do it. And again, setting a line special with a few args is simpler than writing and compiling a script too. Clearly, it's something that I no longer have a problem with, but I don't think their use is totally outlived yet. To me, it would seem like deprecating for the sake of deprecating.

[Zippy]

I wouldn't disagree that there is an argument as to whether their usefulness is outlived. I'm just, obviously, on the opposite side of the fence on the issue. The point behind pushing the idea of their deprecation is so recent and new creations are discouraged from relying on this method which is not going to receive any support from the developers anymore. They don't offer any functionality that can't be duplicated, more people who don't know how to use the new stuff will learn them, and the few and far between time it is (or may seem to be) more convenient may be quickly fading in the not too distant future. Concisely, I don't think the "harm" that comes from labeling it deprecated is going to be meaningful or significant in any way, shape, or form. Especially considering there is going to be a crowd that is going to go ahead and use them anyway, regardless of what anyone says.

[Enjay]

Despite the fact I'm still going on about it, I'm not that bothered. However, I just don't think it makes sense to deprecate something that is the only way to do a certain task (e.g. getting a monster to drop an item using purely traditional editor based features) especially when the feature in question is an original engine feature.

[Graf Zahl]

Agreed. It's only the engine developers who may decide to officially deprecate a feature, *NOT* the users - and although this has been superseded by different methods it has not yet been deprecated!

[HotWax]

Perhaps a compromise would be to make sure that the features that use SpawnID but have a string name equivalent available are noted as such on the wiki. I'm not talking about an actual notice box (those are typically reserved for deprecated features), but at least something in the description that makes a note of the other function. In this way, at least people will be informed that there is an alternative method that may better suit their needs.

[Enjay]

I certainly think it would make sense for the Wiki to point people towards the Classname versions of functions that use spawnid. They are, after all, generally much better.

On that, I was wondering if it might be useful to have an additional parameter for spawnspot to specify whether a teleport fog appears or not? I know it can be done by using a second instance of spawnspot to spawn a teleportfog actor at the same time as the main spawning, but just adding a 1 as an additional parameter for spawning the fog actor strikes me as useful.

It would be

Spawnspot ("Zombieman", tid, 0, 0);
Spawnspot ("TeleportFog", tid, 0, 0);

versus something like

Spawnspot ("Zombieman", tid, 0, 0, 1);

Or perhaps some way of choosing the fog actor (Doom has teleportfog and itemfog IIRC and I suppose there are fogs from other games and also custom fogs) but maybe a second instance of spawnspot is the best way to deal with named fog actors?

[Gez]

Or perhaps some way of choosing the fog actor (Doom has teleportfog and itemfog IIRC and I suppose there are fogs from other games and also custom fogs) but maybe a second instance of spawnspot is the best way to deal with named fog actors?

Well, in order to be worth it, the extension to spawnspot would have to work like this:
Spawnspot ("Zombieman", tid, 0, 0, "TeleportFog");

That way you wouldn't lose any customizability compared to using two different spawnspot commands.

I think you can safely consider that it isn't really needed..

[Enjay]

Spawnspot ("Zombieman", tid, 0, 0, "TeleportFog");

Yeah, I thought about that, but by the time you are going that far, you may as well just use spawnspot twice. Probably not needed right enough, but I thought the question was worth asking.

[Zippy]

Agreed. It's only the engine developers who may decide to officially deprecate a feature, *NOT* the users - and although this has been superseded by different methods it has not yet been deprecated!

All the more reason to have brought up the discussion first before taking Wiki editing action. It's correct that those who work closest with the code are going to be determining the status of things, but it is mainly the users that keep the Wiki up to date. We're never going to know unless someone gets someone to say something.

Perhaps a compromise would be to make sure that the features that use SpawnID but have a string name equivalent available are noted as such on the wiki. I'm not talking about an actual notice box (those are typically reserved for deprecated features), but at least something in the description that makes a note of the other function. In this way, at least people will be informed that there is an alternative method that may better suit their needs.

Wholeheartedly agreed. In my mind one of the more common scenarios is going to be a person surfing the wiki looking for a function to spawn things and come across Thing_Spawn (et al.) first, suddenly getting in it their head that they have to go back to all their stuff and start assigning SpawnIDs, making #defines, etc. if they want to be able to spawn things. Being prominently directed to the classname equivalents should alleviate that and similar circumstances. I think more than half the people still using Thing_Spawn do so out of simply not seeing the alternative. In example (if I am recalling correctly), we had a problem with SpawnIDs when working on ZPack, because Torm and some others had been assigning SpawnIDs to things so they could spawn them in scripts and there was a conflict.