Gotmachine

Yay, great news ! Starting a new career now to playtest. A few issues / remarks about the data/science system : There is an issue when you run the same experiment twice for the same situation/biome, you get the data twice and if you hit the "remove" button, all the data get removed. You have no way to manage/remove an instance of the experiment and I'm not sure how transmiting the data is managed at this point. Also an issue : when running multiple experiments in a row, if you click the "Keep experiment" button, all "opened" experiments are kept, not only the one in front. So you don't get a chance to keep/discard the other. I don't know if this is possible (I get the feeling that the "stock experiment" is lost at this point ?), but it would be nice if in the data panel, clicking on the experiment bring the stock experiment report. Also, I would personally prefer the situation/body/biome info as an undertext or another column. The tooltip method gets quickly annoying since you usually have a load of the same experiment in different situations onboard. @Peder Need confirmation from ShotgunNinja, but I'm pretty sure that using Kerbalism with an existing save (a 1.2 non kerbalism save or even 1.1 kerbalism save) is unsupported and won't work correctly (Maybe this should be mentioned in the OP)

@The-Doctor Adding a lot of habitat space and entertainment part can give you something like 12 kerbin years before instability (but this require a really large ship). There is a "on ground" bonus for planetary bases. However, something to take into account is that "instability points" are accumulated very quickly when kerbals are in a restricted space, typically when you put them in a lander, a rover or in a transfer vessel. There is also a variance of something like +/- 25 % for each individual. I recommend to plan for 50 % more than your estimated mission duration, and more if you plan to have kerbals out of the "main habitat" for some time. I suggested to @ShotgunNinja a change so a large enough QOL factor can remove accumulated "instability points". In conjunction with the radiation shield, this would give a (very hard) way of having kerbals for extended times out of the kerbin SOI.

From my Kerbalism player point of view, I think the most important is to have balanced values for gameplay. There is a major difference between kerbalism and TAC-LS : oxygen (and water ?) is recycled continuously (thanks to the background simulation) and the greenhouse is used to produce food in space. There is probably some balancing to be done, seems to me that the proposed values for the next Kerbalism release are way too high but with the TAC-LS values, recycling and growing food isn't worth the extra greenhouse mass & EC consumption. Looking at the end of the TAC-LS spreadsheet, 6.5 tons of supplies for 6 kerbals for 3000 days is next to nothing compared to what is right for Kerbalism. About the "multitude of mods", I would like to ask which ones ? I know that Kerbal Planetary Base Systems has support for the Kerbalism greenhouse partmodule. About storage mods, since consumption ratios aren't fixed in kerbalism (due to recyclers), I think multi-resource containers can have arbitrary ratios. In any case, all this can be fixed with a few MM patch, I don't see why such mods wouldn't support the specifics of Kerbalism LS the same way they already support TAC, USI, IFI or Snacks. But anyway, since a lot of things are going to change with next release, I think it's time to wait until we can playtest the new balance of things. From what I've heard and seen, seems to me that the main purpose of this mod is to extend the stock gameplay, globally increasing the parameters you should worry about and making time a critical factor in most missions. And doing so by fixing / refining stock mechanics (like the background consumption, signal, transmission & science) or introducing new mechanics based on real space things like life support, quality of life, malfunctions or radiations.

Maybe you could reconsider, since Kerbalism LS is nearly the same as TAC-LS, with in my opinion a better implementation : consolidated interface, VAB planner, background consumption, global vessels panel management, timewarp events management, integrated waste recycling and greenhouses. And it seems that the next version will use a realistic resource set (oxygen + food + water) similar to what is used by TAC-LS. And as far as I know, integration with other mods is on par with TAC-LS.

I don't support this, because of my "annoying random unpredictable complex overrealistic features are pointless" policy toward mods in KSP

