Welcome to ZDF!

Posted: **Fri Nov 19, 2004 11:35 am**

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)

Posted: **Fri Nov 19, 2004 12:16 pm**

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.)

Posted: **Fri Nov 19, 2004 12:32 pm**

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?

Posted: **Fri Nov 19, 2004 3:23 pm**

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.)

Posted: **Fri Nov 19, 2004 3:26 pm**

It looks pretty suhweet though.

Posted: **Fri Nov 19, 2004 6:03 pm**

Graf Zahl wrote: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...

Posted: **Fri Nov 19, 2004 6:24 pm**

The Ultimate DooMer wrote:
Graf Zahl wrote: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...

The Ultimate DooMer wrote: 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.

Posted: **Fri Nov 19, 2004 6:43 pm**

ACS_DoorLockedExecute.

Posted: **Fri Nov 19, 2004 6:43 pm**

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)

Posted: **Fri Nov 19, 2004 7:11 pm**

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.

Posted: **Fri Nov 19, 2004 7:14 pm**

giest118 wrote: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!

Posted: **Fri Nov 19, 2004 8:57 pm**

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].

Posted: **Fri Nov 19, 2004 8:58 pm**

Can't you use checkInventory()?

Posted: **Sat Nov 20, 2004 3:37 am**

Agent ME wrote:Can't you use checkInventory()?

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

Posted: **Tue Dec 21, 2004 8:35 am**

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

Welcome to ZDF!

[94] ACS_LockedExecute key messages

[94] ACS_LockedExecute key messages