AccidentalDisassembly

Members
  • Content Count

    959
  • Joined

  • Last visited

Community Reputation

158 Excellent

About AccidentalDisassembly

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

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

  1. AccidentalDisassembly

    [1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

    Something I don't understand - what you say does not make sense unless you are doing something really unusual that doesn't apply to 99.99% of users. If something differs in the XML file between versions of KJR, then it should not be placed where it won't be deleted when deleting the rest of the mod - you'd want an appropriate XML file to be added with whatever version you're using. If nothing changes in the XML file between versions of KJR, then it still makes no sense to put it somewhere else, since deleting the mod and reinstalling it also successfully reinstalls the same XML file, minus the step (and the confusion) of sticking it in an otherwise completely unused, essentially deprecated folder. So far as I can tell, nothing changes in the xml file through some kind of setup of the mod / use of the mod. No in-game controls seem to allow you to change those values. So why make this the one and only mod in all of KSP that puts its own files in the main KSP directory rather than GameData? Why not just put the config in the KJR folder like before? Or, at the worst, why not just put the xml inside a "KJRSettings" folder in GameData that people don't have to delete when upgrading the mod (or a .dat like Toolbar, or whatever)? What am I missing here?
  2. AccidentalDisassembly

    [1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

    The thread says very little one way or the other. Lisias' response to Drew Kerman does not address the directory structure, only the dependency on KSPAPIExtensions. Considering this is the only mod I've ever seen that puts files outside of the GameData directory, you can imagine why that would be something that would immediately seem like a mistake in how the folders got stuck together somewhere.
  3. AccidentalDisassembly

    [1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

    FYI - the latest release on GitHub seems to have a funky directory structure. PluginData should be inside the mod directory, not alongside the main GameData directory in the downloaded ZIP.
  4. AccidentalDisassembly

    [1.4] RealPlume - Stock [v1.2.0 - 30/3/18] - The Farewell Update

    If I am not mistaken, RealPlume is a set of plume graphics/models/particles and plume definitions - resources that can be used to create new plumes for engines through MM patches. RealPlumeStock is a set of patches that apply those graphics to stock engines. Or something like that.
  5. AccidentalDisassembly

    [1.3] - Modular Kolonization System (MKS)

    Where do you prefer pull requests and such? In the constellation release thing on Github, or in each project repository separately (e.g. in FTT's separate repository)?
  6. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    I'm just happy to know I'm not a loony.
  7. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    But in the second picture, the zero setting on the floatBuoyancy of the left-hand part is 25.4016... Drag the slider up; what's the maximum? It looks like it's not working correctly, at least. Did you launch and see what happens there, too?
  8. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    Quick question about Firespitter's buoyancy feature: I can't seem to make it function properly. With default install of TweakScale, plus SXT (which contains parts that use FSBuoyancy, like the airplane floats or the crash pad bag things), scaling parts with FSBuoyancy up and down creates weird numbers. Example: This is the part unmodified (defaultScale was set to 1.25 because of an error in the TS patch in SXT, but shouldn't matter) - the max floatBuoyancy is 50: This is the part scaled up to 2.0x - note the mysterious new value for floatBuoyancy, which does not persist when launching the craft. Upon launching, right clicking on the part reveals floatBuoyancy maxed out at 102.4 or so, but adjusting floatBuoyancy changes the range back to 0-50. Then, this is the part scaled back down to 1.0x - the floatBuoyancy is now more than it was at 1.25x, for some reason: Finally, here is the part scaled BACK up to 2.0 after the previous step where I scaled it down to 1.0 - new value for floatBuoyancy again: The module looks like this in part files (well, similar anyhoo): MODULE { name = FSbuoyancy waterImpactTolerance = 250 // 50 dragInWater = 2 buoyancyForce = 10.0 splashFXEnabled = False // added } I tried to fix this issue by doing the following, but it did not work: TWEAKSCALEEXPONENTS { name = FSbuoyancy buoyancyForce = 3 } Any idea what's going on here?
  9. AccidentalDisassembly

    [WIP] Infernal Robotics - Next

    FWIW - I found that Rudolf's latest version of fixed KJR simply needed a recompile to work in 1.5.1 (I think, anyway - I have no idea). I did that, and haven't had any problems. Quick fix!
  10. AccidentalDisassembly

    [WIP][1.5.X] Rocket Sound Enhancement [v0.3.1]

    Getting about 48 module manager errors related to two patches - Hypergolic-OMS-Red and -White.cfg. The errors look like this (or similar): [LOG 17:41:00.500] [ModuleManager] Applying update RocketSoundEnhancement/Patches/Hypergolic-OMS-Red/@PART[*]:HAS[@EFFECTS:HAS[@Hypergolic-OMS-Red]] to NearFutureSpacecraft/Parts/Engine/orbital-engine/orbital-engine-125-1/PART [ERR 17:41:00.500] [ModuleManager] Error - Failed to do a maths replacement: AUDIO : original value="0.2 0.5" operator=Multiply mod value="1.7"
  11. AccidentalDisassembly

    [1.5.x] Near Future Technologies (large NF Spacecraft update)

    Just got clued in to the dev branches due to the discussion - the new pods and such (all that I've toyed with so far) look really cool! Looking forward to the next version(s) of the various packs.
  12. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    With respect to one aspect of your proposal in specific: it would be both easy and handy to simply create an "Extras" folder that would always be present inside the main TweakScale package, and in that folder include either: A) individual config files that add specific sizes to scaletypes, e.g. a Size3.125.cfg that adds that specific size, and additional configs for additional sizes, so people can pick and choose, OR B) A "TweakScaleExtended.cfg" in the extras folder which includes many additional size increments at the same time. That way, people looking for additional scales don't have to go very far. Seems like a good solution for the additional scale increments (which, I agree, should not be included by default). Then, with respect to splitting other functions out... dunno about that one, sorry!
  13. AccidentalDisassembly

    [1.5.X] Mk2 Expansion v1.8.3 [update 10/24/2018]

    I believe something is messed up for one of the M2X B9 Part Switch patches, considering B9PS crashes the game with a little fatal exception message when you try to place parts like the Mk2 Tri-coupler (the one with three 1.25m bits) in the editor - it could be a conflict with something else, I suppose, but I think it might be because there are no types defined for some of the switching options in the B9PS patch... possibly.
  14. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    Just a thought for a future update - one nice thing to do in TweakScale would be to replace very patch that creates AND assigns variables like this: { type = stack } ...with the %type = stack create-or-replace thingy in ModuleManager. The reason for this is simply to prevent scaling from not working in the even that other people (like me) have custom patches that accidentally assign a "type" or whatever BEFORE TweakScale does. Then, when TweakScale patches, it creates a second type rather than changing the existing one. Alternatively, maybe have it so that TweakScale just picks one of the assigned "types" and doesn't break when someone goofs on the patches... dunno. Probably a fairly quick change with Notepad++ ... maybe.
  15. AccidentalDisassembly

    [1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

    Long story short, it is relatively easy, but perhaps time-consuming depending on how many parts you're talking about. You can define how mass scaling behaves for individual parts, for scaletypes, and by default, and you can do all of that via MM patch, but without knowing exactly what you're trying to accomplish it's difficult to say for sure. By default, scaling a part up 2x in every dimension results in 8x the mass, so if you're going from 1.25m to 2.5m, yes, the mass will increase quite a lot. 8x the volume, 8x the mass. Other scaletypes exist that only increase mass 4x when linear size is increased 2x (the "xxxxxx_square" types)... you can make your own and have complete control, if you want.