Events, connections, and actions

Events

Events are what you see when you right click an item and open the Connections view.
Things like "OnToggled", "OnUsed", "OnTeleport", and so on.
Not all items have events, but many do.
The name tells you when the event will fire.
For example, "OnPressed" for a button will run the event when a player presses the button.
"OnTeleport" will run when a player is teleported by a teleporter.
When the event runs, all the connected actions inside that event will also run.

Connections

Connections are placed inside events.
They connect that event to a single item in your condo.
They may be connected to the item itself, or another item in the Condo.
You can also connect the same event to the same item multiple times.
Each event can have a practically infinite number of connections.

Actions

Each connection has one Action.
They are the instructions you give to the connected item, to tell it what to do.
An example:
(Event) You can have a button with an "OnPressed" event,
(Connection) connected to a light,
(Action) which then toggles the light by running the "Toggle" action on it.

Connections have a delay value, in seconds, to the left of them in the Connections view.
When the event fires, each connected action will be run after their set amount of seconds has passed.

Like events, the actions that are available depends on the item being connected to.
A light will have a "Toggle" action, because it makes sense to toggle a light on or off, but a Canvas Cube will not.

Actions may also have "properties".
These are used to determine what that action should do.
For example, a SetColor action would have a color property. When run, it will set the connected item to that color.
A SetText action will have a text property. When run, it will make the connected item display the given text.
I know, property is technically one more word to keep in mind, but they're pretty simple. They're just part of actions.

How to set up connections, with the Tower Glove

The Tower Glove is actually kinda awful for this, in general, but I'll mention it first.
This is so you know exactly why it sucks.

It will show you all connections between all items if you press "R".
This can be quite useful for complex connection work. Keep it in mind.

When you connect two items together with the Tower Glove, you do it in this order:
The first item you click should be the one whose event you want to hook into.
(This is the button, in the example further up.)
The second item you click should be the one whose action you want to run.
(This is the light, in the example further up.)

The Tower Glove has a screen, which shows you two things for the item you hover over.
It shows "Input" and "Outputs". These names are pretty unhelpful.
They mean "Action" and "Event", in that order.
You can currently scroll through actions, but not events.
This lets you set which action to fire, on the second item you click.
This makes the display useless for the first item you click. It will not change anything.
When you make a connection between two items, the event on the first item will always be the top event listed in the Connections view.

So, you cannot set the desired event using the Tower Glove.
You cannot set properties for actions.
You have to move to and look at the items you want to connect.
It's very easy to accidentally connect an item to itself, with no feedback, by double-clicking it.
This is why it (generally) sucks.

But, any redeeming qualities?
Yeah, it's pretty fast for making connections from one item to several others nearby.
The ability to press "R" to see connections visually can also be very helpful.

How to set up connections, in the Connections view

Right click an item and open the Connections view.
You'll notice you can click on different events to view their connections.
At the bottom, there's a button that says "New Connection".
Press this, and you'll see a new connection linked to "No Item".

