Lisias

You are not exactly right. But, this is not the place for such discussion. I would suggest to everybody what I usually suggest to anybody: call a friend or relative lawyer on your country and talk about. Better safe than sorry. I'm not trying to tell you what to do or not - I'm just talking about the need to know the consequences (if any) on doing something in your country. European Union, as an example, is extremely consumer friendly on the matter - as long you don't distribute copyright infringing material in the process.

Hi. There's nothing obvious in your KSP.log. We will need the Player.log to diagnose this one, as whatever happened on your rig, killed KSP on the spot - but Unity itself logs something on KSP.log Player.log before exiting, so we still can diagnose the problem. Check this thread about how to get the Player.log:

Hi! Your logging is insufficient. I need the full KSP.log in order to help you. Please check OP, inside the spoiler uner the title "Support:" about how to proceed.

I will keep you informed about my findings. In time, digging on the KSP API, I found that the Funding class is using double, so the problem is not inherent to KSP guts - it's something between me and the Funding class. I will still need to bash my SAS on the problem, but now it appears to be on my reach without unholily shenanigans. On the other side, why in Kraken's name the IPartCostModifer is still under float is a mystery to me.

Thank you! And, yes, the savegame is the important thing now. You are confirming my diagnosing, by the way. You are being bitten by how KSP computes currency, using floats (singles) instead of decimal or BCD (BigNumber on some languages). Using double mitigates the problem for now, because it have twice the size of the single's mantissa and so it takes a lot more to loose accuracy - but theoretically, it will dot it eventually. When handling currency, BCD or similar are, really, the only safe way. You can get yourself in legal trouble in some legislations by using floating point math on currency. I will download your savegame and inspect it soon™ (have some domestic duties to carry on), but the scenario appears to be clear by now: you have a certain amount on Funds that, once stored on a float, overflow the mantissa's resolution and so the general magnitude of the value is simulated using the exponents, at the expenses of accuracy (see my example on my previous post). When recovering the craft, the value of it, after being squashed to fit your wallet's exponent, loses some bits of its own mantissa and this is the reason you are losing Funds - "unholy" roundings happening while KSP sums things up while squashing everything into a mere float instead of something more robust. There's no real fix for this one, other than rewriting KSP's handling of Funds. Changing the IPartCostModifier interface would be ideal, but not strictly needed (the losses at this point is about less than 1K Funds for vessels costing more than 100.000.000 F), so the burden of recompiling the World will not be worth the pain - as long the Agency's Account is handled on a more robust datatype, things would be fine in the long run. This is beyound what can be done by a PartModule, however. I'm going to need some bigger guns to tackle down this one. I'm afraid I will not be able to offer you a fix as fast as you would want. But I'm working on it - somehow. — — POST EDIT — — I was wrong! Funding is being handled as doubles by KSP! https://www.kerbalspaceprogram.com/ksp/api/class_funding.html I fail to understand why IPartCostModifier is using floats, however. But since the problem is not inherent to KSP guts, it's again something I can try to tackle down from my side.

On countries where the thing is a Felony, the rules differs. Murderer is a Felony, as example. The mere accusation can trigger the police in seizing you and your digital assets. The prosecution must prove violation for keeping you in jail, not to seize your assets. Or even arrest you. Yes, it requires significant resources, begin the reason such stunts are applied now and then to some few chosen ones. Anyone willing to play roulette? In time - who decides if my actions harm the product? What's the criteria? How many years I need to worry about, if by some reason something I did is considered harmful? Anyway.

People underestimates the Legal Systems of different countries. Very few Countries in the World follow the same Doctrines followed by USA's Common Law. Some Countries plain declare null and void the EULA's clausule about arbitration. Point. A very few ones see Decompilation as a Felony and, so, you would be prosecuted under the Criminal Law, and not on the Civil one. I'm not telling I agree with this, but Law doesn't require my agreement, only my obedience. Since PD probably wants to have KSP2 being sold everywhere, without risking any of the paying customers to be dragged on legal problems in their country by something published on this Official Forum, I'm not surprised the Add'ons publishing rules states what follows: That said, it's up to the Forum administration to decide to apply the rule or not. But if the rule is not going to be applied, why it was written at first place?

