The type initializer for 'KSPe.1O.Hierarchy' threw an exception - newest KspE and Lisias module manager.

[pokemoncrusher1]

Receive this error on startup, no other mods installed, KSP 12.2.3 KSP.log

Heres the ksp.log , plugin data folder from KspE is installed into the KSP root directory.

@Lisias , thanks in advance

[pokemoncrusher1]

I should add: when I use the following versions, I dont get this error, but module manager says that it is not present.

[pokemoncrusher1]

Edit: error isolated to KSPe, goes away when switching to KspE 2.3.0.4

[pokemoncrusher1]

I just realised I uploaded the wrong log file, here is the full one. Player.log

I should clarify, this is running the latest release of KspE ,. module manager -L, and ubiozur (irrelevant) error occurs with or without this Thank you for your continued efforts!

[Lisias]

OOWWWWW KRAPPP!!!

It's the God Damned missing Kernel32.dll again!!! #facePalm

[KSPe] ERROR: Fatal Error CriticalComponentsAbsent was shown. e = [The type initializer for 'KSPe.IO.Hierarchy' threw an exception.]. Please visit htt
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

Uploading Crash Report
Win32Exception: The system cannot find the file specified.

  at KSPe.Multiplatform.LowLevelTools.Windows32.GetFinalPathName (System.String path) [0x0002b] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.Multiplatform.FileSystem.Reparse_windows (System.String path) [0x00000] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.Multiplatform.FileSystem.ReparsePath (System.String path) [0x00015] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.IO.Directory.RealPath (System.String path) [0x0001f] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.IO.Directory.Exists (System.String path) [0x00000] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.IO.Path.EnsureTrailingSeparatorOnDir (System.String path, System.Boolean blindlyAppend) [0x00033] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.IO.Path.Combine (System.String path1, System.String path2) [0x00007] in <67792739c4584a1897b06d874e1e20e6>:0
  at KSPe.IO.Hierarchy..cctor () [0x00041] in <67792739c4584a1897b06d874e1e20e6>:0
Rethrow as TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy' threw an exception.
  at KSPe.Util.SystemTools+Assembly+Loader..ctor (System.String namespaceOverride, System.String[] subdirs) [0x00025] in <67792739c4584a1897b06d874e1e
  at KSPe.Startup.Awake () [0x00000] in <67792739c4584a1897b06d874e1e20e6>:0

@pokemoncrusher1 would be you available for some tests? I'm trying (almost) desperately to diagnose this crap for months already. I just don't understand why some Windows rig borks due this….

[pokemoncrusher1]

@pokemoncrusher1 would be you available for some tests? I'm trying (almost) desperately to diagnose this crap for months already. I just don't understand why some Windows rig borks due this….

sure no problem!

[Lisias]

@pokemoncrusher1:

sure no problem!

Do you know how to find a system file on the hard disk? I need to know how many and where are a file named Kernel32.dll. If there's any on your rig.

This file apparently is missing on some Windows rigs - but this file is important for C# programs, I think it's incredibly unlikely MS just removed it from the system.

[pokemoncrusher1]

kernal32search.txt here are all results for kernal32.dll, there is one in system32 and a lot of other copies.- paths to each are included

[Lisias]

Humm…

everything on your rig is on lower case, but the reference code I used to implement the stunt on KSPe.Multiplatform.LowLevelTools used "Kernel32.dll" (upcase K).

Usually this should not be a problem, as until now it was my understanding that NTFS is case insensitive. However, I just found this article on MSDN, and it means that the Case Sensitiveness flag will be eventually set sooner or later on some user. I suspect this may be the reason KSPe borked on @pokemoncrusher1 's machine.

Since your current setup is working for you, @pokemoncrusher1 , I will not ask you to test a beta release of KSPe. I intend to, instead, write two small C# programs - one intended to bork and another intended to work - to test this hypothesis. Can I ask you to, once I made them, to download these programs and run them to see what happens?

Thanks in advance!

[pokemoncrusher1]

yes that is ok, I can also test any version of kspE you need me too, I really do not mind at all.

[Lisias]

Hi, @pokemoncrusher1 ! Thanks for the help!

