4. Object Placement and Removal

A level’s .pcc does not merely contain a list of visible objects. It contains placed actors, references to the assets those actors use, and the level structures that tell the game those actors belong in the world.

For Ghost in the Machine, our first object-placement work will reorganize the final rooms of Luna’s three bunkers. This gives each bunker a clear module-installation point and prepares separate rooms for optional evidence and the final encounter with Hannibal.

What a placed object contains

A visible object in a level is generally represented by an actor. That actor records information such as its position, rotation, scale, components, and properties.

A simplified relationship looks like this:

Level
└── Placed actor
    ├── Transform
    ├── Mesh component
    │   └── Mesh asset
    ├── Collision
    └── Behavior or interaction references

The actor must also be included in the appropriate level’s actor collection. An export can exist inside the package without appearing in the game if the level does not include it among its actors.

Which assets are available?

An asset does not always have to be stored inside the level’s own .pcc. A placed actor can use:

An asset existing somewhere in the game does not automatically make it available to every level. The target package must be able to resolve the reference when the level is loaded.

For initial work, prefer actors and assets already used by the target .pcc. Cloning an existing object within the same package avoids many dependency questions because the level already knows how to resolve its mesh, materials, collision, and related classes.

A visible object is not necessarily interactive

Placing or cloning a console’s mesh may create only scenery. Its interaction can depend on additional objects and connections, such as:

Treat visual placement and gameplay interaction as related but separate tasks. First prove that the object appears in the intended location. Then identify and connect the objects that make it usable.

Our first Luna layout

The repeated final corridor in each bunker will establish a consistent layout.

In every bunker, the left-hand room becomes a restoration room. We will remove its satellites and existing destructible power junctions, then place one power junction at the center of the far wall. In the revised story, this object represents modular computing and memory hardware rather than a literal power junction. Shepard will eventually use it to install one recovered module.

The initially locked right-hand rooms serve different purposes:

Facility Control will eventually unlock the two archive rooms. Hannibal’s room remains locked until all three recovery modules have been installed.

Safest first experiment

Begin with one left-hand restoration room in one bunker:

  1. Identify the room’s satellite actors and existing power-junction actors.
  2. Record their export numbers, full paths, transforms, components, and Kismet references before changing anything.
  3. Remove or disable the satellites and unwanted junctions.
  4. Clone one existing power junction already used in that package.
  5. Move the clone to the center of the far wall.
  6. Confirm that it belongs to the correct level’s actor collection.
  7. Save the package and inspect the installed, highest-mounted copy.
  8. Load the bunker and verify only the visual layout.

Do not add module installation behavior during this first experiment. A visible, correctly positioned junction proves that object removal, cloning, placement, package installation, and level loading all work. Interaction can then be added as the next independently testable layer.

Details still to confirm

As we perform this work in Legendary Explorer, this tutorial still needs exact instructions for:

These instructions should be filled in from the actual Luna edit rather than guessed in advance.