[1.4.3 <= KSP <= 1.12.5] KSP Recall - 0.4.1.0- 2024-0407

[Lisias]

8 hours ago, Krazy1 said:

The thread you linked was started before 1.11.2 was released and EVA construction was horrible before that. I got all kinds of explosions when placing parts. 

KSP is not known to tackle down all the bugs of a major release before issuing the next - it's exactly the opposite. Once a bug happens, you can expect it to linger for years without being correctly handled.

So, unfortunately, every bug that happened in the past cannot be considered completely fixed and need to be considered a probable suspect when coincidences are detected on 'new bugs' (that, not rarely, are only different side effects of a root cause that was not tackled down).

 

8 hours ago, Krazy1 said:

But this time I just removed the part from inventory and got the Null Refs before I could even try to place the part. It's probably still a core game bug. I also installed other types of lights and they worked. I tried the same Mk1 Illuminator again and it gave the Null refs again.  I might try it in stock if I find motivation. Thanks

So the thing is specific to Mk1 Illuminator? That makes things easier (or less hard) to replicate. I will give it a try,  now that I know where to look.

One thing that the other types of light have different from Illuminator Mk1 (and Mk2!) is that Illuminator is not stackable, while the other lights are. I failed to detect any other meaningful diference while looking the CFGs.

Since we are here, try this stunt:

@PART[spotLight1_v2]
{
	@MODULE[ModuleLight]
	{
		%stackableQuantity = 2
	}
}

This will make the Mk1 Illuminator "more like" the other lights (of course, do it on a disposable installment, we are mangling with the KSP's stock parts!). If the problem goes away, we found a trigger. Knowing for sure about the trigger, we can try to zero into the problem from there.

 

16 hours ago, Jebs_SY said:

Could it help to set maxAmount to some value that's big enough? This is from a save:

Dude, we have a problem. I can't set the MaxAmount to a "reasonable" value, or the part of KSP that is working fine will nullify the Refunding stunt by deducting the "total value of the Resource" on recovering.

I.e., if you fire up a vessel with 200 Units of Fuel, and on recovering it has 10 Units of Fuel left, then KSP will deduct 200*FuelCost and will refund 10*FuelCost. On this example, MaxAmount = 200 and Amount = 10.

So I need to keep MaxMount on 0.0, so KSP is fooled on the deduction I depicted above.

I didn't managed to find a solution to this yet (my last attempt, setting MaxAmount to 0.00001d fired backwards). I may need to just remove Refunding support when MAS is installed.[Naaah... I tested the wrong binary!  ]

So I tried a stunt - I set MaxAmount to be pretty small (0.0000001d) so it would get round down by KSP on recovering, but yet would give a non 0 value to MAS play with.

Please check this on your rig (I have little to no time to play KSP this week).

https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.2.0.0

In time - I checked the MAS code, it's not trying to handle hidden resources as I imagined. It's calculating the current mass of the PART, and so it really needs to take hidden resources into account.

Edited May 4, 2021 by Lisias
Brute force post merging

[Lisias]

On 5/4/2021 at 12:45 AM, Krazy1 said:

But this time I just removed the part from inventory and got the Null Refs before I could even try to place the part. It's probably still a core game bug. I also installed other types of lights and they worked. I tried the same Mk1 Illuminator again and it gave the Null refs again.  I might try it in stock if I find motivation. Thanks

Tried that on a "naked" installment (only Recall and TweakScale) - but no Exceptions where detected on KSP.log .

It's not the Refunding neither TweakScale for sure.

Full report : https://github.com/net-lisias-ksp/KSP-Recall/issues/19#issuecomment-832551502

[Jebs_SY]

On 5/4/2021 at 8:16 AM, Lisias said:

Dude, we have a problem. I can't set the MaxAmount to a "reasonable" value, or the part of KSP that is working fine will nullify the Refunding stunt by deducting the "total value of the Resource" on recovering.
I.e., if you fire up a vessel with 200 Units of Fuel, and on recovering it has 10 Units of Fuel left, then KSP will deduct 200*FuelCost and will refund 10*FuelCost. On this example, MaxAmount = 200 and Amount = 10.
So I need to keep MaxMount on 0.0, so KSP is fooled on the deduction I depicted above.
So I tried a stunt - I set MaxAmount to be pretty small (0.0000001d) so it would get round down by KSP on recovering, but yet would give a non 0 value to MAS play with.
Please check this on your rig (I have little to no time to play KSP this week).
https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.2.0.0
In time - I checked the MAS code, it's not trying to handle hidden resources as I imagined. It's calculating the current mass of the PART, and so it really needs to take hidden resources into account.

Hello Lisias,
I also don't have that much time currently, but from the first quick test it looks, like it has eliminated the log spam! 
BR Jebs_SY

[Lisias]

ANNOUNCE

KSP Recall 0.2.0.0 is on the Wild, featuring:

• A minor change to cope with MAS being a little picky about resources, even on hidden ones.

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. Right now..
• SpaceDock (and CKAN users). Right now.

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Cheers!

Edited May 11, 2021 by Lisias
All distribution channels updated.

[Lisias]

from BDB thread:

2 hours ago, Pappystein said:

Warning, KSP REcall not compatable with Smart Parts (sad panda noises!)

Damn, really? I will check what can be done...

Can you advance for me what's going wrong with Smart Parts and Recall? Without Recall, Career is seriously hindered on a modded KSP 1.11.x ....

[darthgently]

Is there a way to install the latest TweakScale without the dependency on KSPRecall?  I'm trying to narrow down a runaway memory leak that eats 64GB of RAM and all my disk space via VM in less than a minute.  I recently upgraded from a previous version of TweakScale as a standalone (non-CKAN) install sans KSPRecall to the latest CKAN version that depends on KSPRecall.  I had previously gone to the standalone without KSPR because I was getting a lot of null reference errors and low FPS with an earlier version of KSPRecall installed.  If there is a way to uninstall the Making History DLC and someone knows how to remove that PM me please as that is another test I can try. I installed TweakScale from CKAN today and so whatever versions of TS and KSPR are on CKAN are what I'm running.  Also: Nothing in logs.  All log output halts while memory disappears until crash or I kill it.

Edited May 24, 2021 by darthgently

[darthgently]

Followup on previous post here.  I moved the KSPRecall DLLs out of the GameData/....KSP-Recall../Plugins directory to elsewhere and fired everything up again and the aggressive memory leak completely went away.  Unfortunately there was no log output when the problem existed so I have nothing other than the fact that removing KSPRecall fixed the issue.  I can tell you what versions and what mods I'm running if you want me to

2 minutes ago, darthgently said:

Followup on previous post here.  I moved the KSPRecall DLLs out of the GameData/....KSP-Recall../Plugins directory to elsewhere and fired everything up again and the aggressive memory leak completely went away.  Unfortunately there was no log output when the problem existed so I have nothing other than the fact that removing KSPRecall fixed the issue.  I can tell you what versions and what mods I'm running if you want me to

Basic info:

Debian 5.10.9-1, KSP 1.11.2 (3077), TweakScale 2.4.5.0, KSPRecall 2.0.0

If I get time I will create a new install with no other mods but the above and see if I can replicate

Edited May 24, 2021 by darthgently

[darthgently]

I'm going to suggest making KSPRecall highly recommended, but not a hard dependency, for TweakScale.  Ppl can always just use the cheat menu to recover the negative funds when returning craft to KSC; that is what I've been doing for some time.  Also, it might make maintenance more manageable if the the various fixes in KSCRecall were split out into separate mods (Refund issue in one, rover issue in another, etc).  The kitchen sink approach combined with having to trick KSP to work right in convoluted ways (I can only imagine the headaches) probably makes it a bit hairy 

[Lisias]

13 hours ago, darthgently said:

Is there a way to install the latest TweakScale without the dependency on KSPRecall? 

Yes. You can just remove it. TweakScale will pesky you about it, but will work.

 

12 hours ago, darthgently said:

 fired everything up again and the aggressive memory leak completely went away. 

Basic info:

Debian 5.10.9-1, KSP 1.11.2 (3077), TweakScale 2.4.5.0, KSPRecall 2.0.0

If I get time I will create a new install with no other mods but the above and see if I can replicate

HUmm... Resourceful could be the culprit, but it is deactivated on KSP 1.11.

 

11 hours ago, darthgently said:

I'm going to suggest making KSPRecall highly recommended, but not a hard dependency, for TweakScale. 

It's is not. Recall is needed to prevent KSP to mess up your gaming due internal bugs - from KSP itself.

You can run TweakScale without Recall, but so you will have to cope with the bugs. And such bugs affects a lot of add'ons, not only TweakScale - it only happens that TweakScale appears to be the only one talking about.

On KSP 1.9, Recall is needed by TweakScale and any add'on that handle resources (As Fuel Switches like B9PS, Firespitter, Modular Fuel Tanks, etc).

On KSP 1.11, Recall is needed by any Add'On that uses IPartCostModifier.

And so on.

 

11 hours ago, darthgently said:

 Ppl can always just use the cheat menu to recover the negative funds when returning craft to KSC; that is what I've been doing for some time. 

The whole idea is to prevent people having to do so.

In a way or another, TweakScale WORKS without Recall. It's KSP that is borking, not TweakScale (or any other add'on). You CAN remove Recall and the affected add'ons (not only TweakScale) will work (or not, on KSP 1.9, the game became unplayable).

 

11 hours ago, darthgently said:

 Also, it might make maintenance more manageable if the the various fixes in KSCRecall were split out into separate mods (Refund issue in one, rover issue in another, etc). 

No.

It would be exactly the opposite, I would have to create and maintain different add'ons for fixing things unrelated to add'ons. And so I would have to create and maintain different CKAN netkan files. And in the end, everything would be installed anyway. See below.

And Recall only activates the fixes where it is needed.

 

11 hours ago, darthgently said:

 (Refund issue in one, rover issue in another, etc).  The kitchen sink approach combined with having to trick KSP to work right in convoluted ways (I can only imagine the headaches) probably makes it a bit hairy 

The convoluted ways to make things work would not be necessary if KSP had not such bugs. The headaches are about working around the bugs, not to maintaining the code running. They are just modules that need to be patched into parts in order to work - you don't patch them, they are not activated and so, don't run.

Moreover, the present solution satisfies CKAN requirements. CKAN doen't have any dispositive to allow conditional installations. It's all or nothing. So even by me splitting KSP-Recall in many different add'ons (what I don't want), all of them would be installed anyway due CKAN. No gain, just pain.

The historic for this request can be followed on TweakScale thread, starting on this post.

Edited May 24, 2021 by Lisias
I managed to cut TWO phrases by the half before posting. (sigh)

[darthgently]

8 minutes ago, Lisias said:

It's is not. Recall is needed to prevent KSP to messed you your gaming due internabugs - of KSP itself.

On CKAN, it is installed as a hard dependency for Tweakscale, that is what I meant.  But I suppose CKAN users can be directed to move the DLLs after the fact (if they run into the same issue I did)

Edited May 24, 2021 by darthgently

[Lisias]

8 hours ago, darthgently said:

On CKAN, it is installed as a hard dependency for Tweakscale, that is what I meant.  But I suppose CKAN users can be directed to move the DLLs after the fact (if they run into the same issue I did)

Now I see. Well, it appears so that's a CKAN problem. Please move the discussion to CKAN Thread as requested by CKAN guys. You may be interested on this post and the follow ups in the mean time.

In an ideal Word, users should install Recall only if needed and desired. However....

 

In time, I'm interested on the memory leak problem. Currently, Attached and Resourceful are the current suspects - but both are not activated on KSP 1.11 - They are not even patched on the parts on KSP 1.11, so I'm pretty confused about this. I will need your Module Manager ConfigCache and Patch Log in order to inspect how things are patched on your rig to know where to start looking...

Edited May 24, 2021 by Lisias
Tyops galore!

[darthgently]

10 hours ago, Lisias said:

Now I see. Well, it appears so that's a CKAN problem. Please move the discussion to CKAN Thread as requested by CKAN guys. You may be interested on this post and the follow ups in the mean time.

In an ideal Word, users should install Recall only if needed and desired. However....

 

In time, I'm interested on the memory leak problem. Currently, Attached and Resourceful are the current suspects - but both are not activated on KSP 1.11 - They are not even patched on the parts on KSP 1.11, so I'm pretty confused about this. I will need your Module Manager ConfigCache and Patch Log in order to inspect how things are patched on your rig to know where to start looking...

