Live Link connects OpenCAGE to Alien: Isolation while the game is running. With the game playing the level you have open, the script edits you make reach it moments later, without saving or reloading the level. You can also trigger an entity's methods (start, trigger, show...) in the game straight from the Entity Inspector or a method pin on the flowgraph, have the game's camera and the Viewport's follow each other, and watch your scripts run, as the flowgraph lights up each link the game uses and counts how often each output fires and each method is called. With the game's Debug Menu on as well, you can stop the scripts at a breakpoint on a node, see what led there, and step on from it.

It's also the quickest way to light and dress a level: place a light or a prop, move it and change it in OpenCAGE, and the game draws it within a second. See What You Can Do With It.

It makes for quick iteration on a script. Add a DebugTextStacking, give it some text and pick start from ▶ Trigger Method in the Entity Inspector, and the text is on screen in the game (with Debug entities ticked in Launch Game too, so the game draws it). Change the text and trigger start again, and the new text appears on a line under the old one: a DebugTextStacking adds a line each time it starts, and an edit doesn't clear the ones already there (call its clear_all method to empty the stack, or clear_last to remove the newest line).

OpenCAGE connected to the game: Live Link is pressed on the main toolbar, Resync sits on the composite toolbar, Live Link Camera on the Viewport toolbar, and the Entity Inspector offers ▶ Trigger Method for the selected DebugTextStacking.

The same DebugTextStacking in the game, added and started over Live Link. In the top-right corner, OpenCAGE Live Link shows the game is connected, with the last thing done underneath.

A few of the things Live Link is good for, each with a link to the details further down. All of it happens in the running game without saving the level, so save when you want to keep your work (see Editing While the Game Runs).

Build a New Script Without Saving

You can put a whole new piece of script together while the game runs: add the entities, link them up, trigger start (or link something to start it), watch what it does, then change it and go again. Every entity and link you add reaches the game a moment later. A test script of a TriggerLooper ticking a LogicCounter, DebugTexts showing the count, a DebugTextStacking logging each tick and a couple of markers was built this way in the root of a running level, and was running within seconds, without a save.

To try it, open the level's root composite (the orange globe in the Composite Browser), add entities with a right-click on the flowgraph and Create Entity → New Function, and drag from one pin to another to link them, as in Creating a Script. Debug Text & Markers builds that counter script step by step, with a picture of it running in the game.

The main limit is a brand-new composite. The running level doesn't have it, so the game turns it away with Composite XXXXXXXX is not in the running level - save and reload the level to add new composites. Build in a composite the level already has (its root, say), and save and reload once you move the script into a composite of its own. See What Needs a Reload.

See Small Script Changes at Once

In a script that's already there, change a value, a delay or some text in the Entity Inspector, or make or break a link on the flowgraph, and the game has it a moment later, with no save and no reload (see What Reaches the Game).

