Lisias

@Ben J. Kerman, I think you will like to know https://kerbalx.com (yeah, I'm looking for a download from one of your cranes for that mission on the What did you do on KSP Today! ).

It's made of Word of Goo applicants that failed the admission exam and then were hired by KSC!

<rant on> On the good old days, there was a thing called FTP. You could resume the downloads from where you had stopped when interruptions happened. (I still use FTP when possible, by the way). HTTP just wasn't made for this task. (sigh) <rant off> Well, I see you are using Windows (winrar).Open the Explorer, and check if you didn't installed the add'ons on the wrong place. The most usual mistake is installing the add'ons on <KSP>/GameData/GameData/<blah> instead of <KSP>/GameData/<blah>

Don't ask, I'm not sure how this happened neither....

We have two reports that the MM_PATCH_LOOP was entering on a infinite loop, mine and @FreeThinker, so this is unlikely to be a misdiagnosing. And I made my tests using both canonical and my experimental (customised) fork, with identical results, so none of my customisations affected the result. MM 3 also presented the problem, by the way... I made my tests on many KSP versions, clean (only MM installed) and dirty (many random add'ons) installed, and got similar results on every try. On the other hand, this is straightforward enough to be easily reproducible... So this must be something environmental, perhaps Mono itself? I'm presuming you are running Windows, I'm running MacOS. @FreeThinker, what was you running when you detected the problem? In a way or another, all my digging were made with the assumption there's a bug on the code, I didn't considered that it may be good code running on a "bad" runtime... No to mention the stunt not locking forever when using :FINAL.... I will try using AFTER and BEFORE too to see what happens... -- -- -- POST EDIT -- -- -- NOW I'm worried. One of the clean test beds that presented the problem two days ago, on March 25, is passing with flying colours today. I didn't even recompile that LOGSPAM customised DLL I used, it was already there. Weird. Nothing changed from Thursday to today - other than a reboot on the machine. I have no explanation for this. Not even a wild guess... -- -- -- POST POST EDIT -- -- -- Another test bed that was borking Thursday is working now. This one was exactly as I leaved, including the patch. Had not @FreeThinker reported it too, and had not I posted a log excerpt with this line: @name= FNResourceTransfer: IFSResourceTransfer -> FNResourceTransfer (evidence that I didn't messed up the patch with a typo or something), I would be considering I messed this up somehow... Well, this clears Module Manager as a source of the problem. It's something environmental for sure, as the same testbed with the same binaries and patches behave differently today. What remains to understand is how this happened, why and if this could not be happening somewhere else too...

ANNOUNCE Release 2.4.4.6 is available for downloading, with a last minute fix. Lifts the soft ban on KSP 1.11.2. See OP for download links. Your Attention, please: Users of TweakScale, as well as any other add'on that changes the part's cost, need to install KSP-Recall when running on KSP 1.11.x , as it has a bug on recovering the craft's costs on Career mode. This affects every add'on that changes cost in a way or another, it just happens that TweakScale will warn you about. 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) - Right now. The rationale os that the latest KSP-Recall was just release and I want to deploy it gradually to detect any mishaps, so TweakScale will follow that schedule as it's kinda a dependency for Career players.

Sandboxes are OK (Science is called SCIENCE_SANDBOX internally!). The KSP's mishap that screwed us affects a thingy called IPartCostModifier, (a mechanism where Add'Ons tell KSP about how they affect the cost of the part) what it's only really relevant on Career, where refunding for recovered parts are important. On SandBox and Science, Funds are infinite, so the cost of the craft is not important.

In the mean time, KSP Recall 0.0.7.7 is working fine (hopefully at least!) and it's available on GITHUB for the early adopters.

