Hangar & Garage Runtime

Hangar ownership layers

Readiness is a conjunction

The current HangarSpace deliberately exposes separate signals. Its service can be initialized while geometry is loading; the space can exist while the vehicle model is still rebuilding; a scene group can be active before its CGF anchors or camera components appear.

Space and vehicle lifecycle

Current source fires onSpaceCreating after starting creation. When the engine-space completion callback runs, it marks spaceInited, fires onSpaceCreate, reports the hangar-ready milestone, and then completes any separately requested vehicle work. Vehicle recreation clears isModelLoaded; the vehicle-loaded callback restores it and fires onVehicleChanged.

1. Subscribe once and first inspect the current state so a late subscriber does not miss an already-completed load.
2. Bind pending work to the current space ID, selected vehicle identity, and visible route.
3. Cancel callbacks before space destruction, account exit, or feature shutdown.
4. On a space refresh, discard camera, CGF, entity, appearance, collision, and model references from the previous space.

# Pseudocode — private names are build-dependent.
def try_apply(context):
    space = dependency.instance(IHangarSpace)
    if not space or not space.spaceInited or space.spaceLoading():
        return RETRY
    if context.space_id != space.spaceID or not context.route_is_owned():
        return STALE
    if context.needs_vehicle_model and not space.isModelLoaded:
        return RETRY
    return apply_to_current_space(space)

Native subhangar groups

Native lobby scenes commonly reuse the current hangar space by activating named groups. The current SubhangarObserver derives groups from entered lobby-state groups, queues activation and deactivation, waits for the hangar space, updates the environment, calls the native Hangar.activateGroup or Hangar.deactivateGroup functions, and then hands the configured camera to HangarCameraSystem.

• Borrow an existing group only through the current space and route lifecycle; do not infer a standalone space path from a group or feature name.
• Group activation proves only that the activation request ran. Verify any required camera, game object, selection component, or transform separately.
• Keep a native group only while the feature owns the visible scene. A global deactivation block can break the native feature that owns the same group.
• Restore hidden or moved native objects before returning ownership. They may participate in click, preview, camera, or progression behavior.

Route ownership and handoffs

The visible route decides which scene owner should win, but release may need to happen before the destination becomes visible. Customization, Vehicle Hub, armor inspection, missions, previews, and post-battle results may read the normal vehicle bounding box or activate their camera, lighting, environment, and scene groups during the transition.

When the visible-route callback is too late, inspect the lobby state machine's navigation request and the destination state's entry path. Patch the narrowest owner and preserve unknown routes, parameters, return values, and other wrappers.

Replacement and synthetic spaces

A replacement garage is a different integration from a native subhangar. Current space creation resolves the configured default or event path, reads hangar settings, chooses a visibility mask, creates a hangar BigWorld space and HangarVehicle, maps geometry, initializes camera state, and reveals the world through the loading flow.

• Apply a default-space override before the account GUI resolves its first hangar; a late override may affect only a later refresh.
• Keep every default-space owner consistent. Another switch controller or event path can restore the native scene during vehicle loading.
• Start from the current default configuration and replace only fields the feature owns, rather than inventing camera, visibility, or vehicle-anchor defaults.
• Use the target mode's intended visibility mask; enabling every layer can reveal incompatible objects.
• Return to a native hangar before routes that require native camera, collision, selection, or feature CGF systems.

Selected vehicle, cameras, and CGF

• The inventory vehicle owns configuration; the hangar entity owns current presentation; a feature display vehicle is a separate CGF object.
• Snapshot the selected vehicle's original transform before moving it and restore it before a native destination computes bounds or placement.
• Resolve HangarCameraSystem for the current space only after its mapping is loaded. Its mapping-unload path removes input listeners, camera components, idle/parallax helpers, FOV subscriptions, and retained state.
• Check that a named camera exists before switching. Camera names, modes, orbit components, and private parameters are build-dependent.
• Treat CGF game-object validity and required components as separate readiness checks; never retain objects across space destruction.

Cleanup contract

• Cancel every pending callback and invalidate its captured space, route, and vehicle context.
• Unsubscribe space, vehicle, route, input, and camera events with the same handler objects.
• Deactivate only groups owned by the feature and do not remove native groups owned by the destination route.
• Restore vehicle transforms, native-object activity, environment state, visibility masks, camera state, and wrappers only when still owned.
• Make repeated release, refresh, logout, and shutdown paths idempotent.

Hangar diagnostics

Verification checklist

• Trace current space-path selection and the exact readiness event.
• Trace lobby state registration, navigation request, entered states, and visible-route change.
• Inspect subhangar group configuration, activation/deactivation callers, environment, and camera ownership.
• Verify selected-vehicle identity, model, appearance, collisions, and transform separately.
• Exercise cold login, warm refresh, vehicle change, every native scene destination, battle return, logout, and shutdown.
• Label group names, route IDs, cameras, CGF components, and private hooks as version-sensitive.