Lisias

One thing that now and then happens to me is an unintended (and unattended) "quick click" over a file while moving the mouse - sometimes, the computer is overloaded with something else and then it takes some time to process the "unclick" event - and then acts as we were dragging the file. Kraken knows how many times this happened to me. (on MacOS, the information used by a process are retained for some time in the case the user closed the program by accident, but this completely screws us up when we close the a big program like KSP purposely and then open it again - or another version of it - damn, this royally screws me up, as the memory consumption goes into the stratosphere and the machine gets sluggish, making it more prone to the problem)

There's something wrong on your Firespitter installation: [ERR 06:42:04.411] [ShipTemplate]: No Resource definition found for RESOURCE [WRN 06:42:04.411] PartLoader Warning: Variable SSS_Tier not found in Part [LOG 06:42:04.412] FSCoolant not found in resource database. Propellant Setup has failed. [ERR 06:42:04.413] Module ModuleEnginesFX threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object at ModuleEngines.SetupPropellant () [0x000a4] in <4b449f2841f84227adfaad3149c8fdba>:0 at ModuleEngines.OnLoad (ConfigNode node) [0x000d7] in <4b449f2841f84227adfaad3149c8fdba>:0 at PartModule.Load (ConfigNode node) [0x001ab] in <4b449f2841f84227adfaad3149c8fdba>:0 No to mention that you have a rogue DLL installed on the wrong place! [LOG 06:37:54.410] Load(Assembly): /Firespitter [LOG 06:37:54.411] AssemblyLoader: Loading assembly at C:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Firespitter.dll Remove all Firespitter related files from your rig and reinstall from scratch. The latest Firespitter release can be found on https://github.com/snjo/Firespitter/releases

Apparently it's missing a dependency. Did you installed Firespitter? If yes, send me a full KSP.log and I will check what's happening.

Posting the KSP.log so people can inspect it will surely help!

Post the KSP.log file and I till inspect it for the culprit! Almost surely it's a missing dependency or something silly like that

Wait! Just restarting fixed the problem? Seriously? damn!

AppLovin will try to buy Unity3D again, taking advantage of the pretty low stock values at this time. BOY, I knew this was going to get yet more interesting! https://gameworldobserver.com/2023/10/13/applovin-unity-acquisition-second-attempt-citibank-report The Winter is coming!

I hope you know a pretty good otolaryngologist specialised on hot ears. Same here. It's incredible how Sao Paulo's skies have this ability to get clouded on WeekEnds and special events - while being usually clear at working days at this time of the year. Yeah, good weather on working days, rainy on weekends. Marvellous. I'm not even mad, because I was pretty convinced this would happen so I didn't bored to prepare for this event. Oh well… People on Youtube will surely broadcast it. I will watch them under a blanket and a nice cup of tea on my hands.

Handle them the way you say their clients should be handled, and see what happens so.

