Lisias

It's something on your rig. I'm sorry, but you really need to go to that Uninstall Fest in order to diagnose this problem. I built a Test Bed using KSP 1.11.2, the latest KSP Recall and the Latest TweakScale. No problem detected on KIS or KSPR. Then I launched the same vessel again, gone to EVA and dropped the Electric ScrewDriver on the ground, then I recovered the vessel. Again, the Refunding is right. The ScrewDriver was not refunded. KSP-Recall is working fine with KIS. So we are back to something borking on your installment. You will have to carryon that Uninstall Fest until the problem vanishes, otherwise I can't further help!

Humm... Perhaps I missed an use case after all... I don't remember doing this test with KIS, i recollect only testing ModuleInventoryPart... I will try it by night and come back to you...

Mine is 10G. Believe me, I know how you feel. Unfortunately, it's the best way to diagnose the problem. Since most of the time the triggering module is used by the craft, I nailed down the most probable suspects in an attempt to save you some time. Start removing that Add'Ons I mentioned first (one by one, otherwise you will have to do it again by reinstalling them to find the trigger). There're good chances you will find the trigger this way. Launching the craft is fine, KSP is calling IPartCostModifier on every part as it should on Editor and on Launch, The bug is on recovering the craft. The developer that changed that code (probably in order to cope with the ModulePartInventory , so you would recover funds from parts stored inside parts - and there's a bug on this code too) forgot something, and so a lot of funds that you should have being refunded, it's not. KSP-Recall::Refund does not messes with Editor and Launch (it only run to save values to remember how much the part was costing on launch, and that's all!). Refund tricks KSP into counting the missing funds on Recovery only, I think we have two lines crossing here. One, it's the KSP bug that KSP-Recall::Refunding is working around. Other, it's something borking heavily on your rig, and this somehow is sabotaging some Add'Ons (KSP-Recall between them). The KSP bug is tackled down by RSPR. If even by installing KSPR (as you did) you are not being refunded correctly, we have one of the following problems: 1) I messed up or forgot something - it's always a possibility, as I work using a thingy called "Clean Room Design", a way to "reverse engineering" something without breaking forum rules (that explicitly forbids decompiling here). 2) Something else is borking in a way that it's preventing KSP-Recall from doing its job. Right now, we have a KSP.log littered with Exceptions on some critical parts of KSP that heavily suggests you are suffering from a "type 2" problem, and that list of Add'Ons I wrote above is the best guess about who can be the trigger of the problem. But... It's exactly what I'm saying: it's my current best guess.... The only real way to dignose the problem is by removing Add'Ons one by one until the problem vanishes. The last add'on removed is the trigger for the problem - and once we know the trigger, we have to closely look on it to see exactly what's going wrong...

