Star Citizen Live | Tech Talk with Benoit Beausejour

Well, so if I recap, almost same date last year was when we actually launched 4.0 and server meshing actually went to the live environment. And so it's kind of the one-year anniversary of the tech being available for all players. It's been surprisingly solid. I like to say it this way because it's a very large system. But it has given us just good foundation for what we had to do last year in terms of the content drive that we've pushed forward, the performance improvements that we wanted to deploy. We were expecting a lot more turbulence with the release of server meshing than we've had in a year. It's been a very, very stable system overall. And so I would say, if I look back at the year, obviously there's always problems with new technologies, but the server meshing itself has been very, very solid for us.

Well, if you walk back to the Star Citizen experience before 4.0, so before server meshing got introduced, a server crashing, that was the end of your session. You would lose your ship. You would lose your cargo. Everything would disappear. You'd have to reconnect, restart the client, start over. Anybody who's lived through the first years of development of the project knows how intense this was. So the first thing that server meshing brought us is server recovery. And so because of the fact that the replication is separated from the simulation, when a game server crashes, which is where most of the crash risk exists, the state of the replication is still good. So we just tell you, hey, we're getting another server. You stay there. And when it comes back, we can recover exactly where you were. You don't lose your ship. You don't lose your cargo. You don't lose your materials. And I think that's been a very, very big, it's kind of the unsung hero feature of server meshing. It helps with engagement, playing longer sessions, finishing missions. And so for me, that's one of the big, big pluses that was brought in with server meshing.

On top of that, and we did have some crash isolation, to be clear, in 3.24 and before, right? But what server meshing really brings also on top of that is crash isolation. So if a server is in charge of the Crusader area and he's the one running into issues, then only that area is affected. And so the player who's bounty hunting in Pyro or something like that, he's completely safe from his crash. And the perceived stability has increased a lot based on that. On top of all the work we've done to prevent servers from crashing in the first place, this whole setup has made the game a lot more stable in that sense.

So that's just the kind of meat and potatoes of what meshing has brought us, but the key bit it brought us also is much larger player counts. And so we used to be limited to 100 players per server, which had the whole universe to simulate. Now we've got a series of servers simulating the universe. And so we oscillate between caps of 600, 700, 800. We're still experimenting going higher with this; depending on multiple factors, that cap changes for the moment. But just the fact of having more players in the same shard means you can have an event where 200 people show up at one area. Surprisingly enough, we've also discovered things through this: sometimes game servers actually perform better with more players in one area than one server simulating the whole universe would, because he has less entities streamed in and now it's all about updating the components in that area. So we've seen certain events, because players always find a way to organize something that should be a problem, but there was a 400-player party in one of the bars in New Babbage, and we looked at the server performance through that, and it was actually very, very decent. So we expected the full meltdown, but it was actually good. And so that enables that experience, right? Obviously, there's a million other problems to solve for this to be a really good experience, but from a server meshing point of view, that was a big win. You've got a 500-player meetup coming, I just saw something. It's like that becomes a kind of common thing. And we love it because that's exactly what the tech is meant to enable.

And then obviously the two other things that meshing has brought us this year is two new solar systems. And so for years we've been stuck in Stanton, expanding the Stanton system, more POIs, more planets, more things. And now suddenly we were able to branch into Pyro, which everybody at CIG was really looking forward to. There was internal tension: when are we going to launch this thing? I've been working on this for a long time. And so that was really a relief to be able to get players to cross the jump gate. So the jump gate technology obviously comes with meshing. And so expanding into two systems in one year.

There's one more thing that server meshing brought us that's not negligible: a very substantial gain of performance on the game servers in general. So when 3.24 game servers were running, we had a very low bar for acceptance on FPS for game servers because we just had to deal with so much. Nowadays, server FPS is magnitudes higher. So that actually allowed some of the content we've already produced to actually shine because it was working properly. And so that's because servers have less to simulate. We can optimize their workload. We've also reduced, I mean, we've talked about this before, the size of the game servers because they just have to simulate one area. And so overall, meshing has improved server performance by big magnitudes.

Well, so the dynamism in the mesh. So we're running out of words internally to define what the next step of server meshing is. Currently, we're working on quasi-dynamic server meshing, which is we're trying to iterate on the static mesh to bring it so that if an area is empty and nobody's there, we can spin down a server. And if people go to that area, we can spin up a server. To achieve all this, all of the mechanics required for a full dynamic mesh need to be there. So like mass authority transfer between servers, because when a server goes out and it has X amount of entities that it currently has authority over, it needs to give that to another one, and obviously you don't want that process to lock up the parent server. So that whole mechanism is what we're working on at the moment. In fact, over the break, the team has actually reached a milestone. We were able to run with our internal testers a test of quasi-dynamic server meshing internally. So that's good. I mean, it's the first test, so a little bit rough, but it basically requested, I think, 200 servers to run the mesh. Our ops teams, Ahmed specifically, I got a call from Ahmed immediately.

So you did your first test of this quasi-dynamic. Like, hey server, you try to determine how much you need, and the first thing it did was ask for 200 more servers?

Yeah, exactly. A little bug in the assignment system. So that's what we're working on right now. That's the next step towards the full dynamic mesh. Obviously, the goal with the dynamic mesh, just to recap it, is that instead of having a subdivision that we pre-make in advance, like currently, every patch we look at the territory assignment, is what we call it, of what's coming: oh, we have an event at this place and most players are going to go to this system, and so we adjust the mesh, right? And sometimes you get it wrong, and it's a very manually intensive process and we don't want to keep doing that. So the goal with the dynamic mesh is to be able to just adapt to where the players are, the cost of the location they're in, to be able to provision compute dynamically up and down. So there's also the unfortunate cost equation in this, right? The current static mesh will always provision the server for every territory that's configured. And so there's a little bit of savings we can go and get there. But more importantly, the dynamic aspect of it is to be able to always make sure that the proper compute is available for players when they're in an area doing something. So that's the goal.

