Star Citizen’s communal travel has a reputation: sometimes it’s smooth, and sometimes an elevator ride turns into a soft-lock, a long delay, or the dreaded “void door.” Cloud Imperium Games is now testing a new transport system (a full rewrite of the older transit tech) aimed at making elevators, trams, and gateways far more reliable as the game pushes deeper into instancing, streaming, and server meshing.

This article breaks down what the new system is, which locations are currently running it, the most important quality-of-life changes (including the new destination queue), what’s missing from the tech preview, and the known issues you should plan around while testing or traveling.

What the “new transport system” actually is

The new transport system is a complete rewrite of the legacy transit system that historically handled shared movement across landing zones and hubs: trams, trains/monorails, and many types of elevators (including hangar elevators and central “physical” elevators at places like GrimHEX).

It’s not pitched as a flashy feature like a new profession or a new combat loop. Instead, it’s a foundational quality-of-life and stability upgrade. The goal is simple: the core loop of moving from habitation to hospital to spaceport to hangar (and back again) should work consistently, even under stress, across long play sessions, and with multiple players using the same network.

Important scope note: this rewrite is about communal transport and elevator/tram networks. It is not a rework of freight elevators, which are being developed under a separate initiative.

Why CIG is prioritizing this now

As Star Citizen continues moving toward more advanced backend tech (including larger-scale instancing and broader server meshing goals), “simple” systems like elevators and trams become more complex behind the scenes. The older transit implementation has struggled to keep pace with newer tech requirements and the realities of busy landing zones.

In practical terms, transport reliability isn’t just convenience. It affects:

• Session flow: getting from bed to ship without a reset.
• Group play: parties moving together without desync or blocked doors.
• Economic loops: cargo, bounty hunting, salvage, and mission runs all start with getting to your hangar.
• Player trust: fewer “I died to an elevator” moments means fewer wasted kits, repairs, and time.

When the transport network fails, it can indirectly cost credits and aUEC through delays, missed contracts, re-kitting, medical respawns, and lost momentum. That’s why this kind of refactor matters even if you never think about it when it’s working.

Where the new system is currently active

This is a limited tech preview and not a full replacement across the Persistent Universe. During the test window described in the source, CIG recreated specific locations on the new system while leaving the rest of the game on the older transit tech.

Locations included in the tech preview

• Area18 (ArcCorp): the full location is on the new system, excluding event halls.
• GrimHEX: central physical elevators and hangar elevators are included.
• Orison (Crusader): hangar elevators/gateways only.
• New Babbage (microTech): hangar elevators/gateways only.

Everything else remains on the legacy transit system for now, and vehicle elevators are not part of this phase.

Why “Area18 excludes event halls” matters

When a landing zone is partially migrated to new code, edge cases tend to show up at boundaries: routes that used to be “all one system” now cross between old and new. If you’re stress testing, those transitions are often where timing, streaming, and door-state issues appear.

It’s also a reminder that this rollout is incremental. Even if Area18 feels better immediately, other hubs may still behave like classic transit until they’re migrated.

CIG’s stated intent is that most of the rewrite should be undetectable to players when it’s working correctly. You still call an elevator, ride to the lobby, take a tram, and head to your hangar. The difference is in reliability and in a few key interaction changes.

1) Destination queue mechanic (multi-player elevator logic)

Elevators now use a destination queue. In practice, this changes how shared elevators behave when multiple players are inside:

• Each player in the elevator can make one floor selection.
• Destinations are queued first come, first served.
• If a player changes their selection, they are de-prioritized in the queue without disrupting other players’ selections (including players who chose the same destination).
• If a player disconnects, the elevator should handle the queued destination gracefully and avoid opening to an invalid location.

This is a big deal for busy hubs where elevators are constantly shared by strangers, party members, and players moving in opposite directions. The intended outcome is fewer “wrong stop” moments and fewer desync-driven door failures.

2) Hangar elevator panels are local and personalized

Hangar elevator panels are now local/unique per player. Instead of everyone fighting over the same shared list, the panel should show the destinations you personally have access to, including:

• Your own instance destination
• Any hangar or location shared with you

The most noticeable quality-of-life improvement here is simple but impactful: your own hangar appears at the top of the destination list, rather than being buried at the end. When you’re repeating the loop (hab to spaceport to hangar) multiple times, this reduces friction every single trip.

3) “Hold doors” button

A new hold doors button extends how long elevator doors stay open, up to a limit. The intent is to reduce missed rides and awkward party splits, while still preventing infinite door holds that could be abused to grief traffic.

For group play, this is especially useful when one player is delayed by inventory, kiosks, or streaming hiccups and you need the elevator to wait just long enough to keep the team together.

4) “Void doors” should be largely eliminated

One of the most infamous transit failures is the door opening into the void (or a non-streamed space), which can lead to falling, death, or getting stuck. Under the new system, the goal is:

• A door should not open until the carriage is ready.
• If a door fails to open, switching to a different gateway is recommended.
• If a gateway opens to the void during this preview, it’s treated as a sign of a more critical issue that needs reproduction and debugging.

Even with improvements, it’s still smart to treat any suspicious door state as dangerous. If something looks wrong, waiting a moment, choosing a different elevator, or regrouping can save you from a medical respawn and the time cost that follows.

