Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
sparerib1968

Crash report, introduction

Recommended Posts

Hope this is the right place to report crashes and possible bugs. Details
follow below; hope it's enough. Will gladly provide snapshots, eternity.cfg,
etersavX.dsg, or whatever else may be needed.

TIA

Me:
New to Eternity Engine. Been using BOOM and PrBoom for several years.
Old-schooler, and quite comfortable at the DOS prompt. Know alot about
'puters, but not nearly enough to be satisfied.

Computer:
Brand new HP Pavilion dv8135nr Notebook. Windows XP Media Center Edition 2002
SP2 w/ all updates. Just breaking it in, and it rocks! (
http://h10025.www1.hp.com/ewfrf/wc/product?product=1818492&lc=en&cc=us&dlc=en&submit.y=0&submit.x=0&lang=en&cc=us
)

Eternity Engine:
ee3.33.02-win32

Conditions:
EE launched from the CMD box, passing absolute path to Ultimate DOOM's
DOOM.WAD from via pre-assigned env. variable. Played all the way through
Episode 1, no problems. Now playing Episode 2, but it crashes when I throw
this switch. The crash occurs every time I throw the switch, even after
reloading the game.

Location:
E2M7: Spawning Vats
X: 1040
Y: 749
Z: 192

Other odd behavior:
When using spacebar to search for secrets, the HUD changes erratically.
Hmm, can't seem to use my numeric keypad (darn!)

Session log:
C:\MyName\games\Doom\eternity>eternity -iwad %udoom%
The Eternity Engine
Copyright 2005 James Haley and Steven McGranahan
http://www.doomworld.com/eternity

This program is free software distributed under the terms of
the GNU General Public License. See the file "COPYING" for
full details. Commercial sale or distribution of this product
without its license, source code, and copyright notices is an
infringement of US and international copyright laws.


IWAD found: C:/MYNAME/GAMES/DOOM/DOOM_SE/DOOM.WAD
Ultimate DOOM version


Built on Oct 1 2005 at 10:27:12
M_LoadDefaults: Load system defaults.
V_Init: Allocate screens.
W_Init: Init WADfiles.
adding C:/MyName/games/Doom/eternity/eternity.wad
adding C:/MyName/GAMES/DOOM/DOOM_SE/DOOM.WAD

E_ProcessEDF: Loading root file C:/MyName/games/Doom/eternity/root.edf
C_Init: Init console.
V_InitMisc: Init miscellaneous video patches.
I_Init: Setting up machine state.
I_InitSound:
Configured audio device with 512 samples/slice.
I_InitMusic: Using SDL_mixer.
D_SetGraphicsMode: Set graphics mode
Fatal signal: Segmentation Fault (SDL Parachute Deployed)

Thanks for using the Eternity Engine.

Press any key to continue

Share this post


Link to post

>The crash occurs every time I throw the >switch, even after
>reloading the game.

>Location:
>E2M7: Spawning Vats
>X: 1040
>Y: 749
>Z: 192

I cannot replicate this in the current build, in fact, the game won't let me push this switch at all. It just acts dumb like there's nothing for it to do. Can anybody verify what this switch is supposed to do?

>When using spacebar to search for secrets, the HUD changes erratically.

The only idea I have for this is to check your keybindings. Make sure the hud toggle action is not bound to spacebar.

>Hmm, can't seem to use my numeric keypad (darn!)

This is a known issue and has to do with the antiquated keysym -> ASCII translation table brought over from DOS. We can't get rid of this thing yet, and until we do, we can't support keybinding for numpad keys.

Share this post


Link to post
Quasar said:

I cannot replicate this in the current build, in fact, the game won't let me push this switch at all. It just acts dumb like there's nothing for it to do. Can anybody verify what this switch is supposed to do?

It's a type 103 switch (S1 open door stay open). It opens the second door in the secret hallway in the start room.

The first door is opened by the switch in the red room at the bottom left of the map. This switch is also type 103. See if you can flip that one, or if it encounters a similar problem.

