Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

720 Excellent

1 Follower

About micha

  • Rank
    Sr. Spacecraft Engineer

Contact Methods

Profile Information

  • Location
    Tokyo, JP
  • Interests
    Computer (games); Motorbiking; Scuba-diving; reading; travelling; ...

Recent Profile Visitors

4,104 profile views
  1. I'm not sure it's possible but it's something I want to look into once I get some spare time again. It's the way the KEES experiments are mounted on the experiment holder which doesn't require tools or an engineer which I don't think is doable in stock. It was always Nehemia's plan to remove KIS/KAS dependency eventually. While I love KIS/KAS myself, having mod dependencies is something to avoid wherever possible.
  2. Thanks for posting the solution as well. Sorry for not replying but I'm not able to test right now to see what it could have been.
  3. Awesome, thank you! I'll have a quick play with it "soon" and see if it all works as expected, but, unlike a lot of stuff here, CLS isn't exactly rocket science It's more a case of what the mod authors consider apppropriate for their parts which is why I would prefer the mod authors to provide CLS patches. Otherwise it's my (or users') best guesses.
  4. I'm afraid I don't know ShadowWorks or Tantares or what they are/do (and don't have the time to chase them down either), but if those mods recently had a major update I'd check to see whether the mod changed its support for CLS. It's pretty easy to write a MM patch to put CLS support back in if they removed it . If necessary I can help you if you give me direct links to the mod(s) and part(s) in question. EDIT: In particular it seems Tantares recently wiped their entire repository and started from scratch 2 weeks ago. I found some note in thier dev thread saying that CLS is supported out
  5. The error message is pretty straightforward - either the destination is full (you say it's not, so I believe you), or the parts are not internally reachable according to CLS rules (quite likely). You have to make sure that all parts (and specifically the nodes which connect the parts) between the source and destination parts at the very least allow Kerbals to "pass" through them. I see that the Eridani port is a size0.5 node - that is generally considered to be too small for Kerbals. You can override it using a ModuleManager patch (it's considered bad practise to edit the part config
  6. Sorry I'm not sure what you mean. Could you possibly mock up some images to illustrate what you want?
  7. Welcome to the madhouse! Actually, this is a pretty chill online community on the whole - better by far than most! Enjoy!
  8. Dang but that is an awesome changelist! Well done guys!
  9. 1.8 moved to a new version of Unity (2019.2.2.f1) and thus DotNet (4.x up from 3.5) which may have helped.
  10. You're talking IRL. I believe most other people here are talking KSP (where a Pod is a single item, not a collection of (redundant) subsystems). Of course, I reserve the right to be utterly wrong on this The OP was (I believe) saying that it doesn't make sense that a fully assembled Pod consisting of chassis plus all integrated subsystems and components costs the same as a parachute system. And I'd go out on a limb here and say the same is true IRL; that is, that a fully assembled command capsule (eg, Dragon) costs WAY more than the parachute subsystem integrated into it (IRL, the parachut
  11. Methinks there might be miscommunication. "Pod" != hull. "Pod" == hull + avionics + lights + life support + ....... Just like "parachute" != "canopy" but "parachute" == canopy + rigging + deployment mechanism + ....
  12. Umm... hardly. What primarily chews up memory is that the way KSP was written, ALL assets are loaded at the start and held in memory at all times. That's sounds, textures, models, etc etc. Most other games load levels or assets "on demand" which does slow them down a bit at times, but reduces their memory footprint significantly. Code itself is generally small. Maths functions in particular don't allocate memory so they barely impact RAM. There are lots of management and informational functions which DO use up lots of RAM though because they are constantly allocating memory. Poorly writt
  13. Well, they've only got a couple of body retextures left to do which will complete the promised stock texture revamp. Who knows what other feature additions they have planned though (there's a couple I can think of which the community has been somewhat loud about..). So maybe after that things will calm down a bit for a pure stability release?
  14. v2.0.0.6 is released for KSP1.11. Fixes a few issues and adds more part configurations. Please see the Changelog. Notably the StockFreedomAddon configuration is now enabled by default to have less restrictions. Also the "Enable Optional Passable Parts" option now takes effect immediately making it easier to tweak a parts' passability on the fly.
  • Create New...