Future networking update

As I said earlier, according to the plan, I was going to add the possibility of moving between sectors. In theory, it looks simple: Move the ship to a sufficiently distant point by specifying the desired coordinates, done. But in practice it does not work. In previous update I made the movement system non server-authoritative, so this way it was possible to simulate the world on a remote client at a point that is very far from the world origin on the server to bypass the float precision limitation.

This restriction also does not allow to make a raycast to determine hits of guns those belong to the ship that is very far from the center of the world on the server, including beams, projectiles and missiles. As raycasts are also used to determine the dead angles for shooting, it becomes impossible to reliably determine them on the server too. Therefore, if you simply move the ship far enough away, it will not be able to function properly.

Thus, to get around this, it is possible to determine the hits either from the player who owns projectile or cannon, or from the one who owns the object being shot, as it is expected that in these particular cases the given simulation will be the most accurate. Choosing between the two solutions described, I chose the 2nd one, since in this case it is not necessary to dynamically check, change and sync the authority of projectiles as they approach ships of other players. In this case, authority is only assigned once when the projectile is spawned. In order not to give clients full authority over what was happening, it was decided to only determine the hits on the clients, while to keep doing the damage calculation on the server.

In order to bypass the impossibility of determining dead zones for shooting on the server in the case described above, it was decided to “bake” the raycasts on the client with a certain accuracy, and transmit the result to the server. Since the angles are not affected by the problem with precision limitation unlike positions it will be possible to use determined dead zones when shooting on server. In addition, it even works faster than a raycast and provides just a slightly different result.

Since the position relative to the key object in the sector is used as a workaround for positions, it is very important that all objects in the sector store a reference to it. And there is a second problem, this time with UNET HLAPI. When moving between sectors, it is necessary to create a key sector object first, and then assign a reference to it to the ship and all other objects in this sector. unfortunately UNET HLAPI does not provide enough control over the spawn process, and because it internally handles object spawning, RPCs and syncvars slightly different, the delivery of the RPC containing the reference to the key sector object to the client happens earlier than the spawn of this object, even if it sent after object spawn and on the exact same QoS channel, causing bugs. There is a simple way to get around this by sending a reference to the object after a few frames, but it's hard to say how reliable it is, moreover it's extremely inconvenient.

As a solution, I see the transition to UNET LLAPI and making my own implementation of many basic concepts from HLAPI in order to fully control the order of all messages. This will require minor changes in all networked scripts and significant in several of them, so it will take about a month.