UDMF 'classtype' field

[Leonard2]

I don't really get why people worry about the editors?
This suggestion only concerns zdoom..
I'm very surprised nobody made this point: I literally don't care if the editor comes with a list.
All I want is to be able to place a thing without having to worry about the chore of assigning a doomednum to it.
I don't think that's much to ask really, just flat out using the property and nothing else.

[Tapwave]

I don't really get why people worry about the editors?
This suggestion only concerns zdoom..

UDMF concerns a variety of engines, actually. Since it's supposed to be an universal specification, it'd require consensus to be added, as the maps would be broken in any other engine than ZDoom if the other ports weren't made to support it.

All I want is to be able to place a thing without having to worry about the chore of assigning a doomednum to it.

In theory, yes, that'd be the ideal purpose. But the problem of abstract classes, inter-operability between ports with different classnames, etc, makes this a riskier addition than anything else.
At this point, it's much easier to use something like MaxEd showed, an editor with a search function that can find the actor's name from the resource file.

[Gez]

UDMF concerns a variety of engines, actually.

Fixed your link to be not evil.

[Graf Zahl]

In that case: report the post so someone can remove the evil link - which has been taken care of now.

In theory, yes, that'd be the ideal purpose. But the problem of abstract classes, inter-operability between ports with different classnames, etc, makes this a riskier addition than anything else.

That's exactly my problem here. This one concerns one of the core properties in UDMF. This stuff is not changed for some mere convenience issue. Remember: A similar situation results in USDF vs. ZSDF, but there the alternative was not acceptable.

[printz]

I don't get it. We're talking about the "zdoom" namespace here, aren't we? Why should the "zdoom" namespace care how other ports can read it?

[Graf Zahl]

It doesn't. But I still have issues with superseding core properties.

But the way this discussion went I saw no other choice but to end it. The feature as-is would be ok, but not if it needs to get saddled with safeguards and other clutter that were proposed.

[arookas]

The safeguarding was strictly for the editors, which was not needed: the editors could simply not to show any actor classes by default and it be an opt-in feature for actor classes using some method designated by the editor (for GZDB, it could be done in the actor's DECORATE using an editor comment or game-configuration using the classname instead of doomednum). However, the actual in-engine implementation would remain sweet and simple. Or, just do this:

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).