Lisias

NOTAM Cooked a way to allow correctly recovering of funds when the recovering is made from Space Center or Tracking Station (or anywhere else). The current fix should work with FMRS and Stage Recovery too (still to be tested). My problem now is to overcome the limitation on ModuleCargoPart , that doesn't allows parts with resources to be Stackable. The current workaround is terribly naive, I just don't Refund on them. The second less naive solution would be to avoid patching Refund on parts with ModuleCargoPart and that also have no resources, but that would not improve the situation too much. The ideal solution I'm pursuing now is to try to detect when the part is stored or in the imminence of being stored and then remove the Refunding Resource from it, and applying the Resource back when the part is removed from storage: the metadata is stored on the Refunding Module and it's persisted on saving the craft, so we can get rid of the Refunding Resource at any time, and then apply it back when needed. This will not solve all use cases (as recovering stacked parts with IPartCostModifier modules ), but it will allow these parts to be correctly refunded when recovered in use - unless, of course, I manage to trick the code to inject a Resource on a stored part without screwing up KSP's guts

Check the origin of the tarball. You are absolutely sure the binaries weren't tampered? As an practical example, I backup my clean installations using 7zip, and it happens it don't preserve the UNIX file attributes, so the startup binary is packed without the X attribute, and so when unpacking the thingy I'm unable to run the KSP.app until I chmod +x <root>/KSP.app/Contents/MacOS/KSP . So there's a chance that your package is tempered somehow. If you absolutely trust the source of the package, you may had run on the same problem this guy below had, and the solution should be the same on the bottom of the page.

Humm... I missed the Space Center recovering Use Case. It will probably cover the FMRS Use Case too... Thanks for the report, I will try to get it fixed by the WeekEnd! -- -- POST EDIT -- -- Yep... The Refunding doesn't works when the vessel is on Rails. Fix appears to be simple, trying it today. Wish me luck! -- -- POST POST EDIT -- -- Incredible - I was typing the last post edit when I got a call with an emergency on a client. Incredible! -- -- POST POST POST EDIT -- -- Thats the thing: the GameEvents.OnVesselRecoveryRequested event is only fired when the craft being recovered has the focus. When you recover it from the Space Center, from the Tracking Stating and from FMRS, that Event is not called - so my PartModule failed on recalculate the costs. So my clever trick to prevent some spamming had failed, and I really need to spam the Refunding Resource on evert part that appears to need it, as there's no real standard way to detect when the part is being recovered. Fortunately, until the moment every time the craft is in the imminence of being recovered, the Save callback is summoned. So I have a pretty & cozy place to shove the Refunding process without having to worry about every single possible way a craft is recovered on the game. What reverted the solution to my initial approach, recalculating this thing everywhere instead of trying to being smart and only doing it when the craft was being recovered. As I said before, I'm not the only one modding around here, and one size does not fits all. TL;DR: The overall solution is being reworked to be less "smart". I'm currently tackling down some small glitches (re)introduced by the change, then I will test the thing on FMRS to see what happens. There's a good change to have a new Release before the WeekEnd (famous last words...) -- -- -- POST POST POST POST EDIT -- -- -- Yeah. "Lucky". (sigh) That "Save" I detected was being triggered by FMRS. Without it, recovering vessels from the Space Center or Tracking Station does not triggers a PartModule.Save. So I kinda back to square one on this. Well, there're some more options to explore....

"At least the crater is in the right place!" Musk, Elon.

B9 Stock Parts (and B9PS), by example. If I understood correctly, this add'on applies patches on already patched parts. Since you complained about the PPD_10 being reset to Stock, I think it's more or less obvious that it was not patched, and since B9 Stock Parts are the add'on that apply B9PS to Stock Parts, perhaps its absence is the cause of the error, and not a bug on KSP 1.11 or this (WiP) add'on.

Did you installed all the dependencies? Some patches are only applied when the dependencies are found...

Ah, yes! You mean Kaboom!

Nice wallpaper! And I finally understood what's happening... You downloaded the wrong file (the -master thing means you download a dump of the GIT repository, not the actual release!) So, let's try to clear out the misunderstandings. you want to download Kerbal Foundries, the one maintained on this thread. You want to download the latest release, 2.4.8.16, from this page. Being specific, you want this file. (KerbalFoundries-2.4.8.18.zip) You DON'T WANT the Source Code.zip neither Source Code.tar.gz. You are facing some problems on downloading things Since the Release zip should be somewhat smaller than the source tar balls, hopefully you will be able to download the correct file. But it is still ~54.3Mb. So, try to download it using the "you want this file" link above, and if you don't manage to do it, I shove this file on the FTP of my server and I teach you how to handle FileZilla (an easy to use FTP cliente) to download it. FTP allows resuming files, so if anything goes wrong you can resume from where you were, instead of downloading it from the start again.