It was a stupid question, but it had to be done - now and then someone complain about something he/she forgot to install. Well, these links worked. On an initial analysis, there's something wrong involving WB modules: [EXC 23:45:33.848] NullReferenceException: Object reference not set to an instance of an object WOLF.WOLF_CrewTransferScenario.OnAwake () (at <7eb3c6e6467043e49992a5c417f5d542>:0) ScenarioModule.Awake () (at <06f13185617646e5bc801baeab53ab75>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) ScenarioRunner:AddModule(String) ScenarioRunner:AddModule(ConfigNode) ProtoScenarioModule:Load(ScenarioRunner) ScenarioRunner:LoadModules(List`1) ScenarioRunner:SetProtoModules(List`1) Game:Load() <Start>d__4:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) WOLF is also borking sometimes during startup, and this can abort some initialisation that could bite you later. Additionally, your KSP.log is littered with errors like this one: [ERR 23:51:27.782] KSP_PartVolume: PartInfo.Start, Part: WildBlueIndustries/Pathfinder/Parts/Utility/Mule/WBI_Cone at WildBlueIndustries.WBIResourceSwitcher.GetModuleMass (System.Single defaultMass, ModifierStagingSituation sit at Part.GetModuleMass (System.Single defaultMass, ModifierStagingSituation sit) [0x00046] in <06f13185617646e5bc at ModuleCargoPart.GetInfo () [0x00098] in <06f13185617646e5bc801baeab53ab75>:0 at KSP_PartVolume.PartVolume.Start () [0x00552] in <89d5800f7d6c4fce99a2b0104c856cea>:0 What's a surprise, as I have PartInfo installed and this doesn't happens here. So I think that perhaps something on WildBlueIndustries are borking (or being borked by someone else). In a way or another, Refunding (the thingy on KSP Recall that does the magic) appears to be working fine, no exceptions were issued mentioning it. and the expected messages about it being loaded and instantiated are there: [LOG 23:25:08.513] Load(Assembly): 999_KSP-Recall/Plugins/Refunding [LOG 23:25:08.513] AssemblyLoader: Loading assembly at E:\games\Kerbal Space Program\GameData\999_KSP-Recall\Plugins\Refunding.dll Refunding v0.2.0.0 [LOG 23:33:09.505] Config(RESOURCE_DEFINITION) 999_KSP-Recall/Resources/Resources/RefundingForKSP111x [LOG 23:33:10.482] Resource RefundingForKSP111x added to database Refunding 0.2.0.0 0.2.0.0 8011ca680ffb8b2555bc48c04843493e02515df59eb51897f11c563ab1769d5d [LOG 23:33:11.157] Resource RefundingForKSP111x added to database [LOG 23:45:13.909] [AddonLoader]: Instantiating addon 'SpaceCentreHelper' from assembly 'Refunding' [LOG 23:46:37.212] [AddonLoader]: Instantiating addon 'EditorHelper' from assembly 'Refunding' [LOG 23:48:26.221] [AddonLoader]: Instantiating addon 'FlightHelper' from assembly 'Refunding' [LOG 23:49:50.977] [AddonLoader]: Instantiating addon 'SpaceCentreHelper' from assembly 'Refunding' My best guess is that one of that exceptions it's littering your KSP.log is aborting some internal KSP processing, and so KSP-Recall is not being called as it should. Keep in mind that this is not affecting only Recall, as any other add'on could be being also a victim of this problem (perhaps WBI itself, and so it would be just another screaming victim). Your best line of action at this point is to backup the whole installation, and on the copy selectively remove add'ons until the problem vanishes. This happening, the last removed add'on is the trigger for the problem, and so you need to ask its maintainer for help. In an attempt to help you, follows every Module your sample craft is using: KIS.electricScrewdriver LifeSupportModule MechJebCore ModuleCargoPart ModuleColorChanger ModuleCommand ModuleConductionMultiplier ModuleDataTransmitter ModuleInventoryPart ModuleKISInventory ModuleKISItemAttachTool ModuleKISItemEvaPropellant ModuleLiftingSurface ModulePartVariants ModuleReactionWheel ModuleScienceContainer ModuleScienceExperiment ModuleTestSubject ModuleTripLogger Refunding SCANRPMStorage TweakScale USI_ModuleRecycleablePart WBIPartScrapper In strikethrough, the Modules I know and I had already tested while developing Refunding. In normal, modules that I have already used on Refunding while diagnosing problems and found they were not the problem at that time - but I didn't thoroughly tested them myself. They should be working, but I can't guarantee. In bold Modules that I didn't tested KSP-R yet. This doesn't means they are at faulty, it only means that I didn't tested them - so they are good candidates for starters on the Uninstall Fest: TAC Life Support SCANSat USITools (and, so, everything USI related) Wild Blue's PathFinder and Buffalo. Remove them one by one and test the craft again. Removing all of them at once would make difficult later to detect exactly who was the one borking on you. Keep in mind that you will not find the culprit, but the trigger. It's possible that something else is inducing the detected module to misbehave, and so it would be the screaming victim and not the culprit - but pinpoint the trigger is the first step nevertheless. Once you detect the trigger, its maintainer is the one that can help you.

I'm very reticent on relying on Walled Gardens to provide community support for modding. Amateurs will not cope with it. Professionals will charge for it. Walled Gardens are expensive. I would prefer a DLC centric model instead for providing new content. If you are going to rely on professionals for doing the work, DLCs are a proven and safer option IMHO. You keep the money and the creative control in-house.

