Search thousands of answers Star Citizen developers gave in official shows, streams and posts.

For me, there's three main ways that we're tackling this. Number one, root cause analysis. What is that? So when you're faced with a bug, you can diagnose it sort of surface level, find out what's going wrong and fix it. But unless you follow that through and you go down the rabbit hole and find out what the ultimate root cause of what is essentially a symptom is, there's a very good chance that that is going to come back. So some good examples would be freight elevators, hangars, ASOP, ATC. Freight elevators especially, we've had a decent amount of time of people on our teams really digging into this at a core level, and hopefully people in the community are starting to see the improvements from that.

I mean, that's the thing: root cause analysis changes how we assign our resources when they're debugging things, so that they stay longer on the issue. They go a lot deeper and they document the process before taking action. Then we can identify in that process regressions that have caused the problems to begin with. And then we can also build a comprehensive fix plan, which then feeds into the second point.

So the second point then was expanding our test plan. And that's the thing that you've worked quite a lot on.

Yeah, so basically this is the idea of going from a given change to a larger test plan for regressions.

And what is a test plan?

Well, it's basically a list of steps, a matrix of steps or tests that QA needs to perform, which are much larger now with these expanded test plans.

To validate the fix or to validate the change.

Validate the fix in multiple configurations. We typically used to do these tests, but deferred. Now we're trying to do them pre-submit. And so what that means is that we're doing multiplayer testing with more players pre-submit. We're doing server recovery testing pre-submit. We're covering the happy and the destructive path for each feature pre-submit. We used to do that post-submit.

And that leads into the third point that we mentioned, which is just massively scaling up our suite of tools and frameworks and functionalities for validation. So whether that's in content creation tools or scaling up our use of our automated testing framework.

It's about expanding this testing so that we can simulate live environments basically as much as we can. And so validating the content allows us to make sure that our content and code that are linked actually work properly before submit. But then after that, it's about validating that when you put a lot of players on it, it actually functions the way you would expect it to function.

And that's ultimately what this question is kind of speaking to. It's like feature roulette. You don't want to be rolling a dice.

I agree, 100%.

And I think all of that combined can really give us the confidence that this approach is going to work, and the stability and the robustness of our game, its features, its systems, its content, the waterline of that is just going to continue to rise.

Well, I can speak to that. Star Citizen currently uses a majority of Building Blocks, actually. There are major elements that we still need to be able to completely remove Scaleform from the game. There's still some legacy elements tied to the visor, which need to be ported over and transformed into Building Blocks. And there's two major applications that are left: the Comlink app, and the next one is the VMA, which is the vehicle manager, which is being replaced by the vehicle loadout system. So both of these are actively being worked on to replace, and this will allow us to completely remove Scaleform from the game. Removing one of the render passes on the UI on the visor will really help performance. And more importantly, it standardizes our UI framework in one, which helps the UI team go a bit faster in some elements. And so out of this, currently Star Citizen still uses Scaleform, even in the Building Blocks elements, for font rendering, but that's been completely replaced and will roll out to Star Citizen at some point.

So that actually brings me into my first point, which is fidelity. In Star Citizen, it's all about fidelity. We want everything to be immersive and keep you there. And two players performing together is always quite challenging. The takedown becomes a little bit easier because it's a... less peaceful.

Well, it always has one final destination.

Exactly. And body carry or body dragging tends to be more, you know, you're already out. One of the persons is in a position where we know kind of what they're going to be doing. We're obviously two players goofing around doing all these things and one is trying to give something to another. But I think the other point is obviously the security of it: if I hand something over, if I want Benoit to have it, I don't want Carl to come running in and grabbing it from me. Or a system like that opening up an avenue for people to take things unfairly from other players. Those are the main considerations, I would say: the safety and security of them, and knowing that you're not going to lose your stuff.

So I'd like to bring it back to the question: why don't we already have it? Well, it's technically possible. There's a bunch of challenges to resolve, like we've just talked about, but ultimately it's a design question. It's a prioritization question. Do we want to do this over doing something else? Do we want this in the game? Those are questions for our creative director, game director. And it'll be in their minds, I'm certain. And then when it comes up, we'll have solutions ready if we want to do it.

Yes, social tools are progressing. While it's not going as fast as we would like, because we did have to divert resources to the efforts we talked about at the beginning of the show, there's still a lot of work actually being done on social tools in general. So back-end work has been moving along quite a bit, because there's a lot of back-end changes to be able to provide that. Social tools are inherently real time, and so there's a lot of communication messages, asynchronous messages that need to go out, and so that back end needs to support that really well. That's actually on track and is going really well. What we are still planning to do here, and where we're slowed down, is implementation in the game itself. Our first drop for social tools that we have planned is a revamp of the chat systems, which includes regional chat or location-based chat, meaning that we split the main chat into multiple depending on the location that you are at. This is in preparation for larger player count support per shard, so that we don't have a massive chat at the top of the list there. More presence, rich presence updates, the chat widget, a complete revamp of the chat widget, and a new application called the Social App that replaces the Comlink app, which, as we discussed, is an old Scaleform element that we want to get rid of.

