Lisias

What does not makes FF the "culprit" for sure - sometimes I forget to mention it. Triggering a KSP problem can be made by pushing a trigger, or by innocently stepping on a landmine. Hummm… KSPUtil is a KSP internal class (I forget about it everytime). https://kerbalspaceprogram.com/api/class_k_s_p_util.html There's something else smelling on this stunt, I need to recheck your KSP logs. Can you send the new ones you have, just in case? With a brand new installation, perhaps something different is being logged and with a bit of luck, this can help. Sending also the KSP.log (and not only the Player.log) also can help a bit, as some information are not logged on the Player. — — — POST EDIT — — — Just found the lastVesselSurfacePosition thingy on FF: private Vector3d lastVesselSurfacePosition; The error message is implying that the Vector3d thingy is causing the problem, because supposedly it was present on the KSPUtil Assembly when the code was compiled by the last time. This thing still exists on the current API: https://kerbalspaceprogram.com/api/struct_vector3d.html So the problem in your rig is something else. I can only guess by now, but at least are guesses based on what had already happened in the past: By some reason, the current directory for the KSP process is set wrongly, and so the KSP.exe is not being able to find the KSP DLLs. I only heard of this on Linux (that has a different modus operandi for launching programs), however. Your KSP installation is corrupted or missing some files. Use Steam to verify the integrity of the installed files! There's something else on your rig (usually a System DLL) that is corrupted or missing and preventing mono from loading the needed DLLs But I think it's pretty unlikely somthing like this would happen without further error messages on the log... I think (or hope) that your KSP.log file can throw some more light on the situation!

Nope. TweakScale is the one yelling about the problem, not the one causing it. From the log using FF, I found: Uploading Crash Report TypeLoadException: Could not load type of field 'Nereid.FinalFrontier.EventObserver:lastVesselSurfacePosition' (7) due to: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. assembly:KSP Util, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) signature:<none> Rethrow as TypeInitializationException: The type initializer for 'Nereid.FinalFrontier.FinalFrontier' threw an exception. There's a nasty problem on KSP throughly explained here. TL;DR: something borks while loading a DLL, two important things get broken inside KSP and from now on everybody trying to use these things borks too. It only happens that TweakScale is aware of the problem and yells everytime it happens, as loading a savegame with TweakScale unable to work due this problem leads to corrupted savegames. So, yeah, Final Frontier is the one triggering the KSP problem. Fix the KSP_Util thingy (I don't know what it is, but apparently the KSP_Util installed on your rig is not the version FF knows how to use) and the KSP problem will be avoided avoided, fixing everything that was broken after it. Keep in mind that, as TweakScale, FF is not going to behave as expected until you fix this problem. Cheers!

I found this one incredibly Kerbal… Source: https://www.thedrive.com/news/34753/the-winnebago-heli-home-was-a-real-flying-rv-that-needs-to-make-a-comeback-in-2020

Nope. It tries to do the Right Thing™ and only patches parts without TweakScale support. Keep in mind, however, that after installing it, you can't add any TweakScale support for already existing parts because this may break your games - switching ScaleTypes and DefaulScales on a part still leads to undesired results because TweakScale lose the common baseground needed to scale things up or down. Humm… On the other hand, an automated tool may be possible…. Keep an eye on https://github.com/net-lisias-ksp/TweakScale/issues/236

The OSI Silver Fox. This thing reach 155MPH (~250 KM/h) using a 1.0 litre 4 cylinder engine. Not bad! Source: https://www.carthrottle.com/post/a2m6lrj/

