Yemo

Do you have the SETIprobeControlEnabler mod installed? If I remember correctly, there were some RemoteTech limitations which forced me to remove the integrated omni antennas from probe cores, when that is installed. Can you right click on a probe core in vab/research and check whether the probe core lists a 160km omni antenna? If I remember correctly, cockpits and such were not affected, so they retained their integrated omnis with probeControlEnabler installed.

KSP 1.2 has newly introduced issues with too many parts in VAB and SPH. Might have just been the straw that broke the camels back. Even though SETIprobeParts does not even introduce new textures, just reuses the stock ones. Good idea, 100 would just provide an additional money sink without creating balancing issues. Curious to hear about your experiences with it, will mark this for the next version. Yep, the part overhaul parts are still unbalanced, so they are not supported at this moment. It is recommended to use CTT + UbM together. They make a more stockish combo, ETT is a truly different tech tree. Depends on your personal preference. So, while there have only been very minor visible changes, there is some stuff going on in the background. For example you might have noticed that the 1.8 version of RemoteTech uses antenna/dish masses very similar to the ones in SETIrebalance, which is no coincidence. Although I expect some more balance changes with the adjustment to stock commnet and the newly provided stock antennas/dishes. There are still some issues with RT, which are due to be adressed in 1.8.1, thus I will wait with the recompile of the support mods. And with the mini mod which will simplyfy RT to the point where it is much easier and less confusing than stock commnet... Similar news for TAC life support. The recyclers from TAC life support are planned to have the SETIrebalance masses in the future, which makes them much more useful and balanced than before. Also the converter module code will change. This means that SETIrebalance and SETIgreenhouse will have to be adjusted to this new code once the next TAC life support version is released. edit: Both of those mass adjustments should also make it easier to install and uninstall SETIrebalance during a game, especially concerning the 2 main gameplay altering mods for life support and communications. SETI Contracts v1.2.0.0 (for KSP 1.2.x) Simple recompile for KSP 1.2 SETI ProbeParts v1.2.0.1 (for KSP 1.2.x) Added Hibernation and data transmission functionality to probe cores, thank you very much @tjt

ad1: It does not resemble stock commnet ground relay station positions, as it is much older than commnet. Also I already offered it some time ago, but the very concept of multiple ground stations was rejected for stock remote tech. ad2: Yep. I also made a mistake there, they are fairly close to RT masses, so close that giving them mass appropriate ranges would make some current RT dishes redundant. That requires some thought on which dishes/ranges are desireable at all.

@tjt: Thank you very much, will be implemented in next version! @Jashin: Thank you for the request, something I nearly forgot with all the remotetech transition going on. It is planned to support the part overhaul, though first they would need balancing, second the (currently badly implemented and thus troublesome) part upgrade functionality has to be removed and third the equivalent stock parts have to be hidden (those are all things that could/would be done by SETIrebalance, though there is already a MM patch floating around, which hides the stock parts). When/if that is done so that they do not create gameplay/balance issues anymore, I ll write a config for UbM. @MaxwellsDemon: Hm, I just bundled the module manager which was downloaded via ckan, no idea why it has a different version number than the one distributed in the forum thread.

ad1: SETIremoteTechConfig adds ground stations ad2: The new stock relay dishes represent multiple (RT equivalent) dishes in one part, thus they are eg far heavier than rt dishes. Treating them as RT dishes requires that they are completely rebalanced.

Yep, I remember that it originally had a "forced" origin after the old tech manager was not necessary for tech tree modding anymore. But regardless of the origin of that behaviour, it objectively provides the user with more information and it makes the tech tree more predictable. For example, if you only install a very late game mod (eg ftl) and later install a mod for the nodes in between, that could result in the latter nodes being researched while the many in between nodes are still locked.

Empty tech nodes are objectively not a problem but could even be seen as a "feature", and for those vocal few who have a subjective problem with them, there is a mod.

How do you intend to balance the stock relay antennas for remote tech? Since they simulate multiple antennas, they are much too heavy in comparison to the single direction rt dishes. Another issue is imho that the energy consumption of the current RT dishes is not yet balanced, which limits their use, especially at longer distances (eg jool) in conjunction with solar panels. If there is interest, I could simply implement the values from SETIrebalance.

Since (nearly?) all contract packs require contract configurator, and contract configurator is not updated for ksp 1.2 yet, I do not expect any of them to be cleared for ksp 1.2 at the moment.

Yes, or like all the people who install remote tech mod expecting it to replace stock commnet, only to find out that they have to deactivate commnet manually at game start...

I would strongly suggest that remote tech deactivates commnet itself, regardless of player choice in the start screen. Otherwise it is a support nightmare, and there is no benefit at all to have them both active. If a player would wish to use commnet, that player would not install remote tech in the first place.

Seeing lots of people being unhappy with the difficulty presets, I wonder if it is possible to mod them? Eg easy is selected by extremely few people, the "hard" difficulties mainly make it grindier, not harder, and so on...

Looks like ckan did not like the removal of the craft files, thank you for your report, should work now.

So, a few more or less minor updates for ksp 1.2. The other mods should work as well, though I will wait with the recompiles until their base mods are updated (ContractConfigurator, RemoteTech and TAC life support). Also note, that the ckan meta mod pack is now part of SETIrebalance instead of UnmannedBeforeManned! Unmanned before Manned v1.2.0.0 Minor changes for KSP 1.2 (new antennas/dishes) Also removed the vessels, as I can't maintain them for 2 different comm systems SETI Rebalance v1.2.0.0 Minor compatibility fixes for KSP 1.2 Crewed parts costs increased by a factor of 5 EntryCosts all set to 1 Rather not having a "feature" than a severely unbalanced one Especially as long as it is part of the "difficulty" presets SETI ProbeParts v1.2.0.0 0.65m HeatShield removed, since a similar sized stock one is now available

Hey, I had to set the mods in ckan to be compatible with all versions to reduce install issues. The mods are not yet updated to ksp 1.2, though most should work. The only one possible producing real issues would be SETIrebalance, which I m in the processs of updating. The double parts in the tech tree are just due to general ksp tech tree modding issues. If you alter/mod the position of a part, which you have already researched in your savegame, the part is still displayed where you formerly researched it, in addition to the new modded location. Though that is only a graphical anomaly in the tech tree, functionally the part is only available at the new tech node position.

I dont see how the distinction between relay and non-relay can coexist with the RT functionality to point every dish individually.

Imho the primary focus should be to make current RT work with 1.2, especially given the dev constraints. And then, with more time, gradually transition to CommNet where possible/desirable, while current RT still works and provides a fallback. Instantly switching to CommNet means, that people who actually prefer current RT will have nothing at first and something below current RT standard for quite some time. Like you dont usually abandon a game and start from scratch as soon as a new windows version comes out...

So I read about and tested the new version a bit more and have some additions to my statements above: The upgrade system is really a two-edged sword. In addition to the balancing nightmare, it is also a severe problem for craft file sharing. Previously you simply checked whether you had the right parts unlocked. Now you have to have the right upgrade unlocked as well. As far as I can tell (so I could be wrong about this), a design which is constructed eg with a LV-T45 upgrade 1, can not be used if you eg only have upgrade 0 unlocked, and, confusingly, also not when you have upgrade 2 unlocked... Anyone can confirm this? This would be a serious issue. Apropos craft files, due to the new comm net feature, I ll have to remove the example craft files from UbM. @kcs123 Something like a flight computer from MechJeb would be awesome. I dont agree with the discussions in the remote tech thread about priorities. Imho a working (old) remote tech with 1.2 is much more desireable than commnet + flightcomputer + signal delay. If that is the route RT is going, I ll have to switch to CommNet alltogether. Especially if MJ implements a flight computer as well. Though with those options, it is likely that I ll personally stay on 1.1.3 until the options improve... Oh, and while on the RT topic, the "requirement to point dishes in RT" can be easily changed by a small MM statement which converts all dishes to omni-antennas and thus makes RT much simpler than current CommNet, with its destinction between relays and the other antennas/dishes. If the old RT functionality is restored for ksp 1.2, I could just make another small mini-mod which does that. It seems that squad decided to reorder some experiments in the direction of UbM (thermo and baro earlier, materials bay later). There is also that science return capsule, though I do not particularly like the form factor and that there is no distinction between returning values (eg thermometer readings) and more complex samples (surface sample). Imho a half-hearted implementation. I ll check whether I can simply give that functionality to probe cores and reuse the sample return part for something else. To restore some balance, I recommend the SETIrebalanceMaterialsGoo mini mod anyway. I agree with the technical stability part, though with the "new" features and open ends (part upgrades), it seems to be less feature/modding stable than 1.0...

They seem to fill some gaps, but as far as I can see, their stats are not (yet?) balanced (looking at you, LV-T30 and LV-T45...), so I ll take a look at them when they are ready. Otherwise they are pretty much less interesting versions of VenStockRevamp (LV-T15). Same goes for the different "butts". VenStockRevamp had a feature which allowed you to attach the same engine on different tank sizes, with auto adjusting fairings, quite some time ago. I welcome the additions in those 2 areas, but they are nothing new in terms of a fully modded game. The natively supported upgrade is the real difference, though it is a very ambiguous one. For me it all depends on the implementation and compatibility with mods. The general idea is nice, to have different stats for the same part. Possible issues are eg compatibility with tech tree mods and tweakscale, especially when a lot of part mods add a whole bunch of upgrades based on stock. Also makes it a nightmare to balance. Flight Computer is a control workaround when there is no instant connection. A loss of instant connection can not only be caused by signal delay, but also by having no connection at all, eg because of occlusion. As far as I can see, there is an option to have control issues due to occlusion, but no workaround by eg a flight computer. I m personally not a fan of signal delay, but I still want to have a method of control for a probe which does not have a connection at the moment, even when playing with realistic difficulty settings which simulate a total instantenous loss of control on loss of connection. Some things from current modded/adjusted RT I would look for in a modded/adjusted commnet, to my knowledge it only provides some of them: 1. Flight Computer for reasons stated above. 2. Option that no connection only restricts science transmission, not control 3. Customizable range model, eg root, additive, fixed, and so on 4. Balanced parts in terms of mass, costs, range/signal strength, etc. 5. Possbility of command stations for local control of unmanned craft 6. Variable origins of main connection (ground stations, whole planet - which can be simulated for certain altitudes/orbits in RT with enough ground stations) 7. Fixed/variable relay networks 8. Visualization of information 9. Signal Delay for total realism So far I see CommNet as being only strictly better in 8. Visualization of information, while being equal (though different) in some aspects and strictly inferior in others, most importantly the lack of a flight computer as a workaround for not having an instant connection while playing with control restrictions on loss of connection. If there is anything not quite right or plain wrong about my assessment, please do tell, I m eager to get it right! edit: From what I have seen so far, the main advantage of 1.2 over a fully modded 1.1.3 is the "fix" of the landing legs, even though/because they can now be used as cannon springs. The improvements compared to stock 1.1.3 are just not interesting for me personally.

@kcs123 But it also seems to offer very few advantages for my personal preference over current RT + addons. While there is quite some stuff about current RT + addons + rebalance which I personally prefer to current stock CommNet as far as I have seen of it. It might be possible to adjust some of the stock CommNet features to my personal preferences, but why do so? I ve not yet seen much of CommNet, but what are the features that are improvements over RT + addons + rebalance? I m genuinely curious. I read about the RT mod lacking dev with the possibility of hiatus. That is very unfortunate. But I m not really eager to dedicate a lot of time to reach a state which is marginally better in some aspects while being marginally worse in other aspects compared to the 1.1.3 fully modded experience. I already had that experience and it was not pleasant, so I d rather wait for the options to improve/the difference to be large enough to justify the extra work.

Will do, thank you! I took a brief look at it, but will take a more detailed look in the future. So, I just took a look at 1.2 prerelease, especially the commnet. It feels like being somewhere in the middle between RT + SETIremoteTechConfig + SETIprobeControlEnabler which is very simple and RT with some options which makes it very hard. Personally I prefer the extremes, either simple to fool around, or realism to go all the way. Was true for RT options as well, one of the reasons why I created the addons, to offer a very simple version/option. However I like the added features from commnet (map). Just my personal preference. Tracking Station / Kerbin side of range restrictions seems to be intended to scale nicely with career, so that comm sats are only necessary for coverage, not for range (at least in stock, not really compatible with NewHorizon/OPM distances...). I do not yet understand the part balancing of the antennas, but I only took a brief look. Since I personally prefer (modded/customized) RT (flight computer, range model, etc., and because I m already very used to RT), I do not plan to touch/rebalance the stock antennas for CommNet/stock anyway. I definately like the fact that command parts now have an inbuilt antenna with useful range, so I m happy that this part of SETIrebalance modifying RT is now also in the stock game. From what I have seen so far, I think that it is a great new feature with sound implementation (especially due to the ingame documentation, ie part range shown for tracking station upgrades), which really enriches stock gameplay. Personally I just prefer RT, mainly due to familiarity, flight computer and existing customization. SETI update plans so far: 1) UbM needs some minor adjustments to account for the new parts 2) SETIrebalance needs some minor compatibility adjustments (at the moment it adds transmitters to command parts, so those MM statements simply need to be removed for ksp 1.2, no plan to touch new comm net parts/functionality) 3) SETIctt reboot makes no sense at the moment, with uncertainty about upcoming engine rebalance, part upgrade feature, mod reactions to that and commnet and thus impact on tech tree, etc. But I already have a contingency plan for that. Since imho the main gameplay difference between UbM and SETIctt is the increased challenge at the career start (control/reaction wheels), I will just make a mini mod which can be added to UbM to alter that part of the progression and increase the gameplay challenge of UbM. While SETIctt adds more nodes, UbM has its science parts further down the tree, so gathering science is more difficult, which kind of cancels out. And when (if) things settle down and are thus more plannable, it can be revisited. 4) The other mods are either fine or depend on other mods to update, to see what changes are necessary. edit: So I will take SETIctt out of the OP since it is not really suited for ksp 1.2 with the new antennas/dishes and UbM + the new mini mod will be a good approximation with much better mod support. The last version should still be available on spacedock.

That is great news. Removing folders is vital for not messing up installs. I shall have to put a file into SETIreactionWheelRebalance or whatever it was called, explaining that the folder is empty but not useless. I guess I stay with the current opt-out in this case, since it is just a simple trigger folder, not a mod itself. And I guess that people who actually find SETIrebalance are generally interested in tackling this imbalance in stock. It also seems like 1.2 is in pre-release. I ll check on that and then take a look at which mods need updating. First focus is most likely on UbM.

Hm, KSP-AVC was added as a dependency a long time ago, due to the nature of SETI, CKAN, KSP and user behaviour (eg not reading threads). I guess I can remove it from UbM, since that has a broader audience and the issues with old module manager versions and stuff not working for tech tree modding was quite some time ago. On the other hand, I dont want to those times to return, especially considering ksp updates coming out soon.

I would definately put in a recommendation to use a non-stock tech tree. Which modded tech tree is used is not so relevant, they are all massive improvements over the stock "progression" (late wheels, ladders and so on). ETT, HPTT, UbM...

In preparation for ksp 1.2, I did some changes/consolidation to the ckan recommendations/mod packs. UbM now focuses on the tech tree, thus it simply recommends CTT, TakeCommand and SETI-ProbeParts (to fill in stock part gaps). Suggestions will possibly be extended in the future. SETIContracts focuses on contracts, recommending CustomBarnKit, AnomalySurveyor, FieldResearch, KerbinSpaceStation, Tourism, GAP and Waypoint Manager. SETIrebalance is the (only) meta mod pack (consolidating former SETI-BalanceMod and UbM meta mod packs), acting as a sort of "conversion" mod pack. The "recommendations" focus on real gaps of the stock game, in terms of comfort and missing parts (station, probes, very light remote tech implementation similar to the one proposed for 1.2), while the suggestions offer further improvements (LifeSupport, ProceduralParts etc). I also changed some descriptions in the OP, eg writing about the differences between UbM and SETIctt. Further dev depends, as usual, on the state of the base game. Especially in terms of fixes (wheels), implementation of new features and reliability.