moduleIsEnabled = False/True does not work with RT modules?

[Gordon-Dry]

I try to add part upgrade to RT modules for specific parts, like this:

section 1

@PART[*]:HAS[@MODULE[ModuleCommand],~CrewCapacity[>0],@MODULE[ModuleRTAntennaPassive],@MODULE[ModuleSPU],!MODULE[KerbalEVA]]:NEEDS[RemoteTech]:AFTER[RemoteTech]
{
    //%RSSROConfig = true
    @MODULE[ModuleRTAntennaPassive]
    {
        %TechRequired = unmannedTech
        %IsRTActive = false
        %moduleIsEnabled = False
        @TRANSMITTER
        {
            @PacketInterval /= #$/mass$
            @PacketResourceCost *= #$/mass$
        }
        %UPGRADES
        {
            UPGRADE
            {
                name__ = GD_RT_unmannedTech
                description__ = Probe cores are now remote controllable.
                IsRTActive = true
                moduleIsEnabled = True
            }
        }
    }

    @MODULE[ModuleSPU]
    {
        %TechRequired = unmannedTech
        %IsRTActive = false
        %moduleIsEnabled = False
        %UPGRADES
        {
            UPGRADE
            {
                name__ = GD_RT_unmannedTech
                description__ = Probe cores are now remote controllable.
                IsRTActive = true
                moduleIsEnabled = True
            }
        }
    }
}

section 2

PARTUPGRADE
{
    name = GD_RT_unmannedTech
    partIcon = GD.RT.unmannedTech
    techRequired = unmannedTech
    entryCost = 2000
    cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this.

    title = RT: probe cores remote control
    basicInfo = #autoLOC_501093 //#autoLOC_501093 = Warning: May contain traces of sentience.
    manufacturer = #autoLOC_501664 //#autoLOC_501664 = Experimental Engineering Group
    description = Probe cores are now remote controllable.
}

section 3

PART
{
    name = GD_RT_unmannedTech
    module = Part
    author = Gordon Dry (used under permission of Allis Tauri)
    RSSROConfig = true

    MODEL
    {
        model = zFinal/RT_Mod/RT_pod_up
    }

    TechRequired = HIDDEN
    entryCost = 2000
    cost = 0
    mass = 0
    category = -1
    subcategory = 0
    PhysicsSignificance = 0
    bulkheadProfiles = srf

    manufacturer = #autoLOC_501664 //#autoLOC_501664 = Experimental Engineering Group
    title = RT: probe cores remote control
    description = Probe cores are now remote controllable.
}

It works somehow, but the modules are just enabled from start ...

My last resort was to add the %TechRequired = unmannedTech to the part's module itself ...

[KSP-TaxiService]

Hi,

The moduleIsEnabled variable is not used anywhere in RT codebase. It obeys the IsRTActive variable only.

What were you trying to do with this?

[Gordon-Dry]

I want to give probes / pods built-in basic RT functionality with limited RT range after specific tech tree nodes are unlocked:

• Give probes ModuleRTAntennaPassive / ModuleSPU when unmannedTech is unlocked
• Give probes ModuleRTAntenna / ModuleSPUPassive when advUnmanned is unlocked
• Give crewable pods ModuleRTAntennaPassive / ModuleSPU when advUnmanned is unlocked (for remote testing without a crew)
• Give crewable pods ModuleRTAntenna / ModuleSPUPassive when heavyCommandModules is unlocked

Of course additional antennas to be attached are still needed for long range comms.

This is my patch config so far: https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

^Contents of linked file changed.

Could my patch be the reason for this?

