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

Do you enjoy a good mystery?

Recommended Posts

Great, because here's a major WTF mystery:

My map has once again broken compatibility with Chocolate Doom 2. To try and narrow things down, I decided to see if a camera thing entity had been left behind. In order to do this, I went through and deleted all items per 1 sector at a time. I ended up deleting every single thing entity, none of which was a camera.

Here's where things get strange. With all thing items deleted, I test ran the map (using Doomsday through Doom Builder) and GIANT SECTIONS OF WALL WERE MISSING. So now I had a new problem: trying to figure out just what the hell caused this to happen. I went back to my previous map save (with all thing items in place) and began deleting them again. I'd delete one, test the map, and the walls were fine. Delete another, test the map, walls were fine. I did this over and over again until I narrowed it down to which item was somehow killing my map.

I finally find the culprit: a rocket thing entity, in a completely unrelated sector to the one where the walls diappear. But sure enough, delete the rocket, test the map, walls are gone. Leave the rocket, test the map, walls are fine. The rocket is in Sector 157. The walls that vanish are in Sector 0/1.

How the heck is this even possible? Why would an item in a different sector cause the walls of another sector to vanish? How would you even fix something like this? And yet, it gets even stranger still. In Doom Builder, when the rocket remains undeleted, and you press W for 3D edit mode... your view is from the rocket! Not the player 1 start position in Sector 0... but from the rocket in Sector 157. WTF. Again I must ask, How the heck is this even possible?

So, not only does deleting that rocket cause 4 "minor" warnings in Doomsday... not only does it cause several walls in an unrelated sector to vanish... but it somehow is so screwed up that the rocket acts as a camera start point.

Here are a few screenshots to clarify exactly what I mean:








You can see the map layout from Doom Builder here:
http://www.georgeharrisalphacompany.com/wads/bugs/doombuilderwtf.png

If anyone can solve this bizzare mystery, I'd forever be in your debt.

Share this post


Link to post

I highly doubt a thing could cause such an error. It's more like a map or node building error. The later of which could be caused by DB or Doomsday.

You might also want to run DB's error checker, just incase (F4).

Still, without the wad it'self to look at...

BTW, in DB, you can search for many things on a map automatically by pressing F3 or Ctrl+H to find and replace.

Share this post


Link to post

I know, I did search Things that way first. It didn't come up with anything (didn't find a camera), so I wanted to be more thorough and check by hand. And I've used DBs built-in error checker multiple times.

The thing is that when I leave all the thing entities in, there are zero errors in Doomsday. It just won't play in Chocolate Doom. So it may not have anything to do with a camera, that was just my first guess and what I've thus far investigated--which lead to the discovery of this weird rocket/camera/disappearing-walls problem.

If you don't mind, I'll send you a PM with the WAD that has all but the rocket deleted.

Share this post


Link to post

If anyone here uses DeePsea, there are quite a few errors with my map that simply do not show up in Doom Builder. Unfortunately, I don't have a registered version of DeePsea, so there's no way of fixing any of these issues. Any ideas on how to repair them in DB or perhaps another WAD editor?

The error log:

