In Ranvier, all rooms for an area are defined in a single file within the area folder:
- id: 1 title: "Test Room 1" description: "A featureless white room. A pitch black void in the shape of archway can be seen on the east side of the room." npcs: ["limbo:1"] items: - id: "limbo:3" replaceOnRespawn: true respawnChance: 30 script: "1-test" exits: - roomId: "limbo:2" direction: "east" leaveMessage: " steps into the void and disappears." - id: 2 title: "Test Room 2" description: "A completely black room. Somehow all of the light that should be coming from the room to the west does not pass through the archway. A single lightbulb hangs from the ceiling illuminating a small area." behaviors: [ "test" ] items: ["limbo:2"] npcs: - id: "limbo:2" respawnChance: 20 maxLoad: 5 metadata: fooType: 'bar' exits: - roomId: "limbo:1" direction: "west" leaveMessage: " steps into the light and disappears." doors: "limbo:1": # The player encounters a door when trying to move between "limbo:1" and this room lockedBy: "limbo:test_key" # this room can only be locked/unlocked with this item locked: true # if the door is locked by default closed: true # if the door is closed by default
Doors are specified with the
doors config on the room you want to block access to. Meaning if I want the player in Room A to run into a door when going east to Room B you specify the door config on Room B, not on Room A.
It should be noted that, while the
Room object allows the definition of doors/locks, nothing in the core (or rooms themselves) block access based on these doors/locks, that is done inside the bundles. See the
ranvier-commands bundle for an demonstration of how access is blocked or the
open commands to see how the doors are controlled.
Note: When defining doors be careful to make sure you don't accidentally define a double door like a hotel room where Room A has a door blocking access to Room B and Room B has another door blocking access from Room A as this could cause the player to have to open two doors every time they moved between the rooms.
- required Room id, unique among the rooms of the current area
- required Title of the room, shown on
- required Long description of the room, shown under the title on
- List of NPCs to place in this room on initial load. You can customize the number of max instances of the NPC per room and the respawn chance by making the
npcsentry an object as described above in the "Test Room 2" example.
- List of items to place in this room on initial load. As with NPCs, you can customize the respawn chance for the item. For containers there's also
replaceOnRespawnwhich when the item is due to respawn will replace an empty instance will a full one
- Name of custom script to attach to this room (See Scripting)
- List of behaviors to attach to this room (See Scripting)
- A place to put other data you want to access inside scripts/behaviors/commands/etc. that doesn't fit into one of the existing properties. See
Room.setMeta. Note: changes to metadata while the server is running will be lost when the server is shut down.
- Rooms the player can get to from here; each
exitsentry has the following fields:
- required Movement command the player will use to leave the room (Standard compass directions are recommended)
- required Room the player will end up in when they go this direction
- Message shown to the room when the player leaves the room in this direction. In the Room 1 example above, players in the same room will see "Shawn steps into the void and disappears." when Shawn leaves to the east.
- Doors blocking access to this room. The key for each door is the room you want to block access from. So if you want to block access to players coming from
limbo:5into the room the key would be
- Optional item EntityReference of the item that will be the key that locks/unlocks the door
- Whether the door starts locked
- Whether the door starts closed