Jump to content

Search the Community

Showing results for '"Assembly Resolver/Loader"'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

Found 4 results

  1. Sure thing! From the log: [LOG 13:01:37.402] [TweakScale] Version 2.4.6.8 /L [LOG 13:01:37.918] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> 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 KSPe.IO.Hierarchy`1+<>c[T].<calculateTypeRoot>b__10_0 (System.Reflection.Assembly assembly) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at System.Linq.Enumerable+<SelectManyIterator>d__167`3[TSource,TCollection,TResult].MoveNext () [0x0004e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () [0x00059] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable.TryGetFirst[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Boolean& found) [0x00045] in <351e49e2a5bf4fd6beabb458ce2255f3> :0 at System.Linq.Enumerable.FirstOrDefault[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x00000] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at KSPe.IO.Hierarchy`1[T].calculateTypeRoot () [0x000a5] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T].CalculateTypeRoot () [0x00022] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..ctor (KSPe.IO.Hierarchy hierarchy) [0x00007] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..cctor () [0x0000a] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 --- End of inner exception stack trace --- at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr) at KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) [0x0002e] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at TweakScale.Startup.Start () [0x00018] in <c8a4ba9de07c4f43928c3b6b1d79e4c1>:0 at error:0 [LOG 13:01:37.923] [TweakScale] "Houston, we have a Problem!" about Missing DLLs was displayed Oh well, it's that old KSP bug on the Assembly Resolver/Loader again. This crap is bitting our SASes since 1.8 (sigh). TL;DR: this weird bug happens when someone fails to load a DLL - the side effect is that after that, everybody fails to load their DLLs too. Usually, the first occurrence of a System.Reflection.ReflectionTypeLoadException is the trigger for the problem: [ERR 13:01:28.810] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Reflectio nTypeLoadException' 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 <a1ca58b5ca7140639de29a81de5e3f32>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' Apparently, the B9_Aerospace_WingStuff thingy is missing a dependency called KSPUtil. You will need to reach whoever is maintaining this thingy and ask for further help! Cheers! — — POST EDIT — — I think it's B9 Aerospace ProceduralWings - but I'm not sure.
  2. Oh, yeah… Old "friend". There's a nasty bug on a thingy called Assembly Resolver/Loader since KSP 1.8.0 , and it's pretty nasty indeed: when an Assembly borks the loading due a missing or broken dependency, something breaks inside KSP and from that point, everything else borks while loading. Yeah, that's it: DLL A, D, E, F and the kitchen's sink borks because B thrown an Exception while trying to load C that it's missing, and B needed it. On sane system, only B would be affected (and that's what used to happen until KSP 1.7.3), but on KSP 1.8 and newer… So your last update installed something that triggered this problem, and since TweakScale detected it, it's the one yelling about. The funny thing is that TweakScale is almost 99% surely fine (never got a report like this one due a faulty TweakScale installation, it was always something else). Funny fact: I'm starting to be able to infer the KSP the user is using by the bugs he/she reports! Well, the answer is simple: something borked due a missing/broken dependency and triggered that nasty KSP bug. Detecting exactly who is the trigger is easy: check your KSP.log and look for the first occurrence of a Exception called System.Reflection.ReflectionTypeLoadException , as this example from a previous report: [ERR 14:41:14.058] AssemblyLoader: Exception loading 'MoleUtils': 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 <cd473063d3a2482f8d93d388d0c95035>:0 It's important to be sure you found THE FIRST ONE, as everything else are bogus (as they are being issued by the faulty code triggered by the first occurrence). The next line will tell you what gone wrong: Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000003 (from typeref, class/assembly WildBlueIndustries.Window`1, WildBlueTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) On this case, this cryptographic message is telling us that MoleUtils was expecting something on WildBlueTools that was not there. This is another example from another report: [ERR 18:27:45.081] AssemblyLoader: Exception loading 'Konstruction': 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 <cd473063d3a2482f8d93d388d0c95035>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000066 (from typeref, class/assembly USITools.UI.Window, USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null type:USITools.UI.Window member:(null) signature:<none> Exactly the same problem, but from a different Add'On. These are usually cumbersome to fix, because you need to reach the Maintainer and ask him where is the right DLL you need, as the one currently on your system, by some reason, is not compatible to the Add'Ons you have installed. This can be a royal pain in the SAS because not rarely the right DLL for an Add'On you have installed will break another one - usually happening because the maintainer updated a library used by many Add'Ons, but didn't had time to update everything to the latest version of the lib - and yeah, this happens, including to me: the TweakScale 2.4.6.0 took a long time to reach the streets because it uses a new (non retrocompatible) release of a thingy called KSPe.Light.TweakScale, that some TweakScale Companions use (and so I had to update everything first, and then publish everything at the same time). Software, Laws and sausages - it's better not to know how they made them. Finally, the other kind of this problem I have records of: [ERR 17:21:27.114] AssemblyLoader: Exception loading 'ScrapYard_ContractConfigurator': 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 <cd473063d3a2482f8d93d388d0c95035>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' This one is about a missing DLL, and it is pretty easy to fix : find the Add'On where the missing dependency is and install it. Additionally, you can send me the KSP.log so I can check it for you. This ends up being useful for me too, as I keep track of the problems happening on the field on this moment, and can help on planning the next releases (as to be aware of a supported Add'On passing trough a heavy legacy breaking update that needs to be handled by TweakScale). Cheers!
  3. Parallax needs Kopernicus, as it appears. Install Kopernicus and that nasty bug on the Assembly Resolver/Loader will not bite our SASes anymore (that it's, essentially, what prompted TweakScale to yell on the screen - TweakScale checks things before starting instead of trusting everything is allright and then blowing up in the middle of the game!!). [ERR 17:53:17.865] AssemblyLoader: Exception loading 'Parallax': 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' In time, please void pasting the KSP.log on the post. Pasting small pieces of it where you think is the problem is allright, sometimes it helps, but pasting long walls of logs are useless because the Forum has a limit on the size of the post (and it's pretty smaller than the smallest useful log), not to mention the unnecessary overload on mobile users where too much information not only clogs the small screen, but causes performance issues. Manual installing is not hard, once you get a grasp on it. You unzip the package on a temp place (as the Desktop, or the Download folder), then you look for the GameData folder somwhere inside the directory structure. Using the Benjee10's example, if you unzip the thing on your Desktop, you will have something like: C:\Users\<your login>\Desktop Benjee10_Orion_v1.2.0 GameData <yada yada yada> <yada yada yada> Them you drag and drop the GameData's contents (and not the GameData itself!) into inside your KSP's GameData folder. In your case , inside the folder C:\Kerbal Space Program 3\GameData\ . O you can hit Alt+A (select all), then Ctrl-X (cut), open the target's KSP GameData and then hit Ctrl-V (Paste). Pay special attention before overwriting existing files - overwritting other people's files is, usually, a bad idea (besides some pretty borderline situations ends up needed it). Cheers!
  4. I had put it on the backlog, unfortunately pending Real Life™ agreement. https://github.com/net-lisias-ksp/TweakScaleCompanion_FuelSwitches/issues/5 I completely understand you. I'm still playing on 1.4.3 on some savegames… Well.. The mess is not from TweakScale. It happens that KSP has some internal bugs that, unfortunately, were being downplayed by the developers and also by some relevant add'on authors, and when some of these bugs bites TweakScale, it is rendered ineffective. And when this happens, all your scaled parts are screwed on savegame loading - for good. If you are on the gory details mood, search for "Assembly Resolver/Loader". Please note that this affects EVERYTHING, not only TweakScale. Anyone, absolutely anyone that have a custom data into the PART gets screwed when it's bitten by these KSP bug. It only happens that TweakScale is checking for the problem and yelling when it detects it, preventing you from loading and corrupting your savegames. Humm… There's a bug on ZeroMiniAVC (I think) where it's checking for duplicated DLLs where it should not - anything inside a directory called PluginData is plain ignored by KSP, and I use this place for integrity checks and seamless updates. This is unfortunate, because the alternative will be to obfuscate these DLLS, and this is really bad because it's how viruses work and I don't want to risk being flagged as one. Please send me the KSP.log so I can check this for you. I think you have multiple problems happening at once. Please send me your KSP.log using dropbox or similar service - don't try to copy & paste it here, it will screw up Forum, and it will be truncated anyway, rendering it useless. Yep. I know of some users that install TweakScale only for the safety checks, completely ignoring the feature itself (I think one of them even deleted the patches… ). KSP is being plagued by multiple bugs for years - did you know that if you have more than one ModuleManager installed, the oldest one is used instead of the newer one since KSP 1.8? This are that bad, and it's the reason WatchDog and TweakScale are extremely picky about things. There's no "simple solutions" anymore, people going to the easiest path are making things worse. Many things had changed. Some tricks that used to work in the past now cause problems - it's five years of piling changes to cope with…. If you have a somewhat older rig, I suggest you read these two threads two: Buoyancy apparently was an afterthought on KSP, as the drag cubes were used to simulate it. Problem: I need to scale the drag cubes, otherwise the parts will have a very unfair drag, so it's a catch22 situation for now. I demonstrated the problem on this video: I have a task for it here: https://github.com/net-lisias-ksp/TweakScale/issues/252 (pending Real Life™ agreement, unfortunately…) You are right in the sense it's not (at 99.99% of the time at least) a problem on TweakScale, however TweakScale is deadly affected by it, so I had to code that "Houston" thingy to prevent users from losing the savegames. (again, I want to stress out that TS is not the only one suffering - but it's the only one complaining about, as it appears). Publish your KSP.log on dropbox or something, please. I think I need to inspect this one. There're safeties coded on MMWD that may be at jeopardy due this, and if this is the case, I unfortunately will be forced to code a less than sympathetic counter-measure - or hell will be unleashed on me again!
×
×
  • Create New...