It's unlikely the S.A.V.E, I'm using it for a long time, mangled with it a lot, broke it in uncountable ways toying with the code - but never got this problem. Unfortunately, your KSP.log ends abruptly on the middle of the loading process. The log you provided don't even reaches the Main Menu! [LOG 01:34:58.290] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_1p5/EnginePlate1p5' [LOG 01:34:58.362] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_1p5/EnginePlate1p5' has no database record. Creating. So it can't be used for diagnosing. In time, you are running 1.8.1. Besides not that common, it's possible the the current release could work on the latest KSP, but present some glitches on older ones. By last, but not by least, you have a awful amount of Exceptions on your parts, as this one: [LOG 01:29:40.505] PartLoader: Compiling Part 'B9_Aerospace/Parts/Aero_HL_Body/1m-Universal/B9_Aero_HL_Body_Structure_1m_U' [ERR 01:29:40.508] PartLoader: Encountered exception during compilation. System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber (System.String str, System.Globalization.NumberStyles options, System.Number+NumberBuffer& number, System.Globalization.Numbe rFormatInfo info, System.Boolean parseDecimal) [0x00057] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.Number.ParseInt32 (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00013] in <ad04dee02e7e 4a85a1299c7ee81c79f6>:0 at System.Int32.Parse (System.String s) [0x00007] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at PartLoader.ParsePart (UrlDir+UrlConfig urlConfig, ConfigNode node) [0x001d9] in <9d71e4043e394d78a6cf9193ad011698>:0 at PartLoader+<CompileParts>d__56.MoveNext () [0x005cd] in <9d71e4043e394d78a6cf9193ad011698>:0 Besides not common, such problems may cause borks on 3rd parties add'ons that don't know how to handle them. Perhaps S.A.V.E. could be one of these. I suggest you to: Duplicate your whole KSP installment, so we can mangle it without risking your savegames Remove B9_Aerospace Check if the problem persists. You can also try to install an older version of S.A.V.E., install the 1.8.0-3165 release from SpaceDock and see what happens. Remember, do it on the copy you made - so if anythings goes south (and sometimes they do), nothing is lost.

Impossible Innovations has part that does that - you attach a device called "Poofing Part" on the part you want to.. "Poof" and that's it.

Awesome!

You will have one Refund Module for each (supported) part. Refund works on the part it's installed, and only on it - so any problem we may get on it will be easily solved on the field by a MM patch (or by you manually deactivating it on the Editor). That was a problem on previous Recall releases because Stackable parts can't have "State" (ie, something that could make a part different from other of the same type, as fuel: one part may be empty, other may be full), and I didn't realised that until someone reported the problem. I solved this by preventing Refund to be patched on parts that have ModuleCargoPart , the stock module that stackable parts should have. This was fixed on 0.0.7.6, IIRC. (I just fired up 1.11.2 with Recall 0.0.7.6 and the stackable parts are being stacked allright) In time.... -- -- -- METAR -- -- -- Curseforge will not be updated for some time, as I'm facing problems on uploading the release - the site refuses my zip complaining about a "invalid JSON". I opened a ticked, but until this is solved by Overworlf, KSP-Recall will not be updated on Curseforge. Curseforge problem fixed.

Yep. Once you install a Add'On (any add'on) and create crafts, onde you desinstall the add'on (any add'on), you will get exactly this log spam. This happens with all add'ons on KSP, being KSP-Recall just one of them. No need to manually remove them. Loading them and saving them will do the same, including on running savegames. As with every other add'on on KSP, by the way. KSP-Recall is not different from anything else. To tell you the true, you are breaking them. KSP-Recall only install the Modules you need on your installment, so by not using them you are getting back the problems you had before installing it. Be sure to do not use any add'on that changes the cost of a part while playing Career.

What? Buzzing the tower? Scrap that... THIS is buzzing the tower!!! Additional screenshots (they survived the stunt!!!), craft file and quicksave on my site. Fly (un)safe!!!

Guys, CodePlex will shutdown on July 1st 2021, so anything being hosted there will just vanish from the Web. I made mirrors for KerbalEdit and KerbalData on: https://github.com/net-lisias-ksph/kerbaledit https://github.com/net-lisias-ksph/kerbaldata Including some page dumps and license data to keep things tight on the legal side. If anyone knows of anything else still on CodePlex, please advise. We have about 3 months to mirror what we can. Cheers!

Also famous for wining an argument on a debate about a territorial dispute!

Yes. However this is not exactly a bug on TweakScale, because it is working on Stock, and TweakScale "vanilla" aims to support only Stock and DLCs. There's a task for it, and even a new Companion incepted to be focused only on Fuel Switches (all of them, not only B9PS - but B9PS and FS will be the first ones implemented). However, some pressuring not directly related problems diverted me from these tasks on the time window I had for modding (observe that the KSP-Recall issue was created on the same day I was working on B9PS support on the Companion), so unfortunately this will need to wait a week (worst case two) until the next time window for it. Sorry for that. It will be tackled on for sure.

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