I guess that's the other big part of this. There's a lot of UI work involved in screens like this.

Absolutely. The chat widget is a very complicated piece of UI. Even though it's simple in its appearance, the functionality behind it is very in-depth. We want you to be able to have different channels that you can manage, manage tabs the way you want, maybe have a bit more flexibility on where the UI is positioned, how it works, can you expand it? So we have a lot of functionality for that that's being done. The design is completed, implementation on the game side is about to start, UI is already on it, so it's progressing really well. That said, there are still features being worked on in the current version of the game. So there are improvements to VoIP and FoIP that are coming into every patch.

What are VoIP and FoIP, for those who don't know?

Voice over IP and face over IP. It's basically being able to transmit your voice over the network to other players.

And your face.

And your face, in our case, yes. So far, I think since 4.8, 4.9 and 4.10, there have been incremental changes to the VoIP back end, which transmits all of this. In 4.10 too, actually, there are changes to the synchronization code that synchronizes the face across the network, which is a lot more robust. And so unfortunately, for this feature, one of the big things we think is holding it up is supporting the UI in the game itself. Receiving calls right now is a bit hard to find; you don't get proper notifications for it. And so obviously, to be able to really feel these improvements, you need the UI changes. It's actually moving forward and we're trying to bring any improvements that we have into the game right now.

The question was, is the development of social tools progressing? The answer is yes, very much. It's coming to a start as a new year.

So I did inquire about this, because I did not know the answer to that. So I went to the source. When we implemented LAMP, it was a limited feature that was meant to be only on fighter ships initially. And there was a reason for that. It's because in order to get the feature in the game in a timely fashion, we knew that we could get this working with the exterior canopies really easily. For example, you take a Gladius canopy; the canopy is part of the exterior of the ship. And the way LAMP actually works is there's a submaterial on the inside of the canopy itself, so that if you look at it from that direction and LAMP is turned on, then the visibility is changed and the effects come into play. Now, the problem is for static canopies, which are part of the structure of the ship, there is a linkage issue at the moment that prevents us from properly activating or finding that submaterial from code. Now, it's solvable and we will solve it. But we're trying to find a way to do that without having to reauthor 100-plus ships to be able to activate LAMP. And so this is what's keeping us from doing it now. It's a priority call that we need to make to get it in there. We do want to do it. We do want to support it. And so we need to find a way to do it without having to reauthor all the materials in the static pieces. And so most likely, we already have all the theories set up. We just need the work to be planned.

I actually checked with John, because again, there could be a creative consideration here. Do you want to have LAMP on every vehicle? Should it be only on certain archetypes? He said, nope, we want it on every vehicle, including ground vehicles. So John loves LAMP.

Oh yeah, absolutely. What I want to do before we bring ground vehicles up from the freight elevator is I want to decouple from ATC. I shouldn't need permission from the air traffic controller to bring my ground vehicle up. I'm in my hangar. I'm in my own little safe space. I can do what I want.

I mean, it's air traffic control. What do they care about?

They should care about what happens when I leave the hangar, not what I do in the hangar. So I definitely want to do that. And then the other part is the insurance handling flow. Ground vehicles are vehicles, and vehicles have a slightly different insurance flow than other items. So that means we need to make sure that that insurance flow is available to the freight elevator, for freight to be able to do the same thing. I wouldn't want to go to the ASOP terminal to deal with insurance on my vehicle, to then go to a different terminal to bring it back up. So those are the two technical hurdles for me that I would like to see solved; I think that will make it a more robust feature.

Yeah, this ties very directly to our first question. Ground vehicles coming up from freight elevators, I think that's appeared in our internal roadmap, but we're not going to do that until we feel comfortable that we have really, is "robustified" a word? It is now. Robustified freight elevators. We don't want to build a feature on top of something that has reliability issues. And we don't want to exacerbate that by looping it into more gameplay loops. So we want to instead invest the time fixing up freight elevators like we just described before, and then layer on top.

I think also the point about decoupling from ATC is an important point. The air traffic controller in the game has evolved into also the manager of your insurance claims or the destroyed state of ships or things like that. And we don't want to keep that logic in this area. We want to be able to use that elsewhere properly. And so we just don't want to build on top of the current ATC to support the freight elevator with ground vehicles. We really want to decouple that. So Jens, you mentioned something just earlier about how insurance is different for ground vehicles. What did you mean by that, really?

It's just purely a technical aspect. So it's not that vehicles have a special type of insurance. It's for us on the engineering side: the flow itself is different and we just need to move it out so it becomes available for the freight elevator kiosk.

And other kiosks.

Yeah, exactly.

Well, when we reviewed the questions, we saw a lot of questions related to desync. Recently, we have done some testing on our Tech Preview for some desync changes. This is kind of a result of the work that we've been doing in writing the desync post that I got coerced into writing. And so that is still ongoing. I know this is the underlying question. There were also some notes about this. And so we are about done with writing this desync post, which has a lot of information trying to explain where desync comes from. It's big. It's 45 pages.

It's big, but it's good. It's very good. A lot of detail from a lot of different angles.

And so one of the things with this is that we didn't want to just come out with some additional post or information without some level of action as well. And so we've been looking at improving some of the netsync elements. And so what we've been testing recently was a targeted change to how we simulate rigid body entities with the physics engine.

That went on Tech Preview. It was very well received.

Well, as a first drop, it was great. That's why we wanted to move it to Tech Preview rapidly, because we wanted to gauge the actual impact of this change, which seems to be positive. Now, there's a couple of fallouts from it that we're going to fix, but that's an example of how we start to look at more of the desync from different angles. Obviously, our post will go into details about all the sources. Because unfortunately, it's a bit like the flu: there's a symptom and then there's the cause. And so there's many causes for desync.

It's also an umbrella term, right?

Yes, correct. And so we'll talk about that in the deeper post. Plus, I'm hoping that some of these changes are going to yield good results, which I think this first Tech Preview at least showed us some promise of. We're going to do more of those targeted changes so that we can measure that and see the impact on players. That's really what we wanted to navigate: when we see improvements locally, we see improvements with our development setup, internal testing, there's nothing like bringing it to you guys to see if there is an actual effect when you're trying to do something with it, whether it's a Jenga tower or, in this case, since we're doing rigid bodies, that was really the test. And so that change was really targeted at how we synchronize these objects, and especially revisiting a decade-old system that's been in the engine forever. And so I'm happy with the first pass result. I think this is really promising. And then if that scheme does hold up, then we're going to roll it out to more elements in the game. Currently, for example, ships and vehicles are not targeted by that. There's also a bunch of different types of entities that are not targeted by that. So there's a lot more things to roll out there. But I think the approach is looking sound, so I'm happy about it. That's what's coming down the pipe: I think the desync post will answer a lot of questions, I'm hoping. And then we're going to do more Tech Previews for these tech changes.

I mean, it's really cool to see these changes coming in. It's really exciting. I think it's the start of some really, really great changes. So the team's done awesome on that.

It's ultimately a design question. There's a big design and creative element to this as a feature. But we did dig out some interesting information to talk about from the tech perspective.

I asked Benoit the question: can we do it, technically? If someone came to us and said this needs to happen, could we do this?

The answer is yes, we can do it. And I can add some color to some of the elements here. So in 4.8, there was a major change to the game, the back end specifically, where we introduced a new entitlement system. Now, for those who don't know, the entitlement system tracks what you own. This used to only track your actual platform entitlements, which are either elements you've received through Subscriber flair or actual real-money purchases or things like that. Now, since 4.8, the system tracks everything that you own, whether you bought it in an in-game shop or through any other acquisition method except stealing. That's the only one that's not covered by this.

You're essentially the legal owner of this. You've been identified as having legal rights to this item. So when we go back to the give, when you give it to another player, you would legally give them the rights. So we'd have to tell the entitlement service about that.

Correct. And the entitlement system also tracks your insurance loadouts. And so through this, the ability to sell a deed like this would involve the entitlement system, and that system can do it. Obviously, we already have wallets for transactions and other things like that. Maybe some color commentary here: there's also active work in consolidating a lot of the economy-adjacent systems together. So we have the wallet system, which is called the ledger service, that actually drives all of your monetary currencies. And there's all different systems that attach to that. So we're bringing all those into a single economy system, which will include, at some point, marketplace features, reactive scenario features and other elements of the economy. If we did build a system where you could sell an existing ship, then those systems would be involved in making the transaction. We already have the ability to do that right now.

Yeah, so deleting a ship could actually be a zero-cost transaction and maybe even be recoverable in that case, in case you've done it in a moment of weakness.

Deleter's remorse.

Yeah, exactly. And now the advantage of the new system too is that it persists cross-patch. So your entitlements are completely persistent cross-patch. We don't recover them from the previous patch. They are just there. And so that's why we no longer have issues like, oh, I lost my ships between patches, or things like that. Those are completely persisted by the entitlement system now.

So Server Meshing has been amazing. I think it's definitely delivered on what we needed from the technology. And I think it has lifted server frame rate, which I would hope means people in general have a better experience. But there's still a lot more we want to do to get server frame rate up, which will help NPCs, because in general NPCs can be perceived as slow to react, because they need a little bit of time to cook. They need a few frames from the server to get all the decisions made. So if you are unfortunately on a server that isn't performing at the rate we want, then it could be a bit slower.

There's also a condition we know of that we need to solve, which is related to large areas streaming in at once, which can cause server stalls, like we've seen with Siege, and that's something that we're tracing. Solutions are on the way to resolve that. It's a lot of deep engine work here, because we need to parallelize a phase of the initialization of entities.

We should be cautious of attributing every AI issue to server performance. Sometimes we do just see genuine issues or glitches or bugs and things like that. We just work through them, we fix them. There's a bunch of good work been done recently, right?

Well, that's what I was going to point out: we've been developing upgraded behaviors for our AI. Obviously, we've been tuning this work in Squadron 42. At this point, that work is completely signed off, and we're very happy with those new behaviors. This touches on many elements and many systems, which is why we can't bring it back right away. But we're talking about balancing the perception system and vision system so that the AIs, the NPCs, are a lot smarter about picking their targets. The ticket system tuning: this is something that in Siege of Orison we've actually seen, because this is one of the instances or areas that we've had the most active AIs in. And you could see that there are load balancing systems in place when many AIs are in the same area, where the server is going to give a certain amount of budget to each AI. And that's tuned for the current game. Siege of Orison had 10 times more AIs in general. So you could see how the load balancing wasn't perfect. This we're tuning on the SC side, but there's been massive work on this. We have a lot of changes related to how the tactical queries actually operate, which is how AIs actually plan their work. So there's quite a bit of work that has been done and completed there that really changes the behaviors in general. SC still uses an older set of roles for AIs in general: pusher, defender and strafer are the major three archetypes that we use on SC. We have a lot more roles now that are available in this new version of the AI subsystems that we need to bring back, including things like using cover, relocating between cover properly.

And so that's better tuned for a large population of NPCs. There's more roles available to pick. So if there's only five pushers, then obviously if you have a population of 70 trying to engage, then you need a few more roles.

Much richer behaviors will also allow things like not having to put as many AI agents in one area, because they can all be more effective.

It's like a double dip of improvement as well. The more roles you have, the more varied those roles will be, the less intense some of them may be in terms of performance requirements and things like that, which helps with performance, obviously. And then, like you said, greater variety of AI behaviors and archetypes means maybe a need for fewer AI, which again will help with performance.

Also potentially easier for the client to predict what an AI is going to do when they know what the role is, if the role is more defined.

So I did ask the team about this to see what the current plans are. And yes, there's a lot of planned and actually active work being done on ground vehicles in general. So to give a bit of context, there are currently three, let's call them setup rigs, for ground vehicles in the game. There's the really old Crytek vehicle system rig setup. Obviously, it's been tweaked a little bit, but that was the original one. I think the Mule is using this, for example. It's the most simple setup of all. The second one is a hybrid version, so the tanks, like the Nova, take this old physics rig but then add a little bit of control over it. And then the final one is a fully simulated version of it, which all the other vehicles are using currently. So we do have plans to unify this so that everybody uses the best version. That's the first stage. And then we want to evolve that quite a bit to give it better handling. So like tuning up the physics for rotational clamping, collision damping, things to make the experience smoother in general for gameplay inside ground vehicles when they collide with terrain, especially with V5 coming out, where this will actually help.

Yeah, Planet Tech V5 coming out in Genesis. Greater fidelity of physics proxy generation for terrain, things like that. So that is only going to be an improvement.

So that even helps with the old rigs. So you get a bit of a better feel on the ground. But there's a lot of physics upgrades that are needed for ground vehicles, and we are planning to do them. We're talking about modeling the drivetrain, braking model, engine and suspensions. We already have suspensions, but we want to improve that quite a bit. And so from a systems and design point of view, yes, the plan is to unify all ground vehicles under one setup and then improve that setup across the game.

I mean, I worked in racing games for 13 years. I know that this stuff is challenging, but we do have an excellent team, a comparable size team and composition makeup to what I would have had in something where the entire game is about racing and about driving. So with that unification and those good people, I think we'll be able to get where we need to go.

Yes. So the first good news is that the new flight model is fully complete, working in Squadron 42. There is no master modes. All the functionality you have at your fingertips is purely based on your engineering distribution. So if you want to have weapons powered at the same time as your quantum drive powered at the same time as radar, it's purely up to you. So you can manipulate your power pips to dictate how you want to fly. We also have the quantum boost functionality in quantum travel. So now there is no SCM and NAV. You just fly in the direction you want. Go where you want. You go max speed or not max speed. You can quantum boost at any moment. Quantum boost is, I have to say, incredible to use. You can use it in atmosphere. You can use it in space. It takes a short amount of time to charge up and go. When you are going, you're in this kind of quantum bubble light. You can actually steer and maneuver. You're obviously not going as fast as quantum travel at all, but it's giving you a much faster speed around and navigation. So if you're coming out of a landing zone and wanting to get up to an LEO station, you can trigger quantum boost and get there.

And it's freeform, right? You don't pick a destination?

No, it's freeform. So you can go into the black of space, quantum boost around a planet. And then obviously then we have quantum travel. So the new flight model, obviously it's been directed by Chris alongside myself. We're really happy with what's there in Squadron. We will be obviously then getting lots of feedback, which I think we've already had a few tests with players from Star Citizen. The work ahead of us is now transposing that flight model into Star Citizen with all of the necessary details and intricacies that Star Citizen brings, because obviously they're not a one-to-one gameplay experience. We know that.

Making sure it works in a networked environment as well. Make sure we don't introduce any new desyncs.

