Skip to main content

Interact with Terrain and World Boundaries

Overview​

User capability

Respond predictably to terrain, collision surfaces, altitude limits, and world boundaries

User

An AeroSim player

What the user can do

Respond predictably to terrain, collision surfaces, altitude limits, and world boundaries

Why the user benefits

The player receives one coherent, observable capability.

User need

The player needs AeroSim to respond predictably to terrain, collision surfaces, altitude limits, and world boundaries.

In scope

Respond predictably to terrain, collision surfaces, altitude limits, and world boundaries

Tasks​

AEROSIM-TS-2Planning status: Done

Detect and classify supported terrain and obstacle contact

The deterministic runtime reports controlled terrain contact, unsafe terrain contact, and solid-object collision using the aligned Rapier collision world.

  • ComponentWeb flight runtime — Rapier contact adapter and classifier
  • Depends onAEROSIM-TS-34
  • RequirementsFR-0003
AEROSIM-TS-83Planning status: Done

Implement warning, grace-zone, and hard-limit transitions

Configured horizontal and altitude limits produce a visible warning zone, a return grace zone, and an unambiguous hard-limit event.

  • ComponentWeb flight runtime — world boundary state machine and warning presenter
  • Depends onAEROSIM-TS-2
  • RequirementsFR-0004
AEROSIM-TS-84Planning status: Done

Restore a safe aircraft state or conclude the boundary violation

A hard-limit or governed collision event restores the last safe state/configured recovery point or explicitly concludes the session without leaving an unexplained aircraft state.

  • ComponentWeb flight session — safe-state store and recovery coordinator
  • Depends onAEROSIM-TS-83
  • RequirementsFR-0004
AEROSIM-TS-85Planning status: Done

Verify world-interaction timing, determinism, resources, and browser compatibility

Supported contact, warning, recovery, and terminal scenarios remain responsive, resource-bounded, and equivalent within governed tolerances across certified browsers.

  • ComponentWeb flight runtime — world-interaction browser and resource verification harness
  • Depends onAEROSIM-TS-84
  • RequirementsNFR-0001, NFR-0002, NFR-0005, NFR-0006, NFR-0009
AEROSIM-TS-141Planning status: Done

Prevent false boundary violations before world launch

A boundary warning appears only from the active confirmed world policy and never reports a hard limit before a world has been selected and launched.

  • ComponentPrevent false boundary violations before world launch
  • Depends onAEROSIM-TS-34
  • RequirementsFR-0004
AEROSIM-TS-148Planning status: Done

Apply production-scale world-boundary distances

A launched flight remains usable within the intended world area and reaches warning, hard-limit, recovery, and restart states only at governed metre distances.

  • ComponentActive-flight world-boundary policy
  • Depends onAEROSIM-TS-141
  • RequirementsFR-0004

Acceptance outcomes​

  1. 01

    Contact with terrain or a configured world boundary produces a visible governed response.

  2. 02

    A boundary violation ends or recovers the session without leaving an unexplained aircraft state.

Functional requirements and measurable criteria​

FR-0003

detect world contact

The system shall detect supported ground and obstacle contact.

Acceptance 01

Givena valid current Feature configuration and defined initial state

Whenthe relevant user action or simulation step occurs

Thenthe observable result must detect supported ground and obstacle contact

EvidenceFuture reviewed automated and browser evidence must verify this outcome against the current requirement.

Acceptance 02

Givenan invalid or unsupported input at the same boundary

Whenthe system evaluates the input

Thenthe system must reject or recover visibly without publishing a misleading result

EvidenceFuture negative-path tests and browser evidence must verify explicit failure or recovery behaviour.

FR-0004

respond to world boundaries

The system shall present a bounded, recoverable response to collision and world limits.

Acceptance 01

Givena valid current Feature configuration and defined initial state

Whenthe relevant user action or simulation step occurs

Thenthe observable result must present a bounded, recoverable response to collision and world limits

EvidenceFuture reviewed automated and browser evidence must verify this outcome against the current requirement.

Acceptance 02

Givenan invalid or unsupported input at the same boundary

Whenthe system evaluates the input

Thenthe system must reject or recover visibly without publishing a misleading result

EvidenceFuture negative-path tests and browser evidence must verify explicit failure or recovery behaviour.

Non-functional requirements

Risks​

  • Risk

    Prototype behaviour may not meet the current acceptance outcomes.

Original source and prototype evidence​

Prototype and discovery boundary

Existing application behaviour is discovery evidence only; it establishes no current Scope approval, implementation approval, acceptance, or release state.