• Content Count

  • Joined

  • Last visited

Community Reputation

224 Excellent

About jd284

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, thanks, that was it. I did look at the issues but didn't realize it was a drill issue rather than a TCS issue...
  2. Is there a description of this? But anyway my problem isn't that the separators don't produce what they should (they do), but that they overheat doing so. You seem to confuse MEU-500 (the drill) and TCS (the ranger heat pump). But yes you're right, when I tried it again additional cooling systems (ranger TCS or radiators) didn't help actually. So the problem is that the drill can't move its heat fast enough to the cooling systems. But still that doesn't make sense, why would the drill have three separator bits when you can only use one of them at full efficiency without it overheating? That actually makes the bigger drills less efficient and more expensive than many smaller drills adding up to the same production capability, which the TCS can cool with no problems. I doubt that's the intended behavior.
  3. Did the Ranger Thermal Control System get super-nerfed? I used to be able to have just one of these for a whole base of nuclear reactors and dozens of drills, now it's not even enough to cool two bits of a MEU-500 drill. If I have one bit running it's at 500K, but two bits it's 622K (only 63% efficiency) and three bits it's 667K (41% efficiency). It doesn't even matter whether there's an engineer present and the drills run at 65% load, or not and they run at 3.5% load. Strangely enough this is true even for multiple drills, so it's not a problem of the TCS being overloaded but it not getting the heat away from the drills, it seems. Either way at the moment I need three TCS for every two drills... so it's pretty useless. Or is this a KSP bug itself?
  4. Is it possible to reduce the volume of the warp sound effect? It seems to be extremely loud compared to other sounds in the game. I basically have to turn off my speakers when warp is active. [edit] So after looking into this a bit more, I changed the drives to ModuleEnginesFX and defined an EFFECTS section accordingly. If anyone wants to try, download the files from https://github.com/jd284/WarpDrive/tree/patch-1/FOR_RELEASE/GameData/UmbraSpaceIndustries/WarpDrive/Parts I noticed the older parts have some particle effects which I left alone, not sure if they still work or if they also need an entry in the EFFECTS section now. But if so I don't know how to do this correctly. Should I make a PR for this anyway?
  5. For me it only worked after I deleted Mercury, Neptune and Uranus from the RSSKopernicus folder. Running on 64bit Linux. With those planets left in it will lock up while loading. Not a big deal for now since I'm not planning to visit them for quite a while yet.
  6. How do I disable the saves created on deployment and launch of the kits? I have a good savegame management so I don't need this and it clutters my quicksave list. Didn't see any options for this in the settings or config files.
  7. How do I express a condition "has ModuleA OR ModuleB OR ModuleC"? I tried various things like @PART[*]:HAS[@MODULE[ModuleA|ModuleB]] or @PART[*]:HAS[@MODULE[ModuleA,ModuleB]] but it only ever got applied if I have a single module name there. Is such a thing supported or do I have to copy my block many times for all possible combinations of modules?
  8. Yes. However, if you have USI-LS the life support is shared between vessels, so you only need one setup for recyclers and habitats and such. But efficiency bonuses are per vessel only.
  9. Yes, they have to be on the vessel. Doesn't have to be engineers though, miners also improve the drill efficiency.
  10. In my opinion, that shouldn't be the job of MKS. There are plenty of mods that add interesting failure modes, and I don't think MKS needs to reinvent that wheel. The main problem I have with adding failure possibility is that it doesn't really work very well with KSP's (non-existent) model of background processing. If a failure happens, and I can't immediately react to have it taken care of, it's a bad design. So basically, failures should not ever happen during catch-up of background processing, only at the end of it. I don't want to come back to a colony after several months only to find that it failed and nobody told me. Nor do I want to visit every colony every day just in case. Personally I like the way machinery works, perhaps it's just a bit too "smooth" though. Maybe making it operate in steps would work better? Instead of linearly scaling throughput with amount of machinery, you could have steps of 25% and each time machinery falls by a quarter, throughput reduces by another 25% step. Like having multiple machines inside, and each time one of them fails.
  11. It's possible that this is a new biome or it just wasn't accessible up to now. I think there was a bug like that although I didn't see it mentioned in the change log. Or maybe it's only accessible at level 2 and I've never noticed it before...
  12. I tried to balance the crew of my various bases to make the kolonization stats grow somewhat equally, but manually counting heads and checking how many crew present increases which stats go tedious very quickly. So I decided to change the kolonization monitor to display how many crew are present that increase each of the three kolonization stats. The coding wasn't too hard so I committed and pushed to a branch on my fork. So far so good. However when I tried to make a pull request from there, it included a dozen other commits and listed some changes to CustomAstronautComplexUI.cs that I didn't make... see here. Is this normal or did I make a mistake? I'm not very good with git, it seems to be completely orthogonal to my way of thinking. So please let me know if I should go ahead with this PR as is or if I need to fix something first, thanks. [edit] If I make a PR against MKS/master instead of MKS/DEVELOP the unexpected CustomAstronautComplexUI.cs changes don't show up. But I believe all PR's should be against DEVELOP?
  13. Very late reply, but I've been thinking about this on and off for a while. First, I don't think either velocity or linear or angular momentum conservation is any more realistic than the others. I find it just as wrong when you move closer to the sun and gain velocity out of nowhere just to conserve angular momentum. The only reasonably realistic way to fix this would be to conserve both energy and momentum. That's possible, of course, but only following the (non-warp) trajectories. That means the warp drive would just boost you along your trajectory at warp speed, but not be able to change the trajectory. I'm not sure if it's worth implementing that mode though. It would be kind of interesting and quite realistics, but probably pretty useless for gameplay, since effectively it does nothing the time-warp button doesn't do already, more or less. (Except that it happens in less game time of course.) So you'd still need to do all the usual delta-v changes using regular drives, plus you've got a super-heavy warp drive to include in those delta-v calculations. I doubt that'll be a very popular option...
  14. Is there any information yet about the requirements to deploy the upcoming new huge base parts? I think Roverdude mentioned that they need high enough Kolonization scores. How high are we talking and which score(s)? Just curious if I need to make a special effort to raise my scores (they're mostly between 150 - 180%).