Padishar

(Emphasis mine) Please don't post totally inaccurate conclusions about mods, especially when the correct information is already freely available in the particular mod's own forum thread. You should NOT be using Kopernicus 1.1.1. Version 1.1.2 is the latest version and works correctly. Download a fresh copy of version 1.1.2 from here and install it. Specifically, this problem is caused by having an old version of ModularFlightIntegrator. Various mods (not to mention CKAN) include an older version of this mod (either 1.1.4 or even 1.1.3 for KSP 1.1.2) and, if their install instructions are followed, you can overwrite the working version supplied with Kopernicus with a broken version. Your downgrade to Kopernicus 1.1.1 will have restored the correct version of ModularFlightIntegrator which will have fixed (some aspects of) the solar panels but will have introduced a number of other issues.

Solar panels not working will probably be you need Kopernicus 1.1.2 and/or ModularFlightIntegrator 1.1.5.

Alternatively, build the plane so the wings have positive AoA on the runway and you may not need to rotate at all to take off...

Just look in the bottom right corner of the main menu screen. The version number should have (x64) after it.

Oh dear, another CKAN install problem just when they're in the news. Kopernicus has never used version 1.1.3 of MFI, it started using version 1.1.4 and updated to 1.1.5 shortly after. There was also a bug in Kopernicus with solar panels but this has been fixed in the latest version (1.1.2). Until it's sorted out I would recommend you don't try to use CKAN to install Kopernicus. Instead, follow the very simple instructions in the OP of this thread and install version 1.1.2 manually. This includes the correct version of MFI and has a number of other fixes besides the solar panels.

The 1.1.2 on that page is the version of Kopernicus.

Have you updated to Kopernicus 1.1.2? The linux version quite possibly suffers from the same issues as the 32bit windows version.

You need to make them public. In GDrive, right click on the file and select "Get shareable link" and post those instead.

The log is in either the KSP_Data folder in your KSP install for 32bit, or the KSP_x64_Data folder for 64bit. Upload the file to a file hosting service (e.g. Dropbox, GDrive etc.) and then paste the link into a post here. You may need to tell the file hosting service that you want the file to be public before it will give you a link... The other logs that Thomas P. mentioned are in the Logs folder in your KSP install. Probably best to right click on the Kopernicus folder and select the "Send To/Compressed (zipped) folder" menu item. This should create a file called Kopernicus.zip which you then upload as above.

It looks reasonable. Your best bet will be to upload your output_log.txt file to a file hosting site and post a link. This should give us some clues as to what is wrong. Incidentally, are you running the 32bit version of the game or the 64bit one?

Were they stock wheels or modded ones? EVA kerbals are supposed to now be on a different layer so they shouldn't interact with wheel colliders at all. If this is a stock issue then it is probably worth reporting it in the support forum (or adding some information to an existing bug on the tracker). As for low FPS in the VAB, have you turned off the animated ground crew in the settings? This should significantly reduce the CPU usage in the VAB...

Unfortunately, the player.log file is rather messed up. Both the start and end have large chunks overwritten with information about Mono not being able to load various types. One thing I can see is that the Trajectories mod is spamming the log with exceptions all through the loading process: NullReferenceException: Object reference not set to an instance of an object at FlightGlobals.get_ActiveVessel () [0x00000] in <filename unknown>:0 at Trajectories.AutoPilot.Update () [0x00000] in <filename unknown>:0 Why an AutoPilot object is even being created that early on is a mystery. I presume they use [KSPAddon] with the "instantly" option to avoid the object being deleted and recreated on every scene switch for some reason, but this isn't a very nice thing to do, it should just be instantiated in the scenes that it's needed in (and has a hope of working in). If this is done to preserve data between scenes then this can be done in other ways (e.g. store the data in statics rather than instance variables, or various other ways).

Actually, the KSP.log was changed in a fairly recent version to include more detailed stack traces though there is other info in output_log.txt that is very helpful for diagnostic purposes. On the other hand, the KSP.log includes timestamps which can be very helpful when trying to diagnose some issues... In this case, I specifically asked for the output_log.txt so that should definitely be considered better...

Ok, it sounds like one of the other changes since 1.0.5 may have broken something. I'll take a look at your log when you post it and if I can't see anything then I'll set up a test install and try to reproduce...

What do you mean by this? Do you mean the problem happens with KSP 1.1.3 and the official Kopernicus 1.1 release but it doesn't happen if you build Kopernicus for 1.1.3 yourself based on the source for 1.0.5? What changes did you make? Have you tried the DLLs I linked in the post before yours? As with all issues, your best bet is to upload your output_log.txt/player.log file somewhere and link it here.

The archive is empty (only 59 bytes).

But unfortunately there is a bug that causes all solar panels to give 0 EC. This has been fixed but not yet officially released (though there is a test build of the DLLs available in the thread).

I believe it was superseded in 1.1.0 by KSP.UI.Screens.StageManager but the old Staging class wasn't removed until 1.1.3.

@Clyde Jones, I meant the bit that talks about uploading the output_log.txt file from the KSP_Data folder. The game (and mods) log all sorts of useful things into this file which should show what is going on...

Please post a log file as described in this thread: ...and we may have some hope of helping you...

It looks like the suggestion I made to account for the change to solar panels in KSP 1.1.3 was incorrect. Rather than changing sunTransform to sunDotTransform, it should have been changed to sunTransformLocal (or possibly sunTransformScaled, though I think it should probably be the Local one). I'll submit a PR shortly... Edit: I have now submitted a PR to fix this issue. I have tested it briefly in OPM around one of Sarnus' moons but would appreciate others testing it too. If you feel up to it then please try replacing the DLLs in your GameData/Kopernicus/Plugins folder with the ones from this zip.

Basically it consists of two parts. First, when a planet goes out of view the textures are no longer discarded immediately. Instead, a note is made of the time and if, after "onDemandUnloadDelay" seconds have passed, the planet hasn't come back into view then they are discarded. Second, the code that actually loads the DDS or PNG textures from disk used to allocate either 1 (for PNG) or 2 (for DDS) byte arrays to hold the data before it is passed to the Unity Texture2D class. These large array allocations have been totally eliminated resulting in much less garbage being generated and the loading being a bit faster. The two fixes combined both reduce the number of times that textures get loaded and almost eliminate the garbage generated by doing so.

Duh! Sorry, totally missed that. I just thought it might reduce the likelihood of people spamming the thread with update requests...

Are you waiting for CKAN before changing the version in the thread title?

Is that "slightly", as in "water is slightly wet"?