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

[Warro]

@Lisias Did a quick and dirty check  - I guessed right - probably one of VAB staff is stealing KIS equipment. If I remove items from KIS inventory, all costs are ok, 588 launched, 588 recovered.

BUT: when Jeb was launched with untouched inventory and recovered, items from inventory were not in recovery list.  And misterious disappearance of equipment should be KIS problem, BUT(yes, again) the overall sum was still 1488 funds, cause KSPR adds missing 900 fund in "Refund" resource way, which leads to possible abuse, I guess. If the items will be transferred to other place, but the KSPR still add funds.... You can imagine. That probably should not work that way. Will do more test and then update the post.
UPD: false alarm - if items were "lost" during flight - no reward, but when I launched pod+kis inventory container and moved items to it and then recover - items were not in list, but there was refunds for them.  I  even took item from KIS inventory, dropped on ground and than store to stock - still no item in recovery list, but that time price for pod increased by price of item in stock inventory. Good news - our funds are safe, bad news - VAB staff continues to steal items from recovered craft's inventories. You should name that part of mod "insurance"

Edited June 5, 2021 by Warro

[Lisias]

50 minutes ago, Warro said:

@Lisias Did a quick and dirty check  - I guessed right - probably one of VAB staff is stealing KIS equipment. If I remove items from KIS inventory, all costs are ok, 588 launched, 588 recovered.

BUT: when Jeb was launched with untouched inventory and recovered, items from inventory were not in recovery list.  And misterious disappearance of equipment should be KIS problem, BUT(yes, again) the overall sum was still 1488 funds, cause KSPR adds missing 900 fund in "Refund" resource way, which leads to possible abuse, I guess. If the items will be transferred to other place, but the KSPR still add funds.... You can imagine. That probably should not work that way. Will do more test and then update the post.

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!

[Warro]

@LisiasThanks for the support, I've already found, than nothing wrong is with recovery, just confusing moment of recovery inventory content via refund resource. So my install maybe have problems, but unrelated to refunding.
Funny thing - you did just the same trick with screwdriver and KIS container, that I've done. Screenshot made me stuck for a second (how there can be screen what I was doing if I didn't make one?) but then I saw the difference - my pad is still lvl. 1 and Jeb had helmet off. Thanks again for help finding the truth, that is "out there"

[Krzeszny]

@Lisias About that bug, I think you would get the same results by just spawning any expanding container EDIT: except for the ore container from Baha ELP Redrilled (no scale tweaking needed), but here are the files:

https://drive.google.com/file/d/1UnU6AzF9ZC6I1SCPkhTuDUs63S4raeQj/view?usp=sharing

The expected result is as follows:

• the parts list shows that this part costs 0.00
• the editor shows that the cost is negative 37,440 when placed down
• when you fill the container, the editor shows 0.00
• when you launch this part as it's empty, you get money
• when you recover it, you lose money 

I will stress again that this is stock behavior. All fuel tank configs provide ONLY the "wet cost", whether stock or modded, and the game calculates the dry cost from the cost provided in the configs.

This container's cost is negative because its "wet cost" in the config is the dry cost, and that's wrong. The config is wrong.

Perhaps we have a misunderstanding, but I hope it'll be sorted out eventually.

Edited June 8, 2021 by Krzeszny
all containers except for ore

[Lisias]

11 hours ago, Krzeszny said:

The expected result is as follows:

• the parts list shows that this part costs 0.00
• the editor shows that the cost is negative 37,440 when placed down
• when you fill the container, the editor shows 0.00
• when you launch this part as it's empty, you get money
• when you recover it, you lose money 

Well, if the problem happens already on the Editor, you was right: KSP is playing no role on it. Yet.

 

11 hours ago, Krzeszny said:

@LisiasI will stress again that this is stock behavior. All fuel tank configs provide ONLY the "wet cost", whether stock or modded, and the game calculates the dry cost from the cost provided in the configs.

This container's cost is negative because its "wet cost" in the config is the dry cost, and that's wrong. The config is wrong.

I detected that the  Baha ELP Redrilled has a old version of Interstellar Fuel Switch installed. Did you updated it to the latest?

 

11 hours ago, Krzeszny said:

Perhaps we have a misunderstanding, but I hope it'll be sorted out eventually.

Yep, I'm pretty sure I misdiagnosed the problem - or at least, part of it. But since Baha ELP makes use of IFS, it's prone to the problem I described on the its thread.

But I found odd that such a bug would had passed undetected since the last revision published, yet for KSP 1.5.1 . So I decided to test first on KSP 1.5.1 (I have Test Beds for every KSP version I ever managed to - legally - download from Steam) to see what I get.

KSP 1.5.1 loads faster on my MacPotato anyway , so it will save me some time anyway.

And it worked fine! 

Including launching it and recovering it immediately after.

This 1.5.1 test bed had only Module Manager and the contents of the latest distribution zip from SpaceDock.

So we can rule out a problem on the configs. My current guess is that you need to use the latest Interstellar Fuel Switch in order to use these parts. I'm building a 1.11.2 test bed and I will come to you as soon as I check this hypothesis.

-- -- POST EDIT -- -- 

On KSP 1.11.2, by using the latest Interstellar Fuel Switch in place of the old one embedded on the distribution file (meant for KSP 1.5.1, as it appears), everything worked as expected.

-- -- POST POST EDIT -- -- 

Ha! Found it! I was using the wrong Expanding Container. The problem is happening on the RocketParts one!

The behaviour is exactly the one described by @Krzeszny. And his diagnosis was accurate, it's indeed something wrong on the config file.

Weirdly enough, I gone trough the historic both from the Baha ELP (the 1.2 release from BahamutoD) as well from the Community Resource Pack (a hard dependency for this part), and the problem is really on the Part config, as in every release of CRP the price for the RocketPart resource is defined and, so, it always had a price.

And, of course, I made the tests on KSP 1.5.1 to be absolutely sure this is not an environmental problem.

Well, this settles the question.  

Edited June 8, 2021 by Lisias
post post edit

[Krzeszny]

7 hours ago, Lisias said:

Ha! Found it! I was using the wrong Expanding Container. The problem is happening on the RocketParts one!

Well yes, but actually no. The problem happens with RocketParts, Metal and Karbonite containers. It's the same problem.

