Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse negative DoomedNums #1688

Open
andOlga opened this issue Jun 3, 2024 · 2 comments
Open

Parse negative DoomedNums #1688

andOlga opened this issue Jun 3, 2024 · 2 comments

Comments

@andOlga
Copy link

andOlga commented Jun 3, 2024

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":
image

The thing selector does not show these at all:
image

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

@Blue-Shadow
Copy link
Contributor

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

@OrdinaryMagician
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants