General tutorial for removing WIN64 KSP Denial of access code from mods.

[mcirish3]

Hi KSP WIN64 users. This is a general tutorial on how to remove the WIN64 block for your favorite mod. As mod makers may have various methods to prevent KSP WIN64 from running their mod I will try and make this a general as possible without leaving out any pertinent details. However, just as with many of life’s tasks there is always more than one way to do things. SO the method I show you here may not be the best, the fastest or most efficient. Also mod makers may use various methods to block KSP WIN 64 from running. I will here cover the most common method, and cannot immediately solve other variations, and I WILL NOT be giving particular information on how to unlock any particular mod unless I receive EXPRESS WRITTEN consent from that mod maker. IF any consent is given that consent will be posted in this thread either by the mod maker or myself prior to the submission of particular directions.

What this thread is NOT:

It is not a place to find someone to do the work for you.

It is not a place to bash the mod makers or to complain about the WIN64 block.

It is not a place to in anyway denigrate members of the KSP community.

It is not a place to denigrate Squad, moderators, any other representative of Squad.

It is not a place to debate whether users should be able to circumvent the WIN64 block.

It is not a place to debate whether Squad should have released KSP WIN64.

IT IS NOT A PLACE TO POST PARTICULAR DIRECTIONS FOR A MOD WITHOUT EXPRESS WRITTEN CONSENT OF THE MOD MAKER.

What this thread IS:

A place to learn how to remove, FOR YOUR OWN PERSONAL USE, the most common block used to prevent KSP WIN64 from running a mod.

A place to seek general help in modifying and compiling source code.

A place to increase your knowledge and better yourself.

What I am NOT:

I am not a programmer.

I am not a coder.

I am not your mother.

I am not your enabler.

What I am:

I am trying to help you DO IT YOURSELF.

I am willing to help if I can.

I am a newb at this too.

How NOT to get help from me, or any programmers, mod creators, or good Samaritans:

Be rude.

Be Vague.

Be lazy.

How to get help from me, or any programmers, mod creators, or good Samaritans:

READ everything.

Be polite.

Be detailed.

Demonstrate you have already tried to follow directions.

Notice: Mod makers are not at this time taking any support questions in regards to WIN64 KSP. SO either post your questions here in this thread or on Senshi's thread found here:

http://forum.kerbalspaceprogram.com/threads/98707-0-25-Win64-Enabled-NEAR-1-3-10-FAR-0-14-3-2-Real-Fuels-8-1-MFT-5-2-3

OK now that we have some ground rules let us begin.

First off what do we need?

1. Patience and lots of it. Coding is challenging even for the experienced programmers that is why they get the big bucks. One small mistake and nothing works. My experience is the smaller the mistake the harder it is to find. So go slow and check and double check.

2. You are going to need Visual Studio Express 2013 for web. This is a rather large program (4GB) sorry about that. This is a free program from Microsoft. Follow the direction on web site to download and install. Skip the Azure installation! I am sure Visual Studio Express 2013 for Windows and Visual Studio Express 2013 for Windows Desktop would do the job as well I just happened to grab the first one I saw and it did the job for me so if you want the screenshot to match up use that one. You can grab the program here.

3. You will need a Hotmail account to sign in to Visual Studio 2013 for Web. Sorry, no way around it. The website will walk you through all of the setup.

4. You will need to download the source code for mode you want to remove the Win64 block from. Unzip the code into a folder. If you want to modify more than one mode perhaps a set up like the pic below will work for you. I am using widows7 x64 so if you have different windows things may not look the same. You can find a link to the source code on the thread of whichever mod you are trying to modify. Here is a link to a program for unzipping the files if you don’t already have one.

Once you have gone through the initial setup your program should look like this:

Next click FILE and select open project.

Use the navigation pain to navigate to the location of where you unzipped the source code to. It should look something like this.

You are looking for a (your_mod_name).sln or if there is no (your_mod_name).sln look for a (your_mod_name).csproj file like the one in the picture above. These can be located in a sub folder so you may have to look around a bit. Click on the file and then click open.

Note: as best as I can tell .sln files can govern multiple .csproj files and usually give preference to the .sln file unless your experience informs you otherwise.

At this point your screen should look something like this. ( it may not however, click the "debug" menu at the top of the screen to and select modname properties, and then select "Application" from the list on the right.) (Note: Needs a pic)

