blakemw

I second Kerbalism, the greenhouse takes ~180 days for a crop to mature so you still need at least a 6 month stock of food. Also the crop is sensitive to radiation, I don't believe radiation actually kills the crop, it just delays its maturing. You can completely recycle the ammonia (via Kerbals) and mostly (or entirely?) recycle the water used but it increases the amount of water recycling you need, also the greenhouse leaks atmosphere (like other parts) and the leaked nitrogen is hard to replace except on the worlds with nitrogen-rich atmospheres: Kerbin, Eve and Laythe - maybe Duna. So for most locations it's not "closed loop" but ultimately requires nitrogen (and maybe water) as an input. Finally it's fairly heavy especially if you add radiation shielding. I haven't calculated the exact break-even point for bringing a greenhouse instead of more food, but it's probably about 2 years.

@CristiHow do you run them multiple times? If I do the same experiment again after analyzing and transmitting it gives zero science (doing the experiment again in a different location doesn't count since the whole point is to have a reason to maintain a station in one location). I've never tried it separately from Kerbalism so maybe it works differently in stock?

I was under the impression that station science only lets you do each experiment once, no? It's basically just like really, really, really heavy versions of Dmagic orbital science, that take a few days to run each experiment, then you may as well abandon the station.

I strongly support this. One idea for balancing it would be to have diminishing returns over time, the way I've imagined it could work would be something like this: A scientist in a lab produces research at a rate of 1/day, that research is converted to data which then needs to be transmitted/returned as per usual, and the research -> science rate depends on the location's science multiplier. There is a 25% penalty for not having a pilot on board, and another 25% penalty for not having an engineer on board, because the scientists time is wasted on communication, administration, maintenance etc. The more research that has been generated from a "location" (with valid locations being "in orbit" and "surface") the more slowly new research is generated, say every 100 research reduces research rate by 10% using a power relationship, i.e. after 1000 research has been generated the new research rate is 0.9^(1000/100) = 34.9% - I would favor an "infinite science, but with greatly diminishing rates" solution, but a finite amount of science which eventually gets completely depleted would be okay too. So the basic idea would be that a lab wouldn't be an infinite science mill (at least not without investing infinity^2 time), but it would be initially fairly rewarding to run. After a while - a few years - the research rate starts to noticeably decay, you could then feel justified in shutting down the lab, or revitalize the research by relocating to another world. Employing more scientists would mainly increase how quickly you get the "easy" science for a location, like a big station with 8 scientists and pilots and engineers could quickly science the hell out of a moon then move on to the next moon once the rate drops to 10%, on the other hand a solitary scientist could produce reasonably stable science returns for many years. But if you really want to you could employ like dozens of scientists in low kerbin orbit and with a gigantic investment in life support and maintenance produce a fair income of science, basically just doubling your scientist population each time the rate halves (that is clearly unsustainable, but you could keep it up for a while) The main reason I like the decaying solution is it incentivizes leaving LKO. A non-decaying rate either produces a really abysmal and not very rewarding return rate, or provides no incentive to ever leave LKO. Something I feel quite strongly about is that science based on stations/bases should be a *fully viable alternative* to biome hopping. The reason I feel quite strongly about this is that veteran players have probably done biome hopping in dozens of careers previously. I don't want biome hopping to go away, but it's nice to just be able to focus on building and maintaining stations/bases and not have to do biome hopping for the hundredth time. For this reason I feel that station science should be balanced to be fairly rewarding, kind of like the MPL is in stock, except not quite as fast as the MPL, but without needing to repeat a bunch of experiments in a bunch of locations to populate the lab with data, instead just needing to provide life support, maintenance and crew rotations to keep the scientists alive.

In career Ion Drives, their power system and Xenon (especially) tend to be so expensive that it works out cheaper to use 1 LV-N rather than 1 Dawn, even for a 10kg payload (this is partly because both engines are relatively heavy and can easily dominate the weight of the payload). The ion drive will be A LOT lighter than the LV-N which does equate to a smaller launch vessel, but launchers of the scale required to launch a single LV-N are very cheap, but that lightness becomes a bigger benefit the deeper the staging goes. Where the ion drive shines, is when you can't get enough dV out of a single LV-N, what you then do is put an Ion Drive stage on top of the LV-N stage, this results in my standard low cost high ejection thrust high-deltaV stack for small (<1t) payloads which I only really use for Kerbol rescue contracts: 3000m/s chemical (Twin-Boar first stage) 3000m/s chemical (Skipper second stage) 8000m/s nuclear (LV-N third stage) 10000m/s ion (Dawn forth stage - can easily be raised to as high as 20000m/s) It's hardly ever economical to skip the LV-N and go directly to the Dawn, but using a Dawn on top of an LV-N is a lot better than using an LV-N on top of 5 LV-Ns which are on top of a Triple Mammoth... So in career my opinion is the Dawn is mainly only useful as an upper stage on top of an LV-N when the LV-N alone can't provide enough dV. In non-career the Dawn is useful for ultra lightweight challenges. Also if you have a superior power system (i.e. small fission reactor) it can be more attractive to skip the LV-N - half the niceness of the LV-N is that it doesn't require a power system which for Dawn is either heavy (solar panels), extra heavy (fuel cells), heavy and expensive (RTGs) or tedious & limiting (batteries + many small burns with long breaks to recharge), a micro fission reactor can make those problems go away - though the other half the niceness of the LV-N is it provides 4-10x the TWR with an appropriate fuel load, making burns quicker and taking more advantage of oberth effect.

I've also been thinking about this WRT Kerbalism and RSS. It's critical to take into account that stock uses a compressed time scale (6 hr days), for example an orbit of Kerbin is completed in ~30 minutes, compared with an orbit of earth in ~2 hours, so eclipse times are 1/4 in KSP compared with IRL, another example is mission time: the transfer to Duna is ~200 (6hr) days, compared with ~200 (24hr) days to Mars IRL. For balance purposes - achieving a realistic mass ratio of solar panels to batteries or a realistic mission lifespan on batteries - either battery capacities should be quartered or solar panel production and all consumption should be quadrupled. If 1EC = 1kJ then the OX-4L 1x6 panel massing in at 17.5kg and producing 1.64EC would be producing 93W/kg, this happens to be almost exactly right for a modern satellite solar panel (70-100W/kg). So by this reasoning, 1EC = 1kJ works really well if we assume that instantaneous power production vs consumption is at realistic levels. (there is also scope for better solar panels, the best solar panels might achieve 300W/kg) If 1EC = 1kJ then the Z-100K battery massing in at 5 kg would have an energy density of 0.02MJ/kg. Quadrupling the EC to normalize at real timescale results in an energy density of 0.08MJ/kg, which happens to be about 1/2 that of a lead acid battery or 1/4 that of NiMH. Given that KSP batteries enjoy arbitrarily high charge/discharge rates, 100% efficiency, no self-discharge, no memory effect and suffer no decay that is actually fairly reasonable. (this also leaves scope for better power density: up to about 4x higher would still be in the bounds of the plausible)

Yeah that's what I'm doing at the moment, it works fine for my purposes but is limited in adaptability since it can't adapt to presence of "optional" mods. You can use mine, it's not perfect but it works well enough. I also included the Settings.cfg since it adjusts solar storms. kerbalism-rss-profile Thanks for the explanation of what's going on under the hood, I suspected as much. One thing worth mentioning is that in my RSS profile virtually all the changes are either multiplying or dividing by 4, basically I used a script which rewrote the default.cfg with these changes: interval x4 or rate /4 if interval is not defined (exception: EC remains unchanged) input /4, output /4 (exception: EC) radiation thresholds x4 Finally since I wanted to keep EC "instantaneous balance" the same I used a MM patch to increase EC storage of all parts x4 to account for longer eclipse times and to make battery powered missions more viable, this felt like a simpler solution than adjusting all EC consumption and production across the board. But anyway, my point is that all the bulleted changes could be ideally applied by setting a single variable: "dayLengthMultiplier" or the like.

@ShotgunNinja I'm working on a profile for RSS which renormalizes around a 24hr day - I'm using it in a RSS game but am still improving it. I'm a bit of a noob when it comes to module manager, my question is, is it possible for a MM patch to reach into the kerbalism profile or settings? There are some things I'd like to do like change processes to liquid fuel -> methane etc, but only if realfuels is installed. Also, one of the things which needs to be renormalized is the solar flares, which should occur 1/4 as frequently and last 4x longer (they are extremely "spammy" on the time scale of a mission to Mars), but the solar flares are currently defined in settings.cfg.

I'd tend to recommend USI-LS if you want a forgiving and stock-a-like life support system well-suited for a "fantasy space program" involving big stations and bases and stuff. It's good if you like to run many missions at once (i.e. managed using Kerbal Alarm Clock) because it's exceptionally low in scripting, using stock mechanisms. Kerbalism is awesome but it is quite exceptionally unforgiving, it introduces many, many ways for kerbals to die (and of course, the ways to keep them alive). I find it a rather "micromanagement" orientated mod, lots of details, lots of things which can go wrong. You definitely don't want to use it if you want to run two dozens missions at once (both because of the level of attention required, but also because it's scripting-heavy so you'll possibly run into performance issues or annoyances if your space program is too big), but if you want to run a "real space program" and get the feeling of having overcome the challenges of staying alive in space I'd super highly recommend Kerbalism. I find the progression in Kerbalism to be very reasonable, progressing from Orbit->Mun->Minmus->Duna/Eve, you'll experience new hazards each time. Getting to Jool and home again would be a super accomplishment. I find TAC to be like a rather easier version of Kerbalism, for example in Kerbalism along with having to provide food, water, oxygen and EC there's a good chance your kerbals will die of radiation poisoning on a round trip mission to Duna, unless you put a lot of effort into radiation mitigation (shielding, short trip times etc), they can also go insane, furthermore parts can malfunction which can also obviously be lethal if it's something that keeps your kerbals alive or which they need to get home, malfunctions can be mitigated through redundancy (at last a reason for triple redundancy) and setting part quality to high and usually a kerbal/engineer can repair a malfunction (I could see some players would get frustrated with malfunctions, but it's probably one of my favorite features of Kerbalism - it's really well implemented). With TAC you basically just have to bring enough stuff to keep them fed and watered, it's a lot more predictable and less hazardous.

Altough in Kerbalism a nitrogen/oxygen atmosphere is used, presumably at 1atm, and would mass in at 8kg. Pure oxygen atmosphere at low partial pressure is very favorable to venting/leaking compared with oxygen+nitrogen.

That's not it. What it comes down to is the rules like these: @PART[*]:HAS[#CrewCapacity[>0]]:NEEDS[ProfileDefault]:FOR[Kerbalism] { You need to copy these rules from Default.cfg and change the :NEEDS[ProfileDefault] to match the name you use for your profile (if indeed, you want that aspect in your profile). Then when you change the profile in settings.cfg, the rules in Default.cfg won't be loaded, but the rules in your new profile will be loaded: the required stuff gets loaded, with no doubling up.

When I get unwelcome hitchhikers I often forcefully eject them on the launchpad, this leads to a long tumble down the side of the rocket to the ground then they have to stand in the plume of the launching rocket as punishment. It doesn't learn them tho, they still do it again.

@michanstKerbalism will slaughter your kerbals. They won't have the life support they need to stay alive for long. Actually you'll experience probably 100% attrition rate even in a new career with Kerbalism because it's very harsh, but in any case you should expect all your kerbals to die.

It does make sense. The idea is that a mission to Duna should result in about the same amount of supplies requirements as an IRL mission to Mars, since the distances in KSP are shrunk the supply usage is increased.

The formula to use is the volume of a truncated cone, treating it as a cone with lower radius 1.25m and upper radius 0.625m, it should have ~58% the volume of a Mk1 fuselage, 240 units would be 60%, which would be in keeping with the shape which bulges outwards and so would be bigger than a true truncated cone. 160 or 200 units is less than generous but reasonable if an "adapter penalty" is desired.

I usually just delete debris, but I have experimented extensively with recovery & recycling, especially in hard difficulty careers. Rockets built around the Twin-Boar are exceptionally easy to recover because it's got the most excellent drag profile for re-entry (basically being fat it slows down like a dream and the heating isn't too bad). I've even gone so far as to recover ejection stages: This involves a Twin-Boar central core with ~1000m/s of dV leftover in orbit. It starts the ejection burn and once reaching Kerbin escape (having expended ~950m/s) is decoupled, the remaining vehicle goes on to the complete the transfer burn while the Twin-Boar turns around and does a burn to un-escape. Now on a highly elliptical orbit it can be aerobraked back down and recovered. While technically possible with any engine (especially doing many tedious areobrake passes) the Twin-Boar's drag profile makes it particularly pleasant and it's much less likely to burn up than say a Mammoth or Mainsail would be. I also use SSTOs and SSTOs that cheat (by slapping on a bunch of SRBs) a good deal, often refueling on Minmus to get two 5000m/s burns out of them which is enough to get almost anywhere without creating any debris. I've also experimented with recycling LV-N based ships a lot, essentially by always joining the payload using a docking port rather than a decoupler, so after it's job is done the LV-N stage is left with a little fuel and can be refueled and reused for some other task. Most the cost and much of the weight of a LV-N stage is in the engine itself, so once you've put the thing in orbit it's relatively cheaper to refuel it than to launch a whole new one, and it's a lot cheaper to deliver tanks of liquid fuel to other worlds than whole new LV-N engines. The end result is many of my missions have been nearly completely recovered, recycled or reused with next to no debris creation. Still, I can't always be bothered, so usually now I just end up deleting debris.

Hmmm, I'm getting CO2 fatalities at 100000x warp - but only when the vessel is loaded, when warping time at the tracking station it doesn't happen, also doesn't happen at lower warp speeds. What happens is that after a few moments of 100000x warp the electric charge spontaneously zeros out and the kerbals die from CO2 poisoning, funny thing is that at 10000x warp the EC only fluctuates by ~500EC, with 17000EC the ship has plenty of buffer to handle expected fluctuations from time warp. There is no exception in the debug/log, and there is no warning about low power. Just instant EC zero out and instant death. The vessel is a Jool transfer vessel which is exceptionally well equipped, with heaps of solar panels in full sun and massive redundancies in systems, unfortunately it also has quite a lot of mod parts - I activated a NFT nuclear reactor to see if it would make a difference and it didn't, the station can be powered fine by either solar or NFT reactor or both, and in all cases (both functional and dysfunctional) it works the same, so it's not an issue with the solar panels. I also tried restarting the game which made no difference. I decided to reproduce it in stock+Kerbalism and succeeded without difficulty [save file]. I'm not sure what the minimum requirements to reproduce it is (i.e. perhaps a recycler is to blame), but I basically reproduced my vessel, a vessel where there is no excuse other than a bug: 16000EC, lots of solar panels, great redundancy in life support w/ all recyclers including CO2->O2 chemical plant. Put in orbit of sun, warp at 100000x speed and within moments everyone dies without warning, with the EC zeroing out.

There is a known issue where if you EVA and plant a flag then upon returning to the vessel control will be locked out until you either remove the flag or completely exit and restart KSP.

I've noticed a strange behaviour of the IFS Cryogenic Tanks, in brief, the conversion of liquid to gas can be significantly over or under unity in terms of resulting mass of gas Lqd Nitrogen converts into about 5x the mass of Nitrogen In contrast, Lqd Xenon converts into only about 1/10th the mass of Xenon But Lqd Hydrogen and most other liquids I tested convert correctly, including Argon, Ammonia, CO and CO2 I did not find other inconsistent conversions, but I did not test everything. I did the test in an install with only IFS to make sure no other mod was interfering.

Just put that into a .cfg file which is somewhere in GameData subfolders. You can literally put it almost anywhere (as long as it's in a cfg file) but what I do is have a folder in GameData for my personal tweaks (creatively called "personal") and put any custom cfg in that folder, no action is required to make that folder "a mod" as the game loads stuff from GameData indiscriminately. By not using an existing folder (such as kerbalism) there's no problem with my personal tweaks being lost due to mod updates.

This has come up several times in this thread. At the moment nitrogen can only be harvested from atmospheres (using the atmospheric sampling experiment), so unless you're making a base on Eve, Duna or Laythe you basically have to bring nitrogen from Kerbin. Realistically it should be possible to extract nitrogen from nitrate deposits but atm no such option exists, however someone has created a profile that allows (indirect) production of nitrogen from ore.

Ah, yes, that is a hindrance, I made my own config:

You could use TweakScale I used to not like TweakScale, but it works really well for reducing parts list clutter if a mod only provides a very limited range of sizes, and suggests using TweakScale if you want larger parts. I don't really like TweakScale for engines, but it makes a heap of sense for storage parts.

The scaling is exactly the same as how the base game tanks scale, for example if you scale an orange tank down to 1.25m it'll have identical volume and mass to a FL-T800 tank. This scaling factor is related to the cube of the radius: 2.5^3/1.25^3 = 8x, you'll notice an Orange Tank has 8x the volume and 8x the mass as a FL-T800 (or a 1.25m rescaled orange tank). The volume scaling factor from 0.625m -> 1.25m and 1.25m -> 2.5m is 8x, but from 2.5m -> 3.75m is 3.375x

It's worth noting that Near Future Technologies reactors seem to be properly supported by Kerbalism. At least I had lots of problems using USI Nuclear Reactors, but zero problems using NFT reactors.