Now that we have some persistence in Habs, what can we look forward to seeing on the path to Full Persistence?

here are several types of persistence, and they're currently aiming to help Server-Side Object Container Streaming (SSOCS) with their development of persistence. We currently have Client-Side Object Container Streaming (CSOCS), where if a cup moves away from a ship, the cup streams out for the client which helps to improve the client's FPS, but is still on the Server. The next evolution of this tech is SSOCS, where if no-one's near the cup, the Server doesn't need to know about it (so the cup is streamed-out for the Server just as it was for the client, boosting the server's performance). The problem with SSOCS is that, if it's a ship that was damaged that's going to be streamed-out, it needs to be brought back to the Server with the same damage it had before, which is where the next evolution of persistence is (where things like damage states persist regardless of whether the entity is streamed-in or out). There are a lot of teams working on it, to get both the engine and persistence working, and to do that they will have to change how and when persistence is stored. With the current persistence model, if a Player owns a cup then the cup has persistent info because it's bound to the Player, but an AI is not bound to a Player but to the Server. This is where global persistence comes in, where the cup is saving its persistent state (damage, health, who's inside it) to the Server's version of persistence info. This will allow for things to be streamed-out on each dedicated server, to unroll an entity and then bring it back. Further out, we'll see stuff like Server Meshing where maybe the cup is owned by a different Server, so then the persistence info of the cup has to be stored to the global universe, rather than to a particular Server - this is much further away, so right now we're just looking at SSOCS and Server Persistence. Just like with CSOCS, this will change a tremendous amount of game code, and most engineers are focusing on this development. As the tech becomes available, game coders (like Mark Abent) will have to change the system to expect that the cup is no longer (potentially) on the Server, so they need to figure out what needs to be saved in the general persistence so that it "comes back" as it was before it was streamed-out. The Ping System is a good example of what gets heavily affected by this. Right now with Ping, you can ping out and find things outside of the radar, but if the cup could be seen by a Player and it's streamed-out by both the Client and the Server, and the Player pings out and is expected to know that there's something there, the Player won't get that info (because it's streamed-out and there's nothing to communicate that it would be there). So now the coders have to change the Ping code to run a "service" - code that can read the persistent data - so that the Ping could as the service if there's anything within the area that's being pinged, and then the service checks to persistent entities that are streamed-out and what info is attached to them, so that it can be relayed back to the Player, who could then fly to that point of interest and find that a ship, which was there but was streamed-out, has now been streamed back in. Sean Tracy adds: SSOCS will have a dramatic effect on performance. Last quarter they hit a serious limit for content they can load on a Server, to the point where it's really hard for even the Devs to run their Servers locally, just because of the amount of RAM they need. So there's no more content they can shove in; they need SSOCS. And work on SSOCS doesn't stop work on Features, instead tasks are periodically fed to Devs, although SSOCS does take precedent over any Feature by far, because of how badly it's holding them back. A lot of the problems with performance, both Client and Server, is just too much stuff being held in memory, which SSOCS will help with. Also, the Persistence Team has laid out a calendar of when they want to get certain things in, which isn't a direct "on this day this" but more just a "we're here on the schedule" and "when we get to this point we'll have to talk to these people to do these things", and then when that's done they move forward on the schedule. Having done CSOCS already, it's helped them to know exactly what's going to happen with SSOCS so that they could plan pretty rigidly, to the point where SSOCS is more like game construction than game development.