Lisias

You are right. I just downloaded the ZIPs from CurseForge and Spacedock and the contents of the 2.4.6.6 zip file is… well… the 2.4.6.5 binaries and files. Anyway, thank you for the heads up. Github is updated to 2.4.6.7 (the real deal this time, I double checked everything), CurseForge and Spacedock is going to be updated in the next 15 minutes.

SubLieut Ian Warson, a Kerbal among Humans. Not only landed a Harrier on a cargo ship and fell over a van (two strikes at the price of one!), but the container was holding the base for the Newton Telescope! (this dude peeled potatoes for some time...)

Me definitions for 'race conditions' were updated. I never thought on trying something like that. I will try to reproduce this on my clean and dirty testbeds. If I don't manage to reproduce it, I will need your help to nail this one!

METAR A regression on TweakScale was detected (eating your own dog-food is simply the best QAS tool I know). While tackling down Issue #219, I inadvertently resurrected Issue #139 - but with a glitch, it was working at that time, otherwise I would not had closed it. As it appears, @darthgently apparently was kind of right: And I was not entirely at fault as I was thinking. Empirical tests suggests that the problem is not something being done (or not!!!) after TweakScale acts, but before. Apparently, there're two situations in which the nodes are already on its ideal places, and one situation in which I must set the nodes myself. The problem appears to be OnLoad and OnCopy triggering the event KSPEvents.onEditorVariantApplied (what's nuts, it's my understanding that this event should be called only when the User selected a new Variant) - but OnLoad and OnCopy already have the nodes on their places, and so TweakScale's code that handles the user changing Variants ends up borking their job. There's already KSPEvents.onVariantApplied , where it's my understanding the code induced events should happen. Unless I missing some important detail, the current usage of these events makes no sense. This apparently explains why the #219 bug affected loading crafts on Editor, but not on the Flight Scene (something that scared the sheet out of me at that time!). In a way or another, the current status quo is that if you change the variant of a scaled part on editor, now, the nodes will be defaulted to the unscaled position - you need to scale the part to the default, change the variant, and then scale back the part. Pretty cumbersome (and the problem that line of code I deleted was fixing). Now that I understand what's happening, I can try to fix the thing safely. This will be tackled down on Issue #223.

As a matter of fact, active shielding is exactly what "Hazard Lizard" said: explosives used to protect the hull from explosives!

Didn't knew it. Well, let's dig again on that log. Well, I found this later: [ERR 17:56:20.880] AssemblyLoader: Exception loading 'SSTUTools': 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 <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <c1858a3f77504bd1aaa946fdccf84670>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' Since Principia is not the cause of the problem, it must be this one. Something needs Textures Unlimited installed, and apparently it is not installed. Your log is littered with this one, but since Principia "came first" on the log, I didn't paid attention on it. — — POST EDIT — — I added a comment on the issue you created there suggesting a way to solve this Principia's annoyance.

