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

[Gotmachine]

9 hours ago, Lisias said:

Initially, I thought things would be "easy" (famous last words)

Just a reminder that I gave you the easy (and side effect free) solution two weeks ago, and warned you that what you are currently doing is a hacky mess.

[Lisias]

12 minutes ago, Gotmachine said:

Just a reminder that I gave you the easy (and side effect free) solution two weeks ago, and warned you that what you are currently doing is a hacky mess.

Just a reminder that your solution was flawed (so not properly tested, as KSP by the way), that it can't be audited and can't be selectively applied to parts - so any problem on the field can't be worked out.

As I said before, I'm not the only modder in town. Everything I do need to have the impacts on the field measured, need to traceable and need to be selectively deactivated so punctual problems can have an easy fix on the user's machine, without he need to tell them "stop playing until the next release".

I have no interest on providing a solution that can be worst than the problem itself.

Part of it has some merits, though. But still, I need to get through what I'm doing now to know exactly where it can be worst, so I can know exactly the parts that have more value to the solution.

A working hacky mess is better than a nice and elegant solution that is flawed - as your was. You know, we need to test things before shipping them. Have you played KSP lately?

Edited April 2, 2021 by Lisias
tyops! Surprised?

[Gotmachine]

1 minute ago, Lisias said:

your solution was flawed

How so ? I made a small mistake that prevented the UI info from showing when the recovered sum was negative, and gave the fix a few posts earlier.

5 minutes ago, Lisias said:

can't be selectively applied to parts - so any problem on the field can't be worked out.

My solution doesn't need to exclude anything. You are fixing issues that you created yourself.

[Lisias]

7 minutes ago, Gotmachine said:

How so ? I made a small mistake that prevented the UI info from showing when the recovered sum was negative, and gave the fix a few posts earlier.

Well, a flaw.

 

7 minutes ago, Gotmachine said:

My solution doesn't need to exclude anything. You are fixing issues that you created yourself.

Your solution need to trust the cost KSP is giving to you, exactly what I'm not doing. I will not trust a piece of code that is failing on me, and I will not trust blindly another piece of code without understanding what it is doing.

A working hacky mess that I understand and can fix is better than a nice and elegant solution I don't understand and can't fix if something bad happens.

Thank you for your code contribution, but not so much for how you try to push it over. You could be doing a better job on explaining WHY your solution is better and HOW it can fail instead of just whining about how hacky messy mine is.

-- -- -- 

On a side note, I just understood how to TweakScale things before storing them on a Cargo Inventory Part, and having a hint of the problems I can get.

Hardly a bad bargain for the trouble I'm getting now. You know, I DO TEST things before shipping them.

Edited April 2, 2021 by Lisias
yeah. another typo. :/

[Gotmachine]

18 minutes ago, Lisias said:

You could be doing a better job on explaining WHY your solution is better instead of just whining about how hacky messy mine is.

I already explained it. There is a single line of code missing from KSP causing this refund bug, you don't need to rewrite the whole refunding code to make it work. My piece of code add that missing line where it should have been in the less intrusive way possible, and add the same UI feedback as yours by doing UI code without having to spam resources and modules all around. If you don't understand how it work, you know what you have to do, we also already had that discussion.

As to why your solution is worse, the amount of issues that are popping in this thread speak for themselves.

Edited April 2, 2021 by Gotmachine

[Lisias]

3 hours ago, Gotmachine said:

I already explained it. There is a single line of code missing from KSP causing this refund bug, you don't need to rewrite the whole refunding code to make it work. 

And exactly how you are supposed to know that without breaking NDAs ou Forum Rules? 

And exactly what is the alternative to what I'm doing to reach a similar conclusion without breaking Forum Rules?

 

3 hours ago, Gotmachine said:

My piece of code add that missing line where it should have been in the less intrusive way possible

You are not being the less intrusive possible. You are doing exactly the opposite. It's a simple piece of code (granted) that will handle every single part of the game exactly the same way, without the slightest chance of deactivating it on parts where things are going fine, neither considering strange new interactions between older Modules from the Scene and the new Modules from KSP. Things may not behave as you expect, even the present KSP failure on calculating costs may not be consistent - things may be behaving differently on a point of the code from another, depending on who is calling who and when.