I believe there is a difference in the line flags. For some reason, DeePsea shows all the lines in the general area of that first switch room as having the flag "usethru" checked. In Boom, this flag means "usethru" and in Hexen it means "repeat". I don't even know if that's supposed to be an option in vanilla Doom. The hex for the lines checked "usethru" is fe01, whereas the flags for standard 1s impassible lines (like the second switch) is 0011.

[edit] I've done a quick skim through about half the other Ultimate Doom maps and never seen this "usethru" flag used again. It seems the original author might have somehow messed up the flags with an early editor or used a feature/setting which was later removed/changed. IIRC, Spawning Vats was the first map begun for Doom, and later revamped, so the latter option seems likely.

Share this post


Link to post

Thanks. This line has all the high-order bits set:

1111111000000001

This is activating Eternity's 3DMidTex switch feature, which doesn't work on one-sided lines. This is a big-time problem for compatibility, and this problem may yet bite other ports. Unfortunately, bit #9 "reserved" with value 256 is NOT set on this line, so Lee Killough's code to fix Hellmaker wads is letting this little gem pass right on through.

EDIT: The reserved flag is only for things, not lines. I have to now waste a bit of the linedef flags field to implement a similar system :/

Share this post


Link to post

ee3.33.02-win32 continually crashes every time I push the switch.

I tested Ultimate Doom e2m7 in prboom v2.2.6 (built Oct 7 2004) and played all the way through with no trouble. Even got 100% monsters/items/secrets.

The switch in question opens the secret door at X:1506 Y:1904 Z:72

HTH

Share this post


Link to post

It's bad flagging by the original map author.

There were high-order bits checked which didn't exist in doom.exe so they didn't matter. It works in most boom-based ports because only the new "usethru" high-order bit gets added when the bad flags are applied. Eternity adds another high-order bit "3dMidTex" which allows mid-textures to be solid and walkable, making those 3D bridges easy to use. But of course, that flag isn't compatible with 1-sided lines, so that results in the crash in 3.33.02. The crash has been fixed in the latest version, but the two flags are still incompatible, so Q's having some fun coming up with a workaround now :D

Share this post


Link to post

I checked my settings in ee3.33.02-win32, and 'Toggle HUD' is mapped to 'F5'. When using spacebar to search for secrets the HUD layout will change unpredictably. I'm not sure about this, but it seems to happen when I'm simultaneously holding the shift (run) key down while pressing spacebar (action). Like I said, the behavior is erratic, and unpredictable.

To be fair, prboom v2.2.6 (built Oct 7 2004) seems to exhibit the exact same behavior. I checked this today.

My computer is HP Pavilion dv8135nr notebook, and my OS is Windows XP Media Center Edition.

About the switch problem, should I anticipate a fix in the near future?

Since I've never done any mapping for Doom, I don't completely understand your explaination. I got that there are some flag bits set wrongly in the DOOM.WAD, and that this bug was never noticed until now because DOOM.EXE ignores these bits. Eternity uses these bits for a feature which is incompatible in the context of this switch, right?

Share this post


Link to post
sparerib1968 said:

About the switch problem, should I anticipate a fix in the near future?

Yeah I think Q had finished a fix last night, but I was going to bed and didn't find out for sure.

sparerib1968 said:

Since I've never done any mapping for Doom, I don't completely understand your explaination. I got that there are some flag bits set wrongly in the DOOM.WAD, and that this bug was never noticed until now because DOOM.EXE ignores these bits. Eternity uses these bits for a feature which is incompatible in the context of this switch, right?

Well, I'm not a coder, but basically: flags are properties that each line can have checked. Standard ones are impassible, block sound, block monster, two-sided, display as secret (solid red on automap), don't display at all (invisible on automap), display automatically (shows on automap when starting a level), and upper or lower unpeg (for texture attachments/alignments). If you looked at the line's raw data that Q posted above, it's a series of 1's and 0's to tell which flags are enabled or disabled. The flag data format allows for more than just these default flags though, so when ports like Boom and Eternity add more flags, they don't restructure the current flagging setup, they just use more of what's already available (you'll see there's 16 digits available, but only 9 default flags). In 99% of cases, these extra flags will be 0's because they weren't available to use in doom.exe, but in the case of the map in question, a considerable portion of them are 1's for some reason, so when a port like Boom uses the first extra flag for "usethru" and Eternity uses a second custom flag for 3DMidTex, they become enabled. As another example, if Zdoom had decided to make the second custom flag "scroll texture vertically", this map would have a bunch of scrolling walls that aren't supposed to be scrolling. The ideal fix would be a proper patch from id, but since that's not going to happen, the source ports will have to come up with their own workarounds.