Hi! It's that pesky KSP bug on Assembly Resolver again. There's something very wrong on some Principia DLL's (dont have a clue what, you will need to reach Principia's maintainers for help on this: [LOG 17:56:14.371] AssemblyLoader: Loading assembly at E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libglog.dll [ERR 17:56:14.922] Failed to load assembly E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libglog.dll: System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid. at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00067] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImage () [0x0007a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00022] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0000a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <c1858a3f77504bd1aaa946fdccf84670>:0 at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00175] in <c1858a3f77504bd1aaa946fdccf84670>:0 [LOG 17:56:14.922] Load(Assembly): Principia/x64/libprotobuf [LOG 17:56:14.922] AssemblyLoader: Loading assembly at E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll [ERR 17:56:15.574] Failed to load assembly E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll: System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid. at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00067] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImage () [0x0007a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00022] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0000a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <c1858a3f77504bd1aaa946fdccf84670>:0 at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00175] in <c1858a3f77504bd1aaa946fdccf84670>:0 [LOG 17:56:15.574] Load(Assembly): Principia/x64/principia [LOG 17:56:15.574] AssemblyLoader: Loading assembly at E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\principia.dll [ERR 17:56:16.436] Failed to load assembly E:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\Principia\x64\principia.dll: System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid. at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00067] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImage () [0x0007a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00022] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0000a] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00007] in <7a890c320a104d46b8776d7dd2bc4e65>:0 at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <c1858a3f77504bd1aaa946fdccf84670>:0 at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00175] in <c1858a3f77504bd1aaa946fdccf84670>:0 The KSP's bug kicks in now - when some dependency DLLs fails to be loaded (as it happened with Principia), something inside KSP gets broke and from this point, everything else breaks the same disregarding the thing being able to be loaded or not, and this is what happened on DOE: [LOG 17:56:21.329] [AddonLoader]: Instantiating addon 'Startup' from assembly 'DistantObject' [EXC 17:56:22.126] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) KSPe.IO.Hierarchy`1+<>c[T].<calculateTypeRoot>b__10_0 (System.Reflection.Assembly assembly) (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) System.Linq.Enumerable+<SelectManyIterator>d__167`3[TSource,TCollection,TResult].MoveNext () (at <fbb5ed17eb6e46c680000f8910ebb50c>:0) System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () (at <fbb5ed17eb6e46c680000f8910ebb50c>:0) System.Linq.Enumerable.TryGetFirst[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Boolean& found) (at <fbb5ed17eb6e46c680000f8910ebb50c>:0) System.Linq.Enumerable.FirstOrDefault[TSource] (System.Collections.Generic.IEnumerable`1[T] source) (at <fbb5ed17eb6e46c680000f8910ebb50c>:0) KSPe.IO.Hierarchy`1[T].calculateTypeRoot () (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) KSPe.IO.Hierarchy`1[T].CalculateTypeRoot () (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) KSPe.IO.Hierarchy`1[T]..ctor (KSPe.IO.Hierarchy hierarchy) (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) KSPe.IO.Hierarchy`1[T]..cctor () (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) Rethrow as TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) (at <9f7cd9a529194dc4a60f3cf218f8503b>:0) DistantObject.Startup.Awake () (at <e30ec9083ad44f3d8c362bd51ed054ea>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__88:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__69:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() Others add'ons were also affected, but apparently only my ones are programmed to cry when something goes wrong. In a way or another, you need to have Principia fixed. Once this is done, I expect the other add'ons borking on load (including DOE) will be fixed - otherwise, drop me a log here again and we will "Rinse, Repeat"™. Cheers! — POST EDIT — ERRATA: The Principia DLL erros are harmless. See Principia#3229. There's a solution to prevent this errors on the log suggested on the link.

Given the state of KSP-1 codebase, this is not exactly reassuring...

I'm betting something else is borking a DLL, a situation that triggers a nasty bug on KSP's Assembly Loader - everything borks after that, no mattet what. Send me your KSP.log (use dropbox or something) and I will inspect it for you.

