Jump to content

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


Lisias

Recommended Posts

ANNOUNCE

KSP Recall 0.1.0.1 is on the Wild, featuring:

  • Minor revision to make life easier for Package Managers as CKAN.
    • Will allow installing on any KSP >= 1.4.1, even by not having (yet :P) any fix for them.
  • Closes Issues:
    • #14 Make Recall safe to be installed on any KSP version instead of yelling about not being compatible

All Distributions Channels are up to date.

Cheers!

Edited by Lisias
"All your base are belong to me" feelings...
Link to comment
Share on other sites

On 4/7/2021 at 4:02 AM, Lisias said:

ANNOUNCE

KSP Recall 0.1.0.1 is on the Wild, featuring:

  • Minor revision to make life easier for Package Managers as CKAN.
    • Will allow installing on any KSP >= 1.4.1, even by not having (yet :P) any fix for them.
  • Closes Issues:
    • #14 Make Recall safe to be installed on any KSP version instead of yelling about not being compatible

All Distributions Channels are up to date.

Cheers!

Hello @Lisias !

I confirm that on this new release, several issues were actually solved, which is awesome :), but some others are still over there.

I hope that my logs can help:

https://www.dropbox.com/s/laeh18h1jxn22n0/log-recall.zip?dl=0

Previous build log: KSP-recall-error.log

With this new release: KSP-with-new-release.log

Link to comment
Share on other sites

ANNOUNCE

KSP Recall 0.1.0.2 KSP Recall 0.1.0.3 is on the Wild, featuring:

  • Pretty stupid mistake on Refunding fixed.
  • Updating KSPe Light.
  • The problem fixed on 1.0.2 was masking another problem on Refunding that, once fixed, regressed the over-billing problem.
    • GameEvents related to vessels don't work as I expected.
    • The solution was to step back a bit, and risking some over-refunding on FMRS on automatic recovery.

All Distribution Channels are up to date.

Cheers!

Edited by Lisias
KSP Recall 0.1.0.3 is on the wild. All Distribution Channels are up to date.
Link to comment
Share on other sites

Umm Huston, we have an over-refunding problem. I sent a rover out at KSC that had a lot of deployable science in cargo. 

First, it gave errors when I removed a Kerbal's parachute from his PAW inventory slot - screenshot

Then when I recovered, it gave me over :funds:160K for a :funds:120K ship. Using latest version. Nothing on the ship was modded. I have TweakScale installed but everything was stock size. KSP 1.11.2.

Second test: big rocket in VAB::funds:425792  and recovered :funds:468823... which listed 96607 for Refunding. So that just does not add up at all. This rocket did have a few Tweaked parts.

Edited by Krazy1
second test
Link to comment
Share on other sites

3 hours ago, Krazy1 said:

Umm Huston, we have an over-refunding problem. I sent a rover out at KSC that had a lot of deployable science in cargo. 

First, it gave errors when I removed a Kerbal's parachute from his PAW inventory slot - screenshot

I confirm the Exception.

That is embarrassing... The code blowing up is this one:

		private void RemoveResourceIfAvailable()
		{
			Log.dbg("Removing {0} from part {1}-{2}:{3:X}", RESOURCENAME, this.part.vessel.vesselName, this.part.partName, this.part.GetInstanceID());

Replacing the this.part.vessel.vesselName thingy with a property guarding against NULLs on this.part.vessel solved the exception problem - as we can see, a part loses it's vessel when moving from the Kerbal to the Storage.

(the fix was preemptively replicated on the whole code - better safe than sorry)

Well... I was caught with my pants down on this, but thinking a bit on the problem, it makes sense. The fix is on this commit, if you are curious.

However, after fixing this, I still got a Over-Refunding!!!!

Long story made short, I got twice the intended refunding for this craft. And I know it because Refunding is traceable, and it listed 70 Funds as Refunding besides KSP giving me 140 Funds!

114316275-37391280-9ad9-11eb-8c77-61bbd3

The whole history is on Issue #16.

I think I know what's happening - the Recovering process is correctly recovering the funds of Stored parts![Nope! The IPartCostModifier is still being ignored on Stored parts - what we found was A BUG INSIDE THE BUG, as the Refunding Resource is being counted TWICE, damnit!]

Jesus Christ, how many ways of doing the same freaking thing were implemented on KSP? It's no surprise the code base is so terribly bugged, they implemented the same feature many times, each one on a different way - and once something changes, God knows how may different code that was doing the same thing need to be fixed - not to mention tested!

I'm working on a solution for this. Theoretically, it's simple - once the part is stored inside an Inventory Part, the Refunding must be withdrawn, and once it is removed from it, reapplied. 

But... Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet...
[EDIT: I will say it again: Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet...]

 

Edited by Lisias
I was wrong, things are still more broken than I thought.
Link to comment
Share on other sites

18 hours ago, Krazy1 said:

First, it gave errors when I removed a Kerbal's parachute from his PAW inventory slot - screenshot

The NREs were fixed on latest Pre Release: https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.1.0.4

I wil not promote it a proper release yet, because I'm testing if the failed solution for #16 would fix by accident a situation I had foresee on FMRS (over refunding on automatic recoveries).

Your over-refunding, however, is due another misbehaviour on KSP, that it's counting TWICE any Resource stored on a Inventory Part.

I will take a break in the next hours (RL is calling), but I will be on it again later. Until there, please report anything different using this pre-release.

Thanks for the heads up and sorry by the NRE.

-- POST EDIT --

I promoted the thing as Release, as it fixed the NRE and a small trick solved the hypothetical problem in which third-parties Add'Ons that would recover Craft themselves would bork the calculations due the Refunding Resource stunt.

Edited by Lisias
post edit
Link to comment
Share on other sites

Yeah I figured it was double-counting somehow. With Recall 0.1.0.3 it also spammed the KSP log when loading a ship in the VAB and once when sending a ship to the launch pad from VAB once. It usually worked without error though so I don't have steps to reproduce it.  It may have been related to the auto-saved ship. Message (1190 times):

Spoiler

[ERR 13:03:33.282] Module Refunding threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at KSP_Recall.Refunds.Refunding.RemoveResourceIfAvailable () [0x00020] in <6a6e0cdce4694e5e9f7bc91fa34bd177>:0 
  at KSP_Recall.Refunds.Refunding.OnLoad (ConfigNode node) [0x00066] in <6a6e0cdce4694e5e9f7bc91fa34bd177>:0 
  at PartModule.Load (ConfigNode node) [0x001ab] in <06f13185617646e5bc801baeab53ab75>:0 

I suppose we should enter a KSP bug report too if it's over refunding in stock. I expect it will screw up on the fuel stored in an Oscar tank stored in cargo. 

I'll get the new version later - RL also calling. Thanks

Link to comment
Share on other sites

On 4/11/2021 at 6:49 PM, Krazy1 said:

Yeah I figured it was double-counting somehow.

I figured out something interesting. Using a debug compile of Refunding, I realised that ModuleInventoryPart implemented IPartCostModifier, and it's returning a cost of 35Funds (look for CalculateModulesCost below):

[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Recalculate kerbalEVAfemale (Valentina Kerman):FFF9DD2C
[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVAfemale,ModuleInventoryPart) => 35
[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVAfemale,Refunding) => 0
[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 0.0; resourceCosts:0.0; wrongCost:0.0; rightCost:35.0; fix:35.0 ;
[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: UpdateResource kerbalEVAfemale:FFF9DD2C
[LOG 22:46:13.775] [KSP-Recall-Refunding] TRACE: Test OverRefunding-Part:FFF9DD2C is not stackable
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Before PartResource 0 1 1
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: After PartResource 35 0 1
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Recalculate kerbalEVA (Lulan Kerman):FFF9D762
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVA,ModuleInventoryPart) => 35
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(kerbalEVA,Refunding) => 0
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 0.0; resourceCosts:0.0; wrongCost:0.0; rightCost:35.0; fix:35.0 ;
[LOG 22:46:13.776] [KSP-Recall-Refunding] TRACE: UpdateResource kerbalEVA:FFF9D762

Since Refunding tacitly assume that the IPartCostModifier is always ignored, it adds that 35Funds into the costFix variable (that will be used to create the RefundingResource later). Since we have two Kerbals on the vessel, we have two Refundings of 35 Funds, ergo 70 Funds.

So we now have the explanation from where came that 70 Refunding.

Now we need to find from where the others 70 Funds came. Logic suggests that each part that the Kerbal's IPartCostModifier is being honored if and only if the Kerbal has a Resource on him [NO! Even Stock Career is broken, the Funds are being incorrectly refunded on vanilla too!]. This would explain the 140 Funds on the recovery of the Vessel used for this test.

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

HA!! It's yet another bug on KSP!!!!

114486384-27f2bb80-9be4-11eb-9a1e-af3d78

Resources on storage are being counted twice. That extra :funds:70 is from KSP itself!

So Refunding need to detect these situations somehow, and DEFUND the value of the Resources to get the correct value back

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

Given the seriousness of the situation, I made a DebugMode release for KSP-Recall 0.1.0.4 . Please, pretty please, use it only for debugging purposes.

Note that you will need to copy the file KSPe.cfg into <KSP_ROOT>/PluginData folder (and not inside GameData!)

Edited by Lisias
HA! ** 2
Link to comment
Share on other sites

I just installed Recall 0.1.0.4 and TweakScale 2.4.5.0 on KSP 1.11.2 with many QoL mods but no other part mods*. The new buttons to disable Refunding and Tweakscale were not touched for testing.

First craft test was a simple SEQ-24 filled with cargo - nothing stackable or with anything that has it's own resources (I believe). Confirmed 100% correct funds. (Although KSP did not show the recovery summary because there was no command pod? )

Second test was the notorious Refinery, maybe not exactly the version I uploaded before. In SPH :funds:19785770. Recovered -3731203. "Kerbal 1 Jumbo... Pan Pan Pan." ;)

Convert-o-tron  value was 8000, same as 1x scale. Drill was 6000 also 1x value. FL-R1 RCS tank value was -459000. Refunding was -34.

Third test has 4 variations. All use a S3-14400 tank (root part) and Stayputnik. I noticed in the editor KER did not show "Refunding for KSP111x" like it did before and does when I load the Refinery.

3A: 1x scale tank full fuel. :funds:13300 correct.

3B: 1x scale with no OX: :funds:11874 correct.

3C: 5m tank full fuel: :funds:46782 in editor, recovered 13300. Same as 1x so it's ignoring TweakScale?

3D: 5m tank no OX: :funds:43403 in editor, recovered 9921. Tank value -2667. Refunding value: zero. Less than 1x scale value so I've got no obvious theory. 

Also found an issue on TweakScale I'll post there. Thanks for your hard work man!

*Edit: I lied a little. I do have Simple Fuel Switch installed but didn't use it. 

Edited by Krazy1
fuel switch
Link to comment
Share on other sites

9 hours ago, Krazy1 said:

I just installed Recall 0.1.0.4 and TweakScale 2.4.5.0 on KSP 1.11.2 with many QoL mods but no other part mods. The new buttons to disable Refunding and Tweakscale were not touched for testing.

First craft test was a simple SEQ-24 filled with cargo - nothing stackable or with anything that has it's own resources (I believe). Confirmed 100% correct funds. (Although KSP did not show the recovery summary because there was no command pod? )

Second test was the notorious Refinery, maybe not exactly the version I uploaded before. In SPH :funds:19785770. Recovered -3731203. "Kerbal 1 Jumbo... Pan Pan Pan." ;)

I confirm the problem. Kerbodyne has a grudge with me and it's retaliating. :D

 

9 hours ago, Krazy1 said:

Convert-o-tron  value was 8000, same as 1x scale. Drill was 6000 also 1x value. FL-R1 RCS tank value was -459000. Refunding was -34.

Third test has 4 variations. All use a S3-14400 tank (root part) and Stayputnik. I noticed in the editor KER did not show "Refunding for KSP111x" like it did before and does when I load the Refinery.

3A: 1x scale tank full fuel. :funds:13300 correct.

3B: 1x scale with no OX: :funds:11874 correct.

3C: 5m tank full fuel: :funds:46782 in editor, recovered 13300. Same as 1x so it's ignoring TweakScale?

3D: 5m tank no OX: :funds:43403 in editor, recovered 9921. Tank value -2667. Refunding value: zero. Less than 1x scale value so I've got no obvious theory. 

Well, I have. I messed up.

Refunding can't be applied immediately on craft launch because otherwise you will be over-billed (as the billing will count the Refunding as the price of the launch). So I had to delay the Refunding creation for some frames.

However, TweakScale also has a similar problem (but due different reasons). TweakScale can't run on OnStart because at this point there's no guarantee that every other module on the part was already OnStarted, and since TweakScale needs to mangle these modules on scaling, trying to do so on OnStart will be a race condition where you don't know if the module you are scaling was already OnStarted or not.

So TweakScale also delays it's run a bit, it do its "real" OnStart on the first Update. But Refunding does its delay on FixedUpdate - I choose it because its timing is determinist, while the Update is variable. I think I probably caused a race condition of my own...

I'm trying a quick test before bedtime - let's see if I'm rigtht.

-- -- POST EDIT -- -- 

Bad luck, things are not so simple. Refunding is doing its work right on Editor Time. Whatever is happening, is happening on recovering - exactly the place where I didn't expected more problems.... :/ 

[LOG 01:54:05.953] [KSP-Recall-Refunding] TRACE: OnStart Size3LargeTank:FFFA573C Editor True
[LOG 01:54:06.081] [KSP-Recall-Refunding] TRACE: OnStart probeCoreSphere.v2:FFFA5702 Editor True
[LOG 01:54:06.183] [KSP-Recall-Refunding] TRACE: FixedUpdate Size3LargeTank:FFFA573C
[LOG 01:54:06.184] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,LiquidFuel) => 12288.0023803713
[LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,Oxidizer) => 3379.20073852546
[LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,ModulePartVariants) => 0
[LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,Refunding) => 0
[LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,TweakScale) => 17814.82
[LOG 01:54:06.219] [KSP-Recall-Refunding] TRACE: FixedUpdate probeCoreSphere.v2:FFFA5702
[LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(probeCoreSphere.v2,ElectricCharge) => 0
[LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(probeCoreSphere.v2,Refunding) => 0
[LOG 01:54:06.220] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(probeCoreSphere.v2,TweakScale) => 0
[LOG 01:54:11.433] [KSP-Recall-Refunding] TRACE: OnSave Size3LargeTank:FFFA573C
[LOG 01:54:11.433] [KSP-Recall-Refunding] TRACE: OnSave probeCoreSphere.v2:FFFA5702

However, I found the problem! Damn! I shoot me in the feet! [ All the four!! ] 

[LOG 01:56:03.706] [KSP-Recall-Refunding-FlightHelper] TRACE: OnVesselRecoveryRequested Untitled Space Craft
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: Recalculate Size3LargeTank:FFFA26B0
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,LiquidFuel) => 12288.0023803713
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateResourcesCost(Size3LargeTank,Oxidizer) => 3379.20073852546
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,ModulePartVariants) => 0
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,Refunding) => -17814.82	<<-- KRAP!!!!!!
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: CalculateModulesCost(Size3LargeTank,TweakScale) => 17814.82
[LOG 01:56:03.730] [KSP-Recall-Refunding] TRACE: Recalculate Results originalCost: 46482.0; resourceCosts:15667.2; wrongCost:30814.8; rightCost:30814.8; fix:0.0 ;

