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

[Phineas Freak]

@neitsa @TaxiService after seeing the features planned for RT 2.0 i would like to submit a request: while some of the features are considered too hard (like frequency bands, SNR, realistic transmittion models and data rates etc) it would be nice to have them not apply directly (not activated by default) but implemented in the RT core. Then, they can be activated via MM patches for every intererested party.

A specific mod suite comes to my mind that would really appreciate a "next level" RT...

[Yemo]

53 minutes ago, TaxiService said:

That RT default settings in the preset window is MM-patched. I tested your second scenario of existing game and I can see the extra stations in the existing game after the overwrite.

Yes, but nearly no one knows that it works this way. If people install SETIremoteTechConfig and want to use it for an existing game, they will install it, see that there are no ground stations, check the ingame options, see that there is only an option for RT default settings overwrite, and only half? of them will just test-click "overwrite" and check what happens. The others will give up or ask for support.

A neutral "revert/reload RT settings" button would solve this. By using a preset description explicitly stating "default RT settings" and having a path pointing to the remote tech folder, when in fact the patched RT settings are applied upon clicking it, is misleading.

I could try having the MM patch as well as the 1.8.1 style config in the mod, the MM patch for new games, the 1.8.1 config for existing games to be listed in the "presets". Though that would at most be a limited utility workaround (if it works at all). As soon as other mods apply MM patches, it gets confusing.

[Ringkeeper]

1 hour ago, TaxiService said:

It is basically the codes of RT managing the RT network of connections so I doubt you can't just "make less CPU work" by deactivating some antennas. Is it becoming too burdensome on your CPU?

 

Yes. KSP uses then up to 35% CPU according to task manager and ingame the date goes from green to yellow, so as far as i understand the CPU can't keep up or?

I deactivated all antennas on all unused sats, only 9 sats remain with connections. I have the feeling it got better, but not sure yet.

[TaxiService]

13 hours ago, Ringkeeper said:

 

Yes. KSP uses then up to 35% CPU according to task manager and ingame the date goes from green to yellow, so as far as i understand the CPU can't keep up or?

I deactivated all antennas on all unused sats, only 9 sats remain with connections. I have the feeling it got better, but not sure yet.

I think you may want to ask (with your output_log.txt) in the sub-forum of technical support (modded?) on the general performance. I have little idea of how the KSP performance goes with a number of mods installed.

In each physic/time frame, KSP runs its CPU calculations and mods' CPU-dependent operations so this could be normal or not. :-/

[TaxiService]

>> Minor announcement <<

A little update on our public proposal of RT 2.x redevelopment. An introduction and list of proposed modules are added to this proposal.

You should be able to get more concrete picture of what RT 2.x could eventually look like.

Edited December 2, 2016 by TaxiService

[cyberpunkdreams]

That questionnaire has had a reasonable number of responses as well now. 

[Booots]

Just a minor bug report that the Sentinel telescope from the AsteroidDay mod doesn't seem to work with RemoteTech. It gives a message "cannot gather data without an antenna present to transmit the data it gathers". I presume this is because of the antenna PartModule being replaced by RemoteTech's. Obviously not a huge priority, but it would be nice to be compatible.

[garwel]

One thing that felt cheaty about Flight Computer was that you can use all the hold commands regardless of your probe core's capabilities. Even the most basic one could hold prograde/retrograde, execute maneuver nodes etc. It made most advanced probe cores redundant. So I think, 2.0 RTFlightComputer or RTCommandPlanner should make some features unavailable depending on the capabilities of the CPU core.

[TaxiService]

13 hours ago, Booots said:

Just a minor bug report that the Sentinel telescope from the AsteroidDay mod doesn't seem to work with RemoteTech. It gives a message "cannot gather data without an antenna present to transmit the data it gathers". I presume this is because of the antenna PartModule being replaced by RemoteTech's. Obviously not a huge priority, but it would be nice to be compatible.

Oops, I will let our RT team know on this.

8 hours ago, garwel said:

One thing that felt cheaty about Flight Computer was that you can use all the hold commands regardless of your probe core's capabilities. Even the most basic one could hold prograde/retrograde, execute maneuver nodes etc. It made most advanced probe cores redundant. So I think, 2.0 RTFlightComputer or RTCommandPlanner should make some features unavailable depending on the capabilities of the CPU core.

Oops, I forgot to add this detail to our RT 2.x proposal page. This detail was floated in our talking on FlightComputer's abilities. Thanks for pointing out!

Edited December 3, 2016 by TaxiService

[Yamori Yuki]

19 hours ago, Booots said:

Just a minor bug report that the Sentinel telescope from the AsteroidDay mod doesn't seem to work with RemoteTech. It gives a message "cannot gather data without an antenna present to transmit the data it gathers". I presume this is because of the antenna PartModule being replaced by RemoteTech's. Obviously not a huge priority, but it would be nice to be compatible.

Do you have the latest RT (1.8.2)? And does your vessel have an external antenna?
I tested this with just RT and AsteroidDay and it works for me so if you keep having problems with the SENTINEL, let us know (GitHub issue is preferred).

[LostOblivion]

What is the best way to migrate from RT to stock system, keeping all RT parts?

[TaxiService]

34 minutes ago, LostOblivion said:

What is the best way to migrate from RT to stock system, keeping all RT parts?

Assumed you want to retain the RT parts to prevent KSP from automatically deleting your vessels with would-be-deleted RT parts, remove everything inside GameData/RemoteTech folder except for the Parts folder you want to retain.

However, there are couple effects of this removal:

1) the RT parts will be "cosmetic" parts
2) You need to edit this "EnableCommNet = False" in your persistent.sfs to enable CommNet back.

P.S. Make a backup of your save first so that you can undo any accidental destruction

[TaxiService]

@Yemo

Referring to my post to Module Manager, I am trying to duplicate and pass Default_Settings.cfg off as a third-party mod's "RemoteTech_Settings.cfg"  using a MM patch. It seems MM does have a way to modify where the cfg is from. Do you have any idea on this?

Edit: I am thinking of changing RemoteTech to overwrite a player's existing save settings with the MM-patched default settings, every time the player resumes the game. This would work when a player installs another mod with MM patch for RT OR starts a new game, isn't it?

Edited December 4, 2016 by TaxiService

[Yemo]

1 hour ago, TaxiService said:

@Yemo

Referring to my post to Module Manager, I am trying to duplicate and pass Default_Settings.cfg off as a third-party mod's "RemoteTech_Settings.cfg"  using a MM patch. It seems MM does have a way to modify where the cfg is from. Do you have any idea on this?

Edit: I am thinking of changing RemoteTech to overwrite a player's existing save settings with the MM-patched default settings, every time the player resumes the game. This would work when a player installs another mod with MM patch for RT OR starts a new game, isn't it?

Reading your post in the module manager thread and this one, I got an idea how to deal with custom settings/savegame settings:

1. RT default settings get modified by other mods through MM patches
2. The result of this is the "standard" and is used when creating a new game (up until this point, that is how it works at the moment).

The difference is, how and when manual player changes of settings are stored. At the moment all settings are stored in the savefile. I propose to only save "distinct manual settings" to the savefile. Like eg saving the delta v instead of the new velocity. This should practically depend on the setting in question.

For example, default RT setting is "RangeMultiplier = 1". The player has no other mods installed when starting a new game.
After starting a new game, (s)he manually changes the RangeMultiplier to 1.5 in the in game menu. RT thus adds a line in the savegame, eg "RangeMultiplier *= 1.5" (the *= is important for this setting).
After playing for some time, the player installs a mod, which uses MM patches to set the RangeMultiplier to 2 (because it eg provides an upscaled solar system).
After the mod is installed the player continues the existing savegame. Now here comes the difference on how manual changes are applied:

The basic RT settings is "RangeMultiplier = 1", this is modified by the mod to be "RangeMultiplier = 2" (which would thus be used for a new game). Since the savegame has the line "RangeMultiplier *= 1.5" stored, this is applied as if it were an MM patch, after the last MM patch (even after a :FINAL mm patch). So the RangeMultiplier is 3. From 1 (default) * 2 (mod MM patch) * 1.5 (from savegame).

The same goes for all the other settings which can be manually changed in game. The only question is, when the savegame should store values. Imho it should do so, once a player sees the value and acknowledges it (eg by not changing it).

For example the player has only remote tech installed and starts a new game. The player then clicks on "AlternativeRules", where the player sees the default values for "EnableSignalDelay = True", "RangeModelType = Standard" and "MultipleAntennaMultiplier = 0". The player changes RangeModelType to "Root" but does not change the other two options.
Imho this means that the player likes them the way they are. Thus after visiting this "AlternativeRules" screen, RT should store all three values ("EnableSignalDelay = True", "RangeModelType = Root" and "MultipleAntennaMultiplier = 0") in the savegame. If the player does not look at any other RT settings screens, these are the only 3 lines stored in his/her savegame regarding RT values.
After some time, the player decides to install SETIremoteTechConfig (which uses an MM patch to set EnableSignalDelay = False, but does not change the other two values).
So when the player resumes the existing game, this is what happens: Default RT settings
"EnableSignalDelay = True", "RangeModelType = Standard", "MultipleAntennaMultiplier = 0".
After MM patch from SETIremoteTechConfig:
"EnableSignalDelay = False", "RangeModelType = Standard", "MultipleAntennaMultiplier = 0".
After Savegame stored settings are applied:
"EnableSignalDelay = True", "RangeModelType = Root", "MultipleAntennaMultiplier = 0".

The EnableSignalDelay = False from SETIremoteTechConfig is again modified by the savegame stored value (overwritten since it is boolean, if it was number like the RangeMultiplier, it would simple get multiplied).

Stuff that is not changeable in game through the UI of remote tech is not stored in the savegame (eg ground stations).

 

The only thing left is, to implement a button (eg in the "start" tab of the rt in game ui) which says "Revert Manual Settings". By clicking it, it simply deletes all settings stored in the savegame, thus reverts to default + MM patches. The "presets" tab would be obsolete.

 

With this logic, mods would affect existing savegames without any further user input. But the player preferences are taken into account as well. For boolean values, the settings seen (and thus approved) by the player are dominant. For numbers, both are taken into account. And for settings not changeable by the ui, the mod settings are directly applied to existing savegames.

 

tl,dr: Settings are individually stored in the savegame after looking at them in the in game ui. They are then applied as if they were an MM patch, after the last MM patch. There is a revert button, which simply deletes all settings from the savegame file, so that only default + MM mod settings are used. Preset tab is removed.

PS: Sorry for the long post.

Edited December 4, 2016 by Yemo

[JadeOfMaar]

Howdy, all. Can someone explain this to me? I tested RemoteTech compatibility with Galileo's Planet Pack and I get extreme lag anytime this RT toolbar panel is open. I get Errors when it's opened, and Exceptions when I press a button in it and focus an RT-equipped vessel, but otherwise compatibility is confirmed. If it means anything, Kerbin and the other stock planets do not exist. They're supposed to not exist.

Edited December 4, 2016 by JadeOfMaar

[TaxiService]

14 hours ago, JadeOfMaar said:

Howdy, all. Can someone explain this to me? I tested RemoteTech compatibility with Galileo's Planet Pack and I get extreme lag anytime this RT toolbar panel is open. I get Errors when it's opened, and Exceptions when I press a button in it and focus an RT-equipped vessel, but otherwise compatibility is confirmed. If it means anything, Kerbin and the other stock planets do not exist. They're supposed to not exist.

I need a bug report on this error to narrow down to the offensive codes. Thanks!

[TaxiService]

Spoiler

21 hours ago, Yemo said:

Reading your post in the module manager thread and this one, I got an idea how to deal with custom settings/savegame settings:

1. RT default settings get modified by other mods through MM patches
2. The result of this is the "standard" and is used when creating a new game (up until this point, that is how it works at the moment).

The difference is, how and when manual player changes of settings are stored. At the moment all settings are stored in the savefile. I propose to only save "distinct manual settings" to the savefile. Like eg saving the delta v instead of the new velocity. This should practically depend on the setting in question.

For example, default RT setting is "RangeMultiplier = 1". The player has no other mods installed when starting a new game.
After starting a new game, (s)he manually changes the RangeMultiplier to 1.5 in the in game menu. RT thus adds a line in the savegame, eg "RangeMultiplier *= 1.5" (the *= is important for this setting).
After playing for some time, the player installs a mod, which uses MM patches to set the RangeMultiplier to 2 (because it eg provides an upscaled solar system).
After the mod is installed the player continues the existing savegame. Now here comes the difference on how manual changes are applied:

The basic RT settings is "RangeMultiplier = 1", this is modified by the mod to be "RangeMultiplier = 2" (which would thus be used for a new game). Since the savegame has the line "RangeMultiplier *= 1.5" stored, this is applied as if it were an MM patch, after the last MM patch (even after a :FINAL mm patch). So the RangeMultiplier is 3. From 1 (default) * 2 (mod MM patch) * 1.5 (from savegame).

The same goes for all the other settings which can be manually changed in game. The only question is, when the savegame should store values. Imho it should do so, once a player sees the value and acknowledges it (eg by not changing it).

For example the player has only remote tech installed and starts a new game. The player then clicks on "AlternativeRules", where the player sees the default values for "EnableSignalDelay = True", "RangeModelType = Standard" and "MultipleAntennaMultiplier = 0". The player changes RangeModelType to "Root" but does not change the other two options.
Imho this means that the player likes them the way they are. Thus after visiting this "AlternativeRules" screen, RT should store all three values ("EnableSignalDelay = True", "RangeModelType = Root" and "MultipleAntennaMultiplier = 0") in the savegame. If the player does not look at any other RT settings screens, these are the only 3 lines stored in his/her savegame regarding RT values.
After some time, the player decides to install SETIremoteTechConfig (which uses an MM patch to set EnableSignalDelay = False, but does not change the other two values).
So when the player resumes the existing game, this is what happens: Default RT settings
"EnableSignalDelay = True", "RangeModelType = Standard", "MultipleAntennaMultiplier = 0".
After MM patch from SETIremoteTechConfig:
"EnableSignalDelay = False", "RangeModelType = Standard", "MultipleAntennaMultiplier = 0".
After Savegame stored settings are applied:
"EnableSignalDelay = True", "RangeModelType = Root", "MultipleAntennaMultiplier = 0".

The EnableSignalDelay = False from SETIremoteTechConfig is again modified by the savegame stored value (overwritten since it is boolean, if it was number like the RangeMultiplier, it would simple get multiplied).

Stuff that is not changeable in game through the UI of remote tech is not stored in the savegame (eg ground stations).

 

The only thing left is, to implement a button (eg in the "start" tab of the rt in game ui) which says "Revert Manual Settings". By clicking it, it simply deletes all settings stored in the savegame, thus reverts to default + MM patches. The "presets" tab would be obsolete.

 

With this logic, mods would affect existing savegames without any further user input. But the player preferences are taken into account as well. For boolean values, the settings seen (and thus approved) by the player are dominant. For numbers, both are taken into account. And for settings not changeable by the ui, the mod settings are directly applied to existing savegames.

 

tl,dr: Settings are individually stored in the savegame after looking at them in the in game ui. They are then applied as if they were an MM patch, after the last MM patch. There is a revert button, which simply deletes all settings from the savegame file, so that only default + MM mod settings are used. Preset tab is removed.

PS: Sorry for the long post.

 

I discussed with my team over this delta-v idea and setting-related matters. Here're the outputs:

1) Thanks to your feedback, I edit the RT's preset window to clarify better. The "default" word is awkward and nonsense, given we switched to MM patches.

2) Given the RT 1.x branch is now under the bug-fixing maintenance and the delta-v idea is complicated, this idea consideration is postponed to the RT 2.x redevelopment. I expected that the setting set of each independent module of RT 2.x will have an unique name for MM patches targeting the module. The whole preset feature should be gone when a new button is added to revert to the starting settings.

3) For your SETI RemoteTech config, I think your MM patch is sufficient, given we re-worded to the "starting settings" phrase.

Edited December 5, 2016 by TaxiService

[LostOblivion]

On 4.12.2016 at 3:18 PM, TaxiService said:

Assumed you want to retain the RT parts to prevent KSP from automatically deleting your vessels with would-be-deleted RT parts, remove everything inside GameData/RemoteTech folder except for the Parts folder you want to retain.

However, there are couple effects of this removal:

1) the RT parts will be "cosmetic" parts
2) You need to edit this "EnableCommNet = False" in your persistent.sfs to enable CommNet back.

P.S. Make a backup of your save first so that you can undo any accidental destruction

Great, thanks. Are there any patches for the RT parts that puts them in the stock system?

Edit: Nevermind, I didn't find any online, but figured my save only used two of the RT antennas, so I made two MM patches for them based on the new stock surface antenna and the DTS-M1.

+PART[SurfAntenna]
{
    %name = RTShortAntenna1
  %MODEL
  {
    %model = RemoteTech/Parts/ShortAntenna1/model
  }
  -mesh = none
  %scale = 0.1
    %specPower = 0.1
    %rimFalloff = 3
    %alphaCutoff = 0.5
  -rescaleFactor = 1
  %node_attach = 0.21, 0.0, 0.0, 1.0, 0.0, 0.0
  %title = Reflectron DP-10
    %manufacturer = Parabolic Industries
    %description = When moving this antenna to a test site, engineers always forgot to turn it on. Frustrated with having to walk back and forth, they had this antenna be active by default.
  %attachRules = 0,1,0,0,0
  %mass = 0.015
}
+PART[mediumDishAntenna]
{
    %name = RTShortDish2
  %MODEL
  {
    %model = RemoteTech/Parts/ShortDish2/newss5
  }
  -mesh = none
    %scale = 0.1
    %specPower = 0.1
    %rimFalloff = 3
    %alphaCutoff = 0.5
  -rescaleFactor = 1
  %node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0
  %node_attach = 0.0, -0.225, 0.0, 0.0, -1.0, 0.0
  %title =  Reflectron KR-7
    %manufacturer = Parabolic Industries.
    %description = Locals complained about their missing garbage lids, so our engineers quickly developed an alternative. Matching performance with the SS-5 for only double the cost!
  %attachRules = 1,1,0,0,1
  %mass = 0.05
}

Even though I'm switching to the stock system now...thanks for making this mod, can't wait to try out version 2.0!

Edited December 5, 2016 by LostOblivion

[Calvin_Maclure]

I have a very quick question about a tiny detail I wanted to confirm. When the dish ranges are displayed in the VAB, is the ''G'' in ''Gm'' really ''Giga'' as in 10^12 meters (so Mm = 10^6 / Bm = 10^9 / Gm = 10^12)?

Thanks very much. 

[neitsa]

16 minutes ago, Calvin_Maclure said:

I have a very quick question about a tiny detail I wanted to confirm. When the dish ranges are displayed in the VAB, is the ''G'' in ''Gm'' really ''Giga'' as in 10^12 meters (so Mm = 10^6 / Bm = 10^9 / Gm = 10^12)?

Thanks very much. 

Yes the "Gm" is for gigameter but 1 Gm is 1 billion  meters (1*10^9)

[Errol]

I'm trying to learn how to do this new "translate to MM patch" method for defining some ground stations. I have no idea what I'm doing though. Here is the data I want to use, in .cfg form: (it is from an older mod)

 

RemoteTechSettings
{
	ConsumptionMultiplier = 1
	RangeMultiplier = 1
	ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2
	SpeedOfLight = 3E+08
	MapFilter = Omni, Dish, Path
	EnableSignalDelay = True
	RangeModelType = Standard
	MultipleAntennaMultiplier = 0
	ThrottleTimeWarp = True
	ThrottleZeroOnNoConnection = True
	HideGroundStationsBehindBody = False
	DishConnectionColor = 0.9960784,0.7019608,0.03137255,1
	OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1
	ActiveConnectionColor = 0.6588235,1,0.01568628,1
	GroundStations
	{
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
			Name = Mission Control
			Latitude = 28.608389
			Longitude = -19.7
			Height = 75
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 7.5E+07
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc489
			Name = DSN 1
			Latitude = 0.1538
			Longitude = 40.4517
			Height = 1300
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48a
			Name = DSN 2
			Latitude = -10.4810
			Longitude = 160.3784
			Height = 400
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48b
			Name = DSN 3
			Latitude = 7.3389
			Longitude = -69.7412
			Height = 200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48c
			Name = Polar Launch Station
			Latitude = -42.1875
			Longitude = -18.8965
			Height = 600
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48d
			Name = Eastward Launch Station
			Latitude = 29.0698
			Longitude = 12.6123
			Height = 1200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
	}
}

I know there is a MM handbook, but I am not a programmer and don't know how to make heads or tails of that stuff. Do I just copy all of this into a new file with a @ at the beginning of each line?

EDIT:

This is what I've modified it to so far:
 

@RemoteTechSettings:FOR[HarderSolarSystem1]
{
	@RangeModelType = root
	@MultipleAntennaMultiplier = 1
	@HideGroundStationsBehindBody = true

	!GroundStations,*{}
	GroundStations
	{
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
			Name = Mission Control
			Latitude = 28.608389
			Longitude = -19.7
			Height = 75
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 7.5E+07
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc489
			Name = DSN 1
			Latitude = 0.1538
			Longitude = 40.4517
			Height = 1300
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48a
			Name = DSN 2
			Latitude = -10.4810
			Longitude = 160.3784
			Height = 400
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48b
			Name = DSN 3
			Latitude = 7.3389
			Longitude = -69.7412
			Height = 200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48c
			Name = Polar Launch Station
			Latitude = -42.1875
			Longitude = -18.8965
			Height = 600
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48d
			Name = Eastward Launch Station
			Latitude = 29.0698
			Longitude = 12.6123
			Height = 1200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
	}
}

The game freezes during main loading screen on module manager patching for RT giga dish when this .cfg is in the game data folder. Obviously I've done something wrong....

EDIT2: I got it working by giving up on the MM method and just directly editing my extra ground stations into the remote default cfg. Game loads now and I have my extra stations.

Edited December 7, 2016 by Errol

[TaxiService]

Spoiler

15 hours ago, Errol said:

I'm trying to learn how to do this new "translate to MM patch" method for defining some ground stations. I have no idea what I'm doing though. Here is the data I want to use, in .cfg form: (it is from an older mod)

 

RemoteTechSettings
{
	ConsumptionMultiplier = 1
	RangeMultiplier = 1
	ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2
	SpeedOfLight = 3E+08
	MapFilter = Omni, Dish, Path
	EnableSignalDelay = True
	RangeModelType = Standard
	MultipleAntennaMultiplier = 0
	ThrottleTimeWarp = True
	ThrottleZeroOnNoConnection = True
	HideGroundStationsBehindBody = False
	DishConnectionColor = 0.9960784,0.7019608,0.03137255,1
	OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1
	ActiveConnectionColor = 0.6588235,1,0.01568628,1
	GroundStations
	{
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
			Name = Mission Control
			Latitude = 28.608389
			Longitude = -19.7
			Height = 75
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 7.5E+07
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc489
			Name = DSN 1
			Latitude = 0.1538
			Longitude = 40.4517
			Height = 1300
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48a
			Name = DSN 2
			Latitude = -10.4810
			Longitude = 160.3784
			Height = 400
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48b
			Name = DSN 3
			Latitude = 7.3389
			Longitude = -69.7412
			Height = 200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48c
			Name = Polar Launch Station
			Latitude = -42.1875
			Longitude = -18.8965
			Height = 600
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48d
			Name = Eastward Launch Station
			Latitude = 29.0698
			Longitude = 12.6123
			Height = 1200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
	}
}

I know there is a MM handbook, but I am not a programmer and don't know how to make heads or tails of that stuff. Do I just copy all of this into a new file with a @ at the beginning of each line?

EDIT:

This is what I've modified it to so far:
 

@RemoteTechSettings:FOR[HarderSolarSystem1]
{
	@RangeModelType = root
	@MultipleAntennaMultiplier = 1
	@HideGroundStationsBehindBody = true

	!GroundStations,*{}
	GroundStations
	{
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488
			Name = Mission Control
			Latitude = 28.608389
			Longitude = -19.7
			Height = 75
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 7.5E+07
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc489
			Name = DSN 1
			Latitude = 0.1538
			Longitude = 40.4517
			Height = 1300
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48a
			Name = DSN 2
			Latitude = -10.4810
			Longitude = 160.3784
			Height = 400
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48b
			Name = DSN 3
			Latitude = 7.3389
			Longitude = -69.7412
			Height = 200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+12
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48c
			Name = Polar Launch Station
			Latitude = -42.1875
			Longitude = -18.8965
			Height = 600
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
		STATION
		{
			Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc48d
			Name = Eastward Launch Station
			Latitude = 29.0698
			Longitude = 12.6123
			Height = 1200
			Body = 1
			MarkColor = 0.996078,0,0,1
			Antennas
			{
				ANTENNA
				{
					Omni = 1E+06
				}
			}
		}
	}
}

The game freezes during main loading screen on module manager patching for RT giga dish when this .cfg is in the game data folder. Obviously I've done something wrong....

EDIT2: I got it working by giving up on the MM method and just directly editing my extra ground stations into the remote default cfg. Game loads now and I have my extra stations.

 

Almost correct. Apparently the previous RT 1.x developer used a different name for the root range model. It is "Additive" not "Root". RangeModelType is sensitive so 

@RangeModelType = Root

And your MM patch works on my side.

 

Edited December 7, 2016 by TaxiService
Updated

[TaxiService]

 

RemoteTech 1.8.3 for KSP 1.2.2 released

This release 1.8.3 is minor, containing one bug fix and few improvements.

What are fixed:
The engineer report should correctly read an antenna's electricity consumption in the editor
A variable of crew control is added to command/probe modules for third-party modders

Complete changelog is below:

Spoiler

What's New?
===========

* Add a crew-control variable to SPU module [#558]
* Simplified fix for science data transmission [#667]
* Clarification of whole default settings [#700]
       Please see: http://remotetechnologiesgroup.github.io/RemoteTech/modders/settings/
* Fix to the engineer report's electricity consumption [#707]

Detailed Changelog
==================

Fixed Issues
------------

* Issue #558: ModuleSPUPassive removes control from probe cores [requested by: Y3mo]
* Issue #667: Antennas don't transmit science in 1.1.2 [requested by: Kyoyashi]
* Issue #700: Rework Settings storage mechanism [requested by: YamoriYuki]
* Issue #707: 1.8.2 Antenna Ec usage not displayed in VAB [requested by: muppet9876]

Pull Requests
-------------

* PR #709: Rework fix for #667 [PR by: neitsa]

Future
-------------

We are already moving to make the next RT major release.

Issues and feedbacks are still welcome!

If you find any bug, please report them on our github (as it is hard to keep track of bugs here). Feedback is also welcome for the next release, here or on this github post.

We are continuing the 2.x development. We, however, still will fix any urgent issue found in RT 1.x branch.

 

---

RemoteTech 1.7.2 for KSP 1.1.3 released

This release 1.7.2 includes the critical fix to the science transmission bug from the 1.8.x branch. It is for KSP 1.1 players whose mods are not updated to KSP 1.2 yet.

What are fixed:
The science transmission bug (no effect upon the completion) is fixed
No NullReferenceException spam when transmitting science

Complete changelog is below:

Spoiler

What's New?
===========

Note: This is a maintenance release with back-ported patches from the 1.8.x branch

* Antenna range multiplier option slider is no longer snapped to 0 or 1. [#594]
* Fixed a NRE spamming issue while transmitting science. [#613]
* Fixed an old bug when science didn't transmit correctly despite UI displaying that 100% was transmitted. [#667; #675]
* Option sliders (in option window) are rounded to 2 decimal places.

Note: This is a maintenance release with back-ported patches from the 1.8.x branch. 

Edited December 10, 2016 by TaxiService

[Stone Blue]

@RT Dev Team, thanx for the update... The team is moving at an awesome pace on maintenance AND new feature dev...Thanx

AND, a BIG THANK YOU, for back-porting a release for 1.1.x... Lots of us still play 1.1.3, till 1.2.x gets finalised.. :thumbs_up:

[The-Doctor]

Is a version for 1.2.2 being worked on?