ANNOUNCE KSP-Recall 0.0.7.7 is on the Wild, featuring: An improved Refunding (hopefully) working on Fuel Switches and other add'ons that mangle the resources of a part. Some general small fixes and improvements Known Issues: KSP-Recall 0.0.7.7 changed a bit how Refunding works, and in at least one situation a craft file created with the previous KSP-Recall release was loaded with the wrong prive on the VAB/SPH, leading to wasting funds no launching it. Changing anything on the craft will trigger a recalculation, and the price will be corrected. -- -- -- This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. (Indefinitely delayed due a problem on uploading) SpaceDock (and CKAN users). Right now The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

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

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.

I buzzed the tower!!!

There was this site, Kerbal Comics, on 2012 and 2013. Some are pretty good, a shame the site is down due technical problems nowadays. But there's Archive dot org to the rescue! And, boy, I need to try this one! NOW! -- -- -- -- Mission Accomplished! -- -- post edit -- -- Scrap the last one. THIS is buzzing the tower!!!

Landing a rover on Mün is relativelly easy, you just aim for the Mün and hit it - I rarely miss it nowadays! Still having a rover after the landing is the hard part - misteriously, most of my rovers that touch the Mün vanishes on a cloud of dust...

A 2.5 PAX cabin never existed before, at least on KAX and Firespitter. The FS2CF part is not exactly new, by the way, nether the KAX ones - the "medFuselage" parts were incorporated on KAX on 2.2.1 (2014), while the FS1 Bomber parts entered service on Firespitter on the same year. So I think we have a misunderstanding here - what's not exactly a surprise, as things are somewhat messy nowadays. Since I'm pretty sure you had used a 2.5m crew cabin before, I searched on my personal museum of aviation add'ons looking for crewed 2.5m fuselages, and found one on Airplane Plus and another one in Neist Airline Parts. Give a peek on this thread, there more hints on airplanes add'ons there (including links for the ones I mentioned above):

Yep. And I was wrong when I thought I was wrong! There's a bug on Module Manager. A real nasty bug. I recompiled MM with LOGSPAM, and noticed that with or wihout :FINAL, the patch enters in a infinite loop! The MMPatch.log is HUGE, with an almost endless repetition of what follows: [ModuleManager] INFO: Looping on __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager] [ModuleManager] INFO: Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager] [ModuleManager] INFO: modding values [ModuleManager] INFO: modding values @name= FNResourceTransfer: IFSResourceTransfer -> FNResourceTransfer [ModuleManager] INFO: Applying subnode @MODULE[IFSResourceTransfer] [ModuleManager] INFO: modding values <and now it loops into INFO: Applying update in secula seculorum> The difference is that, somehow, the :FINAL is not locking the thread. I'm guessing that by not using :FINAL, the patch runs on the LEGACY phase and whatever calls the LEGACY phase locks waiting for its finish (what never happens), but the caller don't locks on :FINAL - so when the code detects everything is patched, it moves on and the dead-looped thread is killed by someone else.

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.

I dream on classical cockpits like this on KSP! (Cesna 140)

