Conversation
Whenever the client's CarSpawner.SpawnCar() or CarSpawner.SpawnCars functions are called: 1. The client sends the server a spawn request packet with the required information. 2. The client-side car is deleted. 3. The server spawns an appropriate NetworkedTrainCar. 4. The server sends all clients a request to spawn that NetworkedTrainCar. This could be done more efficiently, but it works well from testing.
|
Hey @leonskij, Haven't forgotten this PR, still need to test & review #112 and this one. In general everything should be server authorative (rerailing and clearing cars from the comms radio is an example), where the client requests an action and the server either accepts and processes or rejects the action. In the case of the spawn workflow I would expect:
There are a few traps with some client spawns, inparticular, the Work Trains, as only 1 of each type exists in the game so calling it while someone else is using it is problematic and requires validation/blocking. From memory another issue is the way it can jump across the map requires special handling to stop the physics from freaking out. These issues were why the spawn features are deliberately disabled until higher priority issues could be resolved, so very much hoping either your PR or #112 works :). |
I checked out #112, but it did not work in my testing. Thus, I thought I would have a crack at it. If #112 does indeed work then feel free to close this.
Allows cars spawned via the client's
CarSpawner.SpawnCar()andCarSpawner.SpawnCars()methods to be correctly requested to be spawned on the server from the client.There are improvements that could be made, such as possibly linking the client-spawned car to the networked car instead of despawning it just for the server to re-create it. But, I'm new to the code-base and still getting used to it.