Lisias Posted January 26, 2023 Author Share Posted January 26, 2023 (edited) ANNOUNCE Release 2.4.6.20 is available for downloading, with the following changes: MOAR bug fixes! Updates KSPe.Light with yet moar bug fixes. Closes Issues: #261 Misbehaviour (again) while scaling parts with VARIANT #238 TweakScale is failing to consistently resize the Attachment Node’s sizes. I finally nailed the Editor's Attachment Problems!!! #hurray!!! Now you can change variants, do duplicates, multiple subassemblies radially, etc on "inverted parts" (turning them 180º) without worries on Editor (it never was a problem on Flight Scene). This freaking bug was pesking me for years and, frankly, things just started to fall in their places after working on KSP-Recall - where I could have a glimpse on how and where things get screwed on KSP, and what Squad did to fix or at least workaround some things. And then it finally passed trough my dull, thick skull: ModulePartVariants is working fine (or didn't misbehave on the test beds I built for this problem). Editor was the one royally screwing things, and all that code I wrote since 1.4.5 times (when the MPV really started to kick in) was coded around an Editor's bug, not over a PartModule one. TL;DR: I was fighting the wrong code - once I stopped trying to be smarter than ModulePartVariant, it stopped fighting back and, then, KSP-Recall did its job on Editor. Fixing bugs by removing code is, well, embarrassing. In a way or another, this was the last major bug on TweakScale. Now I can, finally, be back on doing real improvements on TS. I will soon™ publish a new Beta release with some serious refactoring which will allow me to work better and faster on supporting 3rd parties futurelly - things on the Companion Program will start to develop faster once 2.5 reaches the main stream - and I'm considering speeding it up by reworking the ROAD MAP to postpone some things in favor of other ones. Disclaimer By last, but not the least... Spoiler No Module Manager was harmed during the development of TweakScale. This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). A bit less Soon™. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong. Edited January 26, 2023 by Lisias curseforge online Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 26, 2023 Share Posted January 26, 2023 (edited) 16 hours ago, Lisias said: ANNOUNCE Release 2.4.6.20 is available for downloading, with the following changes: MOAR bug fixes! Updates KSPe.Light with yet moar bug fixes. Closes Issues: #261 Misbehaviour (again) while scaling parts with VARIANT #238 TweakScale is failing to consistently resize the Attachment Node’s sizes. I finally nailed the Editor's Attachment Problems!!! #hurray!!! 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! Edited January 26, 2023 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 26, 2023 Author Share Posted January 26, 2023 (edited) 5 hours ago, AccidentalDisassembly said: 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 Ah, Fuel Switches! That's the thing: TweakScale needs to be taught about Fuel Switches, so things would work as you (reasonably) want. Problem - historically, shoving 3rd party Fuel Switches support directly into TweakScale leaded to tons os bugs - you fix something for a dude, another one to two got screwed. You rush to fix one of these two, you screw up the first and make things worst for the second... And B9PS had earned me a huge lot of headaches in the past by doing exactly that. In special, when B9PS detects a second Fuel Switch on a part, it refrain itself from working on that part, but it keeps handling events from people that needs to announce or asks things to/from it, causing breakage. Breakage that leads to a support fest to innocent add'ons that were just doing what they are expected to do! Spoiler TL;DR: B9PS still tries to compute the IPartCostModifier and IPartMassModifier interfaces even when it is self-deactivated, what causes NREs and Divisions By Zero inside it! So, how a 3rd party can tell when B9PS is self deactivated or not? And why they should? Why not answering 0 on these Interfaces when B9PS had self deactivated itself? This is a B9PS bug, and should be fixed there. I had fixed some B9PS bugs myself in the past, but I'm out of time for doing it nowadays - B9PS is a pretty complex piece of software, I don't have time to spend on learning it so I can fix things myself! It's the reason "Stock" TweakScale only supports Stock + DLCs and that's it. However… This doesn't means that 3rd parties will not be supported. It only happens that such support was delegated into specialised "add'on' add'ons", called TweakScale Companion. You will find more on the TweakScale Companion Program's thread: In time, I just incepted the TweakScale Companion for Fuel Switches here. However, this only works on the TweakScale Beta branch - that soon™ will be promoted to the new 2.5 TweakScale series. I had made some heavy refactoring on TS to allow easier and better coping with such more exotic PartModules B9PS is the next on the line for being implemented, I'm planning to have it working when I launch 2.5 into the main stream, hopefully in the next few weeks.[Not anymore: just realised that B9PS handles TweakScale itself!!] — — — POST EDIT — — — 5 hours ago, AccidentalDisassembly said: Hope that helps track down the B9 Part Switch issues... sorry to be a bummer! Not a problem, but please remember that TweakScale doesn't supports anything but Stock + DLC. Anything else will be supported on a specialised TweakScale Companion, and currently I didn't wrote one for B9PS. Yet. Once I publish it, then please file bug reports on the thing! — — — POST EDIT² — — — Humm… Perhaps this is related to KSP-Recall ? Since KSP 1.9 Editor is royally screwing up TweakScale by resetting things to the prefab on some circumstances and since this is a KSP issue and not TweakScale, I solved the problem on KSP-Recall so TweakScale could focus on its core business instead of trying dark magic to workaround them (and this was another source of immense headaches for me in the past - things got infinitely better when I decided to handle KSP idiosyncrasies on KSP-Recall instead on TweakScale). Since B9PS probably had to cope with the same problems, and probably decided to work around it themselves, they are probably having the same problems TweakScale had in the past - i.e., a toe stomping fest between more than one add'on trying to save the day at the same time. Try this on the affected rig (save it somewhere in GameData, I suggest GameData/__LOCAL/KSP-Recall/B9PS.cfg to be easily findable later): @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FINAL { -MODULE[AttachedOnEditor] { } } Let me know if this solves the problem for you - if yes, it's KSP-Recall the one that needs to be updated! Edited January 27, 2023 by Lisias Hit "save" too soon. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 27, 2023 Author Share Posted January 27, 2023 (edited) NOTAM I just released the latest BETA for the (now) near coming TweakScale 2.5. A huge refactoring was finished (I think the last one before - if I ever - start to think on TweakScale3), and I need to have this tested on the field in order to check for any unexpected problems these change may cause. I reverted a (now) old decision on using :FOR[TweakScale] in the standard patches. In these two years, very, but very few Add'Ons had adopted the needed protocol to prevent breakage (i.e., using :AFTER[TweakScale] or even :FINAL when in need to change a TweakScale standard behaviour). So that ship has sailed at this point, and the Right Thing™ will just not happen anymore. "Vida que segue." On the bright side, TweakScale 2.5 BETA is now completely free of any "alien" code. To tell you the true, not even Stock and DLC specific code is there anymore, everything is now on the specialised DLLs for each KSP version. I finally made TweakScale's Scale Engine completely game agnostic (with some obvious limitations, as it still depends from the KSP's life cycle and GameDatabase!). This means 100% clean 3rd party support without the weird shenanigans I had to code in the first TweakScale Companions (some of them will be soon™ rewrote to this new programming interface), and I now have a decent place to shove any Robotics specific code I need to prevent a myriad of problems from being escalated by TweakScale (and without risking screwing up what works fine). I suggest to anyone willing to risk their SAS with this stunt to have TweakScale Companion "ÜberPacket" installed, as I'm removing even the alien patches from the standard distribution into the Companions - and some ones, like Firespitter, will cause crashes without the specialised support from the respective Companions. Links into the spoiler below: Spoiler https://github.com/net-lisias-ksp/TweakScale/releases/tag/PRERELEASE%2F2.5.0.50 https://github.com/net-lisias-ksp/TweakScaleCompanion/releases Keep in mind: you are using a BETA release, and things can go down trough the tubes pretty fast if any mistake had passed trough. MAKE BACKUPS of everything to be on the safe side, and use them instead of your main gaming files. Ideally, you must be able to remove TweakScale 2.4.x series from a game, install 2.5 and the TSC ÜberPacket and things will just keep working as nothing had changed (other than some improvements on the new patches). But this is what I'm intending to do, what may not be exactly what I effectively did on this BETA release. So, again, MAKE BACKUPS if you decide to help me up with this BETA. And don't risk your valuable savegames on it. Please report any problems, anything, on the issue #42 (lucky number! ) on TweakScale's issue tracker. IMPORTANT NOTE: You need to use the 2.5's 999_Scale_Redist.dll (versioned to 1.2), completely replacing any older on GameData, or nothing made for 2.5 (including itself) will work. Everything compiled using the older 999_Scale_Redist.dll (versioned to 1.0) are expected to work fine, as the new Scale_Redist is backwards compatible down to the first one from 2013. Do not compile anything against it, however - remember, it's still BETA. Edited January 27, 2023 by Lisias Important Note Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 27, 2023 Share Posted January 27, 2023 (edited) 5 hours ago, Lisias said: Ah, Fuel Switches! That's the thing: TweakScale needs to be taught about Fuel Switches, so things would work as you (reasonably) want. Problem - historically, shoving 3rd party Fuel Switches support directly into TweakScale leaded to tons os bugs - you fix something for a dude, another one to two got screwed. You rush to fix one of these two, you screw up the first and make things worst for the second... And B9PS had earned me a huge lot of headaches in the past by doing exactly that. In special, when B9PS detects a second Fuel Switch on a part, it refrain itself from working on that part, but it keeps handling events from people that needs to announce or asks things to/from it, causing breakage. Breakage that leads to a support fest to innocent add'ons that were just doing what they are expected to do! Reveal hidden contents TL;DR: B9PS still tries to compute the IPartCostModifier and IPartMassModifier interfaces even when it is self-deactivated, what causes NREs and Divisions By Zero inside it! So, how a 3rd party can tell when B9PS is self deactivated or not? And why they should? Why not answering 0 on these Interfaces when B9PS had self deactivated itself? This is a B9PS bug, and should be fixed there. I had fixed some B9PS bugs myself in the past, but I'm out of time for doing it nowadays - B9PS is a pretty complex piece of software, I don't have time to spend on learning it so I can fix things myself! It's the reason "Stock" TweakScale only supports Stock + DLCs and that's it. However… This doesn't means that 3rd parties will not be supported. It only happens that such support was delegated into specialised "add'on' add'ons", called TweakScale Companion. You will find more on the TweakScale Companion Program's thread: In time, I just incepted the TweakScale Companion for Fuel Switches here. However, this only works on the TweakScale Beta branch - that soon™ will be promoted to the new 2.5 TweakScale series. I had made some heavy refactoring on TS to allow easier and better coping with such more exotic PartModules B9PS is the next on the line for being implemented, I'm planning to have it working when I launch 2.5 into the main stream, hopefully in the next few weeks.[Not anymore: just realised that B9PS handles TweakScale itself!!] — — — POST EDIT — — — Not a problem, but please remember that TweakScale doesn't supports anything but Stock + DLC. Anything else will be supported on a specialised TweakScale Companion, and currently I didn't wrote one for B9PS. Yet. Once I publish it, then please file bug reports on the thing! — — — POST EDIT² — — — Humm… Perhaps this is related to KSP-Recall ? Since KSP 1.9 Editor is royally screwing up TweakScale by resetting things to the prefab on some circumstances and since this is a KSP issue and not TweakScale, I solved the problem on KSP-Recall so TweakScale could focus on its core business instead of trying dark magic to workaround them (and this was another source of immense headaches for me in the past - things got infinitely better when I decided to handle KSP idiosyncrasies on KSP-Recall instead on TweakScale). Since B9PS probably had to cope with the same problems, and probably decided to work around it themselves, they are probably having the same problems TweakScale had in the past - i.e., a toe stomping fest between more than one add'on trying to save the day at the same time. Try this on the affected rig (save it somewhere in GameData, I suggest GameData/__LOCAL/KSP-Recall/B9PS.cfg to be easily findable later): @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FINAL { -MODULE[AttachedOnEditor] { } } Let me know if this solves the problem for you - if yes, it's KSP-Recall the one that needs to be updated! 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! Edited January 27, 2023 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 27, 2023 Author Share Posted January 27, 2023 (edited) 10 hours ago, AccidentalDisassembly said: In any case, all of these behaviors are different from what happened on .19, so... effects are happening! Until 2.4.6.19, I was screwing (and being screwed back) by ModulePartVariants. The first time I implemented support for it, I thought that some weirds interactions I was having in the code was due some idiosyncrasy (or plain bug) from the PartModule itself. I think I managed to kick this thing trough the doors on the KSP 1.6 times. Spoiler What I did was to force my hand on the problem after ModulePartVariants had "misbehaved". Essentially doing myself part of the work done by it (to tell you the true, calculating where I thought the part should be, calculating the difference from where part effectively was, and then translating the part into the right place using that diff). Problem, by some mistake of mine, if a part is rotate to any axis more than 90º, any Part attached to it would be displaced, as this: But… And I missed this detail at that time, only when the craft was being loaded into the Editor!! I was pretty convinced that this was something I did wrong, but didn't found where - and I completely failed to note that this same thing wasn't happening when the craft was being loaded by the Flight Scene - for some reason beyond my current comprehension, I didn't connected the dots: the craft being loaded correctly into the Flight Scene definitively ruled out my code from the problem. Then, I had this misbehaviour: Every time I change the variant on an already scaled part, the attachment points were being miscalculated (see the Juno being injected inside the Adapter tank!). This one was on me for sure, but I also didn't understood exactly why and where - the code was looking solid, the logging was giving me the numbers I was expecting. Then I finally had a happy thought (#einsteinFellings). "Dude… The damned craft was being loaded fine on Flight Scene! I'm innocent on that one!". So I though it would be another bug on Editor, and tried to figure it out using KSP-Recall. No dice. Then I got fed up, and left the task to be tackled down later and published .19 the way it was. I was playing another game I'm liking very much (Planet Nomads) in this weekend when another "happy thought" happened to me: "Two lightnings can hit the same person on the same place at the same time, after all" (the dude on the video survived). There's nothing preventing two problems from happening at the same times with similar effects. So my code could both be doing something right (and later I discovered it was right but useless) and wrong at the same time, being the second "wrong" being a consequence os something else. So I removed my custom scaling node code from the Variant Scale Engine and trusted the ModulePartVariant would do its job correctly. And it did. The second problem was solved by rescaling the whole part once the user changes the Variant - then the ticket was solved. I had wrote a code that solved the problem by duplicating a behaviour, and that code ended up in my way when something else had happened rendering me without being sure about who as borking and where. So, now, we "can't" have a problem on TweakScale anymore, because I'm trusting ModulePartVariant to do its part of the deal, and then just scaled things using the same code that is used for parts without variants since the beginning of times. The only problem at hands, now, is the one on Editor that gets completely confused if any of the first two parts of a Craft (from the root) doesn't have the ModulePartVariant and then a part with it happens somewhere in the chain (or something like that, I forgot the gory details). And this one is already being tackled down by KSP-Recall using the AttachedOnEditor thingy. When I found that Editor was also screwing up with Resources, I wrote Resourceful to work around it. Now, back to the problem at our hands on B9PS: I managed to reproduce the problem Any part with B9PS switching fuels is being affected, so CryoTanks is out of the problem - but you already knew it. But I reproduced the problem after uninstalling CryoTanks, CommunityResourcePack and Dynamic BatteryStorage just to have hard evidence of it. You are right - when you scale the original tank, everything works fine. When you scale a clone, only the resources of the clone gets recalculated, the other two keep the last values before the scaling. KSP-Recall is not involved on the mess, I removed it from the parts with B9PS and the misbehaviour kept happening. On the bright side, apparently B9PS doesn't needed it. So I will remove KSP-Recall's AttachedOnEditor and Resourceful from parts using it and save some memory and CPU cycles. My code on the Scaling Engine for ModulePartVariant was innocent anyway, because B9PS removes the ModulePartVariant from the Part, and then TweakScale reverts to use the Classic Scale Engine - and this one is solid for almost a decade by now. So the change in behaviour is happening because I gave up trying to be smart and decided to rescale the whole part all the time on Editor, instead of doing it only when I thought it was needed - this commit is the only thing between .19 and .20 that could be influencing on the change of behaviour. Humm.. Perhaps B9PS is innocent, and it only happens that you noticed the problem by using it? So I fired up an almost clean KSP 1.12.5 (only TweakScale 2.4.6.20 and Recall) and reproduced the problem the same. Damn. Worst. It's happening also with parts without ModulePartVariant (Mk1 LF Fuselage). Danm²: Start the craft using a MK1 LF Tank Attach another one radially using symmetry (I used 3) Scale any cloned tank (do not scale the original one). Problem reproduced: by opening the PAW of every tank, you will note that at least one of them will have the wrong fuel capacity - most of the time, only he one you scaled up will be fine. And interesting… If you use Chain Scale (and scale the root part), all the parts are scaled correctly! But… Such a marvellous bork would be detected while development. So I decided to make regressions tests on 2.4.6.20 into other KSP versions too (I usually develop on 1.4.3 and test things up, because KSP 1.4.3 is fantastically faster on my old potato than anything newer!). Hell, the damned thing worked fine on KSP 1.4.3!! Damn³!!!! (not a surprise, right? I would had detected the problem on it) Tried it again on KSP 1.8.1 : Works fine!! Tried it on KSP 1.11.2 : Works fine!!! So this is a new problem introduced by KSP somewhere on the 1.12.x series, apparenlty. I don't have 1.12.0 neither 1.12.1 installed anymore, so I tried it on a 1.12.2 test bed that I forgot to delete: It worked fine!!! That's weird… This kind of bug usually happens on the .0 release. Something wrong is not right here... So I tried again on 1.12.5 (didn't had touched that thing since the last test a couple hours ago). And the problem was there... Confusing. Why only my 1.12.5 is being screwed by 2.4.6.20? 1.12.2 worked fine. Then I noticed the TweakScale button on the toolbar was greenlit - and I remembered that on all the other tests, that button was turned off. Then I thought to myself, what a wonderful world… I mean… "Nooooooo… IT CAN'T BE….". And then I clicked on it twice - don't even unchecked anything. Guess what? The problem vanished!!!! So that's the "fix": open and close the TweakScale's Option Menu and everything (apparently) will be fine after!! At least on an almost pure stock rig. @AccidentalDisassembly, please reproduce the problem using B9PS and try my "fix" - right now I need to take some rest, it's still working days and I just had recovered from a nasty flu (I'm wasted, to tell you the true). @Sokol_323, the problem you described here may be related! If the problem you reported ever happen again, try clicking the TweakScale button twice to see what happens (do not bother setting or unsetting any options!). My current working theory is that I forgot to initialise something when one (or all) of that Options are set when booting KSP! I will investigate it further on this weekend! Cheers for all, and thank you for your reports! That one I would never caught by myself!!!! Cheers! Edited January 27, 2023 by Lisias Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 27, 2023 Share Posted January 27, 2023 (edited) 13 hours ago, Lisias said: Until 2.4.6.19, I was screwing (and being screwed back) by ModulePartVariants. The first time I implemented support for it, I thought that some weirds interactions I was having in the code was due some idiosyncrasy (or plain bug) from the PartModule itself. I think I managed to kick this thing trough the doors on the KSP 1.6 times. Reveal hidden contents What I did was to force my hand on the problem after ModulePartVariants had "misbehaved". Essentially doing myself part of the work done by it (to tell you the true, calculating where I thought the part should be, calculating the difference from where part effectively was, and then translating the part into the right place using that diff). Problem, by some mistake of mine, if a part is rotate to any axis more than 90º, any Part attached to it would be displaced, as this: But… And I missed this detail at that time, only when the craft was being loaded into the Editor!! I was pretty convinced that this was something I did wrong, but didn't found where - and I completely failed to note that this same thing wasn't happening when the craft was being loaded by the Flight Scene - for some reason beyond my current comprehension, I didn't connected the dots: the craft being loaded correctly into the Flight Scene definitively ruled out my code from the problem. Then, I had this misbehaviour: Every time I change the variant on an already scaled part, the attachment points were being miscalculated (see the Juno being injected inside the Adapter tank!). This one was on me for sure, but I also didn't understood exactly why and where - the code was looking solid, the logging was giving me the numbers I was expecting. Then I finally had a happy thought (#einsteinFellings). "Dude… The damned craft was being loaded fine on Flight Scene! I'm innocent on that one!". So I though it would be another bug on Editor, and tried to figure it out using KSP-Recall. No dice. Then I got fed up, and left the task to be tackled down later and published .19 the way it was. I was playing another game I'm liking very much (Planet Nomads) in this weekend when another "happy thought" happened to me: "Two lightnings can hit the same person on the same place at the same time, after all" (the dude on the video survived). There's nothing preventing two problems from happening at the same times with similar effects. So my code could both be doing something right (and later I discovered it was right but useless) and wrong at the same time, being the second "wrong" being a consequence os something else. So I removed my custom scaling node code from the Variant Scale Engine and trusted the ModulePartVariant would do its job correctly. And it did. The second problem was solved by rescaling the whole part once the user changes the Variant - then the ticket was solved. I had wrote a code that solved the problem by duplicating a behaviour, and that code ended up in my way when something else had happened rendering me without being sure about who as borking and where. So, now, we "can't" have a problem on TweakScale anymore, because I'm trusting ModulePartVariant to do its part of the deal, and then just scaled things using the same code that is used for parts without variants since the beginning of times. The only problem at hands, now, is the one on Editor that gets completely confused if any of the first two parts of a Craft (from the root) doesn't have the ModulePartVariant and then a part with it happens somewhere in the chain (or something like that, I forgot the gory details). And this one is already being tackled down by KSP-Recall using the AttachedOnEditor thingy. When I found that Editor was also screwing up with Resources, I wrote Resourceful to work around it. Now, back to the problem at our hands on B9PS: I managed to reproduce the problem Any part with B9PS switching fuels is being affected, so CryoTanks is out of the problem - but you already knew it. But I reproduced the problem after uninstalling CryoTanks, CommunityResourcePack and Dynamic BatteryStorage just to have hard evidence of it. You are right - when you scale the original tank, everything works fine. When you scale a clone, only the resources of the clone gets recalculated, the other two keep the last values before the scaling. KSP-Recall is not involved on the mess, I removed it from the parts with B9PS and the misbehaviour kept happening. On the bright side, apparently B9PS doesn't needed it. So I will remove KSP-Recall's AttachedOnEditor and Resourceful from parts using it and save some memory and CPU cycles. My code on the Scaling Engine for ModulePartVariant was innocent anyway, because B9PS removes the ModulePartVariant from the Part, and then TweakScale reverts to use the Classic Scale Engine - and this one is solid for almost a decade by now. So the change in behaviour is happening because I gave up trying to be smart and decided to rescale the whole part all the time on Editor, instead of doing it only when I thought it was needed - this commit is the only thing between .19 and .20 that could be influencing on the change of behaviour. Humm.. Perhaps B9PS is innocent, and it only happens that you noticed the problem by using it? So I fired up an almost clean KSP 1.12.5 (only TweakScale 2.4.6.20 and Recall) and reproduced the problem the same. Damn. Worst. It's happening also with parts without ModulePartVariant (Mk1 LF Fuselage). Danm²: Start the craft using a MK1 LF Tank Attach another one radially using symmetry (I used 3) Scale any cloned tank (do not scale the original one). Problem reproduced: by opening the PAW of every tank, you will note that at least one of them will have the wrong fuel capacity - most of the time, only he one you scaled up will be fine. And interesting… If you use Chain Scale (and scale the root part), all the parts are scaled correctly! But… Such a marvellous bork would be detected while development. So I decided to make regressions tests on 2.4.6.20 into other KSP versions too (I usually develop on 1.4.3 and test things up, because KSP 1.4.3 is fantastically faster on my old potato than anything newer!). Hell, the damned thing worked fine on KSP 1.4.3!! Damn³!!!! (not a surprise, right? I would had detected the problem on it) Tried it again on KSP 1.8.1 : Works fine!! Tried it on KSP 1.11.2 : Works fine!!! So this is a new problem introduced by KSP somewhere on the 1.12.x series, apparenlty. I don't have 1.12.0 neither 1.12.1 installed anymore, so I tried it on a 1.12.2 test bed that I forgot to delete: It worked fine!!! That's weird… This kind of bug usually happens on the .0 release. Something wrong is not right here... So I tried again on 1.12.5 (didn't had touched that thing since the last test a couple hours ago). And the problem was there... Confusing. Why only my 1.12.5 is being screwed by 2.4.6.20? 1.12.2 worked fine. Then I noticed the TweakScale button on the toolbar was greenlit - and I remembered that on all the other tests, that button was turned off. Then I thought to myself, what a wonderful world… I mean… "Nooooooo… IT CAN'T BE….". And then I clicked on it twice - don't even unchecked anything. Guess what? The problem vanished!!!! So that's the "fix": open and close the TweakScale's Option Menu and everything (apparently) will be fine after!! At least on an almost pure stock rig. @AccidentalDisassembly, please reproduce the problem using B9PS and try my "fix" - right now I need to take some rest, it's still working days and I just had recovered from a nasty flu (I'm wasted, to tell you the true). @Sokol_323, the problem you described here may be related! If the problem you reported ever happen again, try clicking the TweakScale button twice to see what happens (do not bother setting or unsetting any options!). My current working theory is that I forgot to initialise something when one (or all) of that Options are set when booting KSP! I will investigate it further on this weekend! Cheers for all, and thank you for your reports! That one I would never caught by myself!!!! Cheers! 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! Edited January 27, 2023 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Mussarelinha Posted January 27, 2023 Share Posted January 27, 2023 Tweakscale stopped working after this update, is there a reason? i reinstalled, deleted and installed again, but to no avail... Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 2 hours ago, Mussarelinha said: Tweakscale stopped working after this update, is there a reason? i reinstalled, deleted and installed again, but to no avail... Send me your KSP.log and I will check what happened - TweakScale usually logs a cry for help there, telling what had happened! 2 hours ago, AccidentalDisassembly said: 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. I confess that odd it was the damned stunt doing the trick on my side. Just for the sake of curiosity - did reproduced the problem on an almost vanilla installation? (KSP + DLC + KSP-Recall + TweakScale) 2 hours ago, AccidentalDisassembly said: 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. That's absolutely weird. I will do some more checks. Can you send me a new KSP.log from your rig after reproducing the problem? 2 hours ago, Mussarelinha said: Tweakscale stopped working after this update, is there a reason? i reinstalled, deleted and installed again, but to no avail... How exactly it stopped to work? Do you see a TwesakScale icon on the toolbar? Or it's a functinal problem (i.e, TweakScale is there, but it's not working as expected, perhaps with weird behaviours)? I'm curious about these problems, because I did tested the thing (in multiple KSP versions!) before releasing it. I need to find a pattern. Please send me your KSP.log in a way or another, so I can see what's installed on your rig and check for anything smelly. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 (edited) 5 hours ago, AccidentalDisassembly said: 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. That's the problem: I'm easily reproducing this on KSP without B9PS installed. B9PS is just an innocent bystander yelling about something else hitting him by behind. TweakScale appears to be the hitter, but I can't rule out something else inducing TweakScale to the err, because… Hell, this damned thing is working on most test beds I have (1.4.3, 1.7.3, 1.8.1, 1.11.2 for sure). Anyway, this is how I reproducing the problem now, using a pretty clean KSP rig only with Recall and TweakScale: Start a craft using MK1 LF Tank Place a second MK1 LF Tank radially, using symmetry (I'm using 3) Scale the original radially attached tank once. All the clones scale fine Scale the original radially attached tank again All the clones are not scaled right, they retain the previous RESOURCES settings. Then I made another check, starting from the point I left : I detached the original radially attached tank Attached it back two more clones are created All parts are descaled back to the original size But the original tank retains the previous RESOURCE settings. I reproduced this on KSP 1.12.5. I will check this behaviour on previous KSP releases I still have around to confirm if the problem is on TweakScale, or if this is something new. Or both... — — POST EDIT — — **NOW** I could reproduce the problem deterministically on KSP 1.11.2 too. Checking all the others. — — POST POST EDIT — — I got things right on KSP 1.10.1. So I'm guessing something changed (again) on Editor on KSP 1.11.x (probably .0 , but I don't have a working 1.11.0 test bed anymore). This ruled out (apparently) TweakScale of any wrongdoing, it's something "new" that happened on the 1.11.x series that, somehow, my previous crappy code was making. Now that I decided to "trust" ModulePartVariant, KSP's Editor (apparently) decided to strike back in revenge. I had already saw this movie before - or one pretty similar: Editor is squashing current's part data with prefab's again. I will keep testing things down to 1.3.1 just to be absolutely sure about this working theory - this can be also a race condition unadrevtidly created by TweakScale's code since ever and that I uncovering now. If I'm right, I will probably detect an anomaly or two sooner or later by going back KSP versions, as each version added or removed something from the Part's Life Cycle and this would have some effect on the race condition. Still working on it. I need to be reasonably sure about the race condition or the Editor's prefab squashing because the solution for the problem will differ accordingly. — — POST POST POST EDIT — — Interesting. On 1.9.1, the first part of the test (scaling the radially attached thanks) passed, but the second (detaching e reattaching) failed. Redoing the test (both this time) on 1.10.1, From now on, I will just update the following table as I do the checkings (1st check is the scaling the radial tanks twice, the 2nd is detaching and attaching again): KSP 1st Check 2nd Check 1.12.5 Fail Fail 1.11.2 Fail Fail 1.10.1 Pass Fail 1.9.1 Pass Fail 1.8.1 Pass Fail 1.7.3 Pass Pass 1.6.1 Pass Pass 1.5.1 Pass Pass 1.4.5 Pass Fail (!!!) Pass 1.4.3 Pass Pass 1.4.1 Pass Pass 1.3.1 Pass Pass Note: the 2nd Check on 1.4.5 didn't really failed, I messed the test myself. Doing the check properly 'fixed' the results Edited January 28, 2023 by Lisias POST³ EDIT Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 28, 2023 Share Posted January 28, 2023 (edited) 2 hours ago, Lisias said: I confess that odd it was the damned stunt doing the trick on my side. Just for the sake of curiosity - did reproduced the problem on an almost vanilla installation? (KSP + DLC + KSP-Recall + TweakScale) 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! Edited January 28, 2023 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 (edited) 1 hour ago, AccidentalDisassembly said: 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. DAMN! I screwed up the merge. KSPe should be a dependency only on the Beta branch, not the mainstream! As you will observe above, I'm nailing the problems as follows: 1st Check: something changed on KSP 1.11.x, and the code cleanup I did on TS probably removed some crappy code that was masking it. I will check the change log to see if this is not something I had already fixed but forgot about. EDIT: Nope. I never handled it before, this really caught me with my pants down... 2nd Check: By some weird reason, when using Auto Scale, by attaching the part back, all the parts (original and symmetries) get scaled to the size of the parent (as expected). But the root part keeps its resources as is was still scaled. This one is my fault. I forgot to send a Message to KSP-Recall to rebuild the Resources cache. You will note that the only KSP versions affected are the ones that need Resourceful to be applied! EDIT: While fixing #282 (see below), I detected that once Auto Scale started to behave nicely on KSP <= 1.10.2, on 1.11.2 it started to behave exactly like #283. I think KSP 1.11.x screwed up royally this.part.symmetryCounterparts I'm inspecting your logs and will redo the tests your way now. In a way or another, I had to withdraw 2.4.6.20 . Too much hassle, I will issue a 2.4.6.21 as soon as I fix the KSPe mishap, the fix for the "2nd Check" (it should be a easy pick) and whatever I need to do to survive the mess KSP 1.11.x brought to me. I think your issues are the same, being the reason I intend to reproduce "your" way on KSP 1.12.5 and then on 1.10.1 to see what happens. — — POST EDIT — — Yep… It's it. The symmetry handling was broken on KSP 1.11.x , but since I was still forcing my hand on things by brute force, I didn't detected it. Once I removed that half baked solution I had coded, the problem ceased from being masked by it and so… https://github.com/net-lisias-ksp/TweakScale/issues/283 And since we are here, this one is on me: https://github.com/net-lisias-ksp/TweakScale/issues/282 Edited January 28, 2023 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
Mussarelinha Posted January 28, 2023 Share Posted January 28, 2023 (edited) where can i find the KSP.log? I am playing using the epicgames version btw, that is, i downloaded ksp from the epicgames and i am playing with mods via forge Edited January 28, 2023 by Mussarelinha Quote Link to comment Share on other sites More sharing options...
Mussarelinha Posted January 28, 2023 Share Posted January 28, 2023 12 hours ago, Lisias said: Send me your KSP.log and I will check what happened - TweakScale usually logs a cry for help there, telling what had happened! I confess that odd it was the damned stunt doing the trick on my side. Just for the sake of curiosity - did reproduced the problem on an almost vanilla installation? (KSP + DLC + KSP-Recall + TweakScale) That's absolutely weird. I will do some more checks. Can you send me a new KSP.log from your rig after reproducing the problem? How exactly it stopped to work? Do you see a TwesakScale icon on the toolbar? Or it's a functinal problem (i.e, TweakScale is there, but it's not working as expected, perhaps with weird behaviours)? I'm curious about these problems, because I did tested the thing (in multiple KSP versions!) before releasing it. I need to find a pattern. Please send me your KSP.log in a way or another, so I can see what's installed on your rig and check for anything smelly. after i downloaded the .5 update it just stopped working as if it wasn't installed, the icon wasn't present and the option to scale things wasn't present either. Quote Link to comment Share on other sites More sharing options...
Mussarelinha Posted January 28, 2023 Share Posted January 28, 2023 Like, "Vessel name is missing part module Tweakscale" Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 (edited) NOTAM Oh, yeah. I was caught with my pants down again. Further jokes about is not allowed by Forum Rules 2.2.c, d & g. This last 2.4.6.20 release marvellously blew up on my… face. That's the reasons: I forgot a development library as a dependency, allowing it to leak into mainstream I did that before on another add'on, and forgot to echo the fix on TS KSP 1.12.5 was recently released, and I didn't created yet the Acceptance Test test rig for it, so I ended making the smoke tests on a dirty development environment. Not one of my brightest moments. But it ended being for the best. A major bork on scaling Resources was detected by our fellow Kerbonaut @AccidentalDisassembly It was determined that TweakScale is not the cause, as the problem started to happen only on KSP 1.11.x (just have 1.11.2 installed at this point). But yet, it's something that needs to be tackled down somehow. Another bug on the Auto Scale (and Chain) were detected in the process (and this one is fixed now). Now, let's talk about what's bitting our SASes right now. On KSP 1.11.x something changed (again) on Editor that screwed Part Switches and TweakScale by messing up the PartModule's life cycle when the Part being configured have Symmetries Counter Parts. Apparently a PartMessage is not being issued somehow (or issued too soon or too late), and so a chain of events that was happening until 1.10.1 stopped happening (or do it on an useless timeframe) from 1.11.x and forward. Damn, this is pretty annoying. By some reason, that crappy code I got rid from TweakScale was masking this problem. I don't have the slightest idea what, where and why. I prefer not to think about too much, I'm still burnt by that AirplanePlus MonkeyPatching problem. In a way or another, I had nailed down the problem to KSP 1.11.x . The "new" TweakScale code works perfectly from KSP 1.3.1 to KSP 1.10.1. Another evidence that the root problem is Editor is that by saving the craft (or launching it), the problems detected on the Resources are "magically" fixed. Magically on quotes, because this is evidence that without Editor screwing it, TweakScale is working fine - otherwise things would be still screwed on Flight Scene. So, TL;DR: TweakScale is innocent, but it's up to me to cope with the mess nevertheless B9PS is also innocent, as it depends of TweakScale for knowing when to do its things, On the bright side, I discovered that at AttachedOnEditor and Attached Recall stunts are not needed when B9PS is installed on the part. Next version of Recall will withdraw itself from parts using it. Saving and loading the craft solves the problem. Again, this last info states clearly where the problem really is. I'm unsure if I will be able to fix this one, but since the impact is negligible - crafts are fine when launched, where things really matter - I will call it a day and release 2.4.6.21 with I have at hands now. Edited January 28, 2023 by Lisias Typos! Good thing they're not illegal! Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 3 hours ago, Mussarelinha said: where can i find the KSP.log? I am playing using the epicgames version btw, that is, i downloaded ksp from the epicgames and i am playing with mods via forge Ah, this makes things easier. Tell forge to uninstall 2.4.6.20 and install 2.4.6.19 back. I'm working on .21 right now, it should be available to downloading in a couple hours. And thanks for the heads up, I need to update the Support instructions for Epic Store! Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 28, 2023 Share Posted January 28, 2023 (edited) 1 hour ago, Lisias said: NOTAM Oh, yeah. I was caught with my pants down again. Further jokes about is not allowed by Forum Rules 2.2.c, d & g. This last 2.4.6.20 release marvellously blew up on my… face. That's the reasons: I forgot a development library as a dependency, allowing it to leak into mainstream I did that before on another add'on, and forgot to echo the fix on TS KSP 1.12.5 was recently released, and I didn't created yet the Acceptance Test test rig for it, so I ended making the smoke tests on a dirty development environment. Not one of my brightest moments. But it ended being for the best. A major bork on scaling Resources was detected by our fellow Kerbonaut @AccidentalDisassembly It was determined that TweakScale is not the cause, as the problem started to happen only on KSP 1.11.x (just have 1.11.2 installed at this point). But yet, it's something that needs to be tackled down somehow. Another bug on the Auto Scale (and Chain) were detected in the process (and this one is fixed now). Now, let's talk about what's bitting our SASes right now. On KSP 1.11.x something changed (again) on Editor that screwed Part Switches and TweakScale by messing up the PartModule's life cycle when the Part being configured have Symmetries Counter Parts. Apparently a PartMessage is not being issued somehow (or issued too soon or too late), and so a chain of events that was happening until 1.10.1 stopped happening (or do it on an useless timeframe) from 1.11.x and forward. Damn, this is pretty annoying. By some reason, that crappy code I got rid from TweakScale was masking this problem. I don't have the slightest idea what, where and why. I prefer not to think about too much, I'm still burnt by that AirplanePlus MonkeyPatching problem. In a way or another, I had nailed down the problem to KSP 1.11.x . The "new" TweakScale code works perfectly from KSP 1.3.1 to KSP 1.10.1. Another evidence that the root problem is Editor is that by saving the craft (or launching it), the problems detected on the Resources are "magically" fixed. Magically on quotes, because this is evidence that without Editor screwing it, TweakScale is working fine - otherwise things would be still screwed on Flight Scene. So, TL;DR: TweakScale is innocent, but it's up to me to cope with the mess nevertheless B9PS is also innocent, as it depends of TweakScale for knowing when to do its things, On the bright side, I discovered that at AttachedOnEditor and Attached Recall stunts are not needed when B9PS is installed on the part. Next version of Recall will withdraw itself from parts using it. Saving and loading the craft solves the problem. Again, this last info states clearly where the problem really is. I'm unsure if I will be able to fix this one, but since the impact is negligible - crafts are fine when launched, where things really matter - I will call it a day and release 2.4.6.21 with I have at hands now. 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. Edited January 28, 2023 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 28, 2023 Author Share Posted January 28, 2023 (edited) 1 hour ago, AccidentalDisassembly said: 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). Neither did I!!! I had to quit KSP to do something else, and when I reloaded it later I was lazy and reload the craft instead of doing everything from scratch!! 1 hour ago, AccidentalDisassembly said: 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. Well, right now, this is not happening to me, so perhaps the #282 ended up fixing something else by collateral effect. I just published 2.4.6.21 (github and curseforge are up to date right now as I already had people downloading 2.4.6.20 from them, on SpaceDock I will delay a few hours just in case…). But since B9PS is not Stock, if the problem persists it will be tackled down on TweakScale Companion for Fuel Switches from now on. It will be tackled down, rest assured. It only won't be by TweakScale. 1 hour ago, AccidentalDisassembly said: 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... There's a chance that this would be KSP-Recall "restoring" that last known values for the Resources due KSP being known to squash the current one from values from prefab. Since KSP (from 1.11.x) is failing somehow to handle Symmetries from TweakScale, then these poor guys ended up not receiving some PartMessages (I confirmed that they are being sent by TweakScale), and since KSP-Recall rely on PartMessages from TweakScale (or any other interested party) to know when it should refresh its internal structures from new data, what you are describing can be a possible consequence. Anyway, since I was testing B9PS anyway, I checked if removing some PartModules from Recall when the part uses B9PS would cause any problem, and I realised that not. I'm publishing a new KSP-Recall release in the next hour reflecting this. I think this may solve this punctual problem from yours. 1 hour ago, AccidentalDisassembly said: 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. There are no exceptions on TweakScale code, other than specialised handling of "Classic Parts" and "Parts with ModulePartVariant". And since B9PS get rid of every ModulePartVariant on the part, TS is surely using the Classic Engine for parts with B9PS - that are known to work fine together for years. So I'm reasonably sure that by fixing the problem for on part, we will fix it for all the other - unless KSP's Editor would be screwing something else besides Resources from 1.11.x and newer. Curiously, I the latest B9PS on KSP 1.10.1 , and it got screwed on it! I just fail to understand (or perhaps I don't?) why "new" TweakScale fails on 1.11.x and 1.12.x but works fine on everything else, why "older" TweskScale is working fine on everything, and why B9PS is working fine only from KSP 1.11.x . I think I will need to check B9PS historical commits since 1.10.1 to see what had changed in order to get some idea about what in hell is happening here... Edited January 28, 2023 by Lisias Tyops, what else? Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted January 28, 2023 Share Posted January 28, 2023 17 minutes ago, Lisias said: Neither did I!!! I had to quit KSP to do something else, and when I reloaded it later I was lazy and reload the craft instead of doing everything from scratch!! Well, right now, this is not happening to me, so perhaps the #282 ended up fixing something else by collateral effect. I just published 2.4.6.21 (github and curseforge are up to date right now as I already had people downloading 2.4.6.20 from them, on SpaceDock I will delay a few hours just in case…). But since B9PS is not Stock, if the problem persists it will be tackled down on TweakScale Companion for Fuel Switches from now on. It will be tackled down, rest assured. It only won't be by TweakScale. There's a chance that this would be KSP-Recall "restoring" that last known values for the Resources due KSP being known to squash the current one from values from prefab. Since KSP (from 1.11.x) is failing somehow to handle Symmetries from TweakScale, then these poor guys ended up not receiving some PartMessages (I confirmed that they are being sent by TweakScale), and since KSP-Recall rely on PartMessages from TweakScale (or any other interested party) to know when it should refresh its internal structures from new data, what you are describing can be a possible consequence. Anyway, since I was testing B9PS anyway, I checked if removing some PartModules from Recall when the part uses B9PS would cause any problem, and I realised that not. I'm publishing a new KSP-Recall release in the next hour reflecting this. I think this may solve this punctual problem from yours. There are no exceptions on TweakScale code, other than specialised handling of "Classic Parts" and "Parts with ModulePartVariant". And since B9PS get rid of every ModulePartVariant on the part, TS is surely using the Classic Engine for parts with B9PS - that are known to work fine together for years. So I'm reasonably sure that by fixing the problem for on part, we will fix it for all the other - unless KSP's Editor would be screwing something else besides Resources from 1.11.x and newer. Curiously, I the latest B9PS on KSP 1.10.1 , and it got screwed on it! I just fail to understand (or perhaps I don't?) why "new" TweakScale fails on 1.11.x and 1.12.x but works fine on everything else, why "older" TweskScale is working fine on everything, and why B9PS is working fine only from KSP 1.11.x . I think I will need to check B9PS historical commits since 1.10.1 to see what had changed in order to get some idea about what in hell is happening here... 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! Quote Link to comment Share on other sites More sharing options...
noaa_satellite Posted January 29, 2023 Share Posted January 29, 2023 @LisiasSorry if this is a basic question but how do you change the mass scale exponent for a specific given part? Like a patch that identifies a specific part and just changes the mass scale exponent. I've been trying to figure it out on my own but it hasn't been working, so what's the right way to do it? Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 29, 2023 Author Share Posted January 29, 2023 21 minutes ago, noaa_satellite said: @LisiasSorry if this is a basic question but how do you change the mass scale exponent for a specific given part? Like a patch that identifies a specific part and just changes the mass scale exponent. I've been trying to figure it out on my own but it hasn't been working, so what's the right way to do it? by overwritting the mass exponent from the Part module like this: @PART[FancyPantsPart]:AFTER[TweakScale] { @MODULE[TweakScale] { %TWEAKSCALEEXPONENTS[Part] { %mass = 3.25 } } } This part will scale its mass, from now on, using a 3.25 exponent (yep, you can use fractions on the exponents!). The :AFTER will save you from some race conditions - use TweakScale is the part is being patched by TweakScale, otherwise use the name of the Add'On that had patched the part - if this patch "runs" before the target add'on is able to patch the file with their own patches, it will fail. The first "@" will prevent the patch if the part wasn't patched yet (important to prevent double patching if things goes out of hand). The "%" will add or replace the respective data into the TweakScale's section - it's almost impossible to have TweakScale patched on a part without having also a TWEAKSCALEEXPONENT for Part, and this one having the mass exponent. But, better safer than sorry. Avoid exponents less than 1.0 - it's almost sure it will not do what you expect. Quote Link to comment Share on other sites More sharing options...
Undone Posted January 29, 2023 Share Posted January 29, 2023 (edited) I've just come back to KSP after a long time out and trying to install some mods I've never used before - mainly KSPIE and GU, plus associated scaling mods. When I start up the game I get a fatal error message due to duplicated properties. I've tried looking through the log to figure it out but don't really know where to start. Full log is uploaded here: https://www.dropbox.com/s/ec7ej4bfmu28yd7/KSP.log?dl=0 Appreciate any help getting me going again! EDIT: After a bit more digging, I'll take an uneducated guess that the issue comes from KSPIE and Interstellar Technologies (which is a part mod recommended by KSPIE) both coming bundled with TweakScale and some conflict which has arisen as a result. Not the slightest clue where to start to resolve it though? Edited January 29, 2023 by Undone Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 29, 2023 Author Share Posted January 29, 2023 (edited) 4 hours ago, Undone said: I've just come back to KSP after a long time out and trying to install some mods I've never used before - mainly KSPIE and GU, plus associated scaling mods. When I start up the game I get a fatal error message due to duplicated properties. I've tried looking through the log to figure it out but don't really know where to start. Full log is uploaded here: https://www.dropbox.com/s/ec7ej4bfmu28yd7/KSP.log?dl=0 Appreciate any help getting me going again! EDIT: After a bit more digging, I'll take an uneducated guess that the issue comes from KSPIE and Interstellar Technologies (which is a part mod recommended by KSPIE) both coming bundled with TweakScale and some conflict which has arisen as a result. Not the slightest clue where to start to resolve it though? This is off: [LOG 12:01:06.904] Applying update TweakScale/patches/Squad/Cargo/@PART[cargoContainer]:NEEDS[Squad,TweakScale] to Squad/Parts/Cargo/CargoContainers/cargoContainer.cfg/PART[cargoContainer] [LOG 12:01:07.097] Applying update TweakScale/patches/SquadExpansion/Serenity/Cargo/@PART[cargoContainer] to Squad/Parts/Cargo/CargoContainers/cargoContainer.cfg/PART[cargoContainer] I think you unpacked a new version of TweakScale on a very older version (see the ":NEEDS" thingy on Squad, but not on SquadExpansion?). If memory servers me right, the cargoContainer was moved from a DLC into the main game, and this double confirms what I said. Completely delete the TweakScale directory contents and then unpack the version you want to use. Edited January 29, 2023 by Lisias better phrasing Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted January 30, 2023 Share Posted January 30, 2023 @Lisias Question about docking ports. I'm having a problem getting a couple of SpaceY docking port to connect, they are the 7.5m scaled up to 10m. Does Tweakscale adjust any of the internal parameters, such as the acquireForce, acquireRange, nodetype, etc? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.