[ck3D]

Context: rotating sector 0 somewhere inside of sector 1024 (IIRC, maybe the other way around). Wall 0 is one of the boundary walls between the two.

Upon user action I am still trying to pin down (but seems to have to do with save/quit game/reload?), wall 0 might load way outside of map/corrupt, and from then on loading the room containing it will result in EDuke crash (tested with latest).

OG thread/post with log file and debug.map, can also share saves if needed: https://forums.duke4...161#entry387161

Still studying the map in case it's a map thing but the values and behavior make it seem like it's not.

[stillTodd]

I am no mapper, but I do QA and understand basic to medium C (including dabbling in Build). I can see if I can establish a pattern of recreatable behavior.

I'm used to the eduke32 version that comes with Dukeplus. Is that acceptable or should I use a newer/specific version?

Edit: I read more carefully, and if I'm reading with enough coffee present, it looks like things get funky with older versions of eduke32. As an aside, I feel like - on my slow system - for whatever reason the controls are not as responsive on newer versions than the one included with DP. I may be hallucinating that.

To explain: I'm keyboard only unless mouse required, and have a weird-ass method of play that involves a lot of jumping, autoaim and running backward while shooting, so I'm maybe a corner case in play style. As a result, keyboard control reaction time is paramount here.

[ck3D]

Thanks for offering to look into it; I just tried and confirmed my theory, it is saving, quitting game, then reloading the save that kills the map, including in newer EDukes.

Doesn't seem to break when reloading without quitting.

Can be achieved as soon as map start (in the non debug version) seeing as the problematic wall can be loaded from there.

[ck3D]

Some visual assistance:

Normal map state, stable before quit game:

Spoiler

Map state after save/quit game/reload (NOT just save/reload):

Spoiler

(Sector itself having moved away from position is normal)

Perhaps is wall 0's NEXTWALL that corrupts since that seems to be what shifts (in the case of this map I think it's wall 70, rest of surrounding nextwalls # essentially is random).

Spoiler

Sector 1024 is the main sector (parent), 0 is the island/child.

Will try to fix on the map side, there has to be something rudimentary that must be possible. But doesn't sound like desired behavior anyway? Especially seeing as it can do really weird things to player X/Y speed and rendering of textures altogether if the level is completed in the broken state (by avoiding loading the broken room).

[Aleks]

Have you tried just deleting this sector then re-making it, so that the wall/sector numbering would change? That could at least help in isolating whether the problem is with the specific numbers of sectors and wall or with something else about the geometry/effect.

[ck3D]

Yeah I just haven't done it yet But am hoping that or similar will fix it, I really don't think the map is at fault though, geo/effect is proper, point just snaps onto the cosmos like that upon Quit Game.

But one thing I forgot to specify is that map was started off a section that was cut and repurposed from a different one (that is, this specific room containing the sector) and then continued later, pretty sure literally cut and pasted and not just highlighted/newboard.mapped (or negative-highlighted/cut), but now wonder if there is any way that could have kept track of the position of wall 0 of the original map and for some reason now is trying to reload it from there. Really just trying to solve an almost pointless mystery (it does comprise 1 wall point).

[ck3D]

Aleks, on 15 May 2026 - 12:58 PM, said:

Have you tried just deleting this sector then re-making it, so that the wall/sector numbering would change? That could at least help in isolating whether the problem is with the specific numbers of sectors and wall or with something else about the geometry/effect.

Tested, not a map bug. Map 'fixed' like this still breaks upon reload after game break.

What I just observed though is, it only seems to happen in continuous play? For a split second testing loaded as user map was fine, I thought I had gotten it. But then testing as part of episode (DNSCOTTY507'ing there) and then quitting/reloading in that context still trips it up. The USER.CON used is a normal Atomic USER.CON just with basic level name, time and music swaps.

Rearranging sectnums rules sector 1024 out of the equation (or at least it seems, naively), container/parent sector post fix becomes something random in the 3000's.

Sector 0 is a different child one now (literally the next platform over; easy to observe the difference since it's larger), but numerically the problem, still.

Spoiler

Corrupts the same way, wall connected to wall 0 for some reason snaps onto infinity, and loading the room either crashes EDuke or makes it behave in strange loose ways. Important variables getting touched that shouldn't be, player speed, collision, textures.

Spoiler

Remember it is a rotating sector and so makes sense the ray draws in a different direction. Guess I could try changing the effect again (I've lost track of how many times I've done it already, it's minor work, just affects approach to level) and see if that can help the bug. Or keeping rearranging the sectors in hope I might land on a safe combo but TBH ugh. I'll land on a solution in my particular case anyway no doubt.

Wall can be dragged back from outer space by just clicking on it, here is its data after snapping it back (only way to access it again I've managed but also tried), probably useless but what do I know.

Spoiler

EDIT:

I think I've managed to fix it on the map side. Literally assumed something may be wrong with the map file encryption at some level and so just opened it in Mapster, exported all of it into new newboard.map, swapped the old version with this one instead in the episode folder and now save/quit/reload no longer corrupts it. So I have found the solution/mapper workaround in situations like this it seems (provided it's even likely to happen to somebody again). Root problem still mysterious but perhaps bound to forever remain as such (and repurposed as deliberate in-game meta five years from now).