panarchist

Checking that one out now - looks good so far. BTW, how much radiation is lethal to a Kerbal? (i.e. what does "K" mean in the units? Is it kilo- for thousand, or does it stand for something else? Is it still banana-equivalent doses and K means so many thousands of B-E-D?) Just wondering since I sent all my unshielded veterans up there to sit on the new space station.

Finally got around to testing in an instance without 130+ mods. Yes, HL is working in 1.12.3.

Is there a beta or pre-release somewhere in one of your GitHub branches? I'd love to check that out.

What you're talking about sounds an awful lot like compatibility patches. Your question is probably better served by an IP lawyer (which I am not), but compatibility patches are made all the time without drawing the ire of most of the mod makers. The JNSQ team would be the final arbiter of what is and isn't appropriate for the license as they see it, but generally, where the line would be is - are you writing a MM patch which is modifying values set in JNSQ files? You're probably (almost certainly) ok. Are you instead copying an entire config file and changing the values therein, and then publishing that with instructions to the user on how to copy and overwrite the file in JNSQ? That would be a violation of the derivative works clause, because you took a file, copied it wholesale, and then distributed it.

Almost all KK mods work for a 2.5x scaled world if you know how to use the editor. As in, they usually only require a simple edit to move the entire base to the proper elevation and minor repositioning.

It was a good run. I wish I had the technical chops to take it over, there are a couple of aspects I really liked about it. So far, EVA repairs has worked pretty well, so really I think all I miss was the "lite" analogue to KCT.

I would definitely object to making them even, since that doesn't reflect RL values at all. For MKS it makes sense, since that system uses "Supplies". It also makes sense for Snacks. But if using TAC-LS it's completely inaccurate since as @linuxgurugamerpointed out they all have different densities. The point to US2 wedges is that they have consistent volumes. I can't remember the in-game volume of a wedge, but just looking at RL values for Food, Oxygen, and Water with 1m3 as an example - 1m3 of food is 190 days for 1 human. 1m3 of water is 400 days, and and 1m3 of compressed Oxygen is 247.5 days. (source and source)

My instance is heavily modded, so I'll try to test it with just HL Airships and Heisenberg - currently the UI is functional across the board, but trying to actually lift ship isn't working at all - it rises far too fast and is uncontrollable. So I'll pare things down to just the specifics and check again, and will edit this post accordingly.

Also double-check you're on the latest KK - prior versions had trouble with the menu under 1.12.x. If you're using CKAN, make sure CKAN installed the correct version. If it's working in the other game, and that game is *also* 1.12.x, then you might consider copying the entire GameData directory to the new install to ensure you have the same setup, and then add/remove the other mods needed to get it where you want it.

Yes, I was imprecise.

I can't think of any outside of that list, unless you can somehow convince Daishi to create a re-skin of an existing tank for Nitrogen. (it was on Daishi's to-do list at one point, I and others requested it to support Kerbalism and other mods using N2 as a resource.

Let me know if you need any help with testing fixes / changes. I use this mod in every save, I've done QA work before and can write a decent bug report, (been doing tech / SaaS work for almost 25 years) and I'm highly interested in this mod continuing on. If I had more direct modding experience I'd have reached out myself. (someone's gotta keep you from adopting ALL the mods)

Most of the "system packs" that place another star and planets well away from the primary work fine with JNSQ - Extrasolar, Other Worlds, Galaxies Unbound, The World Beyond - looks for "preserves the stock system" or similar language, and check to make sure that the parent body of the mod orbits Kerbol. (rather than the parent body *being* Kerbol) The usual cautions apply - back up your save first, and if adding to an existing save, make sure you don't have any craft orbiting a body being modified. (or safer yet, no orbiting craft at all) And beware of any planet pack that universally rescales everything - those are almost certainly going to cause problems with JNSQ.

Do you have an experienced engineer on board? If not, then this behavior is by design:

Pretty sure that dates back to the early days of US2 or possibly the original US. This was by design - parts only show in the list if you have a mod which requires them. Parts aren't balanced for any of those mods, and they weren't intended to be. When Paul Kingtiger and Daishi started working on the original Universal Storage, Paul had a lengthy discussion with a number of parties in the mod community about part volumes and life support baseline values. The values in each US part were volume-based, with a presumption that 1 unit = 5L of RL volume. Tank capacities are linked specifically to the volume of the container / tanks within the wedge, and the density of the stored item. For gases, some are stored in liquid form, and others in gaseous form under high pressure. There was no effort made to balance them out for any of the mods, because they're based on RL physical constants and properties that Kingtiger meticulously calculated and published the math and methodology for. (I don't know if those links are still online) For US2, they specifically balanced the parts against stock instead of RL physics, so the capacities are in line with similarly-sized parts in the stock game. US/US2 doesn't contain patches for compatibility with other mods, just the ones inside the part.cfg which enable part visibility if a given mod is installed. It's on the other mods if they want to provide config files to change the storage values in US2. I can't speak as to why Kingtiger decided to put the patch in the config file, but I suspect it was done since MM is a dependency for the mod. It's bad practice now, but there weren't any standard on that in 2017 that I can recall.

The new KIS in development works with stock - but it's currently VERY MUCH "in development". Doesn't help a lot right now, but in theory it would eventually.

Is this other save in a different installation of KSP? If not, does KK still work in the other save?

Reply directed to @akron - this can be mitigated if you have some technical confidence, by using an editor like KML or opening the persistent.sfs file in a text editor and editing the reliability numbers on your existing parts. To do that, back up your save, then open the save in KSP with EVA Repairs installed. Immediately close the save and quit, then edit the file. What I don't know is if the reliability effects are added on initial game launch or after the vehicle is loaded into memory - if it's the latter, then you'd need to switch control to each vehicle, quit, and then edit the file. As long as you have a backup ahead of time, you're fine. Then you just have to go up and repair things as they fail - adding repair kits to existing vehicles is a more complex procedure that I'm not going to attempt to outline.

That mod only used the "Kerbin Mini Shuttle" name from 2013-2014. After that, it was renamed the Kerbin Shuttle Orbiter (KSO) or for a time, Kerbin Shuttle Orbiter System (KSOS). There isn't a conflict if @DimonD wanted to use it. KSO has passed through several hands, and the current maintainer is idle at the moment: Definitely going to try this mod out - it looks great. Nice work, DimonD!

When you say "Triton", you mean "Neptune", right? (Triton is the RL design and isn't in Kerbal Atomics) That sounds in the right ballpark, given the details on Triton. The generator takes 3% of the output of the reactor in propulsive mode. Also, the MW in the engine is MWt (Thermal) - for the Triton design, 10% of the MWt becomes MWe (Electrical) - so the Brayton cycle generator is only going to produce 3 tenths of a percent of that - 500MWt becomes 1.5MWe. The devil's in the details - without knowing how closely to the designs Nertea is modelling, and without more detail on the RL Triton, it's hard to say what's realistic - but I find it plausible that a Trimodal engine is less efficient than a fission reactor dedicated solely to electrical power. You gave the production numbers, but what's the consumption difference look like?

Yes, after making the changes for engines, copy that whole block of text and paste it in below itself, then change the second @PART[*]:HAS[@MODULE[ModuleEnginesFX]] line with @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]] There's almost certainly a more elegant way to do it, but that will work.

Yes - one way is to edit BaselineConfig.cfg Replace the line: EVAREPAIRS_BASELINE_CONFIG with: @PART[*]:HAS[@MODULE[ModuleEnginesFX]] The downside to this approach is you'd need to do it every time you update EVA Repairs. A better way would be to write a Module Manager patch to remove the EVAREPAIRS_BASELINE_CONFIG module from all parts except engines. I usually mess those patches up, so implementing that is best left as an exercise for the intrepid reader.

That's how that type of engine works - effectively, you *are* running it at minimum throttle. It's higher than normal reactors, but it means you don't have to have a separate reactor for electrical generation. How much worse is it? Re: radiators in the model - when a trimodal nuke runs, most of the heat leaves the spacecraft in the exhaust - the radiators are to deal with heat that is transferred to the frame before the propellant leaves the engine. When operating in power production mode, the "propellant" stays in the engine and isn't exhausted, so it's plausible to have heat generation in that mode. The intent of the RL trimodal engines is to operate in power production mode long enough to charge batteries or some other energy storage device, then to be shut down until needed for the next recharge. Of course, no one has built the real thing yet, so all the numbers are approximations anyway.

Brigadier is correct, it's Kerbalism. Lots of cool stuff in that mod, but beware - it doesn't play well with a lot of other mods. Best to run it in a separate instance of the game. That said, it is pretty amazing in terms of scope and functionality, and a lot of fun (and sometimes real challenge) to play.

The art and model are public domain, the config files are GPLv3, so yes, you can create derivative works and distribute them, but you'll want to call out specifically in the Junkyards mod that the PSA Greenhouse config files (and only those) are GPL 3 and retain the GPLV3.txt license file. (as required by the license) The specific callout is necessary because otherwise you're putting the whole mod under GPLv3, and that license isn't compatible with certain other licenses like MIT. This reminds me that I really should update, re-license, and redistribute this mod as MIT once I review and replace the configs. Looks like you already did that in the Github repository for AtomicTech-Inc.-Junkyards. So you should be good to go. TLDR - you don't actually need to ask, just adhere to the license - but yes, and thanks for asking.