If you click "No Item", you'll open the Item Picker. (Not to be confused with the Item Finder, which is in the top right of your view.)
From here, you're able to select nearly any item in your condo, and make a connection from the currently selected item to that item.
For example, if you're currently in the connections tab of a button, you can then connect it to a light thousands of meters away, without needing to fly to it.
(If the item you want doesn't show up, you can enable Show All Items. Some are hidden otherwise.)

You can also set the names of items.
Right click an item, and enter its Properties or Connections tab.
At the very top of this menu, where it says "Editing [Item Name]", click the [Item Name] field.
Here, you can set a name for the item.
This is especially useful in the Item Picker mentioned before, as you can search for that name.

You can also remotely name other items from the Connections view.
If you have a button connected to a light, you can change the name of the light from inside the button.

Naming an item is very useful for organizing complex connections.
You might have a relay module in charge of toggling all the lights in a hallway. (What are relay modules? It's explained further down.)
You can name the relay "Hallway Light Control" and find it very easily in the Item Picker.
For Physics Slot modules, these names can be used as a filter.
Only the item(s) with names matching the filter will be accepted by the Physics Slot.
Very handy for door keys, or Capture-the-Flag maps.

One final example

You may have a button which is meant to do many, many things at once.
For example, you may have a room with many lights that need to be toggled on/off when the button is pressed.
However, two problems.
1: You might want several of these buttons.
2: You want to make sure the lights toggle in sync. They should always either all turn on, or all turn off.

Relays are useful for the first problem.
They are found in the Condo I/O tab of your Condo Inventory.
Relays have an "OnFired" event.
This event will only run when another item, connected to the relay, runs the Fire action on it.
This makes it easy to make large, complicated groups of actions reusable.
Simply put all those actions in one relay, and you can Fire it to run all those actions at once.

To solve the first problem, of needing many buttons to do the same thing, we spawn a relay module.
Connect the relay module's "OnFired" event to each light's "Toggle" action.
Then, we connect the button's "OnPressed" event to the relay's "Fire" action.

Now, when you press the button, all the lights will toggle on and off.
You can make several more buttons, connect them to the relay, and they now toggle the lights as well.

However, what if someone ends up toggling one of the lights on, while the rest are off?
Now they're desynchronized. No good.

To solve the second problem, we must either copy the existing relay, or make a new one and connect it to the lights as before.
In one relay, change all the "Toggle" actions for the lights to "TurnOn" actions.
In the other relay, change all the "Toggle actions for the lights to "TurnOff" actions.

Now, spawn a Toggle module. Connect the toggle module's "On" event with the "Fire" action of the relay that turns all the lights on.
Connect the toggle module's "Off" event with the "Fire" action of the relay that turns all the lights off.
(How can you tell which relay you're connecting to? Give them helpful names!)

And finally, in your buttons, remove all the connections to the relays.
Instead, connect the buttons to the "Toggle" action on the toggle module.

If everything is set up properly, your buttons should now toggle the lights perfectly, even if some rascal desynchronized your lights. The final connections look roughly like this:
Buttons -> Toggle module -> Two On/Off Relays -> Lights

Some last helpful notes

Spawning Condo I/O modules and stashing them has a bug.
Often, they will respawn when you reload the condo.
Usually, stashing them again will make them disappear for good, but it can be annoying.
They can also retain their connections when this happens.

Conflicting actions on the same item can crash the game.
For example, a light being turned on at the same time it's turned off.
These conflicts sometimes resolve peacefully, sometimes they crash.
Be careful in setting up your I/O logic.

Infinite loops are possible, and can also sometimes crash the game, if the game gets confused about what to do.
For example: A light that when turned on, tries to run TurnOff and TurnOn actions on itself.
It's infinitely toggling off and back on and firing its "OnTurnedOn" event to turn off and back on to fire its "OnTurnedOn" event to turn off and back on to...
Boom.
Although, this particular example didn't actually crash the game in my experiments.
It just serves to give you an idea of the physically impossible things you can ask a computer to do, even with Condo I/O.
Sometimes they panic.

Many Condo I/O interactions are not super well-tested, and some will just crash the game regardless. Sometimes at random. Be careful.

In Condos where clients are making I/O connections, crashes are WAY more likely.
It's very easy for the game to crash at random when a new connection is created.
Especially if clients are doing it quickly with the Tower Glove, and their ping is bad.
Presumably this is due to some unrecoverable desync issue that's not fixed yet.
Ideally, the host should do as much of the I/O work as possible, and save often.

When an item is copied via Alt-dragging, its events and the events' connections will also be copied.
For example, a button connected to a light:
Button "OnPressed" event -> Light "Toggle" action
Copying the button will make a new button which is connected to the same light in the same manner.
Copying the light will make a new light, but will not connect the buttons to it.

Counters may reset to 0 when reloading a condo.
Levers may reset their state when reloading a condo. They may also run their "OnToggledOff" event.
And some others. I haven't actually fully tested these behaviors, but keep them in mind.
If you ever rely on counters being set to specific values when the condo loads, make a hidden button to set them to those values.
Then, press that button whenever you start your condo.

Hiding items will usually disable player collisions with them.
Unhiding items will usually enable player collisions with them.
This does not work on physics items or weapon attacks.
Sometimes, collision stays enabled or disabled on a Condo reload.
It's a good idea to have a "hard reset" button that unhides anything that can be hidden, to make sure you don't lose them.
Hidden items will not show up when you hold Q, though you can hover over them and still get a hover popup.
However, you can always use the Item Finder, or Connections view, to help set up a button to unhide anything that's hidden.

There's a unique type of connection called a Persistent connection. These are not fully implemented, so I didn't cover them here.
They can currently be used for connecting I/O stuff to media players and such.
They can also be used to connect media players to each other, so they play the same video.
However, this is a bit broken at the moment and sometimes leaves one or more screens stuck on static.

"I want to make something that compares a persistent boolean state and runs one thing if it's true, and another if it's false."

Comparisons like these are not implemented at the time of writing, but you can rig up a bootleg comparator yourself.
You need two counters, set to the range of 0-2, and some kind of boolean item, like a lever or a toggle module.
When the boolean is set to Off, the "false check" counter is set to 1 and the "true check" counter is set to 0.
When the boolean is set to On, the "false check" counter is set to 2 and the "true check" counter is set to 1.
Whenever the comparison must happen, the "false check" counter has its value subtracted by 1, waits 0.01 second, then adds by 1.
The "true check" counter has its value added by 1, waits 0.01 second, then subtracts by 1.
Connect the thing that should run on a "false" check to the "false check" counter's OnReachedMin value,
and the thing that should run on a "true" check to the "true check" counter's OnReachedMax value.