Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Quasar

Shared feature proposition: Standard BEX mnemonic for MAP33

Recommended Posts

A lot of mods have taken to including a "super secret" MAP33 for their DOOM II megawads, such as Speed of Doom. I think it would be nice if BEX-compliant ports offered a HUSTR_33 BEX mnemonic for providing a name for this map which doesn't require the use of non-standard MAPINFOs etc.

Is there any agreement at large?

Share this post


Link to post

Only if you actually can reach it gameplay-wise from Boom. Otherwise, I don't find it necessary, because it probably required a MapInfo in the first place to be made accessible.

Why not standardize MapInfo instead. Has Eternity switched to an EDF-like { } style MapInfo yet?

Share this post


Link to post

Then somebody will want to add map34 and map99. BEX is dead format. Do not touch it. Use zdoom for features!

Share this post


Link to post

Why not in Dehacked?

It's my understanding that Eternity already extended that more common format by adding support for changing the ammo types used by each weapon, that many other ports have added to their own Dehacked support.

That said, Entryway is right (except for the ZDoom bias), Deh and Bex are both legacy formats. If I want a fully working Map33, I will use a ZDoom Mapinfo lump, some Doomsday XG etc, which can co-exist allowing a Map33 and beyond, to be fully playable on most any port if the wad creator writes the required definitions.

Share this post


Link to post
printz said:

Why not standardize MapInfo instead.



Universal Doom MapInfo Format (UDMIF) ? ;)


Even if it came, the result would probably be that there's one less MAPINFO lump to do because aside from ZDoom and Eternity probably nobody would bother.

If both Doomsday and Eternity are participating I might consider thinking about it, otherwise it's not worth it.

Share this post


Link to post

That's a rotten fucking attitude IMO. Maybe somebody would want to add MAP34, but so far I haven't seen it.

Frankly, you could support all of _33 through _XX if you wanted to, simply by handling the mnemonics as a special case and storing the mapnames into an alternate cache of string pointers. But that's too hard right? Never put anything more than the minimum effort into everything you do.

Mediocrity: It takes a lot less time, and most people won't notice the difference, until it's too late.

But since making a simple suggestion such as this seems to bring out the worst in everybody, forget it. Let one port determine what we all have to do.

Last time I checked, BEX is not dead. It is editable via utilities such as Whacked, and megawads continue to provide them for ports that do not support MAPINFO lumps.

MAP33 was accessible in the vanilla executable. If it didn't work in BOOM, then IMHO that was BOOM's problem. Maybe we should keep zone heap corruption in all our ports, because, hey, BOOM had it right? And I shouldn't change those Killoughized functions because that's how BOOM did them. Haha. See? Bad attitude.

In vanilla, the automap name for MAP33 appeared as semi-random garbage. In PrBoom that probably means you should be emulating access to the garbage memory and displaying a bunch of gobbledeegunk on the screen, anyway.

</rant>

Share this post


Link to post
Graf Zahl said:

Universal Doom MapInfo Format (UDMIF) ? ;)


Even if it came, the result would probably be that there's one less MAPINFO lump to do because aside from ZDoom and Eternity probably nobody would bother.

If both Doomsday and Eternity are participating I might consider thinking about it, otherwise it's not worth it.

You forgot Vavoom, which is already trying to support the Mapinfo format of Zdoom.

Share this post


Link to post
Quasar said:

Last time I checked, BEX is not dead. It is editable via utilities such as Whacked, and megawads continue to provide them for ports that do not support MAPINFO lumps.

"BEX is dead" means the format was planned and implemented 12 years ago and you should not extend it just because someone made map99 or because prboom added new cheats and they are not supported by bex's cheats section.

I'd like to have an ability to change some sprites names through in-wad DEH, because vanilla does not support tall sprites and I prefer to have their cut off versions in vanilla and full sized in prboom. Should I extend DEH format and add all sprites names to allowed deh strings and change them through DEHACKED lump as I do for sounds?

Share this post


Link to post

How is this considered a format extension, anyway? There's nothing stopping me from adding the extra string in a BEX patch right now. If a few port authors (or even just one) want to add support for it, I say why not?

Share this post


Link to post

I have to agree with those that are suggesting to standardize a MAPINFO format. The suggested feature doesn't make a whole lot of sense since it would only apply to new projects. All of which can easily supply a MAPINFO lump with their project.

I'm not entirely sure what MAPINFO format would be best to consider a standard. One thing that EMAPINFO has going against it is that it doesn't require strings to be quoted. As such I think it would be difficult for ZDoom to support it. I would suggest using ZMAPINFO and picking a subset of it's properties to be considered standard (probably whatever came from Hexen would do).

Share this post


Link to post

One thing I like in Eternity's version is that it's cumulative per-map.

E.g., if all you want to change is a map's title, you can do something like this:

[MAP01]
levelname = My map
In a Hexen/Vavoom/ZDoom format MAPINFO, that would give you a level with no sky, no music, no par time, no exit, etc.

I posit here that a universal, standardized MAPINFO-like thing would have to be cumulative in the same way, so that you can change just want you want to change and the rest will remain as it was given by the previous definitions of the map.

Share this post


Link to post
Blzut3 said:

I'm not entirely sure what MAPINFO format would be best to consider a standard. One thing that EMAPINFO has going against it is that it doesn't require strings to be quoted. As such I think it would be difficult for ZDoom to support it.


ZDoom's current parser couldn't handle it. And I consider a format that allows unquoted strings fundamentally broken because you always need special parsers for it.

Gez said:

I posit here that a universal, standardized MAPINFO-like thing would have to be cumulative in the same way, so that you can change just want you want to change and the rest will remain as it was given by the previous definitions of the map.


A universal format needs to support both: Adding to the existing definition and replacing it completely. Each one exclusively will always have issues.

Share this post


Link to post

Add a "reset" keyword then. Kinda like DECORATE's skip_super keyword.

Share this post


Link to post

First, EE's EMAPINFO (inherited from SMMU) is not strictly cumulative in that settings are not additive across unrelated lumps. The difference between EE and ZDoom in this department is that all maps have sane defaults. Simply defining a MAPINFO does not cause all of the sane defaults for variables that were not modified to suddenly evaporate. These defaults are relative to the game being played, and for maps that are in the normal range for that game, they are determined by what was originally in that map slot. This is necessary for backward compatibility in a number of instances.

Second, BEX hasn't been dead in EE since its inception, so that's news to me. I've been adding stuff to BEX longer than EE has even been a publicly released source port. cph even adapted many of my early BEX features into PrBoom, such as the [SOUNDS] and [MUSIC] block, which were based on notes for unfinished (*gasp!*) features in Ty Haldermans' BOOM changelog.

I wish we could stop pretending that BOOM team got everything right and finished everything they set out to do, because neither is true. BEX was designed in a way that it is extensible - BEX string mnemonics which are unrecognized by the BOOM DeHackEd parser are ignored, and a simple diagnostic to that effect is issued to the log file if it is active.

That means that no matter HOW MANY BEX mnemonics we add, ports that do not support them are not harmed in any way other than having less support for newer features.

Finally, I don't really believe this shared mapinfo will get anywhere. There are too many fundamental semantic differences in the way ports like EE and ZDoom treat things like episodes for this to ever reach a level of agreement beyond basic syntax. And after looking at the documentation for ZDoom's extended syntax, I am certainly not in love with that. Many elements of it are fundamentally much more complex than anything that made it into UDMF.

Share this post


Link to post
Quasar said:

Many elements of it are fundamentally much more complex than anything that made it into UDMF.



Obviously, because it was never designed as a machine creatable format so many of UDMF's design goals don't apply.

Share this post


Link to post

I'm not against the idea of a shared MAPINFO but lets be honest here, its not going to happen. There is already far too much variation between what each port does with that lump. If anyone is serious about this then I suggest starting over with a new syntax in a new lump/file.

