[0.25] Win64 Enabled: NEAR 1.3.10 | FAR 0.14.4 | Real Fuels 8.1 | MFT 5.2.3

[NathanKell]

Ruedii, KSP plugins are architecture independent. Errors you encounter in Win x64 are not due to mods, and the fact that we can do nothing about the problems, and that nonetheless people blame the mods is a very, very large contributing factor to why a number of us disabled our plugins on KSP Windows x64.

(For example, all the stuff you talk about applies to KSP and to Unity. Please make those suggestions to those devs.)

I mean, heck, I'd love to be proven wrong. Maybe we're using unsafe x86 code and we just somehow don't know it.

[Camacha]

Ruedii, KSP plugins are architecture independent.

I never even realized that - not in conjunction with the issue discussed. That means the plugins also do not work under Linux? No use making a specialized x64 installation then.

[NathanKell]

Of course they work in Linux. KSP Linux x64 is stable, and thus we see no reason to lock plugins on it.

[Camacha]

Of course they work in Linux. KSP Linux x64 is stable, and thus we see no reason to lock plugins on it.

Independent but not agnostic. Check. It kind of tempts me to make a shiny new high performance USB stick into a dedicated setup, though currently x86 with OpenGL seems to work just fine too.

[nukeboyt]

So please try not to be stupid, okay?

If I see that you can't follow this simple rule, I will withdraw my files.

I applaud your desire to serve the community and the fact that you reached out to the original authors of the mods. Stupidity won't be the problem. I've been in on-line communities since the days of 300 baud, handset-cradle modems and BBS's, and there has always been one constant: trolls! Vigilant moderators can minimize the impact, but never eliminate it. Invariably (and sadly) you will be forced to follow through on your removal assertion. (I hope I am wrong).

Edited November 2, 2014 by nukeboyt

[Guest]

No, he won't be forced to do anything. If nobody managed to grasp this simple rule, then maybe. But as long as most people stay in this thread, it'll be fine.

Also, any progress on RSS? It'd be great if that would be added, especially as it's maintained by NathanKell. I'm not optimistic about permission for RealChutes to get this treatment (disabling it's restriction might necessitate a different approach), but RSS should be OK.

Edited November 2, 2014 by Guest

[KasperVld]

Again a few off-topic posts have been removed. Discussion of whether or not people should share forks against the will of an add-on author is a seperate discussion and should be held [thread=98761]here[/thread] or in another location where it's on-topic. Further off-topic posting will be met with infractions.

[JeffersonFlight]

Senshi, If you would like some help with this I would gladly do so. I have already disabled the 64bit checks in RSS,DeadlyReentry,RealChutes,ProceduralParts, and a few others for personal use.

Edited November 2, 2014 by JeffersonFlight

[NathanKell]

Any disabled checks should only be winx64 checks IMO; you can just find/replace IsAllCompatible with IsCompatible in most cases.

[JeffersonFlight]

Any disabled checks should only be winx64 checks IMO; you can just find/replace IsAllCompatible with IsCompatible in most cases.

Yes let me clarify only 64bit checks were removed.... Tons of pointer checks every where

[Corodius]

(Reposting my On-Topic Part from my posts which were rightfully moved, and thank you to the mod who moved them, that was my mistake)

Thank you for releasing these! The no 64bit check kept me from trying out the windows 64bit version as I have not had the time to set up my KSP Build Environment yet, I am still learning the game and how the parts all work together. My first big Unity based game, especially on the modding side, so still learning a lot atm. However I completely understood the "why" behind these Author's Choices. Thank you for compiling these for those of us who at least understand not to bug the original Authors about bugs in something they themselves have been forced to disable. (I really wish people would think sometimes, would avoid these sorts of issues, but that is the way things are I guess.)

[G'th]

How would I go ab out doing this myself? Because I'd like to really reenable all of the disabled x64 mods (because really KSP is getting frustrating to play without them, and its awful to look at KSP's graphics now without x64) but thus far I haven't been able to really find much of a how-to on it. (Because really I don't even know what to search for and just searching for re-enable x64 mods just brings me here anyway)