Well, so I think that obviously coming from the server meshing improvements, there were also some failings at the beginning of the year where we saw transit became a very big problem. That's an example of a system that was built years ago that wasn't properly scaled over time. When you added dynamic gateways for the transit system plus the meshing situation, that became a really problematic system. That was, I think, the first order of business once we launched 4.0: we need to really take action on transit. And so we talked about this last year, but we did create the Transit Heroes group, which was a coalition of volunteers. Well, they got volunteered. Voluntold, exactly. To come and give a bit of oversight on this, to look at the system to see, okay, what do we need to actually have stable elevators and trains and make sure that that's always available? Because the traversal of the game, if that doesn't work, then the game doesn't work at all. If you can't take an elevator to get out of the habs, then good luck, right? So the Transit Heroes team, I think, has done a fantastic job. They haven't re-engineered the system in that strike team, but they really focused on self-healing strategies. If a manager loses a carriage for any reason, we'll just create another one and get this thing rolling. Now, they couldn't rebuild the system in this effort. There were fundamental flaws in how it was engineered for server meshing support. But at least they got it in working condition. So I do think if you look at the game now, transit is no longer the big problem. It actually functions when you need it. Now, that said, it fixes itself, right? It gets in a weird state, but it fixes itself. So we've done more about this and we'll talk about that later.

And we're building the transport system concurrently. So while this team is repairing the transit system, we're building a new bespoke transport system.

Right. So transport is basically the fix for this, the real fix.

Well, I've got a list here that I worked out a little bit with Jens, just to gather up because the game is so big.

So I'm going to limit you a little bit on this time. I'm going to give you five minutes.

Okay, 30K protection. Transit improvements, right, to make it stable. A stable tech base for the content teams. What doesn't show is that to achieve the content we shipped in '25, we actually froze a lot of the technology to give the content teams a stable base to work off. Before, it was a bit more of a mayhem. So we did that. As we built all of this content last year, a monthly patch was a very heavy cadence. 10 patches last year. I think that what's really cool is that we've built kind of a library of locations and events that if you start playing Star Citizen today, there's that to do, right? We never had that before. A real set of locations that have a full-on storyline to follow. So that's really cool. In these locations, we were able to ship some new creatures. So a lot of new creatures and boss fights. So we had the first couple of boss fights this year, with Jormandy's Thumbbreaker. So that's a brand new design discipline for us, to design boss fights for multiplayer elements. So that's new. Spawn in hangar is something that we've actually been able to enable this time. So we tried to enable that at the end of '24 and that was a bit of a disaster. '25 now, spawn in your hangar is there. So if your hangar is available, you spawn directly there. That's actually a very large quality of life improvement. I play the game a lot. Not having to go to the habs is fantastic. We've been able to put weather in key locations, including some of those big hero locations we talked about. We're hoping to do more, but for now, it actually is there. Two new star systems, we talked about this. Jump gates, which is a game on its own. The way it functions is actually super interesting, as you're going through, the zone is moving and you're moving within the zone. It's really a fun system to go through. So that's in. We fixed the goddamn bounty beacons, which is one of the coolest loops in the game. I love it. And that was obviously not working. So now we've actually got them to work again, which is a big win. Quantum interdiction was in the same bag, where now with a server mesh, having proper interdiction was kind of difficult, so restoring it was an interesting one. We had to actually build systems to allow that, because not every server has a view of the entire shard anymore, and so in order to interdict cross-server, you needed to have a special tech to do that. That fixed also quantum linking. Now, routing, there's still issues, right? It's getting there, but at least there's been some quality of life improvements on that side that we've done this year. Freight elevator: ongoing, ongoing, ongoing. We'll have a whole section on freight elevators. But throughout the year, freight elevators have received tons of fixes.

Compared to where they started when we attempted to push them to the forefront for an event.

We talked about server FPS and stability from the meshing and the cleanup that we've put in place. Also, we pushed in the middle of the year, it came for you guys at the end of the year, but actually we merged it in the middle of the year, a whole new tech base, including at least a year of graphics updates, including Vulkan, coming into the game now. That's what will allow us this year to do some pretty large changes as well. The first weaponized mech, so the ATLS IKTI came in, so that's also a really big boost. We still don't know if it's a vehicle; John Crewe and I have this ongoing feud. He says it's not. I say it is.

You're dipping into content here. I'm not going to let you count the IKTI. That's content. Although the jump jets were a feature, I suppose. I'll give you half credit for the IKTI.

Thank you. I will take that. Comms notifications got a big facelift. It's something that we want to use a lot more of. And so we needed the proper tech to be able to render that properly and not just the equip lines; you need more immersion than that. So that was actually a pretty big thing, with facial animations and tracking. And so that's in there. And then cross-shard progress for events. So what powered a lot of the content this year was a new service in the background of the game called the scenario service, which, whether you're doing Clean Air or the Resource Drive last year, the cross-shard progress of these events is tracked by the scenario system. And so that's how we were able to show tables about how many resource drives, stuff like that.

So transit was problematic, wasn't designed for server meshing. And so transport is a complete rebuild of the transit system, but using server meshing native approaches for how different pieces are going to manage elements that are streamed out and streamed in. We're also moving away from some previous misconceptions that were put into the transit system. For example, one of them was responsible for trains going into space. We don't want trains to go into space. Well, I mean, unless we do a space elevator. Astro train would be great. So the state of transport, right? So at the end of last year...

Sorry, I'm going to pause. What's included in transport? What are we talking about?

