[not a bug]DEHACKED strings problem?

[Enjay]

I was just playing through my own "NJThief" level (link below) when I noticed some of the messages that had been changed via dehacked were coming up as the original messages. The first one I noticed was right on the first lock. If you try it without the required key you get told "you need a blue card to activate this object". However, you should be told "You need the gatekeeper's key to activate this lock".

It works in all recent versions of Zdoom (unofficial and official) but not in GZDoom. I also noticed other locks that had the wrong message, but one was OK. All other dehacked work (what little there was of it) seemed to be OK. I've used far more extensive dehacked patches and even dehsupp lumps too with GZDoom and they've all been fine. This is the first dehacked related problem I've found.

The level is here.

http://www.doomworld.com/idgames/index.php?id=11107

For info, here is the dehacked strings section:

Code: Select all

[STRINGS]
GOTBLUECARD = Picked up the Gatekeeper's key.
GOTYELWCARD = Picked up the cook's key.
GOTREDCARD  = Picked up the gardener's key.
GOTBLUESKUL = Picked up the ceremonial key.
GOTYELWSKUL = Picked up the master's key.
GOTREDSKUL = Picked up the security key.
PD_BLUEO = You need the gatekeeper's key to activate this lock
PD_REDO = You need the gardener's key to activate this lock
PD_YELLOWO = You need the cook's key to activate this lock
PD_BLUEK = You need the gate keeper's key
PD_REDK = You need the gardener's key
PD_YELLOWK = You need the cook's key
PD_BLUEC = You need the gatekeeper's key
PD_REDC = You need the gardener's key
PD_YELLOWC = You need the cook's key
PD_BLUES = You need the ceremonial key
PD_REDS  = You need the security key
PD_YELLOWS = You need the the master's key

I can't remember which line types I used (object or door?) but of all the locks in the map, only "the cook's key" message worked. All other keys were asked for by their doom names. All the pickup messages worked fine.

Heh, I also noticed how crappy my skybox is now that I can look all the way up.

[Graf Zahl]

That's because the 'you need a card/skull to activate this object' messages don't exist in the LANGUAGE lump. Boom just forgot them and ZDoom never changed that. So I have to substitute them with new messages that logically aren't replaced by DEHACKED.

Sorry that this breaks your WAD but the alternative - outputting incorrect messages in many more WADs seems much worse to me.

[Enjay]

Fair enough. Presumably then, these are handled internally with no alternative way to change the relevant strings?

What does Zdoom do that allows this to work?

Which particular line types does the non-supported message apply to? I'm assuming that type 13 (I think that's right - can't check ATM) doors use the door message, but what uses the "object" message? Scripts? Must be something else too because, from memory, the switches where I noticed the problem certainly weren't scripts.

[Graf Zahl]

You can change them. Just extract the LOCKDEFS lump from GZDOOM.WAD and change it.

The'object' message is used when opening a tagged Door_LockedRaise special or ACS_LockedExecute.


ZDoom just displays the 'door' message instead but due to the LOCKDEFS mechanism I was able to fix that problem.

[Enjay]

Ok, thanks for the info. LOCKDEFS changing it is in future then.

[Enjay]

Related to LOCKDEFS.

In Zdoom, the Heretic Blue, yellow and green keys worked exactly like the Doom blue, yellow and red cards if you spawned them into a Doom game. This included being able to unlock blue card only, yellow card only and red card only locks. What's more, when you picked one up, the status bar icon for the blue, yellow and red cards respectively would be used. This meant it was an easy job to recolour the KeyGreen item to be read and have all 3 Heretic keys behave exactly like the Doom keycards.

No problem, you'd think, because you should just be able to redefine the Doom lock types to use either the Doom key or the Heretic one. I tried this:

Code: Select all

Lock 1 Doom
{
	Any { RedCard KeyGreen }
	Message "$PD_REDC"
	RemoteMessage "You need a red card to activate this object"
	Mapcolor 255 0 0
}


Lock 2 Doom
{
	Any { BlueCard KeyBlue }
	Message "$PD_BLUEC"
	RemoteMessage "You need a blue card to activate this object"
	Mapcolor 0 0 255
}


Lock 3 Doom
{
	Any { YellowCard KeyYellow }
	Message "$PD_YELLOWC"
	RemoteMessage "You need a yellow card to activate this object"
	Mapcolor 255 255 0
}

It all seemed to work in game as far as the right keys opening the right locks was concerned, but doing this meant that the statusbar indicators were wrong. eg, picking up a Doom blue key card puts the yellow keycard indicator onto the status bar and picking up the yellow card shows the blue skull on the status bar.

Now, personally I'm not bothered because the built in definitions for the doom "any yellow" "any blue" and "any red" are fine by me and work just fine for my purposes (and LOCKDEFS leaves me much more flexibility too). However, I thought you might want to know as this seems like it's going wrong.

As an additional thing, I couldn't see anything obvious, it is possible to define what gets shown on the status bar/ hud when picking up keys? I assume althud is configurable via the ALTHUDCF lump - but what about other HUD modes? (In fact, althud seems OK anyway.) Again, not something that bothers me, but possibly useful (if it doesn't already exist)?

[Graf Zahl]

The keys that get displayed on the status bar are the first keys that are initialized. Normally a new LOCKDEF lump shouldn't override that because the one in GZDoom.wad takes precedence. It only gets changed if you specify ClearLocks first or replace the one in GZDoom.wad.
Adding the code you posted as a separate lump the status bar indicators work as before for me.

[Enjay]

Ah, right, I haven't tested this yet, but the problem will be the clearlocks thing. I extracted the entire LOCKDEFS, modified the appropriate lines and then loaded the entire thing from the command line, including the clearlocks instruction at the start. My bad, I should know from working with other lumps that's not the best way to go about these things.

[edit]Confirmed, that was the problem.[/edit]