Lisias

Install TweakScale Companion for SMCE. If anything goes wrong even with it installed, then publish the KSP.log on TweakScale Companion Program thread.

I would agree with you if the new updates would not AT LEAST be breaking the core business of the game. On a vanilla stock game, [nope, I misread the report. On a vanilla game you are being over-refunded, the under-refunding happens on modded games] you can't play a Career game safely anymore on 1.11.x - there's a nasty bug where you are not refunded on recovery for some parts, and on more complex crafts, you would be losing hundreds of thousands of Funds on recovering the craft. This is the game's Score System, dude. They just messed up the game's core business. The RCS Block v2 on the KSP 1.11.1 release was something else too, it was not only a cosmetic problem, the RCS was really thrusting on the wrong direction! And, again, on a Stock vanilla game. Because you don't want to lose all the stuff you have working now? I heard of people losing savegames by updating from 1.11.0 to 1.11.1 (if memory servers well). I'm not complaining about new features, they are nice, of course. But not so nice that would worth losing my savegames on a minor update in the hope of getting some really nasty bugs fixed (as the refunding problem I mentioned above). KSP is a long term gaming platform - you will take months in order to complete a Career game. Losing a Career is a pretty nasty blow to the player. Me too. Being the reason I think they should stop updating new features to the game and start to create new content for it, and then sell the new content. I'm all for DLCs, I was buying every one of them even by not using them most of the time. Because I KNOW developers need money to keep the business running, but I fail to understand how to keep a Company afloat by breaking core functionalities of the game on free updates instead of producing quality content to be sold. Someone has to pay the bills. I completely understand them too, as I also have a Company to keep afloat. Sometimes the cash flow just don't allow us to do things the right way, so we do it as we can, and then fix them next month when the cash flow normalizes. And this appears to be the problem now: or the cash flow is not going back, or it was not being used to fix things that needed to go broken trough the door last month. So, being completely honest, I don't want more updates. I want content. The updates are breaking too much important things, and new content will give us more things to do and to brag about on "What you did on KSP today".

Ideally, when people license the add'ons on a OSI approved license (OSI aims to be a kind if ISO for open source licenses - I wonder if they intended a pun with the name), anyone can took the code and keep it alive. Problem happens when the add'on is licensed under anything else. Most Open Source developers avoid touching them, not to mention some gotchas that you need to be aware when trying to "adopt" such add'ons. About Add'Ons being messed up, sometimes it's unavoidable. On the past, when they released KSP 1.4.4, some very used add'ons broke because they changed a thingy called PQS (a code that renders terrains). The new PQS aimed to optimise things by simplifying the terrain based on the distance of the camera - too far terrains would be too tiny to be rendered at full detail, so why not reduce the details to be rendered at all? But that change broke all add'ons that was made relying on the old PQS system. So, sometimes, breaking things is unavoidable. Things only get nasty when things are broken by no technical reason. Welcome! About your Kerbal-X crane, I will try to play with it on the WeekEnd. On working days is hard to find time (and most of the free time is being eating by KSP-Recall... ) Do you know Kerbal Electric? This is one add'on I miss on newer KSP. Way more options to play than current stock.

Nope. Emulators will keep the torch lit. I'm playing Directd3D games on my MacOS thanks to Wine. Hell, I'm playing MS-DOS games era thanks to DOSBox! Don't be. The retro-gaming community is way bigger than you think, and these guys go to the extra mile to keep things running thigh. Some games get way better once the retro-gaming community take over. I hope not. Every new update introduces new bugs, some terrible, that usually are never fixed. And since some of these bugs break add'ons we use, the net result is negative.

I won't. Believe it or not, we are having a busy week on job, and this escapades to do anything else ends up helping. Not being able to proper rest because you need to watch something can be terribly frustrating, so I keep a window opened on the secondary monitor to watch it and Keep Kerbaling on the main one. Today I need to figure out how in hell some <insert your favorite non-forum conforming adjective here> implemented a very simple thing to do on a sysvinit on a freaking systemd box. Believe me, before the end of the day we will have a new release of Recall - or someone is going be thrown through the window. Humm.. How about an add'on about financial frauds? Now and then, Funds are stollen from your recoveries, and you need to investigate before the scandal goes public and affects the KSC's reputation??