Transit and transport manage elevators, in-ship elevators, trains, anything that has to move when you press a button and you call it. So it's a network of carriages, peripherals and gateways. So you take an elevator to go to your hangar, that's transit. You take a tram. Anything that's automated, anything that moves you not under your control. And he's the one moving the carriages. So he needs to deal with carriages being streamed out, prediction for that stuff. So transport is a rebuild of the original transit, which has been, as we talked about, problematic. So the state of transport at this point is it's functional. So the team at the end of last year actually completed the first transport link, and we tested this internally with our QA teams extensively at this point: all of the New Babbage habs links. So we took one link in the universe, that one, and we tested the crap out of it. That's a static link. When I say static, it means the two points that the elevator goes to always exist. So we know that works. Then the state at the moment is we also support hangars. So these are dynamic gateways, because if you're online and you're at the location, your hangar spawns there. That's a dynamic gateway. If you leave, that gateway disappears. So the system needs to deal with dynamic gateways. The previous system kind of did, and that bit was the piece that wasn't great. And so we've got internally at the moment New Babbage, we've got hangars and habs. So the state of transport now is the team is working at converting all of Area18. So we're talking habs, hangars, transit trains, all of Area18 to the transport system. So we're going to go to Tech Preview with that. That's our plan. And the reason why we need to go to Tech Preview is because we need players. We've tested this internally. We can't muster as many players as we want. So we're going to see if you guys want to come and help us out, test the new transit for real on a Tech Preview to validate all the assumptions that are in the system.

So we're going to launch a Tech Preview and ask people to just come and ride the elevators, come and ride the trams, and their hangars.

And hope nobody dies. No trains in space. No doors opening to nothingness. That'd be great. No passing through the floors in the carriages. And so after a Tech Preview, if everything is validated... There's one thing, too, we want to try to avoid: the train prediction where the train says it arrives in one million and sixty seconds, which obviously we hope to fix. So after Tech Preview, we're going to scale this out to every landing zone, and we're going to see which patch this will land in. But at that point, we hope to bring transport in and completely deprecate the transit system from the game and nuke it from orbit. We don't give dates. Best effort, but it's looking good. This Tech Preview is going to be where we evaluate really where we're at with scale, because the issues of transit typically come up with scale most of the time.

The freight elevators are way more complicated than we can imagine, because they get affected by other systems like hangars, like planetary locations. There's also multiple flavors of them, top loading, side loading, and they all operate very differently. So this year, we've had issues at the beginning of the year clearly with the freight elevators, like losing items, and obstruction blocking them from functioning.

You said the beginning of the year, but that really came to a head in July.

Yeah, where we even had an event that would rely on them, which was, in retrospect...

Well, we knew there was a collection of issues, but all of our data said they were only localized. It wasn't until we went to scale that we realized this is actually even worse than we thought.

Right. It's also coupled to a couple of things for that event specifically, which was concentrated missions in key locations. That's one thing that has been in our discussions all year. The first thing we did was look at how we distribute missions. If we launch a new mission tomorrow morning and we send everybody to the same spot, that is problematic, not just because it's not fun, because it's a traffic jam, but also it causes other issues. We learned a lot from that on the design side, I think, overall. So we're pretty happy with some of the core mechanics, but there's still very egregious issues that we're tracking. So there's roughly 73 total issues that we know about. 51 of those have been resolved. So I've asked one of our team, Nathaniel Fisher, our resident expert in freight elevators, to track that. So the rest of these issues, some of them are really problematic. One of them we actually discussed, you and I, just before the show, was how if you're turning in Wikelo items, you need to put them one by one.

You have to be able to put things in a box and have it suck up that box.

Yes, I agree 100%. And so that's going to be one of the first ones I think we need to look at. The other one is a bit more problematic because we don't have a proper repro for it, but sometimes there are lost items if there's a back-end slowdown when things get stowed. So we have a couple of reports for this. Not many, but the ones that we have are critical. And so this is a kind of rule we've set on the CGP team. So Jens and I are pushing this to everybody: the golden rule for everything related to freight elevators or anything that touches inventory is a player should never lose an item interacting with these systems, right? We need trust in them 100%. And so that's why we're chasing those issues. So there's still a lot more work required on freight elevators for different edge cases. A new one that we started seeing in 4.6, which seems affected by another change, is sometimes putting stuff on the elevator not on the grid will cause it to disappear, which is kind of a physics cleanup conflict. So I know we're looking into this right now because that's a big one. And then everything that has to do with stacking. Having a stack in your inventory that you want to unstow onto the freight elevator, that mechanism from a backend perspective is actually a creation. I know that sounds weird, but you have a stack of 10, that's one item with a stack of 10. You bring one, it's a creation of nine. So that bit is not stable right now. We're trying to improve that mechanism.

Obviously, T0 was a fairly large change to the game. In the case where you die in the verse, instead of having to do a corpse run to recover your items, you would actually respawn with them. This was mainly done because we're in an alpha game, we needed to do some compromises, so we looked at that. So item imprint, there's multiple names for this at this point: item imprint, item recovery tier one, entitlements 2.0, those are all the same. So the gist of it, and this ties into some other subjects, is that currently when you play the game and you look at your ASOP terminal, I think I've said that last time, but I'll go through it again. When you look at your ASOP terminal, the list that you see there is the list of entitlements that you own, which ships you own, you have a right to, right? Then that's cross-linked with the actual ship. You have this entitlement, let's say it's a Connie: what is it in the game, right? And where is it? And that's how the ASOP terminal shows you the list, right? So that's why you're able to have a row when there's no ship and it says retrieve or deliver, right? That creates the ship. Then deliver brings you the ship on the platform. Those entitlements currently don't live across patches. We recreate them. The first time you log in, there's a big process that reconciles your account, grabs your web purchases, grabs your LTP records, and recreates those entitlements. Obviously, long-term persistence has always been kind of a difficult problem to solve. It sounds simple, but it is not, I assure you. In order to facilitate all this and also other item recovery needs, we've decided to basically persist those entitlements across patches. So these things will never get wiped anymore. And so losing a ship is not going to be a thing. That's not going to be technically possible. We never really delete entitlements. And so you have insurance on those records, so you can claim insurance. The only way to lose a ship will be if you no longer have insurance on it. You still have the deed for it, but you can't claim it. So item recovery is a rework of the entitlement system. It touches on how you claim insurance on ships. It allows snapshotting of ships but also FPS items, so that these live with an insurance loadout that we can keep and recover. And then it will give us the ability to recover or claim even your FPS items. So think of it as an insurance system for FPS items. So this whole mechanic ties into LTP as well. We're also hoping through the system to solve some of the issues that exist with taking components off of a ship, then claiming the ship, losing the components, or in some cases being able to duplicate some default components. Insurance has always been a problem design-wise for how this functions. So item imprint v1 allows you to imprint items, save that state, and then recover it on death or when you claim insurance.