SD 00004 SideDef 4, Xoffset -64 (maxoffset set in F5 options)
SD 00047 SideDef 47, Xoffset -64 (maxoffset set in F5 options)
SD 00049 SideDef 49, Xoffset -96 (maxoffset set in F5 options)
SD 00061 SideDef 61, Yoffset -16 (maxoffset set in F5 options)
SD 00250 SideDef 250, Xoffset 16 (maxoffset set in F5 options)
SD 00765 SideDef 765, Xoffset 28 (maxoffset set in F5 options)
SD 00796 SideDef 796, Xoffset -207 (maxoffset set in F5 options)
SD 00798 SideDef 798, Xoffset -188 (maxoffset set in F5 options)
SD 00800 SideDef 800, Xoffset -103 (maxoffset set in F5 options)
SD 00802 SideDef 802, Xoffset -86 (maxoffset set in F5 options)
SD 00804 SideDef 804, Xoffset -194 (maxoffset set in F5 options)
SD 00806 SideDef 806, Xoffset -177 (maxoffset set in F5 options)
SD 00808 SideDef 808, Xoffset -92 (maxoffset set in F5 options)
SD 00810 SideDef 810, Xoffset -72 (maxoffset set in F5 options)
SD 00814 SideDef 814, Xoffset -250 (maxoffset set in F5 options)
SD 00816 SideDef 816, Xoffset -144 (maxoffset set in F5 options)
SD 00818 SideDef 818, Xoffset -83 (maxoffset set in F5 options)
SD 00820 SideDef 820, Xoffset -191 (maxoffset set in F5 options)
SD 00822 SideDef 822, Xoffset -130 (maxoffset set in F5 options)
SD 00827 SideDef 827, Xoffset -228 (maxoffset set in F5 options)
SD 00877 SideDef 877, Xoffset 64 (maxoffset set in F5 options)
SD 00881 SideDef 881, Xoffset 64 (maxoffset set in F5 options)
L  00089 LineDef 89 WR*Teleport (sector tag 75)
L  00089 5 Sectors have same Teleport Tag?
L  00090 LineDef 90 WR*Teleport (sector tag 75)
L  00090 5 Sectors have same Teleport Tag?
L  00091 LineDef 91 WR*Teleport (sector tag 75)
L  00091 5 Sectors have same Teleport Tag?
L  00093 LineDef 93 WR*Teleport (sector tag 75)
L  00093 5 Sectors have same Teleport Tag?
L  00094 LineDef 94 WR*Teleport (sector tag 75)
L  00094 5 Sectors have same Teleport Tag?
L  00095 LineDef 95 WR*Teleport (sector tag 75)
L  00095 5 Sectors have same Teleport Tag?
L  00096 LineDef 96 WR*Teleport (sector tag 75)
L  00096 5 Sectors have same Teleport Tag?
L  00097 LineDef 97 WR*Teleport (sector tag 75)
L  00097 5 Sectors have same Teleport Tag?
L  00098 LineDef 98 WR*Teleport (sector tag 75)
L  00098 5 Sectors have same Teleport Tag?
L  00101 LineDef 101 WR*Teleport (sector tag 75)
L  00101 5 Sectors have same Teleport Tag?
L  00102 LineDef 102 WR*Teleport (sector tag 75)
L  00102 5 Sectors have same Teleport Tag?
L  00103 LineDef 103 WR*Teleport (sector tag 75)
L  00103 5 Sectors have same Teleport Tag?
L  00510 LineDef 510 WR*Teleport (sector tag 12)
L  00510 2 Sectors have same Teleport Tag?
L  00511 LineDef 511 WR*Teleport (sector tag 12)
L  00511 2 Sectors have same Teleport Tag?
L  00512 LineDef 512 WR*Teleport (sector tag 12)
L  00512 2 Sectors have same Teleport Tag?
L  00513 LineDef 513 WR*Teleport (sector tag 12)
L  00513 2 Sectors have same Teleport Tag?

Share this post


Link to post

The error checker with Doombuilder is severely damaged. I've experienced many times how it just ignores errors that I know are there (just want to know exactly where they are)

Share this post


Link to post
kristus said:

The error checker with Doombuilder is severely damaged. I've experienced many times how it just ignores errors that I know are there (just want to know exactly where they are)


Yeah I know, it kinda sucks--which is a shame, because DB is such a great editor for a beginner like me. From what I've read, the nodebuilder in DB has problems as well, but is supposedly fixed in DB 2. Hopefully the error checker has been fixed too... if DB 2 ever gets released.

Share this post


Link to post

First off OpenGL masks errors. Try running the map in plain old software mode and tell us what you see when you look at the problematic walls. Does the disappearing walls happen in any other port, OpenGL or not?

If everything you say is true, there is something very sinister going on here. Deleting a rocket pickup from a map is not going to make walls disappear even under the strangest circumstances. This might be a wild guess, but you may have got some hefty lump corruption of sorts in your wad and your editor and/or nodesbuilder isn't correcting it. You might try using another editor to open and save it with. Perhaps even try another nodebuilder, an OpenGL-compatible one.

It's not very common for such anomalies like that to happen, but I've ran across them in the past decade and they do make absolutely no sense.