That would be great, finally radiators will get out of the VAB ! About the experiments, do you intend to keep the stock experiments (and their parts) ? Also, can you explain the intended "over time" system : do all experiments generate data over time, and can be started/stopped anytime ? If so, what is the meaning of "take xx days" ? Is that the amount of time until the experiment is considered "done" for a particular body/situation/biome combination ? Also, I don't understand the logic behind each experiment being tied to a part (I understood that you intended to make them switchable). Maybe you could have 3 experiments types : "manned", "small" and "large". They can be VAB-inserted freely into the following "labs" : "Canister" : 1 small experiment "Bay" : 1 large experiments or 3 small "Lab" : 2 large experiments or 6 small, can do manned, provide data rate/amount bonus when the lab is manned by scientist ? "Pod" : manned only (manned by scientist bonus ?) This would remove the grindy stock mechanic of some experiments being available only in the late tech tree, while still having a progression (the large experiments being only avaible when the "Bay" part is unlocked, perhaps at the 160 science nodes). Or perhaps experiments availability could be tied to the KSC science complex levels. But here's my take on two possible experiments : Photography timelapse installed on a goo container (small unmanned experiment) need to be in space low, flying or moving over the surface (is this situation possible ?) unlimited use, generate large amounts of data that yeld small amounts of science (much better science yeld for the flying/surface situations ?) results can be transmitted description : "Scientists agree that taking thousands of high-resolution pictures of random places is rather useless, and KSC engineers are objecting over the huge amounts of data that need to be transmitted. But still, we stand astonished by those eye-candy timelapses of alien landscapes." Space illness medication testing installed on a pod/lab (manned experiment) need to be in space or landed (not on kerbin) take 90 days, body multiplier is applied, can be done for each body/in space and body/landed situation results can be transmitted description : "When KSC scientists finally stabilized the chemical formula of those miracle pills, they triumphaly announced the end of motion sickness and musculoskeletal injuries. Then they asked kerbals on mission to monitor their toxin levels every hour, and to report any "unexpected bleeding"." I could do more, but you plan to recycle stock experiments ? Temperature and pressure could be the other small experiments, and gravioli, seismic and atmospheric scans the larger ones.

Seems that you forgot to install ModuleManager. Read the first post.

The reliability overhaul seems great in every aspect, you really have a thing for game mechanics design ! If you give us a beta release, I've got some time on my hands to test the balance and report bugs. Quick perfectionist observation : in the reliability module VAB text, you could use the "√" (square root) sign instead of $ for the currency symbol (unless there is a way to use the real ksp currency symbol).

You're on the right track, but changing the "localRotation" only affects the plume FX, not the thrust vector. If you do this, the RCS block plume effect will appear in the right direction, but in reality, the thrust will still be rotated by 90° (you can check that using the RCS Build Aid mod). The problem in RCS modules is that they use the Y axis of the thrust transform, while engines use the Z axis. Fortunately, there a setting for that. The steps to convert an engine to a RCS thruster are : In the old engine CFG, find the line "thrustVectorTransformName = name" In the new CFG, add this ModuleRCSFX (note the "useZaxis = true" line) : MODULE { name = ModuleRCSFX stagingEnabled = False thrusterTransformName = thrustTransform // Change this to the "thrustVectorTransformName" of the engine. useZaxis = True // This line is mandatory so the thrust direction is the Z axis, because engines transform use this setting. thrusterPower = 12 // The thrust of the RCS block in kN resourceName = LiquidFuel resourceFlowMode = STAGE_PRIORITY_FLOW runningEffectName = running PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True resourceFlowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = Oxidizer ratio = 1.1 resourceFlowMode = STAGE_PRIORITY_FLOW } atmosphereCurve { key = 0 320 // Vacuum ISP key = 1 220 // Atmospheric ISP key = 5 0.001 } } If the engine already has a EFFECTS { running{} } section, you can copypaste it (delete any other nodes than "running"). If it use the old FX system (if you things like "fx_smokeTrail_light = 0, -0.75, 0, 0, -1.0, 0.0, running" in the part definition, you should delete those and you can use this EFFECTS section (remember to change the transformName ) : EFFECTS { running { AUDIO { channel = Ship clip = sound_rocket_mini volume = 0.0 0.0 volume = 0.1 0.0 volume = 0.5 0.05 volume = 1.0 0.5 pitch = 0.0 0.5 pitch = 1.0 1.0 loop = true } MODEL_MULTI_PARTICLE { modelName = Squad/FX/Monoprop_medium // same effect as the Vernor engine. You can use "Squad/FX/Monoprop_big" for a larger plume. transformName = thrustTransform // Change this to the thrustVectorTransformName of the engine emission = 0.0 0.0 emission = 0.1 0.0 emission = 1.0 1.0 speed = 0.0 0.8 speed = 1.0 1.0 localRotation = 0, 0, 0 localPosition = 0, 0, 0 // you can use this to offset the plume effect, if it appears far away or inside the part (example 0, 0, -0.5 will move the effect toward the part) } } } Delete any other module, like ModuleSurfaceFX, ModuleGimbal or ModuleAnimateHeat This is an example of a converted engine (from the NovaPunch mod) : Original CFG : RCS CFG :