On this link you will find a pre-release with what I hope is a fix for this problem. (Click on the Download button, as emphasised below).

If I'm right, this will work on your rig (but I'm afraid you would need to update UbioWeldingLtd too, as I broke binary compatibility on the 2.4 series).

Let me know if this solves the problem (or not!).

Thanks in advance!

[pokemoncrusher1]

@Lisias same error on launch, MM-L detects a patch error, here is the log file - it seems to be different this time. Player.log

Don't be afraid to ask me for testing, thank you.

[Lisias]

@pokemoncrusher1 ,

@Lisias same error on launch, MM-L detects a patch error, here is the log file - it seems to be different this time. Player.log

I think it happened in a different time, but in the end it was the same problem.

[KSPe] ERROR: Fatal Error CriticalComponentsAbsent was shown. e = [The type initializer for 'KSPe.IO.Hierarchy' threw an exception.]. Please visi
t https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/17 at Show:0
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

Uploading Crash Report
Win32Exception: The system cannot find the file specified.

  at KSPe.Multiplatform.LowLevelTools.Windows32.GetFinalPathName (System.String path) [0x0002b] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.Multiplatform.FileSystem.Reparse_windows (System.String path) [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.Multiplatform.FileSystem.ReparsePath (System.String path) [0x00015] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Directory.RealPath (System.String path) [0x0001f] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Directory.Exists (System.String path) [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Path.EnsureTrailingSeparatorOnDir (System.String path, System.Boolean blindlyAppend) [0x00033] in <73686b5a7ee54464abdb5eae67ccdb52>
:0
  at KSPe.IO.Path.Combine (System.String path1, System.String path2) [0x00007] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Hierarchy..cctor () [0x00041] in <73686b5a7ee54464abdb5eae67ccdb52>:0
Rethrow as TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy' threw an exception.
  at KSPe.Util.SystemTools+Assembly+Loader..ctor (System.String namespaceOverride, System.String[] subdirs) [0x00025] in <73686b5a7ee54464abdb5ea
e67ccdb52>:0
  at KSPe.Startup.Awake () [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0

I need to think a bit about this problem - otherwise I would send you on a blind fishing expedition, what would be a waste of time for both of us. If we are going to fish, at least we need to find a suitable spot to maximize our chances… :)

Do you have disk space (and will) to create a temporary KSP 1.11 or 1.9 or even 1.8 test bed? I want to rule out any KSP 1.12.3 interference from the problem.

(I just diagnosed a "problem" for a fellow Kerbonaut where he tought that an add'on was halting his game, but in the end we realised that something on KSP 1.12.3 had changed and made a few things way slower - on my own rig the affected process is taking 45 seconds to initialise on KDP 1.12.3, but only 2 seconds on KSP 1.4.1 with more or less the same add'ons - I have personal forks of some add'ons where I make them compatible with everything from 1.4.1 1.12.3, so I can do pretty accurate comparisons…)

Currently, I have 3 hypothesis:

1. Your kernel32.dll is corrupted - I had heard some some GPU device drives screwing up by installing a bad one there (probably a very old version from a previous Windows release)
2. Something on your system had stripped out C:\Windows\System32 folder from the application's search path
3. KSP itself did this on its own process

I would advice against trying to download and replace the kernel32.dll file yourself - this is a very sensitive system file, and you can screwup something pretty seriously. I think it's safer to rule out the alternatives first before even considering mangling this file.

The easiest way (for me :P ) to rule out (or not) the options 1 and 2 (and perhaps any 4th I could think off later) is to check the option 3. If an previous KSP release that never gave me this problem before behaves like what you have now, we had ruled out KSP as culprit and should pursue something on your rig.

But if by some reason an older KSP works, we have a confirmation that it's something recently screwed on KSP (again) - and so we can focus on trying to figure out what.

[pokemoncrusher1]

@pokemoncrusher1 ,

@Lisias same error on launch, MM-L detects a patch error, here is the log file - it seems to be different this time. Player.log

I think it happened in a different time, but in the end it was the same problem.

[KSPe] ERROR: Fatal Error CriticalComponentsAbsent was shown. e = [The type initializer for 'KSPe.IO.Hierarchy' threw an exception.]. Please visi
t https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/17 at Show:0
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

Uploading Crash Report
Win32Exception: The system cannot find the file specified.

  at KSPe.Multiplatform.LowLevelTools.Windows32.GetFinalPathName (System.String path) [0x0002b] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.Multiplatform.FileSystem.Reparse_windows (System.String path) [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.Multiplatform.FileSystem.ReparsePath (System.String path) [0x00015] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Directory.RealPath (System.String path) [0x0001f] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Directory.Exists (System.String path) [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Path.EnsureTrailingSeparatorOnDir (System.String path, System.Boolean blindlyAppend) [0x00033] in <73686b5a7ee54464abdb5eae67ccdb52>
:0
  at KSPe.IO.Path.Combine (System.String path1, System.String path2) [0x00007] in <73686b5a7ee54464abdb5eae67ccdb52>:0
  at KSPe.IO.Hierarchy..cctor () [0x00041] in <73686b5a7ee54464abdb5eae67ccdb52>:0
Rethrow as TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy' threw an exception.
  at KSPe.Util.SystemTools+Assembly+Loader..ctor (System.String namespaceOverride, System.String[] subdirs) [0x00025] in <73686b5a7ee54464abdb5ea
e67ccdb52>:0
  at KSPe.Startup.Awake () [0x00000] in <73686b5a7ee54464abdb5eae67ccdb52>:0

I need to think a bit about this problem - otherwise I would send you on a blind fishing expedition, what would be a waste of time for both of us. If we are going to fish, at least we need to find a suitable spot to maximize our chances… :)

Do you have disk space (and will) to create a temporary KSP 1.11 or 1.9 or even 1.8 test bed? I want to rule out any KSP 1.12.3 interference from the problem.

(I just diagnosed a "problem" for a fellow Kerbonaut where he tought that an add'on was halting his game, but in the end we realised that something on KSP 1.12.3 had changed and made a few things way slower - on my own rig the affected process is taking 45 seconds to initialise on KDP 1.12.3, but only 2 seconds on KSP 1.4.1 with more or less the same add'ons - I have personal forks of some add'ons where I make them compatible with everything from 1.4.1 1.12.3, so I can do pretty accurate comparisons…)

Currently, I have 3 hypothesis:

1. Your kernel32.dll is corrupted - I had heard some some GPU device drives screwing up by installing a bad one there (probably a very old version from a previous Windows release)
2. Something on your system had stripped out C:\Windows\System32 folder from the application's search path
3. KSP itself did this on its own process

I would advice avoiding trying to download and replace the kernel32.dll file yourself - this is a very sensitive system file, and you can screwup something pretty seriously. I think it's safer to rule out the alternatives first before even considering mangling this file.

The easiest way (for me :P ) to rule out (or not) the options 1 and 2 (and perhaps any 4th I could think off later) is to check the option 3. If an previous KSP release that never gave me this problem before behaves like what you have now, we had ruled out KSP as culprit and should pursue something on your rig.

But if by some reason an older KSP works, we have a confirmation that it's something recently screwed on KSP (again) - and so we can focus on trying to figure out what.

sure, I can do that? What version @Lisias

[Lisias]

sure, I can do that? What version @Lisias

Let's try KSP 1.9.1 - its somewhat smaller, and I had confirmation that this thing works on it.

[pokemoncrusher1]

sure, I can do that? What version @Lisias

Let's try KSP 1.9.1 - its somewhat smaller, and I had confirmation that this thing works on it.

sure, downloading now.

[pokemoncrusher1]

Player.log Issue persists on ksp 1.9.1 latest MM-L and the prerelease of KspE, same with latest stable release of KSPE Log above @Lisias

[pokemoncrusher1]

@Lisias I just found some more debug info. Using process monitor I saw some abnormalities when KSPe searches for kernel32.

If you look at the bottom line, it looks like kernel32.dll was fileinfonamequeried in system32, I can also see it searches in
C:windows, wow64, and ksproot, and system32, I tried adding the DLL to each of these folders but it still returns the above result despite the files absolutely being there. The one in ksp root shows buffer overflow which means it might be seen(?) but I don't really know for sure. -Either way for some reason it looks like for some reason or another KSPe does not see kernel32.dll , despite it being there and being able to name it. I tried cmd prompting to kernel32 and was able to detect it without admin access, so I don't really understand why. Sorry for any mess btw, I just thought this info might be helpful to you

[Lisias]

@pokemoncrusher1 thank you very much for the information.

KSP is ruled out, we have a problem on Mono, on Windows, or Kranken knows where :)

I'm looking into the logs.

[Lisias]

@pokemoncrusher1

The one in ksp root shows buffer overflow which means it might be seen(?) but I don't really know for sure. -Either way for some reason it looks like for some reason or another KSPe does not see kernel32.dll

Uh…. WAIT A MINUTE…

We have on KSP this weird issue in which borking on loading a dependency would screw up things for everybody loading dependencies later, no matter the dependency is there or not.

What if the problem's root is on a lower level?

Please remove the KERNEL32.dll on KSP's root and see what happens!

[pokemoncrusher1]

@Lisias Ok, removing it now.

[pokemoncrusher1]

Same result with it removed,

@Lisias

[Lisias]

@pokemoncrusher1

Well… What we have until know:

• The KERNEL32.DLL on KSP's folder appears to be screwed up - perhaps an older version for an older Windows version
• There's a kernel32.dll on your C:\Windows\System32
• There's a KERNEL32.dll on your C:\Windows\SysWOW64

There're also multiple copies of UnityPlayer.dll - on System32 and on SysWOW64. I'm not exactly comfortable with this, because we just don't know from what Unity Version these DLLs are.

And, interesting enough, there's also a BUFFEROVERFLOW while trying to access what I think should be the right UnitPlayer.dll to be used, the one on KSP's folder….

Apparently, you are buried into a hell of a DLL HELL. This is just nuts IMHO.

The next logical step would be to start to remove all redundancies to see what happens - but this may screw up some other Unity games you may have installed.

Do you have a way to clone this Windows installations into a VirtualBox VM or similar?

[pokemoncrusher1]

@Lisias , Im pretty sure kernel32 is supposed to be found in both of these locations, as if you go to dll download websites these locations are listed. I also tried download a kernel32.dll and putting it in the ksp root folder but still buffer overflow

I will remove these unityplayer.dll aswell in sys32 etc, they are not essential and I can always add them back.

I will post the logs in a hour or so

[pokemoncrusher1]

@Lisias , Im pretty sure kernel32 is supposed to be found in both of these locations, as if you go to dll download websites these locations are listed. I also tried download a kernel32.dll and putting it in the ksp root folder but still buffer overflow

I will remove these unityplayer.dll aswell in sys32 etc, they are not essential and I can always add them back.

I will post the logs in a hour or so

Actually, there is no UnityPlayer.dll in any of these folders - I think unity maybe searches there by default? It does say "NO SUCH FILE" so I'm guessing it doesn't find them there either,

it does find it in ksp root but again shows buffer overflow- the buffer overflow is similar to the kernel32.dll - this might indicate that is it possible KSP itself is doing something wrong where it finds these files but messes up on using them or accessing them?

It also could be possible the issue could be Unityplayer.dll and be falsely reported? I am still baffled as to why kernel32 shows as successfully queried but then an issue is reported.

[Lisias]

@pokemoncrusher1

it does find it in ksp root but again shows buffer overflow- the buffer overflow is similar to the kernel32.dll - this might indicate that is it possible KSP itself is doing something wrong where it finds these files but messes up on using them or accessing them?

It's something to consider, without a doubt. But, yet, I find it weird why this started to happen only now - this code is there for years. And it worked on the 1.9 times...

I think this may be due some change by a Windows Update that broke some finickle dependency on KSP? This stunt used to work in the past...

It also could be possible the issue could be Unityplayer.dll and be falsely reported? I am still baffled as to why kernel32 shows as successfully queried but then an issue is reported.

I'm prone to think that we are chasing ghosts at this point….

I'm reading some tech docs about DllImport and they strongly advise against the use of StringBuilder while calling native code - and this is exactly what I'm doing on that code.

I will finish reading that document and I will try something in the next couple hours. Stay tuned.

[Lisias]

I'm a fscking idiot. The problem was yelling under my nose all the time, but I was not hearing it.

The use of StringBuffer is not advised due inefficiencies. At this point, I can live with such inefficiencies as all I want is to solve this freaking problem.

When the code was initially written, the pathname limits on Windows were set to 260 chars. I used a buffer with 1024 chars "to be on the safe side". But now we have utf-8 support on pathnames using foreign characters, and a utf char ends up represented on 2 or even 3 octets on utf-8 - and the 260 chars limit obviously is no enough anymore and it's being raised on a configuration somewhere in the Windows Registry.

Being not enough, Steam, GOG and the kitchen's sink are storing KSP inside a long chain of subdirectories, adding gas to this burning fire.

So it's feasible that some Windows installations are breaking KSPe (and perhaps KSP itself!) due this - I'm not the only idiot around here! :D

This doesn't explains all the occurrences I'm getting - I just get another report from a dude on Windows in RU localisation - but the pathnames are all smaller than 260. But since this code is called when a Reparse Point is found, it's perfectly possible that the origin of the reparse point would be such it would trigger this problem.

@pokemoncrusher1 , I'm trying a stunt. I'm shoving more bytes on the StringBuilder I'm using to see what we get. I'm building another prerelease in the next few minutes.

[pokemoncrusher1]

I'm a fscking idiot. The problem was yelling under my nose all the time, but I was not hearing it.

The use of StringBuffer is not advised due inefficiencies. At this point, I can live with such inefficiencies as all I want is to solve this freaking problem.

When the code was initially written, the pathname limits on Windows were set to 260 chars. I used a buffer with 1024 chars "to be on the safe side". But now we have utf-8 support on pathnames using foreign characters, and a utf char ends up represented on 2 or even 3 octets on utf-8 - and the 260 chars limit obviously is no enough anymore and it's being raised on a configuration somewhere in the Windows Registry.

Being not enough, Steam, GOG and the kitchen's sink are storing KSP inside a long chain of subdirectories, adding gas to this burning fire.

So it's feasible that some Windows installations are breaking KSPe (and perhaps KSP itself!) due this - I'm not the only idiot around here! :D

This doesn't explains all the occurrences I'm getting - I just get another report from a dude on Windows in RU localisation - but the pathnames are all smaller than 260. But since this code is called when a Reparse Point is found, it's perfectly possible that the origin of the reparse point would be such it would trigger this problem.

@pokemoncrusher1 , I'm trying a stunt. I'm shoving more bytes on the StringBuilder I'm using to see what we get. I'm building another prerelease in the next few minutes.

Ok! Ping me when needed! 😁

[Lisias]

@pokemoncrusher1 , this is the stunt I talked about:

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/PRERELEASE%2F2.4.1.9

It's the same 2.4.1.7 (the latest official) but expanding the StringBuffer size to 8192 (efficiency? screw that crap!) and some more useful exception raising.

Let me know whatever happens by using this, the KSP.log of any misbehaviour will be useful with the fancy exception's messages.

[pokemoncrusher1]

@Lisias I think the log file appears to have changed! Player.log Win32Exception: Got a invalid handle while CreateFile for G:\KSP TEST BENCH\Kerbal Space Program 1.9.1\GameData__LOCAL

• errorno2

procmon shows same bufferoverflow but the log file change shows the buffersize may have been a roadblock!

Thank you for your continued efforts!

[Lisias]

Post removed. I make a copy*error mistake on a markdown string, and this changed everything!

[pokemoncrusher1]

let me know if you need me to do anything!

[Lisias]

Oukey, let's try again.

@Lisias I think the log file appears to have changed! Player.log Win32Exception: Got a invalid handle while CreateFile for G:\KSP TEST BENCH\Kerbal Space Program 1.9.1\GameData__LOCAL

• errorno2

Unexpected, this caught me with my pants down….

Let's see what's errno 2 at first place…

ERROR_FILE_NOT_FOUND 2 (0x2) The system cannot find the file specified.

WHAT-A-HELL??? o.O

How in hell this file/directory doesn't exists, if I only manage to know about it by reading its pathname while running trough the KSP directory structure???? O.o

Well… Back to the basics. @pokemoncrusher1 , please check if there's a G:\KSP TEST BENCH\Kerbal Space Program 1.9.1\GameData\__LOCAL on your G: disk, and if it's a folder, a file or a symbolic link to one of these.

In time, this "G" drive… it's a real volume (hard disk or ssd partition) or a network resource mounted on G:?

This is getting weirder and weirder…

— — NOTE — —

I was completely wrong until now. You really found something fishy on KSP while trying to load KERNEK32.dll and UnitPlayer.dll, but that BUFFER OVERFLOW thingy appears to be not playing a role on the problem at hands.

(This can be problem to KSP, however - if by any reason that BUFFER_OVERFLOW is preventing the loading of the intended DLL, another one will take its place and the net result is KSP running using a DLL that was not certified bu the QAS team!)

As it appears, finding the kernel32.dll was never a problem on KSPe, I was borking while trying to use it. The reason for this bork is our main concern now.

[pokemoncrusher1]

@Lisias this is seriously weird

• __LOCAL doesn't exist, says it cant be created,I added it manually, then it asks for screenshots folder, then for thumbs, then for MM folder in game data, then MM in root, then MM in plugin data, SO I add ModuleManager folder to every folder of KSP - last log THen its asking for ConfigSHA.cfg - which I don't have so I'm ending it here before I have 90 log files, I will gladly continue if I had that file.

Additionally, KSPe loading screen now shows this error

• Here is the procmon logs where it wants to create file-

• 

below log for each step I did, as you can see the requested folder changes

__LOCAL ADDED.log Screenshots aded.log thumbs added.log [mm root adde.log](https://github.com/net-lisias-ksp/KSPAPIExtensions/files/8107016/ MM plugindata added.log mm added __local.log mm.root.adde.log) GD MM added.log MODULEMANAGER FOLDER ADDED TO EVERY FOLDER.log

My hypothesis: Something is blocking creation of some sort of essential file, kspE tries to read it but it is not there- leading to error 2- I have heard potentially createfile is used to read files aswell- denoted by read access in right column - possibly kspE is searching every directory for what it needs- but it Is not there, and after I create it for some reason wants another?

could also be a mm issue but unsure

very very strange indeed- it also looks like k32 is being read ok, as create file shows successful on procmon - very very odd

-also G is just a HDD

[Lisias]

@pokemoncrusher1

could also be a mm issue but unsure

I don't believe this is something caused or induced by third-parties (i.e., MM is innocent).

This is something I'm screwing up (and I just can't conceive where!), or this is something being screwed up by Mono, Windows or both.

I'm inspecting your log files. Let's see if I find something...

[Lisias]

KRAAAAP… I'm an idiot, really…. #facePalm .

It's the first time you are firing that KSP test bed, these folders were not created yet by KSP! (and __LOCAL is my invention, it will never be automatically created by KSP).

I plain forgot that one may install KSPe on a newer KSP rig that was never fired up before!!!!

Geez… What a mess….

I'm working on this right now, and I will publish a new package once I implement this!

(dude, thanks for your help! and sorry taking so many tests from your side to find this blunder of mine!)

[Lisias]

Commit https://github.com/net-lisias-ksp/KSPAPIExtensions/commit/cb9ccb5616043098f063fda0a7d08e2f82cc4d74 should fix the blunder!

[pokemoncrusher1]

@Lisias is there a compiled version link? - I might just be blind

[Lisias]

@pokemoncrusher1 ,

My hypothesis: Something is blocking creation of some sort of essential file, kspE tries to read it but it is not there- leading to error 2- I have heard potentially createfile is used to read files aswell- denoted by read access in right column - possibly kspE is searching every directory for what it needs- but it Is not there, and after I create it for some reason wants another?

You almost nailed. The problem is not something blocking the creation of that directories, the problem was me not creating them at first place! You just detected a missing (and very important) use case: launching KSP by the first time with KSPe already installed!!

Apparently, I never installed KSPe on a clean, recently installed, never fired up KSP instalment before!

Additionally, after the final "errno 2" due "thumbs", in your long I found a lot of problems with "errno 3" that means:

ERROR_PATH_NOT_FOUND 3 (0x3) The system cannot find the path specified.

This is yet another blunder of mine while probing some key folders on plugins - some add'ons put that folder on slightly different places inside it's hierarchy, and KSPe is probing for them. However, I inadvertently implemented a function Reparse_windows in a way that its results differs from Repase_readlink when the target pathname doesn't exists!

I'm working on it right now.

is there a compiled version link? - I might just be blind

Not yet. I need to rework a function first. This will take a hour more or less...

[pokemoncrusher1]

no problem take your time! Dont lose sleep over me :)

[Lisias]

no problem take your time! Dont lose sleep over me :)

Too late. I tasted "blood", I'm going for the kill. :D

[Lisias]

@pokemoncrusher1 , new pre-release:

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/PRERELEASE%2F2.4.1.10

I reworked the previous fix, and changed the Window's reparsing to behave exactly like the UNIX one - so, in essence, I expect that the Windows will behave exactly like UNIX does now - I would had detected these problems way sooner and easier if i had not deviated the behaviour on Windows.

Let me know what happens, one way or another!

(thanks again!)

[pokemoncrusher1]

@Lisias no more win32 file not found error, so looks like that might be fixed, only issue now is a stack overflow - hopefully easier to figure out than the ghost chasing of kernel32! Player.log

thanks again

[Lisias]

@Lisias no more win32 file not found error, so looks like that might be fixed, only issue now is a stack overflow - hopefully easier to figure out than the ghost chasing of kernel32! Player.log

ugh… :/

Working on it. (this is yet another major blunder - that I don't really understand why didn't had blown up on my face yet)

[Lisias]

Oukey, @pokemoncrusher1 , another pre-release!

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/PRERELEASE%2F2.4.1.11

Let's see if I managed to make it the final one before a proper release! :)

[Lisias]

Note: I was sleepy and didn't fixed the thing properly. (sigh). release .12 will be issued soon.

[Lisias]

Less "soon" than anticipated, but "soon" enough I hope.

@pokemoncrusher1 , I fixed 2 others occurrences of the problem I fixed on last release. I fired up this thing on MacOS (as the affected code theoretically is also used on Mac and Linux) but yet the final word about the fix is yours.

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/RELEASE%2F2.4.1.12

Let me know if I did it this time! Cheers!

[pokemoncrusher1]

@Lisias Hoorah! it works finally! - no errors in my logs on ksp 1.12.3 , this version also fixed an issue where your module manager fork was not patching, but now all appears to be good except for the MM warning screen- Probably cosmetic

Probably cosmetic

Anyways,

My hypothesis as to why this error was sparse and only on some rigs- On my main install of ksp with all my mods - before installing the new kspe version I still did not have any of those folders that were created after your fixes - even though I had run many mods through ksp already! - it looks like for somereason, those folders are not created on some installs for some reason -

I genuinely also think there were 2 present issues - the first being the stringbuilder chars - and the second being the dependendant directiories

Now that both of these are fixed everything seems to work fine! - hopefully it also works for the other users aswell

I really commend your strive and dedication to this project and to the KSP community as a whole! - thank you so very very much and don't be afraid to contact me if you need extra testing for something !

[Lisias]

Hi, @pokemoncrusher1

You are welcome. And, again, thank you very much for your efforts on helping me to diagnose the problem!

In time, you installed the KSP 1.2 binary of the MM. KSP 1.2 is way different from KSP1.3 and newer (to tell you the true, is more a Unity problem than anything else).

For KSP 1.3 to 1.12.3, you need to install the other package. You need to download and install the one emphasised below:

I think I need to do a better description for this stunt.. :)

[pokemoncrusher1]

Hi, @pokemoncrusher1

You are welcome. And, again, thank you very much for your efforts on helping me to diagnose the problem!

In time, you installed the KSP 1.2 binary of the MM. KSP 1.2 is way different from KSP1.3 and newer (to tell you the true, is more a Unity problem than anything else).

For KSP 1.3 to 1.12.3, you need to install the other package. You need to download and install the one emphasised below:

I think I need to do a better description for this stunt.. :)

Ok, thanks for the explanation

[Lisias]

Well, case closed! Cheers!