AccidentalDisassembly

I'm excited for better performance!

OK, I was able to reproduce the problem on a log less than a couple hundred MB, so... hooray? To trigger it, it seemed to require launching a craft; I didn't see the exception in the log until I had loaded KSP, loaded a save game, constructed a craft, and launched the craft: https://www.dropbox.com/s/umzt9cz39lx2iaq/ts_log_after_launch.zip?dl=0 EDIT: Out of curiosity, I tried removing TS 2.4.6.23 and replacing it with Beta 2.5.0.52 (because I happened to have downloaded it previously) - the same problem does not occur on .52, although a new problematic behavior does - unable to launch directly from launch pad with Beta 2.5.0.52 (have not tried with 53), i.e., click on launch pad, select craft, click launch - but can launch from VAB. When launching from VAB, beta .52 does not create the same TS-companion-Waterfall related nullref spam... FWIW EDIT EDIT: I tried Beta 2.5.0.53 as well - a change between 2.5.0.52 and 2.5.0.53 (which, based on Github, seems to be similar to a change on the main branch) is the cause of the Waterfall-companion-related nullref spam - although .53 corrects the behavior of being unable to launch directly from the launch pad. In other words: changing nothing but version .52 to .53 introduces the Waterfall-companion-related problem.

https://www.dropbox.com/s/bb6ve6xbm1rhwn8/mysterious_ts_waterfall_2023_02_08.zip?dl=0 True to KSP form, of course the error does not occur in the log I generate to send... Who knows why anything happens on KSP, really.

Something seems to be going haywire between the Waterfall companion with the newest .23 tweakscale - sorry, full log was much too large to share due to tens of thousands of the following exception; I think the relevant exception is:

One word of caution on the nodeType - mods like KSTS seem to use the nodeType defined in a part's config (maybe even as a string value or something) to determine what kinds of vessels can interact, so if a 3.75m docking port got scaled down to 2.5m and the intended behavior is to be able to dock with 2.5m ports, it would need to acquire the nodeType of the 2.5m ports and lose all others, I think... But not totally sure. Not sure what you might do with intermediate sizes other than disallow them...

Tried it out - I could not reproduce the 'leftover tank type' problem anymore, hooray! The odd values reported in the editor and the "tank de-fills when you place it the third time if it has both tank switching and mesh switching from B9PS, but doesn't happen on parts with B9PS tank switching and stock variants, and only after 3 tries" are still present, but if you drag the slider up to full, the tank values will be correct when launching, so easy enough to work around!

Wellllll.... shoot. I didn't even think to test saving/loading or simply launching the craft; the values do seem to turn out right (extraneous tanks deleted, both symmetry parts have same contents). However, INCORRECT values are preserved after launching a craft if you pick up and re-place the CryoTanks a couple times on my CryoTanks test setup, reproducing the weird phenomenon I described where picking up and re-placing the original tank once probably won't change anything, twice maybe will change things, three times probably will end up with the original tank being partially filled in the editor - it also will be partially filled in flight (for instance, a tank with original capacity of 400 LF or Ox, scaled up 1.5x, picked up and re-placed a couple times, can end up with 405/1350 fuel contents in the editor; 1350 is the right max number, but where did that 405 come from...?), or when reverting to hangar, or when saving/loading. When launching or loading, the amount of fuel in the both the original tank and the symmetry clone will be 400/1350, not 405 - the fill amount is equal to the part's unscaled capacity in Ox (I was using Ox-only tank type to test), max values will be correct. Not sure why the tanks are getting de-filled and why it at first reports 405/1350 in the editor... I could not reproduce this partial-filling thing on parts without B9PS fuel/tank switching AND mesh-switching, but I didn't try every part exhaustively.

