Bypassing locked doors

[Ed the Bat]

Yeah, the idea itself is valid on its own, but not exactly compatible with what I'm aiming for.

[Mr. Tee]

I'm not really sure why you are getting so aggravated.

I'm typing this on my Crackberry which aggrivates me further that this topic normally would.

Everytime I pressed the return key on it the damn thing would load http://www.google.com for no reason. Very annoying (I'm only human after all, just like everyone else).

-------------------

As for the key thing, I may have found something, but not sure if it will work and I cannot test it on this computer. I apologize if something similar had already been suggested.

How about creating a SkeletonKey item in DECORATE that inherits from the Key actor, coupled with a LOCKDEFS lump whose first entry is "CLEARLOCKS", and which then redefines each original lock type to include the SkeletonKey, in the following manner:

LOCKDEFS Lump:

Code: Select all

CLEARLOCKS

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

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

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

Lock 4
{
	Any { RedSkullkey SkeletonKey }
	Message "$PD_REDK"
	RemoteMessage "You need a red card to activate this object"
	Mapcolor 255 0 0
}

etc...

DECORATE Lump:

Code: Select all

ACTOR SkeletonKey : Key
{
  Inventory.PickupMessage "You picked up a Skeleton Key!"
  Inventory.Icon "xxxx"
  States
  {
  Spawn:
    xxxx A 10
    xxxx B 10 Bright
    Loop
  }
}

http://zdoom.org/wiki/LOCKDEFS

http://zdoom.org/wiki/Key_types



EDIT: Fixed the code up a bit

[Ed the Bat]

Original Post:

The best method I've come up with so far is to create a new actor inheriting from Key, and then redefine every lock in LOCKDEFS to accept it. However, some maps may redefine locks themselves, and this can create a conflict that I can only solve with extra patch files. Kind of messy.

That's exactly what I'm doing. The problem here is that if a map defines a new LOCKDEF, one will overwrite the other, so I have to cover that contingency with a specialized external patch for it.

[Mr. Tee]

*facepalm for not rereading original post*

I see... And there is no way to concatenate multiple instances of LOCKDEFS, should a WAD already have one.

I wonder, would they really overwrite each other before being parsed by ZDoom? If ZDoom parses each lump as they are loaded, it's possible that the information won't be overwritten unless a WAD's LOCKDEFS lump already messed around with the original key locks...

Shoot, this is really tricky.


EDIT: I travel over 75% of my time for my job and thus am tired all the time (timezone changes, lack of sleep) , so please excuse some scattered ignorance on my part here and there.

[Ed the Bat]

I see... And there is no way to concatenate multiple instances of LOCKDEFS, should a WAD already have one.

The LOCKDEFS lump itself can have multiple instances, but locks are defined by numbers, and if any number should appear more than once, the last instance will take precedent over the others.

I travel over 75% of my time for my job...

Say no more. We all understand how tough that can be on a person. I'm personally grateful that I can stay put for the things I need to do. Travel is not really in my blood...

Shoot, this is really tricky.

Welcome to my world, fiddling around with things that people probably shouldn't be.

[Graf Zahl]

Sorry to disappoint you, but hoping that add-ons that manipulate game data work with other mods modifying the same game data is futile.
It simply can't be done because it'd resort to second guessing a modder's intent even before he made the mod.

[Ed the Bat]

Then I guess I'll just have to keep doing it how I'm doing it.

[Gez]

Suppose a method suddenly appears. For example, DoomScript happens and you can reprogram directly the action functions themselves. Yeehaw, you can now get in at a lower level than everybody else and make your mod compatible with everything by redefining all the *Locked* specials. Except... Two weeks later, another, different mod appears, which also redefined all the *Locked* specials to achieve some different result, and you're back to needing compatibility patches. As soon as you can mod something, you can create a mod conflict. This is inevitable.

(Also, this hypothesis ignores the UDMF locknumber property which can be placed on any linedef, meaning that any special can be locked anyway, even those that don't use a locknumber parameter.)

You could think that a foolproof method would be to go at the very lowest level and code it directly in C++, as a feature suggestion. But unfortunately, even that isn't guaranteed to work in all cases, since it has been a relatively common practice for people to duplicate lock systems in ACS with inventory checks...

[Ed the Bat]

...duplicate lock systems in ACS with inventory checks...

That one's been a pain in my ass before... Thankfully, there's less reason for people to do that, now that ACS_LockedExecute can check for keys outside of the script.

I know I can't cover every contingency. That's why I load my KEYCONF before other mods, not after. If I load it before, and the map has a different lock set, then I can still pick up those locks; the skeleton keys just won't work. If I loaded mine afterwards, ONLY the skeleton key would work; custom keys inside the map may break, which is definitely the greater of two evils there.

[XutaWoo]

KEYCONF

These aren't the keys you're looking for.

[Ed the Bat]

KEYCONF

These aren't the keys you're looking for.

Brilliant, yes. You're right. I typed that without thinking. I'm sure y'all probably guessed I meant LOCKDEFS when I said that.

This is particularly ironic because I have to load my KEYCONF after custom maps (as opposed to LOCKDEFS before them, like I said above), due to how setslot and clearplayerclasses will muck up anything that was loaded before them.

[Mr. Tee]

Suppose a method suddenly appears. For example, DoomScript happens and you can reprogram directly the action functions themselves. Yeehaw, you can now get in at a lower level than everybody else and make your mod compatible with everything by redefining all the *Locked* specials. Except... Two weeks later, another, different mod appears, which also redefined all the *Locked* specials to achieve some different result, and you're back to needing compatibility patches. As soon as you can mod something, you can create a mod conflict. This is inevitable.

I guess then the only surefire way would be to modify zdoom.exe itself and embed the skeleton key object within. The caveat is you'd have to give this executable to your friends if you all wanted to use this item, and I can imagine something simple like this causing odd bugs elsewhere in the code...

[Ed the Bat]

Editing the executable is probably never a good idea. But, y'know, even if it's not perfectly elegant, the method I've got right now certainly gets the job done for me and my friends, so... I think we'll live.