You keep mentioning insurance. Are you saying that insurance will be in alongside V1?

I say insurance because that's the same kind of loop in terms of what the services are doing to do this, but basically it's a snapshot we recover from.

So when item recovery V1 comes out, it'll still be much like it is today as far as insurance. Everybody has LTI on everything at the moment, until that very specific gameplay system is implemented. So this is not that. You're using lowercase-i insurance.

Lowercase i, yes.

Well, not with item imprint, right? As part of this, no. But there are, I don't want to go too much into details on this, but I can give an example: you have a ship filled with cargo that you stow into your location inventory in New Babbage. And you claim that ship, right? In the current way the system works, that cargo's lost, right? That ship will get deleted and you're done, right? You get a new one, but it's the same entitlement. With the new system, we have the ability to also show you ships that you own that had an entitlement on them. And so what that means is you could claim that ship. Let's say it's a Caterpillar filled with cargo, and you're like, I need to claim it for some reason. You can claim the ship. The other ship will be bricked, right? That's how the design is functioning. So it's no longer usable, but you can still retrieve the bricked ship and get it. And then if you destroy the ship or tow it out, then it'll go away from the entitlement. But there's going to be more systems, of course, to remove that from your ASOP terminal longer term. Not in this phase, but longer term, yes.

There's more. I mean, there's a lot of work ongoing on the long-term persistence side. So just for those who don't know what long-term persistence or LTP is: there's a mechanism we put in place to allow you to keep things between patches, right? So every patch we basically destroy, like when 4.7 comes out, that's a brand new database, right? The whole thing is fresh and then we recreate things. Why do we recreate things? It's because these things are still changing. So the Hornet you had in 4.5 is probably different than the Hornet you have in 4.6. Item port locations have changed, materials have changed, serialized variables and all the data that goes with it has changed.

The Gold Standard Aurora that we just launched is technically an entirely different ship. To the backer, it looks like you just added some fins, but under the hood, it's an entirely new set of entities.

That's right. And so in order to allow us to keep stuff, we've built this system on the side that kind of keeps records of what you own. So it says you own a Hornet, right? That system has always been kind of a, I want to say a crutch, because it did function for a long time, but we've outgrown it quite a bit. There are also many cases where we would remove records of things that you own because they're in play in a shard. That's been proven to be a bit of a bad decision overall, and so that's why we've had multiple issues over the years of players losing ship entitlements in the new patch or having more items than they were supposed to get. Some people have shown screenshots of multiplication of things between patches, and so it's been a big issue. With the item imprint work we're tying into that, we're reducing the footprint of what LTP manages by a lot. It will no longer store your entitlements. We just keep those as is. So that's one big bit removed from that system. The other complexity on that side is that it needs to manage nested inventories. And that's just completely crazy. So I have a handgun stored in the glove box of my Merlin that's attached to my Connie that's parked somehow inside of my Idris and stowed in my location inventory. Well, I need to give you a record for that gun, right? And so that system needs to read data and store it, and it's really complicated.

Which is why people have gotten into the habit, before a patch, of stowing things in certain inventories to have their best chance.

Yeah, to kind of set it up, right? So on long-term persistence, ultimately, we don't want this system, right? Ultimately, we want to get to a point where we don't need it. So step one is to reduce its footprint. So that's part of item imprint. So that's a big deal. But the next steps start from the very low level and will require some large company change. We need to be able to migrate your old Hornet into the new one, right? Or at least be able to know it changed enough, I need to give you a new one. Or being able to just migrate the shape of the hierarchy, the item port locations, and the serialized variable formats on these things. Now, you've got to think about the way the ships are built. The entities have components on them, which enable them to do something. I'll give an example just for the layman. You have a health component on an entity that says, hey, I've got 100 hit points. When that reaches zero, then we destroy the entity, or something else happens, it destroys itself, right? That component is written in code. There's a game programmer maintaining this. We actually have a health component. It does way more things than this, but just to keep it simple. So a game programmer's programming this and he needs to persist the value of health, so that when this ship is put in an inventory then brought back into the game, the values of the health components on the individual parts have persisted and are reloaded. This is true for everything in the game. We have serialized variables and components across the game. I think your character at the moment has like 800 serialized variables on it or something like that. So those are all different components. Are you crouched? Are you standing? Health of all the limbs, stuff like that. Programmers between patches, they just change that. I removed this one and I put a new one in. Some of those variables, it doesn't matter if it changes. Some of them matter. If you change that, it's a different shape, it loads a different CGA model, whatever. That's the big problem about how we need to forward migrate: we need to do this at the very low level. So currently our network team and our online teams are working on this mechanism to be able to differentiate the important from the unimportant SVs, the serialized variables, on components. So that's across all components in the game. There's over 1,500, 2,000 individual code components in the game. For example, I don't need to know if you're crouched when I stow you in your inventory. But I need to know that when we're running and you're crouched. So we differentiate the two, and then we have a mechanism to migrate the data format from one to the other. When we get that functionality in and reliable, what that means is that we will just keep the database. And that is huge, because now that means there's no longer a process between patches that transfers stuff or moves it around or recomputes things. It's the same database. We're just moving its version forward on demand. And we've looked at multiple different options for that. Some of them were just migrate people from one to the other, but then we'd have to keep five databases behind. It's just impossible. And so right now we're working on that option. And that's the longer-term vision that we have for that. So first, reduce the footprint of the LTP system so it just manages some things, not all. And then work on the real fundamental issue, which is we need forward migration on all this data.

