[1.11] RemoteTech v1.9.9 [2020-12-19]

[Yemo]

A simpler logic than the one described above:

 

1. Only stock RemoteTech settings config

2. This config is loaded into the game database upon game start

3. Realism Overhaul and SETIremoteTechConfig are changed to be ModuleManager patches, modifying the RemoteTech setting values (eg adding ground stations)

4. Other mods (eg rescale, solar systems) also use module manager patches to modify those values. MM logic would be used to determine the order (eg :FOR[zOPM] is applied after :FOR[SETIremoteTech])

5. The MM modified remote tech settings from the game database are the preset, and are thus used as default for a new game.

6. This default can then be modified by the player through in-game menu. A reset button would restore the preset from 5. for an existing savegame.

 

This would be very simple with practically the same result. The preset is thus the result of the stock RT settings + all installed MM patches applied, thus is created newly every time ksp loads. Existing savegames have the saved settings stored and applied.

 

There is no real need for multiple presets, since realistically, players have different ksp installs for different mod/game setups anyway. No one mixes a realism overhaul install with a seti install or a stock remote tech install anyways. If people want to have a different savegame setup, they also change the installed mods in 99% of the cases using another copy of the whole ksp folder.

So all the different presets add complexity without any tangible merit for 99% of the players.

Edited November 21, 2016 by Yemo

[TaxiService]

5 hours ago, Yemo said:

Long post

(Yemo, I was writing this post when you made another post on the same matter)

Thanks for clarifications on the RemoteTech's preset functionality, which we couldn't understand fully. RT 1.8.0 and earlier versions didn't have any precedence code when building a `Frankenstein` settings from player's current setup of installed mods. It did this when creating a new save or loading existing save.

RT team discussed this matter and agreed that we changed RT's preset functionality completely in RT 1.8.1, which is an unexpected showstopper for third-party mods. We are thinking of this:

• A `Frankenstein` setting will be only created from installed mods's RT cfgs when creating a new game. 
• It is not clear whether ModuleManager can change the order of RT cfgs in KSP's cfg database. It is possible to add precedence value to each cfg (this patch inside a third-party mod's RT cfg?) but it may be harder for inexperienced modders (maybe?)
• Another way is to add `RemoteTechPrecedence{ precedence=x }` node in a third-party mod's RT cfg, along with the `RemoteTechSettings {...}` node. RT would read each RT cfg from KSP's cfg database and rearrange the order of creating based on the precedence values

In your second post, I am not sure if this approach of sole MM patches is good idea because it is harder to predict and more prone to accidental overwriting. Can you clarify this further as I am inexperienced in MM?

To other modders, feel free to add your feedback/opinion to this matter

Edited November 21, 2016 by TaxiService

[Yemo]

@TaxiService

I ll rewrite the second post.

Under that regime, there are essentially 2 configs:

1. A "Frankenstein" config, newly assembled each time ksp is loaded:
Stock remote tech settings are loaded into the game database.
Then various MM patches are applied from other mods.
Once all MM patches to that config are done, the resulting config is used as "preset".

2. When a new career/savegame is created, the "preset" from 1. is used (if another mod with different MM patches is installed, the "preset" is different).
The player can then use the in-game UI to alter that preset.
A button exists, to revert to the preset from 1.
Once the player clicks accept, the resulting config is stored in this particular savegame.

Thus there are always 2 remote tech configs when an existing savegame is played. The one stored in the savegame, which is the one that matters for this specific savegame.
And a frankenstein preset, which only depends on the stock remote tech settings + all the MM patches (thus is newly created on every game load). For existing savegames, the frankenstein one is only used when the player clicks the revert button in the in-game UI.

 

The prediction and accidental overwriting are only a problem if modders create bad MM patches. A standardized formula is beneficial:

1. RemoteTech does this: RemoteTechSettings {}

 

Mutually exclusive "first order/full" settings modifications do this:

2.a) SETIremoteTech: @RemoteTechSettings:NEEDS[!RealismOverhaul]:FOR[SETIremoteTech] {}
2.b) RealismOverhaul: @RemoteTechSettings:FOR[RealismOverhaul] {}

Thus if the SETIremoteTech patch "detects" that RealismOverhaul is applying a patch, it does not apply the SETIremoteTech patch. Which makes sense, because SETIremoteTech settings would be useless in a realism overhaul world. But this is only a fail-save, since no one should install SETIremoteTechConfig and RealismOverhaul in the same install anyway...

 

"Second order/partial" settings modifications (eg different solar systems requiring different ranges) do this:

3.a) NewHorizons or so: @RemoteTechSettings:FOR[zzNewHorizons] {}
3.b) OuterPlanets: @RemoteTechSettings:NEEDS[zzNewHorizons]:FOR[zzOPM] {}
3.c) OuterPlanets: @RemoteTechSettings:NEEDS[!zzNewHorizons]:FOR[zzOPM] {}

MM patches are applied alphabetically. So a second order patch using :FOR[zz...] is always applied after eg :FOR[RealismOverhaul]. In the example above, OuterPlanets applies different patches, depending on whether NewHorizons is installed or not.

 

"Third order/partial" settings modifications (eg solar system resize modifications) do this:

4.a) Resize 3.2: @RemoteTechSettings:FOR[zzzzResize32] {}

They use :FOR[zzzz...], thus these patches are applied after the second order patches.

 

So in total, it could go like this:

1. RemoteTechSettings loaded into game database
2. SETIremoteTech modifies various fields using MM patches FOR[...], adding new ground stations and replacing the existing one, eg from 10Mm to 20Mm.
3. NewHorizons applies an MM patch on top of that :FOR[zz...], multiplying the ranges of all ground stations, eg 20Mm * 2 = 40Mm.
4. Resize3.2 applies an MM patch on top of that :FOR[zzzz...], again multiplying the range of ground stations, eg 40Mm * 3.2 = 128Mm.

 

Now if only SETIremoteTech and Resize 3.2 were installed, it would look like this:

1. RemoteTechSettings loaded into game database
2. SETIremoteTech modifies various fields using MM patches FOR[...], adding new ground stations and replacing the existing one, eg from 10Mm to 20Mm.
3. Resize3.2 applies an MM patch on top of that :FOR[zzzz...], multiplying the range of ground stations, eg 20Mm * 3.2 = 64Mm.

 

Then the only thing to do is, to add this standardized formula into the wiki, so that all RemoteTech settings related patches/modders stick to it and thus unnecessary problems are avoided.

Edited November 21, 2016 by Yemo

[The-Doctor]

13 hours ago, TaxiService said:

Nope, We don't have any plasma blackout in this current version. The 1.x branch is not using any feature of CommNet (apart from the stock antennas).

so will the next version have it? Also, do you guys intend on working with the developer of Kerbalism, @ShotgunNinja s that his coronal mass ejection feature works with this mod?

[NemesisBosseret]

No ground stations ,  no comms with korpinicous and KSS installed,   don't know why.   it was working before kss and korpinicous patch aka yesterday, not sure if it's a compatibility or just a missed value for kss or korpinicous ,   any ideas?

https://www.dropbox.com/s/c11ponuqkmy4m9d/KSP.log?dl=0

https://www.dropbox.com/s/gckzn3scbe8fsla/output_log.txt?dl=0

https://www.dropbox.com/s/8vlps7gmxom6qtl/screenshot0.png?dl=0

https://www.dropbox.com/s/lyac7q2khgpzcrg/screenshot1.png?dl=0

[TaxiService]

8 hours ago, The-Doctor said:

so will the next version have it? Also, do you guys intend on working with the developer of Kerbalism, @ShotgunNinja s that his coronal mass ejection feature works with this mod?

At this stage, it is too early to be sure as we are still breaking into KSP's CommNet. For this coronal mass ejection, it is too early to be sure as well. We are re-developing everything in the RemoteTech as bunch of stuff are redundant as CommNet became a thing.

1 hour ago, NemesisBosseret said:

No ground stations ,  no comms with korpinicous and KSS installed,   don't know why.   it was working before kss and korpinicous patch aka yesterday, not sure if it's a compatibility or just a missed value for kss or korpinicous ,   any ideas?

https://www.dropbox.com/s/c11ponuqkmy4m9d/KSP.log?dl=0

https://www.dropbox.com/s/gckzn3scbe8fsla/output_log.txt?dl=0

https://www.dropbox.com/s/8vlps7gmxom6qtl/screenshot0.png?dl=0

https://www.dropbox.com/s/lyac7q2khgpzcrg/screenshot1.png?dl=0

It is hard to tell from your logs. Can you go to your RT setting window > preset and list the presets as seen below? Sorry, I found the answer in your log. No presets from your installed mods are found for RT. You were starting a new game?

Also, can you revert to RT 1.8.0 to be sure that RT 1.8.0 works in your game (eg the red dot on KSC in map view)?

By the way, we discovered that RT 1.8.1 accidentally removes the function that interacts with RT cfgs of your installed third-party mods. Currently, we are discussing with one affected mod author on how to approach such third-party mods' RT setting cfgs.

Edited November 22, 2016 by TaxiService

[James3838]

Trying out 1.8.1 and love being able to use stock antennas, that said, I had a contract in progress that requires power/antenna's.  I actually have both RT and Stock on my sat (as before RT would not satisfy contracts).  Now neither satisfies contracts. 

                PARAM
                {
                    name = VesselSystemsParameter
                    state = Incomplete
                    disableOnStateChange = False
                    values = 0,0,0,0,0
                    typeString = probe
                    mannedStatus = 1
                    requireNew = True
                    checkModuleTypes = Antenna|Generator
                    checkModuleDescriptions = has an antenna|can generate power
                    launchID = 44
                }

 

[Jiraiyah]

14 hours ago, Yemo said:

@TaxiService

I ll rewrite the second post.

Under that regime, there are essentially 2 configs:

1. A "Frankenstein" config, newly assembled each time ksp is loaded:
Stock remote tech settings are loaded into the game database.
Then various MM patches are applied from other mods.
Once all MM patches to that config are done, the resulting config is used as "preset".

2. When a new career/savegame is created, the "preset" from 1. is used (if another mod with different MM patches is installed, the "preset" is different).
The player can then use the in-game UI to alter that preset.
A button exists, to revert to the preset from 1.
Once the player clicks accept, the resulting config is stored in this particular savegame.

Thus there are always 2 remote tech configs when an existing savegame is played. The one stored in the savegame, which is the one that matters for this specific savegame.
And a frankenstein preset, which only depends on the stock remote tech settings + all the MM patches (thus is newly created on every game load). For existing savegames, the frankenstein one is only used when the player clicks the revert button in the in-game UI.

 

The prediction and accidental overwriting are only a problem if modders create bad MM patches. A standardized formula is beneficial:

1. RemoteTech does this: RemoteTechSettings {}

 

Mutually exclusive "first order/full" settings modifications do this:

2.a) SETIremoteTech: @RemoteTechSettings:NEEDS[!RealismOverhaul]:FOR[SETIremoteTech] {}
2.b) RealismOverhaul: @RemoteTechSettings:FOR[RealismOverhaul] {}

Thus if the SETIremoteTech patch "detects" that RealismOverhaul is applying a patch, it does not apply the SETIremoteTech patch. Which makes sense, because SETIremoteTech settings would be useless in a realism overhaul world. But this is only a fail-save, since no one should install SETIremoteTechConfig and RealismOverhaul in the same install anyway...

 

"Second order/partial" settings modifications (eg different solar systems requiring different ranges) do this:

3.a) NewHorizons or so: @RemoteTechSettings:FOR[zzNewHorizons] {}
3.b) OuterPlanets: @RemoteTechSettings:NEEDS[zzNewHorizons]:FOR[zzOPM] {}
3.c) OuterPlanets: @RemoteTechSettings:NEEDS[!zzNewHorizons]:FOR[zzOPM] {}

MM patches are applied alphabetically. So a second order patch using :FOR[zz...] is always applied after eg :FOR[RealismOverhaul]. In the example above, OuterPlanets applies different patches, depending on whether NewHorizons is installed or not.

 

"Third order/partial" settings modifications (eg solar system resize modifications) do this:

4.a) Resize 3.2: @RemoteTechSettings:FOR[zzzzResize32] {}

They use :FOR[zzzz...], thus these patches are applied after the second order patches.

 

So in total, it could go like this:

1. RemoteTechSettings loaded into game database
2. SETIremoteTech modifies various fields using MM patches FOR[...], adding new ground stations and replacing the existing one, eg from 10Mm to 20Mm.
3. NewHorizons applies an MM patch on top of that :FOR[zz...], multiplying the ranges of all ground stations, eg 20Mm * 2 = 40Mm.
4. Resize3.2 applies an MM patch on top of that :FOR[zzzz...], again multiplying the range of ground stations, eg 40Mm * 3.2 = 128Mm.

 

Now if only SETIremoteTech and Resize 3.2 were installed, it would look like this:

1. RemoteTechSettings loaded into game database
2. SETIremoteTech modifies various fields using MM patches FOR[...], adding new ground stations and replacing the existing one, eg from 10Mm to 20Mm.
3. Resize3.2 applies an MM patch on top of that :FOR[zzzz...], multiplying the range of ground stations, eg 20Mm * 3.2 = 64Mm.

 

Then the only thing to do is, to add this standardized formula into the wiki, so that all RemoteTech settings related patches/modders stick to it and thus unnecessary problems are avoided.

Hmm there can be an easy approach for the ordering of the settings, how about adding two buttons beside each config in the loading screen of RT in the config window in game? one for moving that config higher in the list and one for moving in down and then the order would be bottom to top?

this would solve any prediction needed and each player would need to set the order properly at the start of the game and hit a "Recalculate" button in the same section so that RT would read the proper order now and set everything? after all this would be one time only setting per new game?

[neitsa]

19 minutes ago, Jiraiyah said:

Hmm there can be an easy approach for the ordering of the settings, how about adding two buttons beside each config in the loading screen of RT in the config window in game? one for moving that config higher in the list and one for moving in down and then the order would be bottom to top?

this would solve any prediction needed and each player would need to set the order properly at the start of the game and hit a "Recalculate" button in the same section so that RT would read the proper order now and set everything? after all this would be one time only setting per new game?

This is tempting but Nah, especially if that's the only possibility. Players usually don't want to deal with configs and all those stuffs, the burden should be on programmers side, not on players. OTOH, that could be an option though if that would allow players to override (for any reason) the default config, but not as the only option.

 

@James3838 could you post an issue on github so that we could make a full repro please?The save file only should be enough if the vessel in question is not using other mod parts (otherwise we'll need a full bug report).

This bug seems to keep resurfacing but no one want to share their saves: and without save files, no bug fix...

Edited November 22, 2016 by neitsa

[TaxiService]

1 hour ago, Jiraiyah said:

Hmm there can be an easy approach for the ordering of the settings, how about adding two buttons beside each config in the loading screen of RT in the config window in game? one for moving that config higher in the list and one for moving in down and then the order would be bottom to top?

this would solve any prediction needed and each player would need to set the order properly at the start of the game and hit a "Recalculate" button in the same section so that RT would read the proper order now and set everything? after all this would be one time only setting per new game?

In addition to what neitsa, this can be difficult for players because much of the settings are technical in nature and the players can't be expected to know exactly what and which settings are changed or left untouched. Players expect to have a out-of-box experience of RT when starting a new game.

Edited November 22, 2016 by TaxiService

[symmeclept]

@James3838 @neitsa I've had a similar issue with contracts recognizing power and antennas for generating contracts(RemoteTech pack). Not sure if they are related, but it can't be coincidence, right? I logged an issue, hope it helps. If not, just delete it

[NemesisBosseret]

@TaxiService I reverted to 1.8.0 still no joy,   no ground stations.    what broke? tried to revert to default configs but using korpinicous and kss planet pack is there something missing ?

[TaxiService]

5 minutes ago, NemesisBosseret said:

@TaxiService I reverted to 1.8.0 still no joy,   no ground stations.    what broke? tried to revert to default configs but using korpinicous and kss planet pack is there something missing ?

When you create a new game with RT 1.8.0, no ground stations are found, right? If so, please zip your new save folder and send so that I can at least look into the files there. I have a feeling something in your list of mods is broken and it isn't from our RT but I want to confirm with your zipped save :-(

Edited November 22, 2016 by TaxiService

[NemesisBosseret]

Rgr do you want career or sandbox?   

[TaxiService]

I doubt this choice matters. Go ahead, thanks!

[NemesisBosseret]

I'll be uploading it shortly,   I'm guessing seti rebalance broke something

[NemesisBosseret]

https://www.dropbox.com/s/iu97gzutgahd4mq/persistent.sfs?dl=0

https://www.dropbox.com/s/xht56b01geu7g3v/RemoteTech_Settings.cfg?dl=0

@TaxiService thats the two files i could use dropbox to upload , do u need anything else

[Jiraiyah]

49 minutes ago, TaxiService said:

In addition to what neitsa, this can be difficult for players because much of the settings are technical in nature and the players can't be expected to know exactly what and which settings are changed or left untouched. Players expect to have a out-of-box experience of RT when starting a new game.

true and true, the reason i said something like that was this : I normally use the mods as they are, the only thing i changed by a custom setting for remote tech was ground station and then i added some patches in separate file to tweak some numbers on the antenna ranges, that is why i thought having sorting option on the config section would be easy, never thought that someone may change anything other than ground stations in that file. sorry

[FreeThinker]

Question at http://remotetechnologiesgroup.github.io/RemoteTech/modders/modules/

it is mentioned that

Quote

TRANSMITTER

This block, if present, indicates that the antenna can send science transmissions through the communications network. The PacketInterval, PacketSize, PacketResourceCost, and RequiredResource fields have the same meanings as those in the stock ModuleDataTransmitter module.

The text appears to suggest the Transmitter block is optional

Does that mean it is possible to create receiver only dishes, that can only be used for control?

Edited November 22, 2016 by FreeThinker

[TaxiService]

27 minutes ago, FreeThinker said:

Question at http://remotetechnologiesgroup.github.io/RemoteTech/modders/modules/

it is mentioned that

The text appears to suggest the Tranmitter block is optional

Does that mean it is possible to create receiver only dishes, that can only be used for control?

It does appear that this Transmitter module is indeed optional. In fact, I checked the cfg for one RT antenna:

@PART[RTShortAntenna1]:FOR[RemoteTech]
{
	%TechRequired = start
	%MODULE[ModuleRTAntenna] {
		%IsRTActive = true
		%Mode0OmniRange = 0
		%Mode1OmniRange = 500000
		%EnergyCost = 0.01
		
		%TRANSMITTER {
			%PacketInterval = 0.3
			%PacketSize = 2
			%PacketResourceCost = 15.0
		}
	}
	
	%MODULE[ModuleSPUPassive] {}
}

To be sure, I deleted the TRANSMITTER module in this cfg and tested a vessel with this RT antenna at KSC's launch pad. I was unable to transmit science because I got error message saying no com device found for science or something.

Edited November 22, 2016 by TaxiService

[FreeThinker]

@TaxiService  Question, how to configure Remote tech transmitters for DIRECT tramission only, preventing to be used as a RELAY? (which appears to be it default behaviour)

Just like stock data transmission, I want relay capability to be limited to specialized parts. I don't want part that are only usefull for  DIRECT long range data transmission to be able to function as super powerfull relay stations.

Edited November 22, 2016 by FreeThinker

[TaxiService]

27 minutes ago, FreeThinker said:

@TaxiService  Question, how to configure Remote tech transmitters for DIRECT tramission only, preventing to be used a relays?

Just like stock data transmission, I want relay capability to be limited to specialized parts. I don't want part that are only usefull for  DIRECT long range data transmission to be able to function as super powerfull relay stations.

I asked my RT team on this matter. This feature is not supported currently, and has been requested for while.

My own opinion is: Once we move to KSP's CommNet in 2.x, it is possible for your side to query CommNet's active links (Look up to CommLink class) to determine if it is direct to home.

Edited November 22, 2016 by TaxiService

[FreeThinker]

Just now, TaxiService said:

I asked my RT team on this matter. This feature is not supported currently, and has been requested for while.

My own opinion is: Once we move to KSP's CommNet in 2.x, it is possible to query CommNet's active links (Look up to CommLink class) to determine if it is direct to home.

Great to hear that. Are you the one taking over development of Remote Tech?

[TaxiService]

1 hour ago, FreeThinker said:

Great to hear that. Are you the one taking over development of Remote Tech?

No, neitsa is leading the RT team of about 3 or 4 members. I am just a coder and thread-sitter. 

Edited November 22, 2016 by TaxiService

[TaxiService]

@Yemo

We like your proposal of using MM-patches to add tweaks to our default settings. Layered onto the previous approach of third-party modders' static RemoteTech_Settings.cfgs, this better and safer approach is outlined below.

Quote

A modder, interested to bring his/her own RT setting tweaks into RT, can do the following actions:
1) delete the RemoteTech_Settings.cfg and use a MM patch contained the same tweaks
2) add/insert the required values like extra ground stations to our RT's Default_Settings.cfg, which will be ONLY used when creating a new game. Player's existing save settings will be left untouched.
3) describe the order in which his/her MM patch should be applied (refer to https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#patch-order)
4) if a MM-patch is not provided, RT will revert to the previous approach: the modder's RemoteTech_Settings.cfg will be listed in RT preset windows to replace player's current settings with.

Can you please download our develop-branch zip to check if we are in right direction (i.e. allowing MM modifying RT's default settings, that will be used when creating a new game)?

For your convenience, I included my test GameData/TestMod/rt.cfg below

Spoiler

@RemoteTechSettings:FOR[TestMod]{
    %EnableSignalDelay = False
    GroundStations
    {
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
            Name = Mission Control
            Latitude = -0.131331503391266
            Longitude = -74.594841003418
            Height = 100
            Body = 1
            MarkColor = 1,0,0,1
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+11
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc489
            Name = KSC Northern Control
            Latitude = 19.65
            Longitude = -77.4
            Height = 3200
            Body = 1
            MarkColor = 1,0.8,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 1E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc490
            Name = KSC NE Island
            Latitude = 5.7
            Longitude = -61.28
            Height = 1320
            Body = 1
            MarkColor = 1,0.8,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 1E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc491
            Name = Eastern Peninsula
            Latitude = 3.15
            Longitude = -37.35
            Height = 1980
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc492
            Name = Eastern Mountains
            Latitude = -2.6
            Longitude = 1.5
            Height = 4400
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc493
            Name = Central Continent
            Latitude = 0.4
            Longitude = 56.2
            Height = 2450
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc494
            Name = Far Eastern Mountains
            Latitude = -6.6
            Longitude = 113.6
            Height = 6500
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc495
            Name = Far Eastern Peninsula
            Latitude = -5.4
            Longitude = 141.9
            Height = 380
            Body = 1
            MarkColor = 1,0.8,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 1E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc496
            Name = Crater Mountain Ridge
            Latitude = 1.19
            Longitude = -175.5
            Height = 5900
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc497
            Name = Desert
            Latitude = 2.25
            Longitude = -131.8
            Height = 3330
            Body = 1
            MarkColor = 1,0.4,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 9E+06
                }
            }
        }
        STATION
        {
            Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc498
            Name = KSC Mountains
            Latitude = -0.1
            Longitude = -79.72
            Height = 5450
            Body = 1
            MarkColor = 1,0.8,0,0.7
            Antennas
            {
                ANTENNA
                {
                    Omni = 1E+06
                }
            }
        }
    }
}

If you find that this fix restores the RT's expected interaction with third-party mods' RT tweaks and this fix represents our approach of MM-patches, the next release will include this fix and a new page (overdue) will be added to our online manual, explaining we are dropping the old approach of reading a third-party mod's RemoteTech_Settings.cfg for a better and safer approach of ModuleManager.

Edited November 22, 2016 by TaxiService