Shared feature proposition: Standard BEX mnemonic for MAP33

[4mer]

If you are considering standardizing a new map info format then how about considering the use of MAPxxINF, ExMxINF lumps to hold the new map info for each map instead of using a single lump.

Also, if you are considering a new baseline standard one suggestion I have is:
Please can you ensure there is a clear way to identify a wad file that uses it. Maybe even going so far as using a new file extension to make it completely obvious i.e. wd2.

[Graf Zahl]

4mer said:

If you are considering standardizing a new map info format then how about considering the use of MAPxxINF, ExMxINF lumps to hold the new map info for each map instead of using a single lump.

Puke!

Why do such a mess? Even SMMU's use of the map label lump was better than that. Besides, it wouldn't really help. You need to load this lump BEFORE starting a game, not while playing it to know what you got. The SMMU method clearly shows its problems in GZDoom because the intermission screens may not be correct due to the missing info and some other stuff gets initialized too late.

[Quasar]

Graf Zahl said:

Puke!

Why do such a mess? Even SMMU's use of the map label lump was better than that. Besides, it wouldn't really help. You need to load this lump BEFORE starting a game, not while playing it to know what you got. The SMMU method clearly shows its problems in GZDoom because the intermission screens may not be correct due to the missing info and some other stuff gets initialized too late.

Which is one of the things I'm trying to fix in EE right now, so that we can load Hexen MAPINFO format stuff at startup properly :>

[4mer]

Maybe it is a bad idea, it's only a suggestion.

I was imagining that the lump would be describing the properties listed above by Gez.

My thoughts were:
It associates the properties of a map with a map.
It can be patched / edited independently.
You can have separate maps in separate wads and merge them without having to edit and merge the map information.

You could still have a master list if you wanted which would describe how maps work together in an episode or hub.
If you want to see what you have before the game starts you could always enumerate the wad directories.

At the intermission the current map info tells you which maps are next so you can read the next map info then if you want.

[Graf Zahl]

4mer said:

Maybe it is a bad idea, it's only a suggestion.

I was imagining that the lump would be describing the properties listed above by Gez.

My thoughts were:
It associates the properties of a map with a map.
It can be patched / edited independently.
You can have separate maps in separate wads and merge them without having to edit and merge the map information.

You can do all of this with cumulative definition lumps like MAPINFO in ZDoom or EMAPINFO in Eternity.

[4mer]

Graf Zahl said:

You can do all of this with cumulative definition lumps like MAPINFO in ZDoom or EMAPINFO in Eternity.

Yes, it's just a different solution to the problem.
I was hoping someone else may be able to justify it with some other advantage that I hadn't considered.

Fair enough, it's probably just a load of work for nothing.

/mops floor

[myk]

Gez said:
People who make maps for PrBoom+ are not going to use extended nodes unless it's technically required by their level because it breaks limits or normal nodes would cause overly disruptive slime trails. "Cleaner" is not something the mapper normally cares about, what matters is that the nodes work.

Yeah, I could have been explicit; had it been a new lump some guy releasing a Boom or vanilla level could add the extended nodes lump for the slime-trail-clean benefit of advanced port users without alienating the users of older engines.

What do you mean by "not make it 'Boom' functionally"? I don't follow. I can see two ways to interpret this, and neither make sense.
-Not "Boom" in that it's entirely incompatible with Boom -> like the extended nodes, then, but you don't like them.

Anything that helps distinguish them immediately helps, as opposed to having to say "hey this BEX file isn't really supported by Boom" in the text file or something.

Quasar said:
In vanilla, the automap name for MAP33 appeared as semi-random garbage.

It depends on the build and game, as it reads what comes after the last level. In the executable files for DOOM II or the Ultimate DOOM (which fail altogether on some systems with some "granular" error) it reads junk, but in the Final DOOM executable (which is more reliable) it reads the name for the first level of Plutonia in DOOM II, the first level of TNT in Plutonia and junk in Evilution. It also reaches the intermission on some environments; apparently consistently in DOSBox... and on some Windows 9x systems, showing no level graphic, instead of the bad graphic error.

Really if anything seems to determine what is considered BOOM compatible now, it's PrBoom+.

Assuming you mean when compatibility level 9 is applied (because if not, it can be critically different form Boom) I'd call that "PrBoom+ -complevel 9" or "PrBoom+'s Boom compatibility"; better names for that in text files than "Boom compatible."

[esselfortium]

myk said:

Assuming you mean when compatibility level 9 is applied (because if not, it can be critically different form Boom) I'd call that "PrBoom+ -complevel 9" or "PrBoom+'s Boom compatibility".

That it's different from Boom itself is, I believe, what he was getting at. If something runs in PrBoom+ with the default settings, it's typically referred to as "Boom compatible" or "for Boom". Definitely somewhat of a misnomer, but it is what it is, for better or worse.

Edit:

myk said:

Yeah, sorry, you caught me before I could add that last bit about better naming :p

There's definitely better possible names for it, but the comment was on what it's commonly thought of as nowadays, not what it should be thought of as. I'd agree that it should be differentiated, but in the common user's mind, it isn't.

[myk]

Yeah, sorry, you caught me before I could add that last bit about better naming :p

Counter-edit: Maybe, but he said it while more or less suggesting we should ditch Boom, so it sounds less neutral. The loose usage also depends on how ports or editing tools present their features (directly and through their documentation) hence Quasar and other coders can do more than just go with the (supposed) flow.

[DaniJ]

I think a definitive 'BOOM compatible' specification would be extremely useful, to modder and developer alike. Such a project could leverage the DOOM wiki and be organised relatively easily (once formally specified it could be locked).