Main Connecting Starting



Building: Simulation Programs

Simulations are our implementation of instanced content. Unlike some instancing systems, these are explicitly instanced in character, being a virtual reality simulation akin to holodecks in Star Trek. Multiple players may enter the same simulation, but there can also be different copies of the same simulation running.

Simulations are used for both training missions, to avoid possible contention, and also as a reason to keep area in the game that otherwise would feel out of character.

How to create a new program

First you must create a container object to contain all the rooms, objects and mobiles that make up your program. The easiest thing to do is create a new zone, but the best thing to do is create a new object inside holo_zone so that we dont have too many zones. If you create it as an object inside holo_zone then every time you create a new room, you must change that rooms's 'start' property to be the ID of your container, and ideally chstr the room's ID to be holo_programname_n e.g. holo_myprogram_1. Maybe one day WebMake will be useful in making programs.

For example: relay_zone holds the Academy program, and holo_combat1 (which is inside holo_zone) holds Combat 1.

Mandatory things to set on the container object

Optional things to set on the container object

If you haven't set DontHideHoloEq you can specify an eq array containing items which should be simulated in the player's inventory when they start the simulation. This is much like the auto array on mobiles, and you may use the same eq.*.worn and eq.*.wield attributes to make stuff automatically worn or wielded.

How to make your program available from a shop

Go into the shop, and type 'addstock <container id>'. For example, in the Games Club (level2_33) you could type 'addstock holo_myprogram' and then type 'list' to see it in the list.

How simulator programs work

When a simulation program is started, it clones your container and everything inside it. All the IDs of the cloned objects will start with @auto<some numbers> infront of the real ID, so a holo_cheese_1 could becomse @auto4412_holo_cheese_1. The cloned objects' 'zone' property is also set to this @auto prefix. Also, it will look at the properties of all the objects in your program template and change any that look like IDs to be the new @auto-prefixed ID. This ensures exits lead to the right cloned room, and not back to the template! There are a few exceptions that do not get altered such as 'treatas'.

Do I have to write special lua traps to make things work in simulator programs?

Generally, no. Any use of 'get()' will magically get the correct @auto_ clone version of the object you specify. This includes when you just pass a string ID into a lib, e.g. move("holo_blah", "holo_10") will really move your current cloned instance of holo_blah into your current cloned instance of holo_10. If for some special reason you really want to 'get' the actual template object (there are a couple of cases in the zoo game) then you can do get(id, 1) to force it to return that instead of the clone. Things like isa() and holdsclone() might need this in very special cases, so dont use get(id,1) unless things dont work properly and someone clever tells you its needed ;)