[94] ACS_LockedExecute key messages

[Chris]

I wouldn't say it's a bug. ACS_LockedExecute isn't limited to just doors, so if you apply it to, say, a computer terminal, it'd look weird if it said "door". Although I can see the card/skull part of the message coming back. If you need comething more specific than "object" use the CheckInventory in your script to show your message and return.

[Graf Zahl]

It should be fixed nevertheless - but completely! There should be 'object' messages for all the separate keys as well. As it is currently it is just wrong.

[Graf Zahl]

The key system I developed is fully customizable so it would only involve adding the Heretic key names to the lock definition so they continue to work.
As for the messages, they are defined within the lock itself so with a proper definition of all locks nothing would be messed up.

Here's an example (for compatibility this would have to be extended to read messages from the LANGUAGE lump by default):

Code: Select all

Lock 6
{
	YellowSkull
	Message "You need a yellow skull to open this door"
	RemoteMessage "You need a yellow skull to activate this object"
	Mapcolor 255 255 0
}

Lock 129
{
	Any { RedCard RedSkull }
	Message "You need a red key to open this door"
	RemoteMessage "You need a red key to activate this object"
	Mapcolor 255 0 0
}

Some explanation:

-The lock number is the number to be used in the line special.
-There is one 'door' message and one 'remote' message for each lock.
-The map color is for the automap (I never checked whether ZDoom supports colored doors on the map. PrBoom does.)
-If you specify a list of keys in Any{} you need one of them
-You can specify as many keys/groups as you want. If you do so you need every single key and one out of each group.

For your Heretic key all that needed to be done is to add the Heretic key to all affected locks (can be done by default without problems and since all messages can be explicitly stated there should be no messing up - unless somebody uses altered messages through Dehacked with Boom's single key locks - but so far I haven't seen any WAD that is doing so.

And here is a ZDoomified version of it. I hope it is of any use! Replacing a_keys.cpp with this version and adding the new lump to ZDoom.wad should be all that's necessary.


BTW: Did I read P_CheckKeys correctly that it did not print a proper message for the 'any key' locks?

[TheDarkArchon]

You never did.

[Graf Zahl]

You never did.

[The Ultimate DooMer]

Something else I found out today: the locked rainbow poly doors (all 6 keys) are unaffected.

[Graf Zahl]

Something else I found out today: the locked rainbow poly doors (all 6 keys) are unaffected.

There are no 'object' messages for those!

[TheDarkArchon]

You never did.

It's disbelief, my friend.

[Graf Zahl]

About what?

[TheDarkArchon]

The fact you actually did it. I thought it would be another thing for Randy's to do list.

(The fact you've done it is a good thing, BTW)

[Graf Zahl]

Let's see whether Randy considers it useful...

[TheDarkArchon]

*crosses finger*

[Graf Zahl]

I just played Caverns of Darkness which is also a WAD that is very negatively affected by this bug...

[Graf Zahl]

fixed - but for SSD it needs additional changes to the WAD.