NOTAM It's not a secret that KAX heavily relies on Firespitter for doing its business. And while working on my Giganta spaceplane I realised I was wasting a lot of dead mass due the lack of options on fuel tanks. I already have lots of fuel on these wings, what I was in need is Oxidiser. Hardly a novelty, I'm pretty sure everybody around here had passed trough this, we would not have Fuel Switches around otherwise. However, why someone would need to install an additional fuel switch if the dude/gal only wants to use Stock Parts and Firespitter already has one available? Thinking on it, I decided to add FS FuelSwitch support into Stock And Making History parts on KAX. Lisias graded patches, they aim to be well behaving - so the patch is only applied if and only if no other (known) fuel switch is already applied on the part (including FS Fuel Switch itself), so no toe stomping fest here. If you find some part with more than one Fuel Switch installed (TweakScale will yell on it!), please report and I will fix it ASAP. To avoid redundancy, fuel tanks that already have a counter part for LiquidFuel only will not have this option available, allowing you to select only between LFO or Oxidiser (use the stock one for LF, it's more portable this way). I also decided to do not touch any non-stock parts, it would be out of scope for KAX. I don't expect these patches to be widely used, most people is already using a newer fuel switch nowadays - but if you have a minimalistic KSP installment as I do and like to use, KAX's new patches may be of value for you. The patches will be "officially" available on the next Beta Release of KAX (where I plan to add some other goodies) to be released Soon™. Until there, early early adopters can test the thing by downloading them from https://github.com/net-lisias-ksp/KAX/tree/dev/GameData/KAX/Patches/FS-FuelSwitchSupport . Please report any mishap. Cheers!

Yes, but I only fixed a string that had leaked from the development branch... Hummm…. A light bulb just sparkled inside my dull head. Perhaps the whole problem was that String, perhaps someone trying to access that field by the localization string instead by its name…. Thanks for the feedback!! Now I have something to work with again!!

Check the "Event ID 14 nvlddmkm" stunt. It's the only option left at this moment.

Environment checks is not part of TweakScale, and I think it should stay so - TS is environment agnostic, it out of scope to handle KSP bugs and idiosyncrasies. That's the reason the WatchDog was made - to handle it on an optional component, to be installed at users (or installer) discretion: the WatchDog is not installed on CKAN - it's up to CKAN to decide what to install or not about the environment handling, as they are the ones supporting installations for CKAN users. Additionally, the WatchDog doesn't handle 3rd party DLLs. It only checks for Scale_Redist, and if and only if a client is installed - if you Uninstall TweakScale, Interstellar Extended and any other known dependents from it, it doesn't checks for anything (even with Scale_Redist being present).

Do a powered reentry! When things get too hot for your comfort, hit the thrusters and pitch up - and go back to near space a bit. Do not go above 70K height unless you screwed up and are almost fried and need to cool before going down again. The trick is to use the thrusters to gain back some vertical speed without gaining too much horizontal speed. Rinse, repeat. You will need some fuel, but you will keep your thermals under control. Even MK1 parts can survive reentry this way!

I also found people complaining about using RTX on AMD 3000, and found two guys telling that they solved the problem by setting "maximum performance" in Nvidia Control Panel. Also found people saying to avoid using G-SYNC on Window mode. Don't have the slightest clue if it will help, but it costs nothing to try. I'm still digging about the ReSize BAR stunt, but apparently it would be a problem only on RTX30. — — POST EDIT — — Check if you find something like "Event ID 14 nvlddmkm" on Event Viewer, I found people complaining about it when using a 2060 on a Ryzen 3000. Apparently, something about zen2 agesa/smu fighthing the PCIe Controller. If this is the case, the BIOS update appears to be the only choice remaining (as this is also mentioned on your BIOS Release Notes).

Nope. The 2.4.6.6 is only a recompiling after I fixed (again) a localization string that leaked (again) from the development branch. Other than that, its essentially the same code. Found it! [LOG 15:31:08.571] Load(Assembly): FerramAerospaceResearch/Plugins/Scale_Redist Delete <your KSP>/GameData/FerramAerospaceResearch/Plugins/Scale_Redist.dll and you will be fine. I need to fix that Error Message, I will do it. Soon™.

Multiple copies of Scale_Redist, as the message is complaining. I don't remember the code from heart (away from computer now) but I think I check for the Assembly's name - so perhaps I was unhappy on writting the error message. Publish the KSP.log and I will inspect it. Every DLL loaded leaves an entry on the log, I will be able to detect the duplicate from it.

for the sake of completude, this is the release notes for the BIOS releases newer than yours: * Version 4602, 2021/09/10, ROG STRIX B450-F GAMING BIOS 4602 + Update AMD AM4 AGESA V2 PI 1.2.0.3 Patch C + Improve system performance * Version 4502, 2021/08/03, ROG STRIX B450-F GAMING BIOS 4502 + Support Windows 11 by default, no settings changes required in the UEFI BIOS. * Version 4402, 2021/06/30, ROG STRIX B450-F GAMING BIOS 4402 + Update AMD AM4 AGESA V2 PI 1.2.0.3 Patch A + Improve system stability * Version 4301, 2021/03/29, ROG STRIX B450-F GAMING BIOS 4301 + Update AMD AM4 AGESA V2 PI 1.2.0.1 + Support Smart Access Memory for Ryzen 3000 Series Processors + Improve system performance * Version 4204, 2021/01/29, ROG STRIX B450-F GAMING BIOS 4204 + Support AMD AM4 AGESA V2 PI 1.2.0.0. + Improve ReSizable BAR compatibility for NVIDIA RTX30 series graphics cards + Improve system performance * Version 4007, 2020/12/09, ROG STRIX B450-F GAMING BIOS 4007 + New CPU support + Offer a Re-size BAR Support option to enhance GPU performance. * Version 3103, 2020/06/23, ROG STRIX B450-F GAMING BIOS 3103 + [E] Improve system performance. + Update AMD AM4 AGESA Combo PI V1 1.0.0.6" Since your RTX is a 20xx, I don't think the Re-size BAR support is the problem (BAR is a protocol to allow the GPU to shove its memory into the CPU's memory bus - Base Address Register), as this is available for RTX 30 only. So I'm guessing the problem may be the Ryzen 3000 "Smart Access Memory", that it is, in essence, how AMD calls the ReSizeable BAR! SO our next step on this diagnosing fest is to check if anything is using the ReSizable BAR on your system, a situation where I think your Mobo's BIOS is borking. I found this, and in essence: If it's enabled, we need to find a way to force it to be off!

All stations stop transmitting. ASSIST in progress! Oukey, TestBed fest. I do all my tests on, at least, 3 KSP versions: 1.4.3, 1.7.3 and the latest (currently 1.12.2). It's how I isolate TS problems from KSP problems - when TS is the culprit, usually the problem is consistent on all versions (but not always, sometimes the bug is on the support for a specific KSP). So, this is the test for KSP 1.4.3 - pretty "standard" scaling, the PartModuleVariant on KSP 1.4.3 was pretty minimalistic and with a smaller surface for attack of bugs. So no problems detected on 1.4.x series. This doesn't not exempt TweakScale from the problem, as TS has dedicated code for some KSP versions. All I did was to clear out the TS code that handles 1.4.3. So the next on the pipeline is KSP 1.7.3, where I copied the craft from 1.4.3 and loaded it: I'm not exactly pleased with the detected bork on TS 2.4.6.4 over KSP 1.7.3. Once you save the craft, I think the mangling is permanent, I will test it asap. And if the craft saving is permanent, so it may be the SFS file as they share code. (sigh) Going to KSP 1.12.2, loading that same craft file made on 1.4.3: So, yeah. You found something, and this something is bitting your SAS. Sorry. Let me know if something goes south on your SFS file. I have some ideas for fixing SFS crafts, perhaps this is the time to put them on a project. Backing up savegames on every change, as small as it can be, should be considered mandatory - check the Announce for 2.4.6.4 for the reason. Struts and Fuel Lines ARE NOT HANDLED by TweakScale. TS just doesn't touch them (even when it should). Whatever is screwing them on your rig, it's not TweakScale. TweakScale may be one of the triggers, but it's not the cause for this problem as far as I could check (and I did a lot of tests on the matter exactly due #173). I will need a mininum set of Add'Ons in which this happens in order to have a chance to diagnose this one. (and yes, these issues are infuriating sometimes - I took a small break and get a coffee just by remembering when this happened to me - it as a pretty large craft) I had of these problems too, and they are not TweakScale related because I had them without TS installed - and I think this is related to the problem you described above. Check the symmetries of the affected struts (and Fuel Lines). Apparently this is related to the symmetry on the root part - somehow it can "infect" the children's symmetries, even by having them already set on the kids. I had full assemblies of wings having this problem, you will notice as I did that Mirror Symmetries are converted into Radial Symmetry silently on the affected parts, and then any change on the craft that would trigger an update fest will screw up things. I managed to fix them by editing the craft file and changing the symmetry of the affected parts back to mirror using a Text Editor, and I think I prevented that from happening by changing the Symmetry of everything not intended to be Radial to Mirror on the whole craft - a bit laborious. In time, I think I had this problem without EEX installed - so it's probably not the cause of the problem (I think it may be another trigger for it, if such). — — — In time, the craft file I used is on this post on Issue #92.

[snip] Nope, it's KJR I have a fork. I never found a reason to do the same to WS, because it just works (or used to).

Not exactly a music, but a whole concert! David Gilmour in 2006 at Royal Albert Hall. Magnificent show, it makes you want to go back in time just to attend to it.

Yeah, that can be a problem. Is pretty uncommon, but it can happens - and without technical support around, it's may be preferable to co-live with the problem to risk losing the computer, not to mention this !!##$#$ silicon shortage that it's making everything more expensive. What's the version of the BIOS currently installed on your computer? With a bit of luck, by comparing the change log from your version and the newer ones we can find exactly what's borking and, with a bit more luck, can try a workaround (that probably will slow a bit your computer, but it's better than not being able to run KSP at all)

As a matter of fact, neither do I (not exactly by the feature, but by having time to spend on it - dude, RL™ is bitting. )

Just to make it clear - you took your RTX 2060 and tested it other computers? I'm considering a HW conflict related to the Asus motherboard - what would be pretty surprising, as they also manufactured the GPU. Most games doesn't uses the GPU as KSP does, KSP loads everything and the kitchen's sink at once while most games loads and unloads assets. This pushes a bit the VRAM usage above the level usually is done by other games. Sometimes a memory conflict, sometimes some device driver using VRAM as it would be System RAM, whatever. And, in fact, I just found something that may be related to your problem : https://rog.asus.com/forum/showthread.php?114811-ASUS-motherboard-graphics-cards-problem The interesting part is: Have you tried updating to 2901 BIOS. Im thinking the latest 1903 along with latest drivers and older microcode could be a culprit that caught up with latest drivers. newest BIOS log says fixed display issue but unfortunately they are not always complete as to what was done. Actually quite the opposite with lines like improved performance. They should be more descript but this has never happened before and I dont expect it to start any time soon. Check your BIOS version, see if there's not an update for it on Asus Support Page. Exercise extreme prudence on updating the BIOS, a power failure on the middle of the process can brick your motherboard - follow PRECISELY the updating instructions to the letter. You may want to pay someone to do that for you, as these professionals usually have the tools to recover the original BIOS is something goes wrong (very, very rare - but it can happens).

Damn, found a note from November on my fridge too!!