Yes, 100%. Things like bringing it over, making sure it works in a multiplayer environment, making sure it works in PvP, making sure it works in PvE, making sure it works for all careers: miners, bounty hunters, haulers. So we've spent a long time making sure that it is fun to use, it's intuitive to use, and ultimately has a lot of depth for the players who want to go in and manipulate how they want to set up their ship. They can do that. I think we're in a really good place. We'll still continue to get lots of feedback as we transpose into Star Citizen. But from a Squadron perspective, that flight model, which is what we want to become the foundation, is functionally complete.

The core ethos of what we call Mission 2.0 is essentially enabling our designers, or anyone in the company, to be able to create meaningful, scalable and robust content. So what do we mean by that? Let's talk about the intent first, as that pretty much solidifies the direction we want to take it to. So as Rich said in the 1.0 conversation, we're going to be having a main story, right? So the first part of that is our mission system will need to be able to create story scenarios, which influences NPCs or game world objects, animation, Track View events, dynamic events in the game world. So when we're telling story, that mission system can drive a lot of that. And currently, we don't have a lot of that functionality. The second major thing is we want to be able to do quest chains. So once you're progressing along that story, you want to be able to finish Story Mission 1, and then unlock Story Mission 2, etc. Again, functionality that we're missing currently right now.

And those quest chains retain or continue across logins.

We were going to get to that, but Rich, you're absolutely right. So jumping onto a little bit of the functionality outside of the intent, upgrading the capability of what we can do. Our first major one is obviously persistence between logins. Carl, you've picked up a mission. You log off for the night, the next day you still have that mission. You don't really care what had to happen on the back end for that mission to still be there in your contract manager the next day, but you want to log in the next day and see it there, ready to go, right? Also, other types of functionality we need is a deeper ability to specify mission sharing and rewards. So right now, as we've seen on a variety of our missions, participation or rewards being split equally are some issues that we wish we had a few more parameters on. So if you want to share a mission with someone and they want to receive some rewards, they have to do a certain amount of participation.

I think it's also really key to understand there that we want to encourage people to be able to play together. They shouldn't have to play together, but if they want to play together, we don't want to penalize them. So Mission 2.0 will give us the ability to allow players to come together without having to vie for individual rewards. They should be rewarded for playing together.

I mean, you've talked a lot about the player impact on Mission 2.0, but for me, it's all about the way that our content creation teams are working to create those missions, right? Our mission tools suite at the moment is very granular and detailed. Mission designers are essentially programming in our mission description tooling. And so they have to worry about way too many error handling cases, initialization, streaming race conditions and things like that. They have to uniquely and very specifically find all of the elements in the world that they need to work with for their mission. And Mission 2.0 is sending things to be much more building-block oriented and make it more declarative. The mission designer will declare what conditions and what environment and what objects they need to be able to work with, and then the mission system provides them with that. They don't have to go and find them and serialize them and worry about their loading and initialization order and things like that. So yeah, it's a big tech...

For everybody at home, that means those missions will be more robust, have less bugs, easier to find out.

There's a question later on that discusses that, so we'll talk about that in a bit.

Well, it means basically if you're a designer, you can focus on designing the content and not...

The gnarly edge case stuff.

Also, some other improvements outside of the way we're building is the presentation of that information. So as we work towards 1.0 and we're scaling the type of mission content, we need to be cleaner in terms of how we're presenting those contracts to the player. The ability to search or the ability to filter, things like that, will be very valuable. Also, the way you accept those missions. Right now, you open up the contract manager, you pick a contract and you're good to go. On the story missions, they'll call you up, they'll enroll you into that mission.

There's also a couple of things there. We want to be able to tell people what tools they need to take on that mission, whether they need a multi-tool or whether they need a specific ship. Also rewards, outlining what rewards they'll get. So a lot of functionality, both from the back-end side for developers to be able to make more robust missions and more complicated missions, all the way to the front end, from the players experiencing that mission, both from a point of view of as soon as they pick up the contract versus playing through the mission and obviously then the rewards at the end. So yeah, there's a lot coming, I think, with Mission 2.0, which is going to be good.

So in a nutshell, Mission 2.0 is essentially an umbrella term we use that affects everything from where we're heading to the way we're building to almost how the engine works. So it's a big initiative.

So essentially engineering is something that we're always looking at and making adjustments to. I'd say the current balance isn't necessarily where we'd want it to be, which is why we're continuing to iterate on it.

The standpoint right now from an engineering perspective, I think, is to let everybody know that it's not where we want it to be. It's not the finished product. The intention with engineering, like we've always wanted it to be, is for it to extend the life of your ship. And with that comes the opportunity for players to engage in further activities to be able to do that. I think right now the balance of fire is probably a bit underwhelming with what we want it to be. The problem that we have trying to achieve the true full scope of engineering is that there are other features around it that need to come into play. But I think that we will definitely be balancing engineering over the next year to make sure that we are getting that tuning right on the base functionality. And like I said, when the new flight model comes in, engineering will be the way that you manipulate and utilize your ship, both from a single-seater all the way up to a capital-class ship. So there's definitely things for us to do there. But at least that's the current standard. But I know that you wanted to take us through some of the future.

