I think that ships inside planets are not “tracked” when you’re in the galaxy view. So when there are few fleets outside the planets its fast.
When @Happyworld move his fleets outside the planets to alleviate the lag inside a system he increased the number of “tracked” fleets on the galaxy map. as a result slowed it down…
The idea of space dock will be a useful tool for players to reduce the number of “tracked” fleets/ships. This is not a solution to the problem though.
When I was preparing for war (back in February) I moved over 350 ships to Pyxis 199 and boy it would grind, the CPU was max on one core. If I had paid more attention I would of noted if the lag reduced when all ships were fleeted… if those in the top 10 could unpack all their ships in one system, and note the lag before and after… It may help.
In the GO, the list of planets will likely be a filtered list, I would expect that they pull all the data and “tracked” on all those planets, when we click “my planets” we are just filtering whats seen, but the events are still being listened to.
So when I say “tracked” I mean that the game engine will be listening for changes to all the ships/planets.
What the devs could look at is
- are all ships in a system being tracked and their positions recalculated over and over creating a massive CPU bottleneck?
- could the GO be a static list (there might be a counter that tells players the data is x minutes old and have a refresh button) I would actually love it of this could be exported to a designated Google sheet every hour… In fact it would be cool to have an API that external apps could hook into… Then no need to jump in and out of the GO…
- events received by the client shouldn’t include ships that haven’t moved. The client shouldnt ask for any new positions only on entering the system/galaxy map
- some events could be throttled based on the client CPU usage and only highest priority messages get processed… so fleet movement is high inside galaxy map/system but low when looking at the GO/research etc
- Change credit updates to every 15 seconds so the client isnt handling any TCP that is doesnt realistically need to.
- devs should look to see if the cpu usage increases linearly or exponentially with the number of ships its tracking in each system.
- Not sure if there is a message bus on the backend but might be useful to see if changing 1 ship will all ships receive an update.
- Push the websocket stuff onto a different thread and triage the messages for relevance to the client before processing them, so a planet view would only care about ships that move out of their orbit or are moving (relevance to resource transfer). Messages could contain a relevance flag so resource changes to a planet are not relevant if you’re in galaxy view, so would contain a “resource” tag and the triage would know that the current view “galaxy map” doesnt care about that update and can process it with cpu is below 50%…
Of course I dont have eyes on the code and I’m 100% guessing what might help, hopefully my time will be of benefit to the devs.