Improving the Live Experience - Star Citizen Update

Ships vanishing at station hangars STARC-186319

A ship could disappear just after arriving at or departing a station hangar, including Levski, appear as stored at ASOP and drop its pilot onto the floor. Two processes were racing to destroy and re-stow the same vehicle; a bad zone or access token on spawn could help trigger it. A new check prevents teardown when the vehicle is already being stowed elsewhere. The failure was therefore happening during competing lifecycle operations on the same ship, rather than simply hiding its marker. Preventing the second teardown protects the stow already in progress from another process acting on the vehicle at the same time.

A quantum jump resuming inside the hangar STARC-206457

A retrieved ship could emerge already in quantum travel and hit the hangar doors or walls as its elevator animation ended. Enclosed-space spawns now block resumption of an unfinished quantum state. Follow-up tests across several stations and ships did not reproduce the failure. The dangerous moment was the end of the elevator animation: retrieval appeared to complete, then the restored travel state moved the ship into the enclosure. Blocking that state specifically for enclosed spawns addresses the collision before the pilot has to react.

Stored ships incorrectly requiring a claim STARC-152514

Station-lobby ASOP terminals could label a safely stored ship as needing a claim. They checked the ship’s immediate storage state, overlooking its place inside the hangar’s inventory when the hangar finished stowing after the player had moved too far away. ASOP now checks that hangar inventory directly. The important distinction is between checking an object directly and finding it inside the container that owns it. A terminal could lose sight of the ship’s immediate state without the ship actually being lost. Including the containing hangar in the lookup resolves that misleading claim requirement.

Interior and exterior doors opening separately STARC-128568

At stations including Stanton Gateway, Ruin Station and Orbituary, the inside door could open while the outer door stayed shut, trapping a ship or preventing entry. Restored backend links between the hangar and both doors make them open together. For the pilot, an open inner door was not evidence of an open flight path. The repair reconnects the two parts of the hangar-door operation, rather than relying on one door’s visible movement to imply that its partner has followed.

Mined ore lost through ship storage STARC-205924

Under load, instability in the cargo-tracking database could return a mining ship’s container to an earlier state after storage and retrieval. The backend repair restores ore persistence across that process. Reverting to an older container state explains why a ship could return while its newly mined cargo did not. This was a persistence failure across stowing and retrieval, with server load contributing to the database instability, rather than a failure to collect the ore in the first place.

External fuel pods losing their contents STARC-207340

Fuel stored in external pods could disappear when a ship was stowed through ASOP. It shared the cargo-database problem behind lost mined ore and was addressed by the same backend fix. Ore and fuel looked like different losses to their owners, but both depended on stored information surviving the same transition. Treating the fuel-pod problem as part of that shared persistence fault allowed one backend correction to address both symptoms.

Changing hangar size breaking retrieval STARC-186642

Only one instanced hangar size could be active for a player. Requesting a ship that needed a different size could fail silently, auto-store it or even destroy it. The old instance is now properly removed before the correct size is created. A follow-up also stopped elevators sending players into unloaded, stale hangars, where ships could falsely look claimable. This involved two different stale-instance problems: making room for the new hangar size, then making sure the transport route did not still lead to an instance that no longer existed. Correct ship spawning alone was insufficient if the elevator delivered its owner to the wrong place.

Missing atmosphere at Levski

Some hangar service and elevator areas lacked atmosphere coverage, allowing an unhelmeted player to suffocate. Coverage has been extended into those spaces.

Mission cargo leaving an elevator stuck transferring

Repeatedly raising and lowering mission cargo could permanently lock the platform on ‘Transferring…’. A collection objective completed after only part of its cargo was collected; putting cargo back did not reverse completion and corrupted the transfer state. Re-stowed mission items now go to personal inventory rather than back into the mission. A later fix closed an empty-transfer-request edge case. Testing across many locations and mission types could no longer reproduce it. The key mismatch was between the mission’s idea of a completed collection and the elevator’s changing contents. Returning some cargo altered the latter without reopening the former. Moving returned items into personal storage separates them from that already-completed mission objective, while the follow-up guards the empty-request path.

Hauling cargo absent at pickup STARC-153267

A backend race let an inventory-count update overwrite newer cargo data with an older cached version, leaving hauling missions without their cargo. The Warehouse Manager now processes those updates in the correct order; subsequent testing found no repeat failures. The cargo could have newer valid data and still disappear from the pickup flow because an older copy arrived afterwards and replaced it. Ordering those updates correctly is the crucial repair; merely displaying the latest inventory count would not protect the underlying cargo record from being overwritten.

An overload message hiding a partial transfer

The ‘Elevator Overloaded’ wording now explains that part of the transfer succeeded, so a player can tell that some cargo reached the platform. The capacity calculation that can raise the warning unnecessarily remains a separate, open issue. This is a split result: the message is clearer, but the calculation behind an unnecessary warning still needs work. Reading the wording change as a complete repair of elevator capacity would overstate what has been resolved. Some cargo having transferred and the warning appearing can both be true.

Boreal Quasi Grazer Eggs not completing a delivery STARC-199979

Handing in these eggs at a freight elevator for Nyx Mission Pack 2 could leave the gathering objective unfinished. Missing default setup data on the creature’s underlying object was responsible. An earlier attempted repair did not work; the corrected fix has since been verified. The failure sat in the setup of the creature-derived object used for the hand-in. The player could reach the freight elevator with the requested eggs and still fail the objective. Verification applies to the corrected repair after the first attempt, not to that unsuccessful earlier change.

Inventories appearing empty STARC-211218

Personal, station and loot inventories could become inaccessible for minutes, blocking mission pickups and deliveries. Stow-request timeouts left pending moves accumulating. The client now displays a loading spinner while the operation resolves; the deeper service and interaction fixes are explained above.

Double-click equipping the neighbouring item STARC-204415

Double-clicking armour could also equip an adjacent item, sometimes removing the undersuit slot and preventing gear removal. This shared the cause of an earlier armour-equip bug. Once that repair was fully deployed, testing no longer reproduced it. The symptom extended beyond the wrong item being selected: losing the undersuit slot could leave the character unable to take equipment off. Completion of the earlier fix’s rollout mattered here, and the reported successful testing came after that full deployment.

The undersuit slot disappearing after prison STARC-200719

A shirt worn before entry to Klescher could remain equipped behind the scenes and conflict with an undersuit, removing its inventory icon and preventing swaps. Prison entry now removes the shirt correctly. The visible failure occurred when equipping certain undersuits, notably after release, but its cause reached back to the clothing worn before imprisonment. Correcting prison entry removes that leftover shirt before it can conflict with the later undersuit change.

Keycards and drives disappearing when handled

Some carry-only keycards and hard drives wrongly offered an Equip action, which hid them until another item was picked up. Removing that invalid action keeps them in the intended carry interaction. These objects were meant to be carried. Offering an equipment action sent them through an inappropriate interaction path, which is why removing the option is part of the repair rather than merely adding a new icon or changing the inventory display.

Carrying a new item losing the one already held STARC-202297

Selecting Carry while holding something such as a multitool could play a holster animation and lose the held item. It had been moved into an internal container instead of personal inventory. Corrected handling and extra validation prevent that loss. A convincing holster animation masked an incorrect destination for the object. The handling change places the already-held item into personal inventory, and the added validation guards against it disappearing into the internal container again when the Carry action starts.

Category menus stacking over each other STARC-200139

Rapid hovering or clicking could leave inventory, freight and crafting-kiosk filters open on top of one another. A hover state failed to reset when the pointer left too quickly. Opening a new menu now forcibly closes the other open menus.

Equipped weapons shown as black silhouettes STARC-204772

Some weapons appeared as black shapes in gear slots and the looting interface immediately after equipping, until inventory was reopened. A rendering correction addresses the display problem.

Loot refusing to transfer into backpacks or core armour STARC-213375

Dragging items or shift-clicking them into those slots failed at many locations. The affected interface panel needed a different rendering mode to receive drag events properly.

The refinery kiosk button sitting in the wrong place

The Buy button at Levski’s Nyx refinery shop was misaligned and difficult to click accurately. Its on-screen position has been corrected.

Split stacks corrupting inventory state

Splitting and recombining items could leave inventory broken because the split items retained duplicate internal identifiers until the local cache updated. Loadouts that left items without a valid sort order made matters worse. Multiple repairs addressed both causes, with extensive testing confirming the result. Two bookkeeping problems overlapped: split items temporarily shared identifiers, and some loadouts provided no proper ordering for them. Fixing only the visible stack would leave that underlying ambiguity. The reported repairs cover both identity and sorting, with the result checked through extensive testing.

New pickups not available for placement

Freshly collected fuses or ore could not be placed from inventory until it had been opened and closed. Pickup now updates the stale inventory cache correctly. An older workaround that made Escape invalidate the cache has also been removed. The object had been picked up, but the cached inventory view used for placement had not caught up. Updating that view at pickup tackles the stale state directly. Removing the Escape workaround also prevents a separate input from invalidating the cache as a side effect.

Ammo restocking ignoring the backpack

Restocking drew magazines from core armour but ignored spares in a backpack. It shared the stale-cache problem behind newly picked-up items failing to place and was resolved by the same repair.

