Lisias

Yeah, I found it. However, KSPCF complains about it but don't tell me what part is being affected… (sigh) [WRN 18:28:28.343] [KSPCF:ModuleIndexingMismatch] Persisted module "TweakScaleRogueDuplicate" at index [13] has been removed, no matching module in the part config [WRN 18:28:28.344] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleIRMovedPartEditor2" at index [18] has been removed, no matching module in the part config [WRN 18:28:28.344] [KSPCF:ModuleIndexingMismatch] Module "TweakScale" at index [13] doesn't exist in the persisted part, a new instance will be created TweakScale is also being screwed by something else, and on a very critical section of code. [WRN 18:28:28.339] [KSPCF:ModuleIndexingMismatch] Part "SYsasR5m" configuration has changed. Synchronizing persisted modules... [ERR 18:28:28.343] Module TweakScale threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TweakScale.IsPartMatchesPrefab (KSPe.ConfigNodeWithSteroids node) [0x0002f] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.TweakScale.ExecuteMyUpgradePipeline (ConfigNode node) [0x00007] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.TweakScale.OnLoad (ConfigNode node) [0x00021] in <62ab179107a144c5a3808f0cd36a9f76>:0 at PartModule.Load (ConfigNode node) [0x001ab] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Curiously, TweakScale itself (and the Companions) didn't found any problems themselves... [LOG 18:26:25.253] [TweakScale] INFO: WriteDryCost Concluded : 2437 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 0 Sanity Check failed; 1329 unscalable parts. [LOG 18:26:25.262] [TweakScaleCompanion.Frameworks] INFO: SanityCheck Concluded : 2437 parts found ; 64 parts using ModuleWaterfallFX ; 0 show stoppers detected . [LOG 18:26:25.270] [TweakScaleCompanion.FS] INFO: SanityCheck Concluded : 2437 parts found ; 5 parts using FSbuoyancy ; 0 show stoppers detected . [LOG 18:26:25.278] [TweakScaleCompanion.KIS] INFO: SanityCheck Concluded : 2437 parts found ; 8 parts using ModuleKISInventory ; 0 show stoppers detected . So I think we have some toe stomping fest here - a problem happened, KSPCF tried to work around it but failed to do it properly, and TweakScale got itself in the crossfire without a gun. I will need your ModuleManager.ConfigCache for inspection - I have a tool that checks it "offline" with the same checkings TweakScale does "online", so I could diagnose problems when something screws TweakScale at runtime preventing it from doing its job. But since you send me one craft that it's borking, I could at least give a try and… I found that at least one of the faulty part is the "SYsasR5m", that it's a part from SpaceY. I know the maintainer, and gave a peek on the respective repository looking for the faulty part, but couldn't! Your installation is using: [LOG 22:37:22.616] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYsasR5m]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Control/SYsasR5m.cfg/PART[SYsasR5m] But on the SpaceY repo the path is different, so I'm betting you are using an old version of SpaceY. I suggest you install the latest release: Necrobones had passed the torch to @zer0Kerbal and he is maintaining it nowadays. I'm betting this can help in your case, but I'm not sure yet because I didn't found a repository for a SpaceY-Lifters with the old patching files (that you are using). So, do this: install the most recent version for SpaceY-Lifters and see what happens (remember to completly remove the all the old files, or things will be messy).

