Jump to content


  • Posts

  • Joined

  • Last visited


237 Excellent

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

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

  1. [...] I found it easier to set up small MKS bases first because the individual parts are far more manageable. I play on RSS and the Wolf parts are just monstrous and, because the parts can't be split, they require monstrous launch vehicles, at least until I had on-orbit construction facilities and the transport routes to go with them. With MKS there are lighter parts available for all functions, they have more manageable form factors, and often you can supply the MK to kit them out separately, that's a huge help with RSS in career mode, where the launch pad limits are a real challenge for getting Wolf parts into orbit until you can afford all the upgrades. So basically I used MKS to bootstrap my initial manufacturing capabilities, which I then used to get Wolf parts operational. That makes we wish for a "Startup Wolf" style of parts with reduced part diameter, mass and (of course) Wolf throughput. Something like a tenth or a fifth of the capabilities of the existing parts. Wolf seems to be ideal for high-throughput bases, not so much for initial bootstrapping. I'm not sure if the wolf resource numbers have to be integer, or if I could create smaller 1.25m parts with 1/10th the corresponding Wolf numbers. Or possibly just make some of them compatible with TweakScale...
  2. Since there's an MM patch to add exactly that (MM-StockScienceLab.cfg), at least at one point in the past it was known and intended by someone... That file has been untouched since linuxgurugamer adopted the mod. So if you're trying to figure out why it is so, you'll have to trawl through the original mod's thread instead. I don't think it really makes sense either for StationScience to add it, and caught me by surprise as well, but I was in the process of bringing up the large radiators to my station anyway, so it didn't really matter for me in the end. Although in general KSP space station generate far too little heat that often you don't even need radiators, where in reality overheating is one of the most pressing problems after oxygen, water and electricity are taken care of. Even the Space Shuttle couldn't go to some orbits because it would get too much sunlight and cook itself.
  3. Oh yeah, that's a fair point. Using it as a feeder for standard MKS setups at first, and then moving to Wolf parts for scaling up. I guess I got thrown off by the tutorials that all seem to start at the deep end first. This makes way more sense.
  4. At home, and whatever they choose to buy at the grocery store, I would imagine. Like any employee. It's not like a prison or remote planet where you'd expect the employer to provide an all-expenses-paid stay. Especially since for USI-LS, Kerbals get infinite life support and habitation below 30 km, so why do I need to provide oxygen and complicated life support equipment? We already have one down here, it's called a window! Also from a gameplay perspective, with the need for life support and habitation, Wolf complexity hits you right in the face with everything it's got just to open a transport route to LEO/LKO, rather than only requiring these complexities later on when you're well established in orbit and want to expand beyond. There's little point in offering the depot early in the tech tree when you need all the other modules anyway just for transport credits. Yeah, I think I'll do that, maybe not infinite but I'll add enough, just what's required for the transport credits to LEO. That seems reasonable and a decent way to learn how to Wolf. I don't really think the other biomes need much anyway since transport routes are free, so I'd just have some harvesters there and ship the output to KSC for processing.
  5. Furthermore, regarding WOLF, do I really need LifeSupport (and Habitation) on Earth / in the KSC biome? That's a bit ridiculous... or is that a bug related to RSS and Earth not being Kerbin?
  6. The stock "extract ore" type of contracts seems to be broken again with respect to the MKS drills. Manually changing the ResourceExtractionParameter to USI_Harvester helps though. Is there a way to make this automatic?
  7. No, both MJController and BetterController are options for Mechjeb's attitude control. I don't want to turn off Mechjeb, I want to select which controller it uses for each vessel.
  8. I looked through the manual and tried some searches but had no luck, so here goes: Is it possible to configure different attitude controllers depending on the vessel? I have a station in orbit where attitude control is really twitchy, except for MJAttitudeController which works extremely well even with the default settings. I tried fudging around with the PID gains and settings for the other controllers but that didn't work as well as just switching controllers. However for all other ships, I want to keep using BetterController, because it is, well, better. So is there a way to use MJAttitudeController just for the station? I tried putting the following in the craft-specific cfg file: MechJebModuleAttitudeController { activeController = 0 } and it works once when I switch to the station, but it's immediately overwritten and removed from the cfg so it's not a viable solution. It also changes the global setting, so it doesn't help for setting a different per-vessel controller.
  9. Well there should be only one experiment of each type in the cfg, otherwise people can't know which exact experiment part is required for a given contract. This was discussed here a few months ago, there wasn't any opposition to the suggested solution and the other experiments are disabled anyway, so I just assumed this was accepted. But feel free to leave that change out of the PR. Or keep both sets and hope that users only unlock one part of each type. Like I said above, I don't really care which experiments are in the default cfg (especially now that a MM patch works), but I'd prefer to have the fuel science ones in. For users, the convenient thing to do would be to make this an in-game mod option but I have no idea how to accomplish that...
  10. Well the code changes just make it possible to use any kind of setup in the cfg file, old parts, new parts, or both. As long as you add new parts with the experiments, and set them up in the StationScience.cfg, it should absolutely work as it did before. If you edit the existing parts, people won't see that anyway because those have been disabled for a while and won't show up, neither in the tech tree nor the VAB unless you unlocked them long ago. As for the assets, so far the old parts are only deprecated but still there. Only when they're removed altogether you'll have to be careful that the assets you use now are getting kept. Personally I don't really care which parts are kept (or how they look in fact), just there should be no duplicates (as there are now) and there's maximum variety in experiments, including the fuel science.
  11. Alright, I added the changes, should be all done now as far as I can tell.
  12. I wrote the files and I'm trying to test them now. CTT patches seem to work, but I'm not sure how to test if the RSS planetChallenge values are taking effect. I mean, they're correct in the MM cache but I don't know if it's actually using the values I give. I got a contract for experiments on the Moon, does that mean it's working? Or is it possibly just using a default value? [edit2] Right, adding some good old debug log statements I found that it's using the right values, so I added the files to the PR. [edit1] Oh and do you want a PR for the above Station.cfg changes to use ArcanumIndustries parts? That would have the disadvantage that no more contracts for the old parts would appear. Although I guess those parts are deprecated anyway.
  13. So after looking at it in more detail it was just that, and I found the problem: the config loading code does not clear the settings before loading new entries, so it could only change the existing entries (or add new ones), but could not remove them. I made a pull request to fix it. With that change ModuleManager patches will work properly; I'm now preparing one for the RSS planets/moons that removes the existing ones as well. (Also, unrelated to this bug, better integration with the CommunityTechTree.)
  14. I also had the problem that contracts wouldn't complete, because contracts had an "experimentType" of "StnSciExperiment5" etc. and those parts are no longer available. I tried the above changes, and they made no difference, contracts still required "StnSciExperiment5". I even checked the ModuleManager cache, and the changes were properly applied there. So as a last resort I deleted the StnSciExperiment* part files. And now I wasn't getting any new contracts at all anymore, and in the logs there's a NRE in StationScience.Contracts.StnSciContract.GetUnlockedExperiments, even though the MM cache now has not a single occurence of the text "StnSciExperiment": So apparently there's a problem loading the "STN_SCI_SETTINGS" nodes from StationScience.cfg, because it will use the compile-time defaults no matter what I tried. I think at this point the only workaround at the moment is to delete the old files, and rename the ArcanumIndustries parts to StnSciExperiment...
  15. Thanks for the update! One minor bee, the stock MM patches are duplicated, in LSModule.cfg and Patches/StockTweaks.cfg. So they add their modules twice, however only one of them takes effect. But it messes up the calculations in the editor which considers both modules to be working. So presuming that the file in Patches is meant to be kept, deleting LSModule.cfg fixes the issue.
  • Create New...