64008 Spawn Resolver Error STARC-178776

Players could be returned to the main menu while entering the Persistent Universe. An earlier wave involved incorrect data exclusion; a later recurrence came from desynchronised backend account state, which could also cause 64006 disconnections. A backend service fix tackled the dominant cause. The same error number appeared in more than one wave for different reasons. Keeping those causes separate matters: the later account-state desynchronisation explains its overlap with 64006, while the earlier data-exclusion bug was a distinct route to the same failure screen.

60029 preventing entry to the universe STARC-162848

Affected character records were effectively stowed in two places at once. A backend service repair addressed the cause, while support tools manually repaired accounts already trapped in that state. For anyone already locked out, stopping the error from happening again was only half the job. Their character still needed to be freed from its contradictory stored state. The manual support repairs supplied that second step, allowing the service change to help existing victims as well as future login attempts.

64010 after a long spawn timeout STARC-177979

Players could wait more than 12 minutes for their last location to resolve and then time out. The limits were in backend location-service throughput and availability, not the client. Backend service improvements address them. The wait was for the service to resolve a stored location, not for the player’s machine to finish a local rendering task. That is why the remedy sits in service capacity and availability, rather than a client-side setting or a different route through the login screen.

64006 Location Resolution Request failed STARC-210544

A temporary account-state desynchronisation stopped the backend finding the character record to bring it online. It did not mean the character data had been lost. It could clear itself after seconds or take around 15 hours. This caused most of a related 64008 wave, and the same backend service fix addresses both. The inability to retrieve a character record looked alarming, but the underlying record had not been deleted. The distinction between unavailable state and lost data is central to this case, especially given the very wide range of times in which the desynchronisation could clear itself.

Routes blocked by the station around the ship

Plotting quantum travel inside a station hangar failed for destinations outside direct line of sight. Stations had a map-object type with navigation points disabled, so the station itself obstructed the calculation. Enabling those points restored routing from hangars. This affected planning a route before leaving the hangar, not only navigation once already in space. The station surrounding the ship participated in the calculation with the wrong navigation settings, so a destination hidden behind it could not be routed correctly.

Mission-marker clicks zooming too far in

The starmap calculated focus distance from a mission marker’s tiny radius rather than an appropriately sized nearby object. A more suitable reference object now determines the zoom. A mission marker is much smaller than the location a player wants to inspect. Using its radius literally brought the camera too close to be useful. Choosing a nearby object of sensible scale changes the reference for the focus calculation rather than changing the mission’s destination.

Repeated party connection notices STARC-170842

Every server-meshing authority handoff could trigger another teammate ‘connected’ notification instead of limiting it to initial arrival on the shard. The backend notification is disabled for now through a configuration flag; that quiets the repeated notices while leaving a more permanent solution for later.

Quantum routes passing through moons

The collision test for quantum arrival points failed to account for a moon blocking the route. It now detects that obstruction rather than allowing travel straight through the moon.

Enemy ships freezing, wobbling or ramming

Several causes contributed: a ship type lacked its fighter-class tag, a broken manoeuvre caused visible wobble, and an unconditional stop command froze AI. Each was repaired separately. Follow-up tests showed proper manoeuvring without the freezing or collisions with the player. There was no single cause behind all the erratic combat. Missing classification data, faulty manoeuvre behaviour and an unconditional stop each produced a different part of the problem. The follow-up testing checked the resulting movement, including the absence of the freezing and ramming previously seen.

Passive Vanduul Scythes at mission sites

The pilot AI pointed to a leftover default activity from an unrelated project rather than the intended idle-then-engage behaviour. Correcting that reference restored engagement.

Staggered Yormandi remaining idle

Logic and data changes repaired the creature’s motivation and pain-reaction interrupts. The problem briefly returned when interrupted in a particular mid-attack state, which a further fix addressed. The follow-up matters because an initial repair did not cover every interruption point. A stagger during a particular attack state could still prevent the Yormandi returning to combat. The later change specifically closed that recurrence after the combined logic-and-data work.

Docking collars rejecting an aligned ship STARC-203449

A second nearby player could interfere with docking, while tubes could remain in an ‘already associated’ state and reject later attempts. Ships were affected across Stanton, Nyx and Pyro, sometimes unable to access hangars or stations despite correct alignment. The fix was confirmed across numerous station and ship combinations. Accurate alignment alone could not solve either obstruction: another nearby player could affect the process, and a tube that still believed it was associated with a ship would reject a new attempt. The confirmation spans different stations and ship types rather than a single successful docking.

Cargo Services failing to answer

Cargo ATC could stop responding at stations in Stanton, Nyx and Pyro, leaving players unable to request a loading zone for automatic cargo loading.

