TaskFlight
Questions we receive from instructors, evaluators and IT officers, answered in public so the answers have a permanent home. Live discussion happens on GitHub — every thread links there.
The most common question we get. Short answer: a new aircraft is an authoring effort against the existing schema and 3D pipeline, not a rebuild — and which physics family it falls into decides most of the work.
Yes, genuinely. The trainer builds to a folder of static files with zero outbound requests — no CDN fonts, no analytics, no telemetry — and runs from any internal web server or kiosk image.
The app is schema-driven — systems, parts, procedure steps and knowledge checks are data, not code. What that means in practice for a training department that wants to own its content.
The public demonstration build deliberately stores progress only in the browser — no accounts, no server. LMS/LRS reporting exists as a contracted deployment option inside your own boundary. Here is how the two builds differ and why.
Explore → procedure → knowledge check → pre-flight maintenance → fly → debrief. Why we recommend running the loop per-system rather than front-loading all maintenance before any flight.
Intentional, and it is the most instructive difference in the fleet. The CH-47 has no tail rotor: pedals tilt the two rotor discs against each other, and the power-pedal coupling you learned on the Apache is simply absent.
Both, because papers are seeded: the seed fully determines every question, distractor and ordering. Same seed, same paper — and any past paper can be regenerated for review.
No. Integrated GPUs are the design target, not a grudging fallback — the fleet’s worst rendering bug was found and fixed on an Intel Iris specifically because that is what classroom laptops actually have.
Progress lives in browser localStorage per profile — which is a privacy feature and a shared-machine problem at once. Practical patterns: per-student OS or browser profiles now, LMS reporting under contract.