On the right is a list of all the different modules that go into making up the mod. Each mod is going to look different. But the names should at least give you a clue as to what they do. In the pic above I circled the Target framework drop down menu. You will need to change this from .NET Framework 4.5 to .NET Framework 3.5. This is the structure KSP is built on. You will get a pop up like this:

Click yes.

Next we need to add couple references. To add them right click on the C# (Your_Mod’s_Name) at the top of the module list on the right. Select add. This will bring up a sub menu. Select references.

This will bring up the following screen.

Select the Browse button on the bottom and navigate to your KSP install folder. If you use steam this will probably be under C:\ program files. Otherwise it will be wherever you chose to install it to. Once there you will need to navigate to the following sub folder. C:\(KSP install folder)\KSP_win64\KSP_x64_Data\Managed

WARNING FROM THIS POINT ON THINGS CAN VARY A LOT. I am sorry nothing can be done about this. It is just the way things are. Every mod maker does things his own way and there is really no way I can standardize that for you.

The two most common files needed for reference are Assembly-CSharp.dll and UnityEngine.dll. But as you see in the pic below they are not the only ones that could be used but they should for the most part be in this folder: (C:\(your_KSP_install_folder)\ KSP_win64\KSP_x64_Data\Managed, Senshi/Mcirish3 will explain some other possibilities at the end of this tutorial.

You will have to click the Browse button for each .dll reference you need to add or you can select multiple .dll files by holding the CTRL+ left click of each file you want to reference. And will look like this:

After clicking add, make sure the check box for each .dll that you want to reference is checked like this:

Click OK.

Great! Now you are all set up and ready to find the code you want to modify.

So the first thing we need to do is know what we are looking for and how to look for it. What you will first need to do is click on a module on the right hand window box. They look like this:

The code we need to modify could be in any one of them or all of them or just some of them but the process is the same. We are looking for a reference to Win64 and most probably IsWin64() the easiest way to find these is to press CTRL+F this will bring up a search box that looks like the pick below in the top right for the main text box:

Type in win64 like I did in the example and hit ENTER. This will highlight every place Win64 occurs in that module’s code.

Now the code segment we are looking for is as follows:

public static bool IsWin64()
        {
            return (IntPtr.Size == 8) && (Environment.OSVersion.Platform == PlatformID.Win32NT);
        }

Well need to change this. The easiest way to do this is to delete

(IntPtr.Size == 8) && (Environment.OSVersion.Platform == PlatformID.Win32NT)

and replace it with the word

false

Your final code segment should look like this:

public static bool IsWin64()
        {
            return false;
        }

Now this may not be the only method used to block the mod from running on Win64 but as of now it is the only one I know. (I told you I am a newb at this). You will need to check through everyone of the .cs modules for this string to make sure you got them all.

Congratulations you are nearly finished!

Now to build your KSP WIN64 enabled mod.

That is easy just press CTRL+SHIFT+B. If everything went as planned you will have an output that looks somewhat like this on the output tab.

1>------ Build started: Project: (your_mod’s_name), Configuration: Debug Any CPU ------

1> NEAR -> C:\KSP project\Mod 1\(your_mod’s_name)\bin\Debug\(your_mod’s_name).dll

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

If not you may have a list of errors, sometimes they may help you solve what went wrong yourself and sometimes you may need to post on this thread for help. (NEVER POST ON THE MODS THREAD ABOUT THIS). That is what THIS thread is for.

Sometime the moder will have the full Gamedata folder as an output and sometimes only the (your_mod’s_name).dll will be made. If only the (your_mod’s_name).dll is made you will have to install the unmodified mod from the KSP form link and then over right the (your_mod’s_name).dll. In either case the location of your newly complied mod is listed in the last line of the output tab. like in the example above, the new (your_mod’s_name).dll would be found at:

C:\KSP project\Mod 1\(your_mod’s_name)\bin\Debug\(your_mod’s_name).dll

Final thoughts Senshi?

In some cases you might be unable to find a specific referenced assembly. This can be the case if multiple solutions are used in a project, and one of them builds the assembly the other one requires.

Can you give an example Senshi?

IIRC before you can build MFT, you need to build another dll. However, that particular github project is already set up in a manner that VS knows about this dependency, so it will run the solutions in the right order, despite the reference warning symbol being shown before the first build.

Some mods also require some actual external libraries, such as the KSPAPIExtensions, which can be found here on the forum.

Final thoughts Senshi?

You will also have to check or change the pre- and post-build events sometimes (right-click on the solution in VS, properties). These sometimes are responsible for either preparing files (Pre-build) or move files around after build is complete (post-build), making the finished .dll easier to grab. Some solutions result in a fully equipped gamedata folder for you to use, others only spawn the .dll in the default output folder. The VS output tab will tell you about issues it runs into, however.

Thanks Senshi for the comments, and good luck to all you new budding programmers .

Edited November 15, 2014 by mcirish3
More info

[technion]

Frankly I'm surprised the "For Web" edition of VS is capable of this, it's certainly not a web site it's compiling.

Just remember mods are different. There's no reason I couldn't call a Winx64 check "bool rocketIsLanded()", or check IntPtr.size != 4. I'd guess a lot of people never test under Linux and hence don't include that test either.

[mcirish3]

There's no reason I couldn't call a Winx64 check "bool rocketIsLanded()", or check IntPtr.size != 4. I'd guess a lot of people never test under Linux and hence don't include that test either.

You are absolutely right, and at that point unless you can trace the codes logic back to see what it is doing you are SOL. It is not like there is much you can do if a mod maker really wants to keep their mod from running on Winx64 KSP. Luckily most mod makers just wanted to raise the entry bar. I personally think educating the community would be more effective at this point thus the Tutorial.

[Kamuchi]

Repost of my post in the 64 enabled bits

It`s now been 4 stable days, 1 ksp craft exploding on the runway crash wich tends to happen in any version and 1 mono crash while I was messing around with mods.

I have no idea where to post it, so maybe here with other 64bit fans it might show some insight

After digging abit into the Unity complaints, I looked at the command lines and have actually found something that turned my pretty much retarted unstable 0.25 64bit to something I`ve spent playing for the past couple of hours without a single crash (hope I didn`t jynxed it now)

Fullscreen disabled

The well known "-popupwindow", but here is what changed everything for me:

I added a profile for ksp in CCC using the standard settings for global but disabled crossfire and added "-force-d3d11-no-singlethreaded" to the shortcut after the popup.

I know, milage may vary and the chance of it either blowing up in your face directly, or soon after, is pretty high...

I`ve actually added a few mods to my install and I`ve been playing all day with 1 crash, wich would have crashed the 32 aswell by nose diving a 250 part ship into the runway, wich also explodes to add injury to a dying client

Anyone one else want to try to see if this actually improves stability? I`m stumped I went from instant crashes to super smooth no crash game play.

Adding more heavy mods like Kerbin Side, FusTek parts, higher res textures&skybox.

Dozen launchers &ship changes later, I have my ksp back!

[mcirish3]

Thank you for sharing I do have a question or two though.

I added a profile for ksp in CCC using the standard settings for global but disabled crossfire and added "-force-d3d11-no-singlethreaded" to the shortcut after the popup.

I know, milage may vary and the chance of it either blowing up in your face directly, or soon after, is pretty high...

Since not all of us are running a crossfire capable system (some use SLI and others have neither) I am guessing disabling multi GPU's if they are present is a good idea? As for

-force-d3d11-no-singlethreaded

as I am not a programer for a living could you explain exactly what this means? I think d3d111 is a graphics packet load type (?) and is this command line telling KSP to only use single thread processing or to never use it?

Any light you could shed on this would be useful.

[R0d1n]

Hmm, tried to do this for RealChute. Eventually found the right segment (labeled as "SixtyFourBitsMustDie"). When I tried to build, though, I get the following warning:

Warning 4 The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'e:\Games\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\Mono.Cecil.dll'

I then get this error repeated a bunch:

Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'

[R0d1n]

Actually, I think I fixed that problem, but now there's a weirder one. There are a couple of lines that use "Path.Combine();". As far as I can tell there's nothing wrong with that syntax, except that I get a bunch of errors saying "'Path' does not contain a definition for 'Combine'".

[Kamuchi]

Thank you for sharing I do have a question or two though.

I have no idea to be honest on both questions

You would think -force-d3d11-no-singlethreaded would be a stupid thing to do when disabling CF.

The only thing that I can even remotely come up with is that something in the Unity code is going wonkey unless forced with that flag so it doesn`t gets confused.

Wouldn`t have a clue if my game is running dx9 or 11 at the moment due to that flag, but for god knows what reason I can play for hours on end?

[mcirish3]

I have no idea to be honest on both questions

You would think -force-d3d11-no-singlethreaded would be a stupid thing to do when disabling CF.

The only thing that I can even remotely come up with is that something in the Unity code is going wonkey unless forced with that flag so it doesn`t gets confused.

Wouldn`t have a clue if my game is running dx9 or 11 at the moment due to that flag, but for god knows what reason I can play for hours on end?

SO next question would be have you tested doing one without doing the other. In other words what happens if you only disable the crossfire? What happens if you only force the switching? Also since you are actually turning on two flags here what happens if you only turn on only one? It looks like 5 possible combinations.

[longbyte1]

You make it sound as if circumventing Win64 restrictions is illegal and should be taken very seriously. (It's not, by the way, since most mods are freely licensed.)

Still, though, a decent tutorial.

[Boomerang]

You make it sound as if circumventing Win64 restrictions is illegal and should be taken very seriously. (It's not, by the way, since most mods are freely licensed.)

Still, though, a decent tutorial.

Well, it would be illegal if someone were to attempt to redistribute a mod after unlocking it for x64, against the license. Hence the 'personal use' emphasis.

And just about all of the other warnings are because most of the tangential discussions on this topic have been leading to a lot of tense, if not hard feelings between various groups around here.

I love that someone's put up this sort of tutorial and immediately laid down the law with regards as to the exact purpose of the thread.

[mcirish3]

Actually, I think I fixed that problem, but now there's a weirder one. There are a couple of lines that use "Path.Combine();". As far as I can tell there's nothing wrong with that syntax, except that I get a bunch of errors saying "'Path' does not contain a definition for 'Combine'".

Sorry R0d1n I missed your post the first time through. This is what Senshi was talking about when he said "IIRC before you can build MFT, you need to build another dll. However, that particular github project is already set up in a manner that VS knows about this dependency, so it will run the solutions in the right order, despite the reference warning symbol being shown before the first build."

I am guessing that you need to complete a project called combine first before it will compile the rest. This should have been included with the source code. I will try and find time to look into it.

[mcirish3]

Sorry R0d1n I missed your post the first time through. This is what Senshi was talking about when he said "IIRC before you can build MFT, you need to build another dll. However, that particular github project is already set up in a manner that VS knows about this dependency, so it will run the solutions in the right order, despite the reference warning symbol being shown before the first build."

I am guessing that you need to complete a project called combine first before it will compile the rest. This should have been included with the source code. I will try and find time to look into it.

I was wrong, the error is in my directions. I have been directing people to compile the *.csproj file this is wrong and I will change my tutorial to reflect this. I ran through and complied "Real Chutes" and received no errors once I put in the correct references using the .sln file in the main folder. (note: RealChutes uses more than one win64 KSP block)

Edit:It would seem that though there are multiple checks for win64 there is a single master switch that can be turned off for RC.

Edited November 15, 2014 by mcirish3

[Kamuchi]

Well, did some testing...

Everything became unstable, still playable, but unstable with alot of general crashes that were not happening befor.

At one point I couldn`t even select a ship in the tracking station that almost made me crap my pants that nearly a month of game time went down the drain because ships didn`t want to load, tons of errors along with random mod failures ontop of unity that I had to start pruning the list and readd after a restart.

On that note I did discover 1 thing and might have a hunch on the -force-d3d11-no-singlethreaded:

The one thing that I did figure out is the right click.

Q: Why is it always fine at the start but after 3-4-5 crashes and restarts it`s really starting to be an absolute pain in the arse?

A: It`s actually windows, no, it`s behaving ok, but from my experiment, when you start having click issues, reboot the pc and all is fine again.

- Wich brings me back to windows, again, my logic says that when unity crashes the memory isn`t cleaned, so when you keep restarting ksp, the underlying issue stacks up to the point it`s becoming nearly impossible to right click when in the world (ship) view.

Solution: reboot the pc and go back enjoying with a working right click

On to my f`ing headache during my 2 dozen crashes while testing and trying to fix all the ******* bs fake crash errors:

Why oh why does -force-d3d11-no-singlethreaded has such a great success for me with disabled crossfire profile for ksp?

My only conclusion of it can be that under the 64 hood there is simply a giant problem, like we didn`t knew that...

-force-d3d11-no-singlethreaded might just be telling this, crappy, unity build "idiot! multiple cards!" and forces it to behave as it should`ish behave wich in a crappy engine prevents some random crashes and as the game doesn`t do crossfire anyway and CCC tells it to bugger off aswell.

I didn`t see any performance difference with or without crossfire enabled, but it did start crashing more and became a horrible debug nightmare after returning to my current settings.

My conclusion in short: -force-d3d11-no-singlethreaded tells the engine to work as it should, wich it doesn`t, otherwise I have no clue unless some one is a unity programmer

I did get quite some stuff done, less then I wanted but having figured out the god annoying richt click issue made it all worth it, 55 pictures ( https://imgur.com/a/2BRJH ) and having shot Das into space in my game

[mcirish3]

Hi Kamuchi,

Well quit the story. Thanks for sharing and taking the time to try and test what works and what does not work. Yes, you are absolutely right about windows, we have this problem all the time at work. I am a analyst and we work with large Excel files with hundreds of thousand of data points in each file and we often have more than one open. After a few days of not restarting, lockups happen more often and things run more slowly. SO in short yes windows can exacerbating the issues with Unity.

So, you are fairly sure that at least for some people "-force-d3d11-no-singlethreaded" can help, Great! I think I may need to add a suggested solutions post to this tutorial thread.

Also you have been busy, those pics are super cool, you should give them a thread in the Fan works section, if you haven't already.

Edited November 16, 2014 by mcirish3

[Kamuchi]

I have a thread there in the mission reports and thanks

It might help some people, but the entire 64bit is a prayer for each player, it does add alot of stability for me atleast.

Just rememberd what extra I wanted to add to the -force-d3d11-no-singlethreaded part, maybe, just tiny maybe, there might be a bug in the gpu memory handling with the 64bit, same as abouve though, it forced unity to behave more as expected`ish.

I run with 4 290X gpu`s, for single cards other issues might be to blame.

Would be funny to take all people`s setup and see if multi card users have more problems then signle card users, I have a funny feeling that would be a "yes"

Maybe it wasn`t clear due to my wording, the issue isn`t not rebooting or pc last reboot time.

After 2-3-4 ksp crashes and immidiate restart, you will start to have serious click issues because most likely ksp bits remain in memory.

The more crashes, the worse it gets.

First startup: right click is fine.

First crash & second restart: right click problems could start to happend, but not always.

Second crash & third restart: changes are you are going to start having right click failures.

Third crash & fourth restart: if you don`t have right click problems, you might be beating the odds.

Fourth crash & fifth restart: I started having more right click failures then working ones, but for a test I kept going.

Fifth crash & sixth restart: getting a click in was getting seriously frustrating, changing back and forth between space, space center and iva kerbals and back, a crash soon followed.

Sixth crash & seventh restart: clicky fail madness that it was unplayable.

First reboot & first startup: all perfectly fine.

Hence and repeat.

I must say that closing the game normally didn`t produce the problem (for me), only with game crashes and starting up without a pc reboot.

I shutdown my pc every day and reboot if needed/wanted, but these unity crashes leave trash around that to solve the right click issue, you have to reboot the pc.

If it`s happening with several crashes in an hour or a day, after a couple of crashes you must restart the pc or the problems stack up.

Past 2 days I have crashed so many times that I was tempted to trash mods to speed up load times lol

Edited November 16, 2014 by Kamuchi

[Xaiier]

I'm a fan of this thread, and I bet a lot of the modders (some of which have blocked x64) would agree.

It's been shown that any attempts to generalize removing x64 checks end badly, as they negate the purpose of those checks and only add complications. This method is the right way to go, it raises the bar past the level of the people who most often cause problems, puts the responsibility on the user, and even offers an opportunity to learn more about modding/programming in general.

[waterlubber]

Hopefully when .90 comes out, they'll update Unity (The birthplace of the Interstellar Ultimate God 64-Bit Kraken), and enable stable 64-bit on all platforms.

As for now, if fixing 64 doesn't help, then Linux might be the way to go.

If you'd like to try it out, try burning a "Live CD". Who knows, you might like it!

Also, I noticed with Linux 64-bit: After the memory cap is lifted, KSP eats up RAM like crazy. If I don't watch it, it'll cap out and the swap space (Linux page file) is too slow, I have to restart the computer. Real pain it is.

However, often a single mod is the cause of the problem. I understand modders are annoyed at the hordes of 64-bit users who blame bugs on them, but there must be a compromise!