DeletedUser Posted August 6, 2013 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. 0 Share this post Link to post
GreyGhost Posted August 6, 2013 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. 0 Share this post Link to post
andrewj Posted August 7, 2013 DoomBuilder should notice the BEHAVIOR lump and automatically switch to a Hexen format (or at the very least put up a warning dialog), no? 0 Share this post Link to post
DeletedUser Posted August 7, 2013 Nope, gives no such warning or any indication at all. Using 2.1.2.1553. 0 Share this post Link to post
GreyGhost Posted August 7, 2013 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. 0 Share this post Link to post
boris Posted August 7, 2013 IIRC CodeImp deliberately decided against trying to auto-detect the map format. 0 Share this post Link to post
kb1 Posted August 7, 2013 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 } } 0 Share this post Link to post
DeletedUser Posted August 8, 2013 Well it certainly was built in (Hexen Format) given it utilizes ACS Scripts. 0 Share this post Link to post
boris Posted August 8, 2013 kb1 said:2. Size("THINGS") / 10 <> Int(Size("THINGS") / 10) Hexen things are 20 byte long, so this will always be true. 0 Share this post Link to post
Quasar Posted August 8, 2013 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. 0 Share this post Link to post
kb1 Posted August 9, 2013 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. 0 Share this post Link to post
Kappes Buur Posted August 10, 2013 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. 0 Share this post Link to post
Quasar Posted August 10, 2013 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. 0 Share this post Link to post
Netherstorm Posted August 10, 2013 I hate it when that happens, always did with my older wads. Changing the format should fix it. 0 Share this post Link to post