Oukey, first things first: TweakScale wasn't affected this time, so a lot of dangerous situations were dodged. However… Boy, there's a huge amount of problems, affecting a lot of others add'ons. Apparenlty one of the most affected is Wildblue: [EXC 22:50:55.938] NullReferenceException: Object reference not set to an instance of an object KerbalActuators.WBIServoManager.FixedUpdate () (at <d38e1d363e2b48c6b994849a11da901e>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Lots and lots of parts are screwed due this Exception. It's a wild guess, but I think there's a file missing on the installation: [EXC 22:44:21.801] DirectoryNotFoundException: Could not find a part of the path '/Users/rhycecomley/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/GameData/WildBlueIndustries/000WildBlueTools/Templates/CRP'. System.IO.__Error.WinIOError (System.Int32 errorCode, System.String maybeFullPath) (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.FileSystemEnumerableIterator`1[TSource].HandleError (System.Int32 hr, System.String path) (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.FileSystemEnumerableIterator`1[TSource].CommonInit () (at <9577ac7a62ef43179789031239ba8798>:0) System.IO.FileSystemEnumerableIterator`1[TSource]..ctor (System.String path, System.String originalUserPath, System.String searchPattern, System.IO.SearchOption searchOption, System.IO.SearchResultHandler`1[TSource] resultHandler, System.Boolean checkHost) (at <9577ac7a62ef43179789031239ba8798>:0) As a matter of fact, there're exceptions everywhere!!! [ERR 22:49:04.924] PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:04.950] PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:04.992] Module Valve threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:04.997] Module ModuleB9PartSwitch threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.009] Module Valve threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.010] Module ModuleB9PartSwitch threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.018] Module Valve threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.019] Module ModuleB9PartSwitch threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.025] Module Valve threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.026] Module ModuleB9PartSwitch threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object [ERR 22:49:05.564] PartLoader: Encountered exception during compilation. System.FormatException: Input string was not in a correct format. [ERR 22:49:05.575] PartLoader: Encountered exception during compilation. System.FormatException: Input string was not in a correct format. [EXC 22:49:05.951] NullReferenceException: Object reference not set to an instance of an object Benjee apparently is not exactly the troublemaker, I appears to be the trigger that was the straw that broke the camel's back. Well, this is going to wild ride. Lets try fixing WildBlue first. Reinstall eveything from WildBlue from scratch, and if the problem persists, reach the Maintainer asking how to fix the missing "GameData/WildBlueIndustries/000WildBlueTools/Templates/CRP" file. This is probably royally screwing WildBlue PartModules, and there's a chance that could be playing havoc with the PartCompiler, than so would screw up everything else. I don't remember, I do a lot of Support! Welcome!

Uh, yeah. I'm a too much old fart on Unix, as it appears. The goal is to send you some (read only) commands in order to understand exactly how things are in your filesystem, so I can try a workaround if needed Not old at all. I already had worked on a lot of issues related to Steam Deck, so this is something new on Deck. In which one? It must be in one of the following: /home/deck/.steam/steam/steamapps/common/Kerbal Space Program/KSP.log /home/deck/.local/share/Steam/steamapps/common/Kerbal Space Program/KSP.log Or, if a bind or a symlink is in effect, on both. By plain luck, I don't need the Player.log for this problem - but I think I need to dig a bit about where the Deck stores it, because sooner or later it will be needed. Don't lose your time with it, this is my job from now. Krapp. So the TweakScale binaries are on the PWD folder and not on the APPROOT. I'm afraid you are being bitten by this change request…. Apparently, the active installation is on the "/home/deck/.local/share/" directory, but the KSP being launched is on "/home/deck/.steam/", (sigh) Not related to TweakScale. this looks more like KSP-Recall not being installed, or being removed from the Part, or something new on recent KSP that I need to tackled down on KSP-Recall. Given that currently I don't even know for sure what's the KSP you are effectively running, I'm prone on believing this problem is related. Backup everything just in case. Since this is, apparently, an uncontrolled situation, we don't have the slightest idea what KSP copy will me moved to the SDCard, and what will happen if you move the thing back. Welcome and thank you! Please keep me in the loop, more and more people are using Steam Deck (hopefully me too in the future!), and I need to keep these guys happy! Cheers!

False dichotomy, I didn't said devs are not responsible for the mess. The development was and probably is problematic, and I stated that on my post. By the launch decision is over the Management shoulders. It's their call, this is exactly the reason they were hired at first place. Developers are responsible for development. As long the devs don't lie to their bosses, they aren't in fault for launching problems - and if they lied to their bosses, it's up to their bosses to take action on the problem the same. But since the last word about the launching is from Management, they are the ones that will answer for the consequences. It's simple like that, and it's the very reason Companies hire Managers at first place. The management is responsible for keeping scope in line from day one, it's on the Job Description! It's up to them to decide who is trustable and who is not, its part of their job in the same way writing reliable code is dev's job! Dude, this is the whole point on hiring Managers!!!! Failures are collective, successes are individual - this mantra only works between peers. Once you have a boss on the circuit, this dude is the one going to be credited for the results - again, we hire Managers for a reason. And this is not exactly what I had said on my previous post? Manager: "We need to go EA in February". Now we have two options: Devs: "We can't deliver a good and reliable product by that date". But the Manager says it will be launched anyway. Devs: "Yes, sir. We will launch on EA in February without problems". And the Manager believed them. In both cases, is still over the Management's shoulders the responsibility of explaining the Share Holders why they are going to lose money this month. If management insisted on the launch against the dev's recommendation, he made a huge mistake on not believing the devs. If the dev team had lied to him, he made a huge mistake on hiring unreliable people for the job. In a way or another, the Manager made a huge mistake.

