Use per-session catalogs when multiple players/controllers or progression states share one game but should not have the same choices. Each PlacementSession carries its own catalog, and the selection UI populates from the active session's catalog.
GridPlacementBundledefines what the game can place.PlacementSession.catalogdefines what one session can use now.- Catalog filtering changes availability, not committed world occupancy or placement rules.
Setup: one catalog per session
Give each player/controller its own session with its own catalog resource. A common pattern is one master catalog duplicated per session, with entries removed or locked as progression changes:
var session:= PlacementSession.new()
session.grid_placement_bundle= preload("res://config/grid_placement_bundle.tres")
session.catalog= preload("res://catalog_player_one.tres")
host.register_session(self, session)Give each player/controller its own session when availability differs. Sessions that build in the same world still share committed occupancy.
Locking individual entries
ScenePlacementEntry.catalog_locked marks a single entry as locked. The selection UI renders locked entries as locked instead of hiding them, so players can see what is not yet available:
entry.catalog_locked= truecatalog_locked lives on the entry resource itself. If two sessions share one catalog resource, locking affects both — use separate catalog resources when sessions need independent availability.
Terrain availability
Terrain choices resolve catalog-first through TerrainCatalogFilter: when the session's catalog has tile_entries, those are the canonical selectable terrains and the palette acts as display theme (icons + colors). When the session has no catalog, the palette entries are used as the legacy fallback.
Boundaries
Per-session catalogs do not provide network authority, ownership permissions, or separate committed worlds. See Multiplayer & Split-Screen.