Fixes for map crashes in EDuke32
#1 Posted 05 May 2013 - 07:53 AM
I just tried to play through "Alien Invasion" (by Fred Hero), but when trying to load E2L6, EDuke32 (r3727) gives me this error:
Subway found no zero'd sectors with locators
at (30976,21248).
It seems to be a glitch with the shuttle at the very beginning of the level which works similar to E2L2 in the original game. Since I have no clue about map editing, maybe someone can take a look and possibly fix this? Would be much appreciated!
(Presumably) bugged map is attached.
This post has been edited by NightFright: 20 May 2013 - 01:47 PM
#3 Posted 05 May 2013 - 12:52 PM
This post has been edited by NightFright: 05 May 2013 - 12:55 PM
#4 Posted 05 May 2013 - 03:30 PM
#5 Posted 05 May 2013 - 06:36 PM
#6 Posted 05 May 2013 - 11:47 PM
So far, there was at least one map where I had to use cheats in order to continue, which was E2L1 ("Mission Impossible"). I couldn't find the switch to open up the sewer section. Maybe it was there and I just didn't see it (can happen with some mods), but it could also be that it really was forgotten (or just doesn't work with EDuke32). There is a valve panel in a circular section with a pool of slime in its center. I assume you would have to press it to open the section beyond or so, but I had to use clipping cheat. Maybe someone else is smarter than me, or otherwise something in this map is also broken.
In other levels, such as E2L5 "U96", keycards are almost perversely well hidden (blue keycard, cough cough), but well, if it's about the whole map crashing, it has nothing to do with level design.
BTW: In general, this mod, even though it's quite simplistic regarding level design, is surprisingly entertaining. In case no other errors are found until I am done with it, I will upload the fixed version over at Duke4.net (or give it to someone who can do it).
This post has been edited by NightFright: 05 May 2013 - 11:52 PM
#7 Posted 06 May 2013 - 01:14 AM
#8 Posted 20 May 2013 - 01:47 PM
Error message from eduke32.log:
Fatal Signal caught: SIGSEGV. Bailing out.
current actor: 299 (842)
g_errorLineNum: 2509, g_tw: 4
Any way to fix it?
And a side question:
Screenshot below is from E3L2 (not E3L3, my bad) of the same pack. This is a texture misalignment in the map or a rendering issue with EDuke32?
This post has been edited by NightFright: 21 May 2013 - 10:50 AM
#9 Posted 21 May 2013 - 09:52 AM
NightFright, on 20 May 2013 - 01:47 PM, said:
I can't reproduce the crash. The map is structurally OK, and the custom CON code is relatively simple, so it shouldn't give any trouble.
Quote
First, attempt to narrow down the suspected cause. Are you running a vanilla setup?, which renderer, etc...
Quote
Screenshot below is from E3L3 of the same pack. This is a texture misalignment in the map or a rendering issue with EDuke32?
What is the map? (It's not E3L3.) What are the coordinates?
#10 Posted 21 May 2013 - 11:04 AM
My EDuke32 setup:
- EDuke32 build: r3798
- Polymer, 1920x1200, 32bit
- System: Win7 Ultimate x64, 12 GB RAM, Nvidia GF GTX 670 (Forceware driver v314.22)
From my settings.cfg (everything besides key bindings):
osdeditpal "12" osdtextpal "12" osdtextshade "2" r_swapinterval "1" r_texcache "0" r_textureanisotropy "16" r_texturemode "4" hud_stats "1" hud_textscale "200" in_mousesmoothing "0" mus_volume "255" r_ambientlight "4.000000" sensitivity "9.000000" skill "1" snd_fxvolume "135" snd_numvoices "64"
From eduke32.log, only relevant sections:
[Setup] ConfigVersion = 276 ForceSetup = 1 NoAutoLoad = 1 SelectedGRP = "stevepak.grp" ModDir = "/" [Screen Setup] Polymer = 1 ScreenBPP = 32 ScreenHeight = 1200 ScreenMode = 1 ScreenWidth = 1920 WindowPositioning = 0 WindowPosX = 0 WindowPosY = 0 MaxRefreshFreq = 60 Out = 0 Password = ""
---------------------------------------------------------------
About the graphics/texture distortions:
You are right, it wasn't E3L3, but E3L2. My bad.
A similar distortion I encountered in E1L3 already, at a wall which exploded. The building texture stretched all across the screen. Screenie from Mapster32 attached.
Distortion coords (as close as I could get):
E1L3: wall 1138 or 1233, x: -4865 y: 7425 ang: 784
E3L2: wall 2732 --> 2696, x: 7911 y: 29394
I hope this helps.
There were even more glitches like that in that pack, but the two I mentioned were the worst (so far, since I couldn't check beyond E3L3).
This post has been edited by NightFright: 21 May 2013 - 11:47 PM
#11 Posted 21 May 2013 - 11:58 AM
Attached File(s)
-
eduke32_or_mapster32.crash-1.log (2.58K)
Number of downloads: 237 -
eduke32-1.log (1.84K)
Number of downloads: 223 -
eduke32_or_mapster32.crash-2.log (2.28K)
Number of downloads: 239 -
eduke32-2.log (1.75K)
Number of downloads: 224
#12 Posted 22 May 2013 - 07:59 AM
NightFright, on 21 May 2013 - 11:04 AM, said:
You are right, it wasn't E3L3, but E3L2. My bad.
A similar distortion I encountered in E1L3 already, at a wall which exploded. The building texture stretched all across the screen. Screenie from Mapster32 attached.
Distortion coords (as close as I could get):
E1L3: wall 1138 or 1233, x: -4865 y: 7425 ang: 784
E3L2: wall 2732 --> 2696, x: 7911 y: 29394
Well, these two maps on the other hand are very corrupt. Issuing "corruptcheck tryfix ??" in Mapster32 lowers the corruption level to level 3 and no corruption, respectively. This should be done from 2D mode, since Polymer invokes undefined behavior when attempting to draw the offending map portion. Currently, Polymer is the renderer that is most sensitive to map corruptions, so there's a good reason for keeping them clean.
#13 Posted 22 May 2013 - 08:16 AM
Helixhorned, on 22 May 2013 - 07:59 AM, said:
Maybe this should be done with all of these maps. xD But I am not sure if that will fix the crash in E3L4, however. :/
#14 Posted 22 May 2013 - 08:30 AM
LeoD, on 21 May 2013 - 11:58 AM, said:
NightFright, on 22 May 2013 - 08:16 AM, said:
It was a Polymer bug
#15 Posted 22 May 2013 - 12:45 PM
I have tried to fix E1L3 with the Mapster32 command, but I think it does not work. When doing that, that wall won't blow open at all any more, so it's even worse. I think this would need to be fixed manually.
#16 Posted 22 May 2013 - 12:56 PM
NightFright, on 22 May 2013 - 12:45 PM, said:
You're right, that place around E1L3's wall 1222 is pretty messed up! Try moving some walls there and you'll notice that they're not connected as they should be. I will take a look at it since there's a prospect of discovering new types of how a map can be broken. Yum!
In general, yes, "corruptcheck tryfix" does safe transformations, but manual intervention may be necessary to restore the map to what the mapper intended.
#17 Posted 22 May 2013 - 01:19 PM
The worst thing with that crappy wall is that it will stay like that even after blowing it up... Means you don't even see what's behind before you actually jump into the skybox. xD The whole pack has many of these "anomalies", but nowhere is it as bad as there (and E3L2 maybe). Problem here is that a keycard or something you need to finish the level lies beyond, so it would be good to have it working, even if it's rather a visual (even though massive) glitch. If both maps got fixed regarding those two walls, it would already be more than you could ask for.
---------------------------------------------------
Some of Steve's episode 3 maps are fine examples for messy mapping, apparently even with one showstopper:
E3L5:
- First, you see some automated doors with space beyond (e3l5_spacedoor1). You think: "No way to get past that." But if you enter the door anyway, you see there's a normal room behind it (e3l5_spacedoor2). If you turn around, you see the mess in all its glory from the other side (e3l5_spacedoor3).
- Before the exit, it gets even more fun: There is a ramp into space (e3l5_ramp1). If you go on, in 9 of 10 cases you will get crushed when trying to enter the teleport tube (e3l5_ramp2). Only with a lot of luck and patience, you can make it (and you have to, because otherwise you cannot finish the level).
E3L6:
-
- If you make it past that and enter the garden mini maze beyond, jumping on the hedges will get you stuck, you cannot jump down again (maybe the author never meant you to be able to get on top of them, but well, you can).
E3L8:
- When exiting the sewers and entering the streets at the beginning of the level, the floor of the main street is completely missing (steve_e3l8_streets1), and when you turn around the corner, a bit more (steve_e3l8_streets2).
- Later, when hunting for the keycards, a section is blowing up in some building and the floor is gone there, too (steve_e3l8_interior).
E3L11:
Rather minor issue with floor and ceiling missing in this control room (steve_e3l11).
I think making the whole pack work properly would be the job of a lifetime... xD But some of the maps are really cool considering their age, especially the three boot camp levels and the sunk, upside-down ship (all in ep.2). For these four levels alone, it's already worth playing the pack (and restoring it to a state where it's at least playable without in-your-face glitches/showstoppers).
---------------------------------------------------
It's remarkable in general how well EDuke32 still runs these bugged maps after all. This SIGSEGV error was the first during many hours of gameplay testing with quite old TCs back from the late 90s, the other crash happened due to a map error (see above). Other than that, besides a few visual glitches, no bigger issues. Another proof that it's a really good port. ^^
This post has been edited by NightFright: 03 June 2013 - 12:40 AM
#18 Posted 25 May 2013 - 08:14 AM
A better way of cleaning it up then would be to first issue "corruptcheck tryfix" until the map is not altered (yes, multiple passes can be necessary.) This way, Mapster32 will attempt to recreate the red-wall connections instead of whiting them out. Second, run "corruptcheck tryfix ??" to white out those ones where no match between two walls could be found. Note their numbers and correct manually when necessary.
Next, the remaining two-walled sectors should be cycled using Alt+[ or Alt+] and eliminated. Since they have zero area, multiple trials may be necessary to highlight them, but you'll notice a message in the status bar. A highlighted two-walled sector can only be deleted using LShift+Ctrl+DEL. However, this may introduce corruptions again under certain circumstances, so read the messages carefully. It definitely helps to know the BUILD map format, i.e. what the different sector and wall members are for.
This map pack seems like a good candidate to learn that workflow a bit. Have a lot of "fun"!
#19 Posted 25 May 2013 - 03:32 PM
Anyway, it seems I brought E1L3 down from 26 errors to 8, and checking ingame revealed the glitch is gone (see screenshot). I was able to finish the level without any major visual disturbance, which more or less means "mission accomplished". While I was at it, I properly aligned sprite #161 (graffiti) which was floating in the middle of a conveyor belt, not being aligned to the wall. Similar with sprite #223 (dipswitch2) which was not wall-aligned.
I will do this for some more maps of that pack where necessary. You will surely get the complete result as download once it has been thoroughly tested. Thank you very much for your help! ^^
This post has been edited by NightFright: 25 May 2013 - 03:40 PM
#20 Posted 08 April 2016 - 02:02 AM
Somebody reported an EDuke32 crash problem with Zaxxtor's "Oblivion" pack which I had included with the EDuke32 addon compilation. It affects E2L10 (Death Valley) and the error is the following according to the report:
Subway found no zero'd sectors with locators at (48896,52480).
Since this is very similar to the issue from "Alien Invasion", I was wondering if this is possible to be fixed as well. Find the (presumably) bugged original map in the attachment.
This post has been edited by NightFright: 08 April 2016 - 02:04 AM
#21 Posted 07 June 2016 - 02:14 AM
Any news on the issue above? It's the only map in the addon which doesn't work. Would be great if that got fixed since it's a showstopper. As far as I understood, Zaxtor uses a 2-way train in the beginning of the map which moves the wall away from the player (instead of moving the train section), giving the illusion of "departing" from the station (while you actually remain stationary).
I have identified the last working EDuke32 snapshot with which the level is loading properly: eduke32_win32_20121113-3158.
Changelog for r3161 which is the first broken build. My bet is the error was introduced with 3159.
I am not sure now if this is something that can be fixed/changed in the map or if the coding team needs to take a look to restore functionality in a future snapshot.
This post has been edited by NightFright: 07 June 2016 - 06:21 AM
#22 Posted 07 June 2016 - 12:46 PM
That said, I don't see how the sector effect ever worked unless Zaxtor does something to it in CON. The code for generating that error didn't change in that span.
The SE in question is sprite 2325, located in sector 0. The code checks all the walls of the sector containing the SE for one that meets these conditions:
1. The wall's nextsector >= 0
2. The nextsector's hitag = 0
3. The nextsector's lotag < 3
All the walls of sector 0 (walls #0 through #8) have sector 37 for a nextsector, and sector 37 has 0 for a hitag and 20 for a lotag. Even before the change from signed to unsigned, "20 < 3" would never be true.
Me confuse.
#23 Posted 07 June 2016 - 01:28 PM
EDIT: Looking at the map with a hex editor, the lotag is indeed 20.
EDIT 2:
prelevel(), premap.c:
switch (sector[i].lotag) { case ST_20_CEILING_DOOR: case ST_22_SPLITTING_DOOR: if (sector[i].floorz > sector[i].ceilingz) sector[i].lotag |= 32768; continue; }
As a signed value, this makes the lotag -32748. As an unsigned value, it makes it 32788.
A_Spawn(), game.c:
case ACTIVATORLOCKED__STATIC: case ACTIVATOR__STATIC: sp->cstat = (int16_t) 32768; if (sp->picnum == ACTIVATORLOCKED) sector[sp->sectnum].lotag |= 16384; changespritestat(i, STAT_ACTIVATOR); break;
-16364
Conclusion: Zaxtor got very lucky. That said, I don't know what the purpose of the lotag < 3 check is, so I would be in favor of relaxing it so that old maps that get lucky like this still work, without breaking anything.
This post has been edited by Hendricks266: 07 June 2016 - 01:45 PM
#24 Posted 07 June 2016 - 11:32 PM
Thanks a lot for the sophisticated analysis of the issue, Hendricks!
This post has been edited by NightFright: 07 June 2016 - 11:55 PM
#26 Posted 08 June 2016 - 11:22 PM
This post has been edited by NightFright: 08 June 2016 - 11:24 PM