Can't control my satellite right after decoupling (RealAntennas, MechJeb and some more)

[crotaro]

So, I built this big rocket that is meant to carry multiple smaller communication satellites into orbit, which is a completely original idea and nobody ever in the history of KSP has attempted this before, I'm sure.

The problem I'm having is that everything goes well right up until I decouple one of those satellites. Even though their MechJeb light goes green after decoupling and they have power and the MechJeb case even has its antenna strong enough to easily reach a ground station on its own (without being relayed by the bigger craft or using the extendable antenna), I lose control of it immediately, saying there's no connection to it anymore.

I know this design works, because I already used it almost 1:1 a year or so ago. The only thing that comes to my mind is that I used RemoteTech (I think) the last time I launched one of those CommBarges. So I'm rather sure it's either a problem with RealAntennas or the vanilla game had some changes to it, which require a different approach to those vehicles.

I'd be super grateful for any help, since I really am not in the mood of launching every single CommSat into orbit using its own vehicle (not only because I'm playing in career mode)

[DRVeyl]

RA should be completely fine with launching multiple CommSats in a single vessel. Please ensure those Communotron-16s get extended, tho: in RA, a deployable antenna will not be active if it is not extended. I'm not sure if RT allowed a sort of "always-on" mode for some antennas that are deployable.

If that isn't the issue, please re-create by launching, kicking out one of the CommSats, waiting 60 seconds [the RealAntennas default log interval], and then grabbing your KSP.log and posting here. In its periodic logging, RA will give info on each vessel and all the antennas it found.

[crotaro]

RA should be completely fine with launching multiple CommSats in a single vessel. Please ensure those Communotron-16s get extended, tho: in RA, a deployable antenna will not be active if it is not extended. I'm not sure if RT allowed a sort of "always-on" mode for some antennas that are deployable.

I already tried having the antennas and solar panels extended right before decoupling. Even when I decouple on the launchpad, it immediately loses connection.

If that isn't the issue, please re-create by launching, kicking out one of the CommSats, waiting 60 seconds [the RealAntennas default log interval], and then grabbing your KSP.log and posting here. In its periodic logging, RA will give info on each vessel and all the antennas it found.

I will do that today, sorry for keeping you waiting on that one.

[crotaro]

Okay, I have a slight problem...I can't paste the entire log here, since it's ~500MB of text, which crashes my computer if I try to paste it into this text field. And I can't attach it because of the 10MB limit. I tried just pasting the last minute, but that's still ~45MB, so instead I put the KSP.log into a WeTransfer link and it'd be great it you could look through it that way. ClickMePls The one thing I noticed that kept repeating every few milliseconds of the log is something about aborting the RA calculations for all kinds of probe cores.

[WRN 12:11:29.758] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] longAntenna [3.0 dBi L 30 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.758] [RealAntennaDigital] Aborting calculation for [+RA] longAntenna [3.0 dBi L 30 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.759] [RealAntennaDigital] Aborting calculation for [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] longAntenna [3.0 dBi L 10 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1 [WRN 12:11:29.760] [RealAntennaDigital] Aborting calculation for [+RA] mumech.MJ2.AR202 [1.5 dBi L 15 dBm [TL:4] 8PSK 94.5 Kbps] and [+RA] mumech.MJ2.AR202 [1.5 dBi L 15 dBm [TL:4] 8PSK 94.5 Kbps] : Distance < 0.1

[crotaro]

Oh, in case this is useful to you, too. Here's two screenshots of the CommSats. The blue conething is a battery. I use just the MechJeb 2 case as a probecore, which works in every other instance as well. Even when I switch it out for a vanilla core, it doesn't work.

[DRVeyl]

Take the last minute, compress it with zip, and paste here, please. I'm not sure how you got those multiple vessels to be considered as less than 0.1 meters apart, except by doing something like transitioning to somewhere very, very far away after.

[crotaro]

Alright, here you go. I'm sorry for taking so long between answers. KSP_last_minute.zip

[DRVeyl]

Try removing SignalDelay. At some point it was conflicting with RA, due to competing for control over the CommNet instance. Looking at their current code, that doesn't look like it would be an issue any longer.

Mostly, I'm worried about the cause of:

[EXC 12:10:29.858] NullReferenceException
    Vessel.UpdateVesselModuleActivation () (at <c1858a3f77504bd1aaa946fdccf84670>:0)
    Vessel.Update () (at <c1858a3f77504bd1aaa946fdccf84670>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Dying during Vessel.Update() is a pretty bad spot. Unfortunately there isn't any info in there to suggest what started that.

[crotaro]

Thank you very much! This did the trick for me. If I may, how could you tell from that log message that SignalDelay was the culprit? Or did you just remember that SignalDelay used to conflict with RA and that log message just popped up to you as a worrying thing separate of that?

[DRVeyl]

There was also seeing this:

[LOG 12:10:29.822] [Kerbalism] Background.ProcessApiModule BackgroundUpdate in PartModule ModuleSignalDelay excepted: Object reference not set to an instance of an object
System.NullReferenceException: Object reference not set to an instance of an object
  at SignalDelay.ModuleSignalDelay.get_ConsumptionRate () [0x0000d] in <24b33828ecda4885b0dc4e5176463aee>:0 
  at SignalDelay.ModuleSignalDelay.BackgroundUpdate (Vessel v, ProtoPartSnapshot part_snapshot, ProtoPartModuleSnapshot module_snapshot, PartModule proto_part_module, Part proto_part, System.Collections.Generic.Dictionary`2[TKey,TValue] availableResources, System.Collections.Generic.List`1[T] resourceChangeRequest, System.Double elapsed_s) [0x00022] in <24b33828ecda4885b0dc4e5176463aee>:0 
  at (wrapper delegate-invoke) System.Func`9[Vessel,ProtoPartSnapshot,ProtoPartModuleSnapshot,PartModule,Part,System.Collections.Generic.Dictionary`2[System.String,System.Double],System.Collections.Generic.List`1[System.Collections.Generic.KeyValuePair`2[System.String,System.Double]],System.Double,System.String].invoke_TResult_T1_T2_T3_T4_T5_T6_T7_T8(Vessel,ProtoPartSnapshot,ProtoPartModuleSnapshot,PartModule,Part,System.Collections.Generic.Dictionary`2<string, double>,System.Collections.Generic.List`1<System.Collections.Generic.KeyValuePair`2<string, double>>,double)
  at KERBALISM.Background+BackgroundDelegate.invoke (Vessel v, ProtoPartSnapshot p, ProtoPartModuleSnapshot m, PartModule module_prefab, Part part_prefab, System.Collections.Generic.Dictionary`2[TKey,TValue] availableRresources, System.Collections.Generic.List`1[T] resourceChangeRequest, System.Double elapsed_s) [0x00000] in <44d2b28eb09144efbf56dab50bc4321b>:0 
  at KERBALISM.Background.ProcessApiModule (Vessel v, ProtoPartSnapshot p, ProtoPartModuleSnapshot m, Part part_prefab, PartModule module_prefab, KERBALISM.VesselResources resources, System.Collections.Generic.Dictionary`2[TKey,TValue] availableResources, System.Collections.Generic.List`1[T] resourceChangeRequests, System.Double elapsed_s) [0x0000e] in <44d2b28eb09144efbf56dab50bc4321b>:0 

which is how I knew SignalDelay was here. Get with its dev about this issue; not sure if you can re-create this without RA.