Maeyanie

This is how Orbital Decay (the mod I'm presuming he's talking about) handled it. If the vessel had a form of propulsion and the appropriate fuel, instead of decaying it would just slowly eat through its fuel instead, based on its orbit height and drag cross-section. By default it was 10x the realistic decay IIRC, so did change gameplay by forcing design considerations, orbit planning, and refueling missions.

You can also use a .cfg file like this to mark non-FAR parts: @PART[*]:HAS[@MODULE[ModuleLiftingSurface],!@MODULE[FARWingAerodynamicModel]]:NEEDS[FerramAerospaceResearch]:FINAL { @title ^= :$: *Non FAR*: } @PART[*]:HAS[@MODULE[ModuleControlSurface],!@MODULE[FARControllableSurface]]:NEEDS[FerramAerospaceResearch]:FINAL { @title ^= :$: *Non FAR*: } (Just create a plain text file anywhere in GameData named whatever.cfg and copy-paste that into it.) Those parts do still work, they just only produce blunt-body lift. This is perfectly fine in some cases, like some flat-bottomed plane parts which the author gave stock-aero fake body lift; FAR simulates that fine without needing any special settings, so them being marked as a "non FAR" wing doesn't matter. This just acts as a reminder when you're looking through all those wings and trying to pick ones which are properly simulated. Edit: As an idea, it might be useful to have links to 3rd party FAR compatibility patches in the OP, to make them easy for everyone to find... unless there's some thread for those I don't know about or something.

It's not all that huge any more, since the updated stock aerodynamics are less soupy than they once were. It used to be quite a lot less, and I think a lot of the people who complain about that are basing it on how FAR compared with the original stock atmosphere model, or repeating other people who were.

I'm not sure if this is causing this particular problem, but Dynamic Battery Storage is a known conflict with Kerbalism, and NFE does seem to work without it despite it being listed as a requirement. Usually the symptom is kerbals suddenly running out of life support in timewarp, but it might be worth trying without this to see if it helps here too.

Yes, FAR includes a "RealChutes Lite" plugin, due to the fact regular stock parachutes don't work in it. You could remove this from your FAR installation, but while that would give you nice spread parachutes, they wouldn't actually slow you down... which might kill you a little more literally.

One trick that real-world rocket designers do to make them less unstable is put the denser of their fuel or oxidizer near the front of the rocket. That's not really an option in KSP (technically possible with RealFuels or similar, but complicated to get the ratio right), but if you have more than one tank on your first stage, setting flow priorities to empty starting from the back gives a similar stabilizing effect. I don't see too many people using this, but it can help quite a bit for rockets that normally somewhat aerodynamically unstable... won't save the very unstable ones though.

One thing of note here is that the body can repair radiation damage somewhat over time on its own, so receiving a "lethal" dose over 21 years is probably fine. For an example with humans, an immediate 8 Sv dose is considered lethal even with medical treatment. However, Albert Stevens survived a total lifetime dose of approximately 64 Sv over a period of roughly 20 years, before he finally died of heart disease at age 79.

It would be nice if they slowly healed while on Kerbin, at least as an option. Not instantly like now, probably even slower than the anti-radiation thing. It'd give a reason to have some depth in the crew roster, without leading to disposable kerbonauts.

Right, forgot about that. That one's a bit harder. Though it looks like it's only used for the cross-sectional area graph, which is definitely very useful but could be lived without if the maintainer isn't up to that particular challenge. Honestly, it still seems like even fixing the currently-known bugs in the 1.4 version is the toughest part.

The license issue would basically just require the person to make new icons, not all that difficult compared to actually updating and maintaining something like this long-term.

It is, but it may not be obvious to everyone that there's also a regular end-user download there in addition to the source. Though, the Spacedock link works perfectly well, so I guess it's not really needed. Just seems lately that there's always some problem or another with the CKAN install of Kerbalism in specific... bad download sizes, some files not getting installed, etc.

Unfortunately, Kerbalism on CKAN being broken is pretty standard... it might be worth removing it from the suggested install methods on the first page, maybe replacing it with a link to the Github releases in case people want an alternative to SpaceDock.

Plus, Kerbals aren't linearly-scaled-down humans, they're far wider. So makes sense for them to have 1/4 volume rather than 1/8 volume. Balancewise, the 1/16 human consumption seems easy enough already, especially combined with the short distances. No need to make it any less.

One of the things various hypothetical RL spacecraft do for this is to use their water tanks as radiation shields. Not really any extra mass, since you need to carry the water for the crew anyhow, and it's very good at the job.

Using Blender 2.79 and git version 49e9ab0 , Trying to import a .craft file gave me this error: Traceback (most recent call last): File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\import_craft.py", line 95, in execute return import_craft_op(self, context, **keywords) File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\import_craft.py", line 70, in import_craft_op obj = import_craft(filepath) File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\import_craft.py", line 56, in import_craft part = gamedata.parts[pname].get_model() File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\part.py", line 68, in get_model self.cfg, loaded_parts_scene()) File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\model.py", line 57, in compile_model scale = parse_vector(n.GetValue("scale")) NameError: name 'parse_vector' is not defined It doesn't seem to happen for every craft, though. The one I pasted this from was RO RN Sputnik 1 (though it did happen with some others as well.) Also, the "Install KSP Shader Presets" button gave this error: Traceback (most recent call last): File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\preferences.py", line 55, in execute install_presets("shaders") File "D:\Blender Foundation\Blender\2.79\scripts\addons\io_object_mu\preferences.py", line 30, in install_presets dst=presets[-1] + "/" + shader.IO_OBJECT_MU_MT_shader_presets.preset_subdir NameError: name 'shader' is not defined