jd284

It depends on their level. You get two points per star, i.e. a five-star engineer gives ten points, a zero-star rookie only adds one crew point. You can hire them at two stars and get four points each for no effort (just some extra hiring cost), or train them to five stars to save on life support infrastructure with fewer crew required, just like with MKS. With two-star hires just a flag-planting trip to Mun and Minmus should give them four stars easily.

Thanks but you linked KER_WheelBay.cfg, can you link the actual KER_Wheel_01.cfg? I would LOVE having functional Karibou wheels again.

That page mentions a ground shipyard, but that doesn't exist, does it?

You should add all USI mods at once. They have multiple dependencies on each other, giving you the "assembly not found" errors if one is missing. Or otherwise figure out each mod's dependencies individually and add those along with each mod that you want to install. That's going to be necessary for most non-trivial mods too, not just USI. However most people just rely on CKAN to do this for them.

The ContractConfigurator file will not help with KEI. But I don't know how KEI does this, you should probably ask in their thread how to exclude the fuel science experiments.

I recently made PR #721 to ContractConfigurator to fix the fuel science experiments, bringing them in line with the rest of Station Science, however this should affect all three of them the same. There does not appear to be a different setup for just Rocket Fuels so I don't know how that could be working differently. I also don't have Kerbal Environmental Institute, but it probably also has a StationScience config of its own which is missing the fuel science experiments since the mod merger.

Is there a way to predict the construction cost of a ship from the VAB? Like how many alloys/electronics/etc. it will cost? It seems totally random to me...

I had a similar problem with the "Bad Location" display instead. That led me to investigate about the allowed locations, and unlike all other StationScience experiments, the Plasma Fuels experiment has a "situationMask" of 32, meaning "only when high in space". I'm not sure if this is intentional since it's not mentioned anywhere in the experiment description or elsewhere... however as far as I can tell it's been like this for years with no changes, so I guess nobody was able to finish this experiment unless high in space. Changing that to the usual value of 51 allows running it in the same places as the other experiments. Although I can't quite confirm right now because apparently I forgot to bring a second cyclotron... Anyway, to change this either edit StationScience/ArcanumIndustries/Resources/Experiments.cfg directly, or put the following MM patch somewhere in your GameData and see if it helps you too. If so I could make a PR to change this, although the question remains whether that's intentional or not... @EXPERIMENT_DEFINITION:HAS[#id[plasmaFuels]] { @situationMask = 51 }

The MKS package has a TAC-LS.cfg if that's what you mean. Another question that might've been answered already, is there a way to fix the Karibou wheels yet, so they don't ridiculously over-steer, especially closer to the CoM? Sometimes they even get stuck in 90° positions when I stop turning.

[...] 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...

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.

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.

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.

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?

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?

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.

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.

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...

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.

Alright, I added the changes, should be all done now as far as I can tell.

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.

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.)

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...

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.

You get half the part mass in MaterialKits. So per ton of mass you get 500 MK. The other half is lost. I usually just add one ISM for this purpose, to contain the scraps until I build up until orbital production becomes available. It never fills up for me, mostly because you only get to scrap the upper stages anyway, which should generally have very low dry mass to get decent deltaV.