Star Citizen’s New Flight Model, Missions 2.0 and Maelstrom: All Ten Answers
Rich Tyrer, Ian Leyland and Karl Chandler address flight, mission reliability, ship systems and the work still ahead in the first 10 From the Community.
A mission that survives your next login, a disabled ship worth boarding and a route back to the equipment you earned: several of Star Citizen’s biggest development questions come down to keeping an evening’s adventure moving. The first 10 From the Community also brings substantial news for pilots, with the new flight model and Maelstrom described as technically complete in Squadron 42. Their move into Star Citizen still involves multiplayer integration and balancing.
Senior Game Director Rich Tyrer, Creative Director Ian Leyland and Gameplay Engineering Director Karl Chandler discuss those changes in the 5 October 2026 episode. Its ten answers range from short commitments on AI blades to detailed explanations of mission failures, armour storage and regeneration. The most promising thread is how those systems could support each other: missions that recognise a disabled target, scanners that reveal what is worth recovering, and engineering that leaves a ship intact long enough to do something with it.
Flight control moves into the power system
The new flight model is functionally complete in Squadron 42, with Chris Roberts and Tyrer directing its development. It removes the Master Modes division between SCM and NAV. Instead, the pilot’s power distribution governs which ship functions are available: weapons, radar and the quantum drive can operate together when the chosen power allocation supports them. Engineering and the power pips therefore become central to managing the ship.
Quantum boost sits alongside quantum travel. Boost is a way to cover distance in space or atmosphere after a short charge, inside a steerable quantum bubble and without selecting a fixed destination. It is slower than quantum travel, but faster than ordinary traversal. Travelling from a landing zone to a low-orbit station, moving around a planet or crossing open space are the examples discussed. The freedom to steer is an important part of its purpose; a pilot would not need a suitable quantum marker simply to move quickly in a chosen direction.
Internally, the team is happy with how the model feels, and a small number of Star Citizen players have already tried it. More player feedback is wanted. The ambition is an intuitive, enjoyable baseline with enough depth and customisation for pilots to develop their own approach.
Getting it into Star Citizen requires work beyond transferring a single-player flight system. Networking must keep ships moving consistently without desynchronisation, and the balance must support both player-versus-player and player-versus-environment encounters. Miners and haulers matter alongside bounty hunters and combat pilots. Those different careers are part of the integration problem, so Squadron 42’s functional completion does not establish a Persistent Universe delivery date.
Missions 2.0 connects contracts, persistence and shared rewards
Missions 2.0 covers the systems used to build missions as well as the experience of finding and completing them. Star Citizen needs a scalable way to produce meaningful, reliable content, including the main story planned for 1.0. That requires staged scenarios which can direct NPCs, world objects, TrackView animation and dynamic events, with capabilities the current mission system does not adequately provide.
For players, one of the clearest changes is continuity. Completing one mission could unlock the next in a quest chain, with progress preserved between sessions. An active contract should also survive logging out: return the following day and it would still be available in the Contract Manager, rather than the session boundary automatically ending the work.
Sharing missions needs more flexible reward rules. A participation threshold could determine entitlement, rather than every activity relying on an equal split. The intention is to make playing together worthwhile without forcing co-operative play or making friends compete over an individual reward. These are authoring options and design goals, not a single announced reward formula for every contract.
Behind that sits a substantial change in how missions are assembled. Current tools make designers handle work that resembles programming: initialisation, error handling, finding the required entities, serialisation, streaming race conditions and the order in which objects load. A mission can fail because the world did not arrive in the sequence its logic expected, even when the intended activity is straightforward.
The proposed declarative approach lets a designer specify the conditions, environment and objects a mission needs, leaving the system to supply and manage them. Reusable building blocks should reduce the amount of fragile technical logic each designer has to reproduce. That would leave more time for designing the encounter itself and fewer opportunities for the same infrastructure problems to recur across different missions.
The Contract Manager also needs clearer presentation, search and filtering as the amount of content grows towards 1.0. Story missions may contact and enrol a player rather than always waiting to be selected from a list. Requirements such as a multi-tool or a suitable ship, together with the expected rewards, should be clear before starting. Missions 2.0 is consequently an initiative spanning creation tools, engine support and the player-facing route through a contract, rather than a replacement menu alone.
Engineering needs disabled ships to remain useful
Engineering’s balance is unfinished. The team expects to keep iterating over the coming year, with the broad aim of extending a ship’s life and giving its occupants things to do while it is damaged. Fire is currently less threatening than intended, and several parts of the experience depend on other features reaching the right stage. The new flight model’s power control also has to work across ships ranging from single-seat craft to capitals.
AI soft death is a particular concern. Enemy ships currently explode too often for the intended aftermath to develop. Destruction can still be appropriate when a critical component fails, but mission logic must recognise a ship that is disabled and dead in the water as defeated where that satisfies the objective. Requiring an explosion to complete the contract works against the opportunity to board or salvage the vessel.
Cargo is another missing connection. A mission currently has to specify a cargo manifest explicitly, which does not scale well. Assigning meaningful cargo through ship archetypes would also make an AI vessel encountered away from a scripted mission more interesting. Its contents could create an opportunity naturally, rather than requiring a bespoke encounter to make stopping it worthwhile.
That depends on being able to understand what is aboard. The scanning MFD has a bug affecting its usefulness, and its information needs to be legible and comprehensible. Cargo and component information from radar and scanning should help a player decide whether to strip components, recover goods or salvage the disabled ship. Poorly maintained AI ships with worn components could still end in an explosion; preserving every target is not the goal.
The team acknowledges that progress has been too slow. Missions 2.0 is relevant here because engineers repeatedly pulled into mission bug support have less time to improve engineering gameplay. Reducing that support burden is intended to release capacity for iteration. The complete chain—disable, assess, board and recover something worthwhile—is still an aspiration, rather than a claim that all those connections already work reliably.
AI blades remain part of the 1.0 plan
AI blades are still planned for Star Citizen 1.0; that commitment has not changed. The example is a player flying a larger ship and using blades to perform some of its functions. Tyrer would like them to arrive sooner, but gives no earlier delivery date.
For owners of larger ships, the prospect is assistance with some onboard jobs. Exactly which functions a blade will cover, and how much crew it can replace, remain unspecified here.
Armour choices need a quick way to change roles
Armour and storage aboard ships bring together three related workstreams: StarWear, suit lockers and FPS Armour 2.0. They need to function as a coherent system if players are to choose clothing and protection for a job without turning each change of activity into an inventory chore.
Heavy armour should not be as suitable for flying as a flight suit. Temperature protection, damage mitigation, pressure, radiation and resistance to G-forces already give equipment different considerations; the larger integration is meant to make those roles work together. Pre-production took place earlier in 2026, but implementation of the combined work had not yet started at the stage Chandler describes. The approach is to deliver smaller pieces incrementally rather than wait for one enormous feature to arrive fully formed.
StarWear expands beyond the fixed relationship between an undersuit and armour. Tyrer has played an internal version of the fuller system and gives wearing sunglasses underneath a helmet as an example of its flexibility.
Suit lockers would let a player prepare outfits for radiation exposure, on-foot combat or flying, then swap the whole set with a single interaction. That is the practical companion to more specialised equipment: the choice becomes more meaningful without demanding a lengthy sequence of individual item transfers every time the plan changes.
Tier-three decorations insurance is intended to protect more of that preparation in future. The intended coverage includes stocked weapon racks and suit lockers, kitchen supplies and medical resources used for an imprint or medical bay. Restoring a customised ship or hab should account for the way its owner has equipped it, rather than treating the bare vehicle or room as the entire loss. That contents-restoration plan is still future-facing.
A community video showing an extensive weapons display on an Idris’s upper hangar level illustrates the appeal. Players already invest effort in making a ship feel prepared and inhabited. Convenient outfit changes and eventual restoration of that setup address the practical work behind those personal spaces, as well as their appearance.
Maelstrom’s next challenge is Star Citizen’s fleet
Maelstrom is technically complete in Squadron 42. Ships and environmental objects can break apart there, and its physical damage calculations account for projectile weight, speed and type—including energy and ballistic weapons—and the force of an impact.
For Star Citizen, Maelstrom would replace the current armour system wholesale. The scale is different: more than 200 ships, multiplayer networking requirements and gameplay balance all need attention. A system working in Squadron 42 is therefore a substantial development milestone, while still leaving a large integration job for the Persistent Universe.
As Squadron 42 approaches release, more people and completed features are expected to move across. The team compares that prospect with the earlier Alpha 3.23 push and identifies Maelstrom among the earliest intended transfers, with the new flight model also mentioned. That intended ordering has no announced date or patch attached.
The attraction in combat is more granular, visible feedback. Pieces of a wing or an aileron coming away can show the effect of an attack from the cockpit, giving a pilot a clearer sense of damage as the fight develops.
Regeneration could offer three permanent imprints
The medical respawn and screen-rework question asks for a choice between home, a ship and other locations when respawning. The planned structure includes three permanent imprints: a main hospital, a future player base and a ship. A player would choose where to return after death, including using another location if one were being camped.
Temporary imprints would sit alongside those longer-term choices. A location associated with an operation such as Align and Mine, or a friend’s ship, could provide a temporary option. The intention is to support moving between those situations rather than making one registration answer every kind of journey.
Death of a Spaceman and DNA integrity remain part of the wider design. The consequences of regeneration are meant to relate to the bed tier, facilities and location used. The longstanding design remains the intended direction for a future update, with its timing and detailed integrity rules still unspecified.
Why working missions break again
Recent large missions, including Vanduul tech-smuggling content and Tactical Strike Groups, frame a familiar frustration: why can something work and then fail again one or two patches later? Chandler, who joined a few months earlier, says he asked much the same question.
The explanation begins with the scale of the game and the number of ways its systems interact. Work discussed with Chief Technology Officer Benoit Beausejour includes improving validation before changes are submitted and expanding automated testing. A change can affect content introduced seven weeks ago or seven years ago; testing only the new feature is not enough to establish that older content remains sound.
A broader automated regression suite is intended to exercise content and gameplay across those interactions. Missions also have their own additional weakness: complex logic for gathering entities, handling streaming races and recovering after a server crash makes their current construction brittle. The declarative model described in Missions 2.0 is meant to reduce that burden at its source.
Race for Stanton provides a concrete example. An interaction between the mission and backend systems funnelled players into one location for a prologue or setup mission. Internal testing did not reproduce the same concurrency, and the live environment differed slightly. The resulting concentration of players was unintended, damaging the experience for players and for developers who had spent time preparing the content.
Large system changes are only one part of the response. The team is also targeting narrower areas for faster improvements in robustness: a new player’s first hour, quantum travel, elevators, freight elevators and hangars. Those everyday systems determine whether someone can get to an activity at all.
The stated expectation is that each patch should improve the game, with community reports feeding into the work. The named problem areas remain priorities for improvement; this discussion does not announce completed fixes for them.
Siege of Orison loot should be easier to bring home
The Siege of Orison question proposes storage terminals at the final shuttle station, before leaving the instance, so players can offload earned loot instead of dragging it out. The team agrees with the underlying need and has been discussing ways to unload equipment throughout the mission.
Item banks at the medical facilities along the route are one possibility. Linking them to Orison’s local inventory would make recovered equipment easier to retain, but the connection between an instance’s inventory and the persistent inventory still needs to be resolved. Discussions with Jens Lind are part of that work. The terminal locations and inventory connection are still being worked out.
Crafting raises a related problem: spending an evening searching for the right quality of ore can leave progress too dependent on chance. A proposed refining path would let players combine lower-quality ore and improve it towards higher quality, giving gathered material a use even when the initial find is not ideal. No conversion ratio, process duration or release date is supplied.
This is a change of direction from the approach described in our April inventory and crafting Q&A coverage, which discussed keeping low-quality materials useful without upgrading them. The October proposal now explicitly includes refining towards higher quality. It remains a development plan, not an instruction to combine materials in the current game.
Progress can take several forms: credits, reputation, access to ships or accumulated materials. The common aim is for time spent playing to contribute towards something. Tyrer uses his experience organising raids as a mage in World of Warcraft to illustrate how preparation and maintenance burdens can prevent people from joining their friends. That kind of exclusion is something he wants Star Citizen’s design to avoid.
Lost equipment inside an instance creates another obstacle. A bad jump near the final area of Siege of Orison can leave a body and its gear somewhere the player cannot reach. A retrieval mechanism is planned for instanced solo and group activities, particularly as the game moves away from automatically returning equipment on respawn towards an insurance-based arrangement. Its final form remains unsettled.
Logging back in aboard a friend’s ship
The final question asks whether logging out on a friend’s ship could allow a player to return there while still in the same party. The planned direction is login in place: try to restore a player to the position and circumstances they left.
Party membership, the ship’s state, different shards or servers, being in space and being docked all create separate cases to handle. The commitment is to do everything possible to put the player back in the same position. It is an intention to preserve continuity across those cases, rather than an unconditional guarantee that every combination can return someone to precisely the same place.