Dunbaratu

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.

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).

Oh good so it's not just me. I got the same problem trying to view my bookmark to my most common search page.

I have a problem that deals with the Remote Tech API as it is called from kOS. Is this the right thread for it? Do any of the maintainers of RT know of anything that might have caused this call to the RT API from kOS to now give a different answer than it used to? var hasFlightComputer = Instance.HasFlightComputer(vesselId); The specific difference is in what happens when the vessel being tested for is unloaded. Now in order for HasFlightComputer to be able to return True, the vessel must be within load distance of the active vessel. Any vessel more than about 2.5km away is always returning false for this API call. I don't think it used to work that way back in 2016 when our code dealing with this in kOS was last touched. The kOS github issue is this: https://github.com/KSP-KOS/KOS/issues/2457 If I'm wrong, and that API call always worked this way, then I guess I have to look elsewhere for the cause of this bug on our system.

Arrrg dangit. In order to fix the rotating map problem, I had to lock out a few more input locks in the terminal in the recent updates to kOS. (I am 100% convinced the rotating map problem is because someone at SQUAD used the input locks as an indirect side-effect test that presumed we are not in map view if the locks are set a certain way, and therefore the camera should rotate to match the ship when the target lock is set.) It makes zero sense that the ability to change target by clicking is the test for being on map view, except it seemed to be doing exactly that. To stop the map view rotation bug, I had to change how the terminal deals with the input locks. This may be a side-effect of that because it's possible I ended up locking out the ability to alter time warp too. Can you write up a good careful description of what triggers the problem (basically what you wrote here in the forum) over on github? I am away at the moment reading this on my phone so I can't easily do it myself. Auto-landing of stages is a very complex operation - one that I don't think Mechjeb does for you. kOS *can* do it, but only if you write a program (or have one someone else wrote) for it. It's not a problem with a simple "out of the box" shrink-wrap solution. (Any such solution will *also* involve having to install the FMRS mod as well, which is needed to avoid the problem that Kerbal Space Program doesn't work if you try to extend the physics bubble" too large to be able to have the 1st stage and 2nd stage both actively thrusting at the same time while 60km apart from each other.) I assume Gudlifer is a native Russian speaker, from the cryllic text in the post. I know there are a few people fluent in both English and Russian in this forum thread. Can someone do me the favor of making a good translation of what I typed above for Gudlifer?

Yeah I see what happened. It now seems that the purpose of that later post must have been you saying, "Let me follow-up that original post by going back and describing more things about what happened just before that first post." But it only seems that way now in hindsight. I took the phrasing about "Followup to the problem" to mean the events being described in your post were a series of events that occurred after the original problem, as part of your follow-up to the problem. That might seem like a minor difference, but getting the order of events swapped around makes all the difference in the world. i.e. instead of "Blizzy was installed when I first reported the problem, in which only Blizzy's icon was broken and the stock icon was working but fuzzy", it sounded more like "Blizzy was installed after I reported the problem, as part of my follow-up to the problem. I discovered that Blizzy's icon was broken too, but the weird thing is that after installing it the stock icon got fixed."

Was it at hard difficulty settings? The building costs are cheaper on the easier difficulties, and the contract payouts are much more lucrative. In the stock game, the intent of scaling it up to hard is NOT to completely cut off, in a strictly Boolean way, access to certain contract types. The intent of "hard" in the stock game is to just make the contracts harder to accomplish because of these limitations, not refuse to even offer them in the first place. This is why I think it doesn't feel right for GAP to require a building upgrade before allowing a certain contract type to even exist at all - especially one that's so low on the tree of prerequisite contracts that it cuts off access to like half the mod.

After reading this, I checked for that problem and yes, there is a mistake similar to the one you describe that I see in the code, but the mistake I see doesn't match your description quite exactly, so I'd like to ask for a clarification to see if it's really the same thing. Question: When you quoted the filename in question as being "launcher-button.png" did you *actually* mean "launcher-button-blizzy.png"? Because if so, then what I see in the code would match your description perfectly. But if you did literally mean the relevant file was "launcher-button.png" (no "-blizzy" in the filename) as you wrote, then what I see wouldn't quite be the same as the problem you describe so I'd still have to look further to find the problem. (What I see in the code would imply that the normal stock toolbar button should work just fine, and the bug I see should only affect the Blizzy modded toolbar, not the stock toolbar.) @infinite_monkey - in your first description of the purple icon, when you said the icon was purple in "the toolbar" did you mean the mod "blizzy's toolbar" rather than just "the toolbar"? If that's what you meant then it all becomes clear. I thought you were reporting it being purple in the normal toolbar - the stock one, and I couldn't reproduce the problem at all. If the stock toolbar was working just fine all along, and only blizzy's toolbar wasn't, then that would fit what I'm seeing. (They are two different image files - the blizzy icon is a smaller version of the image, in a separate filename, and it was that filename that has the problem.)

The problem with any such list as this is that the reality is that these tasks are not pre-requisites in that order. Someone does not need to be able to return from Eve before they're skillfull enough to rendezvous and dock. (iIn fact, being able to rendezvous and dock is almost a necessity before a return from Eve is even something to consider, as the dV requirements of a direct one-stage land and return are enormous compared to doing an orbit rendezvous with detachable lander). How do you rank someone who can do all the things in level 4 but not all the things in level 3? That's a very real possibility. The notion that the skills come in this exact order isn't really true. A better ranking would be each task is worth a score. All the tasks you can do get added together. If the score is above X you are in level Y, etc. That way a person who can't do an "easier" task but can do a "harder" task isn't getting zero credit for that harder task like this ranking does.

I *did* try to use prop engines before jets. The firespitter prop engines are in the same tech tree node as the starting jet engine, which is why I mentioned firespitter by name in my earlier post. When you install GAP on CKAN, GAP recommends also installing FireSpitter, which I did. You say that getting around the stock tech tree not giving any airplane parts till later is outside of GAP's scope, except that then if that's true why do the GAP prototype contracts exist at all? I thought they were there specifically to get around the stock tech tree putting aircraft things too late in the tech tree. I was just saying that to be effective at doing that, at least *some* engine has to be gettable that way, and right now they're not. If it let you get into the firespitter prop engines only, and not the Juno jet, that would be perfectly fine, and make sense. But both props AND jets end up having to wait because the prototype contracts don't unlock any prop engines either, and props are in the same tech tree node as jets. As for the helipad landing, if it does turn out to be the case that upgrading the SPH would have worked all along, then I think the text description of the pre-requisite bullet point might need editing. It would probably need to say "VAB or SPH' where it currently just says "VAB". But even that doesn't really change the fact that that upgrade is *expensive*, even if it's the SPH upgrade, and a player is still left wondering how on earth they're meant to earn that money first while still tootling around on Kerbin and not getting to space yet. The helipad landing contract should be doable without a building upgrade, IMO. It should be just "land on top of one of these buildings", without caring what upgrade level the building is at. Even without the upgrade that marks the top of the SPH or VAB with a big "H", the buildings' roofs are still flat enough to be landed on.