DoomEdNumb > 32768

[Armaetus]

I noticed there is a DoomEdNumb for the actors defined in DECORATE, which is limited to 32768...why not double the range to 65536?

[Graf Zahl]

Because it's stored in a signed short. And because if it ain't broke don't fix it.

[Nash]

<BillGates> Who in their rightful mind would need to define more than 32768 new actors anyway? </BillGates>

[Gez]

<BillGates> Who in their rightful mind would need to define more than 32768 new actors anyway? </BillGates>

You can't actually define 32768 actors because several doomednums are reserved by non-actors (such as player starts) or hardcoded for a specific actor which uses a whole range of them (e.g., the sound sequence and ambient sounds).

[Graf Zahl]

Nobody in their right mind needs 32768 different actor types at the same time. Is there even any mod with more than 500?

KDiZD is around 400 different ones and that's already pushing it.

[Project Shadowcat]

Is there even any mod with more than 500?

Getting there. Redefining everything all while adding a lot more content -- much of it being subtle (not even counting spawned extras) can do that.

[Nash]

Yeah well what I meant was, REALISTICALLY, I don't think anyone would even come close to the limit (hell I can't even imagine defining 5000 or 10000 new things.. let alone 32 thousand?).

Well maybe some time in the far, far future when humans are modified to work better and faster (like super humans) and a homebrew mod with the level of detail Crysis is basically looked at as "n00bish" and "so 2009" (similar to how we insult WADs that are "so 1994"), that limit might be easily reached. I mean hey, someone said 640 KB of RAM is all anyone would ever need... :P

[Macil]

And at that point, they're better off using a different engine, or restructuring how actors work fundamentally and removing the need for DoomEdNumbers.

[Rachael]

By that time you might be able to call actors directly by name in UDMF, rather than by DoomEdNum.

[Graf Zahl]

The only reason that wasn't implemented is that we would never have been able to compromise about that across engines.

Here's the point where the programmers' egos would have come in. Nobody wants to change the scheme they came up with and picking one port's naming scheme would have caused problems for all others. Sadly nobody, except the Vavoom author, has so far shown even the slightest interest in creating a unified set of names.

Unfortunately ZDoom is in a bad position here because it can't anymore. The class names are the fundamental basics of how the engine work and so many things depend on them that changing all this is not an option.

But ask anyone else to adjust, you get a lot of complaints and no results. So in the interest of getting a working spec I didn't push the issue in all UDMF-related discussions because it would have gone nowhere.

Same about line specials. I would have gotten rid of the old Doom-type specials altogether because IMO they serve no real purpose in an advanced format but had I done that we again would have gotten nothing. Remember, the only other engine that is about to support UDMF is Eternity which uses a completely different approach to handle both Doom and Hexen specials - unfortunately one that goes out of its way to avoid streamlining and unification of features.

Had I designed a ZDoom-exclusive spec all these numbers would have been gone for good and replaced by something more meaningful and descriptive.

[Cutmanmike]

Here's the point where the programmers' egos would have come in. Nobody wants to change the scheme they came up with and picking one port's naming scheme would have caused problems for all others. Sadly nobody, except the Vavoom author, has so far shown even the slightest interest in creating a unified set of names.

It's a shame we can't all get along to make one big happy Port of Doom. Think how far we would have gotten if all the port authors teamed up.

[CaptainToenail]

An awesome utopian dream that sounds too good to be true, plus I reckon some people would puke at the idea of, 'gasp' new features.
I would really like to have split-screen and that fancy Doomsday level lighting effects too, that would make my day

[Rachael]

Unfortunately, Graf, you are right, and I have to agree with you.

But, that doesn't stop ZDoom from going an entirely different direction and, while still supporting UDMF, creates a textual map format of its own, such as ZDMF. Unfortunately, it would take a long time for editors to catch up with that concept. I guess in the interest of the Doom community, it's a good thing ZDoom didn't go that route. But so much could have been accomplished if it did.

[Gez]

An awesome utopian dream that sounds too good to be true, plus I reckon some people would puke at the idea of, 'gasp' new features.
I would really like to have split-screen and that fancy Doomsday level lighting effects too, that would make my day

Yeah, well. See, Doomsday's idea of "new features" is fancy level lighting effects. ZDoom's idea of new features is scripting and actor definition. PrBoom's idea of new features is demo compatibility with every doom version ever. Chocolate's idea of new features is re-implementing a few obscure bugs that had been sneakily fixed in the source code release of Doom.

Basically, there are three kinds of Doom ports:
- Innovative, like ZDoom, Eternity or the original Boom, add more modding features
- Decorative, like Doomsday or Risen3D, tweak how the game look and sound but doesn't change it
- Conservative, like Chocolate or PrBoom, try to maintain a standard for competitive purposes (speedrun demos, etc.)

But, that doesn't stop ZDoom from going an entirely different direction and, while still supporting UDMF, creates a textual map format of its own, such as ZDMF.

Which would completely negate the point of having joined UDMF in the first place...

[Cutmanmike]

Yeah. Unfortunately this clusterfuck of Doom ports has literally Doomed all consistency and convenience. At least we're on the right track with UDMF now though.