I got a misbehaviour that could be explained by skipped Updates on my old potato running Unity 2019 under heavy load - what's, frankly, all the time. I considered placing a log on the Update in question, but rapidly realised that doing disk I/O on it will induce huge latencies, screwing up the test I wanted to do at first place. Interestingly, things got incredibly smoother once I set MONO_THREADS_PER_CPU=1 on my rig. Now I can run KSP >= 1.8 on my old patato, and I can even enjoy it a bit as long the craft is under 40 or 50 parts. Without the MONO_THREADS_PER_CPU stunt, I got a slideshow already on the Main Menu, what to say flying something. My suspicion of Updates being skipped, however, is not due the stuttering, but due some exploratory code of mine failing under heavy load - and the most plausible explanation for it is the Update not being called. (and, yeah, the MonoBehaviour.enabled was set to true!). That was a major bork on mine. I had googled for the subject, ended up finding what I wanted to find and got myself trapped on confirmation bias. I should had read that thread way further than I did, but failed on it and ended up wasting your time. My apologies.

Don't bother, I already have the minimals. Now I need something concrete in order to know when I reach a good enough result - the usefulness of the minimals was expired. Whatever is the craft you are getting the misbehaviour, is the one I need now to use as benchmark. Don't mind the add'ons you used, this time I need to get my pawns dirty the hard way to get the results I aim. — — POST EDIT — — Oukey, I did what I do best: I tortured different versions of KSP about the issue until they talked. The whole test session starts with this comment: https://github.com/net-lisias-ksp/KSP-Recall/issues/60#issuecomment-1445226847 TL;DR: KSP 1.11.2 with Recall is recovering more funds than KSP 1.9.1 without, where there's no one trying to workaround the fund recovering problems. On 1.9.1, I lost 779 Funds on the sample craft. On 1.11.2 with Refunding, I got an extra 61. I wish I could install Refunding on my bank account. Serious now, it's really a float inaccuracy problem now. I put WarpPlugin in check, and it passed with flying colours - it is using doubles on the currency computing, what's really good enough for the amounts we are handling now (decimals would be the perfection, but double is good enough and, well, are faster). @GoAHead, I'm pretty convinced that you are being bitten by KSP now. Please just zip your savegame the way it is now, and then tell me the name of the craft where you are being screwed. I don't need to load the savegame, I know where to look now by screening the files. What I need to do is, as I said, get the current values being used by your savegame so I can benchmark them on my development rig. I will forge a simple savegame but using the values I find in yours, and then I will try to fix the float robbery by trying to steal back the error to your agency's account. As it happened on my tests using 1.11.2, I probably won't be able to steal back the right value because the float's mantissa will not be able to represent it, but a little extra funds are better than too much less, right? — — TECHINICAL MAMBO JAMBO — — To simplify things, I will explain how a floating point number works by using decimal numbers, way more easy to cope than binary or hexadecimals. A FP number has two numbers, the Exponent and the Mantissa - let's suppose we have a type of decimal floating points that can hold 4 decimal digits, 3 for the Mantissa, and 1 for the Exponent. The number one would be stored in memory like 001.0 - where the dot is just to separate the mantissa from the exponent so we can easily work with them. In Scientific Notation (science stuff!), we would write 1e0 , or one to the zero power. Interesting enough, since anything to the power of 0 is 1, the very same number can be represented in memory as: 111.0 100.0 010.0 etc So, we now had established that this representation can be somewhat wasteful. But it has its merits, because with only 4 digitis I can write some really big numbers using only 4 digits, as 1e9 or 1,000,000,000 and not using 10 digits as I did now. But there's a catch: I can't represent 1,000,000,001 !! Because I have only 3 digits for the Mantissa!! Using a 9 as exponent, I can only represent the following numbers: 001.9 = 1,000,000,000 002.9 = 2,000,000,000 ... 999.9 = 999,000,000,000 You see, everything under 999,999,999 is squashed - you lose precision. Now, on real word, since the floats uses 4 bytes in binary notation, the standard says that for 4 bytes floats (32 bits), we represent things as: 1 bit for the signal (positive or negative), 8 bit for the exponent (-127 to +128) and 23 bits for the mantissa. We use base 2 for this representation, i.e., our numbers have only 0 e 1. The same way we can count from 0 to 20 in decimal this way: In binary we count: Both lines are the same numbers, but on decimal we have more digits to play before a "carry 1" when we reach 9 (i.e., when we run out of symbols). With doubles we have more bits for exponent and mantissa, so bigger numbers with better precision. But since GPUs cards are optimized to handle floats e not doubles, Unity choose to stick with floats internally. KSP uses doubles for the physics - converting between them all the time can lead to problems, but this is another subject. Understanding floats in binary is a bit scary, but someone had this excellent idea: https://bartaz.github.io/ieee754-visualization/ You can flip the bits, or type numbers, and see how they are stored in memory. You will understand, by toying with it, why some numbers can't be accurately represented on floats. The way I solved the problem on Refunding, was by using a C# datatype called decimal. This thing is a huge bitstream with 128 bits, being 96 bits representing a binary integer value and the remaining 32 bits are flags and the Scaling Exponent. These numbers are different from the Mantissa/Exponent used on IEEE 754 (the IEEE standard almost everybody uses for floating points), but they play similar roles. The end result is a way slower computing, but with way better accuracy. Since the number ends up squashed to a float by the IPartCostModifier interface, Refunding can't assure the accurate value will propagate into KSP - but at least Refunding is not pilling up inaccuracies itself. It was using doubles before, but part of the computations were scaled down to floats due this begin the datatype used by the Resources's amount and cost, and this was an error (as I was pilling up inaccuracies while cimputing the resource's costs). Things are better now because the inaccuracy happens only once, when the final (good) result is squashed to a float by IPartCostModifier. But depending on the value, it will be enough to still screw up the recovery. I will try to calculate this loss, and then compensate for it on the process.

What doesn't changes the fact that all you need to check KSP1's assets is Windows Explorer and Notepad. Hard to say KSP2 made things easier for the beginners. If you need to be a professional on the field to mod KSP2, the franchise lost contact with its fanbase by a mile.

The Refunding stunt is, well, a bit fishy by itself. I'm (ab)using the resources to counter-screw the KSP's failure on correctly calling the iPartCostModifier interface of the PartModules on recovery - at the same time preventing screwing up with other code that is doing it, so when the Refunding resource is active, the PartModule's IPartCostModifier returns the negative value of it to prevent 3rd parties from being fooled about the cost of the craft. I'm, literally, leveraging the KSP's bug against itself. And over it, yes, we have this float on currency happening. What I can say for sure is that, now, Refunding is definitively out of the loop of the troublemakers. The only enemy left is the unhappy use of floats when handling IPartCostModifier. What doesn't means I can't try to do something else - but I need to do it carefully, because I may inject undesired side-effects on 3rds parties as it happened with MAS. I'm over my toes now. Well, back to the designing table. Please send me your craft file (you can zip it and drag'n'drop it on a post on the github issue, if you have a github account: https://github.com/net-lisias-ksp/KSP-Recall/issues/60 ) so I have something concrete to work with. I have some new crazy ideas… But I need to figure out what of them are just plain stupid.

ANNOUNCE KSP Recall 0.3.0.11 on the Wild, featuring: Rework Refunding to use decimal when handling currency to minimize losses due inaccuracies related to float point math. Kudos to GoAhead for the heads up! Closes issue: #60 Weird Misbehaviour on Interstellar Technologies This releases mitigates (besides not solving) a problem related to KSP using floating point math when handling currency, reported by the Fellow Kerbonaut @GoAHead(thanks a lot, dude!). The problem happens because floating point math induces inaccuracies when numbers are big (or small) enough and the whole number can't be stored into the Mantissa anymore. Refunding, the component working around a bug on KSP while recovering crafts, was updated to use decimal instead of doubles while handling currency, eliminating such problems internally. This makes things better (or less worse), but doesn't completely solve the problem as the IPartCostModifier, the interface used by KSP to ask the PartModule for its cost, is still using float - so, in the end, really big or really small values are still going to get screwed. But at least I could remove some inaccuracy, as they are not being pilled up inside Refunding anymore. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Will not be published due a new release. SpaceDock (and CKAN users). Will not be published due a new release. I would like some early adopters to install this thing and use for some time to be sure the stunt I pulled while persisting the current PartModule cost on the Config File will really work in all the use cases.

Yep. Problem is that by doing it, they are risking creating the failure themselves. Most of the backslash is coming from the pricing being asked. Had they published a very minimalistic demo by 10 bucks, you can bet your mouse they would having way less criticism. Software Development is way counter intuitive - the current state of affairs doesn't means necessarily that they screwed up. It probably means that their current customers are the Content Creators and not us, but then some pointed egg head forced the hand on publishing the thing as is and Kraken help us all. The Content Creators need tools to do their job, and if the dev team spends time polishing the engine for us before the Creatives have their tools, we would have no Content at all.

Good to know, and it's fine to me. But I would prefer that the P/R guys didn't started this fire by enticing us with this "day one" buzzword because, hell, the only way to do that right now is by violating the forum rules!!! Source.

Moving back from the KSPIE thread. — — — the "IXSMainHullReactor" worked fine (or almost) on my rig, the refunding were happening almost perfectly. I'm recovering almost all the 44.5M Funds, with an error of less than 1K Funds (I started with 45.000K and ended with 44.999K). The problem appears to be related to the huge amounts of Funds involved, I think we may be handling a float rounding error on this one. In time, it's the reason using floats on currency in Real Life™. I also tried the "MuonCatFusionReactor2", but scaling it down to the 1.25M of the Command Pod Mk1. Interestingly, I got the same problem on this one - I started with 100.000F and ended up with 99.999F - an 1F error. @GoAHead I think this is not a "problem" neither on KSPIE, IT or even Recall - this appears to be related to using floats for currency calculations! I can mitigate a bit the problem on Recall (by using decimals while handling currency), but I can fix it 100% because KSP itself uses floats, so this is beyound my reach: I can't fix it, all I can do is to minimize my role on the problem. I'm working on it. My apologies to FreeThinker by polluting his thread, I genuinely though this was a IT problem. @GoAHead, lets keep this on the Recall thread, please!

Dude, you nailed it! Thank you very much! This is not a problem on KSPIE, IT or even Recall. This is happening because KSP uses floats for currency computing. Lets handle this on Recall thread, as any mitigation measures will be implemented there. My apologies to FreeThinger by polluting his thread, I genuinely though this could be something triggered by IT on one of your PartModules.

Well, not exactly "Not a Problem"… From the Add-on Posting Rules: So… Not so modding friendly after all. The very initial efforts for modding KSP2 is in violation of the Forum rules for modding...

So, no public API and we are back to hacking the game as we did in KSP1. Not a problem, but I remember Nate talking about a public API and dismissing Manley's concerning about decompilations et all.

As long you don't try to create threads for background processing - or, if you do, you don't use any Unity calls. I'm not talking about lack of parallelism on Unity. I'm talking about threading being not the preferable way to do it - to the point Unity itself is royally screwing you if you have too much cores with too many threads available (see that link of mine about MONO_THREADS_PER_CPU). My point on my previous post. It can be useful when you have a lot of crafts scattered in the Universe, but managing colliders for near crafts can be slightly more complicated. You will, at very least, need to synchronise the threads before checking for collisions - what probably will waste any savings you got with the stunt on a low craft count gaming. Now I'm guessing - so taking anything I say here with a considerable grain of (iodized) salt. It's my understanding that in the same way the Unity's Update callbacks can be skipped under heavy load, so do the Burst jobs. At least, is what some posts on Unity forum is telling us. If you built a job to handle the fuel system, and the job is skipped by some reason, well… You have a faulty fuel system with a misbehaviour really hard to diagnose...

It wasn't told to us that they were expecting modders to jump in on day 1? How?

Well… This is a collateral effect of Refunding (ab)using the Resources in order to correct the mistake Stock is doing while refunding your craft on recovery. The thing calculates how much you should be refunded, and then creates a "fake resource" that will add or subtract an amount of resources priced in a way that in the end you get the refunding you deserve. I had noticed that resources were being correctly handled by Stock, the sole problem is not calling the "IPartCostModifier" on recovery. I had set the Refunding "meta-resource" to be invisible, but on recovery the game show it the same.

Make no mistake, I believe you. I had dealt with similar problems before - what makes me very uncomfortable is that a few of them just vanished from the surface of Kerbin, and I never diagnosed the problem neither understood how it happened. This could be a race condition - but this is wild guessing right now. I'm rebuilding the test bed, I will come back to you soon. — — POST EDIT — — I **confirm** that on my rig, KSPIE is not being affected by the but - or, at least, the part I used. See https://github.com/net-lisias-ksp/KSP-Recall/issues/60 for the details, screenshots and zip files. @GoAHead, please try to use the same part I used ("Antimatter Catalyzed Fusion Reactor", the kspiWarpCoreUnit2 on WarpCoreUnit2.cfg.) and see what you get. I may be dismissed KSPIE too soon, but if by any reason the very same part that works for me () will bork on you, then we have an environmental problem - and this is going to hurt a bit to diagnose...

Yes. Up and down. Humm… So you are telling me that the behaviour had changed? This is really uncomfortable. I'm redoing the tests tonight, I will edit this post with the results.

TL;DR: reactors from Interstellar Technologies are being misrefunded, but reactors from KSPIE - at least the ones I used on my testings - weren't. The affected PartModule is IntegratedThermalElectricPowerGenerator. Again, only the part configs from IT were triggering the problem on my tests, KSPIE parts using this PartModule didn't triggered the problem for me. On one specific test (using the rbug.craft provided) reproduced the misbehaviour using Interstellar-Technologies-ICFSC-Reactor, but when I replaced it with kspiWarpCoreUnit2, the problem was gone for me.

I was talking about a hypothetical concurrent physics engine - if you have many threads simulating different partitions from the world, you need to syncronize them before detecting collisions, otherwise you will get some pretty hard to debug bogus collisions due race conditions.