UDMF 'classtype' field

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: UDMF 'classtype' field

Re: UDMF 'classtype' field

by arookas » Fri Sep 09, 2016 5:05 am

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:
printz wrote: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).

Re: UDMF 'classtype' field

by Graf Zahl » Fri Sep 09, 2016 4:37 am

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.

Re: UDMF 'classtype' field

by printz » Fri Sep 09, 2016 4:27 am

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?

Re: UDMF 'classtype' field

by Graf Zahl » Thu Sep 08, 2016 2:03 pm

In that case: report the post so someone can remove the evil link - which has been taken care of now.
Tapwave wrote: 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.

Re: UDMF 'classtype' field

by Gez » Thu Sep 08, 2016 1:36 pm

Tapwave wrote:UDMF concerns a variety of engines, actually.
Fixed your link to be not evil.

Re: UDMF 'classtype' field

by Tapwave » Thu Sep 08, 2016 1:05 pm

Leonard2 wrote: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.

Re: UDMF 'classtype' field

by Leonard2 » Thu Sep 08, 2016 12:55 pm

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.

Re: UDMF 'classtype' field

by MaxED » Thu Sep 08, 2016 12:56 am

Whatever. Less work for me :)

Re: UDMF 'classtype' field

by Graf Zahl » Thu Sep 08, 2016 12:40 am

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

Re: UDMF 'classtype' field

by MaxED » Thu Sep 08, 2016 12:37 am

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.

Re: UDMF 'classtype' field

by Graf Zahl » Thu Sep 08, 2016 12:13 am

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.

Re: UDMF 'classtype' field

by NeuralStunner » Wed Sep 07, 2016 6:26 pm

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

Re: UDMF 'classtype' field

by Graf Zahl » Wed Sep 07, 2016 5:22 pm

Arookas wrote: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...

Re: UDMF 'classtype' field

by arookas » Wed Sep 07, 2016 4:49 pm

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?
Gez wrote: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.

Re: UDMF 'classtype' field

by Graf Zahl » Wed Sep 07, 2016 4:12 pm

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.

Top