UDMF 'classtype' field

[arookas]

Pull request

Made to address my original suggestion. It adds a new string field to UDMF things called classtype. Specifying it will allow you to spawn mapthings by class name directly, rather than by doomednum. It overrides type in a similar manner to arg0str. If both are specified, type is ignored. If the class does not exist, an "unknown type" warning will be logged and the actor will be replaced with the "<!>" actor. The thing will still be affected by spawn replacements. This feature will allow better interoperability among mods, as doomednum conflicts can be avoided.

EDIT: Attached a test map. The explosive barrels are spawned by class name. One of the candelabras have been given a dummy class name to show the error handling.

[Nash]

Does this mean we'd be able to finally do away with DoomEdNums (of course editor support will have to be coded for it)?

I would really like to say goodbye to DoomEdNums once and for all... it's so unnecessarily micro-manage-ey, even for my own projects.

[Graf Zahl]

I'm going to wait for feedback by the editor authors for this.
This is also something that makes it a lot harder to load such maps by other ports, so feedback by the Eternity team would also be appreciated.

@Nash: The numbers are needed because otherwise ports have to agree on the actors' names, which currently is not the case.

[arookas]

Does this mean we'd be able to finally do away with DoomEdNums (of course editor support will have to be coded for it)?

Some actors, unfortunately, do not have actual spawnable DECORATE counterparts, such as player spawns, AmbientSound01-64, polyobj actors, etc. Those would still need to use editor numbers (in MAPINFO, they use special names prefixed with '$' to be assigned these editor numbers).

EDIT: As for the cross-port problem, do you think it would be fine to ignore the classtype if the namespace isn't the one(s) used by the current engine? It'd be a temporary fix.

[Nash]

Oh I don't care about engine Things... those are fine the way it is with the DoomEdNums; I mean, for my own game's custom actors, it would be REALLY productive if I don't have to bother with micromanaging my DoomEdNum list anymore. :)

[Graf Zahl]

EDIT: As for the cross-port problem, do you think it would be fine to ignore the classtype if the namespace isn't the one(s) used by the current engine? It'd be a temporary fix.

The actor names may only be usable in the ZDoom namespace anyway. The problem is something else: If ZDoom overrides core UDMF keys it becomes a lot harder by external tools to handle such maps. This is why I'd like to hear some feedback by those who may be affected by such a change before accepting the PR.

[Gez]

I'm pretty sure it'd require rewriting how thing types are handled in SLADE.

And it'd be very low priority since thing types associated purely and uniquely to numbers is good enough for all non-ZDoom targets.

[Altazimuth]

I'm looking to discuss this with Quasar and printz once they're both online. Personally I like the idea, though it might be a bit of a faff given that ZDoom and Eternity have different class names (but making inheriting types with compatibility names should be relatively easy for both ports). I'll definitely try to get them to weigh in on the subject, and hopefully we can get back to you relatively soon on our conclusion. I'm guessing there might be some resistance due to the overriding of core UDMF keys (as Graf pointed out).

[Quasar]

I've thought about adding "compatnames" to EDF which would consist of ZDoom class names, and these would be usable in certain contexts within Eternity where we're trying to be ZDoom compatible (this would particularly help with making ACS scripts more portable). So to me this idea seems like it has potential.

[Graf Zahl]

My impression is that the biggest roadblock here won't be the ports but the editors, just like Gez pointed out. As for DoomEdNum clashes, I added editor number support to MAPINFO for very good reasons, namely that this method is entirely overridable amd clashes can be sorted out by the actual map using these actors. But from what I see, most custom actors still use the DECORATE numbers, because it's easier to handle - but it also causes more problems.

[arookas]

For editors, it would mean suddenly all actors defined can be placed in the map, which would pollute the thing type lists when placing a thing. The editors could have a manual filter modders can use to optional hide unwanted actors from the list. In GZDB's case, I would suggest making the thing list be able to switch between actor classes (which would show a hierarchial list of actors, similar to UnrealEd) and doomednums (which would have the standard categorized list).

[printz]

Not all things are supposed to be placed in the editor, so therefore not all class names should be accessible. You shouldn't let the designer place Doom imp shots, for example. I think that can be controlled in the thing definition file by adding a hypothetic "editor" specifier.

It is easy to support this in editors: just place something with a dummy doomednum, and set a "custom" UDMF property as classtype="Whatever". The shortcoming would currently mostly be visual (no sprite or size shown in the editor).

[Graf Zahl]

One of the selling points of such a feature would be to enter any arbitrary name, so there's really nothing that would present placing an imp shot. Then again, nothing would prevent a mapper from assigning DoomEdNum 1337 to it via MAPINFO and spawn it anyway.

[printz]

I thought the main selling point was to get rid of numbers which needed to be remembered and carefully chosen not to collide with whatever else defined.

[Graf Zahl]

I guess both are important.