Yes - However, is KSPAPIExtensions a dependency? TweakScale applies patches without that installed, but no TweakScale control appears in the editor PAW if I don't also have KSPAPIExtensions. Meaning: if my GameData folder consists only of 999_KSP-Recall, ModuleManagerWatchDog, Squad, SquadExpansion, TweakScale, 666_ModuleManagerWatchDog.dll, 999_Scale_Redist.dll, ModuleManager4.2.2.dll - then TweakScale does not function. If it's a hard dependency, might want to mention that somewhere in the OP... unless I missed it! Anyhoo, here is a .zip with 3 log files. Hopefully named clearly. One is a log where I loaded KSP without KSPAPIExtensions (no part scaling, because nonfunctional); one is with only the above in GameData, plus 000_KSPAPIExtensions, plus KSPe.dll, plus the KSPe config in the KSP_win64/PluginData/ folder, and the last one is with B9PS and CryoTanks added (with dependencies). Logs: https://www.dropbox.com/s/hqonxkxlqkv9ywe/ts_logs_2023_01_27.zip?dl=0 On the log with kspapiextensions, these are the actions I performed in game: Start game -> new Sandbox. Go to VAB; place Mk1 fuel tank. Select Mk1 fuel from part list and Place 2 additional Mk1 fuel tanks in radial symmetry, surface attached, no snap. Check volumes; scale up original (non-clone) tank, check new volumes. Clone volume incorrect. Remove original non-clone tank and delete (drop on parts list). Repeat above process, but then, after scaling up to 1.875 and observing incorrect volumes, pick up original tank, place original tank again on the root Mk1 fuel tank (still radial symmetry 2x). Check volumes: they are both correct now. Alt-F4 to exit game. On the CryoTanks log, here's what I did: Same steps as above with Mk1 fuel tanks, except rather than Alt-F4 to exit, continued by doing this: Place two H125-4 cryo tanks in radial symmetry 2x. Scale up the original tank, observe new volumes. Both volumes correct. Change tank contents of original tank to LH2 only (from LH2Ox) - Clone tank gains LH2 in the correct amount, but retains original LH2Ox tanks as well (so: two LH2 resources, one Ox resource). Pick up original tank and delete (drop on part list). Place two new H125-4 cryo tanks in same symmetry. WITHOUT scaling the original tank, change its contents to LqdMethane (only). Clone tank has correct LqdMethane amount and no extra resources. Scale up original tank - clone tank does not update LqdMethane resource quantity correctly. Pick up and re-place original tank: clone tank does not update LqdMethane resource quantity correctly. Pick up original tank a second time, re-place it a second time: Original tank now only partially filled (2075 of 6750) - what the hell?; clone tank still full, but still incorrect capacity for LqdMethane Try the same thing with a Mk1 fuel tank: place 2 in symmetry, scale original up, clone tank does not update. Pick up original tank, place again, clone tank updates. Pick up original tank and re-place two or three more times: clone tank still has correct values. Alt-F4 to exit game Hope that helps!

Get some sleep! I can report that opening and closing the TweakScale options button (in the stock toolbar in the editor) does not seem to change the behavior... also, I don't see any green on the icon, before or after pressing... Odd. The setup I used was the same (just TS, Recall, CryoTanks + dependency for the handy fuel-switching patches, and KSPAPIExtensions). I had removed the patch that stripped everything of AttachedOnEditor as well. I tried with and without the TS Companion for CryoTanks just in case something weird was happening there. I can also report a pattern I didn't notice before, I think it can be reproduced: After first loading game and entering editor, do normal thing: place a part, then place stock tank (with B9PS fuel switching patched onto it by CryoTanks) in symmetry; scale the original up. Clone will not have correct fuel. Pick up the original and delete the part. Place a new fuel tank as before in symmetry; scale up original. Clone will have correct fuel values. So something is happening where every second time you place a part in symmetry, something appears to be set such that the clone will get updated with the fuel value correctly. Then the next time you place a tank, it will be incorrect when scaled up; the time after that, the values will be correct when scaling up... odd. This every-second-placement thing does not seem to affect the problem where tanks aren't removed when switching the tank contents, it just seems to affect the updating of the values on the clone tank... I think... hard to say. Hope you feel better soon!