We can elaborate on a bit more. So let's talk about soft death a little bit. So when you're fighting specifically AI ships, the soft death tuning is also, I wouldn't consider, where we want it to be. And what I mean by that is right now, there's a high likelihood that they would just explode. So we want AI ships that you're fighting to explode if a component goes critical. But then you also don't want a ship to be dead in the water and the mission still requiring you to take it out. So we'll be adding a few more callbacks on a mission point to be able to understand certain scenarios where it will consider that ship no longer part of the mission requirement, which I think will help. Another part of that is once the ship is soft-deathed, we want to be incentivizing more dynamic content. And what I mean by that is cargo manifests right now are also built through the mission. So obviously that's not very scalable. It requires every mission to be prescribed explicitly in terms of the manifests, whereas really we want that on ship archetypes. So basically when you come across an AI ship in the wilderness, that will have its cargo manifest, and that means we can create more dynamic scenarios. We're also going to be looking at the bug on the MFD screen. So when you scan that ship, you'll get more of a comprehensive and legible readout, again, to further give you the information you need about whether you want to...

You want to be able to go into combat, fight an AI ship, and some of the ships might be worn and heavily worn, poor components, and then they blow up. But some ships should also, like you said, soft death, and then you should be able to use that as part of the reward for that mission and be able to go and salvage it, take its components. Does it have cargo on board? And obviously radar should be able to give you some of that information and be able to play the game. That's where we want it to be. We're not there yet, but I think that's still a good vision for us to work towards. The development needs to be faster. We need to get more iterations into the players' hands. I think nobody's happy with the pace of development that we want to push towards on these iterative features, and it's definitely something that we're going to be moving towards. And that's coming back to Mission 2.0. The reason why we're investing time into Mission 2.0 is to help make the development faster, so that we can focus the engineers not on helping the designers to fix mission bugs, but come and help us iterate on engineering. We're well aware that we want to be improving on that front, and it's something that we will do.

Ah, so storage and ships. So this is one of the ones where we talked about having it split into three sub-features. We have Starwear, suit lockers, and then there's...

FPS Armor 2.0.

Yeah, exactly. So it's FPS Armor 2.0. So we are working on all three of those things. We want them to come as a cohesive unit. So if I touch on FPS Armor 2.0, in a nutshell, that is the armor roles that I've talked about in the past. We still want to do that. We still want to have heavy armors be G resistance.

And for the system that brings all of this together, we actually did the pre-production of that earlier this year. I just didn't quite get to starting the work.

Yeah, so all of that work is all these little things. It's not this one Goliath feature. It's all these little things for Armor 2.0. So we are slowly chipping away and knocking each one of those down. And then obviously, how does that tie into suit lockers and Starwear? Well, Starwear is the ability to customize your character so that you're not having to wear just a single undersuit and then armor on top, and you're very limited. I've actually played a full version with Starwear. That's almost finished. I've had sunglasses under my helmet. I've been wearing boots on top of my... It was great. But how does suit lockers tie into that? Suit lockers is the way that you save that loadout. So then you can go into your ship and you can be like, this is my radiation package, this is my FPS package, this is my flight suit package. And that should just be a single interaction. You're going in, single interaction, you're now... I've got a different loadout than the loadout that I was in. That should be removing friction so that you can quickly switch between play styles. And obviously, we're working on all three of those. And the big thing with suit lockers, which everyone will obviously want to know, is that insurance, tier three insurance, which includes decorations, would also include weapon racks and suit lockers. So if you are setting up all of your ship and you're filling all of the lockers or the weapon racks or the food goop for your kitchen or your medical goop for your imprint or your medical bay, all of that will be covered under the decorations insurance. So you'll be able to pull it back and decorate your hub or your ship as you see fit, which... what was that guy's name?

So we saw an outstanding video internally. It was incredible. We watched it last week. So that was by John Claude Van Wick.

It was a great video, right? I mean, he had an Idris in the upper hangar. He set up all of the weapon displays and you could go in. That's what we want to see. We want people to be able to customize their ships. We want people to have a home away from home. That is the design. We are absolutely going to deliver that. We are working on those features and it will come.

Maelstrom, okay. So similar to the flight model, Maelstrom is technically complete within Squadron 42. All of the combat, all of the ships, all of our props in the environment are set up with Maelstrom. They all break apart. I mean, the Maelstrom on the ships is fantastic. The challenge ahead of us now is then transposing that into Star Citizen. Obviously Star Citizen is a lot broader, has a lot more, 200-plus ships in Star Citizen, a lot more scope. So obviously it will be the same system, but it will need to be network compliant. It will need to make sure that it's working in all the conditions that we need it from a gameplay perspective and a balance perspective. That will replace the current armor system wholesale. Damage is fully enabled with Maelstrom, so it takes the weight of the bullet, the projectile speed, the type of the bullet, whether it's an energy or ballistic. It calculates the kinetic force on impact. That is all working. All of the physics has been calculated. So that is fully complete in Squadron. Now it's about bringing it over to Star Citizen. And as Squadron moves towards its release, more and more resources, more and more gameplay features will come over. Similar to how we did a big push in 3.23, we brought those features over, we'll be bringing over another tranche of features, which is Flight Model and Maelstrom.

