firethorn6 Posted March 2, 2021 Share Posted March 2, 2021 4 hours ago, Lisias said: Fact: someone squashed the whole IPartCostModifier mechanism, by using the cost from the part's prefab while recovering the craft. Ouch. I mean, vanilla KSP is just so limited, I think. Plus, things like tweakscale allows me to keep the parts count down, to help keep the Kraken from visiting. I'd consider it a core add-on. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 3, 2021 Author Share Posted March 3, 2021 (edited) NOTAM Datum perficiemus munus The new and nasty problem on KSP 1.11.x described on this post now have a functional (but not yet confirmed to be safe) workaround. I managed to counter-attack the current KSP's faulty calculation, but not without a cost: I had to heavily mangle the part's resources in order to brute force my way on the problem. Some parts will have the Recovered Funds mangled in order to force the desired result. THiS IS NOT THE FINAL SOLUTION, I still have some small tricks to try that may improve a bit the final results - but the mechanism was stablished and it works as intended. The solution will be available on KSP Recall - and it will work for every affected add'on, and not only for TweakScale. https://forum.kerbalspaceprogram.com/index.php?/topic/192048-ksp-18-ksp-recall-0061-2021-0209/ -- -- POST EDIT -- -- The issue was transfered to KSP-Recall's issue tracker. new Link: https://github.com/net-lisias-ksp/KSP-Recall/issues/12 -- -- POST POST EDIT -- -- The kludge workaround was published for beta testing! Anyone willing to risk his/her SAS FOR SCIENCE is more than welcome to test the thing. (please use it only on disposable savegames, ok?). -- -- POST POST POST EDIT -- -- KSP-Recall 0.0.7.3 RELEASE is on the wild. This one was properly tested, some fixes applied, and it's good to be used. Happy Refundinds! Edited March 5, 2021 by Lisias KSP Recall 0.0.7.3 in on the wild! Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted March 5, 2021 Share Posted March 5, 2021 (edited) @Lisias -- Getting a bug I am able to reproduce reliably on clean KSP. TweakScale 2.4.4.5 (with a couple Companions, but I don't think they're relevant). Happens w/ B9 Part Switch recompile that you provided to me AND the public version. TS 2.4.4.5 hotfix does not change anything. Two separate symptoms, I think, but I am only able to reproduce #1 reliably. SYMPTOM 1: Install only TS, B9 Part Switch, *AND* a mod such as CryoTanks that patches fuel switch options to many tanks. Place a pod and a fuel tank (one that has switcher options); scale up the fuel tank, noting its new fuel capacity. Alt-click to copy the scaled-up fuel tank, place the copy; the copy will have the *base* fuel capacity of the part, not the scaled-up capacity. No exceptions in ksp.log, at least... Symptom 2, which I can't reproduce and may or may not even be related, involves part copying as well: copying a scaled up fuel tank (for instance) will result in a visually larger part, but attach nodes will remain at original positions (original scale). Here is an example of the MM Config Cache for one affected part: Spoiler UrlConfig { parentUrl = Squad/Parts/FuelTank/Size1_Tanks/fuelTankT400.cfg PART { name = fuelTank module = Part author = RoverDude rescaleFactor = 1.0 node_stack_top = 0.0, 0.981725, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -0.9125, 0.0, 0.0, -1.0, 0.0 node_attach = 0.625, 0.0, 0.0, 1.0, 0.0, 0.0, 1 TechRequired = advRocketry entryCost = 1600 cost = 500 category = FuelTank subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Jebediah Kerman's Junkyard and Spacecraft Parts Co description = The FL series was received as a substantial upgrade over previous fuel containers used in the Space Program, generally due to its ability to keep the fuel unexploded more often than not. Fuel tanks are useless if there isn't a Liquid Engine attached under it. They can also be stacked with other fuel tanks to increase the amount of fuel for the engine below. attachRules = 1,1,1,1,0 mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2000 bulkheadProfiles = size1, srf tags = fueltank ?lfo liquid oxidizer propellant rocket LF = 144 OX = 39.6 totalCap = 400 massOffset = -0.25 costOffset = -183.6 MODEL { model = Squad/Parts/FuelTank/Size1_Tanks/Size1Tank_03 } MODULE { name = ModulePartVariants primaryColor = #000000 secondaryColor = #000000 baseDisplayName = Dark baseThemeName = Dark useMultipleDragCubes = false VARIANT { name = BlackAndWhite displayName = Black and White themeName = BlackAndWhite primaryColor = #ffffff secondaryColor = #000000 TEXTURE { mainTextureURL = Squad/Parts/FuelTank/Size1_Tanks/125Tanks_BW _BumpMap = Squad/Parts/FuelTank/Size1_Tanks/125Tanks_N shader = KSP/Bumped Specular } } VARIANT { name = White displayName = White themeName = White primaryColor = #ffffff secondaryColor = #ffffff TEXTURE { mainTextureURL = Squad/Parts/FuelTank/Size1_Tanks/125Tanks_W shader = KSP/Specular } } VARIANT { name = GrayAndOrange displayName = Gray and Orange themeName = GrayAndOrange primaryColor = #4c4f47 secondaryColor = #f49841 TEXTURE { mainTextureURL = Squad/Parts/FuelTank/Size1_Tanks/125Tanks_O shader = KSP/Specular } } } MODULE { name = TweakScale type = stack defaultScale = 1.25 } MODULE { name = ModuleB9PartSwitch moduleID = fuelSwitch switcherDescription = Tank Type baseVolume = 400 SUBTYPE { name = LF/O title = LF/Ox tankType = LFOX addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = LH2/O title = LH2/Ox tankType = LH2O addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = LH2 title = LH2 tankType = LH2 addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = Methane title = LCH4 tankType = LM addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = Methalox title = LCH4/Ox tankType = LMOx addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = Oxidizer title = Ox tankType = OX addedMass = -0.25 addedCost = -183.6 } SUBTYPE { name = LiquidFuel title = LF tankType = LF addedMass = -0.25 addedCost = -183.6 } } MODULE { name = ModuleCryoTank CoolingEnabled = False BOILOFFCONFIG { FuelName = LqdHydrogen BoiloffRate = 0.05 CoolingCost = 0.09 } BOILOFFCONFIG { FuelName = LqdMethane BoiloffRate = 0.005 CoolingCost = 0.045 } } MODULE { name = ModuleB9PartInfo } } } On the save where I noticed the issue, I had written a custom patch to remove ModuleCryoTank from all parts; the issue with TS is present regardless of whether ModuleCryoTank is there or not (issue happens on that save AND on a clean save with no custom patches or anything else in GameData). Edited March 5, 2021 by AccidentalDisassembly Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 6, 2021 Author Share Posted March 6, 2021 (edited) 19 hours ago, AccidentalDisassembly said: SYMPTOM 1: Install only TS, B9 Part Switch, *AND* a mod such as CryoTanks that patches fuel switch options to many tanks. Place a pod and a fuel tank (one that has switcher options); scale up the fuel tank, noting its new fuel capacity. Alt-click to copy the scaled-up fuel tank, place the copy; the copy will have the *base* fuel capacity of the part, not the scaled-up capacity. No exceptions in ksp.log, at least... Well, as was said by that famous london personality from the 1888 Jack the Ripper... "Let's do it by parts". I'm assuming this is on KSP 1.11.x, so I will give this a try on a clean + TweakScale 1.11.x and 1.10.1 to see what I get. I remember fixing this in the past, by the way.... Perhaps I should reactivate KSP-Recall's Resourcefull on KSP 1.11.x too? Hope not.... 19 hours ago, AccidentalDisassembly said: Symptom 2, which I can't reproduce and may or may not even be related, involves part copying as well: copying a scaled up fuel tank (for instance) will result in a visually larger part, but attach nodes will remain at original positions (original scale). Sounds like someone borking the nodes resizing. This one I fixed for sure on TweakScale - one does not forget this kind of mistake... --- --- --- -- -- Well, lets try to reproduce these symptoms on my rig: (firing up "clean + TS" KSP 1.11.1) * Symptom 1: worked fine for me, could not reproduce * Sympton 2: worked fine for me, could not reproduce Oukey, TS alone on KSP 1.11.x does not triggers any of the 2 symptons. No exactly a surprise, as you stated that the fuel tank need to have switch options (what kinda hints about the problem - besides not hinting about who is causing the problem yet). I will skip clean + ts on 1.10.x tests so. (firing up "CryoTanks + b9ts.mine + CommunityResourcePack + DynamicBatteryStorage + TS" KSP 1.10.1) * Symptom 1: confirmed. * Symptom 2: confirmed. Oukey, this is not KSP related. Good. Looking on how things happens (and now that I know a bit better B9PS' guts), I know the source of the problem - both TS and B9TS are working disregarding each other: on both cases, the B9TS's OnCopy and the Switch Handling code are overwriting whatever the TS had done on the part (as it's copying fresh node and resources data from the prefab the exact same way ModulePartVariant does). I can't say it's a bug on any of them, because B9TS doesn't care about TS, and TS aims to support only Stock and DLC parts leaving to the companions the responsibility to work with third-parties. But yet, it's a problem on the userland that must be tackled down. I will implement B9PS on a new Companion. The task for it is the Companion Issue #17. (I have another similar request for Fuel Switches, I think it's time to reschedule things). Well, I need to reschedule some things (I was working on another Companion before the need for the KSP-Recall's Refunding stunt), but this will be worked out in the near future for sure. Until there, I found that configuring first the fuel type for the tank and then scaling will work around the Symptom 1. Unfortunately, it didn't did the trick for Symptom 2, and I consider this a flaw on B9PS - why squashing prefab data back on the part while handling OnCopy? In a way or another, the Companion will solve both cases. Worst case, I do what I did while implementing support for FS's FSBuoyancy - I will intercept the UI and coordinate B9TS and TS from the companion. Stay tunned. Edited March 6, 2021 by Lisias tyops, as usulla... Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted March 6, 2021 Share Posted March 6, 2021 1 minute ago, Lisias said: Well, as was said by that famous london personality from the 1888 Jack the Ripper... "Let's do it by parts". I'm assuming this is on KSP 1.11.x, so I will give this a try on a clean + TweakScale 1.11.x and 1.10.1 to see what I get. I remember fixing this in the past, by the way.... Perhaps I should reactivate KSP-Recall's Resourcefull on KSP 1.11.x too? Hope not.... Sounds like someone borking the nodes resizing. This one I fixed for sure on TweakScale - one does not forget this kind of mistake... --- --- --- -- -- Well, lets try to reproduce these symptoms on my rig: (firing up "clean + TS" KSP 1.11.1) * Symptom 1: worked fine for me, could not reproduce * Sympton 2: worked fine for me, could not reproduce Oukey, TS alone on KSP 1.11.x does not triggers any of the 2 symptons. No exactly a surprise, as you stated that the fuel tank need to have switch options (what kinda hints about the problem - besides not hinting about who is causing the problem yet). I will skip clean + ts on 1.10.x tests so. (firing up "CryoTanks + b9ts.mine + CommunityResourcePack + DynamicBatteryStorage + TS" KSP 1.10.1) * Symptom 1: confirmed. * Symptom 2: confirmed. Oukey, this is not KSP related. Good. Looking on how things happens (and know that I know a bit better B9PS' guts), I know the source of the problem - both TS and B9TS are working disregarding each other: on both cases, the B9TS's OnCopy and the Switch Handling code are overwriting whatever the TS had done on the part (as it's copying fresh node and resources data from the prefab the exact same way ModulePartVariant does). I can't say it's a bug on any of them, because B9TS don't care about TS, and TS aims to support only Stock and DLC parts leaving to the companions the responsibility to work with third-parties. But yet, it's a problem on the userland that must be tackled down. I will implement B9PS on a new Companion. The task for it is the Companion Issue #17. (I have another similar request for Fuel Switches, I think it's time to reschedule things). Well, I need to reschedule some things (I was working on another Companion before the need for the KSP-Recall's Refunding stunt), but this will be worked out in the near future for sure. Until there, I found that configuring first the fuel type for the tank and then scaling will work around the Symptom 1. Unfortunately, it didn't did the trick for Symptom 2, and I consider this a flaw on B9PS - why squashing prefab data back on the part while handling OnCopy? In a way or another, the Companion will solve both cases. Worst case, I do what I did while implementing support for FS's FSBuoyancy - I will intercept the UI and coordinate B9TS and TS from the companion. Stay tunned. Awesome, thanks! Yes, I am currently working around by doing just as you mention - first place, then scale. Glad to know I am not insane. I saw that blowfish (? I think?) accepted your PR for the other B9PS fix, maybe s/he can somehow address this in concert with you...? Either way, thanks! Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 6, 2021 Author Share Posted March 6, 2021 1 minute ago, AccidentalDisassembly said: I saw that blowfish (? I think?) accepted your PR for the other B9PS fix, maybe s/he can somehow address this in concert with you...? Either way, thanks! First I need to understand why things are happening this way. KSP nowadays have this terrible habit of mangling living parts, and if B9FS is squashing prefab data on the part in order to overcome a previous squash from KSP itself, there's no fix possible on the B9FS side - and so, all I can do is to reapply TS from scratch every time a part is "OnCopied". What I will need to do every time B9FS switches something (as I had to do with ModulePartVariants - there're still some loose ends, by way), so this is more an (additional) annoyance than a problem... Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted March 19, 2021 Share Posted March 19, 2021 Something a bit funny happening with TweakScale (latest), KSP 1.11.2, surface attached parts, ALT-copying, and offsets: copying the satellite part (not as a subassembly, just ALT-copying from the decoupler) causes the solar panels to be further and further offset from the surface-attached robotruss parts. Log as well, but didn't see anything on quick glance: https://www.dropbox.com/s/p96anzx1nsz466g/ksplog_stagerecoveryKKjnsq.log?dl=0 Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 19, 2021 Author Share Posted March 19, 2021 3 hours ago, AccidentalDisassembly said: Something a bit funny happening with TweakScale (latest), KSP 1.11.2, surface attached parts, ALT-copying, and offsets: copying the satellite part (not as a subassembly, just ALT-copying from the decoupler) causes the solar panels to be further and further offset from the surface-attached robotruss parts. I made this gizmo tested it on 1.7.3, 1.10.1, 1.11.1 and 1.11.2: And ALT_Copying worked as expected on all of them. Well, not an obvious bug on TweakScale as it appears. But since you are using Infernal Robotics, I'm sufficiently confident that the problem may lay on the Infernal Robotics itself. You see, IR have to cope with some of the problems TweakScale had to cope too, as it also resizes parts and, so, need to replace attachments nodes - and if the parent part borks on resizing its nodes, TweakScale will reposition the nodes wrongly too - Garbage In, Garbage Out. It's less than optimal, but had you considered to use a scaled down Tube? Two T-12, two cubic truss (as I could not attach the solar panel directly on the tube) and you are set. Spoiler Cheers! Quote Link to comment Share on other sites More sharing options...
AccidentalDisassembly Posted March 19, 2021 Share Posted March 19, 2021 6 hours ago, Lisias said: I made this gizmo tested it on 1.7.3, 1.10.1, 1.11.1 and 1.11.2: And ALT_Copying worked as expected on all of them. Well, not an obvious bug on TweakScale as it appears. But since you are using Infernal Robotics, I'm sufficiently confident that the problem may lay on the Infernal Robotics itself. You see, IR have to cope with some of the problems TweakScale had to cope too, as it also resizes parts and, so, need to replace attachments nodes - and if the parent part borks on resizing its nodes, TweakScale will reposition the nodes wrongly too - Garbage In, Garbage Out. It's less than optimal, but had you considered to use a scaled down Tube? Two T-12, two cubic truss (as I could not attach the solar panel directly on the tube) and you are set. Reveal hidden contents Cheers! Ah! I had completely forgotten that the IR parts aren't actually using TweakScale anymore (ModuleIRVariant instead, looks like)! My brain is living a year or two in the past it seems. Will do that, thanks! Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 19, 2021 Author Share Posted March 19, 2021 1 hour ago, AccidentalDisassembly said: Ah! I had completely forgotten that the IR parts aren't actually using TweakScale anymore (ModuleIRVariant instead, looks like)! My brain is living a year or two in the past it seems. Will do that, thanks! As a matter of fact, you just reminded me that now I can write a Companion for IR, doing things my way... Quote Link to comment Share on other sites More sharing options...
kcs123 Posted March 19, 2021 Share Posted March 19, 2021 1 hour ago, AccidentalDisassembly said: Ah! I had completely forgotten that the IR parts aren't actually using TweakScale anymore It does use TS if it is installed. It does have additional configs for upsaled/downscaled parts if you don't have TS installed. That being said, I didn't checked if those additional config files were published or not (I have cooperated with Zodiusinfuser when he worked on it). Quote Link to comment Share on other sites More sharing options...
Krazy1 Posted March 20, 2021 Share Posted March 20, 2021 On 3/1/2021 at 12:51 PM, Lisias said: This is nasty, sir. Add'On authors can't fight the Dev Team. But the players can! Just Tweak everything huge, single stage to everywhere and never come back to Kerbin. Don't let them rob you. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 20, 2021 Author Share Posted March 20, 2021 17 hours ago, Krazy1 said: But the players can! Just Tweak everything huge, single stage to everywhere and never come back to Kerbin. Don't let them rob you. JNSQ? Humm... Nice idea! I will give it a try! Quote Link to comment Share on other sites More sharing options...
Krazy1 Posted March 21, 2021 Share Posted March 21, 2021 2 hours ago, Lisias said: JNSQ? Humm... Nice idea! I will give it a try! It might be an interesting challenge. No science could be returned only transmitted, no kerbal promotions without a lab... couldn't finish a lot of contracts. Maybe just in Science mode. Or maybe only Kerbals can be recovered. Quote Link to comment Share on other sites More sharing options...
shacvet Posted March 22, 2021 Share Posted March 22, 2021 Receiving FATAL error with KSP 1.11.2.3077 with Breaking Ground and Making History. I have many mods that require this. Please advise? Quote Link to comment Share on other sites More sharing options...
bcqJC Posted March 22, 2021 Share Posted March 22, 2021 I'm on 1.11.2 and am using the most recent stable release of TweakScale. I'm aware that TS is not supported in 1.11.x. For those who are ok with workarounds... Below are the issues I've encountered and how I've worked around them. Scaled part reverting to defaults when copied. Workaround. With the part still attached, I rescale it 1 step down, then scale it back up to my desired scale. Somehow, this forces TS to re-do its magic and I end up with the target values for that scale, i.e. recalculated ISP, thrust, etc. Offsetted parts reverting to the attachment node when reloading a craft. For example... Scale up a part, partA; then attach another part, partB, to one of the attachment nodes. Then offset partB and attach another part, partC, to partB. When you reload the craft, you'll see that partB is no longer offset from the attachment nodes. Of course, anything attached to partB, partC in this case, has also moved. Workaround. Leave partB alone since it insists on going back to the attachment node. Just offset partC instead. This is where you'll learn the virtues of using the tiny Cubic Octagonal Strut. It's small enough to be practically invisible. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 23, 2021 Author Share Posted March 23, 2021 (edited) 3 hours ago, shacvet said: Receiving FATAL error with KSP 1.11.2.3077 with Breaking Ground and Making History. I have many mods that require this. Please advise? Ouch.. Something is borked on the patches - TS is not "officially" supported yet because I didn't had enough time to deeply test it on 1.11.2, but until the moment no evident bugs were detected - au contraire, the norm is 3rd party add'ons borking on KSP 1.11.2, and then TweakScale borking together in solidarity (Garbage In, Garbage Out - if the original part borks, TweakScale borks on it too when trying to scale it). But yet, bug reports from users are a huge help for me on this task. Please send me your KSP.log and ModuleManager.ConfigCache. By inspecting these two files, I'm able to identify the cause of the problem 95% of the time. 1 hour ago, bcqJC said: I'm on 1.11.2 and am using the most recent stable release of TweakScale. I'm aware that TS is not supported in 1.11.x. For those who are ok with workarounds... Below are the issues I've encountered and how I've worked around them. Scaled part reverting to defaults when copied. Workaround. With the part still attached, I rescale it 1 step down, then scale it back up to my desired scale. Somehow, this forces TS to re-do its magic and I end up with the target values for that scale, i.e. recalculated ISP, thrust, etc. Offsetted parts reverting to the attachment node when reloading a craft. For example... Scale up a part, partA; then attach another part, partB, to one of the attachment nodes. Then offset partB and attach another part, partC, to partB. When you reload the craft, you'll see that partB is no longer offset from the attachment nodes. Of course, anything attached to partB, partC in this case, has also moved. Workaround. Leave partB alone since it insists on going back to the attachment node. Just offset partC instead. This is where you'll learn the virtues of using the tiny Cubic Octagonal Strut. It's small enough to be practically invisible. Thank you very much for your report! I will investigate it ASAP. (hack hack, hack - slice, slice, slcie) Humm... We have a problem, I didn't reproduced the problem on my test bed (KSP 1.11.2 + DLCs + TS latest only). This means that we have a bad interaction with a 3rd party add'on. Full report: https://github.com/net-lisias-ksp/TweakScale/issues/92 I will need your full KSP.log, ModuleManager.ConfigCache and probably the craft files you created that reproduce the problem (some bad interactions happens after spawning or saving the craft, or only when some specific parts are involved - I chase my tail on one of these problems once, I dismissed the user report because I was "lucky" and tested only with the "right" parts). -- -- -- POST EDIT -- -- -- Cheers! Edited March 23, 2021 by Lisias Cheers! Quote Link to comment Share on other sites More sharing options...
bcqJC Posted March 23, 2021 Share Posted March 23, 2021 Lisias, I have attached the logs to issue 92 above. As I've said, I have a workaround for it so it is not a biggie for me. Thanks! Quote Link to comment Share on other sites More sharing options...
ElonsMusk Posted March 24, 2021 Share Posted March 24, 2021 I just want to say that I am having a grand old time with Tweakscale. There was that brief era where there were too many kinks to get too complicated. I only have *five* unsupported parts in 1.11 with 21k MM patches applied. I haven't run into a single problem related to scaling. Keep up the great work all of ya!! Quote Link to comment Share on other sites More sharing options...
hendrack Posted March 25, 2021 Share Posted March 25, 2021 (edited) I have some 1.11.2 debugging for you, seems related to above: VAB and it's UI seem to have an issue with a tweakscaled reaction wheel. Have been running on 1.11.1 and encountered no issues with TS, but after updating to 1.11.2, when I load this craft and want to edit it, removing parts, adding parts, changing root borks the UI, I can't click aside loading or exiting the VAB. I have the feeling TS corrups the craft file or someting, I have attached the log file, craft file, and a short video there: https://disk.yandex.com/d/t3cEZ8I_A3J8mA?w=1 When I manage to remove the offending part from the craft everything is normal again. First I thought this is some third-party mod click-through issue but no, I removed most VAB related mods except the essentials. Edited March 25, 2021 by hendrack Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 25, 2021 Author Share Posted March 25, 2021 43 minutes ago, hendrack said: When I manage to remove the offending part from the craft everything is normal again. First I thought this is some third-party mod click-through issue but no, I removed most VAB related mods except the essentials. Yep. Something is throwing an Exception inside a critical region on KSP, and then whatever was being done, it's halted and left undone. So, if you are trying to attach a part and an exception happens, then anything that was going to be executed later is not, and we have these weird situations you are seeing. Inspecting the log it appears to be KSP-Recall's Refunding - something is messing with the fake resource it uses to keep track of the real costs. [EXC 10:46:29.263] NullReferenceException: Object reference not set to an instance of an object KSP_Recall.Refunds.Refunding.UpdateResource () (at <3acfe85e1f3e4fd9ac5a1820c73e672d>:0) KSP_Recall.Refunds.Refunding.SynchronousFullUpdate () (at <3acfe85e1f3e4fd9ac5a1820c73e672d>:0) KSP_Recall.Refunds.Refunding.OnSave (ConfigNode node) (at <3acfe85e1f3e4fd9ac5a1820c73e672d>:0) PartModule.Save (ConfigNode node) (at <06f13185617646e5bc801baeab53ab75>:0) ShipConstruct.SaveShip () (at <06f13185617646e5bc801baeab53ab75>:0) ShipConstruction.CreateBackup (ShipConstruct ship) (at <06f13185617646e5bc801baeab53ab75>:0) EditorLogic.SetBackup () (at <06f13185617646e5bc801baeab53ab75>:0) EditorLogic.<SetupFSM>b__190_21 () (at <06f13185617646e5bc801baeab53ab75>:0) KerbalFSM.RunEvent (KFSMEvent evt) (at <06f13185617646e5bc801baeab53ab75>:0) KerbalFSM.updateFSM (KFSMUpdateMode mode) (at <06f13185617646e5bc801baeab53ab75>:0) KerbalFSM.UpdateFSM () (at <06f13185617646e5bc801baeab53ab75>:0) EditorLogic.Update () (at <06f13185617646e5bc801baeab53ab75>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) KSPe.Util.Log.UnityLogDecorator:UnityEngine.ILogHandler.LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) I'm going to inspect it by night. In the mean time, you may want to uninstall KSP-Recall to keep playing - you probably will need to cheat the money back on recovering the craft in the mean time. Quote Link to comment Share on other sites More sharing options...
rextable Posted March 27, 2021 Share Posted March 27, 2021 Hey Lisias Just a quick question: Can you clarify whether merely having Tweakscale installed (but not using it) in KSP 1.11.2 is a threat to our savegames or does it only become a problem when utilised? If the latter is not the case, can we at least get away with using the current version (2.4.4.5) of Tweakscale on very simple stock parts - eg structural parts - without worry of savegame corruption in KSP 1.11.2? Spanx x Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 27, 2021 Author Share Posted March 27, 2021 1 minute ago, rextable said: Hey Lisias Just a quick question: Can you clarify whether merely having Tweakscale installed (but not using it) in KSP 1.11.2 is a threat to our savegames or does it only become a problem when utilised? If the latter is not the case, can we at least get away with using the current version (2.4.4.5) of Tweakscale on very simple stock parts - eg structural parts - without worry of savegame corruption in KSP 1.11.2? No. To this date, I had no problems on TweakScale running on KSP 1.11.x other that the one KSP-Recall aims to fix on recovering funds on Career Mode (that affects everybody, by the way). TweakScale should had been updated already, but my works on KSP-Recall delayed it a couple weeks. I'm finishing a new update for Recall today, then I will apply a new TweakScale release lifting the 1.11.x ban. Quote Link to comment Share on other sites More sharing options...
rextable Posted March 27, 2021 Share Posted March 27, 2021 3 minutes ago, Lisias said: No. To this date, I had no problems on TweakScale running on KSP 1.11.x other that the one KSP-Recall aims to fix on recovering funds on Career Mode (that affects everybody, by the way). TweakScale should had been updated already, but my works on KSP-Recall delayed it a couple weeks. I'm finishing a new update for Recall today, then I will apply a new TweakScale release lifting the 1.11.x ban. Groovy So long story short: don't install Tweakscale on KSP 1.11.2 until you (Lisias) have updated both KSP-Recall AND Tweakscale. Am I interpreting you correctly? Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 27, 2021 Author Share Posted March 27, 2021 (edited) 1 hour ago, rextable said: Groovy So long story short: don't install Tweakscale on KSP 1.11.2 until you (Lisias) have updated both KSP-Recall AND Tweakscale. Am I interpreting you correctly? As long you don't play Career, there's no (detected until this moment) problems between TweakScale and KSP 1.11.x - some third parties add'ons can bork on KSP 1.11.x and then bork TweakScale in a chain reaction, but there's little one can do about but to be around to give support as this happens. TweakScale 2.4.4.6 will be essentially 2.4.4.5 with the warning removed until 1.12.0. KSP.Recall 0.0.7.7 was just published on GitHub, by the way, I'm going to announce if on the Recall's thread right now. But, again, this is only important if you play Career and use any Add'On that changes a part cost, as TweakScale and a huge amount of other ones (fuel switches, depreciation, damages, etc - TweakScale is only one of the affected add'ons!) Edited March 27, 2021 by Lisias Emphasis. TweakScale is not the only one. 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.