With long-term persistence, it seems like there's always some level of something disappearing every patch. What's going on here?

LTP is a fairly complicated system, but if I can simplify it as much as I can: when you stow something in an inventory, we take that item and we process it. Let's take an easy example, let's say a single gun, a P4. You have a P4, you put it in an inventory that you own. A record is created for your, it's an ownership record that says this player owns a P4, right? Now these records we write to all the time. If you unstow that gun, meaning you put it in your hands, right? We destroy that record, because now it's in play. So you play with the gun and then you stow it back. That recreates the record. So these records should always represent what you've got in your inventory that you own. Now, where it gets complicated is that these things can be hierarchies that contain items that then need to be processed. And so we don't persist everything to LTP. Only a select set of entity classes that designers control will go into LTP. Ships are a good example, things like that. Now, when we stow a ship, we look at its entire hierarchy, and there might be things attached or loosely left in the ship that are LTP. And now they have to be added in. Also with LTP, there's also sometimes perception issues, that things should persist. A classic case is a ship left in the shard between patches. You're flying your ship in 3.24 and we release 4.0. If you leave the ship there in the shard, you don't have a ship record for it. The ship needs to be stowed in order to be there when we recover it. But we do think that there are still issues with some of the recording events in cases where ships are claimed. Because at that point, when you join into the next patch, let's say you have a ship you bought with aUEC and you store it at a location. That ship actually, its record ID comes from your long-term persistent record of that ship. In the case where you claim that ship again, we think that there might be some cases where the record data doesn't follow, and so the LTP record is not recreated. And that could be a source of some of the lost ships in the LTP data. But overall, we're not happy at all with that solution in general. And a bit like you were talking about transit, we want to do a two-pronged approach on this. One of them is, we want to find the cases that are left in the current system that don't behave the way we want them to. But we're also putting significant effort into a different system for this, which is that we don't want to have to wipe the database at all. So we want to be able to keep your inventories intact between patches, and have a forward-compatible model where we can actually keep all this data there the way it is and then migrate it.

Like checking out a file from Perforce. You're not destroying it. You're just copying it out. Nobody else can write to it. Nobody else can mess with it. It's yours. And then when you stow it, it goes back in. So it's a non-destructive process.

And so our goal with this, that's a fairly large endeavor, we're not going to fix it in a second, right? We're going to still hot patch the current system to make sure that the cases that we've seen are fixed. But the longer-term fix is to make sure we only process the data that's going to be compatible. So differentiate between the serialized variables on entities that are important to a ship from those that are runtime only. That's a big difference. So those will be stored in the global database. And between patches, our goal is to just keep that database like this. So there's no, oh, we're getting records back from a thing that has been recording for three months. It's like, no, it's the exact same inventory that you have on the live patch and the new patch. So there's no loss at all. So that's our target for this new LTP solution.