I mean, it's crazy. This is the single most important thing. Because in case you guys don't know, every time we do... Well, a full patch is easy because we patch server, client, hybrid, everything goes at once. But when we perform hotfixes, and God knows we've done a lot of hotfixing this year, that's part of our process now, there's specific steps where our live QA team needs to do compatibility checks. And any change to any serialized variable, added, removed, changed the format, changed the data, whatever: incompatible client. Getting our processes in place to catch those before they get introduced is really taxing, because there's always a, oh yeah, also fix this bug, and that makes the whole hotfix incompatible and we can't launch it. So we have to backtrack, change our approach, whatever. And so that's the kind of thing we're dealing with. This will also solve that if we can make it.

A Social Universe, right? The last panel that we did at CitizenCon outlines the vision of what we want to do with social. Now, with the year that we just had, we had to take a little bit of a detour on that initial plan. But right now, we have completely formed the social strike team. A bit like the heroes team, the social strike team's only mission is to execute this plan.

So don't bury the lede. There is now an official dedicated team on this.

Social strike team, yes. Exactly. And so this group is currently looking at all of the components that make up the social systems now. Fortunately for us, the work didn't stop on this side, even though we couldn't enact the changes in the game. On the back end side of things, there's been a lot of progress on social. And so even though the systems look primitive in game, their capabilities have grown quite a bit, even in '25. So we do have a block list that we leverage now. It's simplistic because we didn't have the UI resources to do it completely. But moving into this, the strike team covers all areas of social. The plan is to go into four different pillars for it. So the first order of business is the Comlink app. So the Comlink app is one of the oldest mobiGlas applications we still have. It's kind of an eyesore because it's from the days of future past. It's from, I want to say 1918 at this point, style-wise. Very old technology, still uses the legacy UI framework that we had in the game. We're completely eliminating that tab. We're bringing forward the social application that we've shown at CitizenCon, so that design is moving forward. So replacing that, the chat widget, right? So the entire chat experience in the game, we're completely overhauling this from the top at the moment. So we're right in the process of changing that and hooking it up to the new systems. Revamping things like social notifications. Currently in our mobiGlas we only have one kind of level of notification, which is ultra important. So to have a proper social experience, you need to have these system updates, system notifications, like someone joins, someone leaves, whatever. Looking at things like combat log and all this stuff that we've looked at in the Social Universe panel. So we're actively building this now. And that's going to be the first, I'm not going to say which patch it's going to land in. So our schedule is twofold. There's a content patch schedule and there's a feature schedule. The features need to have leeway because it depends on where they're going to land. But the first update to social will be the Comlink app. So rich party information, friend info tracking, chat app. So we're working on this right now actively.

For a 2026 release?

Yes. I mean, like you mentioned, it's kind of urgent at this point that we do something there. The next milestone for the social strike team is going to be looking at the party finder mechanic, right? Which basically allows you to advertise your party and then get people to join in. Let's say you're looking for a gunner and some FPS guys for your mission, then you can advertise that; if you're looking for friends to go do a specific event, you can do that as well. And so Party Finder, we're hoping, is going to be a way for you to find friends on a given shard really rapidly. Tie that in with your friendships and your contacts. So we're building on the first release, which will have friend info tracking, into that. And so that's going to be super interesting. That's the second system we want to bring in. And then number three of four is the org system. And so in that space, we're taking the orgs on the website from 2013 and we're moving them completely. Obviously, the technologies we used to build that in 2013 are obsolete. It's a really old system. So we're bringing all of this data back into a game service to manage orgs. To surface that, obviously, game side. So now have org management screens, have your organization chat in the game, and then actually be able to create your organization from the game as well, as well as surface it outside. So that's like, okay, now orgs are in the game.

That's the whole name and then the org, you know?

Yeah, exactly. And this will probably, I mean, we're still having internal discussions about how that surfaces. In our game, nothing is always set in stone, but it's probably going to tie into FPS scanning, radar, additions to when you fly your ship to identify others with scanning. And so the orgs will be part of that. Visibility in game, chat in game for your orgs, actually having your organization communications.

Okay, so VoIP, we're doing improvements there on the backend side of things. So VoIP is mainly, right now, heavily affected by the shard size. So the original design for this was really made for the 100-player servers. And so we haven't had a chance to go back there at all. As part of this work, this team is also going to look at the infrastructure for voice transmission and we're going to try to make it scale to the proper thing. So one element that we're talking about on chat and comms is that we're probably going to be moving away from the server chat, so the original global 600-player chat, and move into regional chats like a true MMO, so that it's tied to the region that you are in, maybe multiple channels for that. And so VoIP will also be affected by that, because it also powers proximity voice. So we're looking at voice transmission from top to bottom. We're changing the whole backend for this to make it scale there.

We're also, out of this, there's also some movement on player reporting for bad behavior. So not just blocking, which is something that we have now but that we want to expand on, but also player reporting for other players for bad behavior, profanity in chat, things like that. Obviously, at CIG, we don't have a large moderation team in game. So we're going to need some automated help there that will come and clean up some of these elements. So we're trying to really tackle communications from the top there with that strike team.

Personal. I've got two. So I would say for me in terms of quality of life, I love to play the game in a kind of larger setup. I have a flight seat that I like to operate to play the game. This thing has roughly 13 devices connected to the game. Managing bindings is literally the worst. And so that's my pet peeve. If there was one thing that I could do for my own game experience, other than the in-game elements, it would be completely control bindings. Currently we rely on device order for some things. And so literally you need to have almost a common order for the devices on your machine; sharing these profiles is very difficult. Being able to bind onto multiple devices to really benefit from that, being able to bind the same action on multiple devices, for me is super key. So that would be my absolute personal quality of life thing to solve: device handling in general.