I second that. This huge krapfest on the Early Access is Management's fault, not dev's. The devs are way over the schedule, and this is indeed their responsibility. But any backslash on the franchise due the Early Access being problematic is Management's fault, and they are the ones that should answer for the consequences.

Hummm... I only tested the thing using "new" crafts and savegames... I forgot to check how the thing will behave when you upgrade from an previous KSP-Recall. Addionally, the thing will only work when Refunding is applied to the part. If you have KSPCF installed (forgot, i will check it again later), then the Refunding thingy is deactivated - and so you will need to reach the KSPCF guys for a fiz for your problem. What reactor you are using on the faulty use case? — — POST EDIT — — Yes, you have KSPCF installed! This is the reason you wasn't getting any of the fixes I did on Refunding! Well, this settles the case - you need to ask KSPCF guys to implement something like this themselves, or you will need to deactivate one KSPCF fix and reenable Refunding from KSP-Recall. I'm checking how to do it and will edit this post soon™. — — POST POST EDIT — — @GoAHead, shove this patch somewhere on your GameData (as usual, I suggest GameData/__LOCAL/KSPCF.cfg) @KSP_COMMUNITY_FIXES:FINAL { @RefundingOnRecovery = false } Unfortunately, KSPCF dudes bluntly remove KSP-Recall PartModules disregarding their Settings - so by deactivating the RefundingOnRecovery from it, KSP-Recall's Refunding is not restored. Bad move, IMHO. Really bad move. Anyway, you will need to manually delete the file GameData/KSPCommunityFixes/MMPatches/ModSupport/KSPRecall.cfg in order to prevent KSPCF from deactivating KSP-Recall. Alternatively, you can just remove KSPCommunityFixes from your GameData, but you will lose all the other fixes from it. I opened a ticked on KSPCF github. I kindly ask users in need to have this fixed to reach KSPCF maintainers and reforce the need to have this issue fixed, https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/124

You need to install the file 999_Scale_Redist.dll into GameData! [ERR 03:12:13.080] ADDON BINDER: Cannot resolve assembly: Scale_Redist, Culture=neutral, PublicKeyToken=null [ERR 03:12:13.081] AssemblyLoader: Exception loading 'Scale': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0 I suggest you to install ModuleManagerWatchDog . It will automatically detect some problems that affect Module Manager and its patchings for you. It would detect this one, and you would had saved the time to ask for help here! https://github.com/net-lisias-ksp/ModuleManagerWatchDog/releases/

Sooner or later KSP (1) is going to die, being replaced by KSP2. Our grandsons will just have to cope with this.

ANNOUNCE KSP Recall 0.3.0.12 on the Wild, featuring: Reworks Refunding (again), this time with a better workaround for the really expensive parts, the preferential targets. Kudos to GoAhead for the heads up! Reworks issue: #60 Weird Misbehaviour on Interstellar Technologies This release reworks to Work Around published in the last one, with a better (or less worst) approach for refunding really , really expensive parts (and. boy, I'm talking expensive here). I can't prevent inaccuracies on recovering because I can't coerce KSP to use doubles on IPartCostModifier (and even if I could, this would break everybody), so I took the less friction path and decided to err in favour of the user: once a float inaccuracy is detected, I mangle the refunding to over-refund you instead of under-refunding. At the very least, you will be able to relaunch the same craft for sure if you recover it immediately. Since the values involved are absolutely insane (and, boy, I really mean INSANE), I would not consider a too much of a cheating this extra funds you will get due the stunt. @GoAHead, I could not check your savegame on my rig - it just can't run your modpack by some reason, probably related but some PartModule on the add'ons - I had launched way heavier GameDatas in the past on this punny excuse of computer I call a Mac Mini. In a way or another, I eye balled what I could and I'm optimist about the results for you. Please give this a try. And since we are here… — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Soon™ SpaceDock (and CKAN users). Also Soon™ 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.

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?