Yemo

Thank you very much! At least I can neuter their effect. Though I m still angry that I had to spend over half and hour to search for the issue to make it like it was before. Again. Next on the update list is SETIctt again, some maintenance at least for the now recommended part mods. @nobodyhasthis2 Oh, and I noticed that VenStockRevamp has a 2 kerbal command pod. Though I do not like the size, the stats and textures are good for an intermediate role between the Mk1 and the Mk1-2. I also want to take a look at mech jeb and make functions and the part available earlier, since kOS is available at the start and even early rockets had some kind of ascent guidance (and people using mech jeb have already decided on using it, no need for an "artificial progression"). Though I m not too familiar with all the components of mech jeb, if anyone can recommend a progression which fits with that idea? This is the current one: MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } SETI Contracts v0.9.5 (for KSP 1.0.5) Adjustments World First Milestones nerfed, since squad (again) felt the need for unmotivated disimprovements... Unmanned contracts now require probes for completion Contracts do not expire anymore ContractConfigurator Groups are now supported Some reward/advance adjustments, especially concerning reputation

Just got a reply from nightingale, it seems that squad has effectively deactivated the ability to easily deactivate those milestones by making them not contracts anymore. I really can not understand why a company would continuously disimprove their game/moddability with such dedication. I guess it is overtime for some competition... Anyway, nothing I can do about it. Nightingale said that he will check how/whether it is possible to restore that functionality. Another time a modder has to invest time just to restore something which worked previously, because of squads unmotivated disimprovements... Really annoying.

Not yet implemented, though I plan to do so for the next version. That is a bug from VenStockRevamp, there is a fix floating around the later pages of that thread. I hope it gets fixed soon. Anyway, while working on SETIcontracts update, I noticed that World First Milestones appear, which should not be the case. Do they appear for you as well? The update is ready, but I m waiting until the World First Milestones issue is resolved (I notified nightingale), in case I have to change something on my side.

I haven't looked at them for quite some time, since there are so many issues with them and I planned to concentrate on non-contract issues. Oh, and by the way, I changed the CKAN recommendations for the SETI-BalanceMod, though I m not sure when CKAN will take them into account. It is now something like "What-Stock-KSP-Could/Should-Have-Been". Including RemoteTech, RemoteTech-ProbeControlEnabler and RemoteTech-SETIconfig. Which essentially makes it like squads plans for ksp 1.1 in that regard, but with a lot more advantages and far less imbalances/issues. Also KIS and USI LifeSupport (which naturally has to be deselected if TAC LifeSupport is preferred) and so on. Making it a "one-click" mod pack.

@nobodyhasthis2: The MOLE mod looks nice, though there is the issue that it does not quite fit VenStockRevamp textures, as you said especially the Mk1 pod. It would be great if there was an alternate texture for that second person module based on Ven's textures, eg replacing the stock one with an MM statement once VenStockRevamp is detected. Though that does not preclude supporting it, thank you very much for the config. I d put the 1.875m tanks where I put the HGR tanks for that diameter. The NearFuture 2 crew pod should go up a bit, agreed. It is far more advanced than corvus, k2 and such. I ll try to remember it for the next SETIctt update. Not sure about N3h3mia, maybe as a "passive" config, thus not openly advertising compatibility, since even the maintenance version is for 1.0.4 and not easily accessible. If you think the science funding mod works in general, I'll put it in the suggested ckan list. Funds are not balanced anyway, so far. They are all over the place in stock (parts, contracts and unlocks) and balancing them now is of little use (I tried for ksp 0.90), since squad will nearly certainly mess around with them again. Thank you very much for your pledge! Unfortunately it is far from the old BalanceMod for ksp 0.90, but at least it works more or less. Please keep in mind that both USI and TAC life support are suggested, and sadly there is no warning if both are installed, although having both does not work. Hm, I can't remember. But possibly yes, since I planned to do a Laythe survey contract afterwards, which would include landing in all biomes. Thus landing on solid ground would be the logical first step in a real space program, and would also make it a bit more difficult than just activating parachutes, since you would really have to aim for a landing zone. I ll adjust the description for the next update to specify that. Thank you! Speaking about SETIcontracts, since Nori is on hiatus at least until ksp 1.1, I'll do some minor work on them as announced, based on the comment above by @nobodyhasthis2, that they there is no strictly better alternative around. Proposed Changes: 1. Fixing the Laythe description as pointed out by @Ixenzo above. 2. Adding restriction to manned orbit, that it can not be completed with the Mk1 cockpit. I can not restrict the usage of this cockpit for atmosphere at the moment, so that might at least prevent the most obvious shortcut for people who do not use more cockpits. So a limited use work-around for the most obvious exploit. 3. Restricting the completion of "unmanned" contracts to probes. Nearly always new players (twitch/youtube) using SETIcontracts will attempt to do the non-starting unmanned contracts with a manned vessel, eg flyby to mun and so on. Only to be offered the manned version after completing the "unmanned" one. It seems people are so used to the horrible stock mess, that you have to force entice them to think rationally, even if there is a neat little chart in the OP. About the implementation, I could check for maxcrew = 0, but that is completeable by just going on EVA. When checking for "probe", you could send a manned vessel and then detach a micro-probe, but that would need planning. Which sounds fair to me. You can still do a "workaround" and launch a manned craft, complete the unmanned contract by detaching a probe and then do the manned contract with the same mission, but you would need to plan for the workaround. Costs are unbalanced as well, but as I said above, they are unbalanced for everything and squad is just too unpredictable to make serious cost balancing worth the effort when there is so much other unbalanced stuff around. Though if someone has more appropriate values for some or all contracts, I'd be happy to use those instead of the current ones.

@nobodyhasthis2: Thank you very much for your support and pledge! I really appreciate it, however if you do not have the money to spare, it would be totally fine not to contribute with money. For many, a few dollars is not much, especially compared to the time and gameplay benefit this mod provides and I appreciate their donations very much, it helps a lot by distributing the effort in terms of time units (which dollars are for most people). Though I would not feel comfortable recieving money when it is not a time unit (in terms of opportunity costs), but instead a trade unit for basic necessities. 10$ can be a lot if you need them for basic stuff. Due to the contribution of the previous 3 patrons, core SETI will at least be kept compatible with 1.1 (and the corresponding CTT). At the moment the big SXT pack is not supported, I wanted to wait until after ksp 1.1 hits and the tech tree is rewritten. My former go-to packs for 2 kerbal pods were k2 and corvus, but it seems like they are on hiatus as well and of course the big hgr pack... Not sure what 2 kerbal pod is feasible in ksp 1.0.5, quite some modders seem to take a break until ksp stabilizes. I would also love to support the science mod by N3h3mia, I was even close to doing so until 1.0 hit. I suspect they will have problems with heating since they have not been updated after ksp 0.90, unfortunately another collateral damage of ksp 1.0. I ll take a look at science funding for the future, thank you for the suggestion. Maybe I ll even take another look at the SETI contracts (some balancing changes, no expansion), since Nori went on hiatus as well. Hm, seems like 1.0.5 is really lacking in mod(der) support, unfortunately not unexpected. Anyway, a minor update for SETIctt. For everyone who remembers ksp 0.90 glory, it seems like the landertrons are back, at least in a rebooted version (though some former functions are missing). They can be downloaded here: https://github.com/charfa/XTLandertron/releases SETI CommunityTechTree v0.9.5.2 (for KSP 1.0.5) Please support continued SETI maintenance & development via Patreon Link provided in the kerbalstuff description & donate field Many thanks to the 4 SETI patrons! Adjustments Karbonite engines moved from specialized to efficient flight (because of new CTT) Mod-Support kOS (smallest module available at start) Landertron (rewrite for ksp 1.0.5 by Charfa, link in SETI OP)

Github repository for part stat standards: https://github.com/Y3mo/CCF-Standards-for-Part-Stats Just added some basic references for energy and fuel tanks, like 1EC/s = 1kW = 1kJ/s and 20EC/kg. Let's see where and how this goes.

Hm, ok. That is something I can do. I will not write a single MM statement, I ll just write down "standards" from my experience concerning procedural parts and tweakscale and so on, which can be implemented or happily ignored, that would be not my problem. About the "balance" of stock parts, please see some examples I gave in this thread. Stock stats in some areas are wildly unbalanced, as anyone can see who spent a little time looking them up (eg the people from procedural parts). It is hard to call something progression, when a part introduced later is strictly worse than a part introduced earlier.

edit: Well, if it is the majority vote to build a straight tower on a lopsided foundation (and then possibly seal off the foundation,) I'll rest my case.

@inigma If stock values remain unchanged, what are those standards based on and how does it make sense to suggest balancing part mods along standards while leaving stock parts wildly differentiating from those standards? If you build straight on top of a lopsided foundation, the building will still be as lopsided as before. Thus no benefit of building straight up anyway as long as the foundation is not in order.

What about FAR, or DeadlyReentry or RemoteTech? DeadlyReentry was the de facto community standard before 1.0, while it introduced massive changes to stock.

The mod parts would not be altered. With regards to fuel tanks it would just be like someone installing procedural tanks and only using those, and then complaining that the parts of someone elses mod do not work anymore since the procedural fuel tanks have different content per volume ratios than stock tanks... That makes no sense. edti: But hey, I m not pressing for CCF to work in a particular fashion or at all. It just seems that some people want a career with some form of balance and some part modders do not want their mods to be changed by MM statements. My suggestions makes both possible, rebalancing stock, no changes to part mods. I thought that this was the point of the thread, finding something that works, respecting everyones interest. Part of that is of course that it is not part of someones interest to specify what has to be someone elses interest, or putting their interests above everyone elses. But hey, not my problem in this case, it is up to the community.

I meant that CCF would not be a framework anymore, it would add nothing compared to just recommending a contract pack along our tech trees (which I already do at the moment). Without balance of stock parts, what would be the added value compared to eg a statement sayting "I recommend x progression contract pack when you use ETT and those part mods are supported: ..."?.

@inigma, @RoverDude Imho without (stock) part balancing, CCF would not add anything beyond selecting compatible tech tree and contracts, making the whole project pointless. Any thoughts on my proposal to just balance stock parts (without much deviating on a whole from the current stock). Just stuff like fuel tanks around what is already percieved to be a kind of balance (in this case procedural parts values). Or the engines around what @stupid_chris did for ksp 0.24, eg bringing outliers like the poodle into line and making them useful even when using tweakscale. There would be no MM patches to mod parts from the CCF side. That would be totally up to the (part) modder, so it is opt-in. Thus CCF is a set of "standards", and modders (tech tree, contracts, parts) can decide whether they want to adhere to them or not. Those standards are only applied to stock (parts, tech tree, contracts). If a mod is compatible, it is listed as such, if not, it simply is not listed. No dabbling into mods. edit: Just like CTT, Community Resource Pack and so on do set standards and may change stock, but it is up to the modders if they want to opt-in.

Oh, and thank you very much to the two patrons! While I have your patreon names, I m not sure whether you want them to appear in the OP (german, thus concerned about giving info without permission), thus I added thanks to two anonymous patrons. If you are ok/willing to be named, please drop me a short message. @kcs123: Hopefully @Nori will come back for ksp 1.1, which would resolve the general progression contracts from the SETI perspective.

ad1. From my point of view there is not much difference between ETT and SETIctt, with regards to compatibility towards contracts and part balance. The main thing compared to stock is just (the possibility of) starting unmanned and early availability of aircraft/rovers. As long as that is the case, picking one over the other or locking on a new one would imho just diminish versatility without any benefit. Which imho is contrary to the idea of a "community" balance approach. It also increases the entry hurdle for new tech trees. Therefore I propose just setting standards and the complying tech trees are then marked CCF compatible, just like part mods. Eg start unmanned or with aircraft or both and the respective alternative is only a few science points away from the start, or something like that. ad2. Inviting @Nori ad3. I only have limited time at the moment, but I can contribute to it. We should agree on some basics regarding that. Imho the way forward in this regard is, to set standards, use MM patches to apply those standards to the stock parts and then just mark part packs compatible, which comply with those standards. Eg standards like: 1. 1EC/s = 1kW = 1kJ/s 2. Tank volumes eg for liquid fule/oxidizer based on procedural parts 3. Some engine rebalance, along the lines of what @stupid_chris did for 0.24: http://forum.kerbalspaceprogram.com/index.php?/topic/68170-024x-stock-rebalance-v14-110914/ 4. Torque rebalance, asking @Crzyrndm 5. Crash tolerance rebalance 6. Heat rebalance, see DeadlyReentry from @Starwaster Adressing one after the other while keeping it modular is imho the key. Starting with some horribly unbalanced stuff which we can be adressed easily using MM for the limited number of stock parts, like the tank volumes. SETIrebalance does not do that at the moment, so I do not have MM files for that, since I use procedural parts myself.

@kcs123, @IntoSpaceAgain: Hm, I could suggest historic missions and then deactivate SETIcontracts if both are installed. I did some clean-up to the OP. It will need some more work, but at least it is functional again.

Need input from the community: Is there some kind of consensus at the moment, which contract packs work well to replace the bad stock contracts for a unmanned & airplanes first career (like SETI)? I m not up to date and due to time restrictions I can't really test it as well as I would like to. Though I would like to recommend those packs when someone installs the SETI-BalanceMod or the UnmannedBeforeManned mods via CKAN. Current thoughts (in order of CKAN appearance): 1. Anomaly Surveyor 2. Bases and Stations 3. Field Research 4. Giving Aircraft a Purpose 5. Remote Tech 6. Rover Missions Redux 7. Tourism Plus Are any of those above not working well with others, or are there any problems with the list above, in general? I m not sure about a general progression pack, on CKAN there are SETIcontracts (and Initial Contracts), AdvancedProgression, GrandTours, Historic Missions and Unmanned Contracts. Without bias (since I made SETIcontracts), which of them provides the best progression for a tech tree starting unmanned, given their current state? And works well enough together with the special contract packs above?

@kcs123 Yep, the splitting of the life support parts/branches is a bit unintuitive. Imho the bottom 2 tech lines belong somewhere else. For the 1.1 tech tree revisit I plan to move the container line somewhere between fuel tanks and construction. And the recycling/spacestation/colonization line should imho be right below the command pod line. Which also brings it much closer to the exploration and resource extraction nodes for the later colonization techs. Another planned feature will be the modularization of fuel tank clutter parts along the lines of the current wing and tac life support special clutter nodes. So users can skip those 1 science nodes if they use procedural tanks preventing clutter in the VAB while still advancing the general tech tree. So that the broad categories are sticking together a bit more (from top to bottom): 1. Nuclear Techs 2. Rocket Propulsion 3. Fuel and Storage 4. Construction 5. Aero Tech 6. Landing 7. Probes and Control 8. Command, Habitation and Colonization 9. Exploration & Resource Extraction 10. Electrics (including Ion engines) and Heat Management But before investing time into implementing that whole tech tree rework, I have to see what changes in ksp 1.1 and the corresponding ctt version.

That looks like a very sophisticated contract pack, I m really looking forward to trying it out!

Thank you very much for your very generous contribution! It really lifts the spirit to see that appreciation and gives new energy especially when dealing the less pleasant tasks like maintenance and repairs! I will post a small monthly update on patreon around the middle of each month. Which may mainly serve as a reminder to cancel pledges, for everyone intending to do one time donations! Speaking of maintenance work, this is the SETIctt maintenance update, roughly adjusting to the new CTT 2.3. Next in line are further repairs to the threads OP. CommunityTechTree v0.9.5.1 (for KSP 1.0.5) Please support continued SETI maintenance & development via Patreon Link provided in the kerbalstuff description & donate field Many thanks to Aelios, first patron of the SETI Mod Project! MOD-SPLIT Only SETIctt and CommunityTechTree are now distributed in this download For the rebalancing part, please download the SETI-BalanceMod If you use RemoteTech, consider the SETI-RemoteTech config from the forum thread Adjustments Maintenance adjustment for CTT 2.3, not great but working Major tech tree rewrite planned for KSP 1.1 and corresponding CTT I just checked the tech tree again and I remembered it differently. Supply storage is available from enhancedSurvivability node for 45 science. I have not found a mulch part being available earlier, but I might well have missed something and I do not have a full mod install at the moment, just the USI life support. So, this is the update for the short term to do list: a ) Functional Mod maintenance (eg adjusting to the new CommunityTechTree) - done b ) Information maintenance (Cleaning up the forum post after the destruction by forum migration) c ) Additions to the mod support d ) Adjustments to SETI-RemoteTech Config for vision color deficiency (red-green) e ) Simple Mod pack around the Unmanned Before Manned mod to lower the entrance barrier to career modding

Imho part balance, tech progression and contract progression do have interdependencies, but can be separated easily if some connections are accounted for. 1. One of the 2 main reasons for this is, that parts in ksp are usually not pareto superior to other, earlier parts, with some noteable exceptions. Parts further down the tech tree usually just increase the repertoire of available stat combinations. And often the partial exceptions to this rule are major balancing problems. Eg when an engine is just massively better than 2 or 3 earlier engines combined. While in reality progress often reduces or replaces choices, in ksp that is usually neither desireable nor unavoidable, it is just bad balancing, especially when procedural parts and/or tweakscale are used. 2. The other main reason is, that the currently available tech trees (including stock) are not radically different from each other, with the noteable exception of some starting manned, while others start unmanned. Though for part balancing, that exception is nearly irrelevant, it mainly affects contract progression. One has earlier girders, the other has later girders, but that has little to no impact on girder stat balancing. SETI is now set up with modularity in mind, though some old remnants from the previous structure are not yet dealt with (like the SETI ctt starting with the HECS probe core and using the stock probe models in a different progression). I would assume that you could install ETT together with SETI-BalanceMod without any major issues, except for the probe core stats as a remnant of the old SETI structure. The problem is, that stock has no standards or reliable balance. As an example, install tweakscale and procedural parts and take a look at the stock cylinder RCS fuel tanks. Scale all of them to have roughly the same dry mass and roughly compare their volume and total mass/fuel capacity. There is not even a hint of balance. You can tweak a procedural RCS tank to get a better understanding of the magnitude of the discrepancy. If that is not devastating enough, add the non cylindrical RCS tanks. While RCS tanks have the highest discrepancies, the liquid fuel tanks are not volume/dry mass/wet mass balanced either. Which might be acceptable in stock, but is just devastating when you play with procedural parts + tweakscale + fuel switch. And those are just 3 stats (volume + dry mass + wet mass/capacity) for one part category (fuel tanks) for the stock parts alone. When you take a closer look, you realize that KSP does not work because it is well balanced, or balanced at all. It works because the restrictions (funds/tonnage/dimensions/crash tolerances/heat tolerances/life support etc) are so lax/unimportant, that part stat balance is totally unimportant for nearly all design decisions. edit: This is compounded by the low dv requirements and the early availability of asparagus staging. No one really cares in ksp whether you have to put 4 tons into orbit or 5, or pay 10k funds instead of 12k... They do become visible in challenges though, where you notice that 12m/s Landing Struts are routinely replaced by the lighter 50m/s Small Landing Gear or 80m/s structural parts and the used engine and command pod selection is pretty limited.

That rebalance was removed from SETIctt, it is now part of SETIrebalance. This is how to change it within SETIrebalance: http://forum.kerbalspaceprogram.com/index.php?/topic/95645-105-seti-unmanned-before-manned-patreon/&do=findComment&comment=2347115

I've scimmed over the thread and since I have some experience with the SETI BalanceMod family, these are some quick remarks which come to mind: I m not completely sure I understand the scope of the project. I unterstand that the long term goals are somewhat similar to the KSP 0.90 SETI BalanceMod, but I m not sure about the process to get in that direction, while there already seems to be a discussion about implementational details. Especially in a collaborative project, initial complexity is death. You need to focus at first, to reach a functioning state supported by a core modder group and then take it from there. Realism Overhaul works along a pre-exiting framework (reality), thus minizing conflicts of opinion and a lot of balancing issues. That pre-existing framework also kind of auto-generates a core modder group. BTSM cuts out mod support, thus allowing for very detailed changes in almost all areas, thus creating a cohesive gameplay experience. SETI (post 0.90) has a very modular setup, while focusing on one module (SETIctt, particularly the mod support) at the moment, thus allowing for modular customization. And those are the somewhat mature projects (with a hard modder "core"), which started a lot smaller. Many areas are only loosely connected, like tech progression and part stat balancing (as long as you want to support procedural parts and tweakscale). There need to be cuts regarding the initial scope, while keeping modularity/scaleability when the scope/mod support widens. Only incremental improvements will keep such a project going.

When using the SETI-BalanceMod, mystery goo and materials bay can not be collected for balancing reasons. They also have different science payouts, masses and sizes, so their role is somewhat different. Unfortunately squad buried that information by messing up the original post of this thread with their forum move. The mechanic can be changed in the SETI-ScienceSettings.cfg within SETIrebalance folder, lines 70 to 120: @dataIsCollectable = False. Thank you very much for your mod support during the last month! I ll write the mulch thing down, USI Life Support seems to be in constant development at the moment, so I ll likely lag somewhat behind. Since I plan to rewrite the tech tree for KSP 1.1, I ll likely wait until then. USI LifeSupport has (at least that is the last info I remember) 15 days of life support. Imho not giving an early option to extend that emphasizes the probes first approach for anything more that minor orbital and munar missions in the early game. At least that was the reasoning behind it. Though since you have more recent experience in that regard, if you are positive that it is too far away, I could move the USI LifeSupport one step forward during the next maintenance update (which is necessary anyway to deal with the updated CTT). edit: Will take a look at GAP, thank you for the suggestion! Hey inigma, at the moment I first want to see if there is actual continued interest (patreon) in a continuation of SETI/my KSP modding and if there is, concentrate on dealing with the short term SETI related issues. But I m reading the CCF thread right now and will at least offer some of my "experience"/thoughts, so that some of my mistakes may be avoided. And then we can take it from there...