AccidentalDisassembly

This one: http://forum.kerbalspaceprogram.com/threads/87700-0-24-Generic-Resource-Converter-v1-0 was mentioned to me a while back in this thread. I know nothing about it, but maybe it's worth checking out? The license reads: License: Feel free to use or edit this however you want to. You can credit me if you like, but it is not necessary.

Why not just install each pack into a subfolder of GameData/Klockheed_Martian? As in: GameData/Klockheed_Martian/CoreComponents/ GameData/Klockheed_Martian/SSE/all directories under KM_SSE right now GameData/Klockheed_Martian/SmartParts/ Then uninstalling or updating a portion of the pack is still as easy as deleting or replacing one folder, but there's only one entry for Part Catalog.

There's a checkbox that says "Always use resources" when Kethane isn't installed, maybe that does it? I'm not sure really. Beats me. I don't know enough about the various ways of converting resources to know whether that is better, worse, or the same as what I've got in the config right now. It would be an easy enough change though if it's better in some way, but the current ModuleGenerator stuff seems to function... so far anyway. Here (https://dl.dropboxusercontent.com/u/59567837/Karbonite_EPL-Patch.cfg) is the cfg as it stands now. This is what it does: - Adds Karbonite drilling ability to EPL and Baha's EPL drills in some vague proportion to their size. Power consumption & drilling rate are arbitrarily chosen to be vaguely in line with the Karbonite drill. Ish. I have no idea how to get the drills to animate, however. Tried the KarboniteDrill module, causes crashes. - Adds the ability to convert Karbonite to metal, metal to rocketparts, and scrapmetal to metal in EPL smelters. Conversion rates are almost assuredly horribly, horribly wrong. As is, one metal converts to 0.7 rocketparts and 0.3 scrap. I have no idea what the conversion ratio is normally. Using Kethane seems to apply some math to resource volumes/masses/whatever in order to come up with a conversion ratio. - So far as I know, it does not remove anything regarding the normal ore method of doing things if you have Kethane installed. Seems to work as it is - I was able to sit a Karbonite drill on the launchpad, use a smelter to change that to Metal, put Metal through a workshop and end up with RocketParts at least.

My thinking was this: All the EPL stuff seems to use Kethane modules to do conversions & extractions. If I simply add ModuleGenerators to various EPL parts that work based on Karbonite, then Kethane doesn't have to be installed for EPL to work (which I think it would have to be if the only change was to produce ore from the drill)... But maybe there's a simpler way of doing this...

I fail to see in any of this how it makes MORE sense to make the patch I am attempting to write depend on MKS rather than not - if it doesn't depend on MKS, that does not mean you can't use it with MKS. It just means that, if you installed this particular MM patch which remains entirely theoretical since all it has done so far is crash for mysterious reasons, you could, if you choose, convert straight from Karbonite to Metal in the Karbonite converter and EPL parts (smelters) and drill for Karbonite with EPL drills in addition to doing whatever MKS does. It doesn't prevent anyone from adding another patch so that the EPL drills also somehow pull ore out of the ground via MKS, so far as I know.

That would be fine for MKS users, but wouldn't it be best not to make the Karbonite + EPL combination also dependent on MKS? As-is I have metal conversion working correctly (Karbonite to metal) but experience lots of crashes with my MM patch intended to change all of the EPL stuff to work with Karbonite...

Aha - well in any case, eliminating the step of getting Ore from the ground makes sense in the event that someone wants to play with Karbonite + EPL, but without either Kethane or MKS. So far I have managed to make the game crash a lot with my attempted patch. Huzzah! EDIT: Can't figure out why none of the EPL parts will show up anymore in the VAB. Here's an example of a module manager edit to them: @PART[ExWorkshop]:Final { -MODULE[KethaneConverter] {} // Get rid of the KethaneConverter module MODULE { name = ModuleGenerator isAlwaysActive = false activateGUIName = Convert Metal shutdownGUIName = Stop Metal INPUT_RESOURCE { name = Metal rate = 0.5 } INPUT_RESOURCE { name = ElectricCharge rate = 10 } OUTPUT_RESOURCE { name = RocketParts rate = 0.7 } OUTPUT_RESOURCE { name = ScrapMetal rate = 0.3 } } } Am I doing something horribly wrong in this MM config?

EPL's Ore exists as a resource if you have Kethane installed, I think. If you don't have Kethane, and only Karbonite, there's no point to converting Karbonite (which seems like an ore) -> Ore -> Metal -> Rocket Parts. Otherwise, I am keeping the EPL conversions mostly intact (or attempting to). EDIT: I mean to say that it exists as something you can pull out of the ground only with Kethane - it's defined whether or not you have Kethane installed, but I think Kethane has to be installed for you to pull it out of the ground using EPL.

Here is a small MM patch that adds to the included Karbonite converter the ability to convert Karbonite into Metal for EPL - I skipped the Ore stage, since I figure Karbonite itself is basically ore-like. I arbitrarily chose an efficiency of 60%, since that's what EPL's Ore->Metal conversion was (I think): --EDIT: Actually, I think it's far lower than that, but whatever: it's easily edited. https://dl.dropboxusercontent.com/u/59567837/KarboniteConvert_EPL-Metal.cfg Currently attempting to fiddle with EPL configs so that it works off of Karbonite rather than Ore, and so that all the converters & drills function properly. Don't even know how to make an EPL drill function properly alone, however, so we'll see how this works. Question though: does a part need both ORSModuleResourceExtraction and KarboniteDrill modules to function as a Karbonite drill?

Based on my rudimentary and just recently-acquired knowledge of the ModuleGenerator that's used to reprocess Karbonite into other stuff, you can set whatever conversion ratio you want - so you could turn 1 Karbonite into 0.0000001 xenon. But I don't know about having a byproduct, except that you could maybe somehow define a new resource (Karboslag) and patch the converter to output that in addition to whatever else you're using... maybe?

No, I mean when both are running, it produces whatever I'm converting Karbonite into at a vastly increased rate - so there's always 0 Karbonite in the tank, but the empty MonoProp or Metal tank (or whatever) fills much much faster than the Karbonite seemed to be coming out of the ground when the converter was off, if that makes sense. Example: Only the drill going: Karbonite comes out of ground at X units per second. Wait 100 seconds: 100 units. Convert to metal: 60 units. Should mean that the Karbonite equivalent of 0.6X metal comes out of the ground per second, essentially. With drill and converter both running, Karbonite is converted as fast as it comes out of the ground, but I am getting the equivalent of at least 60X metal - far more than should be coming out based on the rate at which Karbonite alone comes out. It also happened with MonoProp... EDIT: I should clarify that I have both Kethane and EPL installed to see if I can make either work with Karbonite, in case it's not Karbonite but the combination that's producing this phenomenon. EDIT AGAIN: Also, here (https://dl.dropboxusercontent.com/u/59567837/ProceduralKarbonite.cfg) is a procedural Karbonite tank cfg I whipped up. It holds slightly less Karbonite per volume with 500kg more dry weight (at the equivalent size) than the included Karbonite tank - for anyone who might find it useful.

I was looking through EPL's configs to figure out if I could ditch Kethane as well. I don't know exactly how the mod works, but it uses "KethaneConverter" and "KethaneExtractor" modules on its parts. Could these be replaced with KarboniteDrill or ORSModuleResourceExtraction or ModuleGenerator or whatever using an MM patch?

Noticed something I'm not sure how to explain. I used this MM patch to see if converting Karbonite to metal works: It does work, but in a strange way. When extracting Karbonite from the launchpad WITHOUT the Karbonite metal converter turned on, Karbonite is extracted at a very slow rate (seems normal, I suppose). When I convert one unit of Karbonite into metal, it takes a moment and produces 0.6 units of metal. However, when I leave the Karbonite drill running AND have the metal conversion working in the converter part, the rate at which metal fills my metal tank is far greater than the rate at which Karbonite is coming out of the ground - so it seems like if both are running at the same time, it gives you a much higher output of the converted resource. This was also true for monopropellant when I tried - they're both produced at something on the order of 100x or 500x greater speed.

Awesome. Thanks for putting in the time to make this!

Quick question about the Karbonite converter's cfg, sorry if it's a silly one. Is adding a new resource (that Karbonite can be converted into) as simple as adding something like this via a MM patch or to the cfg directly: Meaning that this mod could already support things like RocketParts, or Metal, or even LiquidHydrogen or what have you? Do you have to work any dark magic to get it to fill a tank for that resource appropriately?

AWESOME! thanks! Time to go rewrite all my scaletypes.

Any word on the mass scaling? Am I just using the wrong format for my definitions?

I'm still having trouble with mass scaling in the new version - I have tried both massFactors (which you confirmed was deprecated, so of course I didn't expect it to work - and it didn't) and this inside a SCALETYPE {} : This has no effect - everything scales as if the exponent were 3 (8x the weight for 2x the size). Am I still doing this wrong?

Just a suggestion - as it is right now, the folder/file structure of the new 2.6 version is difficult for people like me who like to keep only particular parts out of a pack either to save memory or to save ourselves from part list spam. Example: I would rather not have the fairings from KW, cool as they are. But deleting the fairings folders doesn't just get rid of fairings stuff, it also affects a number of other parts that seem totally unrelated, like the 5m decoupler - I am just assuming that's because it uses textures in the fairings folder? In the same vein, deleting many parts' folders doesn't remove the parts' models. It would be much easier if every file that corresponds to only one part were in the same folder as that part, so that you can very easily delete the maximum amount of stuff the game loads by removing that one folder, and if common textures/resources/whatever were placed in explicitly common folders. Just my two cents! If there's some reason it can't work this way, I take it all back.

Oh! One or several steps ahead of me. Cool!

Just a suggestion for that new cargo bay - sorry if it's already been mentioned: It would be cool to have "floor"-suitable textures on both the upper and lower inner surfaces of the bay - that way it can be used in either orientation, i.e. either for vehicles or whatnot that might use the ramp as it is now, or flipped upside down as an aircraft bay on a carrier-type ship.

Sorry if I'm just a little slow on this one and missed the message, but are either of those DLLs meant to replace the one in the 7.0 pre-release you did the video on? With the 7.0 pre2 installed, I get le crash on loading to the space center after the main menu (0.24, 64-bit), and it seems to do the same thing using the 0.24 DLL you posted on the last page instead of the one bundled in 7.0 pre2.

I don't know about most of what you wrote, but here: https://dl.dropboxusercontent.com/u/59567837/NearFuture.cfg is a config I use for texture compression of NearFuture stuff with ATM. Add it to your GameData/BoulderCo/ActiveTextureManagerConfigs or whatever the folder is called and it should (maybe?) work. No guarantees!

Please do! Looking forward to it, and I really like what you both are doing with the parts!

Hmm.. I tried what I thought was exactly that, and it didn't work, but maybe I'm not doing this right. Here's what my MM config looks like. Part still scales as if mass = 3. Adding/removing stuff like scaleNames, minimum/max scale etc. has no effect, and any part name substituted in there results in same thing (so far as I can tell anyway). Does the mass = 3 in the scaleExponents.cfg in the main TweakScale directory override all other instances? SCALETYPE { name = masstest freeScale = false scaleFactors = 1.0, 2.0, 4.0 defaultScale = 1.0 TWEAKSCALEEXPONENTS { mass = 2 } } @PART[N1_BlockV] { MODULE { name = TweakScale type = masstest } }