New release with this fixed in the next 30 minutes.

Edited by Lisias
found the problem, damn...
Link to comment
Share on other sites

2 hours ago, Lisias said:

Given the seriousness of the situation, I made a DebugMode release for KSP-Recall 0.1.0.4 . Please, pretty please, use it only for debugging purposes.

I should be able to tomorrow. On Github?

15 minutes ago, Lisias said:

so on OnStart will be a race condition

I think I'm having a similar problem with a little mod I'm making. I think the button I want it to click doesn't exist yet when the code tries to press it. I might be able to put it in Update. The intro tutorial mentions using a Coroutine (no idea how that works yet).

Link to comment
Share on other sites

57 minutes ago, Krazy1 said:

I should be able to tomorrow. On Github?

Yep. But use the 0.1.0.5 release, currently on the oven. [Released!] I found the problem.

 

57 minutes ago, Krazy1 said:

I think I'm having a similar problem with a little mod I'm making. I think the button I want it to click doesn't exist yet when the code tries to press it. I might be able to put it in Update. The intro tutorial mentions using a Coroutine (no idea how that works yet).

Coroutines were useful in the past, nowadays I'm not so sure.

But it's simple. Imagine a "for loop":

for (ever) {
	try {
		do_something();
	} catch (yield value) {
		send_to_caller(value);
		continue;
	} catch (yield break) {
		break;
	}
}

