Only run the routing algorithm when RA updates#70
Only run the routing algorithm when RA updates#70periodically-makes-puns wants to merge 7 commits intomockingbirdnest:masterfrom
Conversation
| private KSP.UI.Screens.ApplicationLauncherButton toolbar_button_; | ||
|
|
||
| internal RuntimeMetrics runtimeMetrics_ = new RuntimeMetrics(); | ||
| internal bool do_refresh = false; |
There was a problem hiding this comment.
Trailing underscore in member variable names (2x).
| refresh_watch_.Stop(); | ||
| metrics.num_fixed_update_iterations_++; | ||
| metrics.fixed_update_runtime_ = refresh_watch_.Elapsed.TotalMilliseconds; | ||
| metrics.num_iterations_++; |
There was a problem hiding this comment.
I think that Skopos generally uses pre-increment as it is potentially a bit faster (no need to retain the previous value).
| Log("Starting"); | ||
| enabled = false; | ||
| GameEvents.CommNet.OnNetworkInitialized.Add(NetworkInitializedNotify); | ||
| GameEvents.CommNet.OnNetworkInitialized.Add(AddPostUpdateHandler); |
There was a problem hiding this comment.
If you add, you typically need to Remove in OnDestroy
There was a problem hiding this comment.
Oh, that explains the memory leak I saw. Fixed.
| do_refresh_ = true; | ||
| last_update_ut_ = ((RACommNetwork) RACommNetNetwork.Instance.CommNet).LastUpdateUT; | ||
| } | ||
| } |
There was a problem hiding this comment.
I would like to assume the duplicate cast and derefrences get JIT-compiled out. But maybe they don't, and it probably makes readability better to do:
var network_last = ((RACommNetwork) RACommNetNetwork.Instance.CommNet).LastUpdateUT;
if (network_last > last_update_ut) {
do_refresh = true;
last_update_ut = network_last;
}
|
Issue: We still need to consume electricity properly every FixedUpdate. Right now the Skopos electricity consumption flickers (only when we refresh the network.) I need to pull the EC consumption code out to a separate function. |
|
Appears to be resolved now. |
3 participants
If RA has not updated since the last time we ran the routing algorithm, there is no point in re-running it - we will obtain the same result.
Currently, this makes the game run at slideshow pace on rails warp, since this effectively makes RA runs block the current FixedUpdate for 20ms or so while Skopos routes its connections. However, this makes standard gameplay much more bearable, since we only run the routing algorithm 4-5 times per second instead of every physics tick.
Once we combine this with a suitable routing algorithm optimisation, Skopos routing-related lag should essentially become unnoticeable.