Each entity whose parameters you change is re-initialised, and so is one whose value comes through a data link you make or break, since the value it reads has changed (making or breaking a logic link doesn't re-initialise anything). If it was running, it stops. Start it again, or trigger the method that sets the logic off (trigger, start...) with the inspector's ▶ Trigger Method or a right-click on its pin. That way you can run the same bit of script again and again as you tune it, without playing back to the point where it would fire.

Lighting in Real Time: Place and Tune Lights

This is where Live Link saves the most time. Place a light, move it, and change its colour and brightness in OpenCAGE, and the game lights the level with it within a second. You tune it by eye in the game's own render, rather than saving and reloading after every tweak.

1. Open the level's root composite (the orange globe in the Composite Browser), or a composite you step into from it, and add your lights there. The game only follows the Viewport's camera in the level itself.
2. Set Live Link Camera to Sync viewport camera to game, and fly the Viewport to the spot you're lighting. The game draws it from the Viewport's camera, with its own lighting, materials and post effects, so you're looking at the real result as you work.
3. Add the light: drag one of the level's light prefabs from the Composite Browser onto the Viewport (the one below is AYZ\Science\Lighting\Small_Floor_Light), or drag a LightReference from the Entity Palette onto the Viewport. Either is created where you drop it (see Creating Entities), and appears in the game straight away.
4. Select it, and move it with the gizmo or type in its position. The light moves in the game.
5. Change its colour and intensity in the Entity Inspector. On a light prefab these are the instance's parameters, such as lgt_col for the colour and lgt_spot_IntMult, lgt_omni_IntMult and lgt_emissive_IntMult for the intensities. On a LightReference they're its own colour and intensity_multiplier: a new one starts white at an intensity of 1, so give it a colour and raise its intensity_multiplier and end_attenuation until it clearly lights the space (8 and 3 for the one further down).

A Small_Floor_Light prefab dropped on a corridor floor, as the game drew it from the Viewport's camera: placed and coloured cyan, moved across the corridor, moved back and dimmed, then given a new colour and intensity. Each change showed in the game within a second.

Because you're looking at the game's render, you see exactly where the light has ended up. Move it too far and you'll see it go behind a door.

The floor light's instance (named DocsLight in the inspector) selected, with Live Link pressed on the main toolbar. Some of its lgt_ parameters are in view in the Entity Inspector, with the rest of the instance's parameters; scroll up the list for lgt_col and the intensities.

New lights work too. A plain LightReference added to the level's root, with a colour, an intensity_multiplier of 8, an end_attenuation of 3 and light_on_reset ticked, lit the corridor as soon as it was added. Moving it and changing its intensity showed at once, and deleting it took the light away. Adding a LightReference also brings up Its resource references changed (models, collision and the like): those need the level saved and reloaded, on the status bar and in the game's overlay. For a new light that note is expected: the light works anyway.

Before, and after adding a plain LightReference: the corridor is flooded magenta the moment it's added. The resource note at the end of the overlay's line is the expected one.

Lights the level already has change the same way: recolour them, or switch them on and off by triggering light_switch_on and light_switch_off (see Triggering Methods), whether their composite is used once or many times.

Baked lighting isn't recalculated. Live Link changes the lights themselves: the light they cast directly. The light that bounces around the level (its radiosity) is baked by Save and Build, so Live Link leaves it as the last build left it. See How Radiosity is Handled for what a build redoes.

Build and Dress the Level in the Game's Render

Instances of composites the level already has are built by the game as you place them: props, light prefabs, NPC spawns, whole prefab walls. Drag one from the Composite Browser onto the Viewport, move it, turn it or delete it, and the game does the same, so with Live Link Camera following the Viewport you can dress a room while looking at it in the game. The level's own geometry can be moved too. Move the floor the player is standing on, though, and they drop through it for a moment while its collision is rebuilt.

Before (from further back), then a supply crate (an instance of AYZ\_Props_\Static\Generic\Container_Shells) placed in the corridor, then moved and turned, each step drawn by the game straight away.

A model placed on its own, as a new ModelReference entity rather than inside an instance of a composite, isn't built by the running game: the status bar says it's not built, as a level load would not build them. Plain static models come from what Save and Build bakes, so it appears once you use File → Save and Build Level and load the level again. The same goes for new models, imports and material edits, and the navmesh, cover and baked lighting stay as the last build left them too: see What Needs a Reload.

To see a model in the game straight away, place an instance of a composite the level already has that contains it, rather than the bare model. Props such as AYZ\_Props_\Static\Generic\Container_Shells are composites, so find the prop in the Composite Browser and drag it onto the Viewport (see Creating Entities). A model of your own that no composite in the level uses yet still needs Save and Build.

Debug Scripts With Values on Screen

With Debug entities ticked under Debug tools in Launch Game, the game draws the debug entities, so it can show you what your script is doing: a DebugText shows its text and the values linked to it, updating as they change; DebugTextStackings keep a log of the last five lines, in one block on the left of the screen; a DebugPositionMarker draws axes at a position; and a DebugEnvironmentMarker labels a spot, or an entity it follows. Add them, link them and trigger their start over Live Link like anything else.

Debug Text & Markers covers them all, including how to see a script's values and keeping a log. If a DebugTextStacking's log repeats or skips values, start it from the link that fires once the value has changed (a LogicCounter's on_Up, say) rather than from the same trigger that changes it (two links fired by one trigger run in no fixed order), and link its input straight to the counter's reference.

To see which links a script follows, rather than the values it works with, switch on Show Activity and watch the flowgraph light up as the game runs it.

To stop a script at a node and look around, use the script debugger: the game stops just before the node's entity is called, and Show Live States Above Nodes shows each node's state, and the values its data pins read, where it stopped.

And More

• Scrub and play animations in the game. In the CAGEAnimation Editor, Animation Mode with In game ticked holds the animation at the playhead in the running game and plays it from there, so you can time a door, a lift or a light sweep against the real level while you edit its keys.
• Frame shots, and check what the player would see. With Live Link Camera on Sync viewport camera to game, the game draws the level from wherever you put the Viewport's camera, anywhere in the level.
• Find where the game's camera is. On Sync game camera to viewport, the Viewport follows the game's camera, so you can see in the editor where it is and what it's looking at.
• Shape a spline against the real level. With Edit in Viewport ticked in a SplinePath's Edit Spline window, the running game follows its points as you move them, and goes back to the level's spline when you leave without saving.
• Set things off without playing up to them. Lights, NPC spawns, screen effects and sequences can be set off by triggering their methods from the Entity Inspector's Trigger Method or a pin on the flowgraph, rather than playing to the point where the script would.
• See what a script is doing. With Show Activity on, each flowgraph link lights up as the running game uses it, orange for logic and blue for data, with a count beside each pin it fires or calls, so you can follow a script as it runs, see which way it went and how often, and find the parts that never fire.
• Stop a script at a node. With the game's Debug Menu on too, a breakpoint stops the game just before an entity's method is called, shows you the node and the calls that led there, and lets you step on a round of calls at a time.
• Check a change everywhere at once. An edit to a composite reaches every running instance of it, so you can see how it plays out in each place the level uses it (see Editing While the Game Runs).

• The Steam, GOG or Epic Games Store version of the game. Live Link is served inside the game by OpenCAGE's runtime utils, the same plugin behind the rest of Launch Game's Debug tools, and they support those three PC releases. On other platforms the Live Link box is greyed out and the Live Link button never appears.
• The game started from OpenCAGE, from the Launch Game window with Live Link ticked in its Debug tools. A game started without it has no Live Link to connect to. The runtime utils stay in the game folder as Launch Game last set them, so a game started some other way (from Steam, say) serves Live Link too if Live Link was ticked the last time you started the game from Launch Game.
• The Debug Menu, for the script debugger. Edits, method calls and the rest of Live Link work without it, but the script debugger, and an AI assistant working the Debug Menu, need the game started with Debug Menu ticked in Launch Game's Debug tools as well. The whole Debug Menu runs alongside Live Link, its Cinematic group (which replaced Cinematic Tools) included.
• The game running the level you have open, as it's saved on disk. Edits for any other level are refused. The easy way is to tick Load straight into in the same window, which picks the level you're editing for you.
• The same install. If you have several game installs, each OpenCAGE window only looks for the game from the install it's editing.
• One at a time. The game takes one Live Link connection, so while one OpenCAGE window is connected, another stays waiting: switch the first window's Live Link button off to use another. Only one running game can serve Live Link, so with several installs, run one game with it at a time.

The game only accepts Live Link connections from the same PC.

1. Press Launch Game on the main toolbar. Opening the window closes the game if it's already running.
2. Under Debug tools, tick Live Link. It stays ticked for next time.
3. To use the script debugger too, tick Debug Menu in the same group. Don't write saves, under it, keeps the game from writing to your saved games while you test.
4. Tick Load straight into, at the top, and check the level beside it is the one you have open (OpenCAGE preselects it).
5. Press Start Alien: Isolation.

Starting the game this way installs OpenCAGE's runtime utils in the game folder with Live Link switched on, and switches the Live Link button on, so OpenCAGE connects by itself a few seconds after the game starts. The status bar at the bottom of the OpenCAGE window says Live Link: connected to the game when it has.

Live Link is in the right-hand column of the Debug tools group, under Debug entities. Debug Menu, for the script debugger, is at the top of the left-hand column, with Don't write saves under it.

Unsaved Changes

The game loads the level from disk, so edits you haven't saved won't be in it. If the open level has unsaved changes when you press Start Alien: Isolation, OpenCAGE asks whether to save first:

• Yes saves the level, as File → Save Level does, then starts the game. If the save doesn't go through, the game isn't started either.
• No starts the game without saving. What you haven't saved won't be in the game until you edit that composite again or Resync it.
• Cancel does neither.

If you've added models or other content that needs building, press Cancel and use File → Save and Build Level first (see Save and Build). The question comes up whenever you start the game with unsaved changes, with or without Live Link.

The Live Link Button

While this install's game is running and serving Live Link (started with Live Link ticked, as under Requirements), a Live Link button appears on the main toolbar, to the right of Launch Game, and it stays there while OpenCAGE is connected. It shows pressed while Live Link is on, whether it's connected or still waiting for the game, and clicking it switches it off (disconnecting from the game) or back on. Hover over it to see where it stands: connected, or waiting for the game.

The button remembers its setting. Left on, OpenCAGE connects whenever you start the game with Live Link, and reconnects by itself if the game restarts. There's no button for a game started without Live Link, which has nothing to connect to, or for a game from another of your game installs: close it and start this install's game from Launch Game with Live Link ticked.

In the game, OpenCAGE Live Link shows in green in the top-right corner while it's connected, with a line under it for a few seconds about the last thing done: an edit applied, a method called, a Debug Menu command run, or something waiting. You can see it in the screenshot above. To keep the label off the screen, tick Options > Misc > Hide Live Link Label In-Game: a connected game hides it straight away, and the line about the last thing done then shows in its place.

While Live Link is connected, your script edits go to the game automatically: there's nothing to press, and no option to hold them back. A moment after you stop editing (about a third of a second, so a drag or a run of undos goes as one), OpenCAGE sends the whole composite you changed, and the game brings every running instance of it in line with the editor, without a reload. The status bar says what the game did with it: how many running instances it applied to, and how many entities were added, removed or changed.

Sending an edit to the game doesn't save it. The level on disk is unchanged, and the edit is still an unsaved change in OpenCAGE. The game only holds it in memory, so it's gone once the game closes or loads the level again (with the hot reload key, a level change, or starting the game again). To keep your work, save the level when you're done: File → Save Level, which closes the game.

What Reaches the Game

Only script edits are sent: these, and nothing else. Anything that isn't on this list (an asset change, a new composite) needs the level saved and reloaded, as listed under What Needs a Reload.

• Entities added and deleted, including new instances of composites the level already has, which are placed with all of their contents.
• Parameter changes, including alias overrides on entities inside nested instances.
• Links made or broken on the flowgraph. A data link re-initialises the entity its value goes into.
• Entities moved, in the Viewport or the inspector. A Viewport drag is followed as you make it, a few times a second, and so is a colour while you choose it in the inspector's colour picker. Move the floor the player is standing on, and they drop through it for a moment while its collision is rebuilt.
• Keyframes and events in the CAGEAnimation editor, as you make them, and TriggerSequence entries when you close the TriggerSequence editor. The entity is re-initialised, so start it again to see the change.
• Edit → Undo and Edit → Redo, De-instance Composite Instance, and edits made by an AI assistant.

Every entity whose parameters you change (moving it included) is re-initialised: put back in the state it starts the level in, then left to react to the edit, as though the level had just started. So something that was running when you edited it (a Thinker, a looping effect, text a DebugText put on screen, the axes a DebugPositionMarker draws) stops, and needs starting again unless it has start_on_reset set. Triggering its start from the inspector or the flowgraph is the quickest way to do that. A new entity starts the same way: if it doesn't start by itself, it waits for a link or a call to start it.

An instance of a composite is re-initialised along with everything inside it. Moving one, changing its parameters, or changing the default of one of its composite's variables (which re-initialises every instance of that composite) starts all of its logic over. That's usually what you want, but take care with an instance that runs a mission. Starting it over does whatever the mission does when it starts, and that can include sending the player to another level.

What Needs a Reload

Live Link only carries script edits, so everything else you change in OpenCAGE stays out of the running game, however long you wait: no error, the game just never sees it. For these, save the level and load it in the game again:

• A new composite the running level doesn't have: one you've created (including with Create Composite From Selected), copied (with Duplicate or Create Composite Variant), ported or imported. Instances of composites the level already has are fine.
• Resources: models, materials, textures, collision and the like. Edits you make to them (in the Model, Material or Texture editors, say) don't change the script, so nothing is sent and the running game never sees them. If a script edit changes which resources an entity uses (a ModelReference pointed at another model), the game still takes the rest of the edit, and the status bar says those resources need the level saved and reloaded. Adding a LightReference brings up the same note, but its light works straight away (see Lighting in Real Time).
• A new default for one of the level's root variables: the variables of the composite the level starts from. The level reads their defaults when it loads, so the game keeps the old ones until then, and the status bar says so. The variables of every other composite take new defaults straight away.
• A model placed on its own: a new ModelReference entity, rather than an instance of a composite the level already has. The game doesn't build it (the status bar says it's not built, as a level load would not build them), as plain static models come from what Save and Build bakes. It appears once you Save and Build and load the level again.
• What Save and Build works out from the layout: navmesh, cover and job positions, sound, and baked lighting. Props and prefabs you place, and anything you move, over Live Link appear where you put them, but NPCs go by the navmesh, cover and job positions of the last build, and the baked (bounced) lighting stays as the last build left it, until you Save and Build and load the level again.
• Anything else the game only reads when it loads a level.

Saving closes the game, as it always has, so save once you're ready to restart it: File → Save Level, or File → Save and Build Level when there's content to build, then start the game again from Launch Game. With Options → Misc → Open Game On Save ticked, saving starts the game again in the level for you, and OpenCAGE reconnects once it's up.

The game must be running the level you have open in OpenCAGE. Edits and method calls for any other level are turned away with The game is running a different level, rather than landing in the wrong place.

Unsaved edits you made before Live Link connected aren't in the game, which loaded the level from disk. They reach it the next time you edit that composite (the whole composite is sent), or when you Resync it.

Level Start & Pause

The game only takes edits and method calls while the level is being played. While it's still starting (loading, the intro and the opening cutscene), while the pause menu is open, while a cutscene or a message on screen (a DisplayMessage waiting for the player to close it, say) has paused the level's scripts, or after a death while it restarts from a checkpoint, they wait, and the overlay in the game says Waiting for the game and why. Once the level has been playing for 5 seconds, they're carried out in the order you made them.

They wait too while the script debugger holds the level's scripts at a breakpoint, and while the Pause button on the Debug Menu's Game > Tools tab holds the game. Once the scripts go on again, they're carried out straight away, without the 5 seconds.

If they've waited 20 seconds and the level still isn't being played, the game turns them away. OpenCAGE sends its edits again by itself a few seconds later, so they get there in the end. A method call isn't repeated, so call it again once the game is playing.

When the game isn't playing a level at all, between levels or while it unloads one, edits and calls aren't held. They're turned away at once with No level is running or The game is unloading the level (or The game is running a different level at the game's main menu, which is a level of its own), and OpenCAGE doesn't send them again. The level the game loads next comes from disk, so once it's being played, Resync each composite you changed meanwhile.

