Why the netcode issue exists, and why it cannot be fixed.

[Hanabira]

i dont think it is quite this simple. If client live games were the norm. they received the action from the client, sent it to the server, and sent back a response and they were still pretty snappy. the original 1.0 UI did this, and it was unbearably slow, taking 3-5 seconds just to open up a menu. Theoretically, making the game run server side should speed things up because now the transmission doesnt need a response. i think they just built the game on a shoddy framework, completely changed and revamped the game from the ground up, and never addressed the exact same problem we had in 1.0. If i recall, fixing that very deep rooted issue was one of the reasons we got a completely new game

[Sinth]

i dont think it is quite this simple. If client live games were the norm. they received the action from the client, sent it to the server, and sent back a response and they were still pretty snappy. the original 1.0 UI did this, and it was unbearably slow, taking 3-5 seconds just to open up a menu. Theoretically, making the game run server side should speed things up because now the transmission doesnt need a response. i think they just built the game on a shoddy framework, completely changed and revamped the game from the ground up, and never addressed the exact same problem we had in 1.0. If i recall, fixing that very deep rooted issue was one of the reasons we got a completely new game

Both models require the client and server to send the same amount of acknowledgements/responses to eachother. The difference is who is driving and who is waiting for commands. Also, the UI issues from 1.0 are completely unrelated to the current netcode issue (from my 1st hand experience digging through packets back in 1.0 to try and fix my connectivity issues). However, the old UI did interface on the network layer, and that was the primary problem with it; hence the redesign from ground-up.