AccidentalDisassembly

OK - I continue to believe something is messed up within TweakScale, perhaps (or not) related to only certain parts that use TWEAKSCALEBEHAVIORs - on that front, I just can't be sure. However, I can replicate this problem reliably. Here's what I do: This is the picture I'll be referring to - this is what CERTAIN parts look like every time. Can't be scaled (except down by one step, but values in either slider do not change): KSP 1.6.1 with MH - GameData folder contains only MM 4.0.2, TweakScale 2.4.1.0, Squad, and SquadExpansion Start game, create new sandbox, go into editor, place any part, then place the 5m engine plate. Right click on engine plate to scale it - it appears as in above image. Just in case of MM screwiness (or something), delete all MM cache files, and also delete PartDatabse.cfg. Restart KSP, start new sandbox, do same thing in editor: problem remains. Restart KSP, start new sandbox without deleting anything, do same thing in editor, problem remains. So something is going on here. I believe I have an idea what is happening. Nope, I did not know what was happening, but looking at it again gives me a second theory - look at the second TWEAKSCALEEXPONENTS in this TWEAKSCALEBEHAVIOR - it has name = TweakScale... that can't be right, can it? The two TWEAKSCALEBEHAVIORs that have "name = TweakScale" in them (this one and the science one) are ones applied to parts that are borked for me... All of that was wrong too. I have no idea what's going on, but it's borked even in a purely stock/TweakScale install, so something is messed up for sure. I tried. [Snippity] On another note, for purposes of safety and reducing duplication, I would suggest that EVERY patch in TweakScale be edited to use "%type =" and similar rather than "type = " when doing patches - just in case someone else has already defined a type for a part (etc.). Also - some patches have superfluous definitions, e.g. the engine plate's TS patch defines incrementSlide and scaleFactors, but does not need to because those are already defined by its scaletype (unless some custom increments are being used which I didn't catch).

Awesome! I've read your posts on the issue, and I'm not sure that I've understood everything you're working on - so this may be a useless comment: just to clarify, as far as i could tell, there were not two instances of the TweakScale module being applied to that command part. I checked this by looking for the part's name everywhere in gamedata (in all cfg files, pretty much) - the part name only appeared in the part file and the (one) TweakScale stock patch config file. The only thing I changed to get it working correctly again (correct visual size of the command parts in editor, and correct node sizes and orientations) was removing the following from the MM patch that adds TS to the probe core parts: #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } I left the rest of the MM patch (adding the module, setting the scaletype and size) unchanged. Does that mean that there were two instances of #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } somehow being applied to the same part? Or something like that? I'm afraid I don't actually know what the TWEAKSCALEBEHAVIOR thing does...

Small FYI: In latest beta, GameData\Workshop\MM_Patches\_OSE_PartRecipes.cfg is missing a curly brace on the ModuleAlternator patch.

Small FYI : GameData\Bluedog_DB\Compatibility\KIS\KIS.cfg is missing an opening curly brace near the end.

Wondering if anyone else has this issue - I suspect it's some kind of mod interaction, but don't know which one would be interacting with TweakScale... On command parts such as the HECS probe core or the 1.25m or 2.5m remote guidance units, which all have "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" in their patches, the apparent size of the part in the editor (as well as apparent size of its nodes, and also the direction of attachment the stack nodes allow) are all messed up. In addition, they have two tweakscale sliders (see image - shows scale problem and slider, but not nodes): Seems to be OK in flight scene, weirdly. In any case, removing the "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" also seems to fix the issue. Is this a thing? Or have I borked something somewhere? EDIT: 1.6.1 with Making History, latest (I think) tweakscale.

tested it in stock-ish environment and they do seem to work with appropriate symmetry - will try in my full install next.

Is there a way to fix the incorrect deploy direction when using mirror symmetry to create flaps? I.e. one flap deploys up, the other deploys down? I've found that using PartWizard to break symmetry on the parts in the editor after they're placed makes them still deploy together when activated, and makes them both deploy in the same direction - is there a way of using something from that code to make the procedural control surfaces mimic stock behavior?

Just a small note: in GameData\CryoTanks\Patches\CryoTanksCTT.cfg, there's an extra closing brace. Probably not important, but hey! Found it!

Just out of curiosity - does this handle physics warp differently than Time Control? I ask only because it seems like BTWC somehow does relatively high rates of physics warps more "smoothly" than Time Control. On a related note - since BTWC seems to handle physics stuff nicely, would it be possible to add the functionality that TC has (I think?) where additional increments can be added to a given time warp scale? Meaning that you can have a greater number of increments than exist in stock normally, e.g. a physics warp regime where you have x1, x2, x3, x5, x8, x12, x20, (7 total increments versus 4 total in normal stock and current BTWC) without changing warp "sets" ? (Same for non-physics warp). Just curious, probably out of the scope of the mod and whatnot, and/or "Just use Time Control", of course.

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?

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.

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.

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.

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

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

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?

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?

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!

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"

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.

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!

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.

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.

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.

These can also be added by MM patch in your particular install, if you want - you can make it exactly how you want it regardless of what the mod itself does.