Yemo

@Anthras Since RemoteTech is not officially updated for 1.1.3, I m not sure about possibly temporary issues. I tested with RemoteTech dev build 554 manually installed and otherwise all mods recommended and suggesed by UbM ckan install and found no issues. Not sure why the ksp 1.1.3 compatible RT dev build is not working for you.

Well, after pm-ing with @tjt , I thought that people still playing 1.0.5 careers would also benefit from the DP-10 fix, so I just updated SETIrebalance for 1.0.5. That gives everyone the choice whether they want the new CustomBarnKit functionality from above, when SETIrebalance for ksp 1.1.3 is released, without having to forgo the DP-10 fix. SETI Rebalance v0.9.6.6 (for KSP 1.0.5 , works fine with 1.1.x) Fixes: DP-10 from RemoteTech Starts deployed Gap removed

It seems that I accidentally included the wrong (not final) craft files in UbM 1.0.9.0. I made some further changes to them and updated to 1.0.9.1. Since ckan does not like changing file names, I had to keep the slight naming errors for A5 and A6 (one space too much). Unmanned before Manned v1.0.9.1 (for KSP 1.1.x) Craft file fixes DP-10 on all craft changed to start deployed Added small inline reaction wheel to A4 - A6 Replaced LV-T30 with LV-T45 on A5 and A6 plus other adjustments (winglets) Added A7 Manned Orbiter Tech Tree changes kOS CX-4181 Scriptable Control System to start node The kOS change is not final, but does not give an unfair advantage anyway. I ll come back to that when kOS changes. For SETIrebalance I decided to split the planned update. Most of the planned changes can wait a bit longer, so that I can push out an update much earlier. Specifically making the DP-10 start deployed again, unlocking action groups from the start with the new CustomBarnKit and utilizing some of the other new CBK capabilities. The new CBK allows the change of the number of building levels. My current plan is, to add some levels to Launch Pad and R&D. Eg R&D would have 7 levels: @RESEARCH { @levels = 7 @upgradesVisual = 1, 3, 5 @upgrades = 56000, 113000, 225000, 451000, 902000, 1804000, 3608000 @dataToScienceRatio = 1, 1, 1 @scienceCostLimit = 30, 80, 150, 280, 500, 900, -1 @unlockedFuelTransfer = 1 } Not sure about the Launch Pad values: @LAUNCHPAD { @levels = 7 @upgradesVisual = 1, 3, 5 @upgrades = 10000, 19000, 38000, 75000, 148000, 282000, 550000 @craftMassLimit = 9, 18, 36, 72, 140, 280, -1 @craftSizeLimit { @size = 3, 10, 3 @size = 5, 20, 5 @size = 6, 28, 6 @size = 7, 36, 7 @size = 9, 48, 9 @size = 12, 60, 12 @size = -1, -1, -1 } } Any input on that is very welcome! It would affect ongoing careers, but with alt+12 and holding alt, the difference in funds is easily corrected.

@sarbian and @politas effectively pulled/deactivated the installation of all mods with module manager dependency from ckan. edit: So since sarbian did the request and politas simply acted on it according to new policy, sarbian now decides if mods with MM dependency are allowed/installable via ckan, CTT included. This is just an explanation why CTT is not available via ckan as you asked, for more info, go to one of the threads about ckan.

Yeah, I roughly followed that development. Seems like one of my main reasons why I was still modding ksp, the relatively low toxicity of the community (with some exceptions), has ceased to exist. Well, time to go on indefinate hiatus again. I ll still check back to see where this goes and do the occasional update, but I guess it is time to move on in terms of my main modding focus. With the recent update, the mod support data (.version files and so on) seems to be in pretty good shape for that as well.

Oh, and if anyone notices a mission report/youtube/twitch playthrough with the new UbM version or has some feedback, please post it here. I m very interested to know how other people cope, especially with the new early game "challenge".

My advice is, to take it one step at a time and since you are coming from flight sims, make checklists and written plans. And then correct them. And so on. eg checklist: Sufficient dV, good TWR, vessel control (gimbal, reaction wheels), enough batteries, enough solar panels, fins for stability in atmo And then one step at a time. If you can not reliably reach orbit, going to the mun is premature. And if you can not reliably design a rocket which can reach space at an inclination without tumbling, trying to orbit is premature. One learning step at a time instead of trying to do everything at once only to be frustrated.

Unmanned before Manned v1.0.9.0 Massive changes to early progression Materials Bay much later @ miniaturization Mystery Goo even later @ precisionEngineering This makes early science progression much more predictable It also makes early science progression much more challenging It is recommended to send some simple probes to other planets early on Just like it was done in reality Inclusion of some craft files Due to the increased difficulty for early game science point generation They are adjusted for the usage with VenStockRevamp, RealChute and RemoteTech SETIrebalance highly recommended, especially until RemoteTech dish masses are updated TechTree cost changes generalRocketry 20 instead of 16 survivability 16 instead of 24 Other part placement changes RT-10 solid booster later @ basicRocketry KR-7 from RemoteTech earlier @ engineering101 SnubOTron from VenStockRevamp earlier @ basicRocketry 1.25m Fairings earlier @ stability Moved mystery goo only to precision engineering. Since I had to change the folder structure, there might be install issues (ckan and manual). Please check and report them here so that I can sort them out.

That cockpit and those swept wings are really problematic for CoM/CoL balancing, but together they are a pain [...] and lead to something like that. At least kerbals can enter/exit with that design.

With Unmanned Before Manned becoming more challenging in the early game stages, I decided to provide some craft files. Except for the basic jet, most are built for VenStockRevamp + RealChute + RemoteTech (and SETIrebalance). UbM Basic Jet (completely stock) Looks funny, but has balanced CoM and CoL, and provides opportunity for upgrades/addons. >>>Link to kerbalx page<<< edit: To take off from the dirt runway, you simply set throttle to max and keep "S" pushed. It is designed to then take off without requiring any other input/correction.

Based on the suggestions by @nobodyhasthis2, I digged through the ksp-avc and and ckan algorithms concerning versioning. The problem with ksp-avc is, that if the max version is lower than the current ksp version, every such mod generates an error message. But if there is no max version specified in the .version file (so if there is only a ksp version, but not a max ksp version), it lumps all the "outdated" mods together in one error message and displays the mod yellow. If the max KSP version is just set to 1.99.99, there is no error message and no color indication that the mod is outdated. => Thus for KSP-AVC it is preferential only specify a ksp version and simply delete the max ksp version entry. It is different for CKAN. If CKAN detects a max ksp version entry lower than the current one, or a ksp version entry lower than the current one, it simply refuses to install the mod. Normally ckan gets those infos from the .version file included in the mod. => Due to the above reasons, it is benefitial (for users and modders) for ckan operations to simply set the max ksp version to 1.99.99 regardless of what is written in the .version file. So that you can install a mod via ckan regardless of the current ksp version (but that can be changed by myself without having to reupload a mod, in case of real issues). And when you start the game, KSP-AVC, which is a dependency for most SETI mods, will then show you whether the mod version is actually outdated (for bug reporting/support issues). Imho the best of both worlds. Note that this is only useful since the SETI mods do not install plugins, so there are fewer chances of small ksp updates causing issues. I therefore just updated most mods in that fashion. So they should be installable via ckan regardless of version and only generate one warning message via ksp-avc, even though they are still ksp 1.0.5. SETIcontracts has also been recompiled for KSP 1.1.3, and adjusted for the new CustomBarnKit (action group unlocks at start). SETIctt is a special case since a major rework is planned. I therefore decided to not make it available via ckan for the time being. It still works when manually installed. The next version of UnmannedBeforeManned is ready for deployment. But since it includes some craft files and thus the folder structure is changed, I decided to wait until the CKAN metadata changes are deployed. Should be ready within 24 hours. Otherwise it would lead to self inflicted install issues. Early progression in UbM will be much more challenging (materials bay and mystery goo moved far back). So sending very early mini probes to other planets is recommended. Just like it was done in reality. The craft files are intended to give new players some help, due to the increased and probably unexpected early game challenge. They (except for the basic jet) are built with parts from VenStockRevamp, RealChute and RemoteTech (+ SETIrebalance, but the mass adjustments might be included in new RemoteTech version). I would have also included a craft file for early probe missions to other planets, but somehow the small heat shield from VenStockRevamp has disappeared, which is really useful for a "showcase" design. Since the jet is pure stock, I made it available on kerbalx as well: UbM Hangar on kerbalx.com

Bug Report: The 0.625m HeatShield, which is added by VenStockRevamp, is missing (does not show up in the tech tree).

@kcs123 Ah, I see. I ve also read somewhere that putting kOS functionality into other parts might have side effects, though I m not sure whether this info is outdated. Maybe I ll reserve this for a second version of SETIrebalance for ksp 1.1.x and focus on other areas first. The goo/bay shift to later nodes might even encourage players to send extremely light probes (probe, mag, accel, thermo, baro, oscar tank, lv-1r engines, comm, solar, bat) out to other planets, especially Eve and Duna. That capability should be available with few building upgrades and generalRocketry, providing the LV-1 engine family. Thus easily available to players not using DMagic. I m actually fine with the 30 part restriction, it is enough for a mun landing with a probe. Though the mass is certainly my main focus in that area. With more levels, the first levels would be cheaper. Rethinking it, it might make sense to put all the upgrade changes into SETIrebalance, and then implement a check so that they are only activated if SETIctt or UbM are detected. So that those 2 can concentrate on the tech tree part and only a combination activates those specific gameplay changes. Since I guess only the more experienced players will combine UbM with SETIrebalance anyway. That would also mean, that I could release UbM right now and the more complicated stuff can wait for SETIrebalance. I guess I will also just recompile SETIcontracts, as working on it with the current KSP version seems to be not very time efficient anyway.

@kcs123 Hm, I just checked again and even the KR-2042 does not fit nicely into 0.625m diameter. So from my perspective, that would be a major advantage of giving all probes kOS capability. Eg every probe core gets 5000 disk space so people can use the code that would normally fit on a KR-2042. Saves a part in the early game, fits into the probe core diameter and later parts are still superior in terms of disk/mass. Kind of like the integrated 160km omni antenna for remote tech. Hm, maybe command parts cost increase by factor 20 and crew without command by factor of 10. While the parts can be recovered, doing so far away from ksp would at least cost something. I really like the idea of material bay and goo at a 90+ node. That would tremendously increase predictability of early career science returns and slow down initial science generation a lot without taking away from the mid game. Maybe material bay to miniaturization at 90 science and mystery goo to composites at 300 science. That would also make those nodes more "viable". Magnetometer and accelerometer can then imho stay where they are for the moment. Those changes would be especially beneficial in conjunction with the new CustomBarnKit functionality which allows modders to change the number of building upgrade levels. Perhaps R&D cutoffs at 30, 80, 150, 280, 500, 900 science. That would contain some of the beelining to eg particular science parts. Though I m not sure whether that should be part of UbM or SETIrebalance, as the latter might be used in conjunction with other tech trees and thus different cut-off values may be better for those. Not sure how many/what levels would be good for the launch pad/runway (SPH and VAB should imho influence dimension restrictions instead of arbitrary part counts, so I m reluctant to change those until that is fixed).

@kcs123 The problem with unlocking already integrated modules by tech (like the 3km omni of RT and the mech jeb functions) is, that I currently do not know a way to do this with MM patches alone (ie without including a dll). So I meant that instead of unlocking the late game module, I would integrate a kOS module into the stock probe cores, with the capability roughly based on the position of the probe core in the tech tree. I would orient myself along the lines of the SAS functionality. Eg SAS level 3? gives KAL9000 capability, while simple SAS only gives a few hundred/thousand disk space. About progression: I would really love to encourage a different playstyle. For example I consider increasing the costs of parts with crew space 10? fold, makes no sense to have a probe core costing 1000 funds and a command pod costing about 1000 funds. While the real life difference would be much higher, I understand that this might not be feasible with the other gameplay elements the way they are. Imho it would improve gameplay if science point gathering in the early game was a bit more "achievement" based and thus more predictable. One way to do that would be, to reduce the availability of biome based experiments in the early game. Either by changing the biome masks of existing experiments or by moving the ones providing massive biome based payouts (eg goo, material bay) to later positions in the tech tree. Or a combination of that. This might even encourage players to leave the kerbin sphere of influence before science spamming mun and minmus.

@Dombi Hm, UbM is pretty simple and should have no issues or interferences with other mods (except for action groups with custom barn kit...). Also I just checked ckan and it the workaround suggested by @nobodyhasthis2 works fine, current UbM is availabable via ckan for ksp 1.1.3. The SETI RemoteTech mods do not show up, but I guess that is because RemoteTech is not cleared for ksp 1.1.3 so far.

@kcs123 Given how kOS works and what it does, would it not make more sense to include kOS functionality within every probe core instead of creating additional parts? Those already follow the "earlier" = heavier & less capable progress scheme. SETIrebalance could give (at least the stock) probe cores kOS modules and add probe capabilities to the kOS parts... About KSP 1.1.x, I guess my main problem is, that it is 1.0.x all over again. Already experienced this, really unwilling to do it again. I also consider UbM + CTT to be enough for "fooling around"/"quick & dirty career" games. Though I consider some changes to the early game. From what can be seen in streams, most just play on normal or moderate science rewards. And thus the first nodes are pretty much irrelevant. Multiple can be unlocked with one mission. I m not sure how to change that. Perhaps a combination of SETIrebalance changing the experiment payoffs and UbM changing science part positions and node costs. I do not want to make it challenging (that is what I plan for SETIctt dev). Just less of a pushover on normal difficulty.

@kcs123 Just rememered another problem with the order of kOS parts. CX-4181 is simply too fat to fit on 0.625m, which is the size of virtually all relevant stock probe cores... Thus there is little choice, between the first two, only KR-2042 fits into the probe concept.

Hm, yeah, CustomBarnKit changed the structure of the config. I adjusted SETIrebalance for it, but of course that version is not published so far. UbM is the only mod currently adjusted to it, the MM statements are within UnmannedBeforeManned-Settings.cfg. You can take a look at the SETI-PartMod-SQUAD-Probes.cfg file within the current SETIrebalance, which gives each of the specified squad probe cores 200 EC. And then use/modify the statement for 2000 EC. For a more generic MM statement you can take a look at the SETI-GeneralSettings.cfg of the current SETIrebalance, especially the section for command modules, which adds EC to command pods. And learn from that to modify all probe core EC values. Which contract pack do you use to provide the manned contracts, since stock ksp does not offer separate manned and unmanned contracts? Since some serious issues of KSP will not be fixed in the 1.1.x branch (eg the wheels which require an updated unity version), but are postponed to 1.2.x, I m not really motivated to resume work on the SETIctt redevelopment. It makes it impossible to have a satisfactory state of gameplay in 1.1.x. And 1.2.x is scheduled to make more serious changes again on top of the bug fixes, possibly changing part placement / tech tree as well. So probably no SETIctt successor for ksp 1.1.x, due to the state of ksp 1.1.x and experience based expectations for 1.2.x. Though aside from UbM and the RemoteTech mods, I will certainly update SETIrebalance for KSP 1.1.x (and most likely just recompile SETIcontracts for 1.1.x). About kOS: Hm, the mass per code ratio would suggest KR-2042 first, but initial mass would support CX-4181 first. I ll implement your progression. edit: see next post And while on topic, I m inclined to remove physicsSignificance from the CompoMax Radial Tubeless and KAL 9000 in the next version of SETIrebalance, so that they simply add their mass to the part they are attached to.

Since there was no answer to the suggestion a few months ago: Is it possible to make the dimension restrictions dependent on VAB/SPH level instead of LaunchPad/Runway level? That would be a huge improvement for realism mods, which could then deactivate the abstract "part" restriction of the VAB/SPH levels and make them influence the dimensions, as they do in real life.

While unfortunate, I ll have to consider this to be a KSP-AVC issue. When I will release new versions, I ll do a workaround by setting the ksp max version to 1.99.99 to prevent it in the future. Meanwhile you could search for MiniAVC.dll in the gamedata folder and delete them. With SETIctt, the struggle for control was one of the major early game challenges. It is an intended progression: 1. Fins (unguided) 2. Control surfaces (atmo-guidance) 3./4. Gimbal (thrust-guidance) 3./4. Directional thrusters (monoprop) 5. Reaction wheels (much weaker with SETIrebalance, but still magical) That is a lot of mods, which could have interdependencies and are hard to mimic. But I now testest with only RealChute and ModuleManager installed. And the right click resize option is only available before you have action groups through buildin upgrades. Since multiple SETI mods activate action groups from the start when CustomBarnKit is installed, I simply do not understand how you got that right click option to show in the first place with that mod configuration? It seems as if it is intentional from RealChute that this option is unavailable when action groups offer the more detailed settings.

@gobolinno, @Antonio432 Ok, thank you for the info. @Recon777 Nope, it just means that you do not need a full network around kerbin. One keosync long range com sat opposite of ksc should be enough for kerbin. Of course everything beyond kerbin is not affected. You still need networks around other bodies for full coverage.

Hey, great to see TAC LifeSupport continued. I made some pull requests for recycler rebalancing suggestions on github. Basically normal recyclers (1.25m) adjusted for 3 kerbals and general masses lowered for recyclers to make them useful not only for space (kerbin orbital) stations.

Hm, as @Kerbonaut257 suggested, I would also check SETIrebalance first, though I can not exclude the others as that seems very strange indeed. Especially the aprt about "disappear after I play for awhile" anything my mods do should affect the game from the start or not at all, since I only mod configs, not dlls and so on. So you are saying that you load a savegame and after playing that savegame for some time those options just disappear after some time? No building upgrades in between (since RealChutes uses action groups and those depend on building upgrades, except when you also have Custom Barn Kit + SETI rebalance installed (though that functionality of SETIrebalance might need adjustment for the new CustomBarnKit...). Due to KSP instability at the moment, I can not test for extended periods of time and I do not experience this issue when I install SETIrebalance + RealChute myself. I d need at least a clear culprit by process of elimination (eg if you can confirm that it is indeed SETIrebalance while the only other installed mod is RealChutes and module manager of course). Oh, but the removal of the KER parts is definately done by SETIrebalance, they are thus already integrated into every command part to reduce clutter and part count while maintaining functionality. Hm, looking at your linked screenshot, you have a manned plane. Might be this issue? https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/636 Did you manually delete the remnants of the previous version of SETIremoteTechConfig? Though a change/mod of the settings file should have no impact on this at all. I ll test it as soon as I m back at my desktop pc. Yeah, unfortunately they also said that they will change the wheel implementation (again) for 1.2. Reminds me of 1.0.x heat and atmo... I m working on SETIrebalance when I have time, but I m not rushing it anyway. Should be mostly independent of KSP 1.1.3 except for my ability to test with a hopefully more stable KSP version.

Fixed it in new SETIremoteTechConfig version. Please make sure to properly delete all leftovers from previous SETIremoteTechConfig versions.