Dunbaratu

You are 100% correct that it's dumb to work this way, but it does, because Microsoft. Yes, I agree that the exception should only happen when the DLL is first being loaded, not *again and again* every time someone uses reflection to look at the classes. Once someone is using reflection to look at the classes, the classes that don't exist simply, well, shouldn't exist. Not "sort of halfway exist enough to break GetTypes() and make it throw an exception." There is a fix, though. What MS, in their infinite wisdom, decided to do here is make GetTypes() throw an exception despite the fact that it worked just fine. And then, because it threw the exception, that means the return value is inside the exception object instead of being returned in the normal fashion. You can see what I did to fix it here: https://github.com/KSP-KOS/KOS/pull/2492/files

That's a weird way to phrase it. kOS not working with Wind Tunnel is *already* how it is. I think you added a "not" in there by accident that flipped the meaning. Also, just to make it clear, getting an update to kOS that has this fixed *still* doesn't mean you'd have a working Wind Tunnel mod. The problem happened because Wind Tunnel's DLL file won't load in KSP 1.7, and kOS can be broken by any other mod's DLL failing to load because I didn't know how weirdly Microsoft implemented its reflection GetTypes() call (When a DLL didn't load one of its classes, GetTypes() still works anyway but it does so by throwing an exception and moving its return value into that exception's fields instead).

I know it's mostly moot now that a new KAS version is out that works with KSP 1.7, but I wanted to report that I found the cause of this error in kOS and it was *sort of* caused by the fact that KAS didn't load, combined with me not understanding the really weird way GetTypes() works when DLL's fail to load. I would have assumed that "Failure to load this Type" would only throw an exception once - at the time the DLL is being loaded. Then after that if you trapped the exception that the loader generated and keep going (as KSP itself does when trying to load mods), then from then on the Type would simply not even be present at all, because it failed to load. But actually there still is an empty stub of the class there when it didn't load - just enough of one for GetTypes() to attempt to do things with it, and then to make GetTypes() work you have to trap the exception and pull the information from elsewhere to work around the fact that one of the Types that GetTypes wants to return isn't "really there".

I believe I may have a workaround for this "can't open terminal" problem so it doesn't happen again in future versions (i.e. kOS doesn't get ruined by *another* mod's DLL incompatibility). My fix which seems to handle it - making it not crash even when the broken versions of KAS or Wind Tunnel are installed, is this: https://github.com/KSP-KOS/KOS/pull/2492/files This doesn't actually fix the original problems with these other mods failing to work - that's on them - but it fixes the problem of their failure to load in turn causing kOS to fail to work. The comments in the code are verbose, because I may want to show this to other modders who had the same problem, and I want to explain it to them. The actual code lines are not many.

Microsoft has bizarre alien ways of thinking. I find their techniques a weird random hodgepodge. It would seem more intuitive that if the actual error occurs at the time the DLL is loaded, then that's when to have an exception to get a developer's attention, and if that exception is caught and ignored by the dev, then from then on make GetTypes() just return the classes that really exist, or have it be considered normal for it to be populated with some incomplete Types that have some kind of "loaded = false" flag on them that you have to protect around (or a bitflag set of options to GetTypes, as is common in other reflection calls, one of which explicitly says "only get the ones that are loaded, please".) There's other ways to do it that wouldn't have had this weird "If there's a warning it still works anyway but you have to retrieve the return value from *over there* instead of where it belongs.". Anyway, thanks for the information. It makes the problem fixable.

Okay I've *never* seen an exception work that way before, ever. So basically, its saying the exception didn't interrupt the program flow at all, and GetTypes() continued doing the rest of its work on the other classes before it finished. It still built the rest of the list. You just have to look inside the exception to find it, since it didn't return in the normal fashion. That's utterly bizarre way to use an exception but at least it's a workaround. (It's weird to me because it's basically using an exception for something that's a mere warning, rather than using it for an error that actually broke program flow.)

