Request: Non-Relay ModuleSPU

[NathanKell]

(I had at first wondered whether ModuleSPUPassive did this, but in fact it does the reverse of what I'd like to do.)

I would love to be able to have probe cores and antennas that do not automatically act as relays. This way you would need to especially add a relay part to a satellite in order for it to act as a relay in the RT network; otherwise it could receive and transmit but not forward signals.

How hard would this be to do?

[gnivler]

Would a tweakable on the antenna parts suffice? I don't know how hard it would be, just thinking about it.

[NathanKell]

Anything exposed to MM is fine by me. I was thinking that some antennas would allow relay and some would not, not 'player chooses'. Indeed, if the player can always choose, that sort of defeats the purpose. ;)

[gnivler]

I see your point, a toggle would not achieve that.
On May 4, 2016 5:38 PM, "NathanKell" notifications@github.com wrote:

Anything exposed to MM is fine by me. I was thinking that some antennas
would allow relay and some would not, not 'player chooses'. Indeed, if the
player can always choose, that sort of defeats the purpose. ;)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#532 (comment)

[KSP-TaxiService]

(copied from Slack channel with NathanKell)
I looked at this issue you mentioned for RT 1.x. Will this provide the distinction completely for RO? The suggestion of putting a hidden tweakable IsRelay=True in an antenna part, in which you could supply a separate MM cfg in RO to turn off/on explicity, looks doable, assumed that possible connection between two nodes will be disconnected if no IsRelay=true is detected in either node. I need an impact analysis of this addition on the RT's functionality first.

[NathanKell]

If possible I'd like the relay flag to be set on SPU rather than Antenna--that works fine because antennas have SPUPassive anyway so could still be natively relays. But yep, that would be awesome for us, and close the whole issue. In RO we could always set antennas to non-relay, and only allow later probe cores (or additional hardware) to have relay-enabled SPUs.

[KSP-TaxiService]

@NathanKell So sorry for this long delay! When analyzing the relay feature, I notice one potential design issue and require your feedback (for RO).

Consider this scenario: Let be 3 comm satellites between KSC and an active vessel. Suppose the probe-core part of M the middle satellite's AllowSignalRelay attribute is set to false via MM, the remote-control signal would be terminated at M.

But how can this non-relay behavior be highlighted to RO players? Deleting the connections adjacent to M would send an ambiguous message that M is uncontrollable. I am thinking of re-coloring these connections to, say, blue (configurable in RT_settings.cfg), while third-party connections through M are terminated.

What do you think of this?

[KSP-TaxiService]

With the release deadline approaching, I end up going with the two options discussed above. They can be modified further, should they be necessary.

Blue connections

Connections terminate at non-relay satellites

So far, I didn't find any problem with the relay functionality in my playing, other than the obvious gameplay impact.

I will reopen this issue if any further change is needed.

[KSP-TaxiService]

Nuts, ModuleSPU in the file save still retains the value of the relay attribute after removing the MM cfg. I am not sure how to deal with this, besides manually editing the attributes in the save.

[NathanKell]

@KSP-TaxiService My sincere apologies! I went into a bad mix of crunch time, general RL business, and parent visits over the last few months and totally missed this. Super, super thanks for adding this feature ❤️ and sorry again for missing the feedback request!

[NathanKell]

Maybe I'm doing this wrong, but--it looks like relay mode can't be turned off for ModuleSPUPassive, and all antennas have that?

[KSP-TaxiService]

Hmm according to their code descriptions,

ModuleSPU

/// <summary>
/// Module Signal Processing Unit.
/// <para>This module represents the “autopilot” living in a probe core. A vessel will only filter commands according to network availability and time delay if all parts with ModuleCommand also have ModuleSPU; otherwise, the vessel can be controlled in real time. Having at least one ModuleSPU on board is also required to use the flight computer.</para>
/// <para>Signal Processors are any part that can receive commands over a working connection (this include all stock probe cores).</para>
/// <para>Thus, controlling a vessel is made only through the ModuleSPU unit. Players are only able to control a signal processor 5SPU) as long as they have a working connection (which by default is subject to signal delay).</para>
/// </summary>

ModuleSPUPassive

/// <summary>
/// This module allows any vessel with an antenna to participate in a RemoteTech network, even if it does not have a <see cref="ModuleSPU"/>.
/// <para>It should be included in all RemoteTech antennas. Unlike ModuleSPU, it does not filter commands or provide a flight computer.</para>
/// </summary>

Since ModuleSPUPassive does not filter commands, I give it public bool CanRelaySignal => true;. I can change it to match ModuleSPU but it will contradict the description above.

Can you elaborate how the CanRelaySignal attribute would be applied to an antenna (ModuleSPUPassive)?

[NathanKell]

Ah, the main SPU does the command filtering and it filters out all commands if it's not a relay? I think I misunderstood how it worked. :)
(And if there's more than one non-passive SPU, if at least one is relay-enabled, then the commands get through?)

[NathanKell]

(The desired behavior is: you can have as many antennae with their SPUPassives as you like, and as many regular SPUs with relay false, but unless you have a regular SPU with relay true, the craft should not relay commands)

[KSP-TaxiService]

Yes, this is correct. This is how a vessel computes its header attribute CanRelaySignal.

VesselSatellite.cs

/// <summary>Gets if the satellite is capable to forward other signals.</summary>
public bool CanRelaySignal
{
	get { return SignalProcessors.Any(s => s.CanRelaySignal && !(s is ModuleSPUPassive)); }
}

The network-oriented components (eg network render, network manager) read this public attribute and act accordingly.