DoorEngine Documentation (V3)
Work-in-progress: not all sections are added/completed.
DoorEngine is an open-sourced HingeConstraint door engine that allows for easily being able to interact with doors (opening and closing them), and connect them to other systems via the API, all without writing code. The system itself easy to setup, with preincluded doors ready to use. You can customize almost every aspect of the system.
Older DoorEngine V1/V2
iDoor no longer supports the older DoorEngine V1 or V2 doors, they are buggy and do not have the latest features. You should replace them with V3 if you have the older versions.
AGAIN, WE WILL NOT OFFER SUPPORT FOR V1 OR V2 AT ALL
Video Tutorial
A video tutorial will be coming out soon. In the meantime, you can read this guide to learn how to use the system.
Basic Installation
You will need to first grab the model here, if you have not already: DoorEngine V3 BETA by iDoor - Roblox
Our product is open sourced, and you can grab the source here: DoorEngine Source - Roblox
For your security and to ensure you get the latest updates, please make sure to only grab the latest model from the link above.
We do understand some people will try and make custom doors compatible with the system or attempt to modify the scripts, and that’s perfectly fine. However, iDoor also does not guarantee the safety of these models, as they are not made by us. Please be careful when using unofficial models (especially if the source code was modified).
Inserting the model
Once you have the model, insert it into your game. There will be some included doors and keys as shown:
Ungroup the model, and remove the “REMOVE ME” and ThumbnailCamera. You will not need those, those are just for the thumbnail of the model. Do NOT remove the “DoorEngine V3,” as obviously that is the main part of the model.
You should now be left with one folder, “DoorEngine V3.”
The folder contains several parts:
- The Doors folder, with all the doors inside
- The Master Key Module folder, which will be explained later with the “Key System” section
- The Tools folder, which will also be explained with the “Key System” section
- The README script, which links to this post for documentation
If you are not using the key system and are purely using access card readers, a custom door interaction system, or are simply leaving the doors unlocked, you do not need the latter two folders and can delete them.
Installing doors
You should already be familiar with basic Roblox Studio building tools and know how to properly position and install a door. As such, this will not be a tutorial on how to place a door. However, please keep these in mind when installing the doors:
- Make sure that any walls surrounding the door are not touching the door - since these are HingeConstraints, any objects touching the hinge or door may cause the door to either not open or glitch out.
- Sometimes, the floor may also create issues with door movement if you place the door too far down to the ground (to the point where the floor and door collide with each other)
The default doors do have a gap at the bottom of the door itself to avoid floor-related problems with proper placement
Basic configuration
The SystemSettings script, found within the root of each door’s model, controls pretty much every aspect of the door’s behavior and operation. It is very important to not delete this script, as doing so will cause the door scripts to not load.
Opening this script will reveal quite a lot of settings - we’ll only focus on the top section for the basics right now.
One of the settings you may wish to change is the DoorName setting, which sets the door name to be used on the proximity prompts and debugging logs. You can set this to any name you want.
The InteractionType of the doors determines how the door will be interacted with - via either ClickDetector, ProximityPrompt (default), or APIOnly. In most cases, you should not change this, but the options are explained below.
-
ProximityPromptuses Roblox ProximityPrompts and is the default setting. These are much better than legacy ClickDetectors. -
ClickDetectoruses the legacy Roblox ClickDetectors. It is not recommended to use this setting, as ClickDetectors are usually harder to click especially on mobile devices. -
APIOnlywill not generate any default interaction. This means you can use a custom door interaction system, or purely control the doors from the API without having user interactions. The key system, which uses the default interaction system, will not function while on this setting.
ProximityPromptKey sets the keyboard key to be pressed to trigger the proximity prompt. This is E by default, but you can change it for a different key, for example, F or X. Only applies to proximity prompts.
ProximityPromptHoldTime sets the time that the proximity prompt key or tap must be held down until the prompt triggers. Only applies to proximity prompts.
MaxActivationDistance sets the maximum activation distance that the ProximityPrompt or ClickDetector can be activated from. 12 is the default value.
InteractionCooldown sets the cooldown in between door interactions. 0 is the default value. (this does not apply to API commands)
ShowPromptWhenNotInSight, if set to true will show a proximity prompt even if the player is not in direct line of sight (as per Roblox behavior). This is highly recommended to be kept at false, the default setting, unless the proximity prompt will not show at all (sometimes happens with custom doors), in which you can set this to true. Only applies to proximity prompts.
ShowPromptWhenLocked, if set to true, will show a proximity prompt even if the door is locked. However, when the door is locked, the prompt will display “Door Locked” instead of the open/close text. This is set to false by default. Only applies to proximity prompts.
OpenText sets the text that will be displayed when the ProximityPrompt prompts a user for door opening. Only applies to proximity prompts.
CloseText sets the text that will be displayed when the ProximityPrompt prompts a user for door closing. Only applies to proximity prompts.
And… you’re done (but most will want to continue reading!)
At this point, the door will now function (considering you didn’t modify the default loader script in the door model) when starting the game.
The door will setup itself, and when walking up to the door, you should see a proximity prompt to open the door. Press “E” (the default keyboard key) or tap the proximity prompt on mobile to open the door. The door should open, and a close prompt will display. Press “E” or tap again to close the door.
However, most of you will want to continue reading this documentation, as there is way more that the system can do.
Configuring Keys
The built-in key system is very useful for buildings who wish to use keys instead of access card readers. It can also be used in addition to card readers, for example, if an admin wishes to open all of the doors with a key instead. In addition to normal keys, which are configured in each script, master keys are also supported which allow any door that has the master key system enabled to open with the keys configured in the Master Key Module (we’ll abbreviate it MKM for the rest of this guide), this is useful to avoid having to configure each door to setup a master key, especially when having to change the key ID.
Getting the key tool
The model includes two keys in the Tools folder: The “Key” and “MasterKey”
The two keys are the default normal door key and the master key respectively. Inside of it is the KeyID, you can either keep it default or change it (strongly recommended). When using multiple keys, such as only allowing access to certain areas with a particular key, you should change the KeyID for each key to a unique numerical value. Make sure to keep a note of the KeyID for each key, you’ll need it when configuring the settings in a little bit.
Put the tools into the folder where you usually keep your tools (e.g. ServerStorage). If you wish for everyone to have a key, put the tool into the StarterPack. Note that you will need to setup a script yourself to be able to give authorized users their particular keys. Most admin command scripts do have a :give command that gives tools from ServerStorage or other locations (e.g. Adonis) so you can also use that for giving keys to administrators.
Configuring Normal Keys
The default key, if you didn’t change the ID, is already configured in the AllowedKeys section of the script. The AllowedKeys setting contains the table with all of the authorized KeyID values that will be allowed to open the door. You can add as many KeyID values as you want to this table. For example, if you have two keys to be able to open a door:
- Staff Key (KeyID 125)
- Supervisor Key (KeyID 165)
The table should look like this:
Be sure to also change the KeyID value (if you haven’t done so already) for the respective keys, so that the system can read the correct KeyID:
You are now finished configuring normal keys.
Configuring Master Keys
DoorEngine V3 supports being able to configure master keys, which allows access to all doors that have the MasterKeys setting set to true - which is the case by default.
To configure master keys, the DoorEngine_MasterKeys module, located in the Master Key Module (place the MODULE ONLY in ServerScriptService) folder, must be put into ServerScriptService. Do not put the folder into ServerScriptService, only the module script. Once you have done that you can now open the module and you will be greeted to this:
Just like normal key configuration, your
KeyID values that you want to be master keys should go into this table.
Making a specific door not read master keys
If you want a specific door to not use master keys, and instead only the keys within the door’s configuration, you can set theMasterKeyssetting in theSystemSettingsscript of that door tofalse.
What if I don’t want to use keys?
You can completely disable the key system in the door’s SystemSettings script by setting the Enabled setting under KeySystem to false. Disabling this setting will set the door to closed and locked - you will need to use the API or an external system (e.g. card readers) to control the door’s operation.
Using the API or external/third-party systems
The API (application programming interface) allows you to use your third-party external systems with DoorEngine V3, or perhaps make your own systems that integrate with our doors. For example, you can set up access control systems from other tech groups to work with our doors.
This section of the documentation is not finished. If you need help with the API, contact me on Discord: door3773