You write the "do_something" function, and this function returns a value each time it's called using yield, or terminate using yield break.

How the value is sent to the caller is the hard part, but this Unity does for you.

Unity guarantees that your "do_something"  is called only once by frame, so this is a cheap multitasking mechanism for non multithreaded environments (essentially what Unity was on version 3 or 4, I think). Just don't do loops inside your coroutine, or you will drag the framerate.

Edited by Lisias
Link to comment
Share on other sites

Some debugging for you to chew on, 3 crafts with screenshots and KSP log:

recall 1.0.4-debug: https://disk.yandex.com/d/mOY3aS4t2q4lzQ?w=1

recall 1.05-debug: https://disk.yandex.com/d/zvWNiJOVAUF4GA?w=1

Lots of custom resources (CRP, Rational resources, TAC-LS, WildBlueTools stuff).

Edited by hendrack
Link to comment
Share on other sites

NOTAM

A new release, 0.1.0.6, is now available on GitHub only.

It (hopefully) fixes the Stock's OverRefunding problem described below and on github issue #16.

To prevent another mishap to reach the mainstream (as I foolishly did on 0.1.0.4 - What could possibly go wrong?), I'll keep this one only on GitHub for a few days while I give this a proper bashing test time. As usual these days, a DebugMode is available for the brave Kerbonauts that don't fear I/O on KSP.log. :)

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