While connected, a Resync button, with a refresh icon, sits on the composite toolbar at the top of the composite panel (with Create Entity and Create Flowgraph, above the Viewport), after Create Flowgraph and a divider. It sends the composite you have open to the game again, so every running instance of it matches the editor.

Edits are already sent as you make them, so Resync is only needed when the game has fallen out of step with the editor:

• for edits you made before Live Link connected, which the game doesn't have;
• after the game has loaded the level again from disk (with the hot reload key, say), which puts back what's saved and drops what Live Link sent.

Resync sends only the composite you have open, so do it in each composite you've changed. If the game turns it away (because it's running another level, say), a message says why.

• Undo an edit: Edit → Undo is sent like any other edit. The entities it touches are re-initialised again, and the game isn't rewound to before the edit.
• Put the game back to what's saved: press the hot reload key (Hot reload in Launch Game), or start the game again from Launch Game. Everything Live Link sent is dropped. Resync any composite whose unsaved edits you want back.
• Throw away your unsaved edits: reopening the level in OpenCAGE without saving sends nothing to the game. The game keeps what it was sent until it loads the level again, so reload it there too.
• Switch Live Link off: clicking the Live Link button disconnects. The game keeps the edits it already has, and edits you make while it's off only reach the game once it's back on and you edit that composite again or Resync it.
• Camera: set Live Link Camera to Disabled to give the game its camera back and move the Viewport yourself.
• Breakpoints: Remove All Breakpoints on the composite toolbar's Script Debugger menu takes them all away, in the game too, and Continue lets held scripts go on.
• Stop the game serving Live Link: the runtime utils stay in the game folder between runs, so untick Live Link and start the game from Launch Game once.

While connected, you can trigger any of an entity's methods in the running game, from two places:

• The Entity Inspector. With one entity selected, the Entity Inspector's toolbar starts with a ▶ Trigger Method drop-down. It lists every method the entity has by name, its own and those it inherits (start, stop, pause, resume... on a DebugTextStacking). Pick one to trigger it.
• The flowgraph. Right-click a method pin, an input on the left of a node, and choose Trigger 'pin' in Game, below Set Delay and Clear Delay: Trigger 'start' in Game on a DebugTextStacking's start, say. It works on a composite instance's method pins too (Trigger 'Fire' in Game on an instance with a Fire method). It isn't offered on outputs, data pins or a node's body.

Both send the same call. It's carried out in the game on its next frame, just as if a link had fired into that pin. It goes to the instance you reached by stepping down from the level's root composite (the path at the top of the composite panel). If you opened the composite on its own from the Composite Browser, it goes to every running instance of it.

A call waits for the edits you made just before it to reach the game first, so you can add an entity and trigger its start straight away. The status bar says Live Link: calling "start" on entity... while it waits, then Live Link: called "start" on entity (ending (every instance) when it went to every instance) or Live Link: could not call "start" on entity - and the reason. One call goes at a time: trigger another before the game has taken the last one, and the status bar says Live Link: still waiting for the game to take the last call. The drop-down doesn't appear when several entities are selected, or for an entity with no methods (a composite's parameter entities, say), and neither appears while Live Link isn't connected.

