Handling & performance
Develop consistent response across speed, weight, trim, configuration, and control input. Evaluate take-off, climb, cruise, approach, landing, and ground handling through repeatable test profiles.
Oddworks is developing a C-27J Spartan experience for X-Plane 12, bringing together aircraft modelling, interconnected systems, avionics, and carefully designed tools for the pilot.
The C-27J Spartan is a twin-engine tactical transport designed for demanding operations. Translating an aircraft like this into a simulator means bringing its shape, cockpit, operating procedures, and system relationships together as one coherent experience.
Main developer · Adrianas
Exterior work can go beyond the overall silhouette: panel breaks, access doors, antennas, landing gear, propeller assemblies, cockpit glazing, surface variation, and material response all contribute to a convincing aircraft. The same care applies inside, where proportions, visibility, labels, controls, and instrument placement shape how the cockpit feels to use.
Lighting and animation should support the model rather than disguise it. Details will be prioritised by reference quality, visual importance, and their contribution to the complete aircraft.
Exterior modellingCockpit geometryMaterials & lightingAnimationA switch is only the visible start of an interaction. Behind it are conditions, system states, and consequences. Oddworks' engineering direction is to connect pilot inputs to aircraft logic, and aircraft logic to the indications the pilot uses to understand what is happening.
Develop consistent response across speed, weight, trim, configuration, and control input. Evaluate take-off, climb, cruise, approach, landing, and ground handling through repeatable test profiles.
Connect power-lever inputs with engine response, propeller behaviour, aircraft acceleration, and climb performance. Start-up and shutdown should progress through defined states rather than jumping straight to an end result.
Model power sources, buses, switches, and equipment availability as a connected system. The state of a display or component should depend on the relevant supply and conditions.
Research the real aircraft's system architecture and reproduce appropriate relationships where supported by reliable references, including quantities, pressures, control states, and system indications.
Keep selected modes, active modes, aircraft state, and displayed information consistent. Navigation, guidance, and cockpit indications should share reliable data instead of acting as isolated features.
Use repeatable scenarios, track issues, and re-test existing functions after changes. System logic should be understandable to develop and practical to troubleshoot.
A closer look at the planned aircraft systems and the relationships behind them. Each area will be developed against suitable references and evaluated as implementation progresses.
This page describes the development direction. Feature availability and depth will depend on research, implementation, and testing.
Main developer · Adrianas
Primary flight information: attitude, airspeed, altitude, vertical speed, heading, and relevant flight-mode information, according to the chosen cockpit implementation.
Engine and system indications: planned engine parameters, configuration status, cautions, warnings, and synoptic information connected to simulated aircraft state.
Display consistency: indications should reflect the state of the underlying system. A display should not show a normal condition when the associated simulated system is unavailable or in a fault state.
Route construction: route entry and review, waypoint sequencing, direct-to functions, leg information, and procedure support where suitable data and interfaces are available.
Route integrity: identify missing waypoints, invalid entries, and discontinuities before activation. Make the active leg and next waypoint clear to the pilot.
Navigation data: investigate compatible X-Plane navigation sources and flight-plan formats. Database and procedure support will depend on format compatibility and applicable licensing.
Guidance integration: keep route data, navigation display, and any implemented guidance modes aligned to the same underlying flight-plan state.
Mode logic: research which guidance and autopilot functions are appropriate to the aircraft before implementation. Clearly distinguish selected modes from active modes wherever applicable.
Transitions: engagement, disengagement, and mode changes should have predictable results and appropriate indications.
Flight director & autopilot: where implemented, commands and indications should be consistent with aircraft state, pilot inputs, and the available simulation interfaces.
Electrical: power sources and distribution determine equipment availability; switches request actions, while the system checks whether the required conditions are met.
Engine start: model a sequence of meaningful states with changing indications as the engine responds, rather than an instant switch from off to running.
Fuel, hydraulics & environment: investigate the relevant system dependencies, quantities, pressures, and control states using reliable references.
Warnings and failures: where feasible and documented, define the conditions that trigger cautions or warnings, their indications, and their reset or recall behaviour.
Flight preparation: route review, departure and destination information, alternates, estimated time, and pre-flight planning in one organised workspace.
Performance tools: planned take-off and landing performance pages, using relevant mass, configuration, runway, weather, and environmental inputs. Calculations must be based on documented methods and verified data; missing inputs and limitations should be explicit.
Loading & fuel: planned payload and fuel entry, weight-and-balance calculations, fuel estimates, and comparison with simulator values where data access allows.
FMS data transfer: investigate importing, exporting, or copying compatible route data between the EFB and the aircraft's FMS, with route validation and pilot confirmation before changes are applied.
Checklists & documents: interactive checklists, reference notes, limitations, and aircraft documentation organised for quick access.
Logbook & debrief: record completed simulator flights with date, route, airports, block and airborne time, distance, fuel use, altitude, landing details when available, and pilot notes. Offer a post-flight summary and exportable personal history.
Exterior: accurate proportions, surface construction, doors, access panels, antennas, landing gear, propellers, and appropriate material variation based on reference quality.
Cockpit: readable labels, considered geometry, practical visibility, instrument depth, and consistent interaction points.
Animation & audio: moving components, lighting, and sound should respond to the relevant aircraft state wherever technically supported.
The Electronic Flight Bag is planned as a core part of the pilot workflow, not just a decorative tablet. Its job is to help prepare the aircraft, organise the flight, provide useful calculations, and preserve a record of the journey.
The intended experience starts with flight preparation: review a route, confirm aircraft loading, inspect relevant conditions, and calculate performance from transparent inputs. During the flight, selected pages could display live simulator information where supported. After shutdown, the EFB could compile a logbook entry and a concise debrief from recorded data.
Performance figures must be handled carefully. They should use documented calculation methods and suitable reference data, clearly state assumptions, and never be presented as approved real-world operating data.
PlanningPerformanceFMS integrationLogbookExplore calculations based on aircraft mass, configuration, runway length and slope, elevation, temperature, wind, and runway condition when reliable data is available. Show assumptions and limitations alongside the result.
Estimate landing distance using arrival mass, runway and weather inputs, configuration, and other validated factors. Make missing or uncertain inputs visible instead of hiding them behind a single number.
Review flight plans, verify waypoint order and discontinuities, and investigate transfer of compatible route data to and from the simulated FMS with confirmation before changes are made.
Enter cargo and fuel, calculate total mass and centre of gravity where the necessary aircraft data is available, and connect loading to the aircraft model if the integration can be implemented reliably.
Organise planned fuel, expected trip use, reserve assumptions, and in-flight comparisons against recorded simulator values.
Store route, airports, date, flight duration, distance, fuel use, maximum altitude, available landing metrics, and pilot notes. Review, search, and export flight history for personal use.
Keep interactive checklists, procedures, limitations, and aircraft documentation in a consistent interface, with state-aware checklist support where practical.
Investigate links to simulator data so selected EFB pages can reflect current aircraft state, route progress, fuel values, and flight details when reliable interfaces are available.
A complex aircraft is easier to develop when the foundations are stable and every addition can be checked. The process is intended to favour coherent behaviour, traceable assumptions, and quality across the complete experience.
Gather suitable references, define the intended scope, document assumptions, and distinguish verified information from areas that need further investigation.
Establish the aircraft structure, baseline flight model, cockpit layout, and core configuration before expanding into more complex features.
Implement behaviour in manageable units, connecting pilot input, system state, and cockpit indication with clear logic and testable boundaries.
Use repeatable scenarios across take-off, climb, cruise, descent, approach, landing, and ground operations to identify and prioritise issues.
Refine materials, lighting, animations, sound, and cockpit interaction while preserving performance and consistency.
Re-test key scenarios after changes, document known limitations, and communicate clearly what is implemented and what remains in development.