Extended BEX in this instance seems to make sense to me (although I haven't gotten this implemented in Doomsday yet, so feel free to favour the opinions of those who have actually implemented support).

As for the "BOOM is perfect" assertion; I don't think anyone was actually suggesting it was.

Share this post


Link to post

How does Boom respond if you give it a BEX patch with a HUSTR_33 replacement in it?

Just wondering about backwards compatibility as it's probably an important feature in this debate.

Share this post


Link to post

I think it's quite clear that if there were a universal MAPINFO thingie, it would be a lot more limited than the port-specific variants. No defining new episodes, skill levels, end-game messages, gameplay options, etc. Just the bare-bone basics which would be:
- Level string (string)
- Level patch (lump name)
- Level sky (texture name)
- Level music (lump name)
- Level par time (in seconds)
- Normal exit destination (lump name)
- Secret exit destination (lump name)

Other stuff would be skipped. For instance, a Doom or Heretic map outside of a standard E1M1-E3M9 slot would not have the "you were there, now entering" map screen and there would be no way to specify one. Sky wouldn't scroll or rotate. And so on. 99% of the time, people who want such features were going to use a full-fledged MAPINFO thing, whereas this would be mostly an alternative to BEX for arbitrary map lumps. (And that "arbitrary" could very well be limited to just ExMy and MAPxx names.)

Syntax would be simple and easy to parse. Just key = value pairs, no key with more than one value. UDMF syntax could do, so that the parser would be easy to implement.

The lump name would also be new (not MAPINFO), I propose LEVELDEF if it isn't taken already.

Share this post


Link to post

Quasar said:
I wish we

Why "we"? If you want to extend BEX in Eternity, go ahead. Why even ask? If you add this feature and other coders don't add it, so what? This feature will never be "Boom compatible," which is something unchanging people use on purpose so that it will still be supported as such in a hundred years or whatever, or in any new Boom derivative that doesn't necessarily take from someplace else.

My suggestion is: extend the extended DeHackEd format however you'd like, but add new extension (EEX?) and lump names so that it doesn't mess with the way Boom features are used "universally" (much like vanilla.)

Shared features are best applied retroactively when they become established, rather than by whim before they are used.

Share this post


Link to post

I just tried a wad with MAP33 in Boom 202 and even though it didn't let me IDCLEV to it I still managed to play the map using the command -warp 33.
I tried a BEX patch with HUSTR_33 and even though Boom complained about it in (in DEHOUT.TXT):

Could not find 'HUSTR_33'
Invalid string key 'HUSTR_33', substitution skipped.
As you can see, it didn't seem to cause a problem.
Fraggle has a point. If you are going to extend the BEX format it would be a good idea to check all ports that have BEX support and test that it isn't going to cause a problem.

Share this post


Link to post

Going from the Eternity teams' DEH/BEX spec doc, it shouldn't cause any major issues doing it the way Quasar suggests. I don't see what back-compatibility problems it *could* cause tbh (other than perhaps some obscure demos which are reliant on the corruption?).

The reason I say make an exception for MAP33 is because DOOM2.exe allows it to be loaded but doing so leads to zone heap corruption.

I think this is a fair exception and good reason.

Share this post


Link to post
myk said:

Why "we"? If you want to extend BEX in Eternity, go ahead. Why even ask? If you add this feature and other coders don't add it, so what? This feature will never be "Boom compatible," which is something unchanging people use on purpose so that it will still be supported as such in a hundred years or whatever, or in any new Boom derivative that doesn't necessarily take from someplace else.

My suggestion is: extend the extended DeHackEd format however you'd like, but add new extension (EEX?) and lump names so that it doesn't mess with the way Boom features are used "universally" (much like vanilla.)

Shared features are best applied retroactively when they become established, rather than by whim before they are used.

What? Eternity already has its own way to define arbitrary mapnames and numbers. It doesn't need BEX for that. The whole reason for this proposition was to expand an already existing shared/supported feature to create a simple, cross-port standard way of supporting the additional mapslots that seem to have become a popular addition to otherwise Boom-compatible megawads.

Share this post


Link to post
esselfortium said:

the additional mapslots that seem to have become a popular addition to otherwise Boom-compatible megawads.

Unless MAP33 is used as a special map to act like a DEMO1 cutscene ("titlemap" for Boom) or whatever, I see it as a joke if it's just a secret level. Much more correct is to include a separate PWAD in the same ZIP, not mess up with the Doom mechanics due to an original engine oversight.

But I guess it's worth adding support for custom naming if the user watching the cutscene demo presses TAB and sees bad text in the map... So I say I fully agree with Quasar's proposition in this regard. Are there plans for supporting Episode 5 or 6 level names too? Just so that Doom 1 megamappers can include demo cutscenes from hidden levels as well :)

