Let's talk about the [frame rate] FPS in ArcCorp right now. It's not super.

Yeah, no, it sucks. I mean, basically, the problem that we have is that the client-side object container streaming made a massive difference for the client frame rates, which people can see. You've seen people play at 60 plus frames a second. But on the server, since we are not doing the streaming, as we add more content, so we've got all the moons, we've got Hurston, we've got Lorville, now we have ArcCorp and Area18 and all the stuff, the object and the entity count on the server just keeps increasing. So I think we have something like 330,000 entities that are being updated on the servers. We've actually done quite a lot of optimization on our entity updates and a bunch of others. So if we had exactly the same as we had in 3.4, you would see an uptick in the server performance. The problem is, because we've now just added a whole other planet and a bunch more moons and a bunch more entities that are sitting around all the time on that one server, the server is the bottleneck right now. So the server starts to get slow, like really slow. Our target for the server ultimately is 30 frames a second. But now the servers could be at 10 frames a second or five frames a second. And that manifests on the client side, because things are moving around on the server at a much lower fidelity than they are on the client. And that's why sometimes you can see jumps or jitters even if you've got a decent frame rate on the client side.

Object container streaming on the server is what will fix that. And it's also the first stage of server meshing. So the concept would be that you're playing the game and there's a server that only has ArcCorp and Area18 streamed in, and it's just simulating that. And then there's one that's doing the same for Hurston, and there's one that's doing the same for a moon or whatever. And as you as a player go between these locations, you're getting handed off to these different servers. And the servers dynamically can stream in whatever area they care about simulating. So that's the very first step of server meshing, for which we need to have the object container streaming. It's basically the object container streaming plus the very first step of the server meshing, where we have servers that handle areas and they're sort of static. And then the final version of that is that it's just sort of fluid. It's always spinning up and adding servers as it needs them for load. So that's what we are working on right now. We have our top men, and we really have top men, not the Raiders of the Lost Ark version of top men, like Christopher Bolte and Steve Humphreys and stuff. This is what we're working on to get going.

It's the same problem we had without the object container streaming. We couldn't have added Hurston on the client side. And unless we get our server stuff up and running, which is happening right now, we won't be able to get the full Stanton system with all this detail all working at once, because the servers themselves get bottlenecked. Because outside of the entity updates, we still have the issue on physics, where the physics is constrained to a limited number of threads. And we're working on the physics system to stop that. So this physics system will move from the parallel threaded system, which has four separate physics threads running, to what we call a phase batch model, which would be: you update all the entities, and every core in the server does all the entities together. They all work together to get it done. And then once you do that, then you update all the physics. Every core does it. Then you do all the rendering with every core, which is not on the server, but on the client you would do it. But that's what the phase model is. So instead of being parallel, you basically do things in steps, like update entities, update physics, update animation, render. As you do each one of those phases, you use every single core you possibly can on the computer to do that work. So it gets done much quicker. So we're moving from the parallel threaded model to the phase batch model. We've already done a lot of that. That's a lot of what we've been talking about on the entity system, and we've been moving over to that. On the rendering side, that's why moving to Vulkan is important, because Vulkan allows you to do that. We can't do that with DX11. It doesn't matter how many cores are working on it, you've got a constrained pipe in DX11, but in Vulkan, you can do a whole bunch of stuff in parallel. So we're moving to that. So the combination of that with the object container streaming and first stage meshing on the servers will allow these star systems to expand out. So that's all the background tech work that's happening right now.