(If Ore wasn't so cheap, it would be happening with the ore container, too.)

I'm glad we got it sorted out.

Edited June 8, 2021 by Krzeszny

[etmoonshade]

Probably an easy bug to find:

If your KSP directory has the word "plugin" in it, you get a Houston error saying that KSP Recall is installed in the wrong place.

The comparison is probably a bit too simple.

[Lisias]

4 hours ago, etmoonshade said:

Probably an easy bug to find:

If your KSP directory has the word "plugin" in it, you get a Houston error saying that KSP Recall is installed in the wrong place.

The comparison is probably a bit too simple.

It's by design. The library that checks if something is installed looks for the DLLs on :

• GameData\AddOn "Root"
• GameData\AddOn "Root"\Plugin
• GameData\AddOn "Root"\Plugins

It's this way because these are the directories where every Add'On published should be installed (I remember checking literally hundreds of add'ons to detect this patterns.

So if you are installing Recall on anywhere else, it's a non supported configuration and so KSP-Recall will pesky you about this error. And, to tell you the true, none of my Add'Ons will work correctly on this configuration.

Or, perhaps, you are using the "Plugin" word (I made this sounds like a swearword! ) outside the GameData hierarchy?

Where is your KSP Root on this context?

[etmoonshade]

5 minutes ago, Lisias said:

It's by design. The library that checks if something is installed looks for the DLLs on :

• GameData\AddOn "Root"
• GameData\AddOn "Root"\Plugin
• GameData\AddOn "Root"\Plugins

It's this way because these are the directories where every Add'On published should be installed (I remember checking literally hundreds of add'ons to detect this patterns.

So if you are installing Recall on anywhere else, it's a non supported configuration and so KSP-Recall will pesky you about this error. And, to tell you the true, none of my Add'Ons will work correctly on this configuration.

Or, perhaps, you are using the "Plugin" word (I made this sounds like a swearword! ) outside the GameData hierarchy?

Where is your KSP Root on this context?

The last situation. The "naughty" word was in the main folder name: E:\KSP Active Installs\Kerbal Space Program - WarpPlugin Test\ (I was testing an issue with KSPI-E on the install.) My assumption was that you're just searching the whole path for the word "Plugin"

 

It's not a huge bug or anything - it was sorted easily by changing the name of the KSP folder - just figured I'd mention it.

[Lisias]

6 minutes ago, etmoonshade said:

The last situation. The "naughty" word was in the main folder name: E:\KSP Active Installs\Kerbal Space Program - WarpPlugin Test\ (I was testing an issue with KSPI-E on the install.) My assumption was that you're just searching the whole path for the word "Plugin"

Damn. No matter how smart you think you are, sooner or later an user will outsmart you.

You are right, I just checked the relevant code. It's terribly naive.... 

Of well.. I will tackle this one down for the next release, to be issued as soon as KSP 1.12.0 hit the streets.

https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/14

Cheers, and thanks for the heads up!

(you see, these pesky small bugs are the ones that usually pile up and ruin our days in the future!!!)

[etmoonshade]

5 minutes ago, Lisias said:

Damn. No matter how smart you think you are, sooner or later an user will outsmart you.

Ouch! Speaking of naughty words...

calling me a user mumble grumble

[Lisias]

NOTAM

KSP 1.12.0 still presents that pesky problem about IPartCostModifer, and so KSP-Recall's Refunding is still needed on it.

Additionally, I found that my quick&dirty solution for Refunding was a bit too much dirty, and ended up helping Unity to screw KSP. (long story made short, Unity is using a trick that is royally screwing up the Garbage Collector, and Refunding will need to be reworked to mitigate the screwage).

The roadmap for the new revision can be found here, and I will work on it ASAP.

 

[Hohmannson]

2 hours ago, Lisias said:

Recall's

Just a little heads-up. 1.12 seems to show us a different version of drifting bug. I get it on moderate slopes in high gravity, when landed on stock legs(LT-2 or something). The more gravity you add in hack gravity cheat - the more it slides. It can be completely stopped by ParkingBrake or similar mods. Kerbals not affected. So, Driftless may need some changes. It's not gamebreaking at all, but just in case.

[Lisias]

ANNOUNCE

KSP Recall 0.2.0.1 is on the Wild, featuring:

• Compatibility to KSP 1.12.0 and updates on the already published fixes.
• Closes issues:
  • #23 Refunding is triggering a nasty memory leak on this.part.Modules.Add
  • #22 Allow Refunding to be used on KSP 1.12.0
  • #21 Unity's spinlocks are bullying the Garbage Collector, and Refunding is not helping on the situation.

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!

P.S:

• @Hohmannson, I ran out of time to check the Drifting bug on 1.12.0. I will try to tackle it down this week.
  • https://github.com/net-lisias-ksp/KSP-Recall/issues/10
• A big THANK YOU to @darthgently for the reports that leaded me to workarounds for two pretty nasty problems Refunding was triggering!

Edited June 29, 2021 by Lisias
All Distribution Channels updated.

[darthgently]

Is there any code in the dlls that might affect the Core Heat ... Shutting Down issue when mining?  I have a miner that was working fine when I had KSP-Recall disabled, but now it constantly overheats even though the reported temps in the PAW are well within range.  Does ChillingOut.dll affect this?  I'm testing without Recall now... inconclusive, disregard

Edited June 30, 2021 by darthgently

[Lisias]

7 hours ago, darthgently said:

Is there any code in the dlls that might affect the Core Heat ... Shutting Down issue when mining?  I have a miner that was working fine when I had KSP-Recall disabled, but now it constantly overheats even though the reported temps in the PAW are well within range.

theoretically, anyone of the recall workarounds induce side-effects- usually DESIRED side-effects that ends-up undoing something wrong on the stock game.

But it's always possible that these side-effects may stomp someone else's toes.

As an example, Refunding and MAS. Refunding theoretically make things right, mimicking Ablate and Electricity to avoid at any cost to influence the physics of the craft. But then MAS freaked out, because by some reason it complains about resources without density (or mass? I forgot) and started to yell on the KSP.log. So I had to add a pretty small amount of density  (or mass) to it, barely above the float precision - so MAS stopped yelling but the values got rounded up by KSP and the net result is the same...

So, yeah. Ideally Squad should fix these issues and render Recall deprecated. This is not a fix, it's a patch to allow coexistence with the bug.

 

7 hours ago, darthgently said:

 Does ChillingOut.dll affect this?  I'm testing without Recall now...

ChillingOut must initialise by brute force some values related to Heat Squad forgot to initialize on the PartModule on a previous KSP release. So any older Parts' config that don't set the values (as they didn't existed at that time or something) just blows up on the very first physics frame due "overheat".

So, yeah, it may be - besides it acts only on the very first few frames of existence of the craft and by zeroing the heat, so I expect the other way around: preventing overheating when it should happen if a mistake happens.

7 hours ago, darthgently said:

Inconclusive, disregard

in a way or another,  the workarounds are engineered to be easily deactivated by the user (via paw) or patch, so it's pretty simple to overrule Recall by doing a patch to remove the ChillingOut from a part if it has SystemHeat.

Assuming it's being installed, of course, because I just realized it's not  being activated on KSP 1.12... So, in essence, what you are experiencing may be exactly the ABSENCE of ChillingOut!

Do a test: force a true value on your local copy of this file:

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

And see what happens...

Edited July 1, 2021 by Lisias
Yep. Tyops!

[Lisias]

On 6/25/2021 at 1:33 PM, Hohmannson said:

Just a little heads-up. 1.12 seems to show us a different version of drifting bug. I get it on moderate slopes in high gravity, when landed on stock legs(LT-2 or something). The more gravity you add in hack gravity cheat - the more it slides. It can be completely stopped by ParkingBrake or similar mods. Kerbals not affected. So, Driftless may need some changes. It's not gamebreaking at all, but just in case.

Are you talking about this?

Sounds like an easy MM patch. I don't see a technical eason not to include this in the next Recall release (to be published as soon as I recover my rig from a disk crash).

This one, however, sounds more like a polemical implementation decision than exactly a bug  - Recall may not be the best place for this one... what do you think?

[Hohmannson]

2 hours ago, Lisias said:

not be the best place

Yeah, looks like just a bit incorrect values in stock parts, if so, and per-part fixes surely don't belong here. Shame i wasn't subscribed to the thread and thus haven't seen it. Best wishes to your computer, hope it will be fine.

[Lisias]

On 7/1/2021 at 4:54 PM, Hohmannson said:

Best wishes to your computer, hope it will be fine.

Dude, do you have an USB crystal ball shoved on your computer or something?

Spoiler

 (sigh)

 

[Cookie0815]

Installed is KSP-Recall v0.2.0.1 (via CKAN).

I also rely on tweakscale for most of my builds (if parts have the module implemented, i mostly prone to use it).

I really don't know, if this has anything to do with the pesky refunding bug mentioned before , but while I'm just trying to wrap my head around all the bugged up things mentioned towards the refunding for parts with zero initial costs, I stumbled over a very annoying FPS-drop (no complete  freeze, the CPU usage rate stays in usual values) with ProceduralFairing-parts (yes they also have zero initial costs), whenever any part gets added below them (i guess it's when the part cost recalculation gets triggered). Once I remove the "bugged" PF-part, FPS returns to normal.

Btw. this doesn't happen with DecouplerShroud (Shrouded Decoupler), which has also zero initial costs.

[Lisias]

10 hours ago, Cookie0815 said:

Installed is KSP-Recall v0.2.0.1 (via CKAN).

I also rely on tweakscale for most of my builds (if parts have the module implemented, i mostly prone to use it).

I really don't know, if this has anything to do with the pesky refunding bug mentioned before , but while I'm just trying to wrap my head around all the bugged up things mentioned towards the refunding for parts with zero initial costs, I stumbled over a very annoying FPS-drop (no complete  freeze, the CPU usage rate stays in usual values) with ProceduralFairing-parts (yes they also have zero initial costs), whenever any part gets added below them (i guess it's when the part cost recalculation gets triggered). Once I remove the "bugged" PF-part, FPS returns to normal.

Btw. this doesn't happen with DecouplerShroud (Shrouded Decoupler), which has also zero initial costs.

I need the full KSP.log published on dropbox or something, otherwise I can't help.

Please also add ModuleManager's Patch Log and the ConfigCache, as this can be helpful once we have a lot of add'ons installed, potentially stomping each other's feet.

— — — POST EDIT — — — 

@Cookie0815, I just did a code review on Refunding looking for a division by zero or something that could be inducing the current thread to die and provoking some spurious processing (like stack dumps) that could affect your FPS, but I found nothing obvious.

So, even by being something on Refunding, I really need your logs to purse this question - I have little to no time for leisure, what to say for modding, and exploratory tests are out of the question - I can't dispose the little time I have these days pursuing problems that I don't know for sure where they are!

I have a new release of Recall on the works, I will delay it a day in the hope I get your log in the mean time.

Cheers!

Edited July 11, 2021 by Lisias
POST EDIT

[Lisias]

ANNOUNCE

KSP Recall 0.2.0.2 is on the Wild, featuring:

• ChillingOut is still needed on 1.12.x series. Reactivating it.
• Some missing logging stats added.

This Release will be published using the following Schedule:

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

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps, as I will have a hell of a Week and can't handle too many issues if something wrong happens.

Cheers!

Edited July 22, 2021 by Lisias
Aborting distribution due mishaps on the release.

[Cookie0815]

On 7/11/2021 at 6:01 PM, Lisias said:

I have a new release of Recall on the works, I will delay it a day in the hope I get your log in the mean time.

I'm really sorry, and I really appreciate your work on this mod (although most users don't see it, as it works in the background, trying to undo the funding and other bugs that Squad created).
I missed out the notification (should check the setting). But I also had not found a proper solution to dump/upload the logfile (I unsubscribed from dropbox after their data leak some years ago - i don't know if i could publish the file on google drive without demanding an google account for the viewers).

With all the slowly trickling in updates (including yours) on mods, I just steer clear of using procedural fairing parts for a while (using SAF instead) and come back to this when the "waters are calmer" - also i always forget to secure the last KSP.log as it gets overwritten with each game start.

[Lisias]

1 hour ago, Cookie0815 said:

I'm really sorry, and I really appreciate your work on this mod

Not a problem, and thank you

 

1 hour ago, Cookie0815 said:

I missed out the notification (should check the setting). But I also had not found a proper solution to dump/upload the logfile (I unsubscribed from dropbox after their data leak some years ago - i don't know if i could publish the file on google drive without demanding an google account for the viewers).

If you have a github account, you can post a comment on this "issue" and just drag and drop a zip file with the logs there. Copy&paste a link from your post here so I can link the logs with the problem easily.

https://github.com/net-lisias-ksp/KSP-Recall/issues/19

 

1 hour ago, Cookie0815 said:

With all the slowly trickling in updates (including yours) on mods, I just steer clear of using procedural fairing parts for a while (using SAF instead) 

Ok!

Eventually I will have some sparing time again, and then I will play a bit with Procedural Fairings. My problem these last weeks is, essentially, absolute lack of time for playing…  

[Lisias]

ANNOUNCE

KSP Recall 0.2.0.3 is on the Wild, featuring:

• Mishaps on the sanity checks were detected and fixed

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). Saturday Night.

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps, as I will have a hell of a Week and can't handle too many issues if something wrong happens.

Cheers!

Edited July 23, 2021 by Lisias
Distribution channels updated.