Edited level names with dehacked not working on Chocolate Doom

hello everybody, I'm working on a doom2 megawad and I'm using the old method with dehacked to change the level names on the automap for vanilla wads.

Eg:
Text 17 20
level 1: entrywaylevel 1: not working

This works flawlessly on prboom but not on chocolate doom, I've used the same method with my doom1 episode replacements and it worked fine!

I wouldn't say that your Doom 1 episodes are really Choco-friendly in this regard. In both cases I had to extract the patch from the wad and shorten the text lines.

Da Werecat said:

I wouldn't say that your Doom 1 episodes are really Choco-friendly in this regard. In both cases I had to extract the patch from the wad and shorten the text lines.

Yeah, I know that the patches crash the game but I don't know why since the same procedure with my new doom2 wad works fine on chocolate, about the text lines I didn't have any problems. If you have any suggestions tell me :)
EDIT: I think this should be really easy to fix and I must be making some amateurish kind of stupid mistake.

for map01, "Text 17 20" - 20 is too many characters, if you change 20 to 19 it works in choco

I think you could try WhackEd. It won't let you enter more characters than certain string can contain.

TimeOfDeath said:

for map01, "Text 17 20" - 20 is too many characters, if you change 20 to 19 it works in choco

Da Werecat said:

I think you could try WhackEd. It won't let you enter more characters than certain string can contain.

Thanks for the feedback, I've tried both ways and still it's not working on chocolate, no matter how short I make the text, the game shows the original instead. I checked my chocolate .bat file and I'm loading the correct files, other general changes in the wad are shown ;).

Strange. Your code worked for me. At least when I changed the second number. Choco was refusing to launch otherwise. The level name was cut off, of course, but it was replaced.

Are you using DOOM2.WAD? Not TNT.WAD, for example?

hmm, this worked for me in chocodoom 1.6.0 with -deh command:

chocolate-doom -deh deh.deh

Patch File for DeHackEd v3.0
# Created with WhackEd2 0.60 build 214

# General version information
Doom version = 21
Patch format = 6


Text 17 19
level 1: entrywaylevel 1: not working

TimeOfDeath said:

hmm, this worked for me in chocodoom 1.6.0 with -deh command:

chocolate-doom -deh deh.deh

Patch File for DeHackEd v3.0
# Created with WhackEd2 0.60 build 214

# General version information
Doom version = 21
Patch format = 6


Text 17 19
level 1: entrywaylevel 1: not working