Also, do any of the linedefs/sectors in that error report correspond to the walls that are being affected?

Share this post


Link to post

I haven't worked out why the map crashes Chocolate Doom other than noting that it crashes Doom95 with a memory allocation error.

But I have an answer of sorts for the Doomsday issue. It seems that either DB or Dday's node builder has a highly obscure glitch on maps with certain geometry, if it has no things on it other than a player start. This leads to a single invisible wall in a single sector that the player can see at map start up.

I have checked this in Dday using one of my own maps with similar geometry and was able to reproduce the invisible wall.

But Dday's node builder has been rewritten for the upcoming Beta6 which may eliminate this glitch. It's also highly unlikely that someone will make a map with no things. So it really isn't something worth worrying about IMO.

Share this post


Link to post
EarthQuake said:

First off OpenGL masks errors. Try running the map in plain old software mode and tell us what you see when you look at the problematic walls. Does the disappearing walls happen in any other port, OpenGL or not? ...


The only software mode 'port' I have is Chocolate Doom, and my map won't even load in there. What's strange (as if the rest weren't already) is that it was working in Chocolate Doom last night. I've added a couple new sectors since then--nothing major--and now it won't load in Chocolate Doom at all. If Doomsday has a software mode, I'm unaware of it.

EarthQuake said:

Do any of the linedefs/sectors in that error report correspond to the walls that are being affected?


From what I can tell, they don't. They're mainly in a sector to the far east of the map. I know, it's baffling.

Share this post


Link to post
Vermil said:

... I have checked this in Dday using one of my own maps with similar geometry and was able to reproduce the invisible wall.

But Dday's node builder has been rewritten for the upcoming Beta6 which may eliminate this glitch. It's also highly unlikely that someone will make a map with no things. So it really isn't something worth worrying about IMO.


My map won't have no things in that sector, it was just trimmed down while I was trying to find which thing in particular corresponded to the magic disappearing walls. From what you're saying, maybe if I add some weapons/ammo/whatever back into that sector, the walls won't disappear anymore. Which, as I recall, is how it worked before all this mess. The only problem then was that Chocolate Doom won't run the map.

I think if I can't have Chocolate Doom support, but my map will work in any OpenGL port (thus far tested in Risen3D and Doomsday), then I'm happy enough with that.

Vermil said:

...It seems that either DB or Dday's node builder has a highly obscure glitch on maps with certain geometry, if it has no things on it other than a player start. This leads to a single invisible wall in a single sector that the player can see at map start up.


I was able to confirm your theory. I opened the version of my map with just a player 1 start and the rocket item, deleted the rocket in that other sector, added several ammo items and a couple shotguns to Sector 0/1 (where the walls disappear), and tested the map -- no errors whatsoever, and the walls work fine. So strange.

At least we sort of know now part of what lead to it happening. And you're right, as long as I keep items in that sector, everything is fine anyhow. The only mystery left is what broke vanilla/chocolate compatibility.

Share this post


Link to post
Subatomic said:

If Doomsday has a software mode.


Just to answer this. Dday has a software renderer. You enable it with the command line option "-allowsoftware". Naturally though, this isn't advised unless you have a super computer or something :p

The issue doesn't seem to be a blatent mapping mistake (though it probably is a mapping mistake somewhere, just not an obvious one). All sectors seem to be correctly closed and such, so I doubt a software based port will show anything a GL port won't in this case.

Share this post


Link to post
Vermil said:

Just to answer this. Dday has a software renderer. You enable it with the command line option "-allowsoftware". Naturally though, this isn't advised unless you have a super computer or something :p

The issue doesn't seem to be a blatent mapping mistake (though it probably is a mapping mistake somewhere, just not an obvious one). All sectors seem to be correctly closed and such, so I doubt a software based port will show anything a GL port won't in this case.


Well, in DB and in Doomsday there are no errors. So if my map will work with OpenGL ports only, that's fine with me. I tried adding "-allowsoftware" to the commandline, nothing happened. Still ran in OpenGL. Why would a software renderer require a "super computer"?

Share this post


Link to post

Hmm... the mystery continues. It seems that the incompatibility, for the most part, is actually a bug with Chocolate Doom. I've tested the map now in the Eternity engine, and the map works perfectly. Correct me if I'm wrong on this--Eternity is supposed to be like "vanilla" Doom, right? If so, then the map seems to work both with software and OpenGL rendering. For some reason Chocolate Doom just doesn't like it.

Share this post


Link to post

Eternity is actually quite far advanced compared to vanilla. Chocolate Doom and the original vanilla exe's have many hard limits, and maps that try to exceed those limits will crash the game. Do you have more than 64 scroll-texture-left lines in the level? Are there more than 30 moving floors when the level starts? Does the level start show an area that is very visually complex (ie. would break the 256 visplane limit - read about that in the Doom wiki if you want to learn more)? Does the level sprawl over a very large area (ie. does it break the BLOCKMAP size limit - again, check the wiki)?

Share this post


Link to post
Creaphis said:

Do you have more than 64 scroll-texture-left lines in the level?


This seems the most likely of everything you listed. I do in fact have a rather large sector with many linedefs that use the scrolling texture. I'll disable that and see if it fixes vanilla/chocolate compatibility.

Thanks for the tips!

Share this post


Link to post
Vermil said:

Indeed, it would. The map has 74...


Holy cow! Well, that solves that mystery. That was indeed the problem. Disabled all the scrolling textures, the map plays just fine in Chocolate Doom again.

Many thanks to everyone here who replied to help. You guys rock.

Share this post


Link to post

Subatomic said:
And yet, it gets even stranger still. In Doom Builder, when the rocket remains undeleted, and you press W for 3D edit mode... your view is from the rocket! Not the player 1 start position in Sector 0... but from the rocket in Sector 157. WTF. Again I must ask, How the heck is this even possible?

In another build of that map 3D mode started at a teleport destination - probably because it was "Thing 0".

Share this post


Link to post
Creaphis said:

I do enjoy a good mystery, but I've read this one before.


GASP! A topic has been discussed once before. The horror, the horror! Seriously though, that's fine and dandy if you knew what the problem was to begin with. If you'd actually read this thread, you'd know that I had absolutely no idea what was causing the problems we talked about. How exactly would one confront a problem like "my-camera-start-point-is-a-rocket-and-when-I-delete-it-walls-go-bye-bye" and leap to the conclusion, "ah yes, clearly this must be a simple overuse of the scrolling texture linedef."

Share this post


Link to post
GreyGhost said:

In another build of that map 3D mode started at a teleport destination - probably because it was "Thing 0".


Yes, I've noticed that as well. Is there any way of assigning it a different number? A way to make it so Player 1 is "Thing 0," for example.

Share this post


Link to post

Make sure it's the first thing you put in your map. The thing number of something depends on the order it was placed in the map. I don't think any editor has the ability to change this manually. Since things are stored in a list, you can't have multiple things having the same thing number. That would just be bad...

How exactly would one confront a problem like "my-camera-start-point-is-a-rocket-and-when-I-delete-it-walls-go-bye-bye" and leap to the conclusion, "ah yes, clearly this must be a simple overuse of the scrolling texture linedef."


Go figure. :P

Share this post


Link to post
Subatomic said:

GASP! A topic has been discussed once before. The horror, the horror! Seriously though, that's fine and dandy if you knew what the problem was to begin with. If you'd actually read this thread, you'd know that I had absolutely no idea what was causing the problems we talked about. How exactly would one confront a problem like "my-camera-start-point-is-a-rocket-and-when-I-delete-it-walls-go-bye-bye" and leap to the conclusion, "ah yes, clearly this must be a simple overuse of the scrolling texture linedef."


Um, I wasn't saying that you should have known about this error - I just linked to that old thread because I thought it was amusing that this error has shown up twice and it was me who spotted it each time. But sure, you can get really offended if you want to. Whatever.

Share this post


Link to post
Creaphis said:

Um, I wasn't saying that you should have known about this error - I just linked to that old thread because I thought it was amusing that this error has shown up twice and it was me who spotted it each time. But sure, you can get really offended if you want to. Whatever.


I wasn't really offended per se, but I do seem to have misunderstood you. For that, I apologize.

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  
×