• Content count

  • Joined

  • Last visited

Community Reputation

1,372 Excellent


About DStaal

  • Rank
    Capsule Communicator
  1. [1.3] - Modular Kolonization System (MKS)

    Good to hear. I expect he's waiting for the next release. I should also update the PatchManager configs slightly - I left some 'optional' fields empty, but that's meant things are blank in the UI.
  2. It accelerates every launch, from what I understand. However, there are other things can accelerate launching the game, including the fact that the OS will cache files, and that MM will cache configuration changes. So the procedure listed is what you need to run through to see how much *this* mod accelerates it, on it's own. Otherwise any comparisons might be swamped by other factors.
  3. USS NIMITZ and Drydock

    I'm not all that interested in the Nimitz, but: Does that drydock have EL integration?
  4. [1.3] - Modular Kolonization System (MKS)

    And just because EL is no longer officially supported it doesn't mean it doesn't work. It just means you'll get no help from RoverDude and there will be no MKS parts for it. He's happy for users to contribute PRs keeping support. (Speaking of, if I have some time today I should update that...)
  5. VTOL pilot aids?

    TCA is the choice. Note it does still have trouble with some air-breathing engines on occasion - mostly because the throttle lags, and TCA is continually adjusting the throttle. Do expect a learning curve. TCA is powerful and complex.
  6. [1.3] - Modular Kolonization System (MKS)

    Note that 'controlling the craft' is a specialist function. But that's basically what the 'tourist' setting gets you - they'll stop working until you take care of their timer, at which point they'll revert back to their original class/level. Also, if you look at the USI-LS configuration panel you'll notice that homesickness and habitation are already separate - they have separate timers, and can have separate effects.
  7. [1.3] - Modular Kolonization System (MKS)

    Personally? Both. Use GC for initial base planting - you can land a DIY kit of your base core, and build it out using a lander or a drop-pod and inflatables. Long-term, larger more complex bases are easier to build using EL and surveyed builds - easier to put it exactly where you want, and for something large and complex, the size of the DIY kit gets awkward to ship up - while EL will just have you sending multiple stocks of resources.
  8. I like it. I also like the idea of putting it in a Patchmanager-managed patch - you could make it so it's default on, and Patchmanager isn't needed - it just gives it an easy way to select to turn it off. That would allow players to play with how they want it.
  9. Looks like you have two, probably valid, choices. Let's examine. @PART[super25nosekso]:NEEDS[KSO]:FOR[z_KSO] Should work fine. *Creates* the mod 'z_KSO' and applies this patch during it. @PART[super25nosekso]:NEEDS[KSO]:AFTER[z_KSO] Again, valid - assuming 'z_KSO' exists. This runs the patch *after* z_KSO. So if these two were both in the same file, this one would run after the previous one. Another option that you might consider: @PART[super25nosekso]:NEEDS[KSO]:AFTER[KSO] This would run it *before* either of the two choices above (since mods are done in alphabetical order), but it would run *after* the KSO mod's own patches. If the point of the 'z_KSO' is to run after KSO, than this should work. (Assuming the patches in KSO aren't using ordering of their own.)
  10. Yeah, looking at the JX2 patch, and the OPM patch, it doesn't look like the patches can be automatically applied in the correct order at the moment. The problem is that the JX2 patch is :FINAL. If that were changed to :AFTER[OPM], then your patch could be applied :FINAL, or you could use a custom name with :FOR that's after OPM, and it would work. But since the JX2 patch is :FINAL, there's no way to override it.
  11. And I'm of the 'never add code you don't know you need' school of thought. But yep, there are good arguments either way. (Though I will mention on your cache statement - for those of us with a lot of mods, it can be rare that we load an unmodified gamedata - just updates to existing mods can be enough that every time you have a chance to start KSP there's more new updates.)
  12. My only comment is that I suspect you don't need the 'AFTER' at all - the parts are loaded before the MM run I believe, and unless there's something that would interfere with adding that module I'd personally leave it out. On the other hand, even if it's not needed I don't think it'll hurt - it'd just make MM work a bit more.
  13. Patches not applying, or applying incorrectly is most likely. With the exception of the :FOR. That causes *other* mods to have errors, where patches were intended to be a skipped (and may not work) are now being applied. It may even cause them to disable functionality that they would have otherwise had.
  14. KIS jet pack addon

    Using KIS to equip isn't likely to be possible, based on the way that KSP and KIS works. However, there are several mods that have packs that allow you to carry a jetpack, deploy it, and then get into it. (Basically, a small external seat.) First to come to mind is Buffalo, which has a small jetwing you can fly on. Another - fairly outdated, but it still worked last I tried it - mod that has a nice pack is Versatile Toolbox System, which has a large RCS pack. https://spacedock.info/mod/793/Buffalo- Explore In Style
  15. I'd leave it: There's another very good reason for it. That is: Solar panels. If you have them, that 95% will mean the fuel cell will only run if the solar panels aren't doing enough to power the base. If you set it 100%, then you can have an abundance of solar - and still be running fuel cells, and using fuel. (USI does the same with reactors for exactly this reason.)