Jump to content

DStaal

Members
 View Profile  See their activity

  • Posts

    4,001

  • Joined

  • Last visited

 Content Type 

Everything posted by DStaal

  1. DStaal
    I'd dislike that - as it interferes with my usage (though another mod) that turns the lights on when they have a Kerbal in them. (Though it does seem like an ideal case for Indicator Lights support...)
  2. DStaal
    Sure. It'll add some parts, but I don't believe it does much to any of the parts you have. If you want to be careful, you can recover any ships in flight and Kerbals, but I don't believe it will be necessary. (Especially so early on in your career - you likely don't have any large life-support systems running yet.) This sounds interesting, and should definitely be achievable via MM.
  3. DStaal
    Better way to think about it (and closer to what's actually going on) is that *none* of that works in the background - it just pretends it does. You show up and it quickly does everything as if it had happened in the background, using the current situation. And yes this can be abused. If you never check your solar-powered Mun base during the night, it'll say 'oh, you've got enough solar power for these to run, so they kept running'... (On the other hand, note that the counters in the USI-LS window are just straight-line approximations based on the last time those Kerbals were seen. If it says you've run out of EC for some ship, and you've got solar panels and the next time you visit is during the day... They've had EC.)
  4. DStaal
    I can see some disadvantages. First off, it's fiddly. Players will have trouble understanding why different Kerbals have different timers on the same station, or how long they need to 'stage' a Kerbal on a station to get the home time from it. Secondly, it's awkward: If you're adding to a station to prevent your Kerbals from running out of time, how much time ahead do you need to add it? Right now, if you add it one second before they run out, you're fine. With yours... When does the increase come into effect? Does it matter how much there was to start with? How much you're adding? etc. I see the realism argument - but I don't think the small addition to realism is worth the complexity overhead. I do think disconnected home/hab should be limited to surface bases however. It makes sense there, but it really doesn't in space.
  5. DStaal
    Just to clarify: Having spaces in the part names won't cause KSP to *crash.* It may cause other assorted weirdness however - MM patches applying inconsistently, parts doing weird things in the tech tree/VAB, etc. I've never heard of a crash because of it. Just general wonkiness.
  6. DStaal
    In the part 'name' in the .cfg file for each part. You've got a line probably near the top like this: name = Science_Crate (This is from another mod, it was just easy to grab.) Putting spaces in that 'name' causes issues with MM and occasionally with KSP. It's much better (like above) to use underscores or periods instead. Also worth noting is that 'name' has to be globally unique, and is never shown to the user. Typically it's a good idea to make the name start with something related to your mod, and not use something generic. (The mod above sorta did - it's the one part in the mod, and it's the same name as the mod...) However, changing that name makes it a *different* part for KSP, which causes ships with the part in a game to be deleted and vanish on players, so do that *very* rarely. Basically: That name is how *KSP* identifies the part. Spaces work, but only sorta. Make sure it's unique and stays the same. It does *not* need to be pretty.
  7. DStaal
    My solution to this problem is to set node alarms to *pause game* by default, not 'stop warp'. Then MechJeb cannot auto-warp past it. Though I did tend to also just pull up the KAC panel and check to see if my next action is going to be before or after the next alarm. If the ship you're watching isn't the next one that needs an action, there's no particular reason to watch it, after all.
  8. DStaal
    I'm thinking that's part of Buffalo/Pathfinder. It only works with specific engines.
  9. DStaal
    An essential around large stations and ships. Thanks.
  10. DStaal
    Passible just means 'can enter and exit', even if it's through the same node. I'd set these to be passible, or use the more detailed syntax and set only the docking connection as passable. (I will also admit that when working with MKS and Pathfinder, I kinda wish that node *wasn't* a docking port, but was instead a regular port. Then I could use Konstruction ports and make a stronger structure. But I can see that it's better if you aren't using a mod that adds those to have the integrated docking port.)
  11. DStaal
    One comment, looking at the mod distribution: Most users would probably prefer you integrate the optional patches using :NEEDS syntax, so they automatically apply when needed instead of the user having to look through and see which patches they need. (I'm also not sure why the CLS patch specifies that the parts are *not* passable - I'd assume they should be passible, mostly.)
  12. DStaal
    Beautiful.
  13. DStaal
    No problem. If we had a FAQ, this question would be in it.
  14. DStaal
    That's in Freight Transport Technologies, not MKS.
  15. DStaal
    No promises anyone will get to look at them soon, but most likely the issue can be tracked down with pics of your Gamedata & USI folders, and (possibly needed) a link to your log file.
  16. DStaal
    Here's how I think the code should look. It's pretty close to what's currently there: @PART[KSO_Habitat]:FOR[KSO]:HAS[!MODULE[ModuleLifeSupport]]:NEEDS[USILifeSupport] { MODULE { name = ModuleLifeSupport } //etc... It should not be 'FOR[USILifeSupport]' - that's always been a bug. And having two 'FOR' blocks has always been non-sensical, but will throw errors in the newest version of MM. (Before it was silently ignored, with only the first being applied.) You could drop the 'FOR[KSO]' if you wanted - it's not really doing anything, but on the other hand isn't causing harm and is technically correct. And if you look at the file in question, you'll note I've removed two lines that didn't really do anything, and likely would cause syntax errors. The rest of the parts don't have the 'FOR[KSO]' but do have the 'FOR[USILifeSupport]' which should be changed to 'NEEDS[USILifeSupport]'. You also have ReplacementParts being added into some of the parts - this was depreciated, but might be making a comeback. So up to you whether you want to delete it or not.
  17. DStaal
    I mentioned it because I knew an update for one that I was following had come out, so I was sure I should have gotten one. (And by the time I need to deal with some service like that, monit has typically unmonitored it on it's own, given my normal settings.)
  18. DStaal
    From what I recall, the only support it really has is a couple of containers that hold USI-LS resources. As the resources haven't changed, it works just fine. No, but also no. It's been fine so far. I would love a bit of an update - a few more resources, and a couple more racks would be nice - but there's no problems with it.
  19. DStaal
    For reference, I still don't seem to be getting alerts that mods are updated. You should be able to kill & restart the services, then remonitor them directly in monit. Though if you have services that are being started up without registering a PID and are supposed to on a regular basis, you've got deeper problems.
  20. DStaal
    He'd probably love to - but I think he doesn't speak Chinese. So he'd need someone who does to submit it.
  21. DStaal
    KSP doesn't compute what happens for converters on ships more than ~2km from your current location, for efficiency reasons. Planetary Logistics doesn't change that. If you switch to a ship, it'll quickly act like it's been producing all along, but it's just doing it as a quick catch-up. Without a mod like Kerbalism (which is incompatible with MKS) nothing's going to change that. The Planetary Logistics window will show what's *currently* in storage - and will be updated next time you visit any of the ships putting stuff in or taking stuff out of it. It will not get updated unless you do that. This is not a bug. This is everything working as intended.
  22. DStaal
    The rover windows light up just fine for me. Note that they aren't in the 'lights' action group by default. (You can of course add them - but they're just glow panels, not illumination sources.) The Scorpion engines are designed to be placed on the *side* of your rover, and then folded down. Without using hover mode it does take some balancing to get a craft to work. Enable hover mode. Both of these issues make me think you haven't looked carefully at the right-click menus on these parts. It's worth taking a look at. There is a rear fuel tank. I can't remember off the top of my head what it can be switched to, but I know it has a fair number of options. Or just put a bumper on any of the freight models that carry what you want.
  23. DStaal
    I've got a better reason for you Snark: The original mod still exists!
  24. DStaal
    ...Or KSP just doesn't have those glyphs installed in it's font.
  25. DStaal
    Tanks semi-randomly changing contents back to 'defaults', I believe. (I haven't seen the issue myself - but I haven't bothered to debug why my modded install won't launch in 1.3.1, and it's a *very* new feature, so I haven't been running it.)
×
×
  • Create New...