The last time we had this conversation [about long-term persistence], you talked about utilizing this entitlement system. Is that what we were just talking about, or is there more?

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.