Eduke bug in toxic dump with the second shrink room.

[deFaezer]

I'm running Duke Nukem 3D with retropie ports on a Raspberry pi 3 and there seems to be a bug in Eduke3d.

In level 4 ( toxic dump) with the second shrink room.
So in toxic dump after I get the red keycard the second room with the shrinker, the shrink wont shoot out to shrink duke so I cant get out of the room. It "hits" an invisible wall before it can hit me leaving me trapped.

i tried to install and updating from Binary and Source but that makes no difference.

I tried to extract level 4 from the grp file and move the shooter but that didn't help either.

I searched google and all I could find was this: https://steamcommunity.com/app/225140/discussions/0/1635291505036644837/

as a solution it is said that you can fix it by rolling back the version to 20190820-8043. That was the last version to not have this bug.

I have no idea how to do dat so it works with ports?
Is there anyone that can help me or have another solution for this problem?

[mitu]

Do you have a save from before this section ?
We have an older version of eduke32 in the ports (due to some bugs in subsequent versions), but if the bug is fixed in a later version/revision we can try and add the patch to your build.

[deFaezer]

@mitu
No I don't have a save from for this section?

What should I do to add the newer patch to my build?

Great that you help me👍

[mitu]

@defaezer said in Eduke bug in toxic dump with the second shrink room.:

What should I do to add the newer patch to my build?

There's no such patch at the moment, my idea is that if we had a save, I could test if a more recent version fixes the bug.

[deFaezer]

@mitu
By save do you mean a save of this level with the problem? I can make this for you give me a few hours.
where should i send the save to?

[mitu]

@defaezer said in Eduke bug in toxic dump with the second shrink room.:

By save do you mean a save of this level with the problem? I can make this for you give me a few hours.

Yes, a save before the issue happens, so I can test it. There's no rush, get it when you have the time/get to your Pi.

where should i send the save to?

Some file sharing service if you have an account on one (GDrive ?).

[deFaezer]

@mitu
https://drive.google.com/file/d/1Ll7Q2hFBWcGqAF4l6XtS-oK60ZUXdNrc/view?usp=sharing

[mitu]

Thanks for the saves, I'll give them a try. Please remove the archive.

[sleve_mcdichael]

Can confirm the bug, shrink ray splashes against the alcove and does not reach the player. This commit is supposed to fix it (haven't tested. Don't know how to make a patch.)

[deFaezer]

@sleve_mcdichael

Thanks, this link seems like a good place to start.

It seems that the file /home/pi/installEduke32/eduke32/source/duke3d/src/actors.cpp has changed quite a bit in two years.
is going to be a puzzle for me.

https://drive.google.com/file/d/1NckPDHazkyzPYArHz79fR9u9gNJyGcq5/view?usp=sharing

[deFaezer]

@sleve_mcdichael

update:

update /home/pi/installEduke32/eduke32/source/duke3d/src/actors.cpp is not part of retropie but something I added myself to try and overwrite the existing.....

My mistake!

[mitu]

@sleve_mcdichael said in Eduke bug in toxic dump with the second shrink room.:

This commit is supposed to fix it ...

Yes, it does fix the issue with the shrinker ray getting stuck

I've sent a patch to fix this, once merged you'll need to update your RetroPie-Setup script and re-install from source eduke32.

[sleve_mcdichael]

@mitu works, thanks. I downloaded the patch & script from your repo, and can now get back out of that second shrink room.

[deFaezer]

@mitu

So how can i fix this problem…, how to do this?

[sleve_mcdichael]

@defaezer @defaezer said in Eduke bug in toxic dump with the second shrink room.:

So how can i fix this problem…, how to do this?

The easy way is: wait until this pull request is merged, then update your RetroPie-Setup script, and reinstall (from source) eduke32.

(Aaand, it's merged. Ignore the following, just update your script & reinstall eduke.)

If you don't want to wait, download the patch and the updated script from mitu's repo.

Patch: https://raw.githubusercontent.com/cmitu/RetroPie-Setup/eduke32-bugfix/scriptmodules/ports/eduke32/0005-e1m4-shrinker-bug.patch. Put it in RetroPie-Setup/scriptmodules/ports/eduke32/.

Updated script: https://raw.githubusercontent.com/cmitu/RetroPie-Setup/eduke32-bugfix/scriptmodules/ports/eduke32.sh. Put it in RetroPie-Setup/scriptmodules/ports/, replacing the eduke32.sh that is already there.

Once those two files are in place, again you reinstall from source eduke32 from the setup script.

After it's installed, cd back into your RetroPie-Setup directory and do a git reset --hard to undo your changes, or else you won't be able to update the setup script in the future (you will get an error that your local changes would be overwritten and you need to commit or stash them first.)

(Edit: when you do the hard reset, it doesn't touch the patch because the repo doesn't know that it exists since it's not part of it. When the repo does get updated later and then attempts to add the patch, you might get the error again. Just delete it, either now or whenever it becomes an issue.)

[sleve_mcdichael]

@mitu @buzz reinstalling this reintroduced a minor bug that I had squashed previously in my own setup, in which the log file is saved to $HOME where it sticks out like a sore thumb. The log is saved to {cwd}, wherever that happens to be so all it needs is a pushd into the config dir in the emulator command, before the game is launched. This should fix it, I think:

https://github.com/RetroPie/RetroPie-Setup/pull/3473

[deFaezer]

@sleve_mcdichael, @mitu
You guys are amazing, thank you so much, and I'm not only happy that it works, but I've also learned something.

[sleve_mcdichael]

@sleve_mcdichael said in Eduke bug in toxic dump with the second shrink room.:

reinstalling this reintroduced a minor bug

@mitu it also re-downloaded the shareware game data, even though I had the registered version files in place already. But since my filenames are in ALL CAPS (extracted from the DOS disk), they weren't detected by the script.

Aside from just, fixing my own local files and forgetting about it, what's the best way to handle this? Is there any way to make the test [[ ! -f "$dest/duke3d.grp" ]] case-insensitive?

I know that in find and grep you can use the -i flag to ignore case, and how in test/[ you can compare strings with, for example ${var1,,} or ${var2^^}, but how can I do something similar but with filenames?

I suppose it could just be [[ ! -f "$dest/duke3d.grp" && ! -f "$dest/DUKE3D.GRP" ]], but this still wouldn't catch mixed-case like Duke3d.grp if someone had that, and I'm sure we don't want to test for all 2^(8)=256 combinations.

Or, would we be better off just rename-ing everything to lowercase first and adding that to the dependencies, as in wolf4sdl?

[mitu]

@sleve_mcdichael said in Eduke bug in toxic dump with the second shrink room.:

I suppose it could just be [[ ! -f "$dest/duke3d.grp" && ! -f "$dest/DUKE3D.GRP" ]], but this still wouldn't catch mixed-case like Duke3d.grp if someone had that, and I'm sure we don't want to test for all 2^(8)=256 combinations.

Sometimes it's just easier to rename the file. Steam and GOG releases have lowercase names for .grp files, so most of installations would be covered.