Duke4.net Forums: Tracking down WGR2 showstopper in EDuke32 - Duke4.net Forums

I have finally been able to find out when a certain map in WGRealms2: Siege Breaker stopped working.

The map causing problems is the third in the second episode, WGX5 ("Getting Back to Nature"):
You are in the final arena room where you have to defeat two floating mini Cyberdemons, six shotgun Barons and a Cyberdemon boss. Once all of them are dead, the door to the exit teleporter chamber is supposed to open. However, neither the door nor the teleporter tube open once you have defeated all enemies and received the "A door has activated" message. It's a showstopper and has been confirmed by several people, also some who tried to play the mod quite recently.

The bug is shown in this Youtube video (after 16:45).

I have tested this passage with various EDuke32 builds and found that the last working build was 20121113-3158. Any build after that (starting with 20121114-3161) turned out to get you stuck. The two activator/masterswitch sprites in WGX5 which are not triggering any more are #922 and #984 (both have a lotag of 53244).

Test setup:
- Download this WGR2 test setup compilation (zip, 55 MB), based on the version from the EDuke32 Addon Compilation (with .grp/.dat files decompressed since old EDuke32 builds did not support the grpinfo feature)
- Unzip wgrealms2 folder into your EDuke32 dir
- Launch game with "wgrealms2" as custom game content directory set via launcher
- Select WGX5TEST.map via user menu (contains WGX5.map with edited starting point that puts you right into the final arena chamber)
- Use cheats to beat mobs fast (recommended: dnkroy, dnstuff)
- After all monsters are dead: Check whether "A door has activated" message appears and the grey door behind the dead cyberdemon opens. The teleporter needs to open with a slight delay, too.

It would be great to have this mod working again with recent EDuke32 builds, so my question directed at the EDuke32 coding team would be whether it's possible to do anything about it. Thanks in advance!

r3159 is almost certainly the offending revision. That's the same one that caused the issue in Oblivion. I should really review all uses of less-than and greater-than on lotag and hitag in the source to weed out these issues entirely.

Could you test with r6581? I've attempted to resolve the issue with broad strokes.

I can confirm that WGX5 is working as intended once again with r6581. After more than five years, it's finally possible to play WGR2 again with a recent EDuke32 build! Thanks a lot! ^^

I would also like to check if this fixed potential Oblivion problems, but unfortunately I don't even know where exactly this mod used to have issues. Anyway, there's some chance they got fixed, too.

NightFright, on 15 January 2018 - 11:48 PM, said:

One of the issues with Oblivion was the Mudlelizer shrinking you indefinitely instead of making you invincible when you hit yourself

But I believe you guys had fixed it because of a small typo in the code but never quite included the fix officially so maybe it is another issue you're talking about >_>

I remember Hendricks already implemented a fix related to Oblivion, which was in r5775 (fixing an issue dating back to r3580). Maybe it was that already, tbh I don't remember what it was about. Anyway, it's great the issue could be addressed so quickly. I can recommend using r6581 or newer to be used with WGR2 in the compilation readme now. ^^

In general, the compilation has the pleasant side effect of at least occasionally rediscovering/remembering old issues and being able to drag them back into the spotlight.

I'm arriving late to the party here but it's good to see that the issue is apparently fixed. I'm actually glad that I was unaware of it, because it would have bothered me and I probably would have made a workaround CON hack instead of waiting.

Hendricks266, do you have any insight as to how this got broken?

Yes.

Quote

When a variable's value is changed from signed to unsigned or vice versa, the meaning of the less than and greater than comparison operations changes for values that are negative with a signed variable (implying they are also in the larger half of an unsigned variable's range). After this revision, certain checks pass or fail where they previously did the opposite. I restored the behavior to match the engine and game in its original state.

NightFright, on 15 January 2018 - 11:48 PM, said:

I remember there was some bug at beginning of one of the levels that killed you instantly and you had to fix this issue by editing the map. It had to do with a ceiling that would squish you, I think.