Hi! TweakScale maintainer here. Unfortunately you were bitten by a very annoying KSP bug plagging us since 1.8.0: when something borks by loading a DLL (by any reason, from the DLL being missed to the DLL's dependencies borking on their turn), two things breaks badly on KSP: the Reflection and the AssemblyLoader. And anybody else trying to use them borks too. And TweakScale makes heavy use of these, and since a faulty TweakScale can terribly ruin your savegames, it yells on the problem. So you did the right thing coming here for help - on the situation you are, any flying craft using TweakScale on the loaded savegame will be descaled... Usually you can diagnose the problem by looking for the first Reflection exception (all the others after the first one are victims from the problem I described above) on your KSP.log - the only way to diagnose your problem is inspecting the FULL KSP.log. Please publish it on Dropbox or something and post the link here. The list of assemblies you provided is not useful because the "culprit" was not loaded, and so it's not listed on that list! In time, keep in mind that this is not a TweakScale problem. It only happens that TweakScale is not burying its head on the sand and silently letting you get screwed by the problem I described above! Please mention me using @Lisias (@ l i s i a s) when you publish your KSP.log - or do it in the TweakScale thread mentioned above. Cheers!

Yep, you got hit by a annoying KSP bug, yada yada yada… TL;DR: LaunchPad is missing a dependency: [ERR 21:26:37.864] AssemblyLoader: Exception loading 'ELHelper': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoa 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' Reach LaunchPad's maintainer for further help. Since I don't play with it, I don't know where to find ELHelper. Alternatively you can remove LaunchPad from your rig - what probably it's something you don't want to do, otherwise you wouldn't had installed it at first place. But it's a viable workaround to keep playing until you fix LaunchPad. I understand these pesky errors can be annoying, but please consider that if I would allow you to load your savegames nevertheless, TweakScale would not be able to work as intended and the net result would be all your flying crafts on the loaded savegame being descaled on the spot, completely ruining them. Attention! Strong images on the spoiler, user discretion is advised! Please also consider that TweakScale is not the only add'on that would had problems on a badly initialised KSP - it only happens that TweakScale is the one detecting problems and warning you, instead of burying its head on the sand and letting you be screwed by the problem!

Nope. It's normal DOE behaviour! It's the SkyBox dimmer. Every time you look to a planet or a Sun, the skybox will be dimmed. Humm… Looks like a side effect of the issue #15. In fact, uninstalling DOE and the current SkyBox dimming being perpetuated is, by itself, a bug - more probably a new side effect of the #15. As I said on the Poods Skyboxes thread, I'll pursue a workaround for what you need without DOE, as I expect that by fixing #15 the workaround you are relying to will cease to work! Thanks for the head's up!

Not yet. But now that you asked for it, I will work on one this weekend! Cheers!

Hi! DOE's maintainer here. Currently, there's a bug on DOE (scheduled to be fixed soon™) that, once fixed, I suspect will prevent the current workaround from working after DOE is uninstalled. I'm trying to figure out where the current skybox is persisted on KSP itself, so you guys can change the value directly and then avoiding the need to install and deinstall DOE - as it will eventually stop (mis)behaving in the way you expect from it.

Got it!!! (it's a miracle!!! ) @zer0Kerbal is on the house?

Use the -A option to set the same user-agent string your browser is using. Even by the site allowing unknown user-agents to hit it, sometimes the CDN or any other service-in-the-middle borks when an unrecognized user agent is detected . Some of them even blocks the request when they detect the default curl user-agent...

Texaco Doodlebug. Yep, this is a fuel tanker!!! Someone at Texaco really loved his/her VW Bug! Source: https://texacotankerproject.com/the-origin-of-the-streamlined-tankers-the-texaco-doodlebug/ Colorised version: Source: https://estradao.estadao.com.br/caminhoes/texaco-criou-caminhao-futurista-doodlebug-em-1930/

There can be only one! The 999_Scale_Redist.dll is the canon one. Any other copies on the GameData should be deleted. The warning only happens when TweakScale is installed because the (potential) problems only happens when TweakScale and the known TweakScale clients are installed. (there's no point on pesking the user about multiple copies of something that will not be used). Cheers!

If I undertood correctly, you need to buy an external USB hard drive (or a very big thumbstick) and tell XBox to move your game to it. You will probably have to format it on the Xbox. Then you stick the mass storage device on the PC and can copy the files to your computer. So one can try to salvage it. But reading XBox formatted drives on PC is slightly tricky. But doable: https://digiex.net/threads/copy-and-extract-content-from-an-xbox-one-usb-formatted-drive-on-a-windows-pc.13584/ These step are intimidating, but it's not a big deal after you do it the first time. I suggest you buy and play a bit a cheap dispostosable game (to create a guinea pig savegame) and use it first while you find your way on the mess. If anything goes wrong, all you need to do is to download and play a bit the disposable game again - and so you don't risk losing the valuable KSP datafiles. Once you manage to have the data files on your notebook, make some zipped copies of it (we are going to screw up things a bunch of times until we hit the sweet spot) and then ping me here with using @Lisias (type @ then type lisias). Good hacking! You are going to be 1337 !

Yep! And the good news: it is not beta anymore, I just update the Distribution Channels yesterday! You are using a (recently) deprecated KSP-Recall version, 0.2.2.1 . The latest is , now, 0.2.2.3. The reason for this happening is a bit convolute to explain, but I think you deserve an explanation: On KSP 1.9.0 development cycle, I think something got broken by accident on KSP Editor, and the devs choose to shove a "gambiarra" (half-baked workaround on my mother-tongue ) to mask the problem, as they probably didn't managed to located the cause. But this workaround royally screwed TweakScale, and so I had to shove a "chuncho" (a really bad fix for a problem - like using a coin to replace a fuse on a power box) on TweakScale - as I didn't managed to locate the problem myself. Time goes by, I got more experienced about KSP guts and I ended up realising that the "chuncho" on TweakScale could be screwing up things to Add'Ons running after TweakScale the same way Editor was screwing me. And I concluded this was unacceptable. Besides, being a KSP bug, by removing the "chuncho" from TweakScale and using a proper workaround on KSP-Recall, I also allow someone to come with a better solution later - every fix on KSP-Recall is deactivable, so if anyone ends up cooking better solutions he can deactivate the KSP-Recall one and use the better one without worries. And, in the bottom line, KSP-Recall approach ended up fixing some corner cases that the TweakScale's chuncho was not able to cover. It was painful, I know, but today we are in a way better situation than we were before - all corner cases are being covered nowadays as they are discovered, and nowadays I'm more experienced too, the new way of fixing these problems are way more maintainable and reusable. Happy Scalings!

I think it may be a interaction with some other add'on, because I had tested it on a pretty complex scenario and it worked fine - but only using Stock (and TweakScale) to tell you the true…. See, the following picture has two small crafts on the scene, all of them pretty far from the focused craft: Another one, daylight this time: I must have a screenshot somewhere on my rig with at least 4 or 5 crafts in the camera range, but beyound the physics, somewhere here… Anyway, the source for your problem appears to be something else. Please reproduce the problem again, then quit KSP (to prevent it from truncating the log) and then publish your WHOLE KSP.log using dropbox or something so I can inspect it and see exactly what't happening. Sometimes, the Exception you see is only a collateral effect of another one you are not seeing, and the KSP.log will help me if this is what's happening with you.

I found a workaround!!! Install CraftManager, and then use it to load the SubAssemblies as they were ordinary crafts! (Loading crafts works fine, it's the SubAssemblies the problem) Just load the SubAssembly as it was a Craft, and then drag and drop it into a new SubAssembly! Cheers!

ANNOUNCE KSP Recall 0.2.2.3 is on the Wild, featuring: Allows patching AttachedOnEditor on every compatible part, no matter it has TweakScale installed or not. Needed because a TweakScaled part borks when attached to another without it. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. All distributions channels are belong to us. —— — — — I found a workaround for upgrading the SubAssemblies!!!! Use Craft Manager to load the SubAssemblies as they were Crafts, then drag and drop the thing back as a new SubAssembly!

It's an (now) old bug on KSP itself. When a DLL fails tp be loaded, be it by being missed, or by having a faulty or missing dependency, something inside a thingy called Assembly Resolver gets broken, and from this point everything that relies on a thingy called Reflection and also the Assembly Resolver itself starts to bork. TweakScale makes heavy use of both thingies, and so it utterly breaks due this problem. Since by uninstalling SandCastle TweakScale works, it is installed alright. So the logical conclusion is that SandCastle itself is missing a dependency (or the wrong one is installed), and so it's unadvertdily triggering this KSP bug, Check if all dependencies are installed and, if you can't find what's wrong, publish your KSP.log using dropbox or something like that and we will look for the problem there. Cheers!

Yes, it's more expensive. But… The total cost of the endeavour can be way more expensive than the shipping costs. There was at least one Chinese eCommerce shop shipping goods at no-cost to Brazil by airplane during the pandemics - before it, that goods would be shipped by sea, taking about 2 to 3 months. On the pandemics, these goods was reaching me in 2 weeks! (2 or 3 days traveling, almost 10 days being handled by Customs - yeah, we are that bad on Customs). So, let's imagine there's a cargo that could be transported by Mryia in 1 week (total travelling time - manufacturer to airport, flying legs for refuelling, destination airport to final destination) , and now it needs 3 months to be shipped by sea. Let's suppose this cargo had cost 1M USD, and it will help to generate 10K USD/day 24/7 in (gross) revenue once in production. The payment is made upfront, i.e., when the cargo leave the factory. The time the thing will take to be installed is not relevant, because this time is a constant, no matter the cargo had take 1 or 11 weeks to arrive. Now… There's a thing on economics called opportunity cost. It's how much a choice I made will cost me when compared to another one. The opportunity cost of shipping the thing by seas will be 10K * 11 weeks == 10K & 77 days == 770K USD due delayed revenues. But, additionally, I could had used that money to make some investment for these 77 days, so this is also included on the opportunity cost. So it's 770K USD plus 1M USD * dayly interest * 77. I google for "daily interest investment" and took the first percentage it shows (I don't have the slightest idea if this interest if plausible of just marketing bait), and it says 2.5%. I found this excessive so I'm unilaterally and arbitrarily defining the daily interest rate to be 0.5% (what also sounds excessive, but whatever, I'm just trying to prove a point). So… 1M USD * 0.5% by 77 days gives me: ~1.45M USD — the earnings are cumulative, because the interest of today is applied to the sum I had yesterday more the interest I earnt yesterday. So, if I had choose to just take the money and speculate, I would had earn 450K USD on these 77 days. So the total opportunity cost for me by shipping the thing by seas is 770K USD + 450K USD = 1,220M USD (this value is not exactly right, I'm simplifying things to the point of being obtuse…). It would be 220M USD cheaper to pay 1M USD to Mriya and get the thing delivered by plane.

THERE'S NO DEPENDENCY ON TWEAKSCALE ON ANY NON OFFICIAL FORK OF ANYTHING. This slandering must end. This happens due bad patching. More than one add'on are applying patches to TweakScale, and this can lead to inconsistent TweakScale data, that can lead to parts already launched and flying to be wrongly resized. Please abstain from making judgments about what I allegedly like or dislike - you are not in position to know about it, and you are not a common user around here.

Yes, it's possible. And it was already made (to an extension) on Firespitter - but, granted, on propped engines only. It's something that I can think about, I have some in-dev ideas on the works. But I'm unsure if I should shove them on KAX? I don't want to turn it into a feature-creep add'on, it may be a better idea to complement it , like I'm doing with TweakScale and tis Companions... What do you think?

Planes can be re-certified, and even restrictions can be (temporarily or not) lifted. The DreamLifter was used to transport medical supplies during the pandemonium pandemics... If the need arises, someone will do something about. But yet, there're some airports that could be used for the task. It was what was being doing with Mryia. It's weird, but airports can be more versatile than some ship ports - large volume specialised ship ports are optimised to Containers. All the loading/unloading equipment are specialised to be used on Containers. Most cargo ships are specialised to be used with Containers. So, the availability (and the pricing) for non-containerized cargo are not the same for the containerized ones. See https://www.morethanshipping.com/what-are-the-shipping-methods-without-containers/ for more information.

Before providing support for your problem, I need you to understand some things first (on spoiler, to avoid cluttering the support ticket with… "fun". ) : That said... So it's not my fault. I can't be responsible for a fix that doesn't works because it is not being used!!! (and thanks for doing part of the diagnosing for me! You saved me a lot of time!) Now we need to know why US2 parts are not being patched with AttachedOnEditor. The patching process is pretty straightforward: @PART[*]:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA],@MODULE[TweakScale]]:FINAL { %MODULE[AttachedOnEditor] { active = True } } For every part that have TweakScale, but don't have ModuleAsteroid, ModuleComet neither KerbalEVA, apply the patch! Why I did it? Because until now I didn't had a report of this problem happening with any other add'on other than TweakScale, so I choose to be conservative and to only shoot the ducks I can see. So, dear grumpy Kerbonaut, what you are telling me is that (as I always suspected), TweakScale is not the only one being screwed by Squad's Editor stunt. Thanks for your report, I really appreciate it (besides being a bit uncomfortable about how you did it…) macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "TweakScale" | wc -l 23 macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "AttachedOnEditor" | wc -l 23 macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "PART" | wc -l 60 You see? AttachedOnEditor was only applied on parts that have TweakScale module (I eyeballed the file too, just to be sure). But you are using a lot of parts that doesn't have TweakScale installed, so the AttachedOnEditor wasn't neither. In order to see if I'm really right, please edit the patch to: @PART[*]:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:FINAL { %MODULE[AttachedOnEditor] { active = True } } And see if the problem goes away. Please note that I removed the need to have TweakScale applied, the thing will now be applied (almost) everywhere. Nope, it's not. It's an incredibly unfair and… humm… "deviated from reality" statement. A more accurate one would be "KSP is a game that completely breaks your gaming regularly and repeatedly". TweakScale was working perfectly fine on KSP 1.8.1, and suddenly Editor started to screw it up on 1.9.0 . And I'm not even talking about the remaining inumerous serious problems that are plaguing KSP nowadays, some of them since 1.2!!! It's simple like that. You never heard of the problem because nobody else had diagnosed it. As the problem with the AutoStruts, by the way, screwing up savegames since KSP 1.2 and nobody knew about until I diagnosed it. The real problem is that (some) developers just blindly patch symptoms instead of working harder to find the root problem and fix it before the side effects blows up on the user's face at first place. Burying your head in the sand is not the proper way of handling problems. There're a lot more things that you just don't understand. Let me try to remove one of them from your significantly extense list: I didn't managed to inject the proper values from the PartModule on an preexisting Craft/SubAssembly file because the correct values since KSP 1.9.0 are available only after the OnLoad cycle of the PartModule, and so it's beyound the PartModule's ability to fetch it at this time. Only on OnStart the First Update these values are available (because the Editor bluntly overwrite some values between OnLoad and OnStart First Update in a - desperate IMHO - attempt to fix the problem happening on OnLoad), but by then, everybody that was in need of such values (as TweakScale and, as it appears, some others) is already royally screwed. A proper upgrade process is beyound the capabilities of a PartModule. So another approach is needed, and I think that the proper one will be a custom KSP Upgrade Pipeline process. But this is something that I didn't learnt how to do yet. Feel free to help me on the subject. Your loss. There're more fixes for long standing serious bugs on the way. Unfortunately, I don't expect to nail it on a single shot as you appears to demand from me. But this is (fortunately for me) your problem, not mine. I'm not. I'm less than pleased with your decision, you can bet your SAS on it - but I'm not sorry. I'm doing the very best I can, and I'm pretty sure I did a lot more than expected from me: I'm one of the really few ones diagnosing problems plaguing KSP and even Unity for years already. I have nothing to be sorry about. Let me know if by changing the patch as I stated above the problem is fixed for you. May the road rise with you. — — POST EDIT — — Explaining tech details early morning in a hurry and when liquided is, usually, a bad idea. The problem happening on the Editor is not happening between OnLoad and OnStart, because OnStart happens before OnLoad, damn it. I'm working on a different framework at day job, where the Data Load phase happens before Starting the service and I ended up screwing up things in my memory. I'm getting old, as it appears. (sigh) Anyway. The show must go on.