[ITEMS] New key system (UPDATE V2)

Author Topic: [ITEMS] New key system (UPDATE V2)  (Read 6962 times)





Item_KeyName
This add-on changes the way keys work. They no longer look for the color of the brick but rather keywords in the brick's name. This means you can have one or more keys match a single door, regardless of it's color.

How to use normal keys:
To make a door identifiable by a key you will have to add the keyword _key onto the end of the brick's name, followed by any amount of letters corresponding to the keys the door can be opened with.
For example:
bunkerDoor_keyR - Door requires a red key and only a red key.
keyRYBO_keyg - Door can be opened with either a red, yellow, blue, orange or green key.

The key token must be at the start of the field, and the field should only contain key followed by letters corresponding to keys. bunkerDoor_keyR will work. KeyRBunkerDoor will also work, but will produce undesired effects such as the Blue and Orange keys accidentally being attributed to the door. bunker_doorrkeyRed will not work at all.

How to use the personal key:
A new key has been introduced in V2 called the personal key. This key matches to any door that has the token pkey in it's name. If a brick has pkey in it's name, anyone who has at-least the build trust of the owner of the brick will be able to open the door.

For example:
bunkerDoor_pkey_keyRGB - Door can be opened with the red, green and blue keys, or the personal key if you have the owner's trust.
homeDoor_pkey - You can only open this door with the personal key and the owner's trust.

Keycards:
Type $Pref::KeyNames_UseCards = true; in the console (open with ~) and restart your server to enable the use of keycards. They will replace the default keys. To disable them type $Pref::KeyNames_UseCards = false; in the console and restart your server. These settings will persist even after you close Blockland.

Keys and their corresponding identifier:
Red - r
Yellow - y
Green - g
Blue - b
Purple - p
Orange - o
Lime - l
Cyan - c
Key 1 - 1
Key 2 - 2
Key 3 - 3
Key 4 - 4
Personal Key - pkey


There is also a Skeleton Key which calls onKeyMatch on any brick you use it on. (When Keycards are active, it will be called the Master Key)

Download (V2)
NOTE: Upgrading to V2 will not break your saves in the event that you already built doors using the V1 system. By default the legacy support is enabled in parallel with the new system, but it can be turned off by typing $Pref::KeyNames_Legacy = false; in the console.

Previous Versions
V1


NOTE: Make sure you have Item_Key enabled. This uses it's functionality.

Credits to Gravity Cat for the card models and Swollow for the skeleton key model
« Last Edit: August 07, 2017, 08:18:29 PM by Rally »




i still sorta like the the despair syndrome key system works because its way more specific and it has around 30 keys for 30 specific doors



Why do you need to put rkeyR_rkeyG_rkeyY instead of just key:RGY ?
« Last Edit: July 01, 2017, 09:00:05 PM by Zeblote »

Why do you need to put rkeyR_rkeyG_rkeyY instead of just key:RGY ?

i wasn't able to put : in a brick name

This will also print errors if you use a key on a brick with a name that's less than 4 letters long.

I'm having trouble reproducing this
« Last Edit: July 01, 2017, 08:51:14 PM by Rally »

i wasn't able to put : in a brick name

Ok, that's not the point though. You shouldn't have to put another "_rkey" for every single key.

I'm having trouble reproducing this

turns out that was some old stuff I had enabled and not this mod

yeah I guess that would be a better method

I'll forget with it for the next update

probably just have players append the brick name with _rkey-abcdefg1234567890 where each letter/number corresponds to a diff key

that isn't lime, that's turquoise
get your colors right

finally, racial equality for doors and keys alike
srsly tho this is rad

This looks interesting but in my opinion a little less user-friendly. If i were making this i would just make one output event that registers with all the keys as parameters

Like, put the key projectile/raycast as calling onNewKeyHit on a brick, then add an output event registerKeyHit > text box

then have it check for the last key hit type, and have an output function like onNewKeyAccepted and onNewKeyDeclined that will handle any event that happens when the key is accepted or rejected

here would be like an example event system for accepting keys red and blue

onNewKeyHit | Self | registerKeyHit { red blue }
onKeyAccepted | Self | Door { OpenCW }
onKeyDeclined | Self | Playsound { error.wav }


This way acts more user friendly and intuitive than setting it up in a brick's name. Some mods might use a brick's name to register some sort of function, or maybe there's just some sort of impracticality
« Last Edit: July 01, 2017, 11:01:39 PM by PhantOS »