And you're announcing you've created a hero strike team for this?

No. I wish I could just do that; it'd be cool.

So that's not something coming soon.

Well, there is work being done on the control systems, right? But not that I could say it's coming soon to Star Citizen, unfortunately. There's a lot of work there.

And while you're at it, it'd be nice if it stored them and saved them. If I've got to redo it every patch...

Yeah, I know. Saving them, cloud save across machines would be great, right? I mean, it's the kind of thing where I do maintain a couple of rigs at CIG. People are always changing bindings, but the problem is I can't reapply my bindings because the system doesn't support it anyway. I mean, it's because Yogi and I are always fighting over what the best binding is. Mine is clearly better. So we've decided that at some point we'll just fix the binding system so that we don't have to argue. Just load the one you want.

So my second one for inside the game is mission chains. I feel our gameplay is always one-dimensional. You do a thing, you finish it. I know we're working on an updated mission system.

You're talking about the limitations of the existing missions. You're not talking about the quality of the work of the people that are working on these things. You're talking about the tools that they have to work with.

Correct. The system around it doesn't allow us to do these massive quest chains, right? And I think that for me would be a huge quality of life, because you could go on a long adventure that takes you across multiple things. So I know we are working on an updated way to make missions that is a lot more scalable for that. And for me, that's a big quality of life, because I feel you can go on a longer adventure. And I think that's a big quality of life overall.

We built the first version of the mission system where you do a thing, you achieve a goal, and we can't hand you a thing. We've made changes internally to fix it, to adjust it, to replace it. It's currently underway. What they've managed to do with the limitations has been stellar. The event that's on right now, built with the existing system, built with the limitations, has our highest concurrency in the last two years outside of an Invictus or an IAE. We've got to unlock those tools.

That's exactly right. We've got to unlock the tools for them. For me, that's the quality of life update. And tie it into reputation, economy, so that it actually is one big loop.

Good, actually. I mean, I don't want to say surprisingly good, because the team did amazing work on it. But it's been going super well. I mean, there's a lot of work left, right? But I think that we got what we needed from the Tech Preview. And it wasn't a complete meltdown, which is always a good thing. But the team is working really hard to try to hit potentially a patch soon with crafting. I really believe that crafting is such a big step for Star Citizen as a whole. It will be a different game with the crafting system in place. And so the work that those teams are doing right now to bring this to life is incredible. I think that we're leveraging the technology that we have to be able to create runtime items with different properties and things like that. So far, the first Tech Preview has been surprisingly solid and a success, I would say. So now we're riding the coattails of that Tech Preview to try to see about a launch window for crafting.

I don't think it was.

So you can't have crafting without the inventory rework, but the tech preview for crafting doesn't have it?

Technically you can. It would just be really bad. It's more from a game design point of view. But the inventory work is going really well. I mean, some people have been reposting screens recently of the original concept that was shown; it's starting to look like that, so that's really good.

When does that go into tech preview?

We're hoping very soon, because at this point, every version that I've seen is fully functional, and so we just really want to solve one thing. You say quality of life; if I have a third one to add to my list: the speed of rendering of icons in the inventory. Right now, you open your inventory and there's always a moment where it's rendering RTT, the render-to-texture icons, for each of those. In case you don't know, this is a full 3D scene that gets rendered flat right there. We have versions of this in previous concepts where it's full 3D. It's super nice. It takes forever. The user experience is not great, right? And no matter the amount of work we're going to put into the UI and the functionality of inventory, the speed of the UI is really a thing that we need to improve. And so that's the part that we're still iterating on now. We've done massive improvements, but we need to dial that in perfectly, because that's the part we really want to solve. I feel good about it.

You feel good enough to say 4.7 in March?

I think so.

Very good, actually. We actually had a summit this week about instancing, about getting all of the levels set up to support it. So maybe I can do a quick recap on what we've discussed on instancing before. So we talked about server meshing, right? So instancing is basically an additional system on top of server meshing, which allows us to take an area of space and give it to a server in the mesh to manage, right? Doesn't matter which one. The geographical, the spatial position of this thing doesn't matter. So for example, when you go to your hangar right now, that is an instance. So what we're doing is we're taking this system and we're making a true instance manager with it. So we currently have the backend service completed for this. And so what that provides is the mechanism for creating an instance that is associated with you or your party, and having rules for how many players this instance is made for, enforcing player caps and party caps for that instance, managing the life cycle of the instance. So, go back to my WoW days, I mean, maybe that's dated now, but your Molten Core instance lives for 10 days, right? So the instance manager is in charge of doing that. So that system's in place now. And so the teams are currently working on how the entrance to the instance is going to work. Well, we know how it's going to work, but how it ties into the level. So level designers put in an entranceway. At what point are you crossing the boundary? What brings you to the instance? What brings you out? Transport is a requirement for instancing. So it just ties into all the discussion we just had. Transit cannot bring you to an instance, but transport can. So you can imagine an area of space that you walk into through an airlock or an elevator or a transit train. And when you come out, you're in the instance, but you don't even see the demarcations. Now you're inside the instance. You play inside the instance. You can gather items, inventories, whatever, boss fights, et cetera. And then you can exit through another transit link. And that's it. You're back in the world.

So if we do this right, you should never be aware that you're doing it. We might have to put some kind of indicator on there because of raid locks or whatever. There might have to be some UI stuff to tell you.

Some screens will show you like, oh, you can't enter this.

But from an experience standpoint, there's no load screen. There's no, hold on, please wait, we're transferring you. You're going to go, and suddenly the world around you is going to melt away and you will be in a section of the universe that is dedicated entirely to you and your party.