Ok, I'll get that stuff together.  Another piece of information is that the savefile I was working with to test the problem was at a point prior to docking.  The memory leak flares up right after docking.  I'm not sure why I didn't mention that before other than the rapid growth of the leak itself probably erased my medium term memory each time.  Lots of mods involved, some not well tested in general on 1.11.2, so, well, hopefully not too muddy to see what is at issue here

One last note: a good rule of thumb I've adopted is that if a piece of code A is intended to workaround for a bug in other code B, then it is a really good investment to not just go by the version number of code B to determine whether to apply the "fix", but to have instead a dynamic test for the bug and apply the fix, or not, based on the result of the test.   This reduces possible unintended consequences overall and also allows the fix to work on the next version if the bug still exists (for example)

[Lisias]

TL;DR: (not everybody is willing to read this wall of text)

• "I don't want Recall installed" - it's a CKAN problem
• "Recall was installed (no matter why) and it broke something" - it's my problem
• The problems are not mutually exclusive, so the presence of one problem doesn't exempt the other.

 

50 minutes ago, darthgently said:

 The memory leak flares up right after docking.  I'm not sure why I didn't mention that before other than the rapid growth of the leak itself probably erased my medium term memory each time.  Lots of mods involved, some not well tested in general on 1.11.2, so, well, hopefully not too muddy to see what is at issue here

If removing KSP Recall fixed the problem, it's still a bug on KSP Recall. This thingy must be safe to be installed, being it needed or not - otherwise is a major bug that must be tacked down.

Users do what users do - some people just shoves everything on the GameData and call it a day, and if this didn't changed in 10 years, will not change now  - so it's up to Recall to handle such problems, not the user (or even CKAN - besides I would still prefer it could, I hate bloatware)

 

50 minutes ago, darthgently said:

One last note: a good rule of thumb I've adopted is that if a piece of code A is intended to workaround for a bug in other code B, then it is a really good investment to not just go by the version number of code B to determine whether to apply the "fix", but to have instead a dynamic test for the bug and apply the fix, or not, based on the result of the test.   This reduces possible unintended consequences overall and also allows the fix to work on the next version if the bug still exists (for example)

It's what I do.

https://github.com/net-lisias-ksp/KSP-Recall/blob/master/GameData/999_KSP-Recall/KSP-Recall.cfg

Everything is deactivated by default. At startup time, the main DLL detects the running environment and selectively creates the tags that Module Manager uses to apply the patches. And the DLLs, even if patched (perhaps by someone toying with the patches), they still check if it's really a good idea to run:

https://github.com/net-lisias-ksp/KSP-Recall/blob/master/Source/KSP-Recall/Globals.cs

https://github.com/net-lisias-ksp/KSP-Recall/blob/d3f85c8efc5b437db22c86fe4ba4ac4fc295a40f/Source/Refunding/EditorHelper.cs#L38

(so merely blindly patching the Modules on parts it's not enough, you really need to mangle the Globals somehow - i.e., you need to really, really want to activate the damned things!)

And even by these flags being active and the modules patched and loaded on the parts, it's still possible to deactivate each one of the WorkArounds on a specific part, by disabling them on the PAW on Editing Time.

So, if even by all these safety measures something is still borking on your rig then it's a major flaw that I need to tackle down the fastest as I can!

Edited May 24, 2021 by Lisias
TL;DR

[Warro]

Is it normal? That price in menu and the sum in editor differs in more than 900 Funds (when recovered from launchpad it displays 900 Refund resource in it) I thought KSPR should save my money, not move them  there and back

Edited June 4, 2021 by Warro

[Lisias]

3 hours ago, Warro said:

Is it normal? That price in menu and the sum in editor differs in more than 900 Funds (when recovered from launchpad it displays 900 Refund resource in it) I thought KSPR should save my money, not move them  there and back

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.

Edited June 4, 2021 by Lisias
tyops!

[Warro]

@Lisias I've got best result ever - this was empty pod's(1488funds in editor) instant recovery:

Who stole my money?
It's heavy modded install, log right now is already 28Mb (game still running). I'd better rerun short test with just launch-instarecovery, but that needs some time :)
P.S. By the way - it was just the same pod like on screenshot before, just without Jeb that time, but the price changed - 1488 vs 1523 before. How and why?!?

Edited June 4, 2021 by Warro

[Lisias]

39 minutes ago, Warro said:

@Lisias I've got best result ever - this was empty pod's(1488funds in editor) instant recovery:
Who stole my money?
It's heavy modded install, log right now is already 28Mb (game still running). I'd better rerun short test with just launch-instarecovery, but that needs some time :)

I will need the craft file and the KSP.log at least, otherwise I can't help!

 

39 minutes ago, Warro said:

P.S. By the way - it was just the same pod like on screenshot before, just without Jeb that time, but the price changed - 1488 vs 1523 before. How and why?!?

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)

[Warro]

@Lisias Yes, 1523 vs 1488 is because no kerbal in the second variant.
https://dropmefiles.com/DeR1t - Ksp.log (zip)  - load save, launched pod end recovered immediately (1488 in editor/ 588 refund)
https://dropmefiles.com/akD5E  - Craft file (empty MK1 pod without kerbal)

Edited June 4, 2021 by Warro

[Lisias]

4 hours ago, Warro said:

@Lisias Yes, 1523 vs 1488 is because no kerbal in the second variant.
https://dropmefiles.com/DeR1t - Ksp.log (zip)  - load save, launched pod end recovered immediately (1488 in editor/ 588 refund)
https://dropmefiles.com/akD5E  - Craft file (empty MK1 pod without kerbal)

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.

 

[Warro]

@Lisias I'd not bother you if the KSPRecall was not installed. It is, KSP-Recall-0.2.0.0, but I guess something goes wrong.
Sorry, I don't have GitHub account.
Another attempt to share files:
https://ufile.io/7vjsndpr  - Ksp.log (zip)
https://ufile.io/nrhhfq61  - Craft file

[Lisias]

4 hours ago, Warro said:

@Lisias I'd not bother you if the KSPRecall was not installed. It is, KSP-Recall-0.2.0.0, but I guess something goes wrong.
Sorry, I don't have GitHub account.
Another attempt to share files:
https://ufile.io/7vjsndpr  - Ksp.log (zip)
https://ufile.io/nrhhfq61  - Craft file

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.

Edited June 5, 2021 by Lisias
(sigh) moar tyops

[Warro]

@Lisias Your answer made me feel quite a bit of pain in the rear... GameData is ~6.3 Gb and loading time is way too big to check mods one-by-one...
But please confirm  -  the behavior when KSPR add 900 funds to the 600-funds-overall detail at launch was intended by design and so can't be call a bug? I thought that it should only alter funds on recovery, not at launch.
Or is this situation result of some mod interaction goes wrong?

[Lisias]

1 hour ago, Warro said:

@Lisias Your answer made me feel quite a bit of pain in the rear... GameData is ~6.3 Gb and loading time is way too big to check mods one-by-one...

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.

 

1 hour ago, Warro said:

But please confirm  -  the behavior when KSPR add 900 funds to the 600-funds-overall detail at launch was intended by design and so can't be call a bug? I thought that it should only alter funds on recovery, not at launch.

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,

 

1 hour ago, Warro said:

Or is this situation result of some mod interaction goes wrong?

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

Edited June 5, 2021 by Lisias
better phrasing

[Warro]

@Lisias Our conversation has lead me to one thought - to check what and where was defined with prices in craft file, and it looks like I've found my 900 funds: KIS.evapropellant (dryCost = 250) and KIS.electricScrewdriver (dryCost = 650). They are in the craft without kerbal, but probably absent on recovery (no kerbal-no inventory), and maybe even on launch (I don't know when and how KIS adds inventory) I'd probably should have checked overall funds to compare, how much did the launch really costed.
Will investigate further - should have checked something not only without resources, but even without inventories at all.

[Lisias]

15 minutes ago, Warro said:

@Lisias Our conversation has lead me to one thought - to check what and where was defined with prices in craft file, and it looks like I've found my 900 funds: KIS.evapropellant (dryCost = 250) and KIS.electricScrewdriver (dryCost = 650). 

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