The netcode is shit. So there's no way in hell they could have even pulled it off outside of a closed environment. Plus, just like Arena Commander and Star Marine, who would be playing it after the initial thrill wears off and it's revealed that it was just another shiny object to release and appease backers in the short-term?
Any merit to the new super tech, Server to Client Actor Networking Rework?
https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/different-tick-rates-in-different-places-with-serv/1930029https://www.reddit.com/r/starcitizen/comments/bpvkr7/does_client_to_server_actor_networking_also/ I can talk about it a bit, I'm the programmer currently working on the actor networking rework. It's split into two parts - upstream and downstream.
First to clarify what an actor is - in the current game that is any humanoid actor (either controlled by an actual human player or by AI) running around in the verse. It does not effect ship or weapon networking, they're different enough that they use different systems (though they do all have some common elements/strategies).
Upstream refers to the communication from the local client up to the server:
* Currently the actor movement is client authoritative - this means that when you press the 'W' button locally your client moves you forward and then sends the new position up to the server, which then replicates it to all other remote clients. This has a number of issues, not least it being a nightmare for anti-cheat as well as it having an effect on perceived lag (most notably, if someone else has a poor connection you see them teleporting about a bunch).
* We are moving actor movement (and indeed their entire state) to being fully server authoritative - when you press the 'W' button locally that is bundled up in an "action" and sent off to a component called the Actor Action Handler. This component replicates this action up to the server and it is processed on both - the local client and the server will move you forward (hopefully the same amount, there's a whole lot of code to make sure it does) and the position from the server is then replicated to all clients, with remote clients accepting it (same as before) and the local client validating against it (too much divergence and they are moved to where the server thinks they are...or rather were, since by the time it's got back down he's likely moved on, we reset and then rerun the inputs since the frame we were reset to).
* There are a bunch of new complexities with all of this - we have to do our best to not miss any actions, we have to take into account the time it takes the actions to get up to the server, we have to appropriately deal with any divergence between client and server and we have to have methods of mitigating lag.
* The most obvious user facing improvements to this will be improved validation and slightly improved experience when facing players on a poor connection. For the validation, since the server is fully authoritative and can tell us exactly when something has diverged we can better cope with that - the previous method was very susceptible to poor server framerate or network latency, manifesting most obviously with the mobiGlas flicking open and closed rapidly, or ladders being a bit clingy (those changes have already made it back into the main branch actually, expect them in 3.5). For playing with/against players with a poor connection you will see them teleport around less, though on their own clients they will rubber-band more as the server corrects them.
* For the most part, think of this as a change that has some minor improvements but is mainly just a precursor to the next part.
Downstream refers to the communication from the server to all remote clients:
* Currently to smooth out actor movement on remote clients we artificially inject a 250ms delay into all their movement processing - being able to see a quarter of a second into the future allows the various movement and animation systems to give a better visual result, and having that buffer mitigates the problem of lag spikes.
* For us, this is not really a sustainable solution. Everything being 250ms out contributes to the game feeling laggy and is an overwhelming factor in the "movement and shot delays" you mention.
* The plan is to reduce this rewind amount significantly to something sensible (hopefully around ~2 frames instead of 15), with improved dead reckoning and state processing helping to cover over the visual impact of this.
* Another factor of this will be remote client patching that is already implemented but needs some tweaks (and bugfixing...) before going fully live. This means, for example, when I kill someone on my client I can temporarily take control of that remote actor to immediately play a hit/death reaction. Since you tend to be looking directly at someone when you kill them any latency on them playing the reaction is very noticeable, so removing the need for the hit to go up to the server and then come back down reduces the perceived lag significantly. Obviously, if the server disagrees with you (you didn't actually hit/kill them) then it will be undone on your client, though this should only happen in cases of extreme lag or cheating.
We have been planning and working on this rework for quite some time, and have confidence that it should improve things significantly.
