[Request] Instant Structural updates

[JohannesMP]

As demonstrated in the video in this forum post, structural updates do not currently sync between clients. In the video you can see client 1 opening solar panels, enabling lights, and toggling RCS, while client 2 who is either piloting a ship/EVA kerbal nearby or spectating does not see these changes, which for example causes client 2 to see the ship as using up RCS and losing electricity when that is not happening. When client 2 then takes control over the ship, since a spectator becomes the pilot of the other pilot leaves the ship, these values now become what is synced to the server.

I think for multiplayer to be playable it will be necessary for structural changes to a vessel to sync instantly, not every 45 seconds as was the case previously (and seems to be broken currently as demonstrated in the video in the forum post above)

• If a rover flashes its lights at you you should be able to see it
• If ship landing in your vicinity opens its parachute you should be able to see that instantly
• If a station opens its docking port for you to dock, you shouldn't have to wait 45 seconds for your client to recognize that you can actually dock now
• If a lander coming down next to you opens its landing gear the moment before impact, that needs to be synced instantly or else the ship will probably break or lose some parts on your screen, despite having landed successfully on the pilot's screen
• this might be a different issue entirely, but if a pilot has toggled RCS or SAS, and you are spectating that user, that change needs to be reflected in your UI's RCS/SAS

It's far too likely to have really frustrating moments when trying to cooperate in multiplayer if this doesn't happen:

• User A: "Why didn't you put down the landing gear?"
• User B: "What are you talking about, I totally did!"

[godarklight]

I noticed this the other day - Brakes don't seem to instantly change state.

If you change the safety bubble down to 1700, the hill on the end of the runway is outside of the safety bubble. If you park a client there you will see it rolling down the hill and reseting back to where it was (normal vessel updates), until a full update comes along and sets the brakes.

Toggling landing gear/legs, lights, brakes, deploying solar panels, toggling parachutes and a few other cases that I've missed are other times we should send full vessel updates.

The first thing that comes to mind is traversing the ConfigNode tree, but this sounds wrong I can't imagine this would be good for performance or memory. Perhaps we can listen to a certain event, we'll have to see what KSP provides.

[JohannesMP]

Yeah, sending full updates for these changes would be one way, but I still think that it might be worth looking into partial updates.

This is me again just thinking in pseudocode with no bearing on how things are actually handled in the game, but couldn't you just traverse the tree once looking for nodes that contain key characteristics which indicate that they need to be watched, and then on later frames, assuming that vessel doesn't change it's tree structure (like by breaking apart) you could look at those nodes directly?

In any case, here's my attempt at a more extensive list of the types of changes that would be nice to have visible instantaneously - I'm aware that part-specific changes would need to be generalized to how the KSP's object model implements them, but I'm just listing these attributes as examples, and with made up names that make sense to me:

---

Ship-Wide Changes

• RCS/SAS: enabled/disabled (From what I've observed if a spectator's client thinks a vessel has RCS on, they'll see the thrusters fire client-side automatically, even if the original pilot is turning the vessel with RCS off)
• Thrust level (similar to above, I'm making the assumption that a spectator's client will 'see' engines that it thinks are active fire accordingly if it thinks the vessel is throttled up)
• Yaw/Pitch/Roll input (this seems like this is already synced, since when spectating a rover the turning of the wheels when the pilot presses A and D is instantly visible. Though not tested, I'm assuming the same is true for flaps updating their 'position' instantly if the spectator's client believes the flaps are enabled)
• Ship-wide Lights
• Ship-wide Breaks (As you mentioned above, this does not seem to be synced yet)

---

Part-Specific Updates:

• Antennas: extending/retracting
• Control Surfaces: enabled/disabled(yaw/pitch/roll-specific)
• Docking ports: open_shield/close_shield
• Engines: enabled/disabled, lock_gimble/unlock_gimble, state_change (ex: rapier jet/rocket mode)
• Fuel Tanks: enable_fuel_flow/disable_fuel_flow
• Intakes: open/closed
• Ladders: extended/retracted
• Landing Gear: extended/retracted, light_on/light_off, steering_locked/steering_unlocked, breaks_on/breaks_off (not sure if you can force breaks on a single wheel)
• Landing Legs: extended/retracted, suspension_locked/suspension_normal
• Lights: enabled/disabled
• Parachutes: enabled, disabled (spectator seems to see them opening client-side based on the vessel's speed it sees, so the visible triggering of the parachute after it has been staged or set to open manually seems to be calculated client-side and does not need to be sent)
• RSC Thrusters: enabled/disabled
• SAS/Reaction Wheels/Pods/Probe Cores: reaction_wheels_enabled/reaction_wheels_disabled
• Science Parts: opening/closing
• Solar Panels: deployed/undeployed, working/broken(?)
• Wheels: broken/fixed, steering_locked/steering_unlocked, steering_inverted/steering_normal
• Mod specific changes such as B9 airbreaks breaking/not_breaking

---

Resource Updates

• ElectricCharge
• LiquidFuel
• Oxidizer
• IntakeAir
• SolidFuel
• MonoPropellant
• XenonGas
• really any other fuels that mods might add.

Any resource flow should be updated instantly, which I think is one of the biggest reasons to consider adding partial updates. Changes in resources drastically affect how a ship that a spectator is viewing behaves on its client vs on the spectator's client.

For example if the amount of electricity in batteries de-synced somewhat, then between complete updates the lights might turn off for the spectator while they remain on for the actual client due to the changes in electricity not being accurately synchronized.

Other fast changes such as transferring fuel between containers, or intake air changing depending on how the spectated ship is moving can mean the difference of a spectator seeing an engine fire or flameout.

[nevercast]

Noticed this today when I throttled up to check no Thrusters were still enabled (after turning them all off), and a spectator saw me power up all thrusters and the satellite exploded.

What is worse is when he went to the KSP and back again he could still see the satellite exploding, but now he had changed from spectator to pilot (Another issue entirely). This was followed by the both of us logging out and logging in, to see that the satellite was still in one piece, only it had no orbital velocity now. 350,000km up and no Orbital speed. (Another issue again I guess)

The point is all this started because the Thruster on off state didn't sync and then I powered up the thrust.

[JohannesMP]

@nevercast just as a side note regarding the spectator becoming the pilot: If you are controlling a vessel that is set to public (the default setting) and leave that vessel, then whoever is spectating the vessel will become the pilot. This is as is intended. To avoid this happening in the future make sure to set your vessel to private before you leave it.

I would also guess that the vessel losing its orbital velocity is not directly related to this issue (update desync) and was caused by something while the two of you logged out/in. If you can reproduce it then it would be worth opening a new issue just for that.

[nevercast]

I will attempt to reproduce it the next opportunity I get, and I'm fairly sure I was piloting the vessel at the time of losing pilot status. I will test this also, I will also ensure I'm using the very lastest Jenkins build, though I'm sure it's only a couple weeks old

[godarklight]

Throttle status and inputs are is updated immediately (FlightCtrlState), but the others would be really nice to have.

The other bugs sound like server lag - #555.