Take a look at: the Alpha 4.8 roadmap preview covering the transport refactor

What CIG wants testers to do (and why it matters)

The test focus is not “try it once.” It’s repeatability, stress, and long-session stability. The requested loop is essentially the most common landing-zone routine in the game:

• Habitation or hospital to spaceport
• Spaceport to hangar
• Hangar back to lobby and out again

They want this done multiple times, both directions, with and without other players in the elevator. They also encourage normal play across multiple days, returning to the migrated locations to see if transport stability holds up over time.

This kind of testing is what reveals the “it only breaks after six hours” bugs, the “it only breaks when three parties arrive at once” bugs, and the “it only breaks when the hangar streams out” bugs.

Because this is a tech preview, several user-facing layers are intentionally incomplete. If the system feels “barebones,” that’s expected.

UI is functional, not final

Only basic UI functionality is present. Planned UI improvements include:

• Categories of locations instead of one long list
• A visible representation of the destination queue
• Clear messaging when elevators are delayed

Audio announcements are missing

Elevators, trams, and gateways are missing audio announcements during the preview. That can make hubs feel strangely quiet and can remove some of the normal “feedback” players rely on to judge whether something is working.

Self-repair is intentionally excluded

CIG plans a self-repair mechanism so transport networks can recover from blockages with minimal disruption. It’s intentionally excluded from this first preview to make debugging cleaner: when something breaks, they want the failure to be visible and reproducible rather than auto-hidden by recovery logic.

Known issues to watch for during the test

Even with the rewrite, the preview build includes known issues. Knowing them helps you avoid misattributing problems to “random Star Citizen jank” and helps you pick safer workarounds when you’re moving through hubs.

General transport issues

• Instanced hangar elevators may return to the lobby and open if the hangar is unstreamed.
• Selecting multiple destinations at a starport/hangar may send the elevator to the lobby before the next destination.
• No quick-interaction prompt may appear for panels used to call elevators.
• Some carriages can overlap at the same gateway and open incorrect doors.
• Panels can initially read as restricted during load, then update to your handle.
• In rare cases, an elevator may still open to the void from within a player hangar when multiple players use elevators at the same location.

• Panel text may overlap other UI elements.
• Arrival timers can appear to freeze at certain angles/distances.
• Some destination signs may be missing timers (notably mentioned for Area18’s plaza).
• Panels may flicker when accessing multiple floor levels.

Audio and environmental sound issues

• Orison gateways and carriage doors may be missing sound effects.
• GrimHEX physical door elevators may be missing sound effects.
• Environmental SFX may be missing inside or outside transport.
• Area18 starport lobby announcers may trigger early while traveling from hangar to lobby.

Take a look at: what changed in 4.7 and what to expect next

Practical travel tips while the new system rolls out

If you’re playing in a build where some hubs are on the new transport system and others are still on the old transit tech, treat travel like a risk-managed loop. The goal isn’t paranoia, it’s minimizing downtime.

Use “safe habits” that prevent time loss

• Pause before stepping through newly opened doors if the interior looks unlit, empty, or wrong.
• Prefer a different gateway if a door fails to open or the elevator behaves oddly.
• Move as a group and use hold doors to prevent party splits.
• Don’t spam destination changes; the queue system de-prioritizes changes and can complicate shared rides.

Plan for the economic friction of hub instability

Even when transport bugs don’t kill you, they can burn time, and time is money in the PU. If you’re trying to stay efficient with Star Citizen money making loops (cargo, contracts, or reputation grinding), it helps to budget for occasional hub delays: fuel costs, re-kitting, and missed mission windows add up.

That’s also why some players keep a progression buffer for ship and component purchases. Whether that buffer comes from gameplay loops or from out-of-band planning, the goal is the same: keep your session focused on what you actually want to do rather than getting stuck re-running the same commute.

How this connects to Alpha 4.8 and the road to meshing

The transport rewrite is designed to be scalable and robust in a future where the game is increasingly reliant on distributed simulation and more dynamic streaming/instancing behavior. If Star Citizen is going to feel “1.0-ready” in everyday play, the basics must be dependable: doors, elevators, trams, and hangar access should work nearly all the time.

For players, that translates to a better baseline experience: fewer forced relogs, fewer accidental deaths, fewer blocked routes, and fewer wasted runs just to reach a ship. For CIG, it’s a core piece of infrastructure that needs to hold up under real player load, not just internal testing.

Is the new transport system replacing freight elevators?

No. This rewrite targets communal transport like trams and standard elevators. Freight elevator work is being handled under a separate development effort.

Which locations should feel different right now?

In the tech preview described here, Area18 is broadly migrated (excluding event halls), while GrimHEX, Orison, and New Babbage have specific elevator/gateway pieces migrated. Other locations still use the legacy transit system.

What should I do if an elevator door won’t open?

Try a different gateway/elevator and avoid repeatedly forcing interactions. In this preview, a door should not open until the carriage is ready, and failures can indicate a local blockage.

Can the “void door” bug still happen?

It should be significantly reduced, but rare cases may still occur, especially under stress with multiple players using the same hangar elevator network. If something looks wrong, don’t step through.

Why does this matter for earning credits and aUEC?

Reliable transport reduces downtime between missions and hangar access, which helps any loop that depends on consistent pacing, including Star Citizen aUEC farming and reputation-focused contract chains.