UDMF 'classtype' field

[MaxED]

Any chance of enforcing saner actor naming rules first, and only then adding this property?..

[Gez]

Names also need to be remembered and carefully chosen not to collide with whatever else is defined. If you think names are easier to remember than number, look again at the number of people who took twenty years to notice it was "medikit" and not "medkit".

Besides the point is moot anyway since editors just show you a list of what's available. You only need to remember numbers when you want to use stuff that's not listed.

[MaxED]

I thought the main selling point was to get rid of numbers which needed to be remembered...

I don't think I ever did.

filer1.jpg (7.68 KiB) Viewed 689 times

[arookas]

Names also need to be remembered and carefully chosen not to collide with whatever else is defined. If you think names are easier to remember than number, look again at the number of people who took twenty years to notice it was "medikit" and not "medkit".

Besides the point is moot anyway since editors just show you a list of what's available. You only need to remember numbers when you want to use stuff that's not listed.

I don't understand this. Allowing map spawns to use class names makes it unimaginably easier to avoid conflicts. The whole idea of named map things vs numbered map things is analogous to named scripts vs numbered scripts, something you've shown approval of in the past. This is barely different, even down to the arg0str/classtype overriding logic.

[Graf Zahl]

Any chance of enforcing saner actor naming rules first, and only then adding this property?..

Not possible. It would break too many mods with "insane"names.

[Gez]

Collision in a group of 255 possible numbers are a lot more likely than collisions in a group of 32767 possible numbers.

And there's a lot of things you define in DECORATE that you would normally never had any need to place directly with the map editor. What would be the point of placing an imp fireball? Or an abstract class such as [wiki=Classes:DoomKey]DoomKey[/wiki] or [wiki=Classes:HexenArmor]HexenArmor[/wiki]? What about people who would then place a Powerup instead of a PowerupGiver? If editors parse the DECORATE stuff to give you a list of actor names, you'll be spammed by a lot of useless stuff you don't need to use; and if they don't you'll have to type actor names instead of looking at a list of thing types. Is typing "SpiderMastermind" better than typing "7"?

The comparison to arg0str is tenuous. You don't need to use a lot of scripts in a map; whereas you have to deal with things all the time. It'd be more comparable to something such as a specific ZDoom actor type (let's call it CustomSpawner for this discussion) that would, like the RandomSpawner, replace itself with the thing type named in its arg0str.

This would give you about the same feature in a roundabout way (plop a thing, enter a name, and you get it) without having to fundamentally change how map editors work and without having to break core UDMF principles.

[Xaser]

I agree that this would turn into a mess on the editor side without some sort of whitelist for what gets shown, which won't be much easier to configure than just assigning a DoomEdNum in the first place.

Would love to hear some thoughts from the opposite viewpoint, but this seems to me like one of those "lots of work for limited gain" things. Mod interop was mentioned, which is generally a good motivator, but even here it seems a bit niche since we're talking about compatibility between two projects with maps, which would be extremely difficult to make "just work together" without actually coordinating their contents (e.g. if they both define, say, a MAP01, classtype won't help ).

I like this "CustomSpawner" idea Gez mentioned offhand, though. Bonus points for a variant that lets you delay the spawn until Thing_Activate-ing it so you get a nice declarative alternative to SpawnSpot, though that's perhaps a suggestion for another thread.

[Graf Zahl]

The entire "interoperability of mods" is a non-issue. There's two scenarios:

- Everything is assigning DoomEdNums through DECORATE: You'll get warnings no matter what if there's clashes
- mods use MAPINFO to assign Doomednums: No warnings, but they'll overwrite each other.

In both cases the mod can reassign different Doomednums through MAPINFO. Problems solved.
After some thinking I have to agree that this feature would cause a lot of work for a lot of people who would not benefit from it, not the least of which are the editor developers.
I'm ending this by 'no'ing the request.

[arookas]

I'll admit, suddenly making all actors spawnable by name seems a bit overkill, and making them selectable in a hierarchial treeview sorted by inheritance solves only half of the problem.

Maybe extend the MAPINFO doomednums block (or make a new one) to accept named doomednums, which would then be used as a sort of whitelist for spawnable actors using classtype? Something like this:

Code: Select all

doomednames {
  "MyImp" = DoomImp,
  "YourImp" = HereticImp
}

In this example, classtype would only search for names given through this block, using the same overriding logic as the doomednums block. Adding a whitelist to classtype wouldn't be hard. Maybe the name of the field would be changed, as well.

This way, editors wouldn't need to change how a user selects a thing (it'd still have just the spawnable actors in the normal list, grouped by category), the list wouldn't be immediately spammed with unspawnable junk actors, and the actual doomednum/doomedname could be hidden from the user (except for, e.g., search/analysis functions). I wouldn't advise putting the standard actors in there, as to mantain cross-port compatibility, and since they're always define in g/zdoom.pk3, they're going to have doomednums regardless. This would be ideal for custom actors in the future.

Editors could have a named doomednums LUT alongside their numbered doomednums LUT. GZDB has named/numbered scripts as constructor overloads, which is another possiblity.

I think this would be a lot better for everybody. MaxED and Gez, what are your thoughts?

Collision in a group of 255 possible numbers are a lot more likely than collisions in a group of 32767 possible numbers.

True, but note that a considerable range of those numbers are taken by the loaded game/engine. Also to consider is that a good number of mods don't spread out their ranges too far. I often see them start at nice round number ranges in the middle. An example would be 16nnn for items, 17nnn for monsters, 18nnn for decorations.

[Graf Zahl]

I'll admit, suddenly making all actors spawnable by name seems a bit overkill, and making them selectable in a hierarchial treeview sorted by inheritance solves only half of the problem.

Maybe extend the MAPINFO doomednums block (or make a new one) to accept named doomednums, which would then be used as a sort of whitelist for spawnable actors using classtype? Something like this:

Code: Select all

doomednames {
  "MyImp" = DoomImp,
  "YourImp" = HereticImp
}

I'd rather stick with the numbers then...

[NeuralStunner]

If you were going to do all that, it would be less roundabout to add an actor property for it.

[Graf Zahl]

Actually, no. The point was to make that name independent of the actual actor so it can be redefined outside DECORATE. But why? That's what MAPINFO already does, albeit with editor friendly numbers.

[MaxED]

I have an alternative implementation idea:
1. In actor definition, allow to use a keyword instead of the editor number, like so:

Code: Select all

actor MyActor PLACEABLE { ... }

2. In editors/engines, use an int hash of actor's classname as the editor number.

[Graf Zahl]

Whatever. I already 'no'd it because it is becoming very obvious that this is degenerating into a mess.

[MaxED]

Whatever. Less work for me