@DJ Reonic Yup, they will degrade, along with reaction wheels, RCS thrusters and other modules. But you can repair them. @CloudyMN1979 I'm also a bit worried about the planned features inflation but Kerbalism isn't USI, it's a gameplay mechanics mod (very few parts) that add various features based on timewarp-consistent resource usage and consumption. All features are somewhat dependant on each other to offer a more complete gameplay experience, and it seems to me that code-wise, they all are built on the same unique framework. So far, ShotgunNinja has showed a great dedication to his mod and the community and it seems to me that he know what he's doing.

@ShotgunNinja So much changes and additions incoming ! Personally, I think I will switch to a custom simplified and more forgiving profile for next release. I love Kerbalism but after using it for a good hundred hours, there are things that bother me : overall, the mod adds too much mass to vessels for the stock engines ISP range, and I want to keep the possibility to have Kerbals out for very long times. I want to make a profile without background radiation (so I only need storm/belt shelters), more forgiving QOL rules and some other tweaks. What I would like is that when the vessel QOL factor is high enough, "stress" is removed from Kerbals (so with a big enough station/base, I can get "fresh" kerbals). I tried fiddling with the rule degeneration value, but it seems that I can't achieve what I want. Would you please consider adding this possibility the QOL rule ?

Okay, maybe I overreacted a bit. I'm reading again and again what you said about the "science revamp" and I'm not sure I fully understand everything : For example, the goo canister would become a "bio-lab" containing a "bio-sensor". Once in the right situation (defined by the data definition associated to the bio-sensor), let say "landed on a body", I can activate it. Over time, it collects data, even in the background. But is there still a limit to how much data in this particular situation can be acquired ? At what rate is the data generated ? Is it still useful to bring back the data, or do you plan to make this a requirement only for the "samples" resource ? And also, how to handle situation changes (like space high/space low) if they happen with an activated sensor ? It would be nice to have manned requirements for late-game sensors, or maybe a big boost to the data amount when a sensor is used in a manned lab. Something that make late game progression dependant on long manned missions. Also, does that mean that we will get 3 "lab sizes" (the canister, the material bay and the lab) and we choose what sensor we put in ? What will happen to the other stock experiment parts ? About "samples" being a generic resource, does that mean that it will yield the same amount of science regardless of the planet/body multiplier ? How will you retain the "data" associated with each sample if it's a generic resource ? This said, maybe that the idea of making generic, abundant, heavy samples is something interesting.

@goldenpsp At least I'm saying something in relation with the topic, thank you for your intervention. I'm a big fan of this mod, I really enjoy what @ShotgunNinja is doing and I think Kerbalism is the the best gameplay mod out there that actually try to make the game more interesting and not turn it into something else. I actively play with this mod and wanted to share my impressions and give a feedback about the new features, and suggest what I think would be nice to have. Nobody has to feel offended. @ShotgunNinja stated multiple times what he disliked and wanted improved in the stock science system. I have a feeling that what I suggested and said is more or less what he is trying to do and that he need some kind of "science data system" on top of the stock system. I would love to hear more from him about what he want to do with this science revamp, and my intervention was more a question than a critic. Plus, so far everything in this mod is highly configurable and tweakable, so no need to fork it

I should say that I'm a bit disappointed with the features you showed for the next version. What I like in Kerbalism is it's simplicity. It fits nicely in the stock gameplay, adding this new layer of gameplay with the varying life support mechanics. It essentially adds time as a major gameplay element and it does it well with a few parts and a few ressources. I enjoy it because it extend the challenge and possibilities. But I'm worried about the direction this mod is taking. The "radiation update" added a bit of complexity. Now, the greenhouses have a special GUI (I truly hate that) and a ton of special requirements. Air pressure ? Allright, but what's the point ? Now this science overhaul. I don't know. Why not ? But why ? What does all these new modules and systems add that we didn't have before in stock ? Will the gameplay be better ? I don't want realism. Realism is for simulators, not for games. I understand that others want a realistic experience, but this wasn't the point of this mod as far as I know. I'm not really happy with how science and career are done in stock, but what I think is lacking is an incentive to launch probes, rovers and kerbals in space. Currently, I can finish a career game in stock (or with kerbalism) in a few hours because how science is easy to get if you know how to grind it. I don't support your project about science data handling or soil samples as a resource. I only see added complexity and very minor improvements over the stock science storage and transmission system. I don't want more experiment/location combinations. I would prefer to have less of them (and from the science tweaks in Kerbalism, I think we agree). But you also said "things that generate science over time" and "labs". This is a great idea, because it fits with the purpose of the mod : time as a resource. Some ideas : Most experiments/labs need time and/or to be manned to produce data (incentive to stay some time at a destination) Landed and manned experiments/labs can be repeated multiple times automatically in the background (incentive to establish bases and stations) Soil analysis, generate science amounts based on distance traveled on a rover (incentive to send rovers) Very few instant experiments, limited to low science amounts (for a transition to probes/early game/flybys to manned missions/endgame/long stays)

Try the demo and check if it runs smoothly with the biggest ship you can build. While it's based on a (very) old KSP version, it should give you an insight of the performance you will get. On my 5 years old core-i3 2.3 Ghz laptop with integrated graphics and 4 Gb the full game run smoothly as long as I don't use too big ships (~60 parts) and set the graphics on the lowest settings. I think you should be good but don't expect to be able to play with 200+ parts ships or a heavy modded game.

I would advise not using RemoteTech for a first career. RT demands a lot of micromanagement and adds some very specialized gameplay elements, overall adding a lot of complexity and difficulty for unmanned missions, making them very unbalanced against stock manned missions. To make things even, you need to use a life support mod. However, I do recommend a life support mod even for a first career. The whole point is to turn time into an important resource, making the game dependant on two resources (mission duration and payload weight) instead of only one. I don't recommend TAC-LS which adds too many resource and is made more for realism that anything else gameplay-wise. Same thing for USI-LS, it is of no interest without the whole USI package. Snacks is probably the best for a first career as it is simple, integrate well with the stock game and is more forgiving (Kerbals won't die, you will only loose reputation). Another option is Kerbalism which is a all-in-one communications/life support/quality of life/radiation/malfunction mod. It does all these things in a very coherent, straightforward and stockalike way, not adding too much complexity but adding a lot to the stock gameplay, both for manned and unmanned missions. It feature a nice mission planner to ease things and integrate well in the career progression.

This would explain the problem and why adding (a lot) more battery capacity seems to make things better. I'm not too optimist about this, but perhaps you could open a bug report on the bugtracker since you seem to understand what is going on. About QOL, maybe something like this : // entertainment bonus entertainment = 0.0 foreach(part p): entertainment += p.rate // base living space living_space = (crew_capacity + entertainment) / crew_count * QoL_LivingSpace // other factors firm_ground = 1.0 + (landed() ? QoLFirmGround : 0.0) phone_home = 1.0 + (linked() ? QoLPhoneHome : 0.0) not_alone = 1.0 + (crew_count > 1 ? QoLNotAlone : 0.0) // the final quality-of-life factor qol_factor = living_space * firm_ground * phone_home * not_alone Obviously the current module entertainment values would need a buff.

From my Kerbalism experience, the problem with EC depletion in shadow is very intermittent. It seems to me that while the incorrect EC calculations are consistent, most of the time at 100000x the game "skip" the consequences. I had a case where only one out of four kerbals died from cold on a craft orbiting Kerbin. I've also seen random and silent shutdown of the greenhouse or gravity ring when on an interplanetary trip. For now, the best way to keep this from happening is to provide a lot more batteries than necessary. Unrelated-last-post-in-thread-edit : It's about entertainment/comfort. Seems that it's currently calculated as a multiplicative factor on the base space provided. It feels a bit unbalanced, here are a few examples for a 4 kerbals ship, shielded at maximum : 1 hitchhiker + 4 cupolas (8 seats) (18 tons) : 5y389d 7 mk3 passenger modules (112 seats) (161 tons) : 5y110d 4 gravity rings at max speed (needs 2 ec/s) (4 seats) (15 tons) : 7y143d The weight figure gets a bit less dramatic without the shielding, but still is an issue. The problem is that each comfort bonus adds up, making "comfort " parts overpowered against providing just more space which is very costly because of the required shielding. Another caveat I found while trying to make a MM patch for various non-stock parts is that you can't simply make a low-weight small comfort part because by using a bunch of them it is possible to get a ridiculously long breakdown expectancy, even if you use a 1.05 or 1.1 value. Therefore I suggest : To buff the "per seat" breakdown expectancy a bit To change the comfort bonus to be additive instead of multiplicative.

Done some more tests at 100000x : Oxygen : I confirm that this one is calculated correctly in all cases (scrubber, no scrubber, multiple kerbals, active vessel or not) Food : consumption is about 10 % lower than what it should be. Quality of life : with a single hitchhiker (so 4 space + entertainment) and one kerbal, the kerbal turned red at 276d MET instead of the 320d announced in the planner. First "mistake" happened at 418d MET. Exactly the same results using 6 space but no entertainment (same 320d breakdown expectancy in the planner). Radiation : I disabled storms by setting the values to 0 in the settings.cfg and placed directly my vessel in a very high kerbin orbit. Planner life expectancy 250d, Jeb died at 250d MET.

@ShotgunNinja, @g00bd0g I don't think that the EC consumption bug at high time warp is related to solar panel input. Build this simple ship : QUBE Probe core + antenna (-0.03 Ec/s) 1 RTG (+0.75 Ec/s) 2 greenhouses (-0.5 Ec/s at 1.0 lamp power) Launch it, stay on the lauchpad, play with the greenhouse lamps to adjust power consumption and test timewarp. Quick results : EC production (Ec/s) Ec consumption (Ec/s) Stored EC at 10000x Stored EC at 100000x 0.75 0.71 270/405 0/405 0.75 0.53 305/405 0/405 0.75 0.27 355/405 0/405 0.75 0.13 385/405 205/405 Note that although this seems impossible, the stored EC value is perfectly stable. Could reproduce the problem using the gravity ring as a consumer. Testing with the science lab was a bit trickier, but it seems to be affected in a less dramatic way : the stored charge was at 95 % at 100000x warp for a 1.50 ec/s production and 1.46 ec/s consumption. Not 100% sure about this one. Some more info : A quick test with food : 1 kerbal on board, 10900 units stored, planner depletion estimation : 2y238d. Effective depletion timewarping at 100000x : 2y359d Another one with oxygen : 1 kerbal, 120000 units, 1 scrubber active (max tech level). Planner depletion estimation : 1y174d. Effective depletion timewarping at 100000x : 1y174d. In some case with the first test, one greenhouse is automatically shutdown when I begin timewarping (related to the "shutdown non-essential systems" behaviour ?) All the test results are consistent when I timewarp with the vessel active or from the tracking station. But here is the best (well, maybe worst...) part : I can reproduce the problem with EC in stock with no mods using one RTG and lamps. Same exact thing : depending on the production/consumption ratio and the timwarp level, the stored EC stabilize at different points. With + 45 ec/min and -42.6 ec/min, the stored charge stabilized at 18.8/30 at 1000x. At higher timewarp levels, the lamps shut down nearly instantly but I can briefly see the stored EC going down. This may need further testing just to be sure, but the oxygen test results prove that it's possible to have correct values at high timewarp levels. Maybe because it's not using any stock module ? Edit : found some info that may help : http://bugs.kerbalspaceprogram.com/issues/5502 http://forum.kerbalspaceprogram.com/index.php?/topic/122176-resource-consumptionproduction-incorrect-during-timewarp/ http://forum.kerbalspaceprogram.com/index.php?/topic/122820-charge-level-stops-responding-when-over-100x-time-warp/ http://bugs.kerbalspaceprogram.com/issues/750 From what I saw crawling trough the forums and the bugtracker, it seems that the cause is that the different modules don't update exactly at the same time.

Fuel cells EC output was reverted back to stock in 0.9.9.9 to address this specific issue, so the behaviour with them should be the same as the stock game. Note that vessels launched prior to 0.9.9.9 won't update to the new consumptions. Solar panels are still nerfed, so I recommend to avoid using them for mining operations. @ShotgunNinja This said, as it already was pointed out, it seems that background resources consumption is (very) inconsistent at high time warp levels, usually leading to a much higher consumption than what should have been. To avoid this, either don't use the two higher time warp levels or do time-warping while keeping your mining rig as the active vessel.

@ShotgunNinja I barely use ion engines because they are only useful for low weight/long range probes. When I use them I use a lot of batteries, enough to make it trough a 2000-3000 dV burn and I pack a few RTG that recharge the batteries between burns. It's usually more efficient than producing the required EC in real-time. So from this point of view it make them a bit more powerfull but others may have some other use where the EC rate matter more, so the current *0.5 value may be a good middle ground, I would let it as it is. Unrelated : I know that you currently don't account for the heat management and engineer bonus for drills in unloaded ships. I'm not too concerned about the heat (somewhat useless game mechanic if you ask me), but it would be nice to have the engineer bonus applied (I know that stock doesn't either). Totally related : you're really doing great work on this mod !

I still disagree with the idea of nerfing EC generation rates but here is some constructive criticism on specific matters : Running an ISRU + 2 drills require 50 ec/s, that's 9 fuel cell arrays with your config. In stock you need 3 arrays for the same setup. This mean that you need 3 times more LF+Ox to run the arrays. This result in nullifying the final output in case of an unmanned/no engineer/background consumption setup, even with high ore concentrations : for an 8% ore concentration, you get 0.00067 LF/s instead of 0.0074 LF/s and the output becomes negative beginning somewhere below 7% concentration. The problem doesn't really happen with an engineer, a level 0 will only have a 20 % output reduction and it gets negligible with high level ones. From a cosmetic point of view, I understand that the array look like 6 individual fuel cells, but it's quite bulky and takes a lot of space. From what I usually see, nobody use fuel cells for anything else than ISRU anyway (because when you consider the fuel consumption, the EC/mass ratio is stratospheric versus RTG), so please consider revert them to the stock values which are balanced against ISRU/drill consumptions. You divided lights EC rate by 2 and generators by something between 2 (RTG) and 3.5 (solar), meaning that they consume more than in stock. I was under the impression that stock light EC rates were already quite high. I would prefer an increase in RTG mass instead of a reduction of the output as you usually need lot of them even on simple missions. The result is the same but it's more friendly toward the part count.

Okay, we understand your point. But this is a game, not a realistic simulator. If you search deep enough, everything in KSP is broken or worded wrong if compared to real life. @Jovus @ShotgunNinja The performance hit is very low as long as you don't have more than a dozen ships in flight, but things get worse quickly if you have a lot of big ships/stations running in the background. Seems that having a few high part count ships has a big impact. @Nansuchao Found that adding more cupolas is a very effective way of improving the quality of life. Also, turn on your gravity ring in the VAB to see the effect.

Then please keep stock parts at stock values and scale the scrubber, gravity ring and greenhouse consumptions accordingly. I understand the restrictions you want to achieve (ISRU is end-game and needs fuel cells, beyond Duna is end-game and need non-solar power) but my point is that they are arbitrary restrictions. They don't make the game harder, easier, better, they just are arbitrary rules that restrict existing choices that were possible in the stock game. I want to be able to use an ISRU before I have access to the fuel cell array, this is the point of having a tech tree, to be able to make choices as a player. But ok, let's say we want to nerf solar panels. Just double or triple their weight, it would be a lot more effective than reducing their EC output. Reducing EC output can be compensated by adding more panels. More parts, more lag. I hate lag. Everyone hate lag. It's a very frustrating way of nerfing something. And if you really want to make solar panels ineffective on far away planets, just use a more punitive formula than the stock solar_luminosity / (4PI * dist^2).