Well, I think I finally understood (famous last words). The minimalistic craft used on the issue #16 was using parachutes and EVA JetPacks. These two parts are "free", so only the fuel of the JetPack was being counted. Your new test suggests (strongly suggests. to tell you the true) that whatever is screwing up the refunding on Stock, is screwing up only on Resources - the part's "dry cost" is being correctly accounted for. So, yeah... I will need to find my way on that ProtoPartSnapshot and ProtoPartResourceSnapshot stunts and do the job the hard way. Stay tuned. I will try to publish a new release about 15 hours from now.

You know, it happened something weird to me too. On KSC, while trying to enter VAB, somehow the TechTree scene entered instead... At that time, I thought I had screwed up something (as I was testing Recall), but now that you report something more or less similar... That happened to me too. The solution for me was to exit the VAB/SPH, and then enter it again... This happens because you are using non alphanumerical chars on the name, as dashes, slashes, etc. The explanation for this is a bit technical, I will try to simplify it: Unity, the mega-uber-library that KSP uses to do things like graphics, sounds, etc, is aimed to be multiplataform, i.e., it aims to work on many kinds of computers, from Macs to Androids, iPhones, Game Consoles and, obviously, Windows. So a lot of things need to be "abstracted" in a way that differences between these different computers would not get in the way of the developer. One of these things is filenames. Different operating systems have different meanings for some chars: on Linux, Android, Macs, etc, the slash "/" is used to separate directories on pathnames, but on Windows, a back-slash "\" is used for it. A double-colon ":" cannot be used on filenames on Windows, but can on my Mac. And so on. So Unity convert everything into a thingy called "URI" (Uniform Resource Identifier"), that is a stunt meant to allow naming things on every type of computer in the World on the same way. The problem is that the way Unity uses that URI stunt makes us lose track of the some characters, as they are all converted into a dot "." on the URI thing. So, "KTM 1060-3.1" ends up being "KTM.1060.3.1" on the URI thing, and with the URI different from the filename, KSP thinks they are two different things and so alerts you that you are going to overwrite a file that looks different, but it's the same. (yeah, computers can be very messy!) I think I know, but again it's a very technical issue: probably an Exception happened inside KSP guts, and when this happens, whatever it was going to do, it's halted and left uncompleted. So, imagine that by saving the craft, KSP would need to do what follows: Gray out all buttons that would change the craft (or it may save a half-baked craft!) Gray out the buttons that would change the scene (otherwise Unity will kill the save code before it finishes!) Now it save the craft to a file Then it enables back the buttons that change the scene Then it enables back the buttons that can change the craft. Let's imagine that on step 3, something pretty weird happened, so weird that the developer didn't coded a workaround for it - this is what we call a uncaught Exception. When this happens, Unity gets the Exception, logs it on the log file, and promptly kills the running code that launched the Exception thing. If this happens on step 3, the steps 4 and 5 will not be executed anymore. Of course I don't now if the problem you got was really on saving the craft - it can be anything, I just used the "save craft" as plausible example. In a way or another, the KSP.log and the Player.log will have the problem logged. If you can post them here, we can try to check what happened - most of the time, it's something missing on the game, as an asset or an dll deleted by accident. S.A.V.E. saves the craft, and all the information on the savegame - it's a lot of stuff. And yeah, if the current stuff is broken, S.A.V.E will save them broken as they are. The nice thing abot S.A.V.E. is that it does not delete the previous copy, it keeps the many older copies, creating a historic of your saves. So, when something bad happens and you just realise it some time later, you can try to load an older version where the problem didn't happened. You lose some things, but don't lose everything. But... If I'm right and your installment is missing a file or two, loading a older and good copy will not solve, as it will be screwed on memory due that problem I think your rig may have. Do you know how to locate and send the KSP.log and Player log into a dropbox or something?

NOTAM A new release, 0.1.0.6, is now available on GitHub only. It (hopefully) fixes the Stock's OverRefunding problem described below and on github issue #16. To prevent another mishap to reach the mainstream (as I foolishly did on 0.1.0.4 - What could possibly go wrong?), I'll keep this one only on GitHub for a few days while I give this a proper bashing test time. As usual these days, a DebugMode is available for the brave Kerbonauts that don't fear I/O on KSP.log. https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.1.0.6

