AccidentalDisassembly

Okie doke. In that case, I will create a patch (only) that could be used to test it out, but won't PR the swappable stuff for the drills. In the meantime, should I just use stock modules on the Ka/Ka+ drills? Or is there some functionality in the USI specific module that couldn't be replicated? Reason I ask is because I thought it would be nice / good for balance if the Ka drills A) produced heat / potentially overheated like stock Ore drills, and B) also got bonuses from Engineers, so was trying to work that into the config. I see how to do it with Stock modules, but unsure about the USI resource harvester.

Another question about Karbonite - I'd like to update the drills, but am wondering if it wouldn't be best to use swappable converters à la MKS so that each drill has two bays and can go 50/50 Ka/Karborundom, or 100% of either if desired. Thoughts? or best just to have them always able to do both? Is the swappable drill stuff something that comes from USI tools, or from MKS's DLLs, though? If that's a MKS-specific feature, then I could also switch the Ka/Karborundum drills to stock ModuleResourceHarvester with heat efficiencies and whatnot, unless there's some point in retaining the ModuleResourceHarvester_USI...

Don't put the WarpDrive folder directly in your GameData folder. Look inside the ZIP file - there is already a GameData folder that shows you what to do: put the stuff inside THAT folder insider YOUR GameData folder. Result: <KSPdirectory>/GameData/UmbraSpaceIndustries/WarpDrive/

Well, it hasn't crashed or done anything weird for me... so... success?

OK - that makes sense. I originally thought Karbonite might be intended to be some kind of really dense sludge given the sheer mass of Ka that can fit in a given volume when compared to LF/Ox -- Ka tanks hold 2.5x the mass per volume compared to LF/Ox tanks. But it's a result of very high unit capacities (super duper compression?), since it's 0.5x the density of LF/Ox... Hence my uncertainty. In that case, I would imagine that converting Karbonite into LF/Ox would result in more LF/Ox from Karbonite than from Ore (per unit mass of the input materials). So 1 Kg of Karbonite would end up converting to something like 0.8Kg of LF/Ox (or whatever), while 1Kg of Ore might only produce 0.2Kg of LF/Ox. Random arbitrary numbers, just for the sake of argument, but seems plausible that the Ka to LF/Ox converters would be more efficient-ish from a mass standpoint. I'm thinking then that: 1. The mass of 1u of Karbonite is 0.5x the mass of 1u of LF/Ox, 2. So as a first stab at balance... uh... 3u of Ka into 1u of LF/Ox, so 66% efficient from mass standpoint? Or 80%? or..? 3. And I'll have the converters process 1 Kg of Ka faster than they would process 1 Kg of Ore, since it's already a nice combustible product. 4. End goal being that drilling/refining Ka for fuel (either using it directly or converting to LF/Ox) should be preferable in some way, all else being equal, than drilling/refining Ore and converting it. Sound plausible? Just trying to fix the seemingly arbitrary numbers in many Karbonite parts. Obviously RoverDude is free to reject any of this, just figured I'd try to go for some of the low-hanging balance fruit, so to speak. Atmospheric scoops could probably use some love in that respect as well...

Had a question about Karbonite - I was going to do a couple more PRs with balance suggestions for the converters and intakes. My aim was to make it so that a Karbonite converter of a given size could process about the same mass per second of Karbonite as a stock converter of comparable size would process in Ore. However, I wondered how energy dense Karbonite is supposed to be - if it's meant to be Liquid Rocket Magic (TM), then I'd make the converters output a little more LF/Ox per second to reflect the greater usefulness of Karbonite as a source material than Ore. But if the idea is to make Karbonite much more attractive to use as rocket fuel with the included karbonite engines rather than turning it into LF/Ox, I would make the converters less mass efficient than stock stuff. Not that you've got a load of free time at the moment, but if you give me some rough ideas (whenever), I can reflect them in the configs. EDIT: Also noticed that Karbonite is 1/2 as dense as LF/Ox and 1/4 as dense as Ore, is it meant to be a fluffy solid or a really light liquid? Don't want to go mucking around too much when I'm not sure what the intention is. Meanwhile will send another PR for duplicate part names.

Add this to the KJR/Plugins/PluginData/config.xml (or roughly that folder location ,I can't remember): <string name="exemptModuleType6">ModuleDockRotate</string> You'll see a list of those exempt modules, add this one to it. (Make the number work for whatever else is in the list, I guess - don't know if it matters). I think that's the right module to allow the hitch to move again.

If you have KJR installed, that might be the cause of the hitches not articulating. My guess, anyway!

No, it's not worth it. Write an MFT config instead, much faster & easier IMO.

The short answer to your question is: no, you cannot very simply do what you want without editing things. The long answer is that you need to edit the TweakScale patches that are being applied to your part, or you simply need to write new MFT configs and apply them to the parts you want. New patch meaning: such that the increments between each defined scale size are smaller, and therefore the bar (yes, green, whoops) also has smaller increments (that you can actually choose accurately). You can look at the existing scaletypes and patches to get an idea of how that works, but basically, rather than this: You would probably want something like this:

Not the most thorough testing, but I gave it a shot in 1.4, Win10 x64, no -force-anything on the shortcut command, and graphically it looked fine. The maneuvers it gave me did indeed send me pretty close to Moho, so there's that. I will say, however, that I *think* there is some kind of interaction going on with AstroGator and other mods that mess with nodes, e.g. Maneuve Nodes Evolved (maybe) or MechJeb (maybe). This is a kind of useless report, so sorry for that, but I remember there being issues in my 1.3.1 save in that respect, but never really being able to pin it down. Removing AstroGator seemed to help. Anecdotes!

That is not entirely true, I'm afraid. Here's a picture of the interface after clicking on a button: Could be a conflict with something else though, I suppose!

Aha, OK, I think I understand now, thanks. I assumed the prioritization would apply no matter what the charge was, but it makes sense the way you've explained it.

Huh, didn't know that, thanks. But I'm not sure I understand how limiting the reactors to only charge batteries to 90% saves resources. Presumably, if your base takes 100 EC around the clock, and you have 150 EC of solar during the day and 150 EC of nuclear at night, there's some code in there somewhere that makes solar take priority. Then, if you use a sudden burst of energy at night that lowers your battery - let's say it goes from 10,000 to 5,000 - the reactor will take care of the night's 100 EC/second (for 3 hours? just for the sake of argument), and will charge the battery back up with its surplus. But it will only save 1000 EC worth of generation in total, as compared to the (roughly) 1,084,000 EC it generated to cover the output of the base and recharge the battery to 9,000... I don't see the logic here.

Dunno if this is MKS reactors specifically or.. or what. Only tried this with the 0.625m reactor. But: small note in 1.4 - if you have a small reactor recharging your EC on a rover, let's say, it will not recharge EC to full. I have 650 EC on my craft, and the reactor will only bring it to 617EC, but the reactor still reads as having a load on it. Solar panels, by contrast, will recharge the EC to 100%. Dunno what's going on there, but it's easy to replicate the behavior (I think).

My guess: this is a result of old parts (like the 1-2 pod or rockomax 64 tank) being hidden in order to maintain backward compatibility with crafts. I'm guessing their entryCost is not 0, and that they still can be purchased in the tech tree even though they don't show up in game.

No worries! Thank you for the info - that sounds very reasonable, I imagine it will depend on exactly how things end up with the code!

Drag the blue bar or change the TweakScale configs, basically.

To be clear, I think the IDEA is really quite good - being able to group parts into a theme and define which texture (or whatever) to use with that theme - but how it actually works in the editor gives me a sad. EDIT: Also, thank you to the kind soul, whoever you are, that finally realized that parts in the editor should be given titles that result in similar parts being placed with each other (and in size order) in the parts list.

It's the themes tab - clicking on one of the themes in there changes associated parts (all at the same time) to a given color. It's very poorly thought out, IMO, that's most definitely not where such a menu should be. Whoever thought that through (and didn't mouse over it even once before release) should be slapped with a fish. But that's just my $0.02.

I gather no one at Squad actually moused over the new Themes button thingy before publishing EDIT: or thought about the user interface of it, for that matter. It should be something that you can do while looking at the parts you're working with, a flyout menu of some kind..

Looks like MM still works (or at least works enough) to use the JetSounds mod or whatever else would work. They are a little... Uh... I don't know what those sounds are.

I can confirm your issues with the drills in the editor at least - it's proportional to how many bays they have. I looked on GitHub, and the issue was logged - RoverDude said it was "being worked on for the next version" or something like that. Dunno if that's still true, but I assume it is. I *think* the same is true for things with other swappable converters/modules, but am not sure about that.

I recently took a whack at texture/fuel switching by creating a patch and textures for my personal use - they change the included USI-LS containers so that only one part of each size is needed, and resources and colored stripes get swapped out via B9PartSwitch when selecting between Supplies/Fertilizer/Mulch/Combo. If I understand how texture switching works (which I probably don't), it seemed to me that the existing tanks in KPBS (including the ones for USI-LS) can only have their colors or stripes or whatever changed by swapping the whole part's texture for a copy that's been edited. Just wanted to make a small suggestion (if you're taking them, of course!): it would be really handy to very slightly modify the fuel tank / resource tank models to give them a decal transform (I think? don't know my terminology) that would allow for easy patching & visual modification with fuel switchers. Some kind of sub-texture, similar to what KPBS to MKS does, that makes color changes or label changes easy (and not require a whole bunch of duplicate large textures). Hopefully that makes sense!

!!!! Ok, that's news to me! I'll go give that a try. EDIT: will we still be able to mess with those values somehow, in a config somewhere? Probably won't be necessary, just curious. Mostly thinking of mass values, part cost, EC consumption. EDIT2: OK. After removing TWEAKSCALEEXPONENTS everywhere, the part context menu will still lock up IF there is a large scale in the SCALETYPE. This scaletype will not cause it to lock up: EDIT AGAIN: Actually, the blue arrow selectors for part scale cease working after clicking them once or twice (with EITHER scaletype) in the editor, but you can still click on the green bar in the middle to change the scale... what in the world?! Perhaps I have borked something indeed. However, the scaling does seem to work in my preliminary tests! Huzzah! I would note that the Rotatron's EC consumption goes up quite a lot more than the extendatron when scaled large. At 5x size and with values maxed (speed, accel), the rotatron takes something like 1250 EC/s while the extendatron takes far less. Second note: The large scaling works with parts individually. However, if I place both an extendatron and a rotatron scaled to 5x on the same craft, the one I place second will not move/rotate in flight... strange. This does not seem to occur on non-scaled parts, at least.