Exception handling event onVesselWasModified in class VesselStatsManager:System.ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[Vessel,TrackResource.ResourceStats].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 
  at TrackResource.VesselStatsManager.Remove (.Vessel v) [0x00000] in <filename unknown>:0 
  at TrackResource.VesselStatsManager.Reload (.Vessel v) [0x00000] in <filename unknown>:0 
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[Vessel,TrackResource.ResourceStats].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 
  at TrackResource.VesselStatsManager.Remove (.Vessel v) [0x00000] in <filename unknown>:0 
  at TrackResource.VesselStatsManager.Reload (.Vessel v) [0x00000] in <filename unknown>:0 
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
EventData`1:Fire(Vessel)
RemoteTech.Modules.ModuleRTAntenna:AddTransmitter()
RemoteTech.Modules.ModuleRTAntenna:SetState(Boolean)
RemoteTech.Modules.ModuleRTAntenna:OnStart(StartState)
Part:ModulesOnStart()
<Start>c__Iterator0:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

(Filename:  Line: -1)

[KSP-TaxiService]

Ok I see your point about this.

For your error question, it is indeed caused by your patch. ModuleRTAntenna was trying to collect a part's ModuleDataTransmitter, which is null due to moduleIsEnabled = false. moduleIsEnabled is used by stock modules to check if logic should run or not in certain scenarios.

Can you try IsRTActive = true inside a UPGRADE block, along with moduleIsEnabled = true? I think if IsRTActive = true does work inside the block, RT modules will activate at same time when moduleIsEnabled is enabled.

[Gordon-Dry]

I already work on more sanity checks in my patch.

But considering parts with ModuleCommand, ModuleRTAntenna (incl. those already patched by my patch) and ModuleAnimateGeneric; I could assume that the animation is linked to the built-antenna. (Like Explorer 1)

To avoid that these built-in antennas are already deployed in VAB ( and on launch pad); I added this block:

// enable ModuleRTAntenna when no ModuleAnimateGeneric exists
@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleRTAntenna],!MODULE[ModuleAnimateGeneric],!MODULE[KerbalEVA]]:NEEDS[RemoteTech]:AFTER[RemoteTech]
{
    @MODULE[ModuleRTAntenna]
    {
        @IsRTActive = true
    }
}

So by default the ModuleRTAntenna is set to IsRTActive = false Inside the UPGRADE it's set to IsRTActive = true now ...

But perhaps this is also wrong because this check does not affect the UPGRADE AND it will default to IsRTActive = true whatsoever when the tech tree node is unlocked?

Which would mean that as soon as the tech tree node is unlocked, the built-in antennas of the Explorer 1 would be deployed by default in VAB / on launch pad?

Updated file: https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

And another update, because of proper USI Sounding Rockets compatibility ... https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

And again, because just even more compatibility with USI Sounding Rockets and/or Kerbalism ... https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

And a dumb error in one line ... fixed

[Gordon-Dry]

And another mistake regarding the compatibility with USI Sounding Rockets and/or Kerbalism. https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

Today I'm cursed, as it seems (but it's Saturday, 13th, not Friday, damnit): https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

It seems RT doesn't allow to have two different antenna types in the same part ... ;( So I disabled all patches regarding ModuleRTAntenna and ModuleSPUPassive: https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

Another sanity check: https://www.dropbox.com/s/qz3gbgsi2ovdnow/zzz_RemoteTechAddMissingModuleSPUPassive.7z?dl=1

[Gordon-Dry]

Actually it works well - but the infos about connection availability are already shown in PAW before the necessary tech tree node is unlocked: https://i.imgur.com/vznUH9n.png

@KSP-TaxiService and especially the question: Is it impossible to have ModuleRTAntenna and ModuleRTAntennaPassive in the same part (plus ModuleSPU, but no ModuleSPUPassive)? I ask because I got an error message in the log about multiple DataTransmitters or something - and for sanity checking I disabled all parts of my patch that also add ModuleRTAntenna and ModuleSPUPassive. Is it just impossible by design or could it "just" be an incompatibility with some specific parts?

[KSP-TaxiService]

No, it is not possible to have both ModuleRTAntenna and ModuleRTAntennaPassive siding in one same part. ModuleRTAntennaPassive is intended for non-antenna parts like probe core while ModuleRTAntenna is for antenna-type parts.

Also, if a part contains ModuleRTAntenna, you must remove ModuleDataTransmitter from the part. We have our own ModuleRTDataTransmitter in place of the stock module.

Honestly, I am not really familiar with how tech tree upgrading and model self-activation. I can't offer any further advice or suggestion to your quest.

[Gordon-Dry]

That ModuleDataTransmitter has to be removed is clear to me, I just wondered about that error message.

The actual version of the patch works, after some additional sanity check. I commented out everything regarding Module RTAntenna.

I guess I can scrap it completely then.

Thanks.