Fox, on 04 August 2012 - 05:51 AM, said:
I got an issue with a non-functioning SE in Eduke32. For some reason, the blue access card elevator in Spaceport map extracted from the Nintendo 64 ROM does not work, and it won't "teleport" you to the other point.
The map works fine with DOS version of Duke 3D. And if you copy the sectors on a new map it works just fine, meaning it has something to do with a superfluous component of the sector / wall structure (such as firstwall for example).
This is one of those wacky cases where the behavior depends on the particular order of sprite indices (the most famous example probably being the order in which the cameras are cycled each time you "use" a viewscreen). Here's what happens: the warping elevator SE in sector 3 needs to determine when it can teleport the player and sprites contained in it to its matching sector. This is the case when no "hole" is visible from it any more. But the fake ceiling door, sector 178, is immediately adjacent to it! If its spawn-time code executes
before the warp-elevator's one, the "door" will be closed and an engine function searching for the "next z step" fails. This is exactly what happens with the extracted map and EDuke32. Now, when you highlight the whole map from Mapster32 and copy it to a new one, currently the sprite index order is changed in general, and with this quasi-duplicated map, the SE17 runs first.
[*] So why does it work with the DOS or N64 version? I don't know for sure, but the two most natural possibilities are
- The order in which the two SEs run is reversed because of different order in which the code is run between EDuke32 and DOS/N64. I haven't compared the original DOS source with ours, but I'm leaning more to assume that they're functionally identical in this respect.
- That it works in DOS/N64 is coincidence. Currently, I have made EDuke32 terminate the the extracted level since, as noted above, the "find next z step" function fails, and moreover the resulting (invalid) sector index -1 was used to access the sector array, which is undefined behavior.
[*]Side note: I screwed up with copy-pasting. Before r2965, some sector and wall members which are used for TROR functionality would get reset, regardless of whether the source or destination map had any TROR. Now, the bug still persists if the portion to be duplicated contains TROR, but I think its fix has to wait until the new map format.