Not sure if this is a bug or just the way it is, so here goes...
My LOCKDEFS lump seems to be confusing GZDB. When I try to make a line into a locked door, instead of showing the names of the keys, I just get Lock1, Lock2...
Normal:
With my lockdefs loaded
My LOCKDEFS redefines all of the locks, but they are basically very similar to the default Doom ones. The differences are that wherever RedCard, BlueCard, YellowCard, RedSkull, BlueSkull, YellowSkull is normally used NJRedCard, NJBlueCard, NJYellowCard, NJPinkCard, NJGreenCard, NJIOrangeCard are used as well. In addition, the Heretic Keys can also be picked up and these are functionally the same as the Doom key cards (with the green key acting in the same way as a RedCard).
So, all my LOCKDEFS does is redefine each lock type so that any key of the appropriate type (original, my version, Heretic version) should operate the lock. However, I think it might be the fact that every lock has multiple keys allocated to it that causes GZDB to not be able to cope.
Code snippet...
Code: Select all
CLEARLOCKS
Lock 1 Doom
{
Any { NJRedCard RedCard KeyGreen }
Message "This needs a Red key."
RemoteMessage "This needs a Red key."
Mapcolor 255 0 0
}
Lock 2 Doom
{
Any { NJBlueCard BlueCard KeyBlue }
Message "This needs a Blue key."
RemoteMessage "This needs a Blue key."
Mapcolor 0 0 255
}
Lock 3 Doom
{
Any { NJYellowCard YellowCard KeyYellow }
Message "This needs a Yellow key."
RemoteMessage "This needs a Yellow key."
Mapcolor 255 255 0
}
It all works in game but, as I said, it confuses GZDB. I note from the GZDB documentation that LOCKDEFS is used to get the information about locks/keys:
LOCKDEFS:
Lock definitions are loaded. The values are used to populate "keys" Game Configuration enum.
You can specify a lock title by adding "//$Title" special comment inside a lock's definition body.
I can use that last part (//$Title) to fix the issue. It works, so I no longer have a problem. However, I also note that the game cfg files also have entries for the key enums and these do not work to fix the issue.
So, I guess the short version is, is a LOCKDEF of the type I am talking about supposed to be parsed in a more friendly manner, or are things working as they should be?