Exactly. To play it, right? And then we're also talking at the moment about how the instance manager responds to the mission system, because we might want to be able to change what level you're going into when you pass the threshold, or things like that. Or the access rights, right? So if you think back, man, I keep going back to WoW, but whatever. In the good old WoW days, you need to do Lower Blackrock Spire. At some point, someone has a key. That's the requirement that unlocks Upper Blackrock Spire. Well, we're thinking about mechanics in that vein that allow the mission system to lock or unlock access rights to an instance. And so all of this is currently being managed, but it's going really well. Most of the networking capabilities that we needed have been added already. So one of them is that currently when you go to your hangar instance, the way the server actually tracks that is we put a flag on your character that enables you to stream in your hangar and actually view your hangar when you go there. And we remove that flag when you leave it or when the hangar is removed. And so in the code up to now, we only have the ability for a single one of those on your character. So we can only give you access to one instance. But we need to be able to give you access to multiple instances, because we might have areas of transit that cross from one instance to another instance, things like that. We're going a bit deep with this. At the moment, those mechanics are ready, so the networking bit is done. So now we're really about crafting the first experience that we want to do with instancing.

And the first instanced content will be Siege of Orison Redux.

We announced that.

I can tell you, from being with the team this week working on instancing, everybody's super stoked. The energy is really high on how you enter it, how you exit it, what gameplay is going to be in it. There's also a big piece of this, which is that designers, in this case, can design an experience that is repeatable. Most of the content we've produced this year, there's a PvE experience for it, but it's fundamentally in a PvP zone. So this is giving them those tools to make something that's fun and repeatable as an experience. And I mean, the energy is really good.

Well, I don't know in this case exactly what they're asking for, but let's talk about regions. We already have regions. When you play the game, you can pick one of the global availability regions that we service. Obviously, North America is one. Europe is one. We have East Asia, Australia. I forget the other ones, but I think we have another one. Typically, we look at user data, and if an area reaches critical mass at some point, then it's worth it to deploy shards there and have shards hosted in that region. We do it between US and EU. Obviously, they share our common backend, so your inventory system is hosted in one central area, but then the actual game servers you're playing on, for latency reasons, are going to be closer to your area. We are revisiting our region distribution for a couple of reasons. Without naming any details here, we're in the process of doing some pretty large migrations in how we host the game. Even if it's a bit transparent, there is a lot of change happening there. And so we are revisiting our region map at the moment. But typically, the way that we've done this is we look at player data, and if we reach critical mass in an area, then it's worth it to start deploying some shards there. But it needs to be more than one, because deploying one shard in one area is problematic: there are cases where a shard goes into trouble for some reason, and before a hotfix is actually deployed, that shard is no longer usable. So it needs a critical mass, a proper cluster size, to be able to get there.

And the short version of that is you're currently having conversations about where...

Yeah, we're looking at that, because we've done some changes. So we have access to more regions than we used to. So we're looking at that. But I can't promise any changes. Again, it's completely based on players using the service.

Well, so there are a lot of developers at CIG that really like immersive experiences, right? And so there's a contingent of developers, and also one specific one, that have been really trying to get the Star Engine to work in VR. And so as an experiment and to build that, these guys, and Sylvain specifically, have been really pushing hard to try to get Star Engine to work in VR. He experimented with multiple different approaches over the last couple of months, settled on the OpenXR approach, and was actually able, through his own passion and then support from his other colleagues, to get stuff fixed so that we could support VR in specific cases. That's how we decided at some point, hey, you know what? This is actually pretty cool. Let's release it, right? We have a unique chance at CIG to be able to work on a custom engine and on custom technology. And so, encouraging that effort, we decided to release an experimental mode to see if people like it. And the response has been pretty impressive overall. The results that we're able to get in VR are a testament to some of the decisions over the years that were taken and how the game has been made. And so there's a lot of little things that just shine when you put the VR headset on, that maybe if you're playing just on a PC, you're not going to appreciate as much. I'm going to call out Chris Roberts here, but Chris always insisted on taking the difficult approaches to build certain features. There's a lot of things where you're like, oh, we could have done it simpler on this one. Yeah, but we took the hard road and we actually delivered it. And so now when you put the VR headset on, well, you've got reverse IK in the seat, right? And it's the kind of thing where now all these decisions have paid off in VR. And I mean, even internally, the arrival of VR, even before the experimental mode was shipped, was tremendous. A couple of hours here around our VR rigs next to my sim rigs with the ship team going, oh, I want to see my ship in VR, let's go, let's go. Because designing for VR is a bit different; the sense of space changes and whatever. That's truly an experimental mode that we've been pushing. Obviously, there's a lot more people around Sylvain to help him out and get this there. But I think that this is a testament to the technical framework that we have at CIG that allows that kind of effort to not go unnoticed and to show up in the game.

Chat's currently arguing about whether VR is a low priority or high priority.

The priority at this point doesn't matter, because it's an experimental mode. It's a bit like eye tracking. It's a bit like all of these side projects, like head tracking, eye tracking.

In terms of the economy in general, I think we're up to seven or eight right now. First of all, we have a strike team on this at the moment, looking at all these different things. There's a couple of ways in which there's been potentially duping, ways to earn rewards you're not supposed to have. And so we're looking at all these exploit vectors, right, to fix them; obviously, that needs to be prioritized. The big conversation that was spawned from that is: we're a game in development, but we're also delivering a live service, right? And so we don't have a framework for this, in that internally, when we get exploit reports, we don't necessarily automatically prioritize them. So the conversation that was spawned was, okay, well, there are going to be exploits, right? Every game has a series of exploits for the entirety of its life, right? No game has no exploits. And so the question is more, how do you respond to it, right? And so historically, exploits have always taken a lower priority to ongoing development, right?

I'm going to jump in. You're tense-switching between past and present. You're talking about the past right now.

