KSP 1.11.x is borking the recovering of costs from scaled parts. #12
Comments
|
The cost of the part is borked, not the cost of the resources. I really hope Squad didn't decided to fetch the values from the PREFAB instead of asking the living (soon to be dead) part's module for the info. This will break not only TweakScale, but any Add'On that change the cost from the part. It may be a change on the life cycle of the part's module too - this will be troublesome, but at least is fixable. I think. |
|
Tried to change the IPartCostModifier.GetModuleCostChangeWhen from FIXED to No dice. :( |
|
Well, this is the log from KSP 1.10.1 when recovering the craft: And this is the same code running on KSP 1.11.1 (1.11.0 also behaves like this): As we can see, the CostModifier if being reported correctly on both KSP versions, but on KSP 1.11.1, the value is not being used. My guess is that the PREFAB values are being used now for the total cost of the part, and when subtracting the value of the resources, we have a negative value!! |
|
This is the recovery funds from an unscaled Flea:
The recovery funds for the part it's 116F, while for the solid fuel is 84F. What confirms the total cost of 200F. Now, 200 - 944 (the refund of the fuel on the scaled Fleat), we have -744F - exactly the value being "recovered" by KSP 1.11.1. So, TweakScale is toast. It's another hardcoded change inside the KSP guts, and I don't see how to fix this without reverse engineering - breaking Forum Rules |
|
Hi @Lisias! I guess I'm also a victim of this shit happening. So I will have to anounce 1.11 being uncompatible. Could you contact me if you find a solution? |
Hi!
So do I. :/
Yes. Keep an eye on this issue, I'm working on the problem. However, this is not a problem on TweakScale - to tell you the true, this is not even a problem because there's no solution from our side, Add'On developers. The fact is that some dev literally rendered the interface IPartCostModifier useless by ignoring it and using the prefab total cost instead - and there's no way out of the mess other than rewriting the KSP guts doing this stunt. What I'm trying to do is to cook a workaround on KSP Recall that would try to "cheat" back the lost fundings on Vessel Recovery. It will be a hell of a ugly hack, but theoretically it will work - and it will work for everybody, not only for TweakScale. My problem now is managing to make this hack to work - there're some key values I need to mangle on the living craft that, if by bad luck Squad is also squashing them from the prefab, will render the workaround impossible to implement. On this case, I will have no other option as to reverse engineer KSP and apply a hotpatch using Harmony - and this will render the trick not publishable on Forum (due some draconic rules on modding) |
I use this interface on my own. And going to test it with 1.11 rn before I accuse SqUaD of breaking the things in my mod's thread. I guess this cheating is pretty possible if you remember current balance and can access the vessel being stll an actual It took me pretty much time to make the thing work for 1.8-1.10. Upd: taken that, should you make the fix as a separate mod so we only add a dependecy and dont get bothered with problems that can occur when multiple mods are trying to fix the problem? |
"Test, don't trust!" - it's the way to go. By all means, prove me wrong - I will be happy, believe me! :)
Don't work. Squad squashed the recovery funds by using the prefab data, nothing you could do on the Module will have any effect. I'm trying a (Forum rules compliant) workaround on this.
Yes. This issue will be moved to KSP-Recall, I will fix this there - as the fix will work for everybody. I'm keeping this here to avoid confusion, as I already spammed this link everywhere. |
|
News from the front: the "mechanism" is working perfectly: But the prefab squashing had bit me again in another place. Now trying a workaround to make this workaround to work... |
In time. This is not an accusation. It's the declaration of a fact. :) I had tested this issue on KSP 1.4.5, 1.5.1, 1.6.1, 1.7.3, 1.8.1, 1.9.1, 1.10.1 and finally 1.11.0 and 1.11.1 . Only the 1.11.x presented the problem, with all the others elements (Machine, OS Version, TweakScale and ModuleManager) being exactly the same. So the only change between the tests are the KSP version being tested. And since there's only code from Squad on KSP, the logical conclusion is evident. ;) |
Then I have bad news. Or good, taken that they proove your model. Issue has been successfully reproduced for PayToPlay mod, KSP 1.11.1, recovery to KCT storage. My balance has changed. |
|
News From the Front: I found ANOTHER FSCKIG BUG on this mess. The way I tried to recover the funds was by adding a new Resource, called unsurprisingly And then I created a module to control it. Problem. Even by stating that the default amount of the Resource IS ZERO, the freaking game is calculating the cost of the Resource by using the
This COMPLETELY SCREWED UP the whole cost system - you need to add the costs of all the resources to the Part's price, even when it's empty. Thinking a bit about it, I should not had been caught with my pants down on this, as I had to deal with this too once on TweakScale. Well... I still have two options to try to make this work this way. It will add more ugliness to an already ugly kludge, but I want to keep my interventions on the game engine at minimum. |
|
@Lisias this one is not really a bug. Or is. Don't know, it is not 1.11-specific at least. For example, if you MM-patch a regular fuel tank part to have more or less fuel, its full cost is not affected. This means we can actually reduce recovered part cost posting some empty resource into it. If negative resource costs apply "correctly" then we will be able to increase the cost too. |
Agreed. It's more an anti-feature than a bug on a feature. :) Need to cool my head a bit.
Don't work, as the prefab data is injected on the part on launch. You would need to create a new Part for each possible combination. However... While bashing my head on the wall in frustration after trying to mangling the part's living data, I got an even crazier idea, currently under test. Cross your fingers. |
|
News from the Front My last not so dirty trick failed. My worst problem is not calculating the "cost fix" value, neither applying them. The problem is to avoid screwing up the part and vessel value on editor. My initial attempt was to create a resource with 999.999 as Oh well, at least I demonstrated that the stunt have teeth. Then I tried a dirtier trick. I can't use Resource's It worked at runtime.
The But....
The prefab's Resource Definition ended up overruling my stunt once the craft is recovered - @$%@$$#!%!!!!! >:-/ I had run out of "not that dirty" options. My remaining option is to go nuclear - I will brute force my way out of the problem using Introspection. It's what TweakScale does anyway, but I was trying to avoid using this trick. TweakScale is already nosy enough, I didn't wanted a new nosy add'on screwing up other people's business. :D |
|
Almost there! :)
I forgot to zero the Resource's |
|
Things didn't worked exactly as I had planned.... :/
The trick worked as I intended, but I misjudged the resulting effect. Some more reflection abuse is on the way.... |
|
Datum perficiemus munus
Now I will move this issue to KSP Recall, and will publish a Beta Release for public evaluation. I don't trust this stunt yet - a lot of tests need to be done (by me and also on the field) in order to declare this kludge something safe. |
|
Slightly better.
The end result is still the same, but I further abused my way on it in order to prevent changing two fields on the Summary. Now the (improper) values are kept, making easier to track what I really did. |
|
How to check if the KSP Recall stunt is installed on your 1.11.x rig:
|
…behaviour for everybody, and not only for add'ons that works on Editor (and TweakScale). #12
|
Some add'ons as PayToPlay are being ignored by The solution worked fine with TweakScale (surprised? :P ) but it's cumbersome for add'ons that constantly update the part's cost, exactly the case for PayToPlay. A better solution is to monitor when the craft is being recovered and update itself on that time, what guarantee the most updated data to be "refunded". This is a testrun for PayToPlay, where depreciation is being applied to the Flea engine for being used: The U.I. will be still "weird", with the Fix implemented on commit 06255bb |
|
A new release is on the wild. https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/PRE-RELEASE%2F0.0.7.1 I will keep this Issue opened while this stunt is on tests. |
|
It is time I tell you I have lied. P2P does not update cost constantly, it actually changes cost max once during flight (to nullify cost). However there is no way to detect it outside P2P. And I guess at this point the fix covers most the cases if not all. |
|
Fellow Kerbonaut firethorn6 reported a new misbehaviour, at this moment not known to be related to By bulding a craft using a stayputnik and a thoroughbred scaled to 10 meters, we are being charged above the craft cost on launching! The stunt costs 576.300F, and on the screenshot below I have 600kF on my wallet: The refunding stunt itself is working fine, the full costs of the vessel is being recovered: But note on the screenshot above that my wallet is now 576.300F, the price of the craft - what means I had no money left!!! The price being charged on launch is bigger than the craft's price - on this case, I paid 23700F more for it. So I redid the test, but with way more money than needed, so see exactly how much I'm being charged for this:
And my wallet, after launch, came to... WHAT A HELL??? Zero Funds again?
Oukey, I need to reassess this situation... |
|
New test. A way cheaper craft, 5M thoroughbred costing to launch 72.300F, and with 1M on the wallet.
After launch, my wallet gone down to 864.699F: So the launch cost me 1.000.000 - 864.699 = 135.301F !!!! Hummm.... I had an idea... |
|
Found the reason. The What's happening is that the charge happens on the Flight Scene, and by that point I already had initialised the So the solution is to do not initialise |
|
Fixed!
Commit 6a0f157 |
|
With the 0.0.7.3 release publsihed, I consider this issue closed/fixed |
|
This is a terrible, hacky and ugly solution for a very easy to solve problem. The mistake in KSP 1.11 happens in the stock When They are now calling only : which causes the The solution is to create a private void onVesselRecoveryProcessing(ProtoVessel pv, KSP.UI.Screens.MissionRecoveryDialog mrDialog, float recoveryScore)
{
if (pv == null)
{
return;
}
float modulesRecoveredFunds = 0f;
foreach (ProtoPartSnapshot protoPartSnapshot in pv.GetAllProtoPartsIncludingCargo())
{
modulesRecoveredFunds += protoPartSnapshot.moduleCosts;
}
modulesRecoveredFunds *= recoveryScore;
if (mrDialog != null && mrDialog.fundsEarned > 0f)
{
mrDialog.fundsEarned += modulesRecoveredFunds; // might not work if this is called before the stock callback, but this is UI only anyway.
}
Funding.Instance.AddFunds(modulesRecoveredFunds, TransactionReasons.VesselRecovery);
}You can eventually get fancy and create a dummy Also, you should probably check the KSP version since this only apply to KSP 1.11, you can do something like that : Version KSPVersion = new Version(Versioning.version_major, Versioning.version_minor, Versioning.Revision);
Version MinVersion = new Version(1, 11, 0);
Version MaxVersion = new Version(1, 11, 9);
if (KSPVersion >= MinVersion && KSPVersion <= MaxVersion)
{
// Suscribe to GameEvents.onVesselRecoveryProcessing
} |
There's no need to check for the KSP version on the Module, as they are injected selectively by the patch. See the files: 'KSPRECALL-REFUNDING' is registered on ModuleManager only when the patch is needed - the decision of being applied doesn't belongs to the Module, but to some other code where better strategic decisions can be made. |
Fellow Kerbonaut firethorn6 have a misbehaviour on his rig - as from KSP 1.11.x, the refunding at vessels recover is borked!
Evidencest:
A MK1 Pod and a Flea scaled to 2.8M (as anything bigger would not be allowed to launch on a early career). 2848 Funds.
I launched and immediately recovered it, to get the full refund:
And this totalled 2848 Funds. So it's working, at least on KSP 1.4.5.
So I redid the test on 1.7.3:
And it works too. Right now I cleared something wrong on TweakScale, now I need to check if something changed on KSP itself, perhaps on 1.8.1?
Nops. Worked fine. Just for the sake of completude, I did the test on KSP 1.10.1:
And again fine.
Well, gone to KSP 1.11.1 (lots of thing changed on this one, perhaps?)
Bingo. It's something on KSP 1.11.1. :( Interesting enough, the cost of the vessel is now 2883 (probably due the new Inventory system)
The text was updated successfully, but these errors were encountered: