Mission bugs. We went through a refactor with 4.0 that reduced the mission options, hopefully temporarily, but we're still seeing a lot of the same issues that we saw before: arriving at a location and having no AI spawn, mission objectives failing to register, and cargo disappearing upon completion. The Fight for Pyro event going on right now is particularly affected, with many players unable to complete it or various aspects of it due to bugs. Save Stanton Chapter 1 was like walking through a minefield trying to figure out which parts worked and which didn't, and 4.0.2 has more mission content. Talk to me about missions, please.

So let's start at the beginning, right? What did we do in 4.0 for missions, right? So the way missions worked previously is that we had one server with all the entities, all the 100 players playing on it. When you played missions, there was an invisible entity created on the server somewhere, the location doesn't matter, that would manage that mission. And the way the missions work, if you can picture it in your mind, is that there's a mission management module, and then when you reach certain locations, when you stream in that location, a mission module at that location is going to actually kick in and has its own logic. If you're picking up a box, for example, let's say a box delivery mission, you get to that location, there's a mission module that pops up. It does the pickup logic. When you pick it up, it's like, oh, you need to go to this other one. Then there's another mission module at that location. Now, that's the way. And then if I add global events on top of that, there's a global events manager on top of that that was like a global thing on the server. Now, I've said global multiple times here. Every single time I said global is not compatible with server meshing, because we don't have a global entity setup, right? And so what needed to happen is a fairly large engineering task. I hate that we just said refactor, that we branded this as a refactor, because it's really a new core mission system behind the scenes, which is completely outside of the game servers and does the orchestration of what a mission is, right? And the global flow of a mission. Hey, you have something to complete. There are phases, objectives, there's state tracking, there's requirements and rewards, right? And so the mission system is what we call it. There's no longer a mission entity that's held on the server that just manages the whole thing. They all communicate to the mission system, that then takes the logic of the mission forward. Even though all these mission modules, written by the Kid Rock of missions, can do all kinds of fun things at each of the different locations. So the fundamental work was to make sure that the mission system was functional in server meshing. That was really the part of the gameplay element that was completely incompatible with server meshing. Another piece that we needed to solve in the build for 4.0, and as part of the mission system, is how markers work. And so markers are always a big issue. They've always been a big issue in Star Citizen since the very beginning. And with server meshing, these became even more problematic. So let me state the problem. You're on a Pyro game server and I'm on a Stanton game server, but I add you to my party. Now I want a party marker on you. My game server doesn't even have your star system loaded. It doesn't even know what's going on. And so for that, we needed a piece of technology that would allow the streaming system to stream your entity marker on my server so I could actually see your position changing. And so we've built all of this in place. But that's a fundamental change to how markers work. Now I'm going to dive into why we have that many bugs behind it.

It's almost like we need a replication layer for the mission system itself.

Almost, for things that are tracking objectives across systems, things like that. The way we call those things, the markers are independently streamable entities. Which basically allows us to have a marker on an entity that's anywhere in the server mesh. Now that system works, right? It's in place. It's been fairly reliable, but that touches on all the markers in the game. And so a lot of issues came up for that. One of the things that we have not tackled with the refactor is how missions are built. And to Elliott's credit, I think that...

We're using Elliott's name. There's James.

There's Europe, Nick, all these guys. So the credit to all these guys, right? We have not provided this team with the right tools to build compelling missions. They are dealing with an archaic scripting system that dates back to a previous era, that we are just about to finish modernizing by replacing, to give these guys modern tools and modern approaches. And so going back to markers, the markers are completely managed by game designers, and set and removed and displaced and whatever. And that makes for very complicated systems and logic that's not very robust. And so that's why, even with a robust marker system, because the markers are managed a bit ad hoc in mission scripts, it makes it really complicated to follow. I remember distinctly when we did the golden ticket event, which, that was the whole mission. There's a marker on the ticket, right? Well now, oh, the holder puts the ticket on his core armor. Now am I tracking the core armor? How does that work? The mission logic had to manage all these cases. Now we've kind of finished the foundation for making the mission system function in server meshing, and we're going to obviously keep iterating on making it robust in this setting, and fixing the missions to make sure that they also leverage the system properly. Bringing back the missions that are missing, but also improving the ones that are there so that they're even more robust. We have started the engineering work with the new StarScript foundation to rethink how missions are made from the get-go, to give Elliott, Nick, James, and all these mission designers the right tools so that they're not bogged down with details. If you saw the way they make missions now, it's involved. We want to make sure that these guys focus on the flow and not on the functionality they have to build, so that programmers can support that content. When we were talking about this change of focus, we're saying, oh, we're going to deprioritize features. We're also going to prioritize features for content as well, so that they can make content that's fun and reliable, so that missions that have been notoriously problematic, or events that have been notoriously problematic, become fun and reliable. And that's what we really want to do for the mission part.