These links are not working for me. Sorry. On another wild guess, if you are not installing KSPR but are using TweakScale, this is the behaviour Stock currently have - it plain ignores the Extra Cost TweakScale is providing by scaling on Recovering, besides still using it to charge you while launching. If you are not installing KSPR, but is using some other add'on that also relies on IPartCostModifier (as fuel switches, damage or reliability add'ons, etc), this is also a Stock misbehaviour - as TweakScale is not the only one relying on IPartCostModifier. In both cases, installing KSPR should be fixing the problem for you. If you had installed KSPR and are still getting this problem, now I'm worried because you had found a new use case that KSPR should be handling and it's (or it's borking on the task), and on this hypothesis, I really need that craft file and KSP.log in order to inspect them to check what is going on. Do you have a Github account? If yes, please add a comment with these two files on this issue: https://github.com/net-lisias-ksp/KSP-Recall/issues/19 - Github allows you to upload the files on the comment itself (zip them first), and so we will not to cope with some dropmefiles.com idiosyncrasy.

I will need the craft file and the KSP.log at least, otherwise I can't help! Costs calculated by Editor are out of scope from KSPR, I think you need to make that question on the KSP Support Forum. (but on a wild guess, I think the difference is due the parachute and the EVA jetpack - they are discrete parts parts now)

Frankly, at least until KSP 1.11, the relationship can be resumed to publishing half-baked, poorly tested KSP releases, and the mod-authors scrambling to detect problems and work around them. What KSP 1.12 will bring to us is still to be seen. But, usually, most simple add'ons "survive" unscratched, as it's not usual for KSP to change too many things that could severely break too much add'ons (KSP 1.11 was an exception, 1.8.0 and 1.4.0 were another ones). I could not agree more. This is not going to happen. One size does not fits all, and there're no enough money available for the Dev Team to allow them to satisfy every single current and new user. Every single successful game I'm aware of was heavily modded in a way or another, and the harder the game is to be modded, more chances it has to be forgotten as time goes by. What may be not that good as you think. Most of the most successful add'ons I'm aware were made by non-professionals. Keep something in mind: professional developers are expensive (at least, the good ones). We do what we can using our free time, but once a too high standard is demanded, you will need us to use working time for it - and so, we will charge for it. I suggest you to have a look on the Flight Sim scene (FSX, X-Plane, etc), where the add'ons are charged - and some of them are twice the price of the base game. Or perhaps DCS, where the game is free but evey add'on has a hefty price tag on it. Another one that worths to be mentioned is Microprose's Falcon 4.0, that was extensively modded over time - it was even almost rewritten for modern computers in the 2000's. All that code (released under the MIT, as I was informed) is now on BMS, that is closed sourced and so all that code is essentially locked now (I just can't find that repositories with that code anymore, the surviving one is utterly incomplete). Without the amateurs, people are going to need deep pockets in order to play a modded game - what's, frankly, kinda of a settle back: if you are going to rely on selling copies of the game to make a living, you will want people to pay money to you, not to third parties. And, since we are talking popularity, KSP has at this moment at least 3 times the concurrent players now than FSX: Steam Edition (not exactly bad, as FS2020 is on the wild), while X-Plane has less than half. Comparing to X-Plane appears to be more sensible, as X-Plane is also a 10 years old franchise. Do your math. KSP1 would be already sunk without the modder community. What will happen to KSP2 it's something we will need to wait and see, however... Of course!! Anything. The fun is on the path, not on the destination! Frankly, I think this will backfire horribly. The P/R damage can be substantial. I think this is the way to go. Way more inclusive, way more "welcoming". And it will save the community from starting up a new era repeating some of the mistakes of the past. On an ideal world, the Community should provide such tools. The current mess is due a lack of consensus about how things should be done, a somewhat lack of rigor from the present tools on serving the few things there're a consensus about how it should be done and, most of all, the existent utter barrier on allowing a third player on this field, what would provide the needed incentive to improve the current status quo. Not to mention buying a fight with the Steam competition. You don't want to rely solely on Steam to provide features to your game, there're GoG et all around, and you need to have them around in order to induce Steam to behave nicely with you. Never put all your eggs on the same basket. Most of us have only two, we need to properly care for them. Without side-loading, KSP1 would be seriously injured by now - perhaps dead. Not everybody likes CKAN, not everybody likes Curseforge. I would had quit this already if I was to be forced into using one of them.

No, it's a bug on KSP 1.11.x . KSP 1.11.x is not calling a thing called IPartCostModifier where add'ons would tell KSP about how they are changing the cost of the part. This affects TweakScale (between everybody else), as it uses that interface to communicate KSP how scaling affected the cost of the part. Additionally, there's another bug related to certain parts stored on parts with ModuleInventoryPart. Recall handles this use case too. KSPR does not saves your money. It "steals back" the money KSP is "stealing" from you on recovering. Since I don't have access to the KSP Source Code, I can't fix the problem myself - so I had to hack my way into this mess. And since this is a hack, I need to have a way to allow auditing the refunding (an user would not have easily noticed the ModuleInventoryPart bug without it), so the need to specify on the Recovering GUI the amount KSPR is recovering for you. Keep in mind that KSPR is not over refunding you. Missing parts and used resources (as Fuel) is not refunded back, being that the reason you are recovering less than than Editor is telling the craft is costing. As a rule of thumb, launch your craft after getting rid of all her resources, then immediately recover it. This is a situation where the refunding must be equal to the cost on Editor. If it differs, send me the craft, your KSP.log and (when available) the CKAN export list and I will tackle the problem down.