Maelstrom's going to be one of the earliest ones that we look to bring over, right? Because it's quite a chunky piece of tech, and it's going to need some integration with our network model.

I've seen it. I've played it. It is a very different experience based on the armor system currently. So that's exciting.

I won't go on too long about Maelstrom, but the biggest thing is just the feedback that you get when you're shooting a ship. It breaks up much more granularly. You get that feedback that you're actually making progress, that you're removing bits off it. You see bits of wing come off. You see bits of the ailerons come off. You get to see the visual progress.

It's that tangible feedback right from your cockpit, right? And that is game-changing.

Good ideas, great minds think alike. So the expectation with medical is that when you die, you will have multiple options for you to be able to choose from. So you should be able to have your main hospital location, depending on where you want to imprint. You should be able to in the future also have a location for your base. You should be able to have a ship location. So there's like three permanent locations that you'll be able to imprint. And on death, you will be able to choose which one you want to go to, if you've got a specific ship, if you've got a specific base or a specific location.

Or if you've been camped, you can go back to what you want.

You can choose. Then you should also have access to some transient locations. So for example, if you're in one of our large mission operations where you want to be, say, in a line of mine, or you want to be able to respawn at a location, you'll be able to log that imprint, and that will be a temporary imprint that you'll be able to switch back and forth, and vice versa. You'll be able to also have a temporary imprint on somebody else's ship. So you should have these options available to you, and you can choose which location you respawn. And obviously once we've done the Death of a Spaceman in terms of the DNA integrity that ties into your respawn mechanic, that will obviously have wider ramifications depending on where you actually respawn and the tier of the bed and the facilities. But that's what we want. That's been the decision. We've had that design and vision for a long time, and we still want to do that, and we will be bringing that to you in a future update.

It's a good question. I had the same question when I joined the company a few months ago.

Well, why don't you take this one, Carl?

Yeah, I think there's two parts to this question, or two parts to the answer to this question. The first part, and I think the most pertinent part, is what Benoit, our CTO, mentioned, which is a huge scale of volume of content and a huge level of combinatorial complexity of that content with different gameplay systems and features, paired with a lack of validation testing. He talked a lot about our lack of a robust suite of being able to test, validate, pre-submit the work that somebody's doing, working fine for the content and the feature that they're working on, but is not going to regress something that was made seven years ago or what have you, right? Or even seven weeks ago. But that's the thing, right? So once something is released, it goes into the pot of this huge volume of content that we have. And just the scale and combinatorial complexity of all of that integrating together means that we run a pretty high risk of a change not being compatible with something that was released a while ago or fairly recently.

So what are we doing to stop it?

So essentially what we need to do is leverage more automated testing and more tooling around, whether it's gameplay feature development or especially our content development tools, to basically be able to sweep through a suite of all of our content and do some basic regression testing on all of those systems.

The next bit, I'm assuming you're going to talk about the declarative model.

Yeah. The other thing is obviously this person was directly referencing missions. Missions specifically have an additional challenge, which is the complexity of the tooling that we have around our current Mission 1.0, let's say, means that the resulting mission flows and the logic setups and all the things that we just talked about, like finding all the entities, collecting them all together, dealing with streaming race conditions, having to put things into the mission logic to deal with things like server crash recovery and things like that, it results in a very brittle system.

I mean, a good example of this going wrong in some respects is Race for Stanton. What was interesting about that was, for some reason, the way that the mission system interacted with the back-end systems, it funneled everybody to this prologue mission or setup mission to one location. And nobody wanted that. It didn't happen in our own testing because we didn't have enough concurrency. And then when it goes live and the live environment is slightly different, it then funneled everyone, and it's like day one, oh. What? And it makes it poor for the player. It makes it a poor experience for us, because people have spent a long time trying to make the content and get it out live. So that's something that, none of these issues do we want. We want to be adding new content to the game, and every patch should make the game better than previously. And that's something that we're very well aware of and we want to improve on. And we have taken steps, like you said, in terms of refactoring some of these large systems, but we've also taken steps into highlighting these individual areas within the game or development in terms of buckets. So we've talked about the first hour for a new player. We've talked about quantum. We've talked about freight elevators, hangars, and taking those and really doubling down on making sure that they are robust within a short time frame. So yes, I think that is a great question. We're very well aware of the status of the game. Our community is very vocal and we are thankful for that. We want to say that we are taking that on board, and absolutely we will be improving on that going forward.

Isn't it fun when the community highlights something that we internally have had a lot of conversations about?

So essentially, yeah, that's a great question. It's a very pertinent question right now. So ultimately, we completely agree on this. We've been talking about it a lot with Rich internally. The ability to unload your hard-earned loot throughout the mission is something that we're looking into, whether that is item banks along the way at the various medical facilities throughout. Does that tie into my local inventory in Orison? I remember we were speaking with Jens about that. So the nuance about how that would work, we're still looking into, but it's something we'll be looking to add.

I was just going to say, because we have to basically reconcile that with the fact that Siege of Orison is instanced content, right? That's using new technology.

So you'd be communicating from your inventory in an instance to your inventory in your, if your home location was Orison.

Looting is also, just in general, we want looting to be less friction. So we want people, if they go in and spend their time working on a specific operation or specific series of missions, we want people to be able to be rewarded, and it's not great when you do all the effort and then you don't get the reward. So yes, we definitely will be looking into that. And in some respects... I don't think we had a crafting question, did we?

Not yet.

Okay, so a tidbit for crafting. We're going off piste. Yes, for crafting and refinery, this also comes with respecting people's time. We want to make sure that if you are searching and you spend a period of time finding ore of a specific quality, you should, at the end of that period of time, feel like you've made progress to what you want to do. And I know at the moment it's a bit too random. And we want people to be able to take some of those ores and then put them together and then obviously refine them to higher quality ores. So that is something that we will be touching on. And I think it all ties into this same overarching message when it comes to the time that you put in the game. You should be rewarded for that time, whether that is through credits, whether that's through reputation, whether that's through gaining access to a new ship, or whether that's for crafting materials. We want you to be utilizing your time and being rewarded. You've moved forwards during that play session. I don't want to be in a situation, and I've used this example many times before, I used to do end-game raiding when WoW first came out. And I used to do the roll call for all the mages. And I would have people be like, I can't afford to come on the raid because I can't afford the repair costs for my gear. And that sucked. So I don't want that. I know Chris doesn't want that. So we're not going to make it like that. So we want to make sure that if you put in the time, you should be rewarded for that. And that is part of that bigger vision.

So that's a great question. So absolutely, that's part of our plans. The ability to log out and log back in in place is something that you've talked about before, Rich. Chris has talked about it. It's definitely in the plan. How that works if we're in a party and how that works if we're in a ship? Well, I think...

An easier way to describe it, because I think there's lots of different permutations that you could be in: okay, what happens if I'm on a different shard or I'm on a different server, or I'm in space or I'm not in space and my ship's docked. Ultimately, the intention that we want to get across is if you log off in whatever scenario that you're in and then you log back on, we want to do everything possible to try and put you back in that same position.

You want to try and go as far as you can.

Well, for now we're taking the old shuttle that always has been here, and we're going to go to the transition platform, as at least we've been calling it, where we can call ourselves an instance and get involved, get in the mix. So that's step number one. That's what this mission is going to teach us right now, how to do it. And then after that, anyone who wants to play, they can just rock up to these elevators and get themselves an instance.

And I hope the players aren't expecting a reward for this mission. There is no reward. It says zero.

So yeah, what we are now is the transit platform. This is new compared to the original Siege. We can already kind of see that some stuff has been going on and that Crusader is actually in distress. And then from here, we'll take an elevator and we will go into the instance. It's a new technology that we deployed that allows people to have a more curated experience within the universe, where you go in with your own group of four for this Siege of Orison experience, and then other players can't really obstruct your player experience, so we are able to provide the players with a lot more of a directed experience.

There definitely was a theme, sort of mixed between gameplay mechanic themes and also telling the story, I suppose, of the Ninetales attack on these platforms. Luke would probably be the best to talk about how he tackled that side of it art-wise.

Yeah, so the theme that we discussed with the creative director Ian, that we really wanted to bring home on this first island, is really this Normandy beach landing experience. You come out of the shoreline. You're there, explosions are happening. The fight is immediately intense. You're trying to push up. We're fighting uphill. We had the mortar section that we just went through. So it's really like, we're here, it's not a stealth approach. You're getting tossed into it straight away. And I think that really defines this first couple of areas. And then we'll see what the next area has entailed for us.

When you're designing encounters and missions, you always want to try for nice, what we call, peaks and troughs, where there's points of high intensity that then chill out. Because if it was constant high intensity, it gives you a different feeling and experience compared to ones where it's like, okay, now we can breathe, we can gather up, we can sort ourselves out.

So it was actually... I've seen a lot of discussion about it online, and I know everybody has their own opinions about it. I think there's drawbacks and benefits to doing it. Simply put, when we decided to remake Siege of Orison, within an instance, we wanted to see whether we could create a curated experience for four players. A linear mission flow that utilised not having any outside influence inside a mission, really for the first time, in Siege. We wanted to see if we could craft that in particular, and see whether we could pull it off: what we have, what we don't have, what we'd like in the future to perhaps make things like this, or things with a bigger party size.

And like I say, we could have made a bigger platform and increased the party size, tried to curate it for that many people. But we settled on four. We wanted to start with a group of four for this. I know it's not very similar to the old Siege.

I mean, the old Siege was completely unbalanced. We had no way of limiting it. So when we had built it originally, it was designed for 30 people. And then they found an issue where... Originally, we used to have two DGSs running on one server, and we found when we did Siege that they were fighting for resources. So instead, we were like, well, let's just have one DGS per Amazon server. So we did that. And then we were like, we can up the player count then. And then obviously that's when Siege came out, and we'd upped the player count to like 100 people. So it was instantly unbalanced on release. So it's nice to finally see it in a balanced form.