The past. In the past, exploits would be bugs like any other. Depending on the severity, sometimes they got escalated. So now the conversation is about when we do get an exploit report, how do we deal with it? How do we escalate it? How do we respond to it? And so for the current ongoing exploits that we know about that have a damaging effect on the economy, currently we're dealing with them the same way we've dealt with the other hero strike teams. And so we're looking at each one of them and confirming the fixes, right? Because sometimes you fix an exploit, there's a second vector right away. So those are complicated fixes sometimes. So we're dealing with these things right away. But the big thing that this also puts in light is that even a minor exploit at the moment has a very large effect on the economy, because there are many limits that are not in place. And so at the moment, we're also looking at overall economy design and limits around selling, inventory capacity, exchange limits, ongoing active tracking of player trades and/or large purchases, things like that. Now, we want to make clear that we want the economy to be fun and movable, but we also need some protectionism behind it. And so that's what we're looking at at the moment. Now, I don't have all the solutions; I didn't write them out or show them. But this is the spirit that we're in at the moment on these economy exploits.

We can't tell you how we're going to fix it. We can't tell people what we're doing, because knowledge is power. If they know what we're doing, then they can run with it.

Yeah, well, every time it touches security, anti-cheat, economy, exploits, it falls into that area where we can't be as transparent as we'd like to be. And you're going to miss things. That's the main thing.

Yes, the Battlecruiser is coming. Yes. It's from a tried and true manufacturer, not one of these new hotness manufacturers, one of the older manufacturers of the verse. And I did say this last time, so this is not new information; the manufacturer thing is new information. But our big giant military combat-themed event that we do every year around May is probably a pretty good time to expect it. And as we said before, it is our intention to make it the last concept we do. We made it through 2025 without a single concept promotion. We do not have a single concept promotion scheduled for 2026 other than this Battlecruiser. We don't have a single concept promotion scheduled for 2027. This will be the last one. It's an old Kickstarter thing. And so, yeah, it's happening. We're going forward. I'm not going to tell you anything more about it now.

Is it big?

It's very big. It's very, very, very big. That's all I'm going to say.

So, okay. We're not planning a wipe. So we're looking at targeted actions, right? But we're not looking at a wipe for the moment. And so we want to keep on rolling. First of all, there's some of the work we've discussed; obviously, I can't share the details of what we're doing, but that needs to be completed. So for now, we're not intending a full blanket wipe at all.

This goes back to what we were saying before about the biggest quality of life. All this work going into long-term persistence and item recovery V1 and stuff, it's about the freight elevator. It's about making sure you keep your stuff. We've got tools. We've got logs, a lot of logs. We've got a lot of information. So it is our intention to do a targeted correction to those areas that need it and preserve as much of the gotten gains of the everyday Star Citizen as possible.

Exactly.

So no blanket wipe.

That's right.

One thing we didn't talk about in detail that I could give background info on is Genesis and Nyx 1. We're obviously working on this. That's no surprise to anyone. But the one thing that I'm excited about is that we've kind of conjoined development on three separate things in order to ship the best Nyx experience that we could offer. And so obviously Genesis is part of that, and the planet tech that's behind it. But also the Starchitect work. And so for those who don't know, Starchitect is a way for us to be smarter about building planets and the human populations that are on them. So settlements, buildings, distro centers, LZs, name it, right? So historically, we've placed that by hand. And so Starchitect is a way for us to give designers control over the planetary scale of how these are distributed. And it's a fairly fundamental change to how the game is made. And the third one is what we call population control slash population manager. So currently you have AIs in the game that are sometimes hand-placed, sometimes dynamically spawned. If you want to trigger me in a meeting, just tell me there's another overspawn issue. That's my biggest pet peeve. But anyway, so population management and control is a third component of this. So I'm excited about this because, as we're working towards Nyx 1, we're aligning all those three things into one strike team to deliver that together. I'm excited about that because those are three major development pieces that Star Citizen needs to scale, that we're bringing in together. So for pop control, instead of having all these hand-placed or dynamically spawned AIs in key areas, that's a system that will basically manage the server capacity of AI agents to be able to distribute them at the right place, but also spawn the right AIs for the right jobs, manage the priority of these spawn requests, all that stuff. And so it's a much more scalable system that will really build up a denser universe than we've had before. So I'm excited about the fact that those three projects are part of the same kind of drive at the moment. That's the first thing that you guys don't know about that we're going to bring together.

The second one, I mean, there are some hints of this in the game already. I know some of the techies look into the game client, try to find some stuff. I'm not going to go into more details about this, but we talked about sim rigs, about how the experience in the sim rig is. So VR is a great thing if you have a sim rig, right? Obviously, having the headset on is such a denser experience. We're also working on improving our peripheral support, so being able to feed information, non-damaging information, to peripheral manufacturers, to enable them to make custom Star Citizen experiences for the sim rigs. And we're currently in the process of looking at motion and motion platform support for the game. And so I think that's something we haven't talked about specifically, but I'm mega excited about it. Opening up basically the motion systems to be able to leverage that on the key elements. I think that's something that I'm super excited about, because that's just another level.

Oh, yeah. Well, so we talked about spawn in hangar, right? And so to build spawn in hangar, we had to build a new workflow, right? To be able to determine: can we spawn you there? Is there a requirement for you spawning there? So the requirement in the case of spawn in hangar is, is your hangar spawned, right? That's also extended to ships, right? But what we're trying to achieve, and I'm not promising this anywhere, is spawn in place. And so we're trying to extend that workflow for spawn in place so that you just log in to the game and you spawn where you were. And so that's something that we're passionate about and we're trying to get in there.

Log in, log out anywhere. Not you have a bed in a ship, you don't have a bed in a ship. Just wherever you are, get out, get back in, come back right there.

Surface of a planet, spawn in place, as long as you can still spawn there. There's going to be rules and limitations, but we're looking into that. That is also a big change for the game. That's a huge, huge change. I'm happy you raised that up. I was going to forget about it.