Garbled mess when opening certain maps

So I was wondering on a few occasions when attempting to a view a map in Doombuilder it comes up as a garbled mess with lines all over the place, could it be due to the inept mess the author made or am I just opening it in the wrong format?

For instance this is from Dark Tartarus V1 - MAP30, I opened it in (Skulltag Doom in Doom Format) all the other maps open fine with the exception of this. I've also noticed the same effect if viewing Nuts3.wad, you can't actually view the map just a horrendous string of a cobbled mess.

Share this post


Link to post

Yep, wrong format.

Bloodite Krypto said:

you can't actually view the map just a horrendous string of a cobbled mess.

The "Doom in Doom" and Doom in Hexen" Linedef lump formats are incompatible, which is why you're seeing that mess.

Share this post


Link to post

DoomBuilder should notice the BEHAVIOR lump and automatically switch to a Hexen format (or at the very least put up a warning dialog), no?

Share this post


Link to post
andrewj said:

DoomBuilder should notice the BEHAVIOR lump and automatically switch to a Hexen format (or at the very least put up a warning dialog), no?

Part of what's required is already there in the Game Detect Pattern, I'll poke my nose into the development forum to see if there's been a feature request.

Share this post


Link to post

IIRC CodeImp deliberately decided against trying to auto-detect the map format.

Share this post


Link to post

If any one of these statements is true, it's definitely not a Doom map (or it's ill-formed), and it's most-likely a Hexen map:

1. Size("LINEDEFS") / 14 <> Int(Size("LINEDEFS") / 14)
2. Size("THINGS") / 10 <> Int(Size("THINGS") / 10)
3. // Treat "LINEDEFS" as as array of unsigned 16-bit INTs.

   IsDoom = True
   // Loop through the LineDefs_as_INT16 array, 7 INTs at a time
   for (i = 0; i < arraysize; i += 7)
   {
     if (LineDefINTs[i+0] >= VertexCount ||
         LineDefINTs[i+1] >= VertexCount)
     {
        IsDoom = False
        Exit Loop
     }
   }

Share this post


Link to post
kb1 said:

2. Size("THINGS") / 10 <> Int(Size("THINGS") / 10)

Hexen things are 20 byte long, so this will always be true.

Share this post


Link to post

You can't really reliably use lumpsize % sizeof(struct) to detect map formats because of common multiples. For either struct size there will be multiples of them that are divisible by both possible structure sizes, so for those maps you're unable to eliminate either format as a possibility.

This is why all ports to date use the presence of BEHAVIOR to detect Hexen format, and require that BEHAVIOR never be placed after a Doom-format map.

Share this post


Link to post
Quasar said:

You can't really reliably use lumpsize % sizeof(struct) to detect map formats because of common multiples. For either struct size there will be multiples of them that are divisible by both possible structure sizes, so for those maps you're unable to eliminate either format as a possibility.

This is why all ports to date use the presence of BEHAVIOR to detect Hexen format, and require that BEHAVIOR never be placed after a Doom-format map.

...Which is, of course proper. But, again, if any of those tests ARE true, you definitely do not have a Doom-format map, which is what I wanted to say. I've been using these tests in a home-brew lump editor/map viewer for many years now, as a primary method of detection. The 3rd test is practically guaranteed to be right, on all but the most trivial of maps. I suppose you could contrive one, but the test is really quite reliable. If you've worked with enough WAD files, you see all manners of crazy invalid shit - lumps skewed one byte, pieces of maps cut+pasted into different WADs, etc. I though we were discussing detection, and I guess I assumed that meant "above and beyond presence/absense of the BEHAVIOR lump", cause that's what I do, but, maybe not.

Didn't realize Hexen things were 20 bytes (are you sure? wow - a wasted clause). Then again if not divisible by 10, you'd really have a problem... I wonder about Strife things (Quasar?) I must have used that test for something. I guess the test would be better reversed - then, at least it would find 50% of them!

There was a time when I wanted a way for software to identify which game/port a map needed to run on. That involved all manners of crazy things: Checking lump sizes, line triggers, things/thing flags, BEHAVIOR, etc. Can't say I really succeeded, though I was able to sort a whole lot of maps that way. Legacy had a neat idea with the "text in map identifier lump" thing, used for FraggleScript, I think. Oh well.

Share this post


Link to post
andrewj said:

DoomBuilder should notice the BEHAVIOR lump and automatically switch to a Hexen format (or at the very least put up a warning dialog), no?

Bloodite Krypto said:

Nope, gives no such warning or any indication at all. Using 2.1.2.1553.

GZDoombuilder r1760 FTW

If BEHAVIOR lump is present, a map can no longer be detected as a map in Doom map format.

Share this post


Link to post
kb1 said:

...I wonder about Strife things (Quasar?)...

Strife maps are in pure Doom format. Only the numbers differ (thing types, line specials, sector types). Some linedefs and sectors use a ghetto form of argument, in the form of setting certain other fields such as the texture y offset, to specific values, though.

Share this post


Link to post

I hate it when that happens, always did with my older wads. Changing the format should fix it.

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