Add-Ons >> Boards >> Events >> Simple Keypad Events

Simple Keypad Events

Uploaded by Conan
Mar 11th 2021, 12:35 PM


A simple keypad event system to simplify making passcoded doors! Has VCE support to access and view the passkey, and can be used to create string patterns.


  1. fxDTSBrick > inputPassKey [string] - Appends the indicated string to the current stored input passkey on the designated brick (named brick or self)
  2. fxDTSBrick > displayPassKey - Chats the current passkey to the client who triggered the event.
  3. fxDTSBrick > clearPassKey - Clears the stored passkey on the indicated bricks.
  4. fxDTSBrick > checkPassKey [passkey] [salt] - Checks the stored passkey against the passkey in the event. When changing the password, make sure the salt field is cleared so a salt to encode the passkey will be generated.
  5. onPassKeyCorrect - Called if the passkey is correct when checkPassKey is called.
  6. onPassKeyIncorrect - Called if the passkey is incorrect when checkPassKey is called.


To access the passkey with VCE, use <var:br:passkey> or <var:brick:passkey>. The BLID of the last person to edit the password (inputPassKey, clearPassKey) is also stored in <var:br:lastInputPassKey>.


No updates approved.


No bugs reported.
Mar 19th 2021, 10:37 PM
It is true that you can place a brick outside of ghosting range, but this isn't always feasible. Take, for example, a CityRPG.

Also, be aware there is a bug that forces a client to ghost all bricks, but that's StreamShark levels of cheating.

My comment was just a warning against short passcodes, especially numeric.

Maybe consider not storing the salt in events. Check out:
Mar 18th 2021, 4:59 PM
@Queuenard: fortunately you can configure the event to work however you wish it to. There's no limit on the number of characters in the paramter box of fxDTSBrick>inputPassKey (although the passkey limit is 50 characters)

Bruteforcing is also easily resolved by putting the brick with the check events outside of ghosting range - this just makes it not trivial to figure it out by saving the build. But I suppose given that scenario, an unsalted passcode check event would be fine as well.
Mar 17th 2021, 2:17 AM
Consider the risks of numeric-only passcodes...

Average times it would take (on my CPU) to break passcodes: (numeric codes only)

6 digits < 1 second
7 digits 5 seconds
8 digits 35 seconds
9 digits 353 seconds

Divide by 4 since I could even multithread this.