If a call fails, the status bar says why:

• Not called, as the edits made before it have not reached the game yet: the level is still starting. The edits go in by themselves, so call again once it's being played.
• The entity is not in any running instance of the composite: the game hasn't built the entity. Its edit hasn't reached the game, it's one the game doesn't build, or the composite isn't used in the running level.
• The instance path does not resolve in the running level: the instance you stepped down through isn't in the running game, for example one added since the last save whose edit didn't reach it. Resync the composite that holds it, or open the composite on its own to call every instance.
• Composite XXXXXXXX is not in the running level: a new composite, which needs the level saved and reloaded.

While connected, the composite toolbar has a Show Activity button, with a live indicator icon, after Resync and another divider. Press it, and the flowgraph shows what the running game is doing with the composite you have open: each link lights up the moment the game uses it, orange for a logic link and blue for a data link, glowing with dashes running along it the way it went, then fades to a dim shade of its colour that stays until you clear it. Beside the pins, counts show how many times each output has fired and each method has been called. You can watch a script run as you play, see which way it went and how often, and find the links that never fire.

CCTV_Camera_Passive, reached from the level's root through ENVIRONMENT_Torrens and Torrens, with Show Activity pressed and Clear Activity beside it. Its Thinker triggers the VectorDistance many times a second, the VectorDistance reads its two inputs from the GetRotations and writes its result into the VariableFloat, and the PointTrackers at the top write into the VariablePositions every frame, so the whole page keeps glowing. The numbers in brackets are the counts so far.

• Show Activity switches it on and off. It's the same in every composite you open, and OpenCAGE remembers it for next time. Switching it off clears what was lit and the counts, and the game stops keeping track.
• Clear Activity, beside it while Show Activity is on (its icon is the same with a cross through it), forgets what has lit up and the counts so far in the composite you have open, so you only see what happens from then on. Links light up, and counts start again from nothing, as the game uses them.

Opening another composite, or stepping into another instance, starts afresh. Each of the composite's flowgraph pages lights its own links, and a page you switch to catches up straight away. If Live Link disconnects, what was lit and counted stays on the flowgraph, with Show Activity and Clear Activity on the toolbar, until you clear it or switch Show Activity off.

Keeping track costs the game very little, and next to nothing while Show Activity is off.

What Lights Up

• A logic link lights orange when its entity fires the output it leaves from. Every link out of that output lights together, as the game follows them all, and the dashes run from the output to the method it calls.
• A data link (drawn blue) lights a brighter blue when a value goes through it, either way: when the entity at its top pin reads a value through it, or when an entity sends a value out through it, such as a SetInteger writing its Result into a VariableInt's reference, or a PointTracker writing its result. The dashes run the way the value went the last time: into the entity reading it, or from the one writing it into where it's written. When that happens depends on the entity: a TriggerSelect reads its index and a SetInteger writes its Result each time they're triggered, while PointTrackers read and write every frame. Some entities also light a data link when they only look up what's linked to it, such as a list of objects they've been given.
• The composite's parameters light like any other entity: a method called on the instance from outside lights the links leading on from that parameter inside it, and links that fire out through a parameter, or pass a value through one, light too (with one exception, under Limits). In the composite that holds the instance, the links to and from the instance's node light as well.
• Aliases: a link on an alias node lights when the entity the alias points at, in the instance it reaches into, uses it.

A link that's lit but no longer glowing, a dim orange or blue, has been used since you last cleared, though not in the last second and a half. One that keeps its usual colour hasn't been used, so after playing through part of the level, those are the parts of the script that never ran (apart from the cases under Limits).

Top: links the game had just used, with the dashes running the way each one went: down from the GetRotations into the VectorDistance's LHS and RHS as it reads them, and up from its Result into the VariableFloat as it writes its result there. Bottom: the same links a few seconds after the Thinker was stopped with Trigger Method. They stay dimly lit, and the counts stay where they stopped, until you press Clear Activity. The Thinker's stop shows [1] for that call.

Counts Beside the Pins

While Show Activity is on, each pin the game uses gets a count in brackets, in bold beside its name:

• name [n], beside an output on the right of a node: how many times the entity has fired it.
• [n] name, beside a method on the left of a node: how many times it has been called, however it was called: through a link, by a TriggerSequence, or by you with Trigger Method or a pin's Trigger in Game.

A count is bright while the pin is in use, and muted once it hasn't been used for a second and a half, like the links. Counts over 9999 are shortened, to [10k], [1.2M] and so on. A composite parameter's node shows its count on whichever side its pin is drawn. If a label no longer fits beside its count, the label is cut short, never the count. The counts start again from nothing when you press Clear Activity, switch Show Activity off and on, open another composite or step into another instance.

They show how often each part of a script ran: how many times a loop went round, which way a choice went and how often, or whether something meant to happen once happened twice. Each time an output fires, the methods linked to it are called, so in the pictures above the Thinker's on_think and the VectorDistance trigger it's linked to show the same number.

Which Instance It Shows

A composite can be used in many places in a level. Like a method call, Show Activity follows the instance you reached by stepping down from the level's root composite (the path at the top of the composite panel), so you see what that one does: in the pictures above, the one camera reached through ENVIRONMENT_Torrens and Torrens. If you opened the composite on its own from the Composite Browser, it shows every running instance of it at once: a link lights when any of them uses it, including links that only some of them use, and the counts are theirs added together.

Limits