It's hanging because the :HAS is being satisfied. The patch @DialoMalison about removing resources works because there's a condition in which the :HAS eventually fails. Suppose we have PART { name = Foobar RESOURCE { name = foo } RESOURCE { name = bar } } When this patch: @PART[*]:HAS[@RESOURCE[*]] { !RESOURCE,0 {} MM_PATCH_LOOP {} } Hits it by the fist time, the part have 2 RESOURCEs, satisfying the :HAS and so the patch will be executed once, removing the resource at position 0 and giving us: PART { name = Foobar RESOURCE { name = bar } } This part still satisfies that :HAS, so it will be executed again, giving us so: PART { name = Foobar } Now the :HAS fails, and MM moves on. -- -- -- POST POST EDIT -- -- -- Well this is embarrassing. I ended up creating a problem myself while testing the thing.... (original content on the Spoiler, for the amusement of the reader for the years to come. Well, I redid the tests, the right way this time: First, I tried changing something else that not the @name: PART { name = teste de Module Manager MODULE { name = IFSResourceTransfer xxx = IFSResourceTransfer } MODULE { name = IFSResourceTransfer xxx = IFSResourceTransfer } MODULE { name = IFSResourceTransfer xxx = IFSResourceTransfer } } @PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL { @MODULE[IFSResourceTransfer] { @xxx = FNResourceTransfer } MM_PATCH_LOOP { } } And... well... I reproduced the behaviour @FreeThinker reported. As expected, MM enters into an infinite loop - KSP never goes into Main Menu and the MMPatch.log logs [LOG 13:46:39.974] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager] in secula seculorum. So, no, I was WRONG, no bug on MM was found here. Well, I tried the LOOPless patch again, but changing name instead of xxx: @PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL { @MODULE[IFSResourceTransfer] { @name = FNResourceTransfer } MM_PATCH_LOOP { } } And then I got: UrlConfig { parentUrl = __LOCAL/MMPart.cfg PART { name = teste de Module Manager MODULE { name = FNResourceTransfer xxx = IFSResourceTransfer } MODULE { name = FNResourceTransfer xxx = IFSResourceTransfer } MODULE { name = FNResourceTransfer xxx = IFSResourceTransfer } } } ---- LOG ---- [LOG 13:42:00.515] :AFTER[SQUADEXPANSION] pass [LOG 13:42:00.517] :FINAL pass [LOG 13:42:00.529] Looping on __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Mod ule Manager] [LOG 13:42:00.529] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d e Module Manager] [LOG 13:42:00.539] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d e Module Manager] [LOG 13:42:00.539] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d e Module Manager] [LOG 13:42:00.540] Done patching [LOG 13:42:00.540] Saving Cache [LOG 13:42:01.084] Done! i.e... It worked fine! What I can conclude from my mishaps that an extra { } shoved where it should not played havoc with my previous tests, and this was pretty hard to eye ball. It took me some hours doing something else and going back to this to detect the error. My test suggests that the example above from @FreeThinker should had worked. I think that the original patch has some small mishap (as the { } I did) and this is preventing the module's name to be changed, and then the MM_PATCH_LOOP enters into a infinite loop. One thing that may be affecting the result is the ordering directive, I used :FINAL on my patch that worked. On a second attempt, the very same patch failed when I removed the :FINAL operator: it entered into a infinite loop! So I think I diagnosed the problem!

I'm far from my development computer by now, so I made this kind from heart (I don't have 1.11 on anything else). Check if it solves the issue, I will double check tomorrow. @PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleCargoPart]] { -MODULE[Refunding],* { } -RESOURCE[RefundingForKSP111x],* { } } @PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleAsteroid]] { -MODULE[Refunding],* { } -RESOURCE[RefundingForKSP111x],* { } } @PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleComet]] { -MODULE[Refunding],* { } -RESOURCE[RefundingForKSP111x],* { } } @PART[*]:HAS[@MODULE[Refunding],@MODULE[KerbalEVA]] { -MODULE[Refunding],* { } -RESOURCE[RefundingForKSP111x],* { } } A new Recall release will be issue before the weekend, I will a fix for this on it (together the Fuel Switches one). --- POST EDIT --- https://getyarn.io/yarn-clip/82b6238b-1556-4398-a10b-5db598900e02 -- -- -- POST EDIT -- - -- @Hohmannson, you ended up finding a bug... I forgot to correctly implement the deactivation code on Refunding. The present code will prevent it from running until he vessel is copied, saved or recovered - situations where I forgot to check if the thing is disabled and prevent the Synchronous Update... Well, it will be fixed on the next release.

You see, the Common Center of Mass on a twin star system big enough should be a pretty cozy place for a O'Neill Cillinder or other similar huge space station...

Listening compulsively this one today:

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. 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!

For the sake of completute, I redid some basic tests on my side on a cleaner KSP 1.11.2 . The file is here. I also confirmed a M.O.: Load the craft on editor Launch it into the LaunchPad Cheat it into orbit Stage The panels stages, the RCSs's trusters vanish Revert to Launch Cheat it into orbit again Stage NOW the RCSs' trusters present the misbehaviour The uncaught exception hypothesis is still valid, but now I think we have an initialisation error too on the mess. Two cascading problens.