Yep. But use the 0.1.0.5 release, currently on the oven. [Released!] I found the problem. Coroutines were useful in the past, nowadays I'm not so sure. But it's simple. Imagine a "for loop": for (ever) { try { do_something(); } catch (yield value) { send_to_caller(value); continue; } catch (yield break) { break; } } You write the "do_something" function, and this function returns a value each time it's called using yield, or terminate using yield break. How the value is sent to the caller is the hard part, but this Unity does for you. Unity guarantees that your "do_something" is called only once by frame, so this is a cheap multitasking mechanism for non multithreaded environments (essentially what Unity was on version 3 or 4, I think). Just don't do loops inside your coroutine, or you will drag the framerate.

I confirm the problem. Kerbodyne has a grudge with me and it's retaliating. Well, I have. I messed up. Refunding can't be applied immediately on craft launch because otherwise you will be over-billed (as the billing will count the Refunding as the price of the launch). So I had to delay the Refunding creation for some frames. However, TweakScale also has a similar problem (but due different reasons). TweakScale can't run on OnStart because at this point there's no guarantee that every other module on the part was already OnStarted, and since TweakScale needs to mangle these modules on scaling, trying to do so on OnStart will be a race condition where you don't know if the module you are scaling was already OnStarted or not. So TweakScale also delays it's run a bit, it do its "real" OnStart on the first Update. But Refunding does its delay on FixedUpdate - I choose it because its timing is determinist, while the Update is variable. I think I probably caused a race condition of my own... I'm trying a quick test before bedtime - let's see if I'm rigtht. -- -- POST EDIT -- -- Bad luck, things are not so simple. Refunding is doing its work right on Editor Time. Whatever is happening, is happening on recovering - exactly the place where I didn't expected more problems.... [LOG 01:54:05.953] [KSP-Recall-Refunding] TRACE: OnStart Size3LargeTank:FFFA573C Editor True [LOG 01:54:06.081] [KSP-Recall-Refunding] TRACE: OnStart probeCoreSphere.v2:FFFA5702 Editor True [LOG 01:54:06.183] [KSP-Recall-Refunding] TRACE: FixedUpdate Size3LargeTank:FFFA573C [LOG 01:54:06.184] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,LiquidFuel) => 12288.0023803713 [LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,Oxidizer) => 3379.20073852546 [LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,ModulePartVariants) => 0 [LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,Refunding) => 0 [LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,TweakScale) => 17814.82 [LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: FixedUpdate probeCoreSphere.v2:FFFA5702 [LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(probeCoreSphere.v2,ElectricCharge) => 0 [LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(probeCoreSphere.v2,Refunding) => 0 [LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(probeCoreSphere.v2,TweakScale) => 0 [LOG 01:54:11.433] [KSP-Recall-Refunding] TRACE: OnSave Size3LargeTank:FFFA573C [LOG 01:54:11.433] [KSP-Recall-Refunding] TRACE: OnSave probeCoreSphere.v2:FFFA5702 However, I found the problem! Damn! I shoot me in the feet! [ All the four!! ] [LOG 01:56:03.706] [KSP-Recall-Refunding-FlightHelper] TRACE: OnVesselRecoveryRequested Untitled Space Craft [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: Recalculate Size3LargeTank:FFFA26B0 [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,LiquidFuel) => 12288.0023803713 [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,Oxidizer) => 3379.20073852546 [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,ModulePartVariants) => 0 [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,Refunding) => -17814.82 <<-- KRAP!!!!!! [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,TweakScale) => 17814.82 [LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 46482.0; resourceCosts:15667.2; wrongCost:30814.8; rightCost:30814.8; fix:0.0 ; New release with this fixed in the next 30 minutes.

Hey, you found something apparently old - initially, I was thinking that I screwed up something when implementing support for Variants, as the S3-1440 has variants. But then I redid the test with the S3-7200 (that doesn't have Variants), and I reproduced the problem the same way. On a wild guess, I think the error is happening because the code is selecting the wrong attachment node to base the scaling on... So I made some more tests, and realised that of the parts I tried, only Command Modules presented the misbehaviour - other fuels tanks, engines, etc none of them had misbehaved when attached to the bottom of the root part. Then I tried a MK1 Inline Cockpit, and it unexpectedly behave nicely, so this ruled out the Command Module thesis. Then I tried an Aerodynamic Nose Cone, and I got the misbehaviour again. Then a light bulb lightened somewhere inside my dull head and I redid the test with the Mk1 Inline Cockpit, but rotating it before attachment, and then I reproduced it on this part. I think the code is not handling correctly the rotation of the part that needs to be displaced due the scaling of its parent. Link to the Issue: https://github.com/net-lisias-ksp/TweakScale/issues/175

KRAP!!! This will screw up the local cache, forcing the browser to redownload the images every time you visit the page! KRAP!!

I figured out something interesting. Using a debug compile of Refunding, I realised that ModuleInventoryPart implemented IPartCostModifier, and it's returning a cost of 35Funds (look for CalculateModulesCost below): [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Recalculate kerbalEVAfemale (Valentina Kerman):FFF9DD2C [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVAfemale,ModuleInventoryPart) => 35 [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVAfemale,Refunding) => 0 [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 0.0; resourceCosts:0.0; wrongCost:0.0; rightCost:35.0; fix:35.0 ; [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: UpdateResource kerbalEVAfemale:FFF9DD2C [LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Test OverRefunding-Part:FFF9DD2C is not stackable [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Before PartResource 0 1 1 [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: After PartResource 35 0 1 [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Recalculate kerbalEVA (Lulan Kerman):FFF9D762 [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVA,ModuleInventoryPart) => 35 [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVA,Refunding) => 0 [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 0.0; resourceCosts:0.0; wrongCost:0.0; rightCost:35.0; fix:35.0 ; [LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: UpdateResource kerbalEVA:FFF9D762 Since Refunding tacitly assume that the IPartCostModifier is always ignored, it adds that 35Funds into the costFix variable (that will be used to create the RefundingResource later). Since we have two Kerbals on the vessel, we have two Refundings of 35 Funds, ergo 70 Funds. So we now have the explanation from where came that 70 Refunding. Now we need to find from where the others 70 Funds came. Logic suggests that each part that the Kerbal's IPartCostModifier is being honored if and only if the Kerbal has a Resource on him [NO! Even Stock Career is broken, the Funds are being incorrectly refunded on vanilla too!]. This would explain the 140 Funds on the recovery of the Vessel used for this test. ------ POST EDIT ------ HA!! It's yet another bug on KSP!!!! Resources on storage are being counted twice. That extra 70 is from KSP itself! So Refunding need to detect these situations somehow, and DEFUND the value of the Resources to get the correct value back --- --- POST POST EDIT -- -- Given the seriousness of the situation, I made a DebugMode release for KSP-Recall 0.1.0.4 . Please, pretty please, use it only for debugging purposes. Note that you will need to copy the file KSPe.cfg into <KSP_ROOT>/PluginData folder (and not inside GameData!)

Yes, and it's showing for me... How is your browser configuration? Are you behind a firewall?

S.A.V.E. is an add'on to automate backups of savegames. Highly recommended. This will not protect your installment, but will keep backup copies of your savegames that can be used to restore them if by some mishap the KSP instillment gets broken to the point to corrupt the current savegames. In time... you are using Windows, right? Did you know that you can set a flag on the KSP folder to tell Windows to keep everything compressed on the file system for you? KSP just do heavy file I/O on loading, and 99% of the time it's reading files - and having the files compressed by Windows for you will make loading KSP faster, and will also save a lot of space on your disk drive. In a way or another, since you are using Steam, the easiest way to locate the KSP files is to use the "Browse Local files" option: The Windows Explorer will open on the place the KSP is installed. From there, you can copy it to somewhere else for backup purposes, or to play from outside the Steam - what I think it's better. From there, follow this tutorial. You can also completely screw up everything too, so pay attention on any Dialog Box asking you for confirming something.

Should we direct our complains to Private Division directly, so? This is not a blaming game. This is about results. Give us results, and you will see the complains be turned into praising.

I think we have a probable cause. Steam started to update things, and ended up removing some old ones. Modding a Steam maintained game is pretty tricky ( I tried myself in the past, decided it doesn't worth the trouble), I would recommend making a copy of the game and modding only the copy.

Bad patching is always a pain in the SAS, even when it appears to work at first, Try diagnosing the thing as we did last time: do a full copy of the installment, then run the copy eliminating one AddOn at time to see what changes. As soon as the problems vanishes, you found something - but not necessarily the culprit. Publish the KSP.log too, sometimes it's something easy to spot on an eye glance.

Yes, we can. And yes, we do. And that's the problem.

It may be intimidating at first, but it's really not that hard once you get your grasp on it. First thing is to download and install Visual Studio Community Edition. The installer will do the heavy lifting for you. Then, instead of downloading the code, it's better to clone the repository. For that, you will need GIT. Using the embedded GIT client on VS is possible, but I hate this piece of crap, I prefer to use a proper GIT client, as Source Tree or Git Kraken. If you never heard of GIT before, I strongly recommend you to read a good introductory tutorial about the matter. Once you cloned the repository and installed the VS, all you need to do is to open the Solution File (SLN) using Visual Studio, and 80% of your problems are solved. And so you will have something like this on your screen: Now with 80% of your problems solved, we need to solve the other 80%. Every project on KSP has a thingy called Dependency. It's something else that your code relies in order to work. Unity Engine is, obviously, one of them, and the KSP libraries are another. On Visual Studio, we set them on the References "folder" on the Project Explorer: That ones inside the References thingy is each one of the Assemblies I used on this project. An Assembly is a "collection of related code" on C#, and are usually delivered inside a file called DLL (Dynamic Linked File). This is a source of confusion, because DLLs were initially meant to deploy shared C++ compiled code, and when used for this, the dependency is the DLL itself. On C#, however, DLLs are only glorified ZIP files - the dependency is not the DLL, but what is inside it. So the DLL can have any name, as long the Assembly inside it has has the name you need. But, yet, the Assemblies are deployed inside DLLs, and usually the DLL file name follows the name of the Assembly it delivers (but not always, pay attention to this detail as it can bite you on the SAS horribly). What leads us to another problem. You will not get a References list nice and ready to be used as it's shown above. It's almost sure you will have a messed up References list, as shown below: This means that the DLLs I'm using on my machine are not available on the same place on yours. This is the first thing you will have to fix in order to recompile the add'on. There're many professional ways of solving this problem, but usually people playing with KSP add'ons are not professionals and, so, not prone to waste time on learning how to do it professionally. So let's do it the simple way: quick & dirty - it's how I do anyway... The easiest way to fix that, so, it's just to pinpoint the References to your local KSP installment you want to use for toying - I strongly advise you to make a copy of your game and use only that copy for toying add'ons - you can really screw up things by mangling source code, compiling it and running it on KSP. Believe on me, I know what I'm talking. So, take note of every red alerted Assembly name on the References and delete them (there's a glitch on Visual Studio that if you try to add new references for already existing ones, on deleting the crappy one the new one is deleted too - so it's better to delete them first). Click on the crappy Assembly using the right mouse button and select Delete: Now you will add the copies you have on your machine (you took notes of the Assemblies you deleted, right?). To do so, Right Click on References and select Add: It will open a Modal Window, select the Net Assembly tab: And then click on the Browse button under the list of current known Assemblies (I expect your list will be empty, mine if full of Assemblies from many different KSP versions): From now on, it's hunt time, baby. You need to locate every needed DLL. It sounds harder than it is, really. These DLLs are located on very specific places. The KSP and Unity DLLs, on Windows machines, will be on the Managed directory that it's on the KSP_Data directory on the same place where is the KSP.exe file. On Linux, if memory serves me well, it's the same. On MacOS things are different, you will find them on KSP.app/Contents/Resources/Data/Managed . When the add'on your are mangling depends of other add'ons, you will find them on the GameData folder somewhere. You will need to dig a bit on these ones. Now you are done. Build the Solution to see if everything is all right: Once the building is done, you will find your compiled artefacts on the bin folder somewhere on the Solution's folder (dig a little, they are usually on the same place the SLN file is): There 're Release and Debug binaries. While developing, we usually shove a lot of debugging stuff that it's unwanted on the user's machine, so we get these debugging stuff ripped off the code when we compile a Release dll. You select Release or Debug on the top left of the Window (see the screenshot above where I tell how to Build the thing). Now all you need is to copy the compiled DLL (only the one really generated is needed, on the example above, Score.dll) into the right place on the KSP's GameData folder and you are ready to screw up your KSP installment on new and exciting ways!! Just always remember on doing thing on test beds (specialised copies meant to be mangled and mercilessly destroyed while testing things without risking your important savegames), and happy hacking!

Why, by Kraken's Sake, every single thread started by a newbie asking directions about something around here invariably get a one star on the Rate? This is getting ridiculous to the point that I starting to actively look for one star rated posts, as these ones are usually from people really in need of help. Sometimes I wish we could know who is starring the threads.

For the nth² time: this is not customer's problem. I'm sympathise with your problems, but they will not change how customers and shareholders are seeing the product. Blaming previous developers is easy, by the way - and this just don't change the fact that since then, every single opportunity to prevent things from going trough the tubes was just ignored. Your professionalism is measured by what you can deliver with what you have in hands, not by what you could deliver if everything was made right in the past. You accepted the job.

The NREs were fixed on latest Pre Release: https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.1.0.4 I wil not promote it a proper release yet, because I'm testing if the failed solution for #16 would fix by accident a situation I had foresee on FMRS (over refunding on automatic recoveries). Your over-refunding, however, is due another misbehaviour on KSP, that it's counting TWICE any Resource stored on a Inventory Part. I will take a break in the next hours (RL is calling), but I will be on it again later. Until there, please report anything different using this pre-release. Thanks for the heads up and sorry by the NRE. -- POST EDIT -- I promoted the thing as Release, as it fixed the NRE and a small trick solved the hypothetical problem in which third-parties Add'Ons that would recover Craft themselves would bork the calculations due the Refunding Resource stunt.

I confirm the Exception. That is embarrassing... The code blowing up is this one: private void RemoveResourceIfAvailable() { Log.dbg("Removing {0} from part {1}-{2}:{3:X}", RESOURCENAME, this.part.vessel.vesselName, this.part.partName, this.part.GetInstanceID()); Replacing the this.part.vessel.vesselName thingy with a property guarding against NULLs on this.part.vessel solved the exception problem - as we can see, a part loses it's vessel when moving from the Kerbal to the Storage. (the fix was preemptively replicated on the whole code - better safe than sorry) Well... I was caught with my pants down on this, but thinking a bit on the problem, it makes sense. The fix is on this commit, if you are curious. However, after fixing this, I still got a Over-Refunding!!!! Long story made short, I got twice the intended refunding for this craft. And I know it because Refunding is traceable, and it listed 70 Funds as Refunding besides KSP giving me 140 Funds! The whole history is on Issue #16. I think I know what's happening - the Recovering process is correctly recovering the funds of Stored parts![Nope! The IPartCostModifier is still being ignored on Stored parts - what we found was A BUG INSIDE THE BUG, as the Refunding Resource is being counted TWICE, damnit!] Jesus Christ, how many ways of doing the same freaking thing were implemented on KSP? It's no surprise the code base is so terribly bugged, they implemented the same feature many times, each one on a different way - and once something changes, God knows how may different code that was doing the same thing need to be fixed - not to mention tested! I'm working on a solution for this. Theoretically, it's simple - once the part is stored inside an Inventory Part, the Refunding must be withdrawn, and once it is removed from it, reapplied. But... Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet... [EDIT: I will say it again: Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet...]

My guesses are not the problem. Customer's and Shareholder's guesses are. You know, someone is paying for the Party - and they want the interests back. It's not what I want, sir. It's what the customers want. Being fair or unfair, there's a contract on this thing - and providing bugged products rarely is a way to fulfil such contracts. I don't know who is paying for this Party - I'm sure I am not one of them, because the ones paying for the Party are the ones calling the shots. Obviously, customers like me are not the ones calling the shots around here.