Add option to allow control of unmanned ships without a connection

[spookydonut]

It adds a config option (defaults to off) that turns on a network only mode, where it bypasses the connection check (but keeps the powered check).

A few people I've talked to had explained that their enjoyment of remotetech came from the network building aspect, not the delay or control loss aspect.

[spookydonut]

I've actually found a bunch of quirks/bugs that I'm currently working through.

[spookydonut]

Fixed all the bugs I can find.
https://www.mediafire.com/?fu6ubbn6e4qbtrd .dll only for testing, distributing under gpl2 same as RT

[erendrake]

I will not be merging this, one of the other contributors may disagree and reopen this issue but remotetech is about network building. and network building requires that you be able to control your craft.

PRs that make these connections easier to manage are fine, but one that hand waves needing a connection are not imo.

[erendrake]

Thank you very much for the PR, it looks like you did a great job at adding the feature and i am sorry i could not merge it.

[spookydonut]

So it's fine to hand-wave network delay but having another completely optional mode that hand-waves away disconnections in a game that people play for fun isn't? That's just silly.
I'm sure everyone involved would rather merge this than having to fork and maintain a parallel version of remotetech that is exactly the same except for the addition of this feature.

[erendrake]

If it had been up to me i would have never added that option either. That being said, i think one of them is changing the speed of light which is not canonical as far as i know. The other is ignoring the idea that you need to be connected to a craft in order to control it. which as i have said before, is a gift to the RemoteTech project.

Having hard and unbreakable rules in a game or a mod is for me where the game actually is. you have to find ways to achieve your goals with obstacles in your way. Its the difference between Mechjeb and Hyperedit. Both can move your craft to where you want it to be, one follows the rules and the other ignores them.

There is a lot of room for making RemoteTech better and making antenna management easier in ways that give you fewer dead craft and still follow our single unbreakable rule. We have discussed them a lot. Simply turning off the core of the mod citing 'user choice' is not good enough, our users deserve better.

[spookydonut]

You're effectively turning away users because they don't want to play your mod the way you want them too. Which is silly.

[erendrake]

As i said before, one of the other contributors might disagree and want to merge this. I make mods because i like to add new challenges and gameplay to games I love like KSP. I would accept almost any PR other than one that gives the ability to rip the heart out of a mod.

Pleasing all of the people all of the time is impossible anyway so i tend to stick to my guns instead. We had a similar conversation about this exact same issue over on another PR #271

[spookydonut]

This basically allows you to scale down the difficulty for an extremely difficult mod.
Would you merge a feature that allowed the user to ignore short disconnections, i.e; landing on a joolian moon when a freak moon alignment severs the connection and you get a 10-20 minute window to abort/complete the landing of the ship.
The alternative is to quicksave/quickload and start over. KSP has difficulty options, why shouldn't Remotetech?

[jdmj]

If I may.
I can understand disabling signal delay: it may be hard for some people to plan ahead. But this option I don't understand at all. In what way is it fun to build relay networks which you never use? In what way are they "relay networks"? It's like RemoteTech without RemoteTech.

[erendrake]

@spookydonut Just spitballing, this list is very much not exhaustive

i would accept a PR that makes it easier to setup a failover backup link without having to carry and power multiple antenna. ( eg target sat-abc and if you cannot find that, target kerbin ) it might be cool to let more advanced antenna have multiple backups to show how advanced they are.

I would accept a PR that helps antennas that are suddenly disconnected find a new link and continue working ( although this one would require a lot of documentation and be thought through to avoid the same confusion that currently plagues the 'active vessel' feature)

I would accept a new type of special antenna (or alternative antenna configuration) that comes online if there is no valid connection, this antenna could have a longer range than normal but only allow for you to manage the other antenna, not control any other part of the craft.

I would accept a UI that lets you assign antenna in the VAB to avoid the "i forgot to configure these on the pad for the 4th time and lost yet another craft!!!!". It might also be cool to be able to configure antenna to open as soon as you get out of the atmosphere to avoid the same fate.

Being an open source project we are all doing this for free and I respect that and really appreciate that you took the time to send a PR. I will accept almost any PR that doesnt violate what I consider the cardinal rule of RemoteTech. "You must be already connected to a craft in order to issue it commands".

[erendrake]

@spookydonut i have also heard mentioned the idea that you could setup a communication "constellation" where craft in very similar orbits could be grouped and targeted as one and RemoteTech juggles that connection for you.

There are a lot of ideas out there that could make this a much easier, more enjoyable mod. I feel bad that we havent had the bandwidth to implement any of them yet. I am just as guilty as anyone.

[spookydonut]

A lot of these will require repeated cycling of link parameters, what's the best way to do this?
For example if we take a fail-safe mode that cycles a dish to point at different targets.
Assumptions:

1. It will cycle to the next target every x game minutes
2. It should probably not do 1 during timewarp lest it cause problems with graph redraws

You know the codebase better than I (hopefully) so there's probably something obvious that my brief skimming of the code hasn't picked up.

As for constellation management, you would probably need to replace active vessel target with a passive mode (internally, to the user it would be abstracted into the constellation mode) that is presumed to be slowly scanning the sky (but not actually) and establishes a link with the first thing to point at its constellation.

[erendrake]

Disclaimer: if anything i say in here doesnt make sense it might be because i am only up this late to feed an infant :)

@spookydonut if we want to focus on what it would take to do the fail-over. I see it as more of a priority list rather than a cycling. With these rules.

• If you get a hit on the primary target, you are done
• if you miss the primary target, you continue to try each target down the list
• If you miss every target, you would start the next check at the top of the list
• A hit means you were able to connect directly to the craft you specified in the target list. it doesnt mean that you have a connection back to the KSC because your target might be blocked and is working through its own priority list.

the tricky bit is if you get a miss on the primary, but lets say you seek down and find a connection on the 3rd target. The challenge in my mind is do you:

• stay loyal to this new connection for some time (a few seconds)
  This has the advantage of being computationally cheaper and will have far less flail when the limb of a moon is just barely cutting you off from the primary target. At this boundary something small like floating point precision could cause you to gain a loose a connection quickly.
• you immediately seeking back up trying to find a "preferred" connection.
  This is more expensive but so long as we keep the target list fairly short (i envision the first tier or this would have 2, later dishes might have as many as 5?) it will give you your preferred target more of the time when you might otherwise have something sketchy

I will be the first to admit that this connection scheme might be expensive and could even be too slow at time to be useful. its just an idea at this point :)