You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Okay, I know what you're thinking: the documentation states that "[a] DoomEdNum is a value between 1 and 32767".
Like many things in the documentation, this is a blatant lie. The actual range for DoomedNums is -32,768 to 32,767. It's a 16-bit signed integer, because of course it is, where else would such a strange limit come from?
Observe. The attached WAD includes a (barebones) custom monster definition, a doomed number for it -- which is -2, and a "hacked" (manually edited) UDMF textmap which uses that doomed number to refer to a thing type. In engine, this works perfectly.
Now this is great: we can add thousands more custom things to mods than we're led to believe. However, the map editor was probably written based on the misleading docs rather than the actual implementation. As such, we have two problems.
Pre-placed things with negative doomed numbers show up as "unknown type":
The thing selector does not show these at all:
It would be great if these could be supported, as they're perfectly cromulent and some large projects (like RAMP) could benefit greatly from the doubled DoomedNum range.
Mock-up
No response
The text was updated successfully, but these errors were encountered:
Like many things in the documentation, this is a blatant lie. The actual range for DoomedNums is -32,768 to 32,767. It's a 16-bit signed integer, because of course it is, where else would such a strange limit come from?
That "strange limit" comes from the way of assigning editor numbers to actors through their definitions in DECORATE, not the MAPINFO one.
So it's a case of outdated information on the documentation's part rather than a "lie".
The limitation mentioned only applies to DoomEdNums assigned through DECORATE, really. Setting them from MAPINFO allows any signed 32-bit integer instead. I've been using those in combination with a ZScript Map Postprocessor just fine for a long time now to insert certain special things.
Editor
Map editor
Description of your feature request
Okay, I know what you're thinking: the documentation states that "[a] DoomEdNum is a value between 1 and 32767".
Like many things in the documentation, this is a blatant lie. The actual range for DoomedNums is -32,768 to 32,767. It's a 16-bit signed integer, because of course it is, where else would such a strange limit come from?
Observe. The attached WAD includes a (barebones) custom monster definition, a doomed number for it -- which is
-2
, and a "hacked" (manually edited) UDMF textmap which uses that doomed number to refer to a thing type. In engine, this works perfectly.Now this is great: we can add thousands more custom things to mods than we're led to believe. However, the map editor was probably written based on the misleading docs rather than the actual implementation. As such, we have two problems.
Pre-placed things with negative doomed numbers show up as "unknown type":
The thing selector does not show these at all:
It would be great if these could be supported, as they're perfectly cromulent and some large projects (like RAMP) could benefit greatly from the doubled DoomedNum range.
Mock-up
No response
The text was updated successfully, but these errors were encountered: