Yemo

I m just rewriting my contracts, when I noticed that the "HasCrew" parameter seems to be bugged. This is what I used to have a manned 18km altitude contract with return home: PARAMETER { name = OrbitKerbin type = VesselParameterGroup PARAMETER { name = HasCrew type = HasCrew minCrew = 1 } PARAMETER { name = ReachState type = ReachState minAltitude = 18000 disableOnStateChange = true } PARAMETER { name = ReturnHome type = ReturnHome } } While the 18km and returnHome part works, the "HasCrew" is not listed in the right hand side in-flight contract window at launch. It appears there when the 18km parameter is completed and is instantly checked, even if I m only using a probe to do so. edit: Hm, has nothing to do with rewriting the contract, the old contract also completes the HasCrew minCrew = 1 for a probe core (maybe using RemoteTech is a problem?).

I know that feeling. The further you dip into KSP/stock, the more confident you get with squad skipping a proper beta and moving straight to release .

Thank you for the $ help, though naturally I m hesitant to write a config for a mod which does not follow naming conventions. Because I would have to revisit it and change my MM configs, when the "alpha" from "BoxSat alpha" is dropped, or it actually does follow the no-spaces-in-folder-names convention. Which is ok for one mod, but totally undoable for 20 or so. Yes, I know that feeling, there are quite a few compatibility files and requirements, but draggin and dropping single config files for mod support may work for one mod or the odd exceptions, but hardly for 20+. Imho users could read more descriptions, but having to drag and drop MM compatibility configs without reason does not encourage that, it just leads to unnecessary problems.

Yep, if you have sufficient greenhouse capacity, you only need about 10% of the usual water and 20% of the usual food. The greenhouse consumes all the waste products and with the extra water and food, it fulfils all oxygen, water and carbondioxide needs. I m not aware of fuel components in TAC life support. Crew requirement and efficiency: I was considering that, especially with regards to MKS/OKS compatibility. But I also wanted to not provide disadvantages for using the 3 or the 1 kerbal version and keep it as simple as possible. So maybe in the future, eg when squad allows modding of traits and so on. Visualization would be nice, but I can not do anything about it. I just wrote the configs, the model is entirely out of my control/scope.

;-) Those decouplers are annoying as hell. Well, the next patch today or tomorrow is mostly fixing stuff. But I wanted to include a little more, to call it 0.8.7, so I turned to BoxSat, which was asked for way back in the beginning of February. Unfortunately, BoxSat is incompatible with easy ModuleManager referencing (due to not following the no-spaces in folder names convention). So about an hour ago, I searched for someting different, but small. And well, as it turns out, I m just finishing the Mk2Essentials support ;-)... Though I want to do something about the contracts as well, before releasing 0.8.7.

Hey, that is a great mod you have there, very nice system for small sats. Although I have some compatibility issues. The main problem is, that your folder is called "BoxSat alpha", instead of "BoxSat" or "BoxSatAlpha". That space is a problem for ModuleManager, could you please change that folder name? And a suggestion for your optional module manager files: If you replace eg that code @PART[62cm_BoxSat_BlowoffHatch] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } with this code @PART[62cm_BoxSat_BlowoffHatch]:NEEDS[TweakScale] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } the patch only gets applied when TweakScale is installed. So there is no need to distribute the configs in a separate folder and make players install them manually. They are just applied when then needed mods are installed. Which is actually the reason for the compatibility issue above. In order for that :NEEDS[whatever] statement to work, the mods folder under GameData is not allowed to contain spaces like your "BoxSat alpha" currently has. Thank you very much!

@nightingales revision: Ah, great, I will change my contract to follow that scheme. It should also cut down on the lines in the contracts description. @Sequence behaviour: So the new Sequence would behave like the old SequenceNode in terms of completing parameters in order? That failing if not in order was the main (only) reason I picked SequenceNode over Sequence, so I could simply run a "replace" through the contract files. And use what you wrote above under nightingales revision for the less complex ones. So from my side, there would be no reason to keep Sequence and SequenceNode and I would just convert over. Though I guess I would need to do that at the same time as the behavious is changed/Contract Configurator is updated? @flags for hiding: Flags would be a great addition, so contract makers can decide what people would likely understand from the context. @WiderContractsApp: I m generally using ContractsWindow+, but I have to account for people not using that. So integrating WiderContractsApp into ContractsConfigurator would solve that nicely. And it does not seem to take more space than the stock resource panel, while only one of them can be active anyway.

You are welcome! Are you sure you have TAC Life Support installed? Because if that is not installed, it is just a nice looking part with shutters. It receives the converters via ModuleManagerConfigs if TAC Life Support is detected. And those conveters can be deactivated again. Though if it does not have enough input resources (because eg only 2 kerbals are on the station instead of 3), it should only run at 2/3 capacity. That might be a problem for testing on the lauch pad aswell, since kerbals do not consume oxygen and produce carbon dioxide below 5km on kerbin. The consumption/production does not automatically adjust to different TAC settings levels. About the back, imho a greenhouse for space would look very different in reality, much less wasted space, no or extremely few windows (everything lit by LED). But that is the model zzz released to the public domain, and I do not do models and textures myself. Personally I use Ven's StockPartRevamp, putting a docking port on at least one side and long fixed ladder segments on that back strip.

Ah, thank you, was just about to try. @nightingale: At the moment I do not see an adequate replacement of the SequenceNode. The completeInSequence hides the fact that the parameter has to be completed in sequence from the player. The "Sequence" either fails parameters which are completed in the wrong order, or it hides further paramters in flight, which is detrimental to mission planning. Given those options, I will have to keep the "SequenceNode" in the SETI-Contracts. Anything else would be a functionality devolution. Because of that, I hope SequenceNode is still supported in 1.0 CC.

I m not sure we mean the same thing, if you could confirm? The parameter is shown in the top right corner in flight mission list?

Interesting idea, but is the parameter also hidden from the in-flight contract description until the previous one is completed? With complex contracts and especially multiple contract missions, that would lead to a planning/info problem for the player.

Hm, missed that. I do not like the Sequence Node at all, because of the "fails contract if completed out of sequence". Eg if I want to define a contract for first landing on the Mun and then returning back to Mun orbit, I can not do that with the Sequence Node. The vessel will naturally complete the Mun Orbit part before landing on the Mun, which fails the contracts although the player did nothing wrong. For cleaning up: It would help a lot if stuff could be shown in the same line. Eg for this contract parameter: PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = LANDED } It should not show Vessel State: Incomplete Destination: Kerbin: Incomplete Situation: Landed: Incomplete but rather something like this: Landed - Kerbin: Incomplete Actually, besides my time contraints, this is one of the major issues holding me back from making more complex contracts. Because at the moment this is just too confusing for more complex missions, especially in the in-flight window. About removing the sequence node, am I correct in assuming that I shoudl rewrite this PARAMETER { name = OrbitKerbinSeqNode type = SequenceNode PARAMETER { name = OrbitKerbin type = VesselParameterGroup define = OrbiterRecovery PARAMETER { name = ReachState type = ReachState situation = ORBITING } } } PARAMETER { name = LandKerbinSeqNode type = SequenceNode PARAMETER { name = LandKerbin type = VesselParameterGroup vessel = OrbiterRecovery PARAMETER { name = Any type = Any PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = LANDED } PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = SPLASHED } } } } into that?: PARAMETER { name = OrbitKerbin type = VesselParameterGroup define = OrbiterRecovery PARAMETER { name = ReachState type = ReachState situation = ORBITING } } PARAMETER { name = LandKerbin type = VesselParameterGroup vessel = OrbiterRecovery PARAMETER { name = Any type = Any PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = LANDED } PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = SPLASHED } } completeInSequence = true }

Imho recyclers should be used for long range vessels and distant, part time occupied stations or bases which do not get enough sunlight due to slow planetary/moon rotations. And permanent stations/bases with enough sunlight would use greenhouses. That is the setting for which the SETI-Greenhouse is designed for especially when used together with BackgroundProcessing and the SETI-BalanceMod.

I need the TR-18A for the Mk1 pod and the Rockomax Brand for the Mk1-2 pod, if no other mods are installed. Then I additionally need the UP-25 from DeadlyReentry to fit with the Mk1-2 + HeatShield, if StockPartRevamp is not installed. But I can not use the Deadly Reentry ones as default, since not everyone uses Deadly Reentry or puts a HeatShield on the Mk1-2. If Stock Part Revamp is installed, the Mk1-2 has an integrated HeatShield, thus I would only need the TR-18A and the Rockomax Brand and none from DeadlyReentry. However Stock Part Revamp provides a shorter version of the Rockomax Brand, so in that constellation I will deactivate the normal Rockomax Brand and only use the shorter version... It is quite a mess...

You could take a look at the SETI-Greenhouse. When you use the greenhouse, you need 10% of the usual water and 20% of the usual amount of food, everything else is recycled by that one component. And of course EC, depending on the mods you have installed (eg BackgroundProcessing, which is highly recommended). So you do not need additional recyclers. 2 greenhouse versions are available, 2.5m for 1 kerbal (2 tons) and 3.75m for 3 kerbals (6 tons).

Thank you, I might have to update the OP, stating that the maxMods game scratches the win RAM limit. And maybe some short advide how to get around it (-force-opengl, ATM, LINUX!). Thank you for the warning! BackgroundProcessing is not a technical dependency, so there should not crashes or something because of that. And the CKAN dependency change coincides with a pretty big "Savegame endangering" content patch for this mod, so changelog reading users might expect problems anyway. Well, KSP has quite some quirks/bugs, so I can not confirm that with certainty! A problem is, that with BackgroundProcessing, you need a lot more energy, eg for ComSats and for life support if you use the new compatibility file. But since your vessels may not update, they lack the battery capacity to fulfil those needs, resulting in problems. With every major update, I recommend that you copy paste your Kerbal Space Center folder (since it has no DRM) and then apply the patch. So you can always go to your backup if things go wrong. Also you might wait with installing BackgroundProcessing until you are able to update your ingame vessels, especially manned ones (since losing probes is part of a space program anyway). @All: I will try to release a minor patch later today (UTC), fixing some stuff and maybe including support of a mod which has been requested long ago. It will also bring back the stock StackDecoupler, so you would have to unprune with the current SETI-AutoPruner file and then prune again with the new file. This is a response to the twitch stream by "SmeggCo", who did a short introduction to the SETI-BalanceMod 0.8.5 on 25th of May. Until the Mk1 command pod gets proper fairings... edit: Those are the preliminary bug fix notes: **Minor Changes and Fixes** * Fixed Batteries (Z-100 and Z-400), they were not updated if Ven's StockPartRevamp was not installed * Fixed Rovemate EC storage and HeavyDutyCommandSeat EC storage * Fixed SETI Mun Probe ComSat craft file * Removed Karbonite Boosters, which were forgotten, updated AutoPruner file

Hey, great to hear that you are closing in on 1.0.0. I do not use any of the parameters above. About the "cleaning up", that got me thinking. For more elaborate contracts using sequence node and vessel parameter groups and so on, the contracts window looks very cluttered now. For example one of my earlier contracts should only require players to bring a vessel with at least one crew above 18km and then land safely on Kerbin again. This is the code, and it generates a whole 18! lines of mission objectives in the Mission Control building. Which is kind of overwhelming. Is there a way to introduce at least a "hiding" statements for each parameter? For example instead of having one line saying "Crew: At least 1 Kerbal: Incomplete" and the next line saying "Count: At least 1: Incomplete", one would be enough. Same goes for the "Destination: Kerbin" and the "Vessel State", in most contracts, that is obvious from the context, so a flag to hide them would be nice. PARAMETER { name = 18kmKerbinSeqNode type = SequenceNode PARAMETER { name = 18kmKerbin type = VesselParameterGroup define = mAltRecord PARAMETER { name = HasCrew type = HasCrew minCrew = 1 } PARAMETER { name = ReachState type = ReachState minAltitude = 18000 } } } PARAMETER { name = LandKerbinSeqNode type = SequenceNode PARAMETER { name = LandKerbin type = VesselParameterGroup vessel = mAltRecord PARAMETER { name = HasCrew type = HasCrew minCrew = 1 } PARAMETER { name = Any type = Any PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = LANDED } PARAMETER { name = ReachState type = ReachState targetBody = Kerbin situation = SPLASHED } } } } Thank you very much for the plugin and your support!

Wait for the 1.0 StockBugFixMod and an update for KER while derping around.

Thank you! Breaking the RAM limit for windows is a major milestone, on to the next (breaking the windows RAM limit with normal ATM). Hm, and another bug discovered, without Ven's Stock Part Revamp, the small batteries are as bad as before. I might even have to release a minor bugfix patch. edit: And the Karbonite SRBs should have been hidden/pruned...

Originally Karbonite was scheduled for 0.9.0, but a lot changed and I forgot to delete some half-done Karbonite configs for the 0.8.5 release. So I just wrapped it up to avoid the multi-version mess, the air intake engines were roughly balanced, it might need another pass in the future. Removed Karbonite from the dev section, thank you. Yep, looks like I forgot the Rovemate. And I already found a few other issues. For example there are a few size problems without Ven's Stock Part Revamp. And the SETI Mun Probe ComSat craft file is messed up. The SolarArrays are now clipping into each other. This is the corrected version: Download SETI Mun Probe ComSat - fixed craft file The idea behind it is, that you do a Mun flyby, collecting some science with magnetometer and thermometer (if you can get below 30km) and then position the probe outside the Mun's sphere of influence on the same orbit around Kerbin. Either behind or in front of the Mun, it would be able to cover a good part of the "dark side" of the Mun. One KR-7 for communication with Kerbin, one for tracking an active vessel, and two for other stuff, eg further relay to Minmus or for other Mun Comsats. The Communotron 16 barely manages to reach the Mun, it could work for a dense low Mun Orbit Network or as a fall back, otherwise use the two KR-7. The craft has double the amount of necessary solar panels for that mission, if you forget to align the craft correctly. It also has two batteries, one of them can be switched off as an emergency battery. I guess some oversights had to be expected after that kind of patch. KSPI integration needs some preliminary work, because of the TweakScale - Procedural Parts issues, so that may take some time. Maybe I ll release a small patch within the next days, with some minor part pack supports or configs to at least put some more mods into the "AdditionalMods" section without too many inconsistencies. Increasing basic mod compatibility with minimal workload.

For a new career game, you might want to take a look at the SETI-BalanceMod in my signature. Removing clutter by replacing stock tanks with procedural parts is one of the main features. It provides an autopruner list to prevent the unused textures from loading, without deleting them (so they can be unpruned again).

All parts are on the stock tech tree, so no problem there. However in my opinion they are a bit early, so I generally moved them further back for SETI.

Updated the OP with a flow chart and additional info.

It consumes all the waste products from the supported number of kerbals. I will extend the description, had to roll out SETI-BalanceMod 0.8.6 first.

@Lord Aurelius: Will take a look at those contracts. @everyone: You need to reassemble your vessels so that the changes work. Especially regarding command parts, batteries and solar panels! So if you have a craft design, detach all the parts from the command part, then add the command part again from the VAB and reattach the rest of the craft. Same goes with batteries and solar panels, so that the changed stats are recognized. You might want to put BackgroundProcessing on hold, until you are sure that you can supply your vessels with energy! New Version 0.8.6 IMPORTANT: Massive EC rebalance, standardization of many parts to 1EC/s = 1kW = 1kJ/s The mod Background Processing is now listed under the dependencies, though it is not a technical requirement New TAC life support compatibility file, increases crew energy requirements by a factor of 20! A 1 kerbal crew now requires 0.71EC/s instead of 0.036EC/s, 3 kerbals now require about 1.275EC/s Probe Cores now require 2 twice as much energy (0.04EC/s instead of 0.02EC/s), but batteries have 12 times the capacity So Background Processing is very strongly recommended, but not required without TAC life support NEW Craft file Many changes require the reassembly of craft designs Eg only newly assembled (not launched, assembled!) command parts have the increased energy storage Only newly attached solar panels have the correct size 2 version of craft files: minMods and FAR+partMods (using bold mods until the Mun Probe ComSat) Extended Mod Support, updated AutoPruner file New dependency: Background Processing (non-technical) EVA Fuel SETI-Greenhouse (included in the manual download) USI Karbonite Solar Panels Solar Panels renamed to reflect their output and shape Models, Masses, TechNodes and Output of Solar Panels rebalanced, only applies to newly assembled vessels Solar Panel models increased by a factor of about 2.3, to balance realistic W/m² (would need a factor of 3.24) with game optics Solar Panels now use power curve resembling inverse square law, as set by CaptRobau for StockRebalance mod from stupid_chris That means, with twice the distance from Kerbol, they are about 25% as effective Eg at Duna Apoapsis (21.8Gm) Solar Panels are only about 39% as effective as they are around Kerbin (13.6Gm) For Dres Apoapsis that goes down to about 8.4% and for the Joolean system the effectiveness is only about 3.5% Use TweakScale and/or alternate energy sources to compensate Fuel Cells, Batteries, RTGs Alkaline fuel cells only produce energy, if the batteries are not full, thus they are now load dependent! Alkaline fuel cells now require 30 times the input resources, but have increased resource storage All batteries have massively increased capacity, eg former Z-100 battery now rated at 1200ec, instead of 100ec, only applies to newly assembled vessels Batteries are also rebalanced in terms of part volume RTGs rebalanced Procedural Parts and Hydrogen Storage Hydrogen tanks have much less dry mass and double the capacity Procedural Food tank has higher density, you can now copy paste procedural water tank and switch to food for same supply duration New TankTypeOption for the procedural TAC life support tank: Nutrients Same volume/mass as Food, but cheaper and twice as mass efficient to transport Nutrient storage needs much less dry mass per volume/mass compared to Food, it can be used for the SETI-Greenhouse RemoteTech Reflectron DP-10 rebalanced, 0.04 EC/s instead of 0.1EC/s Communotron 16 rebalanced, 0.06 EC/s instead of 0.13EC/s CommTech EXP rebalanced, 0.08 EC/s instead of 0.18EC/s, earlier @electrics Communotron 32 rebalanced, 0.16 EC/s instead of 0.6EC/s DTS-M1 rebalanced, 0.2 EC/s instead of 0.82EC/s, later @advElectrics (behind R&D upgrade) KR-7 rebalanced, 0.05 mass instead of 0.5, 0.2 EC/s instead of 0.82EC/s, earlier @scienceTech KR-8 rebalanced, 0.15 mass instead of 1.2, 0.16 EC/s instead of 1.81EC/s, 0.1 cone instead of 0.01 88-88 rebalanced, 0.1 mass instead of 0.5, 0.21 EC/s instead of 0.93EC/s KR-14 rebalanced, 0.2 mass instead of 1.0, 0.21 EC/s instead of 0.93EC/s CommTech-1 rebalanced, 0.3 mass instead of 1.0, 0.3 EC/s instead of 2.6EC/s Reflectron GX-128 rebalanced, 0.24 mass instead of 0.5, 0.34 EC/s instead of 2.8EC/s, later @experimentalElectrics Other Rebalances & Adjustments Most RoverWheels earlier available Hydroponics tech node in CTT renamed to advRecycling Sabatier reactors earlier @advRecycling (new SETI-Greenhouse @shortTermHabitation) 2.5m Skipper rocket engines later at heavierRocketry, use adapters and engine clusters for early 2.5m rockets Procedural Real Fuel parts now follow the SETI diameter progression Minor Changes and Fixes Procedural HRBs fixed for RealFuels, thank you Chonner RealFuels procedural parts diameter progression closer to SETI