Not sure what to make of the results, but I tried that out, and it does change the behavior - it doesn't fix things, but it makes them... different... With that patch, the incorrect fuel tank scaling is now more reliably reproduced - scale up the first part you place, and the symmetry tank will never (or ... rarely? not sure) be updated with the right contents (whereas before, it only seemed reliable when scaling the tank created by symmetry). I see the same "tank didn't get deleted when changing contents" behavior, as far as I can tell, but now that behavior also occurs on the stock tanks (that don't also have mesh switching). This now happens without needing to scale the tank to trigger the behavior (although I can't be totally sure that is different from before) as well. Sometimes, at least, with stock tanks (only fuel switching), if you place tanks in symmetry, scale up a tank, look at the other tank (which will have incorrect fuel amounts), then pick up the tank you just scaled, place it back in symmetry - re-placing the tank will update the symmetry tank to have the correct values... Other odd stuff happened with picking up and re-placing tanks as well, where volumes did not get updated correctly - all I could figure is that this would happen if you picked up the tank with the incorrect volume, then re-placed it (volumes not updated). But if you picked up whichever tank had the correct volume, and re-placed it, both would get updated correctly. All of this seemed different between tanks with only fuel switching and tanks with mesh switching. In any case, all of these behaviors are different from what happened on .19, so... effects are happening!

Hooray indeed! ... Unfortunately (Sorry, I am perpetually the bearer of bad and annoying news :)) I can also confirm that .20 has not fixed similar issues with B9 Part Switch, and has introduced a new bug specifically on parts that have both a fuel switch and mesh switch from B9 part switch. To reproduce each, follow these steps: Fuel volume issue on parts w/ B9 tank type switcher in symmetry: Clean KSP; install TweakScale, Recall, (I also have KSPAPIExtensions... not sure if required), B9 Part Switch, and CryoTanks (because it has parts with mesh and tank switching, AND applies tank switching to parts without mesh switching too - handy!) In editor, place <anything>, then place two stock fuel tanks on that part/on those parts in radial symmetry. Note that stock tanks do not have a mesh switching option from B9PS (they have stock variants, though), but they do have fuel switching (patched in by CryoTanks). Scale up one of the symmetry tanks; note new fuel volume on the part you justright-clicked on to change scale. Its volume will be correct. Right click on the other symmetry tank - note its fuel volume may not have been updated - sometimes it will work, sometimes it won't; here's what I think I've found about the pattern: I THINK it might have to do with which tank you click on - if you right click on and change scale on the "original" tank (the one you actually placed with your mouse, not the one 'generated by symmetry', so to speak), it seems like the fuel volume scales correctly most (?) of the time. If you right click on (one of) the tank(s) created by symmetry, then scale that tank, then check the volume on the originally-placed tank, the originally-placed tank's volume will not have updated. That said, it also did happen when scaling the "originally placed" tank, just couldn't reliably reproduce. Seems decently reliable when you scale the "generated-by-symmetry" tank, though... Tank-removal failure on parts w/ B9 tank type switcher AND mesh switch in symmetry: This one I could reproduce reliably. Same setup as above. In editor, place a tank from the CryoTanks mod in symmetry rather than a stock tank - these tanks have both a tank switch and a mesh switch option. Scale up one of the tanks (or down) - it may or may not update the fuel volume on the other symmetry tank(s) correctly, but now: Change the B9 tank type of the tank (e.g. change it from LH2/Ox to LH2 only). I do not think it matters whether you change the tank type of the 'originally placed' part or one generated by symmetry. The new content and volume of the tank you right clicked on to do this tank-type switching will be correct. Right click on one of the other symmetry tanks - note that the original tank (LH2/Ox, in this case) is still present in addition to a probably-correct-volume additional tank of the new type. I don't think this happens on parts that have the stock variants + fuel switch - just on parts that have the B9PS mesh switch + fuel switch, but I didn't test extensively. Hope that helps track down the B9 Part Switch issues... sorry to be a bummer!

Just a note to let you know that the github link in your post doesn't go where you want it to

defaultScale is (as I understand it) the default scale value (from the TweakScale SCALETYPE) definitions where the scale slider will be set when you right click on a part in the editor. Short answer: yes, defaultScale of 1.25 for 1.25m parts, 2.5 for 2.5m parts, etc. No defaultScale needed for surface attached parts if you define type = surface or type = free; they will default to 100% or 1x and scale up or down from there.

A module manager patch such as this will do the trick, I think - hopefully without wrecking anything else:

Cool, thanks!