RemoteTechnologiesGroup
Feedback on delays for KerbNet access and features
Clicking on "Kerbnet" action on a probe core delay the action if delay is enabled and is reasonably large (or actions are delayed on Flight Computer).
Is there any reason to delay KerbNet access?
afaik, kerbnet is used in three modes. All of them are kinda awkward to use with RT (mostly because there's a much better ScanSat alternative). In stock, ore scanner uses it in Resources mode, it's local to vessel and always available, regardless of actual kerbnet availability. All of the probe cores and avionics cone have Terrain mode - some sort of altitude map - and it requires connection to kerbnet even for crewed vessel. Lab and some of the probe cores also have Biome mode - not sure if this one needs connection or not.
So, technically, if you delay/restrict action based on whether data is local for the craft controller/driver/operator, then:
- in Resources mode data flows from the vessel to KSC, and delaying/restricting the action is justified for remotely controlled craft but not for crewed vessels, but
- in Terrain and, probably, Biome mode data flows from the KSC to the vessel, and it should be delayed/restricted for crewed vessels but not for remotely-controlled probes (there is no data flow for unmanned probes at all, operator at KSC just looks at the map, he doesn't need to send it to the probe).
But if you're balancing it against ScanSat then action should never be delayed or restricted by lack of connectivity, and the map should always be available as well.
Maybe it's worth asking @BobPalmer for an advice, kerbnet is his child after all.
Thank you @jdmj for your detailed answer. Never played with KerbNet so it clears some aspects that I didn't know of.
I like your first solution (delaying depending the the chosen mod). OTOH you're also right about the balance with ScanSat where display windows are not delayed at all (if I'm not mistaken).
I think I'm gonna try your first idea, which I like a lot and if it's not too time consuming.
Our reflections on this issue:
neitsa ... the only thing left is KerbNet access which is delayed as of now. I have no precise idea of what to do with it. Bypassing the delay for KerbNet is just adding a string in the list of things that have no delay. Delaying precise features of KerbNet is another story with a lot of code needed just for this...
taxiservice as jdmj pointed out, KerbNet and RemoteTech don't mix together well. IMO, we make KerbNet access delay but no further delay to the sub-features of KerbNet. Then, we use the opportunity of 1.8.1 and pre-release RT2 to solicit feedback on this. KerbNet is available only 2 months ago.
neitsa thanks for the heads-up taxiservice ! As of now, the KerbeNet access is delayed but not the features on the KerbNet window. So we can let it as is for now (1.8.1) and, as you said, see what can be done later for the 2.x branch. That's fine for me
This issue will remain open for RT2 development so that other players (included us) can add their opinions once they get familiar with KerbNet features