Share this post


Link to post

I'm not sure what the consensus is as far as the BEX names go. Do we have any agreement or should we just leave it alone?

If somebody does have useful suggestions like the ones above for a simple shared MAPINFO format, I am open to those ideas. I think that trying to, for example, accomodate every single feature of EE and ZDoom and who knows what else ports all in a single lump might prove impossible, but there's still a lot of common ground between them all that could be allowed for.

I am currently in the process of rewriting EE's MAPINFO system so that it'll be able to support Hexen properly anyway, so it'd be a perfect time for me to add the ability to insert this shared lump into the data hive.

esselfortium: Once again you really get it ;) This is just an idea to allow people to have proper names for their MAP33's without having to add a whole MAPINFO lump just for such a purpose. It's not really a huge deal though. I may or may not implement it in EE even if there's not wide consensus; the shame will be that without that consensus, nobody will use it anyway and EE will just end up saying "NEW LEVEL" like previously.

printz: MAP33 in SoD is certainly no joke, at least - it's one of the most challenging maps in the set due to the elevator ride at the end from which it takes its name ("Descent to Nowhere").

Share this post


Link to post
printz said:

Much more correct is to include a separate PWAD in the same ZIP, not mess up with the Doom mechanics due to an original engine oversight.

Aww, but then it's not a secret any more. :(

printz said:

Are there plans for supporting Episode 5 or 6 level names too?

Actually, they're already supported in a couple of ports, but you need to download the official* Episode 5 Patch for it to work.


[*Disclaimer: Not actually endorsed by id/ZeniMax/John Romero.]

Share this post


Link to post
Quasar said:

Many elements of it are fundamentally much more complex than anything that made it into UDMF.

There's a reason I proposed standardizing a "subset". The new syntax was specifically designed to allow other ports (namely Skulltag and GZDoom) to extend the feature set and not require ZDoom to continuously introduce/update dummy implementations. Ahh well, I tried.

Personally, I think the next best option is just to use Hexen's MAPINFO. As limited as it is, at least it does provide enough to define a MAP33.

Share this post


Link to post
Quasar said:

I'm not sure what the consensus is as far as the BEX names go. Do we have any agreement or should we just leave it alone?

By all means do it - is my opinion.

Edit: Anyway, can't we just bump the BEX version number if need be?

Share this post


Link to post

Quasar said:
It's not really a huge deal though. I may or may not implement it in EE even if there's not wide consensus; the shame will be that without that consensus, nobody will use it anyway and EE will just end up saying "NEW LEVEL" like previously.

Maybe I wasn't clear above, but I think it's inconvenient because it'll encourage the hacky extra levels even more in "Boom compatible" WADs, when these aren't fully compatible with Boom or any Boom-based engines that for any reason don't implement this extension.

Share this post


Link to post

How far back should we go though? Some people still use ports that are otherwise BEX compatible that will likely never be updated.

I don't want to speak for everyone else but this is 5mins work for me.

Furthermore, it would be relatively simple to HEX edit an existing executable similarly to the way entryway does in DOOM+.

But still, its a valid point. Show of hands?

Edit: Or lets look at the proposed solution. Surely this can be handled differently so as not to cause issue.

Share this post


Link to post
Blzut3 said:

There's a reason I proposed standardizing a "subset". The new syntax was specifically designed to allow other ports (namely Skulltag and GZDoom) to extend the feature set and not require ZDoom to continuously introduce/update dummy implementations. Ahh well, I tried.

Personally, I think the next best option is just to use Hexen's MAPINFO. As limited as it is, at least it does provide enough to define a MAP33.

Right, I think we're on the same page as far as the options for a possible standard "simple" MAPINFO type goes. It was my initial idea that the standard proposal was for something similar to UDMF but for MAPINFO (ie. infinitely expansive and all-encompassing) that made me express skepticism.

Hexen's MAPINFO is an ok feature, but it has some irritating qualities, and there's also the issue that ZDoom has overloaded that lump with multiple languages, so it's difficult to tell what you're dealing with short of implementing a pre-parsing pass to attempt to tell the difference based on arbitrary characters in the input such as curly braces.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×