Remotetech "Local Control"

[Fumblesneeze]

The Hanger acts like a kerbal sitting in a pod for remotetech, making probe contracts impossible to complete with Hangars.

[allista]

Noted. I'll see why that may be. Could you invite RT developer here for help?

[allista]

At first glance: Hangar does not interact with CommNet in a way, so it cannot modify it's part controlled status. The only thing I can think of is that you actually do have kerbals inside the Hangar (which one has this problem), but you don't see them because there's no internal model. There should be a dummy to still show kerbal portraits, though...

[Fumblesneeze]

The missions I've flown were purely probe missions but I had local control right until I popped the fairing Hangars, then regular remotetech connectivity set in for both vessels.

[allista]

Fairing Hangars do have dynamic crew capacity which is updated according to the crew capacity of the stored vessel, so that you can crew it before launching. But again, it's only the capacity. If you don't have crew in the fairings, than you don't have kerbals. I don't know how RT decides if a ship has local control. First, I'll test it without RT to confirm proper operation in stock game.

[Fumblesneeze]

Thanks for looking into it 👍

[aagon]

Hi Allista. First of all, thank you for your amazing work. I made a few tests to help you speed up the repair.

First test : With one of your parts (box fairing hangar), and without any means of communication whatsoever. Note that the hangar is empty.

Expected result : "N/A" or "No connection" ? (can't remember which one I'm supposed to get) edit : pretty sure you're supposed to get "no connection" if the part is supposed to have an integrated probe.

What I got : "N/A"

Second test : With the same part, with a short range RT omnidirectionnal antenna (Reflectron DP-10)

Expected result : "D+0.000000"

What I got : "Local control" (in green)

I have nothing inside the hangar !

The bug occurs regardless of the presence of another contraption inside the hangar.

Third test : This time with one of the stock parts (Mk3-Cargo Bay-CRG50) that you modded by adding hangar capacity but no remote control capacity module, and a probe (so that its actually controllable), and a rover inside the hangar module. The contraption is placed in 100km Kerbin orbit, so that omni 3km connectivity doesn't tamper with the test. Note that the rover, when placed in the same place, would have RT connectivity (carries C-16S, and a whole satellite network is setup).

Expected result : Since the rover is unloaded, and the hangar carries no antenna, would expect "No connection"

What I got : "No connection"

Fourth test : Same as test #3, but with an antenna near the probe.

Expected result : "D+0.00sthg"

What I got : "D+0.00826s"

The CRG-50 works as intended. In fact, all the stock pieces to which you added only the hangar module (and not the remote control module) work as intended. The problems seems to come from the remote control modules you coded in the new pieces you created.

My bet is that these pieces (say the box fairing hangar) would work perfectly if their remote control module was deactivated, and that the remote control would be forced through one of the stock probes (say probodobodyne HECS) RT remote control module.

Sorry for the long post. I am going to make that test, and post the result here later.

[aagon]

Hello again, allista and Fumblesneeze

I have very good news (or not, depending on whether the solving of the bug depends upon us or the RemoteTech crowd).

My project, a few hours ago, was to remove the ModuleCommand module from all of allista's parts. The expected effect would have been to remove all integrated probes from them, hence :

Forcing the players to add another probe to their contraption These probes would have been known to work without bugs (the stock probes work without problem) Hence, problem solved ! At the cost of a few losses of connections for hangars already at the other end of the system. A wee bit violent solution, but working nonetheless as a temporary one.

The part I wanted to remove :

MODULE
{
    name = ModuleCommand
    minimumCrew = 0
    RESOURCE
    {
        name=ElectricCharge
        rate = 0.03
    }
}

Needless to say, I didn't do that.

I instead noticed, on the first and second screenshots, that the Box Fairing Hangar, who is supposed to have an integrated probe, does not have an SPU module, unlike every other probe in the game that works with RT (see screenshots 3 and 4, where Probodobodyne HECS has SPU : No Connection or SPU : Operational).

This SPU module is created by a bunch of cfg files in the RemoteTech GameData folder. For each probe, it creates the SPU module with this bit of code (here, an example for the Probodobodyne HECS) :

@PART[probeCoreHex]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }

    %MODULE[ModuleRTAntennaPassive] {
        %TechRequired = unmannedTech
        %OmniRange = 3000

        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

Note that the condition

FOR[RemoteTech]

is sometimes replaced with

NEEDS[RemoteTech]

I don't know the difference (@allista could you enlighten me ?)

Anyway, I checked the entire RemoteTech GameData folder, and the string "RoverLanderHangar" is not to be found anywhere. And the string "BoxFairings" neither.

Which means, that for none of the parts created by allista, there is a corresponding bit of code inside the RemoteTech Gamedata folder that creates a SPU module for them. And this bit of code is in fact needed for RemoteTech to consider allista's parts as parts with integrated probes, hence subject to the same rules as, say, any stock probe.

Which means, that neither allista nor the RT crowd have made any provision to make Hangar work with RT.

So, Fumblesneeze's problem is not surprising at all.

The solution is quite simple. We need to write a config file that creates an SPU module for each and everyone of allista's parts that were supposed to have an integrated probe. The bit of code will look like that :

@PART[BoxFairings]:NEEDS[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }

    %MODULE[ModuleRTAntennaPassive] {
        %TechRequired = unmannedTech
        %OmniRange = 3000

        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

If you put this bit of code inside a .cfg file anywhere inside the gamedata folder, it will be loaded by the ModuleManager, and the corresponding part will have an SPU module, hence solving the problem.

Proof (notice the SPU : operational) :

If we crosscheck with another part, for which we haven't written the code :

The problem remains. Writing this bit of code is in fact the only thing I have changed to the GameData folder. It is therefore the solution.

Now, my questions :

@Fumblesneeze , could you try and see if this solves your problem as well (I want to check whether we have the same one) ?

@allista I can write a .cfg file for all of your parts, if you want. However, one question remains : is this file supposed to be distributed with Hangar or with RT ? In other words, are you or are the RT crowd responsible for ensuring that both mods are compatible ? Or shall I take the responsibility myself, therefore distributing the patch myself (I would honestly rather not) ?

@allista I have chosen arbitrary values for the %TRANSMITTER part, effectively copying the Probodobodyne HECS. You are the mod's conceptor, hence you may want to tweak these values yourself.

@allista You created a certain number of new hangar parts. Are all of them supposed to have integrated probes as well ?

If you can provide me with a list of the parts supposed to have an integrated probe, and the list of the values you want for each of these parts in the %TRANSMITTER part, I can go to work right away.

Sorry once again for the long post, this is my first real time on Github.

[aagon]

@allista I will begin work shortly, and I will create a pull request to implement the compatiblity. I will probably also create an issue and/or a pull request on the RT repo. And I will host the code on my repo in the meantime.

I will be able to determine which parts need an SPU module by looking at the module command part on your parts .cfg files. I don't think that the values inside the %TRANSMITTER part matter a lot. I think they reference the transmission rate of the automatic 3km omnidirectionnal antenna created by the unmanned tech R&D node, so it is not problematic (it is indeed more coherent) to have the same values for every single one of your parts.

[allista]

I've merged @aagon 's PR and will include the patch in the next release. Thank you for your patience and initiative!