that worked for me too, but when I put the deh.deh file into the pwad (I'm using xwe for that) chocolate seems to ignore it.

Chocolate Doom cannot load DEHACKED patches from inside PWADs.

"Text 17 19" worked?! So the character limit is a lie?

Sometimes you have a few extra characters.

Memfis said:

"Text 17 19" worked?!

Yes

Memfis said:

So the character limit is a lie?

No. Minimum length for map17 name length is 16 characters and maximum is 19. Dehacked.exe gives you this information when you start to edit text entries.

Dehacked patches being loadable from within Pwads is a feature of source ports.

In Vanilla Doom, you had to run the external Dehacked patch through a program that makes a new Doom.exe.

Chocolate Doom, being faithful to Vanilla Doom only reads external Dehacked patches with the -deh command line option.

Da Werecat said:

Chocolate Doom cannot load DEHACKED patches from inside PWADs.

I'm done! thanks everybody. My wad will come with a deh.file for chocolate doom fans. I'm still wandering why my WILVXX patches make favillesco to crash and on the other hand the CWILVXX patches of my new wad work fine.

Original DeHacked wrote over the strings in the binary, so the new string could not be longer than the original string. Source ports removed that limitation by allocating new space for the new strings.
Chocolate Doom likes to keep the old limitations.

There is also the limitation of only one DeHacked replacement of a string, caused by searching for the string text. Once another PWAD replaced the string, later DEH patches could no longer find it.
That has been fixed in many source ports too.

I've never looked into doom.exe, so maybe there's some reason why it's not practical, but as a ROM hacker it seems like allowing longer text strings should have been trivial to implement in Dehacked.

Dragonsbrethren said:

I've never looked into doom.exe, so maybe there's some reason why it's not practical, but as a ROM hacker it seems like allowing longer text strings should have been trivial to implement in Dehacked.

It's not.

Dragonsbrethren said:

I've never looked into doom.exe, so maybe there's some reason why it's not practical, but as a ROM hacker it seems like allowing longer text strings should have been trivial to implement in Dehacked.

Is this actually that trivial for ROMs? I thought you had to stay within the allotted space for strings unless you wanted to get fancy (extra jump instructions, two characters in one byte, decompiling etc.) I know a lot of 8- and 16-bit games had sub-par English to Japanese translations in part because the translators has such limited space to work with.

Anyhow DeHackEd was just a system for replacing binary data, which meant you only had so much space to work with for any kind of edits.

nicolas monti said:

I'm still wandering why my WILVXX patches make favillesco to crash and on the other hand the CWILVXX patches of my new wad work fine.

The width of one or two map names might be an issue, especially WILV05 "Atmospheric Processor" at 295 pixels.

plums said:

Is this actually that trivial for ROMs? I thought you had to stay within the allotted space for strings unless you wanted to get fancy (extra jump instructions, two characters in one byte, decompiling etc.) I know a lot of 8- and 16-bit games had sub-par English to Japanese translations in part because the translators has such limited space to work with.

Anyhow DeHackEd was just a system for replacing binary data, which meant you only had so much space to work with for any kind of edits.

I guess it depends on your definition of trivial. Expanding strings comes up a lot in hacking for translations, so it's considered one of the basics. Older console games (NES and SNES; I imagine all of the 8 and 16-bit platforms would be similar) typically have a tables of pointers to strings that are in the same program bank as the table. If you have space in that bank, it's simple to expand. If you don't, you have to implement the things you mention, or rewrite the code that loads strings so it can load from multiple banks. That falls under decompiling, but with the excellent utilities and debugging emulators available it's actually not very hard, outside of games that handle things oddly. If the pointers aren't in a nice table, it's usually possible to find them with the string offset alone, without the need to decompile (but again the code more often than not will not account for the bank the string is in). JRPGs also often use fixed-length strings for things like inventory item names, so those require either simply changing the string length or completely rewriting the name loading subroutine(s), depending on how efficient you want to be, in addition to making sure the menus or whatever actually display the longer names, and that's definitely falling into non-trivial territory.

Typically the reason translations suffered wasn't because it was difficult to expand the scripts, but because publishers were unwilling to use larger ROMs. The bigger the ROM, the more expensive to produce, so the translators were forced to cram their scripts into the same space that the original Japanese script used, often having to make significant cuts on top of implementing the techniques you mention. SNES fan translations almost always expand the ROM; it's less common with NES games because it's not nearly as easy, and because the maximum program size is decided by the MMC chip in the cartridge. (One of the Final Fantasy III translations actually increases the PRG size to 1MB, but the MMC3 board the game is on doesn't actually support anything higher than 512KB, so that translation won't work in accurate emualtors.)

If Quasar says it's non-trivial in Doom than it's non-trivial, though. He's the expert here, like I said I never looked into doom.exe, or any PC game for that matter. The only hacks I've done to PC games are things that were already documented, and that doesn't really count.

Edit: Blaming costs alone for the poor quality of most translations in that era is probably simplifying things a bit too much. There were definitely other issues, and I'm hardly an expert on that. I just know that it was very rare for the translated version of a game to use larger ROMs than the Japanese version, and costs are cited as the reason for that.

Thanks for that explanation, I'm familiar with the basics of ROM hacking etc., but not at that level. Forgetting about fixed chip sizes and ROM costs was a silly oversight on my part, though.

As a random interjection, I've found from experience that it's folly to try and edit DEH text strings outside of DeHackEd/WHackEd. It just doesn't work how you expect it would.

Not sure if that's what Nicolas did, of course. Just pointing it out for posterity. :P