Jump to content

Maeyanie

Members
  • Posts

    104
  • Joined

  • Last visited

Everything posted by Maeyanie

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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
  16. Yes, sounds like it can too, at least with lighter payloads, and it does also use an improved (though less so) version of the same engine. So again, could be.
  17. True, the Su-57 can, and it does use an improved version of the same engine. So that theory is certainly reasonable.
  18. Those engines are copies of the ones the Su-27 uses, and it can't supercruise. The plane is a similar weight, too, so TWR should be similar. But yes, it's entirely possible it's due to RJE not being realistic enough, particularly with the intakes.
  19. I used to think it was the unrealistic engines too, but turns out even using RJE engines, and with FAR on hard mode, it's still pretty easy to make a plane supercruise. Even a really bad one. I've posted those screenshots both here and in a Github issue before and Ferram says it's legit... I'm not entirely convinced, but, I'm not an expert on aerodynamics, so I'm willing to accept that I'm wrong. It's definitely much better than stock KSP, anyhow.
  20. Probably the second one. KSP reads everything under GameData ending with .cfg, no matter what it's called, and the tags inside define what it is rather than the name. I'd suggest making backups as "Settings.bak" or similar instead, that should prevent it from being read.
  21. Might be simpler to just disable the Kerbalism reliability system in its config file.
  22. It worked for me. Generally content packs like OPM work fine across minor versions like that, only stuff that affects the core of KSP tends to break.
  23. My personal solution to this has been the Tantares Soyuz parts. I have the scrubber and humidity parts in the main capsule, and the pressurization in the orbital module. It's worth noting that the humidity module has to be enough for all the Kerbals you have along, so putting it in the orbital module (which has a lower crew capacity) will still kill everyone eventually. I may have found this out the hard way.
  24. There is one: https://www.dropbox.com/s/u167tlqjvkus7fj/Screenshot 2018-06-05 12.02.04.png
  25. Apollo missions really don't need much shielding, they're only out for a few days. Even Minmus isn't THAT far away. Only time you start needing a ton of shielding is if you're going on interplanetary trips and expect to be out there for months, if not years. And even then, you could just have the re-entry capsule unshielded so it floats, the part of the vessel which doesn't have to land can be as heavy as it needs. Honestly, I'm fine with the capsule weight balance the way it is, it's never been a significant problem for me. Just have to design with it in mind.
×
×
  • Create New...