[1.4.3 <= KSP <= 1.12.5] KSP Recall - 0.5.0.2- 2024-0521

[Gotmachine]

7 hours ago, Lisias said:

But they will not work properly, AFAIK, for modules that change things at runtime, as Pay for Play.

Yes they will. ProtoPartSnapshot.moduleCosts is recomputed every time the craft is unloaded. It is how recovery costs were computed pre 1.11.
And nothing has changed on that side, the KSP 1.11 issue is because when refactoring the recovery code to account for recovery costs of parts stored in inventories, Squad just forgot to apply it.

8 hours ago, Lisias said:

Because, potentially, every part have custom modules that calculate the costs differently. Doing this way the Refunding costs will be echoed on the savefile, and where it can be audited and fixed if needed.

That's my point. Your are reinventing the wheel for nothing. Stock already does it correctly, the result is readily available for you to use in ProtoPartSnapshot.moduleCosts.

8 hours ago, Lisias said:

So an external and minimally intrusive (from the code point of view) solution is preferable.

That's my other point. Your solution is intrusive and messy. I've given you a code stub on github that fixes the issue in a much more cleaner way and that doesn't rely on any reverse engineering or reflection use, I don't know why you keep insisting on that.

8 hours ago, Lisias said:

I need to cope with the fact that other people are modding things around here, and sooner or later this solution may stomp on someone's toes.

Your solution has much more potential for side issues and unwanted interactions.

8 hours ago, Lisias said:

I DON'T KNOW what's happening inside KSP as I didn't reverse engineered it as requested by Forum Rules.

If that where true, nobody would be able to mod anything. That rule is silly.
We have almost zero documentation on what the KSP publicly available classes and members are doing.
Doesn't matter how you do it. Be it by analyzing and experimenting, or by decompiling the KSP assembly, in the end the act is the same : you are figuring out the KSP code inner working, which is an act of reverse engineering.
This being said, this rule exists for valid legal technicalities, we all understand that, and can be smart about it and do whatever we need to in private to make great mods for our beloved KSP.

[Lisias]

2 hours ago, Gotmachine said:

Yes they will. ProtoPartSnapshot.moduleCosts is recomputed every time the craft is unloaded. It is how recovery costs were computed pre 1.11.

And how it's computed on 1.11?

 

2 hours ago, Gotmachine said:

And nothing has changed on that side, the KSP 1.11 issue is because when refactoring the recovery code to account for recovery costs of parts stored in inventories, Squad just forgot to apply it.

Good to know. However, I didn't knew at that time, and worked with whatever I had on hands relying the less I can on any related internal KSP mechanism that should be considered suspect at that time.

 

2 hours ago, Gotmachine said:

That's my point. Your are reinventing the wheel for nothing. Stock already does it correctly, the result is readily available for you to use in ProtoPartSnapshot.moduleCosts.

I reinvented the "wheel" because I didn't trusted the wheel KSP was giving me. So instead of spending time (what I didn't had) on acquiring by myself all the details you provided now, I rewrote that part of the "wheel" (essentially about 15 to 20 lines of code) and called it a day. All the remaining code was already written on other workarounds, so this was the fastest way out of the mess at that time.

 

2 hours ago, Gotmachine said:

That's my other point. Your solution is intrusive and messy. I've given you a code stub on github that fixes the issue in a much more cleaner way and that doesn't rely on any reverse engineering or reflection use, I don't know why you keep insisting on that.

Messy, yes. Intrusive? Nope. I added a resource and a module, exactly as every Add'On do to add a feature.

The reflection was being applied on my resource, that resource is not used by anyone else, and no code are being injected on any other place.

Doing it on a Module was the easiest way out of the problem at that time, and probably it still is - that stub you gave me on github need to be coded, tested and checked. The messy code I have now is already coded, tested and checked by the people that reported the problem.

You see, there's a lot of man-hours already spent on the messy solution. I see no reason to throw it away and put a new code on the circuit to be tested again, unless the solution is proven to need more work than the work already spent on it (including testing by third parties).

Until the moment, problems are being solved by applying patches instead of publishing new code.

You are the one insisting on rewrite a working solution just because you find it "messy" (not arguing about being messy or not).. Give me a compelling reason to throw away my testers' time and efforts, and I will code a new solution. But until there, things will stay as it is for while, as I have no enough time to do the other things I have to do, not to mention the people that reported and tested the solution until the moment.