Surviving a wreck but remaining trapped in its seat STARC-177016

A cockpit seat could detach before a collision-destruction sequence finished, leaving a live pilot unable to exit or eject, sometimes indefinitely. That detachment now completes the destruction sequence instead of stranding the player. For a surviving pilot, the wreck became a prison. The seat had separated before the ship’s destruction sequence reached completion, leaving the character alive in a state with neither a usable exit nor an eject option. Completing destruction on that detachment closes the stranded-survivor case.

Landing gear spawning through the hangar floor

Retrieving a vehicle while leaving during its storage animation could place its gear through the floor and prevent takeoff. Another retrieval attempt could lock the ASOP retrieve button. A validation-and-repair pass now corrects the vehicle’s placement.

Systems failing to return after a power cycle

Radar and other systems could remain off after switching ship power off and on. A timing race was responsible. Systems that fail to repower are now tracked and restored automatically.

A missing satellite blocking a patrol STARC-179201

Some patrols require a scan in a designated area. If the satellite failed to spawn there, the objective could remain blocked because mission logic never received confirmation of success. A fallback spawn location now allows completion when the original location fails. The objective depended on a satellite actually existing in the designated area, but the mission was proceeding without confirmation that the spawn had worked. A second possible location gives the objective a way forward when the original spawn fails, instead of leaving an impossible scan requirement active.

Scans reporting known identity as unavailable

Ping-wave scans and the Target Status MFD could show a vehicle’s name and faction as ‘Unavailable’ despite known data. The correction immediately displays the scanned vehicle’s model name.

Different default aim modes for the same turret

Manned control defaulted to gimbal/auto-aim, while remote control defaulted to pip aiming. The aim-mode logic had not reinitialised correctly when changing control type, producing inconsistent behaviour for the same turret. That mismatch made the same hardware behave differently depending on how it was controlled. Reinitialisation is the relevant boundary: changing from a seated operator to remote control must not leave the aiming logic in an inconsistent starting mode.

Another landing service cancelling repair

Selecting Repair did not lock the other service options quickly enough, allowing a conflicting request to cancel it silently. The race between requests has been fixed.

Simultaneous services requiring a second repair request STARC-214209

Requesting Repair together with Restock or Refuel could show all services processing while the repair silently failed and needed another request. This is the simultaneous-request case, separate from the slow lockout of other services described above.

No route line on the minimap STARC-131916

A custom minimap route could produce no visible guidance because the route calculation was available only on the server. The fix calls the pathfinding logic directly so the line can render. The route could be requested without producing the line a player needed to follow. Bringing the pathfinding call into the route-line flow connects the calculation to its visible guidance, rather than treating an accepted destination as sufficient evidence that navigation is working.

Low-detail weapon models appearing too soon

Rifles, SMGs, shotguns and sniper rifles could look blocky in inventory and crafting thumbnails and even at moderate in-world distances. Adjusted level-of-detail transitions keep the more detailed models visible where expected.

Klescher ore deposits failing STARC-127424

The Ore Deposit Kiosk rejected mined gemstones with ‘Transaction Failed’, preventing prisoners from earning sentence merits. It misread whether ore was in a backpack and sent the request to the wrong inventory list. That lookup is corrected.

Freight-elevator ore rejected by commodity kiosks STARC-214870

Dolivine, Aphorite and Hadanite on a freight elevator could fail with ‘Failed Entity Query’ at a commodity kiosk. A client-side transaction calculation did not pass server validation. The calculation has been corrected.

Old mining-node bases surviving a respawn

Depleted bases remained indefinitely, cluttering a location even after a new node appeared. The cleanup timeout queue was sorted incorrectly, so despawn timers did not run. The order has been fixed.

A refuelling hint blocking other notifications

Respawning during a refuelling mission could leave ‘Dock with Refueler’ on screen and obstruct later notifications. This is the mid-mission-respawn variant of the stuck-hint problem.

Armed grenades lacking a warning marker

Live thrown grenades had no HUD warning because FPS radar remained disabled by a workaround for an older exploit. Removing that workaround restored the danger indicator. The missing warning was an unintended consequence of leaving an older protective workaround in place. Restoring the radar dependency brings back the nearby-danger marker, giving players a warning when an armed grenade lands close enough to threaten them.

Party markers omitting names STARC-191377

Party members’ HUD markers showed a chevron and distance but no name. A name-visibility data binding was stuck returning zero; that binding is now repaired.

Seventeen exploit fixes in Alpha 4.10

The release includes 17 exploit fixes, although their full details are not public. Among them is the most-reported economy exploit, which injected substantial in-game currency and required repeated corrective action by Game Security.