[Senshi]

1. Get VS Express (free)
   
2. Open sourcecode project in VS
   
3. Fix references to all required assemblies (most/all are found in KSP_025_x64\KSP_x64_Data\Managed)
   
4. Change the CompatibilityChecker.cs (or similarly named) method "IsWin64()" (or similar). I do it by making the method always return false:
   

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

   
   

5. Build solution
   
6. Copy the newly build .dll into your GameData mod folder (replace the old one
   
7. Enjoy
   

Some mods - such as RealChute - have multiple Win64 checks spread throughout all functions. There you need to search for both the actual Win64 check methods (Pointer Size and PlatformID) and remove them before compiling.

[Moleculor]

No one's reporting any issues with FAR so far (or any other mod released in this manner). Does that mean no one's trying it, or have people tried it and had wonderful success?

[DuoDex]

No one's reporting any issues with FAR so far (or any other mod released in this manner). Does that mean no one's trying it, or have people tried it and had wonderful success?

We don't know. Go look in the FAR thread and see if there's any x64 support posts there

[Shad0wCatcher]

With regards to x64; having 0 issues using DX11 & OpenGL rendering. However when using the same DLLs in a 32 bit environment w/ OpenGL getting some weird NREs with FAR that spam the debug log and cause spaceplanes to fail horrifically and hilariously. Basically FAR loses its lunch with any aerodynamic surface I've used (stock, stock's implementation of Porkjet's SPP, and procedural wings along with a combination of structures from stock (mk 2 cockpit) to B9 (mk 2) to nliwork's retrofuture parts (all of which have proper FAR implementation) and the plane takes a nosedive / structurally fails since it instantaneously loses any lift from lifting surfaces. Obviously out of scope since the DLLs have been compiled against a x64 environment, however, those are my observations.

EDIT: @Duodex Was that trolling really necessary? Please if you have nothing constructive to say then don't.

Edited November 3, 2014 by Shad0wCatcher

[NathanKell]

The reason you will not encounter issues is because no mods are incompatible with KSP Windows x64. The problem with KSP Windows x64 is that it, itself, is broken for many people. If it is not broken for you, then mods will not break it. If it is, then nothing can be done.

[DuoDex]

EDIT: @Duodex Was that trolling really necessary? Please if you have nothing constructive to say then don't.

I resent that statement. I was merely pointing out that, as has been pointed out before, the people who are most likely to have issues are most likely to post in the wrong thread, and so to see if there are issues one should visit the FAR megathread.

[G'th]

1. Get VS Express (free)
   
2. Open sourcecode project in VS
   
3. Fix references to all required assemblies (most/all are found in KSP_025_x64\KSP_x64_Data\Managed)
   
4. Change the CompatibilityChecker.cs (or similarly named) method "IsWin64()" (or similar). I do it by making the method always return false:
   

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

   
   

5. Build solution
   
6. Copy the newly build .dll into your GameData mod folder (replace the old one
   
7. Enjoy
   

Some mods - such as RealChute - have multiple Win64 checks spread throughout all functions. There you need to search for both the actual Win64 check methods (Pointer Size and PlatformID) and remove them before compiling.

Yeah I'm still not really getting what I'm supposed to be doing here.

[steve_v]

Ya know, I was going to try to make it clearer - but I don't think I can.

Before posting on the other thread regarding how easy this is, and potentially being a right d*ck, I did it myself.

I have never coded anything in C#, I usually work in ladder or functional block on embedded devices - I hesitate to even call it code.

I have never used monodevelop before (on GNU/Linux, so no VS for me).

It went like this:

So, I need an IDE: Google reveals that there is a KSP wiki page on setting up VS / MonoDevelop.

I needed the code (duh): pull the GIT master, unpack it somewhere.

Load it up: Within IDE, find downloaded project. I keep hearing the term 'solution', so lets try that '.sln' file.

Oh, lookie, some files with a big red 'X' beside them under 'references' tree - recon I've seen those files somewhere - find & add my copies (see aforementioned KSP wiki).

Aha! a file called CompatibilityChecker.cs - wanna bet it's in there?

A line that sets 'IsWin64'? looks like a good place to start, lets see if I can break it

Since I obviously don't want it to return whatever it's currently returning, lets just make it return 'false' and comment out the check (there are obvious comments starting with '//', lets use that).

Hit 'build'.

Bingo! shiny new dll for me.

Regarding more cunning checks - now that we know what a check for Win64 looks like, it's pretty straight forward to search through the rest of the code for the same, rinse, repeat.

If I had seen Senshis post before attempting this, It might have shaved a whole 5 minutes off the process - It's an excellent guide & that's really all there is to it.

G'th, have you actually *tried* following the steps outlined? If so, what didn't work? I'm pretty sure someone can set it right.

[Senshi]

Sorry for being blunt: If you can't get it to work with my basic guide and unless for some reason Google, DuckDuckGo and every other search engine provider is banned by your ISP there's not much point in giving more explanation. If you have an open mind, you can get it all set up in an hour, maximum. You have to understand what you're doing, because there never can be a 100% standard approach that works for every single mod out there. And you'll only learn it if you set it up yourself. If you have proper questions, they will be answered. A simple "I not understand. Halp." does not entice people to help you.

If that doesn't work for you, that's okay, then you'll either just have to rely on my provided .dll files here or go back to Win32.

I would also like to emboss Nathan's statement above on a gold plate. It's what's been reiterated all the time by modders and devs themselves, and still not all people have gotten the message. Mods/plugins are platform-independent. All issues you have in Win64 are KSP issues, not mod issues.

[Voculus]

No one's reporting any issues with FAR so far (or any other mod released in this manner). Does that mean no one's trying it, or have people tried it and had wonderful success?

I've given it a whack multiple times, but for me, it doesn't work in x64. At Mach 0.6. regardless of the ship mass and wing configuration, the plane will nose up uncontrollably, the framerate drops, and the log overflows with FAR64 errors. Worth a shot, though. Going to have to slog through the 32-bit version until Unity 5 is released, or Nvidia releases a Surround driver for Linux.

[Immashift]

Thanks for your work Senshi. Helps not having to recompile myself.

I'll vote for realchutes being included, if license allows it.

Thankfully Win64 has presented utterly zero issues for me. That is until the whole checker thing started. Buuuut I get it

Gonna go ahead and play with NEAR now I think, accepting that if my KSP burns to the ground it is my fault and mine alone.

A line that sets 'IsWin64'? looks like a good place to start, lets see if I can break it

Made me lol.

Edited November 4, 2014 by Immashift

[Senshi]

@Voculus: You know the drill. Without an actual error description and log files we can't help you. I'm still fairly certain that this is not a Win64 issue. Either it's an end user issue or it might be caused by me building the modules using the latest github source, which is not necessarily the same as used for the stable releases. There's a chance bugs got introduced that way.

Simulations and the Inflight FAR data screen can help you greatly in spotting potential design flaws. And you can always revert to some of the stock planes with well-known flight properties.

It's odd however that me (and others as well, apparently) fly planes and rockets of all shapes and persuasions without any FAR issues.

RealChute license needs explicit clearance by Chris, which he has not (yet? ) granted. He'll monitor how this entire thing works out here, he said.

[Voculus]

@Voculus: You know the drill. Without an actual error description and log files we can't help you. I'm still fairly certain that this is not a Win64 issue. Either it's an end user issue or it might be caused by me building the modules using the latest github source, which is not necessarily the same as used for the stable releases. There's a chance bugs got introduced that way.

Sorry about the confusion. I wasn't actually putting forth a plea for help, but answering a previous poster's question. However, if there's a chance it can work for me, I'll submit a log shortly. As far as sound aircraft design, I will simply say (without trying to be arrogant) I got that covered.