AccidentalDisassembly

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?