[94] ACS_LockedExecute key messages

[The Ultimate DooMer]

In previous versions, ACS_LockedExecute gave a "you need a blue/red/yellow card/skull to open this door" message, but now they say "you need a blue/red/key to activate this object". (for which there is no six-key setup for)

Could it be reverted to the previous setup, as it b0rks the messages for all script-operated locked doors (esp. polydoors) that use specific cards/skulls. (which if you haven't guessed already, SSD is full of)

[Graf Zahl]

All this tells is that it is really necessary to completely rethink the entire key/lock mechanism.
At least the door/object messages should be completed so that all messages exist for all keys.

If it wouldn't interfere so much with the HUD I would have offered Randy a fully customizable lock mechanism which doesn't need key numbers anymore some time ago. (Yes, I have it working - except for the key display on the HUD.)

[Enjay]

Would your key system mess up this? ...

I have a few levels where I have spawned Heretic keys in Doom. I noticed some time ago that the yellow and blue keys seem to work in exactly the same way as the Doom keys of the same colour and the green one acts like the Doom red key (so all that was needed was a change to the sprites).

I use this in a few levels where I want keys that have exactly the same functionality as the Doom ones, but which look different. They are used in level sets where the regular looking keys are found in "techy" levels, the skulls are used in "hellish" levels and the Heretic keys are used in "mystic" levels. (ie all used in the same WAD/ project but on dofferently themed levels)

The way things are ATM, the line types requiring the keys give appropriately generic key needed messages and all the keys add appropriate (modified) graphics to the HUD/Stat bar to indicate that they are being carried.

Would that be messed up?

[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 as I said, I didn't add any HUD integration so far so if Randy should be interested this had to be done from scratch - but it can't be that hard. When I originally did this (which was even before the monster definition stuff) I was still working with PrBoom's code (with my own HUD) where HUD integration was much simpler because it had only one hud and didn't make any assumptions about the number of keys present in the game.

ZDoom's Doom HUD is currently locked to the 6 known keys, Heretic's to the known 3 keys, and Hexen's and Strife's HUD don't show any keys at all - and let's not talk about the status bars (except Strife's.)

[TheDarkArchon]

It looks pretty suhweet though.

[The Ultimate DooMer]

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.

Guess what SSD's doing...

Great key system though, but one thing sticks out - the LANGUAGE lump.

/me gets the crucifix out...

[Graf Zahl]

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.

Guess what SSD's doing...

...and you already discovered the problems...

Great key system though, but one thing sticks out - the LANGUAGE lump.

What do you mean?

1. The fact that I mentioned the LANGUAGE lump and support of its strings or
2. that my current version doesn't support it yet? That, however, should be easy enough to add.

[Giest118]

ACS_DoorLockedExecute.

[The Ultimate DooMer]

It's the general fact that the LANGUAGE lump and new versions of ZDoom don't like each other.

(unless your key system doesn't require the lump, in which case it's fine)

[Graf Zahl]

The key system doesn't require the LANGUAGE lump. But it still should have some means to reference the strings defined in there so DEHACKED modified strings get used properly.

[Graf Zahl]

ACS_DoorLockedExecute.

That isn't as stupid as it sounds. ACS_LockedExecute already uses all 5 args so another special that prints the alternate lock message might indeed be useful. But I'd name it ACS_LockedExecuteDoor!

[Chris]

Or how about a special that can give you the keys the activating actor has? Like:

Code: Select all

SCRIPT 666 ()
{
   if(thing_has_key(RED_KEYCARD))
   {
      print(s:"Some custom error text");
      return;
   }
   // write script as normal
}

And then run it with ACS_Execute[Always].

[Macil]

Can't you use checkInventory()?

[Graf Zahl]

Can't you use checkInventory()?

Of course you can. There is no need for a specialc GetKey function.

[The Ultimate DooMer]

Sorry to bump this, but is there any chance of this bug being fixed?