VesselUpdates are slow to generate about lunamultiplayer HOT 6 CLOSED

I agree that vessel updates are slow.

The main problem is that KSP api does not have events to detect when an engine is turned on (with the right click menu, not with the stage button) and also there are no events to detect when a decoupler is triggered (again with the right click menu)

Therefore, after asking about it on the forum
http://forum.kerbalspaceprogram.com/index.php?/topic/150507-detect-decouple-event-engine-start-event/

The only solution I've found is to send the current started and stopped engines and also the existing decouplers.

Regarding the network stuff, receiving and sending messages are handled in another thread so this shouldn't be a problem.

Solutions for the slowness of the engines and so on:

1: Create a new VesselEngineInfoMsg and a VesselDecouplerInfoMsg and send them at a greater interval (0.5s for example)

2: Using reflection, create a delegate that detect when a engine is turned on or a decoupler is triggered by subscribing the correct private methods of the KSP code.
This solution is quite complex and we would need to subscribe that delegate to all vessels. Could be quite slow also as reflection is not very well optimized.

Either way I can help you on the solution that suits best

from lunamultiplayer.

I'm already creating a VesselPositionUpdate that only updates a few fields, and we'll send that frequently. The rest of the updates will be sent infrequently.

from lunamultiplayer.

Wrote a lot of code tonight towards this, but thought of a few bugs with the current implementation, so I'll have to work on it more tomorrow.

from lunamultiplayer.

So I just realized that I had my unit of measurement wrong and it's µs, not ms. So this isn't as much time as I thought.

With the modified code and reduced fields, I'm seeing 25 µs per position update generation. This doesn't account for position update receiving, interpolation, or any other items. So it's roughly twice as fast as before, for transmission. Next, I'll have to look at receiving.

It looks like approximately 3µs is actually generating the update to be sent, and the remainder is in the send method. We could save approximately 22µs in the main thread by moving the send calls to another thread, but that's probably not worth it.

I'm also seeing unexpected results for the bandwidth usage of KSP, so I'm going to keep looking at that to ensure that we're not using too much bandwidth.

from lunamultiplayer.

Hi Lothsahn, good to hear that you made such an improvements :)

Regarding the network, both sending and receiving are handled in different threads.

All the systems that handle messages have a Incoming ConcurrentQueue where messages are inserted from the receiveing thread. Then on the fixedUpdate of every system, the method "HandleMessage" Is called. This method just dequeues the messages and handles them. (MessageSystem abstract class)

The sending thread have also a Outgoing ConcurrentQueue where all systems can enqueue their messages and they will be sent by it's proper thread.

You can see all of this in the NetworkReceiver and NetworkSender classes

from lunamultiplayer.

Closed

from lunamultiplayer.