You are so focused on the "hacky messy" part of that code of mine that you just are not considering the whole picture. You may have wrote a "better" piece of code under determined point of view, but that code just don't meet non functional requirements I need to met in order to keep this thing minimally safe on a already unsafe running environment.

Things will bork on the field, this is not even a prediction, but a statement of a fact. 80% of what I'm doing know is trying to figure out in advance where and how, and then write a code that could be selectively deactivated where I failed to foresee the problems.

Had you tried to TweakScale things before storing them? Had you checked how the costs are being handled while recovering the craft while flying them? Had you compared with the costs of the same stunt when doing it when the craft is packed? Are you concerned about other PartModules as ODFC and PayToPlay and how they will behave? And what happens if someone store them on an Inventory Part? Are you planning how to support these guys if anything goes wrong?

Well, I do.

 

3 hours ago, Gotmachine said:

and add the same UI feedback as yours by doing UI code without having to spam resources and modules all around.

And THAT'S PRECISELY THE REASON YOUR SOLUTION IS INTRUSIVE. Everybody is being forced to use it, instead of selectively activating ou deactivating it on the parts that may behave differently from what you are expecting.

My solution is messy? Yes. But it's not intrusive, someone need to patch it on the part (and, so, another one can remove it later on another patch). And even after being patched, it still CAN BE DEACTIVATED at runtime by the player without the need to reboot the game. This work even on the improbable hypothesis of the stunt work on a craft and not on another - the user has no need to debug the damned thing to understand what to do, just deactivate the thing where it borks and the player is done with the problem.

 

3 hours ago, Gotmachine said:

If you don't understand how it work, you know what you have to do, we also already had that discussion.

NOW I understand how it work (today I had time to check it - I have a day job, you know?). But I don't understand where it can go wrong, so until there, I can't accept the responsibility to maintain it as it is (and I'm not even mentioning the non functional requirements that it doesn't even scratch).

And you still didn't told me where it may fail.

I'm not telling you your contribution was useless, it was not (you probably solved part of the problem). It only happens that it's not useful enough so I can use it as is.

 

Edited April 2, 2021 by Lisias
My dyslexia is hitting hard today.. :P

[AccidentalDisassembly]