• It's drawn on the flowgraph. A composite that opens with no flowgraph pages, its links listed in the Entity Inspector instead (see Interface Overview), has nothing to light. Counts, likewise, only show beside the pins a node draws: a method called on an alias's target by a TriggerSequence, say, with no link drawn to that pin on the alias node, is counted but has nowhere to show it (an AI assistant can still list it).
• A value written into the composite's own parameter from inside. When an entity inside a composite writes a value into one of the composite's own parameters (a SetInteger's Result linked to an output parameter, say), the game never reports it, so that link stays unlit. Reading a parameter, firing out through one, and writing into an instance's parameter from the composite that holds it all light as usual.
• Links used all the time keep glowing, such as those a PointTracker reads and writes every frame. That's the game using them. A page with a lot glowing at once takes OpenCAGE longer to draw, so it's redrawn less often, and its dashes move more slowly, in bigger steps. Only the page on show is redrawn, and only while something on it glows: pages behind it, and links that have faded, cost nothing.
• Aliases into a great many instances. OpenCAGE asks the game to watch the instance you're looking at and the instances its aliases reach into, up to 512 at once, which covers even the Torrens composite in BSP_TORRENS and its aliases into 160 other composites. A composite whose aliases reach into more instances than that leaves the rest out, and the status bar says how many: Live Link: showing script activity (N instance(s) reached through aliases are left out - at most 512 at once). Alias links into those don't light, so open the composite the alias points into to watch it there. An older copy of OpenCAGE's runtime utils in the game watches 32 at most, and the status bar says so: start the game from Launch Game again, which updates them.
• Only the level you have open. As with edits, the game must be running the level open in OpenCAGE. If it's running another, the status bar says Live Link: script activity can't be shown - Another level is running, and Show Activity picks up again by itself once the game is back on your level.

OpenCAGE can stop the running game's scripts at a breakpoint. Put one on a node of the flowgraph, and the moment the game is about to call one of that entity's methods (its start, its trigger or any other), it holds the call back and stops: the level's scripts and the game's clock stop where they are, and OpenCAGE opens the composite at the instance that stopped, with the node in view and outlined. You can see which calls led there, step the scripts on a round of calls at a time, or let them carry on.

It works over Live Link, with the game started with Debug Menu ticked in Launch Game as well as Live Link. The breakpoints are kept by the Debug Menu in the game, but you don't need to open its window. Without the Debug Menu, the breakpoints you set stay in OpenCAGE, drawn as rings, and go into the game the next time it's started with it.

Held at a breakpoint on a CCTV camera's VectorDistance, which its Thinker triggers every frame. The node is outlined, and Continue, Step and where the scripts are held sit on the composite toolbar.

Setting Breakpoints

Right-click a node and choose Set Breakpoint, the last item on its menu, or hover over the node and press F9. With no node under the mouse, F9 sets one on each selected node (up to 16 at a time). A red dot appears on the node's top-left corner. Do the same again to take it away: on a node with a breakpoint, the menu item reads Remove Breakpoint.

A breakpoint on a node stops before any of its entity's methods is called: the same methods Trigger Method lists. To stop on one method only, right-click its pin on the left of the node and choose Break on 'method' (Break on 'trigger', say), under Trigger 'trigger' in Game. It's ticked while the breakpoint stops on that method, and choosing it again takes that method off, and the breakpoint with it if it was the last. The items aren't offered on a node that has no methods, or on the composite's own parameters.

Like a method call, a breakpoint goes to the instance you reached by stepping down from the level's root composite (the path at the top of the composite panel), or, if you opened the composite on its own from the Composite Browser, to every running instance of it. A node shows a breakpoint set on its entity in any instance, and Remove Breakpoint takes away the one it shows.

The dot says where the breakpoint stands:

• A red dot: the game stops on it.
• A red ring: it's set, but isn't stopping the game. Live Link isn't connected, the game was started without the Debug Menu, or the game can't find it in the running level: its composite isn't in it, that instance isn't running, or another level is. The Script Debugger menu says which.
• A grey dot: it has been switched off in the game, with its own box on the Debug Menu's Scripts > Debugger tab.

The status bar says what the game did with each one you set, such as Live Link: Breakpoint on entity - in 1 running instance(s), 3 method call(s) to stop on. You can set them before Live Link connects: they're kept, and set in the game once it can take them.

Breakpoints belong to the level open in OpenCAGE: opening another level starts with none, and the game only stops on them while it's running the level they were set for. They aren't saved with the level, or put on the undo history. The game keeps the ones it has until it closes, so if OpenCAGE is closed and opened again while the game runs, they come back once Live Link reconnects (see Limits for the one thing to switch back on).

When a Breakpoint Is Hit

• In the game, everything stops, as it does for the pause menu (the mouse cursor shows, though no menu opens), and a line along the top of the screen says Scripts held at breakpoint n (method on entity) - Continue in OpenCAGE, or the Debug Menu's Scripts > Debugger, with the entity named as OpenCAGE names it (the game itself keeps no entity names, so OpenCAGE sends the name with the breakpoint). The call the game was about to make is held back, not lost: it's made first when the scripts go on.
• In OpenCAGE, unless Jump to Node When a Breakpoint Hits is off, the composite opens at the instance that stopped, stepped down to from the level's root, with the entity selected and its node in view, outlined in yellow with an arrow pointing at its title. If OpenCAGE isn't in front, its taskbar button flashes: the game keeps the screen. The status bar says Live Link: scripts held at a breakpoint - 'method' on entity in composite (Continue: F8, Step: F10 on a flowgraph).
• On the composite toolbar, after the Script Debugger menu, come Continue and Step buttons and an orange label, Held: 'method' on entity in composite. Hover over the label to see the calls that led there, latest first: the method call whose output led to the held call, the one that led to that, and so on (up to eight). Click the label to go back to the node.

While the scripts are held, your edits and method calls wait, as they do while the game is paused (see Level Start & Pause), and go in as soon as the scripts go on.

Continue, Step & Pause

• Continue (F8 on a flowgraph) lets the scripts go on from the held call, and the game with them. A breakpoint on something that's called all the time, such as an entity a Thinker triggers every frame, stops the game again straight away, so take it away first if you're done with it.
• Step (F10 on a flowgraph) makes the held call and every other call due at the same moment (one round of calls), then stops again. Each step makes the next round. A round takes in calls from every script in the level, not just the one on screen. The label reads Held after a step, and OpenCAGE keeps showing the node the breakpoint was on; if a step reaches another breakpoint, that node is shown instead.
• Pause the Game's Scripts, on the Script Debugger menu, stops the scripts and the game straight away, as a breakpoint would. The label reads Scripts paused; Continue or Step from there.

F8 and F10 only work while the scripts are held, with a flowgraph page taking the keyboard (click it first). The status bar says what the game did, such as Live Link: continued. The Debug Menu's Scripts > Debugger tab has the same controls in the game, and one more: Step frame, which lets one whole frame of the game run, scripts and all, then stops again.

The Script Debugger Menu

While Live Link is connected, or while breakpoints are kept for the game, the composite toolbar has a Script Debugger menu after Show Activity (and Clear Activity, while activity is shown) and a divider. It shows how many breakpoints there are, such as Script Debugger (2), and hovering over it says whether the debugger can be used now, or why not. Each item has an icon, and the two that are options, Show Live States Above Nodes and Jump to Node When a Breakpoint Hits, have a frame round their icon while they're on. It has:

• Go to Breakpoint: each breakpoint, by its composite and entity, ending (every instance) for one set in every instance, and with how many times it has been hit. A breakpoint that's stopping the game is ticked. Hover over one to see the methods it stops on and how many running instances it's in, or why it isn't stopping the game; click one to go to its node.
• Remove All Breakpoints, in the game too.
• Show Live States Above Nodes: see Live States.
• Select Entity Under Game Crosshair: see Select Entity Under Game Crosshair.
• Pause the Game's Scripts: see Continue, Step & Pause. It's greyed out while the scripts are held.
• Jump to Node When a Breakpoint Hits, on to start with: a breakpoint hit brings its node to the front. Turn it off to leave the composite panel where it is when a breakpoint is hit; the toolbar label still says where (click it to go there). It's on again the next time OpenCAGE starts.
• Runtime Error Log: opens the Runtime Error Log.

Live States

With Show Live States Above Nodes turned on in the Script Debugger menu, each node of the flowgraph page on screen gets a dark strip above it, showing its entity's state in the running game, read twice a second: Started, Paused, Enabled, Locked, Opened, Closed, On, Updating, Suspended, Invisible or Frozen, (idle) when it's none of these, and Not initialised before the game has set it up. Under that come the values its data pins (those on the top and bottom of the node) read in the game now, as pin = value: true or false, numbers, text, positions and colours, enums and resources. While a breakpoint holds the scripts, it's the state they stopped in.

A strip shows up to six lines, only the first once you zoom out a little, and nothing once you're zoomed well out. The composite's own parameters don't get one. It's shown for one running instance: the one you stepped down to from the level's root. A composite opened on its own from the Composite Browser only shows states while one instance of it is running; with more, the status bar says Live Link: live states can't be shown on composite - more than one running instance: open the composite from the level's root to see one.

Reading a data pin works its value out as the entity itself would, following the links into it. An entity whose value changes every time it's worked out, such as a random number, can give a new value each time it's read, so a script can behave a little differently while Show Live States Above Nodes is on. OpenCAGE doesn't remember it for next time.

Select Entity Under Game Crosshair

Select Entity Under Game Crosshair, on the Script Debugger menu, finds the entity under the game's crosshair. In the game, tick Crosshair inspector on the Debug Menu's World > Inspect tab and aim at something: a door, a light, a prop. Then choose Select Entity Under Game Crosshair, and OpenCAGE opens the composite that holds it, at the instance it's in, stepped down to from the level's root, with the entity selected and its node in view. It's greyed out while Live Link isn't connected.

If it can't, a message says why: there's nothing under the crosshair, what's under it isn't a script entity, or the entity is in an instance the level open in OpenCAGE doesn't have, which usually means the game isn't running the level as saved.

In the Game

The Debug Menu's Scripts > Debugger tab shows the breakpoints as the game has them: whether the scripts are running or held, the held call (its method and entity, the composite and instance it's in, and the calls that led to it), with Continue, Step, Step frame and Pause scripts buttons, then every breakpoint, with a box to switch it off and on, how many running instances it's in, how many times it has been hit, and a Remove button. Stop at breakpoints switches them all off without taking them away, and Remove all takes them away. Breakpoints are set from OpenCAGE: the tab has no way to add one. See the Debug Menu.