That said, I'm not telling you that your solution is not better. It appears to be. It just happens that it's not proven to be best enough to justify waving some other important things I need to do.

A good enough solution now is better than an optimum solution next week.

 

2 hours ago, Gotmachine said:

Your solution has much more potential for side issues and unwanted interactions.

Prove your point and I will listen. In the mean time, small MM patches can work around the current ones without the need of new code.

 

2 hours ago, Gotmachine said:

If that where true, nobody would be able to mod anything. That rule is silly.

I agree.  But it's the rule, and sillier rules was already enforced before - I just don't wanna take risks on this.

 

2 hours ago, Gotmachine said:

We have almost zero documentation on what the KSP publicly available classes and members are doing.

I agree.

 

2 hours ago, Gotmachine said:

Doesn't matter how you do it. Be it by analyzing and experimenting, or by decompiling the KSP assembly, in the end the act is the same : you are figuring out the KSP code inner working, which is an act of reverse engineering

It matters. Not everybody is an North-American living under North-American legal system.

There's a concept called "clean room design". This is legal on every country I'm aware of, and it's what I'm doing for coding my add'ons.

Decompiling the KSP Assembly it's legal on North-America (as far as I know), but it's not on some other countries. Check about the TRIPS Agreement. So I will not do it (or admit I did).

 

2 hours ago, Gotmachine said:

This being said, this rule exists for valid legal technicalities, we all understand that, and can be smart about it and do whatever we need to in private to make great mods for our beloved KSP.

I agree. But different countries have different legal technicalities - so I decided to err to the safest side. Someone decides to mess with me on my country, I will spend money defending myself - my country is signatory of the TRIPS Agreement and it trowed my legal system on what we call "juridical insecurity" (something specially tricky on countries under the Roman Law system).

I just don't want to take the risk, even by being pretty small.

Edited March 22, 2021 by Lisias
Tyops, as usulla.

[Gotmachine]

2 hours ago, Lisias said:

A good enough solution now is better than an optimum solution next week.

There it is, a better solution, "now", that took me 2 hours to make and doesn't have any performance impact (contrary to your solution) nor unpredictable side effects : https://gist.github.com/gotmachine/bb8f840eb36809a9f74b626eb8ccbfbb

Here is the dll download for testing : https://oshi.at/Lfimhc

Edited March 22, 2021 by Gotmachine
added dll download

[Lisias]

20 hours ago, Gotmachine said:

There it is, a better solution, "now", that took me 2 hours to make and doesn't have any performance impact (contrary to your solution) nor unpredictable side effects : https://gist.github.com/gotmachine/bb8f840eb36809a9f74b626eb8ccbfbb

Here is the dll download for testing : https://oshi.at/Lfimhc

Good, thank you.

When the people that tested my worse solution try it and tell me that yours works, then I will switch to your solution.  I will reach them in private.

Until there, I will stick with what they tested for me until this moment.

-- -- -- POST EDIT -- -- --

One of the beta testers confirmed the fix on a minimal test case of him (the one he cares), and he confirmed that the thing works (unsurprisingly). Also, unsurprisingly, he kinda complained that there's no visual cues from the fix happening - the Dialog shows the current, wrong values - the correct value is given back tough.

So, your fix is not auditable and does not gives the user a visual cue that it's working. I think we need to improve that a bit to be a full replacement for the current, "worst and messy", solution.

I will give this a shot as RL allows.

Edited March 23, 2021 by Lisias
post edit

[Krazy1]

14 hours ago, Gotmachine said:

Here is the dll download for testing : https://oshi.at/Lfimhc

MalwareBytes is blocking this site. Could you mirror it? (Sorry, not going to unblock it)

[DarthPointer]

On 3/22/2021 at 7:16 PM, Lisias said:

One of the beta testers confirmed the fix on a minimal test case of him (the one he cares), and he confirmed that the thing works (unsurprisingly). Also, unsurprisingly, he kinda complained that there's no visual cues from the fix happening - the Dialog shows the current, wrong values - the correct value is given back tough.

To make the things clear: wrong numbers are displayed in the "total vessel cost" of stock's recovery report only in case of negative cost change from modules. Have not tested if it is the case if overall change is negative or it gets inconsistent even if only some of the modules bring negative change regardless the sign of sum.

@Gotmachine pin-n-ng, I guess I better make sure you are notified.

[AccidentalDisassembly]

Think I may have discovered an issue with Recall - it *seems* to be connected to asteroids. Went on an asteroid-grabbing mission, grabbed asteroid, brought it back to Kerbin... can't revert to the space center. Bunch of exceptions from Recall...

Log here: https://www.dropbox.com/s/igyykbmx6m8q1dj/KSPlog_recallexceptions.log?dl=0

[Hohmannson]

nvm, Lisias did a better one

 

Edited March 24, 2021 by Hohmannson
lisias responded with a cleaner solution

[Lisias]

4 hours ago, AccidentalDisassembly said:

Think I may have discovered an issue with Recall - it *seems* to be connected to asteroids. Went on an asteroid-grabbing mission, grabbed asteroid, brought it back to Kerbin... can't revert to the space center. Bunch of exceptions from Recall...

Log here: https://www.dropbox.com/s/igyykbmx6m8q1dj/KSPlog_recallexceptions.log?dl=0

I'm far from my development computer by now, so I made this kind from heart (I don't have 1.11 on anything else).

Check if it solves the issue, I will double check tomorrow.

@PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleCargoPart]]
{
	-MODULE[Refunding],* { }
	-RESOURCE[RefundingForKSP111x],* { }
}

@PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleAsteroid]]
{
	-MODULE[Refunding],* { }
	-RESOURCE[RefundingForKSP111x],* { }
}

@PART[*]:HAS[@MODULE[Refunding],@MODULE[ModuleComet]]
{
	-MODULE[Refunding],* { }
	-RESOURCE[RefundingForKSP111x],* { }
}

@PART[*]:HAS[@MODULE[Refunding],@MODULE[KerbalEVA]]
{
	-MODULE[Refunding],* { }
	-RESOURCE[RefundingForKSP111x],* { }
}

A new Recall release will be issue before the weekend, I will a fix for this on it (together the Fuel Switches one).

--- POST EDIT ---

1 hour ago, Hohmannson said:

Hope it will be that easy.

https://getyarn.io/yarn-clip/82b6238b-1556-4398-a10b-5db598900e02

-- -- -- POST EDIT -- - -- 

@Hohmannson, you ended up finding a bug... I forgot to correctly implement the deactivation code on Refunding. The present code will prevent it from running until he vessel is copied, saved or recovered - situations where I forgot to check if the thing is disabled and prevent the Synchronous Update...

Well, it will be fixed on the next release.  

Edited March 24, 2021 by Lisias
post edit

[Hohmannson]

3 hours ago, Lisias said:

prevent it from running

The PAW button wasn't working and my "soft" patch too? Well, then it wasn't that useless 

[Lisias]

ANNOUNCE

KSP-Recall 0.0.7.7 is on the Wild, featuring:

• An improved Refunding  (hopefully) working on Fuel Switches and other add'ons that mangle the resources of a part.
• Some general small fixes and improvements

Known Issues:

• KSP-Recall 0.0.7.7 changed a bit how Refunding works, and in at least one situation a craft file created with the previous KSP-Recall release was loaded with the wrong prive on the VAB/SPH, leading to wasting funds no launching it.
  • Changing anything on the craft will trigger a recalculation, and the price will be corrected.

---

-- -- -- 

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. (Indefinitely delayed due a problem on uploading)
• SpaceDock (and CKAN users). Right now

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

Edited March 29, 2021 by Lisias
Cureseforge iIndefinitely delayed due a problem on uploading

[Gotmachine]

On 3/23/2021 at 5:22 PM, DarthPointer said:

To make the things clear: wrong numbers are displayed in the "total vessel cost" of stock's recovery report only in case of negative cost change from modules.

My mistake. In the gist I posted, on line 99, the two "> 0.0" conditions should be "!= 0.0".

[Lisias]

In the mean time, KSP Recall 0.0.7.7 is working fine (hopefully at least!) and it's available on GITHUB for the early adopters.

Edited March 27, 2021 by Lisias
hopefully...

[Beetlecat]

3 hours ago, Lisias said:

ANNOUNCE

KSP-Recall 0.0.7.7 is on the Wild, featuring:

• An improved Refunding  (hopefully) working on Fuel Switches and other add'ons that mangle the resources of a part.
• Some general small fixes and improvements

I had a hilarious moment last where a wing developed a "refunding leak" with Oh Scrap!

Yup, not gonna get my deposit back on *that* craft when I return it to the rental agency.

I'll try this newer version out to see if that's still a (potential) issue.

Edited March 27, 2021 by Beetlecat

[Krazy1]

Just removed 0.0.7.5 and then loaded a ship in VAB and it's spamming the KSP log:

Spoiler

Node 'Refunding' found in loaded data, but 'TweakScale' is defined in prefab.
Looking for Refunding in other indices...
[WRN 12:01:39.524] ...no Refunding module found on part definition. Skipping...
[WRN 12:01:39.525] [Part]: PartModule indexing mismatch at pointyNoseConeA, index 3.
Node 'Refunding' found in loaded data, but 'TweakScale' is defined in prefab.
Looking for Refunding in other indices...
[WRN 12:01:39.525] ...no Refunding module found on part definition. Skipping...
[WRN 12:01:39.525] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.525] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.526] [Part]: PartModule Refunding at strutConnector, index 4: index exceeds module count as defined in cfg.
Looking for Refunding in other indices...
[WRN 12:01:39.526] ...no Refunding module found on part definition. Skipping...
[WRN 12:01:39.526] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.526] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.528] [Part]: PartModule Refunding at strutConnector, index 4: index exceeds module count as defined in cfg.
Looking for Refunding in other indices...
[WRN 12:01:39.528] ...no Refunding module found on part definition. Skipping...
[WRN 12:01:39.528] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.528] Could not create PartResource of type 'RefundingForKSP111x
[WRN 12:01:39.529] [Part]: PartModule indexing mismatch at basicFin, index 2.
Node 'Refunding' found in loaded data, but 'TweakScale' is defined in prefab.
Looking for Refunding in other indices...

Spoiler

[ERR 12:02:14.752] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.752] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.901] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.901] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.902] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.902] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.902] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.902] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.902] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

[ERR 12:02:14.988] [ShipTemplate]: No Resource definition found for RefundingForKSP111x

I'm manually removing dozens of these in a few recent .craft files:

Spoiler

MODULE
    {
        name = Refunding
        isEnabled = True
        stagingEnabled = True
        EVENTS
        {
        }
        ACTIONS
        {
        }
        UPGRADESAPPLIED
        {
        }
    }
    RESOURCE
    {
        name = RefundingForKSP111x
        amount = 0
        maxAmount = 1
        flowState = True
        isTweakable = False
        hideFlow = True
        isVisible = True
        flowMode = Both
    }

Hope that fixes them. 

[Lisias]

4 minutes ago, Krazy1 said:

Just removed 0.0.7.5 and then loaded a ship in VAB and it's spamming the KSP log

Yep. Once you install a Add'On (any add'on) and create crafts, onde you desinstall the add'on (any add'on), you will get exactly this log spam.

This happens with all add'ons on KSP, being KSP-Recall just one of them.

 

5 minutes ago, Krazy1 said:

I'm manually removing dozens of these in a few recent .craft files:

No need to manually remove them. Loading them and saving them will do the same, including on running savegames.

As with every other add'on on KSP, by the way. KSP-Recall is not different from anything else.

 

7 minutes ago, Krazy1 said:

Hope that fixes them. 

To tell you the true, you are breaking them.

KSP-Recall only install the Modules you need on your installment, so by not using them you are getting back the problems you had before installing it.

Be sure to do not use any add'on that changes the cost of a part while playing Career.

[Krazy1]

37 minutes ago, Lisias said:

No need to manually remove them. Loading them and saving them will do the same, including on running savegames.

That's a relief. One craft had "refund" 171 times 

Well, I was having problems with stackable parts not stacking in cargo storage again. I'll try to see why the patch wasn't working now. 

[Lisias]

On 3/28/2021 at 5:58 PM, Krazy1 said:

That's a relief. One craft had "refund" 171 times 

You will have one Refund Module for each (supported) part. Refund works on the part it's installed, and only on it - so any problem we may get on it will be easily solved on the field by a MM patch (or by you manually deactivating it on the Editor).

 

On 3/28/2021 at 5:58 PM, Krazy1 said:

Well, I was having problems with stackable parts not stacking in cargo storage again. I'll try to see why the patch wasn't working now. 

That was a problem on previous Recall releases because Stackable parts can't have "State" (ie, something that could make a part different from other of the same type, as fuel: one part may be empty, other may be full), and I didn't realised that until someone reported the problem. I solved this by preventing Refund to be patched on parts that have ModuleCargoPart , the stock module that stackable parts should have. This was fixed on 0.0.7.6, IIRC. (I just fired up 1.11.2 with Recall 0.0.7.6 and the stackable parts are being stacked allright)

In time....

 -- -- -- METAR -- -- -- 

Curseforge will not be updated for some time, as I'm facing problems on uploading the release - the site refuses my zip complaining about a "invalid JSON". I opened a ticked, but until this is solved by Overworlf, KSP-Recall will not be updated on Curseforge.

Curseforge problem fixed.

Edited March 30, 2021 by Lisias
Curseforge problem fixed.

[Krazy1]

10 minutes ago, Lisias said:

I didn't realised that until someone reported the problem

Right - that was me. And the patch you provided was and is still working. I figured out the issue I saw - no problem. The long story- I saved a craft with 2 Ant engines in cargo not stacked, then later applied the MM patch, then reloaded the craft and tried to stack those 2 Ants... that didn't work. So I just removed them and replaced with "fresh" Ants and they do stack.  Makes sense now.

[Krazy1]

Sorry, I was lazy and waited for the CKAN 0.0.7.7 release. I removed the MM patch for 0.0.7.5 BTW. I got about 200 NREs on parts on the first load. I just went to the main menu and exited. Example:

Spoiler

[LOG 17:09:28.353] PartLoader: Compiling Part 'Squad/Parts/Command/mk1pod/mk1Pod/mk1pod'
[ERR 17:09:28.357] Module Refunding threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at KSP_Recall.Refunds.Refunding.RestoreResource () [0x00057] in <826af266ea6e42c19f19ea13d43542a7>:0 
  at KSP_Recall.Refunds.Refunding.OnLoad (ConfigNode node) [0x00066] in <826af266ea6e42c19f19ea13d43542a7>:0 
  at PartModule.Load (ConfigNode node) [0x001ab] in <06f13185617646e5bc801baeab53ab75>:0 

[LOG 17:09:28.363] PartLoader: Part 'Squad/Parts/Command/mk1pod/mk1Pod/mk1pod' has no database record. Creating.
[LOG 17:09:28.363] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes.
[LOG 17:09:28.365] DragCubeSystem: Creating drag cubes for part 'mk1pod'

I didn't see a pattern of why some parts had this error and some did not. I tried again and it did the same thing. 

KSP log

It passed the sanity check...

Spoiler

[LOG 17:10:20.284] [KSP_Recall] INFO: SanityCheck Concluded : 492 parts found ; 0 parts using Resourceful ; 0 parts using Driftless ; 0 parts using Attached ; 0 parts using ChillingOut ; 0 show stoppers detected .

UPDATE: I just ignored the errors and everything seems OK. vOv

Edited March 31, 2021 by Krazy1

[Dodge]

Just tested this with 1.11.2, it is working when I recover directly, but when I recover from space center,  or using FMRS, the "refund" part is still 0. I guess I can bypass the space center recovery, but is there a plan to support FMRS somehow?

[Lisias]

On 3/31/2021 at 5:43 AM, Dodge said:

Just tested this with 1.11.2, it is working when I recover directly, but when I recover from space center,  or using FMRS, the "refund" part is still 0. 

Humm... I missed the Space Center recovering Use Case. It will probably cover the FMRS Use Case too...

Thanks for the report, I will try to get it fixed by the WeekEnd!

-- -- POST EDIT -- -- 

Yep... The Refunding doesn't works when the vessel is on Rails. Fix appears to be simple, trying it today. Wish me luck!

-- -- POST POST EDIT -- -- 

Incredible - I was typing the last post edit when I got a call with an emergency on a client. Incredible!  

-- -- POST POST POST EDIT -- -- 

Thats the thing: the GameEvents.OnVesselRecoveryRequested event is only fired when the craft being recovered has the focus.

When you recover it from the Space Center, from the Tracking Stating and from FMRS, that Event is not called - so my PartModule failed on recalculate the costs.

So my clever trick to prevent some spamming had failed, and I really need to spam the Refunding Resource on evert part that appears to need it, as there's no real standard way to detect when the part is being recovered.

Fortunately, until the moment every time the craft is in the imminence of being recovered, the Save callback is summoned. So I have a pretty & cozy place to shove the Refunding process without having to worry about every single possible way a craft is recovered on the game. What reverted the solution to my initial approach, recalculating this thing everywhere instead of trying to being smart and only doing it when the craft was being recovered.

As I said before, I'm not the only one modding around here, and one size does not fits all. 

TL;DR: The overall solution is being reworked to be less "smart". I'm currently tackling down some small glitches (re)introduced by the change, then I will test the thing on FMRS to see what happens.

There's a good change to have a new Release before the WeekEnd (famous last words...)

-- -- -- POST POST POST POST EDIT -- -- -- 

Yeah. "Lucky". (sigh)

That "Save" I detected was being triggered by FMRS. Without it, recovering vessels from the Space Center or Tracking Station does not triggers a PartModule.Save. So I kinda back to square one on this.

Well, there're some more options to explore....

Edited April 1, 2021 by Lisias
post post post edit

[Lisias]

NOTAM

Cooked a way to allow correctly recovering of funds when the recovering is made from Space Center or Tracking Station (or anywhere else). The current fix should work with FMRS and Stage Recovery too (still to be tested).

My problem now is to overcome the limitation on ModuleCargoPart , that doesn't allows parts with resources to be Stackable.

The current workaround is terribly naive, I just don't Refund on them. The second less naive solution would be to avoid patching Refund on parts with ModuleCargoPart and that also have no resources, but that would not improve the situation too much.

The ideal solution I'm pursuing now is to try to detect when the part is stored or in the imminence of being stored and then remove the Refunding Resource from it, and applying the Resource back when the part is removed from storage: the metadata is stored on the Refunding Module and it's persisted on saving the craft, so we can get rid of the Refunding Resource at any time, and then apply it back when needed.

This will not solve all use cases (as recovering stacked parts with IPartCostModifier modules ), but it will allow these parts to be correctly refunded when recovered in use - unless, of course, I manage to trick the code to inject a Resource on a stored part without screwing up KSP's guts

[kcs123]

7 hours ago, Lisias said:

 

My problem now is to overcome the limitation on ModuleCargoPart , that doesn't allows parts with resources to be Stackable.

Hmmm. How about doing oposite ? Allow to parts be stackable only if their resources are completely empty. That way all of allowed stackable parts will be identical and no need to worry about resource costs. Also no need to track down each part exact properties. Only one set of properties would be required, that could improve performace for a bit too.

[Lisias]

42 minutes ago, kcs123 said:

Hmmm. How about doing oposite ? Allow to parts be stackable only if their resources are completely empty. That way all of allowed stackable parts will be identical and no need to worry about resource costs. Also no need to track down each part exact properties. Only one set of properties would be required, that could improve performace for a bit too.

The problem is not resources, but the "Meta Resource" I use to induce KSP into behaving while recovering costs.

Initially, I thought things would be "easy" (famous last words) due OnVesselRecoveryRequested  - the perfect solution, the vessel is communicated she is going to be recovered, so this is the perfect point to inject the needed Meta Data on the circuit.

Problem: it is only called on vessels that are unpacked - obviously. (sigh). It's the reason it was failing when you recover the vessel from Space Center and Tracking Station, everything is packed on these scenes.

So I need to be sure to inject the "Meta Resource" preemptively, so if the worst happens, the "Meta Resource" is there. But that screwed up the ModuleCargoPart stackable feature - and with people modding the game and injecting ModuleCargoPart on everything, this will be a hell of a problem.

My current shot, and I'm going to test this now, is to apply the "Meta Resource" on packing and remove it on unpacking. I hope (Faith Programming, baby!!  Developing on KSP made me a man of Faith!) that whatever check is done while stacking things, it's done with the part unpacked. Of course this will almost surely prevent the stacked part to be correctly recovered, as the "Meta Resource" will be probably forgotten on stacking, but at least I keep these parts recoverable on every other situation.

Since we are here, I wonder how Recall is behaving on KIS (got no time to test it). KIS way to cope with this is way better, you whitelist a module and KIS is done - it's up to the whitelisted module to find his way out of the mess. This must cope with Recall pretty well - but, as always, I need to test to confirm.