Yemo

I dont really understand why there could not be a default behaviour when starting a new game with both installed. And then players could switch manually when they want something different than the default "integration". If every two mods which could be played together needed a "simple" profile change to interoperate, it would take hours of clicking and reading up to set up a decently modded ksp install. Every time something changes (ksp patch, new mod installs, etc.). Default compatibility/integration makes ksp modding work.

Would it be possible to make this automic? Eg if Kerbalism and TAC Life Support is intalled, that the resource management (Food, Oxygen?) of Kerbalism deactivates itself automatically and that part of life support is "taken over" by TAC life support (Food, Oxygen, Water). That would simplify a lot and reduce (install) issues, for those who really appreciate Kerbalism but are simply to accustomed to TAC life support and the integration for planet bases and so on, which it provides.

Unmanned before Manned v1.2.1.0 (for KSP 1.2.x) After watching the painfully unbalanced Galileo Conquest video from Scott Manley: Due to unsupported parts (SXT), no science adjustments as recommended, etc: Temperature and Barometer experiments adjusted to SETIrebalance values Materials Bay earlier at basicScience, to allow probe only progression SXT mystery goo to the place of stock mystery goo Most problematic early SXT engines moved to more appropriate nodes considering their stats Early stock landing gear moved to start if SXT is installed... Porkjet new Mk1 pod moved to the place of the 1 kerbal lander can (since this pod is the most problematic part) SETI RemoteTechConfig v1.2.1.0 (for RemoteTech 1.8.2+) Just config modding adjustments for RemoteTech 1.8.2 settings format Needs MM to be able to influence RT now, but RT itself needs MM, so no need to provide it in the download

Great idea! One question: Do you intend to release your own contract pack or do you intend to work on the SETI contract mod? If the latter: It is not on github, but you would be essentially the only one working on SETIcontracts, so I could either upload it to github or you could send me the files. If the former: I m not really working on SETIcontracts anymore, only maintaining them until a viable (small, unmanned first) alternative comes along, which ideally works for multiple planet packs. @Nori wanted to work on a general contract progression, which works for new horizons and stock, but afair, it was not released. So if you go this route, you are welcome to use the stuff within the contracts, either for reference or as a base or whatever. My only stipulations would be, to change all the values which could lead to conflict with the existing SETIcontracts pack (and thus lead to support issues). That would be the 1. name/group especially the SETI name to prevent confusion about support (and SETIcontracts in mm statements/folders and such), 2. agency (space exploration technology initiative), 3. contract names (not titles), eg name = OrbitRecovery group = SETIcontracts title = 03.1 Orbit & Recovery! the name and group should be changed, the title is just what is displayed, so no problems with using that, and 4. variables for behaviours and requirements, eg BEHAVIOUR { name = Progression type = Expression CONTRACT_COMPLETED_SUCCESS { setiOrbitRecovery = 10 } } and REQUIREMENT { name = Progression type = Expression title = Completion of "Orbit around Kerbin!" contract expression = setiOrbit == 10 } Other than those 4 (or any other functional/name things which might cause functional/support issues) feel free to work with the actual content. Just name me as a contributor. From my perspective, it would be great if your contract pack would work in stock (and perhaps other solar systems) as well. I would then just recommend your contract pack, and would not have to continue maintaining SETIcontracts. Which would allow me to spend more time on other stuff, where there is no viable alternative at the moment (SETIrebalance). Whatever you decide, good luck and endurance!

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.

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.

@neitsa, @TaxiService Unfortunately rl caught up with me on the weekend, so I could not check it out earlier. About the 1.8.2 functionality: All works well when I start a new game. However when eg I start a game only with remote tech and then later want to add additional ground stations using the example config from the for modders help page, there is no apparent option to do so. I can go to "presets" and overwrite, which does the thing I want it to do, but for players unfamiliar with the workings, it looks like that there is only the option to overwrite with the default remote tech settings (thus not the MM added ground stations which is actually done). About the 2.0 feature poll There are two simple axes to rate many of the opinion features: complex vs simple and hard vs easy 1. For the first one, the preference for default implementation is "simple" for obvious reasons. One just has to look at stock commnet to figure out why a complex range model is a bad idea. You need a spreadsheet/calculator to know about the range of two dishes communicating with each other, if one of them is not KSC (for which the values are displayed in the right-click context menu of the part). Therefore I hope no one plans on making #115 square cube law the default rule... 2. The preference for hard vs easy as a default is a matter of personal preference. Until now, the default was "hard", since people who wanted it easy would use antenna range (or non) anyway. And people who wanted something in between antenna range and "hard" remote tech could do that by changing the config, manually or by installing mods. Since you plan to make the flight computer separate anyway and stock commnet exists, I see no reason to change that. The worst thing you could do, is making the default a mix of hard and easy so that everyone has to adjust rt settings and check all the time whether there is a majority driven change of the defaults again. Commnet + FC = simple, RT = hard by default (signal delay, only ksc, need to point antennas, no connection = no control even over antenna, etc). Of course rt can do the opposite and start simple and people have to tweak it to make it harder. But then go to the other extreme (no signal delay, many ground stations (or the whole planet as ground station), all omni antennas, need connection only to transmit science, etc). Making anything in between the two extremes the default will result in perpetual uncertainty and confusion, when the default depends on the flavor of the month majority/maintainer opinion. And (video/written) guides/playthroughs will always be out of date, adding to the confusion.

You could start small by implementing a very confined set of changes. Or you could take a look at abandoned (plugin) mods and try to reivive one, which happens quite often. RemoteTech is in the process of changing, but that is perhaps not something for starters. If you are interested in making very small plugins, there are two mod requests I have which have not been implemented as far as I know: 1. Make all kerbals have full experience from the start (upon bein recruited and upon being rescued). Since exerperience is questionably balanced in ksp, it would be great if it could be removed. There is no reason why a cosmonaut needs to fly to another celestial object to learn to repair rover wheels... There are mods which deal with experience already, but non which simply "deactivates" it by giving all the experience at the start: 2. Bring back the subassemblies category to the main category screen instead of hiding it behind an additional click (enable advanced mode - top left corner) in the VAB/SPH. There are mods dealing with custom categories, yet I m not aware of any which brings back the subassemblies button where it belongs.

I prefer RemoteTech, because with CommNet, you need an elaborate spreadsheat for everything more complicated than a single dish directly communicating with kerbin. And with mods (eg SETIremoteTechConfig, SETIprobeControlEnabler), remote tech has multiple ground stations, and only needs a connection to transmit science. Signal delay can be turned off as well. And for the next version of remote tech, I plan to release another mini-mod, which removes the necessity to manually point remote tech dishes... However I do miss some of the CommNet features, hopefully they get integrated into remote tech in the future.

Note that SETIremoteTechConfig is outdated at the moment and might need some more fixes. Did you edit that one directly? Not sure if MM patches work at the moment.

Yep, that was exactly my problem with SXT so far. I ll take a look at the Janitors Closet, looks great. Answered in RemoteTech thread, if anyone else experiences this issue.

@TaxiService I m only back at the pc where ksp is installed at the end of the week, so I can not test it at the moment. About the order of MM patches: The standard MM ordering described in its wiki is only useful for a very small number of known mods working on the same values. It does not work well for multiple mods, especially if a mod author does not know all the other ones (eg because they do not exist yet). Therefore the zz, zzzz scheme outlined in my post is highly recommended. With that one, mod authors only have to keep track of other mods working on the same z level. Which is easier because many same level mods are mutually exclusive to begin with and the ones that are not usually adjust for that anyway (eg NewHorizons, OuterPlanets). The double z spacing offers modularity for the future. With regards to the test config, it needs an additional line to delete the existing ground stations before filling in the new ones, in order to not double the Mission Control entry or create other issues with it (I can not test at the moment, but that should do it, included in line 3: "!GroundStations,* {}"): @RemoteTechSettings:FOR[TestMod]{ %EnableSignalDelay = False !GroundStations,* {} 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 } } } } } @NemesisBosseret In the example config above, the stations have the line "Body = 1", as do the ones in the SETIremoteTechConfig. I have no idea why or how Kopernicus interacts with that. Since your screenshots have a "Kerbin" as well, that looks like an issue with kopernicus or the the solar system mods you have installed.

@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.

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.

I agree that the former logic of loading settings was not optimal. Unfortunately the current logic is kind of deal-breaking for me as a modder, especially in terms of mod support. I remember the days when you needed the tech manager plugin to load non-stock tech trees. KSPI used to have its own tech tree, and thus players needed to choose from 4 simple options upon game start, without proper defaults. You would not believe the number of botched setups resulting from this. From my experience, the default upon new game start must be a direct result of installed mods, without any special user interaction in-game. This drastically decreases support issues and if there are support issues, a screenshot of the GameData folder (and perhaps of the ContractPacks sub folder) provides all the information needed for 95+ % of the issues. This is especially true for RemoteTech, with all its mod interactions. Eg. RealismOverhaul and SETIremoteTechConfig change the complete default settings. And other mods might make additional changes on top of that. For example OuterPlanetsMod, NewHorizons and the different Kerbin resize mods might multiply the stock/RealismOverhaul/SETIremoteTechConfig range settings by some factor, to account for the different solar system distances. Thus imho the current logic needs to be changed to something like this (and perhaps the non-stock configs need to be changed as well for that to work properly): 1. All FULL SETs of remoteTech settings found in the GameData folder (eg stock RemoteTech settings, Realism Overhaul, SETIremoteTechConfig) are separately written into the game database upon ksp loading. 2. Each FULL SET of remoteTech settings can then be modified by module manager patches upon ksp loading. For example a kerbin rescale mod could increase the range of all ground stations, both for the stock RemoteTech settings, as well as for the SETIremoteTechConfig, since both are stored separately in the game database and can thus be modified separately by MM patches. 3. The result are possibly multiple MM modified presets, which are available through the in-game remote tech menu. 4. There needs to be a logic to determine which of those MM modified presets takes precendence when a new game is started. With those 3 I know of, it should be RealismOverhaul > SETIremoteTechConfig > stock RemoteTech settings. Since the latter 2 are pretty useless in a Sol/Earth sized world and between the latter two, installing SETIremoteTechConfig is a clear indication that those settings are preferred over stock RT settings for a new game. There should be the possibility to have a private remote tech settings file which takes precedence over all of the 3, similar to the :FINAL statement of module manager. We could simply add a "Precedence" flag in the settings files. Stock RemoteTech settings have precedence = 0, SETIremoteTech uses precendence = 5, Realism Overhaul remote tech config has precedence = 10, a private rt settings file would use something like precedence = 20 or so. This would only be used to determine the default config when a new game is started. 5. The resulting mm modified default config (the one with the highest precedence flag from (4.) can then be adjusted by the player per in-game menu and is then stored in the savegame. 6. The savegame stored config is not altered without user input during an existing game. Thus if the user installs eg SETIremoteTechConfig during an existing game, (s)he must select the MM modified SETIremoteTechConfig preset through in-game menu to use it and thus overwrite the previous settings stored in the savegame. This could imho be the basic logic, providing a framework for full RT settings modders (private and public), solar system modders (OPM, NewHorizons, RealSolarSystem, Kerbin resizes), as well as users who use savegame specific in-game settings.

@tomek.piotrowski, @neitsa I used the new RT 1.8.1 default config as a base for my SETIremoteTechConfig and ported over all the changes. Unfortunately none of the changes affect the settings when starting a new game. Signal delay is still on, the additional ground stations are not displayed and so on. The SETIremoteTechConfig changes are simply ignored by RemoteTech. //---This is the SETI config for RemoteTech, adding ground stations, setting signal delay to false and tweaking colors //---Authors: Yemo //---Contributions: frango9000 //---SETI forum thread: http://forum.kerbalspaceprogram.com/threads/106130 //---RemoteTech forum thread: http://forum.kerbalspaceprogram.com/threads/83305 //---License (except for the names, ground station positions and the version file, which are AllRightsReserved): GPL version 2 (as RemoteTech itself): http://www.gnu.org/licenses/old-licenses/gpl-2.0.html RemoteTechSettings { RemoteTechEnabled = True CommNetEnabled = False ConsumptionMultiplier = 1 RangeMultiplier = 1 MissionControlRangeMultiplier = 1 ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2 NoTargetGuid = 00000000-0000-0000-0000-000000000000 SpeedOfLight = 3E+08 MapFilter = Omni, Cone, Path EnableSignalDelay = False RangeModelType = Standard MultipleAntennaMultiplier = 0 ThrottleTimeWarp = True ThrottleZeroOnNoConnection = True HideGroundStationsBehindBody = True ControlAntennaWithoutConnection = True UpgradeableMissionControlAntennas = False HideGroundStationsOnDistance = True ShowMouseOverInfoGroundStations = True AutoInsertKaCAlerts = True FCLeadTime = 180 FCOffAfterExecute = False DistanceToHideGroundStations = 3E+06 DishConnectionColor = 0.9960784,0.7019608,0.03137255,1 OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1 ActiveConnectionColor = 0.6588235,1,0.01568628,1 RemoteStationColorDot = 1,0,0,1 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 } } } } PreSets { PRESETS = SETIremoteTechConfig/RemoteTech_Settings } }

Hm, I really have to take a closer look at MFT! Those are entryCosts, which are extremely unbalanced in stock. They seem to be set according to the parts position in the stock tech tree. So a simple adapter, which for some reason is placed very late in the stock tech tree, has very high entry costs. Unfortunately those entryCosts are a part of the stock "difficulty" presets. Which themselves are about as gameplay balanced as the stock tech tree. In effect the "difficulty" presets are mostly a "grindiness" slider. So anyone interested in real gameplay balance (as I infer from installing SETIrebalance) does not use those unbalanced presets. The entry cost option is a simple money sink for unlocking parts. And since the stock entry Costs are based on the stock tech tree positions, but a balanced gameplay would use anything but the stock tech tree, the stock entry costs make no sense. But, I agree that 1000 flat is not optimal. Though I m not sure what is, while still being easy to implement for that niche specific money sink option. Perhaps 1, Parts in "fuel" category have entryCosts of 0 2. Every other part is set to have entryCosts equal to a faktor times costs.

Ah, then I simply missed how to do it. Will remember for the future. Thank you very much!

No, since I uploaded a new version, I could now delete 1.2.0.2 on my own, just for the future a button to delete the newest version and thus revert to the previous version. I wanted to upload a new version for Unmanned Before Manned (1.2.0.1). Unfortunately with many tabs open and UbM and SETIrebalance both being version 1.2.0.0, I uploaded the new UbM zip file on the SETIrebalance page of spacedock.info. When I noticed my error, I could not simply delete the wrongly uploaded file for SETIrebalance. I had to upload another version for SETIrebalance (1.2.0.2), to be able to delete the wrongly uploaded file. Including updating the version file and so on. Hm, the problem is, that SETIrebalance does not provide a change to all reaction wheels eg the ones introduced by mods which are not yet fully supported. Instead it rebalances reaction wheels individually. For example the probe core reacction wheels are pretty much what the stock probe cores have (but the probe core masses were often adjusted), while the larger ones are drastically nerfed, but always corresponding to the mass of the part (or more precisely the mass of the reaction wheel sub-component if the part has multiple functions). My rebalancing guideline was afair 2 torque for 200kg and 1EC/s, to keep it simple. So it is a trade-off at the moment. If you have many reaction wheels which are not touched by SETIrebalance, you might want to simply delete the SETIrebalanceReactionWheels folder and apply the all-inclusive nerf.

No problem ;-). I ll perhaps look into it some time in the future. Hm, then it looks like an issue with CC or something else entirely. I would redownload KSP and then install the latest CC and work from there, to avoid any hidden issues, eg previously compromised files. Good luck! Whoops, must have missed it when I uploaded the last version, corrected it. Thank you very much! PS: It would be great if the lastest mod version could be deleted on spacedock.info to revert. At the moment I only see the functionality to delete an older version. SETI Rebalance v1.2.1.0 (for KSP 1.2.x ) EntryCosts all set to 1000 instead of 1, thank you very much @nobodyhasthis2 Minor fixes I went with 1000 for the moment, to avoid too problematic imbalances in the early career with all the plane parts. For the future it might be possible to adjust that based on tech tree unlocks. Though since I (slowly) started working on SETItechtree again (as converting UbM was imho just not worth the issues, for a stop gap solution), I m hesitant to introduce such complexity for SETIrebalance at the moment.

That sounds like a great idea! Is it possible to use diminishing returns instead of a hard cap? For example the first experiment while "landed on the mun" gives full reward. The second landed on mun (in a different biome) gives 80%, the third one 64% and so on. Each "same body, same situation, but different biome" provides only 80% compared to the one before. More complex to implement, but soft caps feel more "natural" than hard caps in this instance and leave the player with a series of relevant choices along the line instead of a sharp cut-off.

For example the new LV-909 is currently very OP, as far as I can tell. Also the part upgrade functionality is problematic for craft sharing. Also the old parts look great, once VenStockRevamp is installed, so there is no visual incentive to fully replace the old ones. I m thinking about using both sets, but only the "upgraded" values for the new porkjet parts, to be unlocked later than the current stock/Ven equivalents. But that requires some work with SETIrebalance. Thank you! I'll include the additional field from the new default settings cfg within the next SETIremoteTechConfig! Hm, then I could deactivate the TankContentSwitcher module manager config if MFT is installed. Though I really do not want to miss the balancing changes... Any help is greatly appreciated, since I have too little experience with MFT myself. SETI Contracts v1.2.1.0 (for KSP 1.2.x) Fixed deactivation of stock exploration contracts, thank you very much @Sol Invictus & @nightingale Added numbering scheme in contract titles SETI Greenhouse v1.2.1.0 (for KSP 1.2.x) Fixed TAC-LS converters, thank you very much @Lant Please note that the current TAC-LS 0.12.6 does not recognize the conversion rate So until that is updated, the big greenhouse will only produce as much as the small one

Ah, now I remember, I left some in for compatibility and just never removed them since there was no issue. But I did not know about the renaming of ExploreBody to ExplorationContract. Will correct this in the next SETIcontracts release. Thank you very much!

I checked the stock contract config file and the names seem to be different from the ones specified in the contract configurator wiki: https://github.com/jrossignol/ContractConfigurator/wiki/Miscellaneous Specifically, "WorldFirstContract" does not exist in the stock "Contracts.cfg", but there is an entry called "Progression". "ExploreBody" does not exists as well, and I do not see an equivalent in the stock Contracts.cfg. Neither does "RecordTrackContract". Those are the 3 contract types specified within SETIcontracts to be deactivated, as specified in the cc wiki: CONTRACT_GROUP { name = SETIcontracts displayName = SETI Contracts minVersion = 1.7.3 disabledContractType = RecordTrackContract disabledContractType = ExploreBody disabledContractType = WorldFirstContract } Maybe squad changed the stock contracts again?

Hey, quite some time ago, the green sub-assemblies-button in the VAB/SPH was prominently displayed with the other categories. Then it was hidden by squad behind another click and this very useful tool was used less by players, many new players do not even know about it. Can anyone please make a mod which puts this button below the main categories, as it used to be? Thank you very much!