The game held at the same breakpoint, with the Debug Menu open on Scripts > Debugger.

Limits

• It stops on method calls. A breakpoint stops the game before a method is called, not when an output fires or a value is read, so there's no breakpoint on a link. Entities with no methods, and the composite's own parameters, can't have one.
• A step is a round of calls, not a single call: everything due at that moment, all over the level.
• The whole game stops, not just the script you're looking at, and stays stopped until something lets it go on: OpenCAGE, the Debug Menu or an AI assistant.
• How many. A breakpoint set in every instance covers up to 64 running instances, and the game can stop on up to 256 method calls for all the breakpoints together (one for each method in each instance).
• Switching Live Link off, or closing OpenCAGE, lets held scripts go on and unticks Stop at breakpoints in the game, so a game left on its own never stops with nothing to let it go on. The breakpoints stay. The next time Live Link connects to that game, from this OpenCAGE or a new one, OpenCAGE ticks Stop at breakpoints again itself once it has read the level's breakpoints back from the game, and they stop the game again. If you unticked Stop at breakpoints in the game yourself, it's left off.
• A level loading lets go. If the game loads a level, or loads the same one again (restarting from a checkpoint), while the scripts are held, they're let go, so the level can start.
• Game releases. If the game's release can't take breakpoints, the Scripts > Debugger tab says Script breakpoints are not available on this game release.

The game checks that the level's script entities are set up properly as it runs them - a pickup spawner that names no item, a door with no animation, an animation set missing the animation asked for, a zone link the wrong way round - but the retail game never says what it finds. The Runtime Error Log shows it, like a game engine's console: each failed check (with an amber sign) and error (with a red one) as it happens, with the entity it's about, the composite that entity is in, and the time on the level's script clock.

Tick Error log (under Live Link) in Launch Game and it opens as the game starts. You can open it yourself from the Script Debugger menu too, while the game is connected, though the game only notes its errors when started with Error log or the Debug Menu ticked.

Three tannoy Speech entities added to TECH_HUB over Live Link with nothing to speak through, then started: the game's check of each fails as it plays. The first error is selected, so the bottom of the window shows it in full.

• Double-click an error (or select it and press Enter) to go to its entity: the composite it's in opens, stepped into from the level's root the way the game reached it, with the entity selected. The bottom of the window shows the selected error in full.
• Warning signs. While the log is open, every flowgraph node whose entity has an error in it shows an amber warning sign on its top-right corner, as a breakpoint shows a red dot on the top-left.
• Clear, on the left of the toolbar, empties the log, and the warning signs go with it. Closing the window does the same.
• The two settings are on the right of the toolbar, and OpenCAGE remembers both:
  • Clear on Play, on unless you turn it off, empties the log each time the game is started from OpenCAGE, so it only ever shows the run in front of you. Turned off, errors from earlier runs stay until you clear them.
  • Group by Entity lists the errors under the entities they're about, each with how many it has, instead of one after another.

The same three entities on their flowgraph page, each with the warning sign while the log has its error. The counts beside start are Show Activity's.

Grouped by entity, each heading says how many errors that entity has.

The game keeps its latest 2048 errors, across levels, until OpenCAGE asks for them, twice a second; if more come at once than that, the bottom of the window says how many were missed. An error from a level other than the one open in OpenCAGE is listed, but going to it says it happened elsewhere. The Debug Menu's Scripts > Errors tab shows the same errors in the game.

While connected, the Viewport toolbar has a Live Link Camera drop-down, after Highlight Zones. It links the Viewport's camera to the game's, one way or the other. It's on Disabled each time Live Link connects, so the game starts out on its own camera and the Viewport stays where you left it until you pick a sync. While either sync is on, the button shows pressed, and hovering over it says which way the cameras are linked.

• Disabled: the game's camera and the Viewport's each move on their own.
• Sync viewport camera to game: the game draws the level from the Viewport's camera (where it is, which way it looks, and its vertical field of view), and what you hear comes from there too. Fly around the Viewport and the game goes with you. The zones around the camera stream in as it moves, as they would around the player, so you can go anywhere, not only near the player (zones only stream in while the game is running, not while it's paused). It works in gameplay, in cutscenes and in the pause menu, and the overlay in the game says Camera: following OpenCAGE.
• Sync game camera to viewport: the Viewport shows what the game's camera sees, field of view included, so you can play the level and watch it in the editor at the same time. The Viewport's camera can't be moved by hand meanwhile (flying, looking, panning and focusing do nothing).

The game drawing a corridor on the Torrens from the Viewport's camera. The overlay in the top-right corner reads Camera: following OpenCAGE.

The other way round: the Viewport following the game's camera.

Both follow only while the Viewport shows the level itself (its root composite, or a composite you stepped into from there) and the game is running the level you have open. The game gets its own camera back when you choose Disabled, when Live Link disconnects, or when you open another composite on its own. The player's camera is never moved, so the view goes straight back to it.

With Sync game camera to viewport, the Viewport's camera stays locked for as long as that choice is on and Live Link is connected, even when it has nothing to follow, as in a composite opened on its own: open the level's root composite to see the game's view again. Choose Disabled to move the Viewport yourself again.

Game logic sees the Viewport's camera too. While the game draws from the Viewport's camera, anything that checks what the player's camera sees reacts to it instead: camera viewcone triggers, the alien's checks for whether it's in view, and AI conditions on the camera's direction. It's the same with the Debug Menu's free camera, so bear it in mind when testing things that depend on being seen.

The Debug Menu's free camera, in its Cinematic group (which replaced Cinematic Tools), runs alongside Live Link. While it's on, it has the game's camera: a game following the Viewport's camera stops following it until the free camera is turned off, and on Sync game camera to viewport the Viewport follows the free camera. Possess Characters runs alongside Live Link too: while the game follows the Viewport's camera, that camera wins over the one behind the character you're steering.

Keep your mouse cursor. While a level is played, the game normally takes over the mouse cursor, which gets in the way of flying the Viewport beside it. Tick Unlock mouse in the Launch Game window's Game options and the game leaves the cursor alone. When you want to look around in the game itself, click its window and press the Unlock mouse key (F4 unless you chose another); press it again to free the cursor.

An EnvironmentMap entity gives the models it's linked to a cubemap to reflect: a picture of the room all around a point, taken from where the entity is. When you change a room, its reflections still show the room as it was. Live Link can take a new one in the running game, showing the room as it is now.

While connected, select an EnvironmentMap entity and press Capture in the Entity Inspector (the button that reads Function for most entities; it's greyed out while Live Link isn't connected, and reads Capturing... while a capture runs). It takes a few seconds:

1. The game moves its camera to the entity's position and streams in the zones around it (the overlay in the game says what it's waiting for).
2. It draws the six views of a cube from there, each 90 degrees wide (+X, -X, +Y, -Y, +Z, -Z), and sends them to OpenCAGE. The game's HUD is hidden while it does, and so are the lens effects that don't belong in a reflection: film grain, vignette, chromatic aberration, lens distortion and depth of field. Then the game gets its camera back.
3. OpenCAGE builds a cubemap shaped like the game's own: the size and format of the one it replaces (the game's are all 128 × 128 faces, nearly all in DXT1), with mip levels down to 2 × 2, each level blurred more than the last the way the game's are, so rough surfaces show a soft reflection and shiny ones a sharp one.
4. It's added to the level's textures as ayz\env\cubemaps\level\composite\composite_entity.dds (with a number on the end if that's taken), and the entity's Texture is set to it.
5. The cubemap the entity used before is deleted if nothing else uses it: no other entity names it, no material uses it, and it isn't one of the GLOBAL textures every level carries. The models that were reflecting it are given the new one.

To capture at another size, pick one under Options > Misc > Cubemap Capture Size: 64, 128, 256 or 512 pixels a face, or Same as the Cubemap Replaced (the default). A bigger cubemap gives mirror-like surfaces a sharper reflection, and leaves rough ones as blurred as before. The faces are cut from the game's picture, so its window needs to be at least as tall as them; if it isn't, they're stretched up and the status bar says so.

It's one step on the undo history: undo takes the new cubemap out and puts the old one, and the entity's Texture, back. The status bar says Live Link: Captured entity's cubemap at (x, y, z) as texture, or why it couldn't.

To see it in the game, save, then load the level again: the game reads cubemaps when it loads a level. If the old cubemap is still used by another EnvironmentMap, the models this one lights keep it until a Save & Build works out again which cubemap each model reflects, and the status bar asks for one.

File > Recapture All Cubemaps, below Export Composites, does the same for every EnvironmentMap in the level, one after another, with a progress bar (a few seconds each: a level with 50 takes about four minutes). Keep the game running and unpaused meanwhile; the editor stays usable. Choose it again (it reads Stop Recapturing Cubemaps) to stop after the one being captured. It stops by itself if the game turns a capture away, and skips any EnvironmentMap whose composite is used in more than one place, or not at all. Each cubemap is its own step on the undo history, and a summary at the end says how many it captured, which it couldn't and why, and whether to save or Save & Build.

The capture is taken from where the entity is in the level: through the instances you stepped down through from the root composite (the path at the top of the composite panel), or, if you opened its composite on its own, the one place that composite is used. A composite used in more than one place has to be opened from the root, so OpenCAGE knows which one to take it from.

• Capture with the game running. Zones don't stream in while the game is paused, so a capture is turned away while the pause menu is open, and stops if the game is paused part way through.
• The game ignores its keyboard and mouse while it captures, so clicking into its window to watch doesn't move or turn the player, and the cursor stays free over it (as with Unlock mouse). Escape still works: press it in the game to stop a capture, as the pause menu ends it. A gamepad isn't held back.
• It shows the room as the game draws it now: lights that are off, doors that are shut and anything else in the level's current state are in the picture. The game's own cubemaps were made when the level was built, under its lighting then, so a new one often looks darker or a different colour from the one it replaces.
• Anything right next to the entity fills part of the picture, as it would a mirror there. Move the entity if something gets in the way.
• Game logic sees the capture's camera for those few seconds, as it does the Viewport's camera with Live Link Camera: anything checking what the player can see reacts to where the capture looks.

Three of the configuration editors change the running game as you edit them: Radiosity, Hair and Skin Shading, and Global Constants (the glow round things the player can use, the stealth light meter, the interaction distance, and the squad and suspicious item timings).

Without Live Link, a change there reaches the game the next time it loads a level, when it reads the settings files again. While Live Link is connected, each change also shows in the running game as you make it, so you can tune the bounce light or the hair shading while looking at the result. The line at the bottom of each editor says which applies, or why the game didn't take a value.

• The bounce light settles rather than snapping: the radiosity builds on its own last result, so First Bounce, Multi Bounce and the albedo settings take a moment to reach their new look. Emissive Surface Scale and Specular Gloss Scale show on the next frame. Emissive Surface Scale changes how brightly emissive surfaces glow, as well as the light they bounce.
• Hair and skin only show on characters close to the camera: try a cutscene, or Live Link Camera pointed at a face.
• Values last until the game loads a level, when it reads the files the editors have saved them to, so nothing jumps back.

Three more editors work with the running game the same way, but read whole files: Alien Configs, Difficulty Settings and Viewcones. The game reads those only when it starts, so without Live Link a change there needs the game restarted. With Live Link connected, and the game started with the Debug Menu on (it does the reading), each change has the running game read the folder again a moment after you make it, and the alien, every character or the view cones take up the new values (see Config Files). The line at the bottom of each editor says how it went: the files read again and how many characters took them up, why not (a file missing or being written, the Debug Menu off), or that the game will do it once it's running again (paused, or no level loaded). Opening the editor, or picking another entry in it, changes nothing the game reads, so nothing is sent then.

When the game was started with both Live Link and the Debug Menu, OpenCAGE can work the Debug Menu from outside the game. The script debugger, Select Entity Under Game Crosshair and Show Live States Above Nodes work this way, and an AI assistant can do nearly anything with the menu that you can in its window:

• See what it holds: whether its window is open, the group and tab in front, the selected character, its groups and tabs, and every one of its switches, values and commands, by name.
• Open or close the window, and bring a tab to the front by its name (or a group, by the group's name).
• Select a character: the first whose name, or failing that whose class, has the text given in it, such as alien or player.
• Turn a switch on or off. The menu's tick boxes have names, such as characters.labels for the labels over the characters' heads, game.dont_write_saves for Don't write saves, or cinematic.camera for the free camera.
• Set a value to a number, kept within the range the menu allows, such as game.speed, the game's speed.
• Run a command, with the text it takes, and get back what it answers. Commands do what the menu's buttons do, and give its lists: game.jump_checkpoint and cinematic.go_to, say. The command help lists every one, with what it takes.

There are a few hundred of these. Each name starts with the part of the menu it belongs to: characters., ai., game., render., cinematic., debugger. and so on.

Running a command puts Debug menu: command on the line under OpenCAGE Live Link in the top-right corner of the game for a few seconds, as an edit does. Commands that only report leave that line alone: help, the lists, a status or state, and the reads the script debugger and Show Live States Above Nodes make several times a second. Opening or closing the window, picking a tab or a character, and setting a switch or value leave it alone too.

If the game was started without the Debug Menu, it answers The debug menu is off in the game: start it again from Launch Game with Debug Menu ticked. If its runtime utils are older than OpenCAGE, the answer says they're too old for the Debug Menu: starting the game from Launch Game again updates them.

An AI assistant connected to OpenCAGE can use Live Link too. Its script edits go to the game automatically, as yours do, and it has tools of its own:

• runtime_utils: the connection's status, connect and disconnect; what the game is running and where its camera is; push a composite; call a method on an entity; hold or play a CAGEAnimation in the game, as Animation Mode does (animate); describe a composite's running instances; take a screenshot of the game; load a level; and Show Activity (activity): switch it on or off, clear it, or list the links the game has used in the open composite, with how often and how long ago, and how many times each output fired and each method was called.
• set_viewport_view with live_link_camera: the Live Link Camera choice, disabled, viewport_to_game or game_to_viewport. Set it after connecting: it goes back to disabled whenever Live Link connects.
• set_viewport_camera: puts the Viewport's camera at a position and direction, and the game's with it while the game follows the Viewport.
• capture_environment_maps: captures cubemaps for one or more EnvironmentMap entities, a composite's, or every one in the level, one after another, with the same steps as the Capture button (all_in_level is Recapture All Cubemaps). It can also take a face size (otherwise Cubemap Capture Size's, which editor_options sets too), a format, how long to wait for zones, and keep the HUD, the lens effects or the old cubemaps.
• runtime_utils with settings: reads, or changes in the running game only, the numbers from the radiosity, skin and hair shading, selection overlay and global constants settings files (see Live Settings). A change made this way lasts until the game next loads a level, as the files themselves aren't changed. With file alien_configs, difficulty_settings, viewcones or ai_configs (all three), it has the running game read those folders again from the files as saved instead (with the game started with the Debug Menu on).
• runtime_utils with debug_menu: works the Debug Menu in a game started with it, as under The Debug Menu Over Live Link. menu is report (the default), open, close, tab, select, set (a switch, to value), value (a value, to number) or run (a command, with argument), and name names the tab, character, switch, value or command.
• runtime_utils with debugger: the script debugger. It sets and removes breakpoints (on an entity, or one of its methods, in one instance or every instance), lists or clears them, reads where the scripts are held and the calls that led there, continues, steps a round of calls or a whole frame, pauses, selects what's under the game's crosshair as Select Entity Under Game Crosshair does, and reads the live states of a composite instance's entities. The breakpoints an assistant sets are drawn on your flowgraphs, and the ones you set are in its list.
• launch_options with live_link: the Live Link box; debug_menu and debug_menu_key: the Debug Menu box and its key; dont_write_saves: Don't write saves. The old cinematic_tools is still taken, as debug_menu.

AI Assistants has more on each.

• There's no Live Link button. It only appears while this install's game is running and serving Live Link (or while OpenCAGE is connected), and only for the Steam, GOG and Epic Games Store versions. If the game is running, it wasn't started with Live Link, or it's from another game install: close it and start it from Launch Game with Live Link ticked.
• "The game is running a different level". The game has a different level loaded from the one open in OpenCAGE. Save, and load the same level in the game, or start the game again from Launch Game with that level picked.
• Edits or calls are "waiting". The level is still starting, the pause menu is open, a cutscene or an on-screen message has paused the level (close the message in the game), the game is restarting from a checkpoint after a death, the script debugger is holding the scripts (Continue them), or the Debug Menu's Pause is holding the game. See Level Start & Pause.
• The game has stopped, with "Scripts held at breakpoint" along the top. A breakpoint was hit, or Pause the Game's Scripts was used. Press Continue on the composite toolbar (or F8 on a flowgraph), or in the game, open the Debug Menu and press Continue on its Scripts > Debugger tab. If it stops again straight away, the breakpoint is on something called all the time: take it away (F9 on its node, or Remove All Breakpoints on the Script Debugger menu) before you continue.
• A breakpoint is a red ring, and never stops the game. Hover over it in the Script Debugger menu's Go to Breakpoint list to see why. Usually the game was started without the Debug Menu (start it again from Launch Game with Debug Menu ticked), or the instance it was set in isn't running: open the composite from the level's root to set it in the instance the game runs, or on its own to set it in every instance. If it says breakpoints are switched off, tick Stop at breakpoints on the Debug Menu's Scripts > Debugger tab.
• "No level is running". The game is between levels, or unloading one. Load the level in the game, then Resync what you changed.
• "The game's runtime utils are too old to follow the viewport camera" (or too old for the viewport to follow the game camera), from Live Link Camera. The game is running an older copy of OpenCAGE's runtime utils. Start it from the Launch Game window again, which updates them.
• "Unsupported Live Link protocol (OpenCAGE and the game's OpenCAGE.RuntimeUtils.asi are different versions)". The runtime utils in the game folder don't match this OpenCAGE, usually after an update. Start the game from Launch Game again, which replaces them.
• "The game is running but not serving Live Link". The game wasn't started with Live Link, another OpenCAGE window is already connected, or another copy of the game is serving Live Link (OpenCAGE.RuntimeUtils.log then says it could not listen on 127.0.0.1:8765). Close the others and start the game from Launch Game.
• An edit didn't show up. Check the status bar for what the game said (see below). A new composite, a model placed on its own, or a change to a model, material, texture or other resource, needs the level saved and reloaded. Edits made before connecting need a Resync.
• My live edits have gone from the game. The game loaded the level again from disk, which only has what you've saved. Resync each composite you changed, or save and start the game again.
• Show Activity lights nothing. The script hasn't run since you switched Show Activity on or cleared it: play up to it, or set it off by triggering a method. Check you're watching the instance that runs (open the composite from the Composite Browser to watch every instance of it), and that the composite has flowgraph pages. If the status bar says the game's OpenCAGE.RuntimeUtils.asi is too old to show script activity, the game is running an older copy of OpenCAGE's runtime utils: start it from Launch Game again, which updates them. See Limits for the rest.
• Something stopped when I edited it. Edited entities are re-initialised, so start it again (trigger its start).
• The game closed when I saved. Saving always closes the game. Start it again from Launch Game. With Options → Misc → Open Game On Save ticked, OpenCAGE starts it again by itself once the save is done, and Live Link reconnects.

The game also writes what Live Link did (every edit applied, call made or request turned away) to OpenCAGE.RuntimeUtils.log in the game folder. OpenCAGE's status bar messages clear after a few seconds, so the log is where to look for one you missed. It's started afresh each time the game starts, so read it before starting the game again.

What the Status Bar Says

Each edit the game answers puts a line on the status bar, starting Live Link: composite -, for a few seconds:

• Applied to N instance(s): … added, … removed, … modified: done. 0 instance(s) means the composite isn't used anywhere in the running level, so nothing visible changes.
• … N of those modified because a data link into them changed: you made or broke a data link, so the entity the value goes into was re-initialised to read it (a link into one of the composite's variables doesn't do this).
• … N of the composite's variables added, removed or changed: counted apart from the entities. Instances of the composite are re-initialised to pick up changed defaults. When it ends save and reload to use changed ones, the composite is the level's root (see What Needs a Reload).
• Unchanged since it was last applied: nothing to do.
• Composite XXXXXXXX is not in the running level - save and reload the level to add new composites: see What Needs a Reload.
• … not built, as a level load would not build them: not an error. The game leaves these entities out when it loads the level too. A model placed on its own is one of these until you Save and Build and load the level again.
• … could not be constructed - they are tried again on the next push: the game couldn't make an entity (an unknown type, or a proxy whose target is missing). Fix it and edit the composite again, or Resync.
• Its resource references changed … need the level saved and reloaded: the rest of the edit went in. A new LightReference brings this up too, and its light works anyway.
• Could not swap the composite's data in … - reload the level: save, and start the game again.
• The game did not answer: nothing came back within 30 seconds. Check the game is still running and not stuck on a loading screen, then Resync.

• Launch Game — the Live Link box and the rest of the Debug tools, the Debug Menu among them
• Cathode Scripting Introduction — the Entity Inspector, and scripting in general
• Viewport — moving the Viewport's camera
• Save and Build — for changes that need a reload
• AI Assistants — driving OpenCAGE from an AI assistant
• Debug Text & Markers — putting text, script values and markers on screen in the game
• Debug Menu — the in-game debug menu, which the script debugger runs in
• DebugTextStacking — handy for trying Live Link out