Creating a "map format" page on Doomwiki.org?

[Doomkid]

I'm hoping some of you out there may be able to help me with this..

 

Personally, knowing what map format a wad is built using is one of the most useful pieces of information to me as a player, so I generally know what ports are likely to work for any given wad I download. The only Wiki page directly addressing and comparing the 4 most common Doom map formats is on the ZDoom wiki (here). Unfortunately it's missing info on Boom format, however the specific changes from vanilla format to Boom format are documented here on the Doomwiki.

 

When you type "map format" in Doomwiki, it redirects here, which is pretty much only useful for tech-heads, unlike the ZDoom article which has more pertinent info for blooming mappers. EDIT: disregard this bit, it's now outdated.

 

I think "map format" being given it's own proper page on the Doomwiki - similar to the ZDoom one - would be awesome. On that note/if it were to be done, could someone possibly help me re-format the ZDoom wiki article and port it over to Doomwiki, removing/altering all the ZDoom-specific references so as to be more port inclusive? I'm under the impression that this is okay to do so long as it's mentioned that information is taken from the ZDoom article, with a link provided. Again if I'm wrong, please correct me..

 

I'd already be making this page on my own right now.. but I want to run the idea past others first. I'm also not the best at writing somewhat technical articles of this nature, though since not much revision is needed, I can go ahead and start assuming this is seen as useful.

 

EDIT: Yay, the page now exists! https://doomwiki.org/wiki/Map_format

Edited June 27, 2021 by Doomkid

[Gez]

24 minutes ago, Doomkid said:

I'm under the impression that this is okay to do so long as it's mentioned that information is taken from the ZDoom article, with a link provided.

Indeed, and there's even a template to make that easier.

 

I've just ported the article mostly directly from the ZDoom wiki, so it can now be rewritten to remove the ZDoom-centric parts. Doom 64 map format will have to be added, too.

[Bauul]

I'm all for more info in the Doomwiki, but I would slightly argue that knowing the map format doesn't really give the player any more information on knowing the right sourceport(s) to target. I do agree that having a specific page on map formats is a good idea, but on the wads themselves I would want to make sure it doesn't distract from the real pertinent information, which is what sourceport(s) it was designed for.

 

Of the three main map formats (Doom, Hexen and UDMF), there are multiple source ports that target each. Knowing a mapset is Doom format, for example, tells you nothing about what source port it's designed for.

 

It would certainly be interesting to know, and it does help in the sense that if a mapset is say UDMF you can discount all but a few sourceports. But I believe that focusing on "what sourceport was this mapset designed for?" is the most pertinent information, regardless of map format.

[SiMpLeToNiUm]

12 minutes ago, Bauul said:

..."what sourceport was this mapset designed for?" is the most pertinent information, regardless of map format.

Perhaps the two can be grouped together?

[Doomkid]

1 hour ago, Bauul said:

I'm all for more info in the Doomwiki, but I would slightly argue that knowing the map format doesn't really give the player any more information on knowing the right sourceport(s) to target. I do agree that having a specific page on map formats is a good idea, but on the wads themselves I would want to make sure it doesn't distract from the real pertinent information, which is what sourceport(s) it was designed for.

I definitely wouldn’t want to replace telling people what port is being targeted, but I can say with certainty that knowing the format is also helpful.

 

If a map is UDMF, you know instantly not to try running it in ZDaemon or Odamex despite then being ZDoom-Family ports with a large helping of “Doom in Hexen” format support. You also know it has no chance of working in Vanilla, Chocolate, PrB(not plus), and Crispy Doom.

 

If a map is Boom format, you know it’s likely to run in every port from (Pr)Boom and up, but won’t run in vanilla, chocolate, or Crispy (AFAIK).

 

If a map is Doom format with nothing extra, you can be 99% certain it’s going to run in pretty much every port that’s in circulation these days, and will probably even run in Doom-Plus (vanilla with some raised limits). Heck, it might even run in true vanilla. Numerous times I’ve played maps where the author was using and - as far as they knew, targeting - GZDoom, and yet it was actually a vanilla/limit removing map, and they just didn’t know any better! For this reason, knowing the format is often just as helpful if not moreso in knowing what ports the wad is likely to run in.

 

Anyway, the point of all this is that an article explaining map formats in a digestible way is for sure going to help newcomers understand the differences - which based on numerous posts I’ve seen from newbies, is often a point of confusion.

 

1 hour ago, Gez said:

Indeed, and there's even a template to make that easier.

 

I've just ported the article mostly directly from the ZDoom wiki, so it can now be rewritten to remove the ZDoom-centric parts. Doom 64 map format will have to be added, too.