Having an issue I think is related to Recall/Refunding (see log here: https://www.dropbox.com/s/3e4odf1dtmaunko/KSPLog_Refunding.log?dl=0)

In editor, I can't put external fuel ducts between parts - connect the fuel duct on one end, and it won't then connect on the other. just picks up the part again. I don't know if it's related to Refunding, but when looking in the logs, I saw a number of errors that is (I think) equal to the number of parts in this save... Passing along the log in case it's useful, whether or not that's actually related to my editor issue.

[Lisias]

3 hours ago, AccidentalDisassembly said:

Having an issue I think is related to Recall/Refunding (see log here: https://www.dropbox.com/s/3e4odf1dtmaunko/KSPLog_Refunding.log?dl=0)

In editor, I can't put external fuel ducts between parts - connect the fuel duct on one end, and it won't then connect on the other. just picks up the part again. I don't know if it's related to Refunding, but when looking in the logs, I saw a number of errors that is (I think) equal to the number of parts in this save... Passing along the log in case it's useful, whether or not that's actually related to my editor issue.

It appears to be a Fuel Switching... well, switching fuels and overwriting Resourful's one. I had this tackled down already on the HEAD, I'm finishing some tests on FMRS and Vessel Mover to check how the new code behave and I will issue a RC in the next few hours. I will use your log for a more thorough test.

While the RC is being proven on the field, I'll check how I can use part of the gotmachine's code on the Refund solution. Getting rid of the Refund Resource on the part is not a bad thing, but to use this code I need to check how the protovessel handles the PartModule's persisted data. I managing to understand that, the next release will have this solution too, and so the user will be able to select the one that fits best - probably this new one, but who knows? Better safe than sorry.

Edited April 3, 2021 by Lisias
Yeah, tyops! =P

[Dave-Daring]

Sadly this mod breaks Smart Parts Drainex part no longer registers part contents.

[Lisias]

3 hours ago, Dave-Daring said:

Sadly this mod breaks Smart Parts Drainex part no longer registers part contents.

You can deactivate Recall on the parts where it is falling. If everything goes right, I will have a new, slightly better behaving, release in the next hours - the thing is theoretically ready, but I didn't had time to test the new features yet. I will give drainex a try.

In the mean time, I want to point out that Recall sets, correctly, the isDrainable property of the resource as false, so the stock drain valve will not drain your refundings into space. So, on a first glance, it appears to be more a problem on Drainex than exactly on Recall.

But yet, it costs almost nothing to check it myself - a patch preventing the Refund to be active by default when Drainex is used may solve the problem (or not, I need to check Drainex M.O. first).

-- -- POST EDIT -- -- 

Yep, it's more a fault on Drainex than anything, as it is hardcoded to drain everything but ElectricCharge. It will fail on a lot of add'ons too, not only Recal. Users of Community Resource Pack will be specially affected by it.

I suggest you reach the current maintainer and ask him to implement a check to respect the "isDrainable" property of the resources.

The newest still to be release KSP-Recall version survives this problem, as it's less naive and will rebuild its data on the last moment possible before recovering. Hold your horses, the next release is currently in test before being published.

Edited April 3, 2021 by Lisias
post edit.

[Krazy1]

16 minutes ago, Lisias said:

so the stock drain valve will not drain your refundings into space.

However... with Recall 0.0.7.7 when jettisoning ore from a stock ore tank, it does jettison "refunding".

screenshot

[Lisias]

3 minutes ago, Krazy1 said:

However... with Recall 0.0.7.7 when jettisoning ore from a stock ore tank, it does jettison "refunding".

screenshot

I think you found a bug on the drain valve. The Refunding Resource is set to be not drainable - so unless someone change it, it should not be drainable!

Can you send me your ConfigCache and KSP.log?

 

[Krazy1]

1 minute ago, Lisias said:

I think you found a bug on the drain valve.

I'm not using a drain valve. I used the "Jettison Tank Contents" in the tank PAW. 

[Lisias]

4 minutes ago, Krazy1 said:

I'm not using a drain valve. I used the "Jettison Tank Contents" in the tank PAW. 

So  you found a problem on the feature! The Refunding Resource is not drainable. It should be handled exactly as the Electric Charge.

The Jettison Contents is also jettisoning the Electric Charge or the Ablator resource?

Edited April 3, 2021 by Lisias
Ablator is also a resource!

[Krazy1]

IFAIK the only stock resource container that has a "jettison" button on the PAW are on the ore tanks. I can't "jettison" EC. This feature predates Squad making the drain valve a stock part. So now the jettison button on the ore tank is redundant  (could use a drain valve) but they left in the game just to give you a headache now. I guess it uses a completely different method to jettison vs. drain the ore resource.

[Hohmannson]

42 minutes ago, Lisias said:

ettison Contents is also jettisoning the Electric Charge or the Ablator resource

Yes. It's a stock module and it jettisons all resources from the part it's in. I use it to emergency stop SRBs, but it can jettison EC from batteries, yes. And hidden resources too.

Edited April 3, 2021 by Hohmannson

[Lisias]

37 minutes ago, Krazy1 said:

IFAIK the only stock resource container that has a "jettison" button on the PAW are on the ore tanks. I can't "jettison" EC. This feature predates Squad making the drain valve a stock part. So now the jettison button on the ore tank is redundant  (could use a drain valve)

Yes, you can jettison EC.

This is the Ore resource definition:

RESOURCE_DEFINITION
{
  name = Ore
  displayName = #autoLOC_501007 //#autoLOC_501007 = Ore
  abbreviation = #autoLOC_6002103 //#autoLOC_6002103 = Ore
  density = 0.010
  unitCost = 0.02
  flowMode = ALL_VESSEL
  transfer = PUMP
  hsp = 1000
  isTweakable = true
  color = 1,0,1
  volume = 5
  RESOURCE_DRAIN_DEFINITION
  {
    isDrainable = true
    showDrainFX = true
    drainFXPriority = 9
    drainForceISP = 5
    drainFXDefinition = particlesDraining
  }
}

And this is the Refunding Definition:

RESOURCE_DEFINITION
{
    name = RefundingForKSP111x
    displayName = Refunding
    abbreviation = rF
    density = 0
    unitCost:NEEDS[KSPRECALL-REFUNDING] = 1     // No need for the 0.0001 stunt anymore
    unitCost:NEEDS[!KSPRECALL-REFUNDING] = 0    // Eliminates any collateral effect from the Refunding stunt
    hsp = 0
    flowMode = NO_FLOW
    transfer = NONE
    isTweakable = false
    isVisible = true 		// It's set to false on the release, but I set it to be visible for this test
    RESOURCE_DRAIN_DEFINITION
    {
        isDrainable = false
        showDrainFX = false
    }
}

And for the sake of curiosity, this is the Ablator where I took inspiration for creating the Refund Resource:

RESOURCE_DEFINITION
{
  name = Ablator
  displayName = #autoLOC_501008 //#autoLOC_501008 = Ablator
  abbreviation = #autoLOC_6002104 //#autoLOC_6002104 = Ab
  density = 0.001
  hsp = 400
  flowMode = NO_FLOW
  transfer = NONE
  isTweakable = True
  unitCost = 0.5
  volume = 1
  RESOURCE_DRAIN_DEFINITION
  {
    isDrainable = false
    showDrainFX = false
  }
}

You see? Ore is drainable and can be pumped. Ablator and Refundind do not.

So I wrote this patch:

@PART[LargeTank]:FINAL
{
	RESOURCE
	{
		name = Ablator
		amount = 1500
		maxAmount = 1500
	}
	RESOURCE
	{
		name = ElectricCharge
		amount = 1500
		maxAmount = 1500
	}
}

And fired KSP 1.11.2 again. And then triggered the ModuleFuelJettison. Module FUEL Jettison.

And this is what I got on jettisoning the Large Ore Tank:

Expanding the important detail:

I rest my case, Your Honor  : it' a bug on ModuleFuelJettison. It should not be jettisoning resources not drainable neither allowed to be pumped. Please note that Ore can be drained and also can be pumped.

In a way or another, the newest Release, currently on tests, is recalculating the Meta Resource on demand, so I don't expect this to be a problem. But I will test it nevertheless.

Unexpected bugs in KSP are almost a feature by now, as it appears. I think someone must write a proper replacement for the ModuleFuelJettison that respects the resources' definition.

In a way or another, I documented the situation on an issue on the github. #13, how appropriate!

 

37 minutes ago, Krazy1 said:

 but they left in the game just to give you a headache now. I guess it uses a completely different method to jettison vs. drain the ore resource.

It's just a bug on ModuleFuelTank. The headache is not that bad, the soon™ to be released KSP Recall version aims to cope with Fuel Switches, that constantly remove resources from the part. It should fix this issue too. I'll check before releasing it.

 

5 minutes ago, Hohmannson said:

Yes. It's a stock module and it jettisons all resources from the part it's in. I use it to emergency stop SRBs, but it can jettison EC from batteries, yes. And hidden resources too.

Yeah. It caught me with my pants down too, however. 

Edited April 3, 2021 by Lisias
Copy & Paste Error.

[Lisias]

News from the Front

About the current test version of KSP Recall (what will be 0.0.7.8 soon ™ ):

• The problem described by @AccidentalDisassemblycould not be reproduced yet.
  • On a minimal B9PartSwitch and OPT at least
  • I'll will test it again on a more complex installment, however.
• The problem described by @Dave-Daring is not happening.
  • The Drainex still don't works for me, but it don't works for me neither without Recall installed - so there's a problem on it, or I don't know how to use the damned thing.
  • In a way or another, the behaviour is exactly the same with and without KSP Recall installed.
• The misbehaviour described by @Krazy1 does not affect the test version.
  • I can't do anything about the resources being drained, but now it is calculated only on the last moment, so you can mess with it as you want - in the end, Recall restores the mess.
• This another problem described by @AccidentalDisassemblyis also fixed.
  • Don't mess with the Magic Bolder, they say...
• The misfeature @Hohmannson found and then thought it was a worst solution is correctly implemented now.
  • You had the best solution - it just didn't worked because I didn't had done my job right. Now I did.

I will take a nap (long day), then I will do a complex test involving B9PartSwitch, then I will release 0.0.7.8 (probably early morning).

The solution proposed by gotmachine will be tested after I kick 0.0.7.8 through the door.

Cheers.

[Dodge]

Quote

The solution proposed by gotmachine will be tested after I kick 0.0.7.8 through the door.

Trying to follow the discussions here, does this mean that the space center / FMRS recovery is gonnat wait a little bit? It also sounds like a breaking change from the developer, should we file a bug to the developer too (then it may break whatever you guys did here), your call.

[AccidentalDisassembly]

4 hours ago, Lisias said:

News from the Front

About the current test version of KSP Recall (what will be 0.0.7.8 soon ™ ):

• The problem described by @AccidentalDisassemblycould not be reproduced yet.
  • On a minimal B9PartSwitch and OPT at least
  • I'll will test it again on a more complex installment, however.
• The problem described by @Dave-Daring is not happening.
  • The Drainex still don't works for me, but it don't works for me neither without Recall installed - so there's a problem on it, or I don't know how to use the damned thing.
  • In a way or another, the behaviour is exactly the same with and without KSP Recall installed.
• The misbehaviour described by @Krazy1 does not affect the test version.
  • I can't do anything about the resources being drained, but now it is calculated only on the last moment, so you can mess with it as you want - in the end, Recall restores the mess.
• This another problem described by @AccidentalDisassemblyis also fixed.
  • Don't mess with the Magic Bolder, they say...
• The misfeature @Hohmannson found and then thought it was a worst solution is correctly implemented now.
  • You had the best solution - it just didn't worked because I didn't had done my job right. Now I did.

I will take a nap (long day), then I will do a complex test involving B9PartSwitch, then I will release 0.0.7.8 (probably early morning).

The solution proposed by gotmachine will be tested after I kick 0.0.7.8 through the door.

Cheers.

Just now had a chance to look at the issue I was having again - it may or may not be related to Recall, but it seems to involve Extraplanetary Launchpands too. Removing Recall and trying it again will allow adding fuel lines on new craft, but not on the old one that used to have Refunding. This was happening when the fuel line was added:

Spoiler

[LOG 22:22:33.386] fuelLine added to ship - part count: 48
[LOG 22:22:33.400] [SystemHeat][SystemHeatEditor]: Vessel MODIFIED
[LOG 22:22:33.400] [SystemHeat][SystemHeatSimulator]: Building heat loops from 1 ModuleSystemHeat modules
[WRN 22:22:33.400] [SystemHeat][Settings]  not found, using default coolant
[LOG 22:22:33.400] [SystemHeat][SystemHeatSimulator]: Created new Heat Loop 0
[LOG 22:22:33.400] [SystemHeat][SystemHeatSimulator]: Added module isru to Heat Loop 0
[EXC 22:22:33.433] NullReferenceException: Object reference not set to an instance of an object
    ExtraplanetaryLaunchpads.BuildResource..ctor (System.String name, System.Double amount) (at <b124727cb78b49188d90d953ff483c93>:0)
    ExtraplanetaryLaunchpads.BuildCost.ProcessResources (ExtraplanetaryLaunchpads.RMResourceSet resources, ExtraplanetaryLaunchpads.BuildResourceSet report_resources, ExtraplanetaryLaunchpads.BuildResourceSet required_resources) (at <b124727cb78b49188d90d953ff483c93>:0)
    ExtraplanetaryLaunchpads.BuildCost.get_cost () (at <b124727cb78b49188d90d953ff483c93>:0)
    ExtraplanetaryLaunchpads.ELShipInfo+<WaitAndRebuildList>d__12.MoveNext () (at <b124727cb78b49188d90d953ff483c93>:0)
    UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[LOG 22:22:34.117] [SystemHeat][SystemHeatEditor]: Vessel MODIFIED
[LOG 22:22:34.117] [SystemHeat][SystemHeatSimulator]: Building heat loops from 1 ModuleSystemHeat modules
[WRN 22:22:34.117] [SystemHeat][Settings]  not found, using default coolant
[LOG 22:22:34.117] [SystemHeat][SystemHeatSimulator]: Created new Heat Loop 0
[LOG 22:22:34.117] [SystemHeat][SystemHeatSimulator]: Added module isru to Heat Loop 0
[LOG 22:22:34.125] [SystemHeat][SystemHeatEditor]: Vessel PART REMOVE
[LOG 22:22:34.139] [SystemHeat][SystemHeatEditor]: Vessel MODIFIED

Seems like perhaps an interaction between Recall and EPL, because on previous iterations of this save, I was using EPL just fine - behavior changed with installing Recall --.7.7, *I think* (low confidence).

Or the aftereffects of some other interaction, or... I really don't know at this point, I can still sometimes reproduce it after removing Refunding stuff, so... Ugh.

Edited April 4, 2021 by AccidentalDisassembly

[Lisias]

7 hours ago, AccidentalDisassembly said:

Just now had a chance to look at the issue I was having again - it may or may not be related to Recall, but it seems to involve Extraplanetary Launchpands too. Removing Recall and trying it again will allow adding fuel lines on new craft, but not on the old one that used to have Refunding.

That first versions of Recall was terribly naïve - I added the Refunding Resource on patch, and trusted that no one would remove it.

Once the resource is vanished, the code that would use it just crashed on a NRE. And once we have an uncaught exception on a thread, the thread dies on the spot - leaving undone all that it was doing at the time. So:

• You get a fuel line, and attach it to the first part
• You try to attach it to the second part
• Something happens (I think a VesselChange event) that triggers the code on Refunding
• The code on Refunding borks because the Refunding Resource vanished
• The threads ends in error on the spot without finishing the attachment
• Anything already done remains done (i.e., no rollback). Anything left to be done remains undone

 

7 hours ago, AccidentalDisassembly said:

Seems like perhaps an interaction between Recall and EPL, because on previous iterations of this save, I was using EPL just fine - behavior changed with installing Recall --.7.7, *I think* (low confidence).

More probably a 3rd party (most likely a fuel switch) removing the Refunding Resource, and then getting my code with its pants down later, when someone else changes something and triggers an event where Refunding tries to change a Resource that it's not there anymore.

 

7 hours ago, AccidentalDisassembly said:

Or the aftereffects of some other interaction, or... I really don't know at this point, I can still sometimes reproduce it after removing Refunding stuff, so... Ugh.

So, most probably, we have a less evident problem on another Module! I'm not the only borker modder in town.  

 

9 hours ago, Dodge said:

Trying to follow the discussions here, does this mean that the space center / FMRS recovery is gonnat wait a little bit? It also sounds like a breaking change from the developer, should we file a bug to the developer too (then it may break whatever you guys did here), your call.

Unless I find something wrong on the last test, really just a little bit. 2 or 3 hours, perhaps.

Yes, it's a breaking change on the KSP itself. No, this should not had passed trough, this broke Career for everything using IPartCostModifier (including anything Squad could had written, unless someone else had worked around the problem internally).

I'm not watching the bug reports, I don't know if anyone had already reported it however. I have no patience to fill bug reports on these days (long story).

Edited April 4, 2021 by Lisias
Brute force post merging

[Lisias]

News from the Front

• Tests with FS Fuel Switch passed with success.
  • Funds recovered both with the vessel packed as unpacked
• Tests with B9 Part Switch passed with success.
  • Including on changing the Tank Type on flight (what changes the cost of the part!!!)
    • I think this should not be allowed on Career - you can make easy money by launching a cheaper variant, changing to a more expensive one and then recovering it.
• Tests on FMRS worked as expected (I think).
  • Manual Recovering works fine.
  • Automatic recovering I'm not sure, I will need help on testing this Use Case.

I'm working on the boilerplate for a new release now.

[Lisias]

ANNOUNCE

KSP Recall 0.1.0.0 is on the Wild, featuring:

• More versatile (and user hackable) mechanism to activate/deactivate the Fixes (i.e: a way to override the safeties checks)
• Allowing the inactivation of the fixes to be persisted on the craft file and savegame, so you can deactivate a fix on some parts and keep them on others on a craft by craft basis
  • Will allow the user to safely keep playing while a new version with a fix/workaround implemented is not released when things goes south.
• Reenabling support for parts with ModuleCargoPart
  • Not all Stackable parts will be correctly refunded yet.
• More reliable and robust Game Event handling.
• Compatibility with resource changing Add'Ons (as fuel switches) enhanced.

From 0.1.0.0 and newer, every fix can be deactivated on a given part, without affecting the other ones. This change is persisted on the craft file and on the savegame, so you can even deactivate a fix on a part on a craft and not do it on another craft. For people willing to write patches, the name of the attribute is active.

The user can also force his/her hand on how and where the fixes is installed by editing GameData/999_KSP-Recall/KSP-Recall.cfg. Changing this file will overrule the default installation decisions KSP-Recall does on startup, allowing you use fixes that usually would not be available for your rig. Use this with caution and prudence, this can royally screw up your savegames.

A new module, Refunding, as well a new Resource was introduced for KSP 1.11, to counter attack the miscalculation mentioned above.

When recovering the craft, the badly calculated refunds will still be there, but an additional Resource called Refunding will be present stealing giving back the losses.

Users of EVERY add'on that implementsIPartCostModifier and are running on KSP 1.11.x NEED to install KSP-Recall - or your Career will be seriously hindered.

Affected (known) add'ons are:

• Darth Pointer's Pay to Play
• FreeThinker's Interstellar Fuel Switch
• allista's Cargo Accelerators
• All Angel 125 Add'Ons that uses WildBlueTools
• Nathan Kell's Modular Fuel System (and Real Fuels)
• IgorZ's Kerbal Inventory System
• KOS
• Kerbalism
• And many, many others - perhaps Squad's own modules (who knows?)

---

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), by this Sunday's night (GMT-3)

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

Edited April 5, 2021 by Lisias
Distributions Channel are being updated as scheduled.

[Hohmannson]

On 4/4/2021 at 12:29 AM, Lisias said:

The Jettison Contents is also jettisoning the Electric Charge or the Ablator resource?

It turned to be not a bug, but a feature. Jettison module have one property, ResourceName. If it is set up properly on tanks, it won't throw out your Refunding.

@PART[*]:HAS[@RESOURCE[Ore],@MODULE[ModuleFuelJettison]]
{
    @MODULE[ModuleFuelJettison]
    {
    %ResourceName = Ore
    }
}

After that the button becomes "jettison ore" and jettisons only ore. Squad didn't set it up, because no such technical resources like Refunding were planned. If that string is not defined, it jettisons any resources on part. Epic Squad moment here.

Also, there is a mod JettisonFuel that adds this to all parts with resources. Not sure what could be done with it, but it's not widely known, maybe, it's OK to not do anything.

[Lisias]

29 minutes ago, Hohmannson said:

It turned to be not a bug, but a feature. Jettison module have one property, ResourceName. If it is set up properly on tanks, it won't throw out your Refunding.

Well, a mishap on the part definition so.

 

29 minutes ago, Hohmannson said:

Also, there is a mod JettisonFuel that adds this to all parts with resources. Not sure what could be done with it, but it's not widely known, maybe, it's OK to not do anything.

Yep, we can safely ignore this issue - other that showing "Refunding Jettisoned" on the screen, nothing bad will happen. The code that handle fuel switches fixed this by side effect.

Edited April 5, 2021 by Lisias
Damn, tyops again!