For the "stock" parts, you need: Waterfall Stock Waterfall Effects Others add'ons will need further packages, see Waterfall's OP for moar info. TweakScale Companion for Visuals (currently Alpha) See OP

Done! @kerbiloid

Yep! But, just to make it clear, TweakScale is just scaling what is being made by WaterfallFX, ok? WaterfallFX was already applying the heat distortion to Junos. I'm just scaling it once you scale the Juno!

Mig-17 undressed for maintenance. Essentially, a Jet Engine with a cockpit strapped ahead of it and some wings attached God knows how. Souce: https://www.reddit.com/r/DefensionemWB/comments/ezbj8x/naked_mig17/ -- -- -- That nine thingies radially attached on the forehead are combustion chambers. At that time, they didn't managed to have only one big combustion chamber (what would be more efficient), so they attached 9 combustion chambers on the engine to do the job! Source : http://www.midlandairmuseum.co.uk/jet.php -- -- -- And more information, specific to the Mig-17 engine, can be found here: https://cnnews.wordpress.com/2007/09/03/turbo-jet-engine-of-mig-15/

What issue? That one in which the plume scaling is reset? It's purely cosmetic, and the published alpha version has this kinda tackled down. But I didn't had the time to check why the Revert to Launch is resetting it. If by any chance, you are talking about bad patching (that pesky Warnings on booting KSP), then it will only be solved when you send me the KSP.log and Module Manager Patch logs for inspecting. These are not TweakScale problems, they are someone else screwing up and I need these logs to check what's happening in order to have a fix or workaround for them.

Virtually unnoticeable on my MacPotato 6.1 (i7 3615QM 2.3 to 3.3GHz) and Intel HD 4000 GPU. It is said that WaterfallFX is lighter than the stock ParticleFX, but on my Mac I couldn't notice any difference - MacOS is terrible for gaming, it starts compressing memory pretty fast and then your performance plummet anyway.

You need to install TweakScale Companion for Visuals, currently in Alpha . Please report any problems on that thread! Cheers!

I managed to steal a bit of time from RL to make an animation! These crafts have scaled up Junos: People willing to help me test TweakScale support for WaterfallFX are more than welcome to try it! (some bugs are expected, please report) And now?

Bad patching. Reach me on TweakScale thread, publishing the full KSP.log and MM Patch log, and we will diagnose and fix the problem. TL;DR : bad patching can change the scale of living crafts in a way that would render them unusable, and once you load and save the save game, the damage is permanent. It's not something that happens all the time, but it does. And you just figure out it happened some time after it happened (we don't check every living craft of a game every time we load it). In a way or another, it's fixable.

You must see it "live". It's way more impressive when animated - I'm going to setup my recording gadgets as soon as I can, this will worth it! I need to tell you, I was a bit skeptic about the "real need" of WaterfallFX. It was nice since the beginning, without the slightest doubt, but so was SmokeScreen too (and since my main gaming is still 1.7.3, I had very few personal reasons to work on WaterfallFX - I'm not going to move to >= 1.8 in the near future, but a fellow Kerbonaut made a request and so, I decided to work on it as he requested) . However, when I finally managed to make this work on TweakScale and saw the air breathing engine's exhausts while working on this... Dude.... What a sight, just plain beautiful.

Oh, yeah! I finally have something publishable! We have (alpha status!) support for WaterfallFX on TweakScale! More information on TweakScale Companion Thread!

Announce! TweakScale Companion for Visuals 0.0.1.0 ALPHA is on the wild. Adds support for Waterfall and works with TweakScale 2.4.5.x series and newer. First Public Release, Alpha Status, not ready for "production" Known Issues: The plume's scaling is reset to the original size when Reverting to Launch. There's something I still didn't understand on the ModuleWaterfallFX's life cycle, as it appears Launching from Editor and loading Savegames works fine (at least, until now... ). Download here or in the OP. have fun!

Since Forum rules demands that the source code must be available, I preemptively created a github repo for it. Google Drive is definitively a terrible choice for distributing software. https://github.com/net-lisias-ksph/KSPUpgradeScriptFix

Hi! I'm not aware of a conflict between these modules (i.e. I don't have notices of these codes stomping each other's toes), but I had some cases of bad patching in the past - what most of the times ended up screwing up something. If you could be more specific about the problem, and if it is not fixed yet, I can try to fix it! Cheers.

I managed to implement (preliminary) support for WaterfallFX on TweakScale! #HURRAY!! Still some work to do, but the thing works! POST EDIT Yep, things are improving!

NOTAM Preliminary support for WaterfallFX is work in progress, and we have a working prototype. #HURRAY!! Soon, on a GameData near you. -- -- -- POST EDIT -- -- -- $@$#@$#$ $@^%@