It's as if the system is contradicting itself, by saying, "that class is doesn't exist, so I can't include it in GetTypes()" and "that class exists, so I will include it in GetTypes()" at the same time. If it doesn't exist, then why is GetTypes() including it and therefore bombing out? Is there any set of flags, or another call I can use, that tells the system, "When I say GetTypes(), what I meant was the ones that are really there. Get me the Types that you actually loaded. If 1000 classes were attempted to be loaded, but 1 of them failed to load, then fine, at least let me see the other 999 of them." I feel like I'm still going to want to protect myself from this in the future, even if KAS and Wind Tunnel get a 1.7 upgrade to fix this one instance of the problem. I wasted a lot of my own time debugging a problem that wasn't "mine" to fix, it turns out. If I cannot find a better version of what GetTypes() does that actually executes it safely, then I'll just have to trap the exception and issue a message to the user along the lines of "Some Mod, which might be kOS or might be some other mod, I can't tell which, has tried to load a class and it failed. This is going to break kOS, but kOS can't fix it - check your error log for the first exception that looks like this: ....... and remove the mod it's talking about." The bettter solution (but much uglier) would be to have a safe way to query all the type names that GetTypes() *wants* to return, in a fashion that won't break, and then try accessing them one at a time with a try/catch wrapper around each attempt, so that when the attempt fails I can at least report which class it is that's causing it, rather than just having GetTypes() in general fail overall.

Here's the long github issue I wrote about this: https://github.com/KSP-KOS/KOS/issues/2491 What I'm basically asking is this - do any other plugin writers out there use the System.Reflection.Assembly.GetTypes() call, and are you having it barf on you with an exception just like I am, starting in KSP 1.7 when it didn't happen in KSP 1.6? The issue linked to above gives the long winded details of the issue. I just wanted to see if others have the same problem, because I am noticing other mods in the output_log also throwing exceptions trying to call GetTypes(). It's as if when the problem happens, then it fails for everyone else too. (Or at least a lot of other people not just me).

Oops - yes I mean KAS not KAC.

In this case, the first mod that shows an error with GetTypes() is KAC. As a quick test, what happens if you try without KAC installed? (Careful don't load your existing save with KAC missing if that save has any KAC parts on vessels, as it will delete those vessels - try it with a fresh new save if your existing save has any KAC parts). Does removing KAC change anything? I have seen posts over in the KAC thread that say KAC has problems loading in 1.7, even without kOS.

There are two different issues being talked about simultaneously in this thread. The issue where I asked about doing 1, 2, or 3, was not the issue you had. Your issue is about KSP Loading and running but without the kos terminal working. The only examples of logs I've seen from that issue were from people who had kerbal wind tunnel, where removing kerbal wind tunnel made it go away. What makes your version different is that you say you don't have kerbal wind tunnel, which means *something* is different from their problem, but I can't really diagnose what until later when you have a chance to generate that log and post it. The "1,2, or 3" question was about Someone2018's issue which was different, where all of KSP broke entirely and crashed so it didn't even get as far as being able to enter the flight scene to even try to open the kOS terminal, and Someone2018's log indicated it was a totally different problem in a different part of the program.

@Someone2018 If nothing else, I can at least tell you how you can try to bypass that screen by directly editing your persistent.sfs savegame to trick it into thinking you've already given it an answer. (As with any edit to persistent.sfs, make sure you copy it to some other name first in case you screw up so you can get it back.) Look for this section of your persistent.sfs save: kOSConnectivityParameters { Look for which of the conditions below is the one you want, and edit your section to look exactly like it shows: IF: you do NOT have Remote Tech installed, and you want to use PermitAll (kOS ignores comms and always pretends you're connected), then make that section look like this: kOSConnectivityParameters { version = 0 knownHandlerList = PermitAllConnectivityManager,CommNetConnectivityManager connectivityHandler = PermitAllConnectivityManager } IF you do NOT have Remote Tech installed, and you want to use CommNet (you want kOS to obey the stock game's antenna connection rules), then make it look like this: kOSConnectivityParameters { version = 0 knownHandlerList = PermitAllConnectivityManager,CommNetConnectivityManager connectivityHandler = CommNetConnectivityManager } IF you DO have Remote Tech installed, then you should use Remote Tech connectivity manager, and make it look like this: kOSConnectivityParameters { version = 0 knownHandlerList = PermitAllConnectivityManager,RemoteTechConnectivityManager connectivityHandler = RemoteTechConnectivityManager } If nothing else, that should let you get past that initial dialog box so at least you can play, but I still would like to get to the bottom of what causes this.

Well darn. Can you temporarily set the 180% scale down to 100% just to see if that changes the behavior of the bug at all? One change I made in kOS 1.1.7.0 was to move that dialog box offcenter to fix this issue: https://github.com/KSP-KOS/KOS/issues/2456 I don't know if that affects this, but the place it is crashing according to your log *is* the place where KSP checks the corners of that box to see if it's offscreen. Why that would throw a null exception instead of just handling it or refusing to work if it doesn't like what it sees, I don't know. I also know I had the box hanging partially offscreen a number of times and it was fine when I tested anyway. The problem seems to be happening when the box is trying to *close* itself, actually. So I wonder if some weird timing issue is causing KSP to try calling the offscreen checker *after* the box has started to dispose of itself and its not all there anymore, thus the null ref. Also, that box appears only if the game is a newly started save from the beginning, or at least a game in which kOS was just installed and had not been running beforehand in that save. If it's a save where kOS was already installed and used in that save, and that dialog box was already answered, then it shouldn't come back again in that save. Which situation is having the crash happen? 1 - kOS already installed, then start a brand new savegame from scratch. (This is a case that I would expect the dialog box to appear). 2 - kOS NOT installed, then start a brand new savegame, then exit KSP and install kOS, then run KSP and resume that savegame. (a game that was started without kOS, then had kOS added later). (This is a case that I would expect the dialog box to appear). 3 - kOS already installed, the savegame already has the connectivity manager selected, and you continue it as normal (this is the case where I would NOT expect the dialog box to appear).

Okay you have *got* to be kidding me. The dialog box that kOS opens to ask for a connectivity manager is causing some weird nullref exception in KSP if any corner of it is off the edge of the screen when it gets dismissed. WTH??? Are you running in a small screen resolution where that dialog is hanging off the edge of the screen? I tested for the smallest resolution setting available on the settings screen when I moved the dialog box offcenter and it never bombed out even when one corner of the box was off the edge of the screen, but in your case that is the very call it's bombing out in - the call KSP makes to test the bounds of the box. Note this is happening when kOS tells KSP to *dismiss* the box, so it may be that KSP will crash whenever a dialog box goes away while partly off the edge of the screen?? Also, annoyingly, your case isn't the one the others are talking about. You're having KSP crash *before* it loads. Other people are having the terminal fail after KSP is loaded. [Edit: sorry - what I mean is annoyingly for me, since I want to find out what is causing the terminal not appearing bug, since I thought I had it nailed down to Wind Tunnel, but if people are getting the problem without Wind Tunnel then I haven't totally found it. I still need one of THOSE logs to look through.]

