Make "not relay antenna" comms problem more prominent in docs

[Dunbaratu]

Inter-vessel comms fails for vessels that have only normal direct antennas and not relay antennas.

This is very confusing because these are vessels that do have working connections, both of them, but the comm message still fails.

I helped a user who was confused for hours about why this didn't work. (It is in the docs, but only on one page about the connectivity managers and is not mentioned on any of the pages about the comms API itself. I didn't know about it until I read the source code and saw the comment in the code.)

I think we should make it prominent not only on the connectivity manager page, but also on the page describing comms, and the page describing the Connection structure (especially the HASCONNECTION suffix).

We could make a single :ref: target link where the the full explanation already exists and just point to it from those other places.

[Dunbaratu]

In examining this problem, I'm of the opinion that the current rules are kind of silly (but not our fault. The KSP API is doing it) and maybe we could fix it.

The problem is that the (entirely sensible) rule that vessels out of physics range can't use their antennae unless they're relays, while it makes sense, is also causing the FindPath() stock API call to fail for vessels that are loaded in physics range and thus should work with direct-style antennae (it just refuses to look at direct antennae at all in the API call).

Three Possible solutions could be:

1 - When FindPath() fails, we fallback to a dumb homebrew test that just checks if there's a direct connection that works right between the two vessels, before giving up.

2 - We make some of the higher-order kOS CPUs be the relay module for other antennae (by having them on the ship you cause other antennae to become relay-capable when they otherwise wouldn't be.)

3- We just make the kOS CPU into a small relay antenna. It doesn't need much range - just enough to handle the case of things being in the physics bubble but still failing anyway.

One worry I have about options 2 or 3 is that the entire reason stock KSP doesn't make every antenna a relay is for performance. A vessel that has only direct antennae doesn't need any bookkeeping in the comms system when it's not loaded.

[Dunbaratu]

Okay this I think is a good solution:

When trying to find a connection between two vessels that the API claims have no path, before giving up on a connection, attempt this:

Find out if VesselA has a path to home. Find out if VesselB has a path to home.

If both paths exist, then we have a connection, who's delay is A's route to home plus B's route to home. (i.e. the KSC is acting as the relay).

[hvacengi]

I would need to do testing again, but I believe the limitation is that KSP literally ignores any vessel in any way if it isn't active (it is possible they don't ignore it if the vessel is in physics range but isn't active). So the path to home will always be found to not be true for the 2nd vessel.

I put a couple weeks into researching this when CommNet was initially released, and even talked with squad about adding the support.

I don't know that adding the relay antenna to kOS cpus will actually fix the problem, in some of my testing it looks as if KSP will only check the relay antennae and not the standard antennae for an unloaded vessel. Which means the relay antenna needs to be strong enough to reach the active vessel, or to reach a relay comm path. I can do some further testing this weekend, but I am not hopeful of a good fix. I very much don't want to implement some kind of home brew system. That could have a worse effect of behaving very differently from stock in some instances.

As for the position of the documentation and the prominence, I wouldn't mind adding a reference to the note to the connection page. But it really doesn't belong on the documentation for Connection, it is a behavior of the CommNetConnectivityManager, and is already called out in a note block. I think a .. seealso:: block on the Connection page might be the best choice since they aren't in the same table on contents grouping.

[MaraRinn]

What about using KSC as the message queue for all vessels that don't have a connection that is connected? Thus for a vessel with only a direct antenna the messages queue would only be populated when the vessel is active.

I came across this bug while trying to deploy a relay + survey constellation. I separate my satellite and try to send it a message to deploy antennas, but it doesn't work because there's no active relay antenna!

The workaround in my case would be to send the message, then set that vessel to be the active vessel.

NB: the documentation does not mention the limitation on vessels requiring relay antennas in order to communicate, and the connection:isconnected attribute is not always "true" despite what the documentation claims.