Thanks, Gez! Once I’m home I’ll get to working on this.

Edited June 27, 2021 by Doomkid

[Gez]

From my viewpoint, "Boom format" doesn't really exist, it's just Doom format. There are more values (for thing types, line types, sector types, etc.) that have meaning, but the format is unchanged. Likewise, there's no "Heretic format" or "Strife format", because they're just Doom format with different lists of values. You can load a Strife map in Doom II, and it'll work. It'll be wonky, you may get errors for unknown sector types or whatever, lines won't do what they're supposed to do... but it'll load.

 

Hexen format, now, that's a different kettle of fish. The way the data is... formatted... is completely different. Take a Hexen format map, delete (or rename) the BEHAVIOR lump to trick the editor into thinking it's Doom format, and look at the result: a complete mess. You're practically guaranteed a crash (or at least an error message telling you it's completely messed up) if you try to load it.

[Doomkid]

I think I could still mention “Boom format” on the article since despite not actually being formatted differently from standard Doom map format, it’s a commonly used colloquialism.

 

I think mentioning it, but also being very clear that it’s just Doom format with extra line types and such that the vanilla EXEs and more basic/restricted ports don’t support would be pertinent (though I’m always open to different ideas or approaches of course)

[Gez]

It could be a subsection of the Doom format section.

[smeghammer]

Certainly from my PoV, I struggled with the availability of objective information on doom, DiHF and UDMF formats. It confused me no end,when I first came across '[insert-sourceport-here] format' in addition to these three.

 

To me - and I guess to other tech-heads too - the format is the way the data is structured. The variations for different source ports are extensions to a particular format (so Boom is simply Doom format with the same data structure, but allowing - for example - more verticies).

 

Therefore, I think it is important for any putative 'map format' page to make this distinction between data format and sourceports that can handle a given format but with limit extensions.

 

In fact, it would probably be useful to tabulate sourceports and the format(s) they can handle, and whether it is extended for a given format.

[Doomkid]

I agree with you that distinction should be made, and on that same note it would probably be best to clearly mention what map formats are supported by which ports.

 

Glad to have several people weighing in here - all these points of consideration that would never occur to me are exactly what I was hoping for.

[ketmar]

still, UDMF can be vanilla (in all kinds except the textual form of data), or "GZDoom UDMF" may or may not work in k8vavoom (depending on used features).

 

what we really need is some way to specify used features. and simply "Boom" may not be enough (again, k8vavoom supports all Boom specials, but some transporters may not work as expected, and break "Voodoo scripting"). also, "Doom in Hexen" may or may not use ZDoom ACS extensions. and so on.

 

ideally, we need some huge table that contains the list of all features from all sourceports (including each ACSF as a separate record), and a tool that will check a map against that table, reporting which sourceports will be able to run the map. not that i know how to create such table, and (which is much more important) how to keep it up-to-date. ;-)

[Sammy J]

I'm glad somebody is working on this, finding descriptive resources for each map format is a pain.

 

I started with an old map format for the most compatibility, Doom 2. I couldn't find much info about it, and all of the example MAPINFO scripts on the doomwiki for ZDoom(old) and ZDoom(new) would crash the game on start up.

 

I'm pretty sure the right info for the format that I'm using is out there, but finding it isn't very obvious. Here's an example of my MAPINFO file that actually works, you can clearly see that the script format isn't on the map format page with the others:

 

//DOOM PROJECT MAP INFO

clearskills

skill nightmare

   AmmoFactor 2
   FastMonsters
   DisableCheats
   RespawnTime 12
   SpawnFilter Nightmare
   PicName M_NMARE
   MustConfirm
   Key "n"

defaultmap
    nocrouch
    nojump
    //sky1 SKY3 0
    cluster 1
    enterpic TITLEPIC
    exitpic ENDPIC
    
map MAP01 "Starbase"
    
    next MAP02
    //secretnext
    sky1 SKYHUB 0.2
    par "45"
    music SAMBO

map MAP02 "Nightmare Arena"

    //next
    //secretnext
    sky1 SKY3 0
    //cluster
    par "30"
    music D_RUNNIN
    

clusterdef 1
music BUNNY
flat RW24_1
exittext "FANCY WRITTEN ENDING"

 

There's a bunch of extra crap in there, I know... But it's the only format that runs for me. The = symbols are gone, no brackets at all, and "" are only used around numbers & letters that are generated in the in-game Doom font. Without those prerequisites the WAD will crash instantly every time. This info should be out there somewhere but I couldn't find anything about it.

 

[Doom-X-Machina]

3 hours ago, Bauul said:

Of the three main map formats (Doom, Hexen and UDMF), there are multiple source ports that target each. Knowing a mapset is Doom format, for example, tells you nothing about what source port it's designed for.

 

I tend to assume anything in UDMF is built for best results in Z/GZDoom.

 

1 hour ago, smeghammer said:

To me - and I guess to other tech-heads too - the format is the way the data is structured. The variations for different source ports are extensions to a particular format (so Boom is simply Doom format with the same data structure, but allowing - for example - more verticies).

 

Agreed.

 

[Urthar]

UDMF can get a bit ambiguous. In theory GZDoom (Hardware Rendering/Software Rendering), ZDoom, LZDoom, Zandronium (Hardware Rendering/Software Rendering) and Eternity Engine all support UDMF, but in practice the level of support can vary quite a bit.

[Doomkid]

Well, here is the page, now with numerous edits by myself compared to the ZDoom version of the article:

 

https://doomwiki.org/wiki/Map_format

 

I tried to do my best to make sure all bases are covered sufficiently. Please take a look and let me know if I've missed anything crucial or there is any misinformation present!

[Bauul]

9 hours ago, Doomkid said:

Well, here is the page, now with numerous edits by myself compared to the ZDoom version of the article:

 

https://doomwiki.org/wiki/Map_format

 

I tried to do my best to make sure all bases are covered sufficiently. Please take a look and let me know if I've missed anything crucial or there is any misinformation present!

 

I think it's a solid start!  However, there are a few things that jumped out as potentially needed additional clarification in the Doom map format section:

 

Quote

Maps created using [Doom] format will be compatible with all source ports.

 

This isn't the case - there are plenty of examples of maps made in Doom format that otherwise target very advanced source ports.  Skulldash: Expanded Edition is primarily made up of Doom format maps for example, but targets GZDoom and won't run in anything else - it will simply crash on startup.  

 

Quote

This format does not support ACS

 

Technically true, but might be worth clarifying that maps built in this format can run ACS, the scripts just have to sit in lumps outside of the map.  For example this is how Eviternity creates its GZDoom-specific effects despite being all Doom map formats targeting PRBoom+.  So just because you make a map in Doom format doesn't mean you are excluded from running ACS scripts.

 

Quote

"Boom format" is a colloquial term referring to maps using features introduced with Boom, such as deep water effects, translucent walls, conveyor belts, generic linedef types and other features.

 

Is it worth explaining that there are different 'levels' of "Boom format", which in practice relate to the different CL levels in PRBoom+/DSDA-Doom?  Using Eviternity as an example again, it targeted the MBF format, but in practice didn't actually run in the original MBF .exe.  In reality, what it was actually designed for was specifically PRBoom+ Complevel 11.  Which kind of brings us back to the issue that describing something by the map format, while certainly interesting from a technical perspective, doesn't actually correlate to what program you need to run it.

 

I think perhaps the page would benefit from a preamble that just explains that a given map format is no guarantee of compatibility with any given source port, although it can guarantee a lack of compatibility with some.  Writing this post helped put my thoughts in order so I'll add this into the wiki now.  I think just explaining this disconnect will be enough to allay my fears about people thinking that certain map formats have a one-to-one relationship with source port compatibility, which isn't the case.

 

Edit: Added in a short opening paragraph.  I'll wait to hear your thoughts before changing any of the existing copy in the main part of the page.

Edited June 27, 2021 by Bauul

[Doomkid]

I think the points you made are generally really agreeable here Bauul, and the clarification in the opening statement is welcome. Regarding the many different flavors of "Boom compat"... I am certainly not against adding clarity (I'm for it, really) but the exact dividing place between "old Boom" and "MBF" and "MBF, but a strain that requires a newer port" is very blurry to me.. I'm not sure where exactly the line is drawn. Definitely not against adding info about those important distinctions though by any means!

 

Re the first point, Skulldash is a bit of an outlier in that it has all kinds of functionality beyond just being a standard level set. I was more referring to the "common wad" which just has levels, music, maybe sounds and a TITLEPIC - anything fancier and I'll be going with the word of the author/text document well before paying mind to the map format :)

 

Also - and this is another point that I think will rarely bare mentioning, certainly not important enough to alter the wiki article - but if a wad has even one UDMF or Doom-in-Hexen map, or uses a single solitary lick of DECORATE, it should be assumed that the entirety of that wad requires a UDMF compatible/advanced/possibly ZDoom-family port, despite the fact that isolated chunks of the wad may be technically be limit-removing on their own.

 

My whole point about the format sometimes being more useful to me than the word of the author refers to many small-scale releases I've played where the author was using a newer port and as such wasn't aware they'd made a vanilla map, essentially.