Share this post


Link to post

It's amazing this never came up before. DAMN YOU TOM HALL!

Share this post


Link to post

Use3D said:
DAMN YOU TOM HALL!

Yeah, no wonder they fired him!

Share this post


Link to post

I can code a bit, just not very well ;)

If DOOM.WAD e2m7: spawning vats is the only level that has this 'bug', then it may be possible to add a check for this specific level. Such a check may not be a graceful solution, but might be simplest.

If there are many other leves with the same 'bug', then I suppose all source ports should make allowance for the possibility of the aforementioned flags being mistakenly set.

It seems very unlikely that _no one_ noticed this problem before. After thousands of doomers and tens of years, someone must have noticed this.

On the other hand, no one is perfect (except my Dad.)

Share this post


Link to post

I noticed another (related?) map issue in E2M7 a while ago: Linedef 1125 has the somewhat unusual type of "-1" (it's the only level where I have noticed such a thing). Pressing on this also causes Eternity to crash. In Doom.exe and Prboom-plus, pressing on it has no effect; the only difference is that there is no sound made (like there normally is if you try to use a wall that can't be used).

Interestingly, the switch in question works OK during the playback of vanilla demos in Eternity (e.g. e2m7-344.lmp). This is perhaps one reason why the problem hasn't been noticed.

BTW, I tested all the compet-n demos on E2M7 with the latest Prboom-plus, and they all played back OK, so it doesn't seem to be causing any fatal problems there, at least in the vanilla complevel.

Share this post


Link to post

Interesting find, though I had a look at the line special in DeePsea and it's shown to be 65535 rather than -1.

If that makes any difference at all.

If it's even right.

sparerib1968 said:

If DOOM.WAD e2m7: spawning vats is the only level that has this 'bug', then it may be possible to add a check for this specific level. Such a check may not be a graceful solution, but might be simplest.

It's the only one with this particular setting, but IIRC Quasar found different odd flag combinations in a few other maps, and there's the Hellmaker problem which does the exact same issues, so this thread was started for that reason.

sparerib1968 said:

It seems very unlikely that _no one_ noticed this problem before. After thousands of doomers and tens of years, someone must have noticed this.

It's not very surprising. There was basically no reason for it to be noticed until now. AFAIK Eternity was the first port to add a function that would enable the erroneous flagging.

Share this post


Link to post
Lüt said:

Interesting find, though I had a look at the line special in DeePsea and it's shown to be 65535 rather than -1.

I presume that's the same Hex/binary number being represented in two different decimal forms (65536 - 1 = 65535).

Lüt said:

It's not very surprising. There was basically no reason for it to be noticed until now. AFAIK Eternity was the first port to add a function that would enable the erroneous flagging.

Except it does suggest that no one has played E2M7 in one of the Eternity versions with this problem - or if they have, they didn't bother with this switch, or else they didn't report the crash.

Share this post


Link to post

This line with a -1 line special is very likely crashing for the same reason as any other switch -- it has the 3DMidTex line flag set on it. All 1S switches with the 3DMidTex line flag would cause the game to crash when pressed in v3.33.02. This is because we somehow missed checking to make sure the 2nd sidedef existed before using it (DOOM itself contained a ton of errors of this exact nature, including the infamous venetian blinds crash caused by trying to open a 1S DR door).

Share this post


Link to post

Thank you to Quasar and all for your attetntion on these issues. I'll keep watching the Doomworld forums. I'll also be waiting for the day I can use my numeric keypad.

Best of luck in your efforts :)

Share this post


Link to post
Guest
This topic is now closed to further replies.
×