Game freezes instantly upon loading map after changing text strings only

[hello_qiangan1]

Hello everyone,

I'm encountering a strange freeze issue with a map running on GZDoom (latest version / Delta Touch). I'm hoping someone can help me pinpoint the cause.

When I type `map prld07` in the console and press Enter, the game freezes instantly. The screen doesn't go black; it just hangs on the console input screen and the music stops. The engine does not generate any error log—the log file simply stops writing at the moment I execute the map command.

I only edited a few text strings inside an ACS script to translate English dialogue into Chinese. Specifically, I changed the string arguments inside `printfbd(s:"...")` statements.

- I did NOT modify any game logic, delay timings, or script structure.
- I did NOT add or remove any `delay()` or `while()` loops.
- The script originally worked fine with English text.

[Redneckerz]

It helps posting the wad with the error in check, and does it also occur on UZDoom?

[m8f]

I'm not sure if ACS supports anything besides ASCII. This post suggests that it doesn't. In this case, you should consider using LANGUAGE lump.

[hello_qiangan1]

It freezes up under any launcher, this is just a file link: https://www.dropbox.com/scl/fi/v118ko99 ... to5cq&dl=0

[Enjay]

I don't know if it's a failed upload, or if the problem is in your copy of the map too, but I have downloaded the file from DropBox and I can't get it to load in Slade, UDB or UZDoom. I'm not sure why though. I don't see anything obviously wrong when using a hex editor to take a quick look at it.

[Rachael]

I checked, and indeed the pointer to the central directory is corrupt.

My attempts to manually recover the data thus far have failed, but that .wad is never going to work in any tool as-is.

[Rachael]

I've had a little extra time to take a closer look at the .wad file - it's actually very corrupt. Whatever tool saved it last, fucked it up a lot.

The central data table was pointed to a negative space in the file, and the entries are the wrong size and also point to invalid places not within the file.

The data is certainly recoverable, but it would be a bit of a manual process, it's going to require someone with knowledge of the .wad format and being able to discern where each file ends and the next begins - and also has a bit of time to do some manual calculations, etc. It's not going to be an automatic process. If you have a backup I'd go back to it - otherwise if there's anything critical in here, you'll need to find someone who is willing to find some time and parse through this.

[simc]

Here, for some reason I couldn't get the scripts rebuild at first. Behavior and nodes are rebuilt.

https://www.dropbox.com/scl/fi/2w1q9x7w ... ce5x0&dl=1

[Enjay]

So, what is the problem now? I am able to load the map in UZDoom and GZDoom and run around. So, it seems like the original problem of freezing has gone - unless its something to do with one of the resources that aren't in the WAD file. I can see the scripts lump with strings in the messages that I can't read, but the file isn't causing a freeze.

[Rachael]

I think Simc took the extra time to try and actually fix the file - which is real nice of them.

It sounds like instead of fixing the archive itself, they simply rebuilt it using some of the resources within it using some of the text data that was already available and easy to grab.

[Enjay]

Oh, you're absolutely right. I thought it was OP posting a new version of the WAD.

It was late when I checked it. /excuse

That is a nice thing to do.Thanks simc.

[simc]

Sorry, I should have added the original version. Here:

https://www.dropbox.com/scl/fi/ayyftk0o ... 4oi8x&dl=1

The nodes were rebuilt because without it the map would not run.

Execution could not continue.
Failed to allocate memory from system heap

In UDB the SCRIPTS fail to compile because of the UFT-8 text. It has mac line endings so it might have been edited outside UDB.

The og wad had too many "ef bf bd" sequences around in both the start and end. When those were replaced with a single mark it looked better. But both the ENDMAP and the index start addresses pointed somewhere to the middle of the wad.