Again, could someone who does NOT have WInd Tunnel installed but DOES have this problem with the terminal not appearing please post their log? So far the only people who have posted their log have all had Wind Tunnel installed, and removing that mod has fixed the problem for them. For me to help the people who do NOT have Wind Tunnel, I need to see *their* logs. I haven't *seen* any examples yet of this case because all the examples I've been shown so far have been with Wind Tunnel.

kOS has been broken by this same error message in 1.7, but only on *some* installs and not others: [EXC 10:33:17.243] ReflectionTypeLoadException: The classes in the module cannot be loaded. System.Reflection.Assembly.GetTypes () And a few other mods have had the same problem, where any attempt to call System.Reflection.Assembly.GetTypes() throws an exception. In some cases in kOS, removing the other mod, Kerbal Wind Tunnel, made the error go away. Kerbal Wind Tunnel includes a side-library called Accord, which seems to be the first case of this call failing in the log. I have no other information about this problem, but I thought it might help to describe this.

It is possible that something accidentally changed in how I compiled 1.1.7.0 such that it's not the same version of .net, but I don't *think* I changed any settings.

See above comment. You have Wind Tunnel installed. Its including a DLL that isn't working and it wrecks kOS. The relevant part of your log is this: Non platform assembly: C:\Users\user\Downloads\Kerbal Space Program\GameData\WindTunnel\Plugins\Accord.dll (this message is harmless) ADDON BINDER: Cannot resolve assembly: System.ComponentModel.DataAnnotations, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) ADDON BINDER: Cannot resolve assembly: System.ComponentModel.DataAnnotations, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) AssemblyLoader: Exception loading 'Accord': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 https://github.com/DBooots/KerbalWindTunnel/issues/5 I was more interested in seeing the log of @garwel who reports having the problem *without* Wind Tunnel installed, which means it might be a different problem than this one I've already seen.

Usually if the terminal won't open, there is something being complained about in the unity log. Usually the terminal won't open because something is throwing an error during kOS's initial setup, so the rest of kOS's initialization got skipped. Behind the scenes, there's usually a lot more that's "broken" than the terminal, it's just that trying to open the terminal is the first step toward doing most other things, so it's the step where you first notice kOS isn't working. Can you put the full output log somewhere I can read it? (Don't try to trim it down to just the parts you think are relevant - find somewhere that will let you post the entire log from the start of the game to the point when you attempted to open the terminal. Sometimes the actual first cause of the problem occurs much earlier than the snippet users show me, and the part they show is just the effect, not the cause.)

Do you have Kerbal Wind Tunnel installed? If you do, try removing it as a test. It ships with an external library DLL file that breaks any other mod's attempt to do the Reflection call GetTypes(), making it throw an error. It's causing kOS to abort partway through its initialization.

The Making History system is essentially a finite state machine (FSM) with no memory other than "I am at this node right now". It would be exceptionally hard to make a script out of that. There's a reason people use FSM generator tools when they use FSMs in the real world, like when making language parsers, rather than writing the FSM directly from scratch. Being graphical doesn't always make things easier. Any proper scripting system will need some kind of memory to say "if X then STORE this value in A", and later on, "If that value we stored beforehand in A was this, then do that." The Making history expansion was a pure FSM which means it lacks that, and this is the main reason it was painful to use to try to make any sort of real mission out of it. The only "memory" an FSM can have about an if/else fork you are doing now is in the form of cutting and pasting a duplicate of the entire tree of events that comes after that fork so you have two variants of the rest of the "program" from there on down that are almost identical except for that one node in the future you want to behave differently based on this if/else you are doing now. I gave up on making missions with Making History once it became clear that there was no capacity to remember a variable and read it later. The massive duplication required to get anything meaningful out of a manually built FSM was too painful at that point, and I think a scripting system based on the same FSM engine would have the same problem. GUI programming *is* a thing, and people have done it, but you have to also have memory and variables. The pure FSM of Making History doesn't cut it.

Thanks for finishing up the release while I was out, @hvacengi. I've also updated the first post with the new version number.

That's No Mun A simple mod that replaces the Mun with a fully capable battle station, with a trench around its equator and an easter egg exhaust port you don't want to have any explosions on.

I usually have the difficulty option that disallows reverts turned on, but with the full knowledge that I can go into the saves/backup directory and find a few autosaves from over the last hour or so. Using those I know I could exit back to the main menu, manually copy down one of those backups on top of the persistent.sfs file, and then go back into the game. That is a way to manually "revert" if I absolutely need to. I leave it like that to discourage me from reverting on a whim. I leave it so that reverts take a bit of manual dinking about in order to force me to take the time to think it over and decide if it really seems fair. My two cases where I feel justified in a revert are: 1 - When I decided *ahead of time* that this was going to be a simulation, so I committed myself to the notion that I wouldn't be allowed to save this result even if it worked. I like the KRASH mod for this because it forces me to declare *before I know if it's going to work* that this one doesn't count. I don't like having the freedom to wait and see if it worked and when it does deciding "okay that wasn't really a simulation this time, let's keep that one". Because that's not how simulations work. When simulating a thing in the real world people do eventually have to decide to do it for reals, and when they do that then they can't retroactively declare it was just a simulation after it crashes. And they can't do the opposite either - when something was a simulation and it worked, they can't go, "Well, since that worked lets make a rift in time and space and move the vessel from the alternate universe of the simulator out here into the real world and that way we've already done it". 2 - When I make the judgement that it's definitely caused by a bug I couldn't possibly have been expected to do anything about or react to. For example, I was playing GAP (giving aircraft a purpose mod) which has contracts with big penalties that fail the mission and cost enormous money any time a part of the vessel breaks. I built a plane and spawned it on the runway. The game spawned the plane *already* clipped through the ground on scene-load, causing it register that as a collision and get flung 10 meters up in the air as soon as physics started. When it came down and broke parts off, I considered that a bug, not my fault, and did a manual revert. (I subsequently learned that those landing gear I was using from a mod have this bug frequently, and stopped using them). Other examples of the kind of buggy thing I feel justified in using a revert for are bad scene switches where your vessel loads under the surface of the Mun and starts falling in (haven't seen that one in a while thankfully), or when a terrain polygon "collider" was missing so as my rover drove over it, so it started diving under the terrain, clipping through the surface so only the top was showing when it rammed into the edge of the next terrain polygon and exploded.

Is there a recommended contract pack to go with this? I started playing through a career of it and while it looks like the tech tree rearrangement is perfect for doing what the mod wants to do, the stock contracts still don't really support doing lots of near-Kerbin stuff first (like for example space stations. The standard space station contracts don't start appearing till later, but this mod is supposed to let you start on space stations before you start really going far away.) I was wondering if there's a good recommended contract mod to pair with this. (And if so, maybe making it appear in the CKAN recommended mods for it would be good).