Edited by Lisias
Missing link
Link to comment
Share on other sites

With 0.1.0.6 I tested basically the same 3 tests as yesterday. Any you completely flipped the results... case 1 failed and 2 and 3 passed. :o

Cargo parts value is being cancelled, meaning the Refunding is negative the value of the stored cargo.  

Specifically, an empty SEQ-24 with a command seat on top and a kerbal (no backpack) is :funds:1700 and that works correctly. Adding  a weather analyzer should recover :funds:3000 but it's still :funds:1700.

 

Link to comment
Share on other sites

4 minutes ago, Krazy1 said:

With 0.1.0.6 I tested basically the same 3 tests as yesterday. Any you completely flipped the results... case 1 failed and 2 and 3 passed. :o

Cargo parts value is being cancelled, meaning the Refunding is negative the value of the stored cargo.  

Specifically, an empty SEQ-24 with a command seat on top and a kerbal (no backpack) is :funds:1700 and that works correctly. Adding  a weather analyzer should recover :funds:3000 but it's still :funds:1700.

Well, I think I finally understood (famous last words).

The minimalistic craft used on the issue #16 was using parachutes and EVA JetPacks. These two parts are "free", so only the fuel of the JetPack was being counted.

Your new test suggests (strongly suggests. to tell you the true) that whatever is screwing up the refunding on Stock, is screwing up only on Resources - the part's "dry cost" is being correctly accounted for.

So, yeah... I will need to find my way on that ProtoPartSnapshot and ProtoPartResourceSnapshot stunts and do the job the hard way.

Stay tuned. I will try to publish a new release about 15 hours from now.

Link to comment
Share on other sites

6 hours ago, Krazy1 said:

Well, don't lose sleep over cargo parts. At least it seems the +/- millions is resolved. 

I won't. Believe it or not, we are having a busy week on job, and this escapades to do anything else ends up helping. Not being able to proper rest because you need to watch something can be terribly frustrating, so I keep a window opened on the secondary monitor to watch it and Keep Kerbaling on the main one. :D

Today I need to figure out how in hell some <insert your favorite non-forum conforming adjective here> implemented a very simple thing to do on a sysvinit on a freaking systemd box. Believe me, before the end of the day we will have a new release of Recall - or someone is going be thrown through the window. :D 

 

3 hours ago, hendrack said:

With 0.1.0.6 I lose somewhat between 1k-10k from recovery, just call that maintenance :D

Humm.. How about an add'on about financial frauds? Now and then, Funds are stollen from your recoveries, and you need to investigate before the scandal goes public and affects the KSC's reputation?? :sticktongue:

Edited by Lisias
hit "save" too soon.
Link to comment
Share on other sites

16 hours ago, Krazy1 said:

Specifically, an empty SEQ-24 with a command seat on top and a kerbal (no backpack) is :funds:1700 and that works correctly. Adding  a weather analyzer should recover :funds:3000 but it's still :funds:1700.

Oukey, debugging time.

I made a new test on a vanilla test bed using that craft of yours, but with Mk0 Fuel Tank inside the SEQ. It worked fine, ir better, it borked as expected - the same 70 Funds over-refunded from the last time. So, at leats for some parts, the thing is working fine (only the already borking parts borked).

114785737-7d99a600-9d53-11eb-88b3-51f586

114785831-9efa9200-9d53-11eb-8055-3ae4b7

Now I redid the test using also the Weather Analyser:

114786609-c7cf5700-9d54-11eb-9896-15d837

114786620-cdc53800-9d54-11eb-9af5-ccafc9

And no new misbehaviour, only that 70 Funds we already know about.

So, yeah, this is a confirmation that your problem is 100% on Refunding.

Link to comment
Share on other sites

The devil is on the details...

I realised something interesting - late night is not exactly the better time of the day for debugging...

I had assumed that the extra 70 Funds were coming from the EVA JetPack from the two Kerbonauts, but the true is that... WE DON'T KNOW from where this Funds is coming from.

Checking the test craft on a stock KSP, I got this:

114861020-16b3d580-9dc3-11eb-851e-b400e0

114861030-1adff300-9dc3-11eb-973e-2aa348

114861159-44008380-9dc3-11eb-8de8-d49208

So, it's not a surprise I was not being able to get rid of that extra 70 Funds, and ended up chasing ghosts on the ProtoPartSnapshot. This other bug on KSP is deep on the code on some hack made in the past, and not on counting Resources!!

So I kept digging.  I launched the vehicle with only one Kerbal, and got a 35F over-refunding.

Then I added an extra command-chair, and launched it with 3 Kerbals, and got 105F over-refunding. Appears to be consistent.

Then I launched it again with only one Kerbal, but getting rid of the chute and of the JetPack. No over-refunding. Adding more Kerbals, as long they are without chutes or jetpacks gave no over-refunding neither.

Found a pattern.

Launching the craft with a single Kerbal with jetpack but without chute gave me back that nameless Resource with a cost of 25F, and a 25F over-refunding.

Launching the craft with a single Kerbal without jetpack but with chute gave me back that nameless Resource with a cost of 10F, and a 10F over-refunding.

Further testings confirmed the over-refunding being applied on a per Kerbal basis.

25F and 10F are the prices for the JetPack and Chute, respectively.

That nameless Resource is a marker with the price of the equipment on the Kerbal, and it's multiplied by the number of the Kerbals on the vessel. [not quite, but near...]

So I launched the craft with 3 Kerbals, one with chute only, other with JetPack, and the third without any equipment.

I got a refunding of 35F, what I expected. That weird nameless Resource happened only once, with a 10F price.

By adding anything else to a Kerbal, I got the total price of the itens over-refunded. By example, if I shove a Small Work Lamp and a EVA Fuel Cylinder to a Kerbal, I got a over-refund of 75F, the combined price of the two itens.

finally understood. Squad added the ModuleInventoryPart stunt but didn't got rid of the older code that was handling Kerbal's inventory.

Well, I finally know what to do. I think someone had hinted something above, but I don't have time to further digging right now. I'll be back to this on the end of the day (GMT-3).

Full details on https://github.com/net-lisias-ksp/KSP-Recall/issues/16

Edited by Lisias
damnit. I need coffee. And a grammars book.
Link to comment
Share on other sites

One good new. :)

I fixed the Over-Refunding related to Kerbals! #hurray (not bad for a lunch break)

114901481-38c14e00-9deb-11eb-9087-aa4132

114901497-3c54d500-9deb-11eb-812b-0db70b

Craft on this comment on Issue #16.

By night I will go through the currently known Use Cases to test against regressions, and then if everything looks fine a new Release will be on the wild! :)

Edited by Lisias
(hate grammars)
Link to comment
Share on other sites

More or less good news... :D

Almost all the test beds passed, but one (B9PS and TweakScale), appears to have a rounding error somewhere:

115039947-4d631c00-9ea7-11eb-823b-3c95d9

115039961-50f6a300-9ea7-11eb-9912-2e4ee0

Craft file on the comment: https://github.com/net-lisias-ksp/KSP-Recall/issues/16#issuecomment-821219507

Since I had ran out of modding time (by a mile, boy I need to work now!), I will rush a 0.1.0.7 Pre Release on github for people willing to test the stunt.

I didn't tested it on FMRS neither, by the way - so don't assume the thing is fine yet (I may had borked something on the module life's cycle, I really didn't tested this specific test case).

Happy Refundings!

-- -- POST EDIT -- -- 

Pre Release 0.1.0.7 is on the wild:

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

This will not be promoted to release until further testings, but at least the most common cases are working fine now.

Edited by Lisias
Pre Release 0.1.0.7 .
Link to comment
Share on other sites

12 hours ago, Lisias said:

rounding error somewhere

So, in the screenshots the before and after craft value was the same but the funds in the bank changed by 1 fund. Is that what failed? I think your "customers" will be happy with this result. :D 

Link to comment
Share on other sites

12 hours ago, Krazy1 said:

So, in the screenshots the before and after craft value was the same but the funds in the bank changed by 1 fund. Is that what failed? I think your "customers" will be happy with this result. :D 

Yep. :D

To simplify things (I hadn't enough time for testing things as I want), I was cheating my funds before launch to have barely the money needed to launch the craft. If the thing costs :funds:7015 , then I zero my account and cheat it into :funds:8000 . So, on recovery, I need to have that 8000 back. Easier to track failures without having to bean counting things! ;) 

Tomorrow I will reserve some time to proper test FMRS and Pay to Play (just to be on the safe side - this is the point where overconfidence usually bites me on my SAS). Everything going fine, I will release the thing into the Wild Wide Web. :)

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

FMRS is working fine, automatic recoverings are being carried out without over or under refundings.

Pay to Play I'm not sure, I may had screwed up something on it, as I think I'm being under-refunding on recovery....

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

Found a small and practical test case for Pay to Play, and it worked.

I will consider 0.1.0.7 a proper release, and it will be distributed as usual from now on.

Edited by Lisias
post post edit
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...