What's making your position yet more inexcusable, because it's exactly our "luxury" that puts food on their table. We, gamers, are the sore reason the Game Industry exists! NEVER forget about that. Again. So say we all. Well, when you say it to the very people you expect to give you the money you need for doing your job… Yes, it is. It's incredibly obtuse - and many things more that would probably violate some Forum's rules. Apparently, some game developers are in need of a serious reality check. The Winter is coming. There's this point on their argument that I'm inclined to agree with: we don't need to engage on character's assassination and smear campaigns neither. In a perfect world, we would be criticising them for what they are doing wrong, not by not doing what we think is right (most of us don't have a clue!). It's really disgusting how some few influential people ends up pushing their weight unchecked on technically unsound opinions and even harming advices, while the developers are being thrown on the fire on a witch hunt. I agree with you that cheering them is exactly what should not be done right now, we just don't reward bad results - point. But what's being done to them instead is equally evil, perhaps worse. — — — Some time ago I had opined that they should had halted the sales, gone (almost) quiet and focused on fixing the product - exactly like Hello Games did with No Man's Sky. And using the Marketing and P/R team to push KSP¹ ahead in the mean time, keeping people interested on the Franchise - perhaps giving the whole KSP¹ stack for free for anyone that bought KSP2 and didn't refunded (and something similar to the ones that already have them - perhaps some of the perks of the shop?). Bluntly stopping KSP¹ development with all the terrible bugs was yet another major mistake, IMHO. Actions have Consequences. Absence of Actions, too.

Sir, you just implied that End Users didn't have to work (hard, most of the time) in order to earn the money and have the free time needed to spend on games. WE ARE FIGHTING FOR PUTTING FOOD ON THE TABLE THE SAME. Game Developers are not the only ones bashing their arses around here. I can understand (and respect) @Periple and @Pthigrivi points of views, besides not agreeing with most of them - but yours, definitely, it's beyound reasoning.

What's the difference? Developers are Unity's clients. Users/fans are Devolopers's clients. It's exactly the same. It's not my job to give hope to anyone. I'm just using my free time to exercise my opinion about the current status quo. I suggest you redirect your concerns to people that are being paid to do such. I!m just telling you what should be obvious: failure on managing your clients expectations will doom your job and hinder your employability. Exactly as it's happening to Riccitiello. It's not my job to secure anyone's else job! I will answer your question with another question: do you think it's fair to Riccitiello to be purged from Unity Technologies due a mistake? He was doing a decent job since 2014, as I had heard, why Developers didn't just acknowledged his efforts and just agreed to pay the install fees? Do you know how many Unity Developers are going to be laid off because of this? How many features will not be implemented anymore on the engine? Wouldn't be much better if the Developers had just agreed with the new payment model without this hurting boycott, securing Unity's funds so they can keep pushing features on this marvelous engine?

How many? Nope. It's exactly the other way around. It's very productive on preventing stunts like that to happen again. It's exactly what's being done on Unity Technologies, by the way - the ad boycott is still ongoing, and the first signs of the consequences is already happening, Riccitiello not only stepped down as CEO, but also from the Board and every single position he had on Unity Technologies - my opinion is that it's not enough, more people need to be purged, but it's not up to me to decide. Actions have consequences. It's more than due time to users start to react against abuses from the Game Industry: Fool me once, shame on you; fool me twice...

The lobby is for the sales being halted or the game cancelled - it's a pretty different thing of lobbying for the game being cancelled, period. Additionally, the claim for the game being refunded is not unfunded (pun not intended) and, frankly, would be a income of fresh air on an increasingly smelling industry that are consistently flirting with law breaking practices. It's more than due time that people start to being withhold to their responsibilities. Granted, the Game Industry is not the only IT related industry needing such call out. And exactly what's the difference?

Nate is confirming things that don't happen for some time now. It may be his fault, or it may be not - I don't have a clue about the reason he did such affirmations - but in a way or another, the net result is that… Something being confirmed by Nate is not exactly something to be blindly thrusted. I agree that the marketing and sales should had been suspended since day 1, when the launching fiasco was blatantly clear. But having a "skeleton" crew working on the game now is not a symptom of degraded development. A game is way more than code, really, really way more than coding. Missions, meshes, textures, drawings, design guidelines, scene design and editing (or, in their case, celestial bodies - as everything is just the Flight Scene), you name it - all of that demands lots, lots of workmanship. Expensive workmanship. So, from the project management's point of view, once you realize that the coding is going to demand more time, it's make perfectly sense to focus all the development efforts on everything else to avoid unnecessary costs - what leads to the development team coding only what's strictly necessary to keep their pipelines full and screw the playability - this can be added later, with all the other artefacts already delivered. Now… Selling the prototype used to keep the creative's workflow pumping as an Early Access, that was scummy, I agree.

There's something very wrong on your rig, I found no messages related to the TweakScale's booting process, it's like the patchers were installed, but not the DLLs. How did you installed TweakScale? What version are you using?

I don't know what's happening with this industry, but I'm not liking it. Thunderbird just forced the update to that crappy SuperNova version - buggy as hell. Fortunately, this is Open Source - no one can force you to use something if you don't want it. — — POST EDIT — — "users will just have to get to used it. We feel the old way is distracting.". https://blog.thunderbird.net/2023/07/thundercast-podcast-3-behind-the-scenes-of-supernova/ (Jesus Christ - Thunderbird is over with these guys on the helm…)

Usually I would be too, but since last year I'm getting bitten by "mysterious" events on KSP that came and gone out of the blue - and one of that events caused something similar to what happen to you. And it vanished exactly the same. I checked KSPCF latest release, and indeed they found a point to make things better on their Exception Reporting tool - but I didn't found any change related specifically to the GetTypes thingy, what suggests that whatever had hit us, came from "somewhere else". On the bright side… I learnt something new (and interesting). I'm still unable to fix these problems, but I'm a bit less "defenceless" now. Cheers!

Like water on rocks. As a matter of fact, there's not too much we need to do, because Life is already doing it for us. I'm being relatively silent the last weeks because, as usual, I'm debugging problems and - guess what? - the closed source way of patching things is already screwing up the game. Before going ahead, let's make perfectly clear that there's absolutely no sign of malice on what I'm going to describe below - but, yet, the fact that it can be easily misunderstood as malice is already a big (snip) red flag raising under our (and their) noses. It's not a secret anymore that KSP¹ is being monkey patched by our backs - silently, and without warning. You fire up your KSP today, and out of the blue it behaves differently from yesterday. Like happened to me last year while coding a support library for Airplane+: Interesting enough, the problem vanished on the early hours of the next Monday - what a coincidence, no? So, the Genie is out of the bottle: Squad (and/or TTI) are monkey patching the game by our backs. Of course they intend to fix problems on the wild, but we need to rise some concerns about this practice; It's legal all over the World? AFAIK the European Union have some restrictions about things changing on the user's machine without explicit authorisation... If they didn't managed to fix the game while it was being developed, exactly why we should believe they will be able to do now? Frankly, I expect the same results we got in the past, with fixes for old bugs creating yet new bugs, on a endless feedback loop. Sooner or later this may be exploited by adversarial parties - i.e., KSP¹ will be used as a vector to distribute malware. The freaking game has no DRM, has it? Exactly what's preventing an adversarial from perverting KSP¹ to download… "interesting" things? And even if they managed to keep the thing secure, the fact is that self-updating code is already a tremendous pain in the ass nowadays, and I'm really surprised there's no legal forces yet advocating for banning this practice. This madness must stop somehow And, so, KSP¹ (and everything else) will just be flagged as malware - assuming this is not happening already. And have I mentioned that having a bunch of people doing MonkeyPatching at the same time is a receipt for disaster? No? Now I have: TL;DR: Someone Monkey Patched something to fix a problem, but this screwed TweakScale because another dude was already emitting CIL code at runtime and the Monkey Patched thing didn't accounted for that, and so we had replaced a nasty bug on the Assembly Loader/Resolver affecting people loading DLLs with a WORST ONE affecting everybody. TweakScale is only one of the victims - but since it's pretty used, it's under the spotlight first. All of this has happened before, and it will all happen again. None, absolutely none of that problems affects Open Source - once you have a secure channel to download binaries, of course. But as long the Source is available and anyone, absolutely anyone is able to compile and double check the integrity of the artefacts, the game will be safe - worst case scenario, we shutdown a rogue channel and replace it with a new one. We (OSS) have bugs? Yeah, damnit, we have a lot of bugs. But they are all on the open - and we are seeing each other trying to fix them. Everything is trackable, we don't get locked between a rock and a hard place as it's happening to me right now - because I'm completely unable to even further diagnosing the problem, because I didn't managed to pinpoint exactly where it is for sure (I'm guessing it may be related to KSPCF, but yet, it may be just another victim of the problem being involved because it handled it before). — — — POST EDIT — — — For anyone wondering if I'm pushing things too far with my argument against Monkey Patching: Valve adds new security check after attackers compromise Steam accounts of multiple game devs and update their games with malware https://www.pcgamer.com/steam-malware-attack-new-security/ Sooner or later an adversarial will realise that KSP is, right now, an excellent vector for Malware distribution. I think we should start to look to this problem before we got hit by something.

Hi! I'm diagnosing some issues related to RunSharp.dll that it's being distributed by KEX, and realised that RunSharp is not mentioned on the OP neither on the KEX documentation. Forum rules says you need to provide the source code for everything you distribute for KSP, so I suggest you pinpoint the RunSharp repository you guys are using on the OP: https://github.com/AqlaSolutions/runsharp . Cheers!

About these errors, send me the MMPatch.log and the KSP.log and I will check what's happening. Chances are that I already had fixed it on the TweakScale Companion for OPT, by the way. Idem for TundraExploration, but this Companion is still work in progress. KerbalUsabilty is a new problem AFAIK. Anyway, send me the KSP.log and MMPatch.log files and I will check them. About Kopernicus… Well… That's the history: since some time ago, some folks around here decided to deeply change some code on KSP using Harmony or similar (RunSharp appears to generate CIL code at runtime - something like having a compiler embedded with your code). I'm one that criticise this practice due the incredible chances of screwing other people - usually people that are doing things right, and are caught in a crossfire by a new situation that never happened before - exactly what caught me with my pants down right now. I concede that sometimes there's no other viable way, but yet… Before 1.8.0 Kopernicus wasn't using any of that shenanigans, so apparently it's possible to avoid using them - but take this with a grain of salt, because there's a limit for what is doable without these things. But yet, I really try hard to avoid them, even by doing things in the hard way. The whole KSP-Recall uses that "hard way" concept - I reimplement the feature that it's misbehaving, instead of trying to fix it injecting new code on the system (what's not exactly allowed on this Forum, by the way) - the reason I do things this way it's clear by now. It's virtually impossible to foresee every consequence of changing already stablished code that will so behave in a new way, we never know when we will be hit by a new bug. Exactly what's happening now. I will try to fix KSPe (my personal library that I use on everything I do, kitchen's sink included) and so I will really need to fix this thing only once (deployment will be my problem, because I didn't managed to push KSPe as a reusable library on SpaceDock's eco system as I did on CurseForge), but keep in mind that a lot of add'ons around here also use Reflection the way I do, and they are going to get hit the same. — — POST EDIT — — As a matter of fact, I did a search on all my archived Logs and found this "RunSharp.dll" on some logs from my support "tickets" since Nov 2021. Interesting enough, the RunSharp's induced "Unsuported" Stunt didn't screwed TweakScale all the time - sometimes TS passed through unscratched. — — POST POST EDIT — — That's precious! (I'm being sarcastic) This problem is unfixable by me!!! The Exception is being thrown inside a method called GetTypes_Patch1 on System.Reflection.Assembly.System.Reflection.Assembly that does not exists for me. The "RunSharp.dll" is, indeed, a tool for making easier to use System.Reflection.Emit, that it's a tool to generate code at runtime. So someone, somewhere, is generating Dynamic Assemblies using this stunt. But what's causing the problem is something that was injected on System.Reflection.Assembly.System.Reflection.Assembly using something like Harmony or similar. So I remembered that KSPCF once published a fix/work-around/whatever for the infamous Assembly Loader/Resolver, and I'm pretty sure that code would need to handle the .Location property (that it's known to trigger the Unsupported Exception on dynamic assemblies). Checking KSPCF soure code, I found this line: if (methodName.StartsWith("<SetupFSM>") && !methodName.Contains("_Patch")) what suggests that KSPCF should be, indeed, be involved somehow on this mess. I also found that KSPCF is, in fact, directly accesing the GetTypes method (see here, and here). So we have evidences enough to drop them this hot potato. @Comrad_501, @matthias123, both of you should ask for further help on KSPCF. There's absolutely nothing I can do from my side, as the problem is that whoever applied the GetTypes_Patch1 thingy into System.Reflection.Assembly.System.Reflection.Assembly, didn't accounted for Dynamic Assemblies and, so, are getting screwed. My code is borking because it was induced to call GetTypes_Patch1 (whatever it is) instead of the original GetTypes. Additionally, my code that got screwed does not tries to access the .Location property, only .Namespace and .Name - so, again, there's nothing I can do to even workaround the problem on my side. It's important to keep in mind that this problem is affecting everybody and everything that calls System.Reflection.Assembly.System.Reflection.Assembly.GetTypes() as I do, being TweakScale only one of the victims.

Check the KSP.log after removing it. Some KopernicusExpansion' extensions use it, others don't. With a bit of lucky, this dirty trick buy us some time while I don't figure out what to do! Krap. Put that file back so, something else installed on your rig needs it. You will have to remove TweakScale until I find my way on this problem, sorry...

I just edited my previous post with a possible work around, while I don't find a proper fix. Try it and let me know if anything goes wrong. I still need to check what's this RunSharp thingy is doing that it's screwing people using Reflection - but the real problem is Mono deciding to throw an exception instead of just returning NULL when a property is not available due some black magic. I already handle NULL on that situation, as Assemblies loaded from Resources also don't have a location.

well, you presumed right - this insidious Exception appears to be part of the problem. It appears to be something on Unity? https://forum.unity.com/threads/finding-the-cause-of-system-notsupportedexception-error.1256958/ Humm…Yeah, something on Unity, definitively: https://github.com/googlesamples/unity-jar-resolver/issues/362 https://github.com/googlesamples/unity-jar-resolver/commit/1b7a9a586796751227796a50277cab6b8c27c8d4 So, nope, KSPIE and TweakScale are innocent on this one. Something else is triggering this Unity bug, almost surely by doing something completely innocent but that by some arcane reason destabilised something inside this sad excuse of software called Unity3D. What's unfortunate, because if it would be something I'm doing wrong, I would fix it ASAP. On the bright (or less dark) side, your CPU is a i7-10700KF, a symmetrical CPU (i.e., all the cores are equal and runs at the same speed), what makes things slightly less worst to cope with. However, we still need to find what's happening on your rig and try to work around it. I'm afraid that TweakScale is just the one winning a lottery here, ideally we need to zero in the problem or this crap will hit someone else later with someone else. We are going to do combinatorial analysis here. First, do a FULL BACKUP of the whole thing and from now on, only mangle with the backup. Do not try anything below on the original installation, as these changes are destructive! Remove Harmony and anything that dependes on it (KSPCF, Kopernicus, etc). Then fire up the test bed and try to reproduce the problem. If the problem is still present, remove KSPIE and try again. If the problem is still present, send me a new KSP.log, but also the output_log.txt this time. In the mean time, I will try the opposite here. I will install KSPIE and see what happens. Then I will install Harmony and KSPCF, etc. I suspect I will not find anything, because such an obvious error would be already caught in the field, but I need to try nevertheless - or we will risk a misdiagnose and I already had my share this month. Anyway, let me know whatever are your findings. Good hunting! — — POST EDIT — — This thing is happening around here since some time, even before I get here!! https://forum.kerbalspaceprogram.com/search/?q="System.NotSupportedException"&quick=1&updated_after=any&sortby=newest&search_and_or=or — — POST POST EDIT — — Aha, found something! https://github.com/blizzy78/ksp_toolbar/pull/39 If I'm right, I have no choice but to cope with this mess on KSPe. Damn, another update fest as it appears. — — POST POST POST EDIT — — @Comrad_501 wait!!! Found something about! Try to first delete the following file: D:\Steam\steamapps\common\Kerbal Space Program\GameData\KopernicusExpansion\Plugins\RunSharp.dll I have notice that this fixed the problem! — — POST POST POST POST EDIT — — NO! DO NOT DELETE THAT FILE!!! (source) -- POST POST POST POST POST EDIT -- That's the history: KopernicusExpansion decides to add a tool to make Reflection handling easier, RunSharp. Apparently it is not using it itself, but some extensions to it are. Why this thing is playing havoc on KSP I didn't checked yet (but I will). So, there's a possible quick&dirty work around for your problem: delete RunSharp.dll and then check if anything borks. If you find nothing wrong, good - you can play KSP while I cook something to cope with the problem. If something borks complaining about the absence of the RunSharp.dll, then you will need to remove TweakScale for while (as I' m assuming you is playing KopernicusExpansion already).

You know, I never really gave enough attention to Saturn I !! My bad! This thing is essentially 9 thin fuel tanks strapped together, with 8 engines shoved below them in a very interesting way - on the most Kerbal way possible! MOAR STRUTS!!!! This video shows how the Saturn I first stage is built, very interesting! — — POST EDIT — — Another very interesting documentary about Saturn I follows: