Lisias

Would be feasible to implement a search criteria so I can build a custom stream filtering content from SubForums I'm not interested in? Currently, Forum has the following Main Sectins (SubForums): General Kerbal Space Program 2 Kerbal Space Program 2 Gameplay & Technical Support Kerbal Space Program 2 Mods Community International Kerbal Space Program 1 KerbalEDU I would like to build a Custom Stream where I can flag some of them as "Not Interested". The current flood of "not interesting" posts are overwhelming, I'm facing trouble on following the Activities that I'm really interested in! Thanks!

Dude, I'm still unsure but if what I had read until this moment is true, you are on a daring situation! SteamDeck **used** to install things on ~/.local/share/Steam , but recently they start to use ~/.steam/steam/ instead. So, if this information is correct, you are launching one copy of KSP, but the PWD is being set to another (and probably older) copy of KSP. I think this is a bug on the Steam Launcher that failed to correctly migrate your shortcuts to the proper place after the new Launcher version was installed. I suggest you contact the Deck Support line and ask about. Pinpoint this post and the github one too for reference. I'm tracking your case here: https://github.com/net-lisias-ksp/KSPe/issues/48 And please let me know whatever they say to you!

Today is this one: The Trooper, from the #eternal Iron Maider: Ping @Daniel Prates!!

Probably bad patching. Publish your KSP.log and I will check for the problems. Last time benjee10 was involved on a report here, it was a rogue (and pretty old) Module Manager DLL that was installed by accident. https://forum.kerbalspaceprogram.com/index.php?/topic/179030-ksp-130-tweakscale-under-lisias-management-24623-2023-0207/&do=findComment&comment=4183107 Can't say. Sometimes it works fine, sometimes it will ruin your savegames - I can't tell before analysing your KSP.log!

Unlikely. There're also gears, lights, and lots of other things in need to be scaled!

Hi. Yeah, something changed on the way things work on SteamDeck, as it appears: [LOG 18:10:07.074] [KSP-Recall] ERROR: pwd != Application Root! -- pwd=/home/deck/.local/share/Steam/steamapps/common/Kerbal Space Program/ ; AppRot=/home/deck/.steam/steam/steamapps/common/Kerbal Space Program/ at error:0 [LOG 18:10:07.079] [KSP-Recall] "Houston, we have a problem!" about "Your 'pwd' doesn't match KSP's 'Application Root'!" was displayed Historically, a thingy called "PWD" (Program Working Directory, or Default Directory on Windows) is set to the same place where the KSP's binary file is. Things on KSP get slightly bonkers when this doesn't happens (KSP.log is placed on the wrong place, your UserLoadingScreens are ignored, and some other misbehaviours). In your case, your KSP is installed on the directory: /home/deck/.steam/steam/steamapps/common/Kerbal Space Program/ But that PWD thingy os being set to: /home/deck/.local/share/Steam/steamapps/common/Kerbal Space Program/ So, in theory, you are now susceptible to that misbehavirours I talked about. But this is linux - if one of the directories I mentioned is mounted as a BIND into the other (or a symbolic link), then we would have two different pathnames pointing to the same place, but since the KSPe thingy (a shared component of mine that takes care of some internal business) can't tell, it warns you about this weirdness so you can do something about - as asking me here what the hell is happening. When was the last time you did installed TweakScale before getting this message? Do you know how to open a X11 terminal on your deck? (if you can open a remote shell on it from your computer, is even better). The meaning of this warning is to be aware of any change that can affect KSP's behaviours, so I can check what's happening and be able to do something about, as to update KSPe (that internal business thingy of mine) in order to cope with this. Until recently, this KSPe library (used directly or indirectly by everything I maintain) was using the PWD in order to locate needed data, as well to write settings. This is standard Windows behaviour, but it was consistently used too on Linux and MacOS. UNIX way of life, however, usually dictates that we use the program directory ("AppRoot") to read readonly data (the GameData) and use the PWD for read/write data (settings, savegames, etc) and apparently SteamDeck is pursuing this Modus Operandi. As far as I know, everything and the kitchen's sink on KSP uses what the message calls AppRoot for everything but, if SteamDeck is really pursuing an UNIX way of life on the file system, backups on the Deck are going to be challenging now because everybody is writing things on the "wrong place". Can you check in your Deck where the KSP.log is located? In the AppRoot? In the PWD? Or in both? And, yeah, you are elligible for support - your current installation is not fully supported yet because I don't know what's happening, but as soon as we figure it out, KSPe will be update and so your installation will be fully supported. Eventually… In the mean time, you can ignore the message - but keep an eye on anything weird happening while playing KSP. How the savegame is being handled is partially concerning for me in this moment. — — POST EDIT — — @AZZlyTheAZZome, I opened a support ticked for easier follow up: https://github.com/net-lisias-ksp/KSPe/issues/48 BOTH paths appears to be valid in SteamDeck, but not a the same time!

I diagnosed a problem related to recovering funds on very expensive parts on career (and I really mean expensive! ) and so did a huge amount of tests - and some of them ended so absurd that it would be a crime not to share them with you! Like this one: THIS is one of the reasons I love this little freaking game.

Humm… This thing is working for me, I'm just did some tests right now radially attaching some fuel tanks and everything gone fine. What parts did you used? — — POST EDIT — — Don't bother! I understood what happened! The problem you are reporting is a known issue, and is already fixed on TweakScale Beta (the almost ready for production TweakScale 2.5 series). Problem is that backporting it to the 2.4 codebase incurs in efforts that I prefer to invest on finishing 2.5 - there're a lot of things that will make things happen faster and safer on the 2.5 series. Since we are here, let me explain for you what is happening. TweakScale initially had only two types of Scaling Types: the stack and the surface. The stack one is still the same, but the surface was a special scaling based on normalised values, where 1.0 is the default and anything from lim(size->0) to 4.0 (or bigger, if properly configured) is the scaling. This setup was convenient because applying surface scaling to stack parts and vice versa are intuitive. But later it was decided that Percentages were a better way, and instead of fiddling with the UI (essentially, multiplying the scaling to 100 and printing it on a Tweakable), a whole new Scaling Type were created for them, free, and everything was converted to it. More or less at the same time, the Auto Scaling and the Chain Scaling broke due a silent change on the KSP API and where removed. Recently I found a way to resurrect Auto Scale and Chain Scaling, but I didn't realised the problem created by percentages - the original code didn't knew squat about all of this, and so when you attach a free scaled part radially into a stack one, the scaling exponent used is 1.0, that free understands as 1% !! Pretty lame mistake, I know - but hell, it passed trough unchecked for some time. Anyway, I had it fixed on 2.5 because a lot of things changed on it and all that jazz made it easier to cope with different scaling types - so, if someday someone decides to use Imperial Measuring on TweakScale, things will just work without fuzz. But the bad side is that I would need to backport everything into the 2.4 series, what would essentially be rewriting some things again. I ask for a bit of patience to have this fixed on the mainstream - The 2.5 is nearly 99.99% ready for production (famous last words, I know), and the only reason it's not published yet is because I need to push the TweakScale Companion thingies into production first, but I getting some problems to get is published on CKAN and so I'm delaying it a bit until I have this last mess sorted. Cheers!

Emerson Lake & Palmer. I didn't knew this one, and I consider myself a fan!

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.