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

[Immashift]

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.

Well that's at the very least not an outright "no". Long as we all handle this correctly I don't see a problem later on down the line.

Regarding the far issues I tend to think it might be other mods interacting in weird ways. I had an issue in .24 ish, where certain parts with multiple versions via tweakables handled very amusingly with far. Perhaps that's what you're experiencing.

[G'th]

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.

Talking like that makes me wonder why people got upset with you.

And not to mention that what you wrote clearly relies on the person reading it to already be familiar with everything involved. All you really said would have just helped someone who could have figured it out themselves save 5 minutes. Its not going to help someone who doesn't know how to even read what he's looking at, very much less how to use the program itself.

So no, your "basic" guide did not help, because past opening the program you decided to assume I would just automatically know what to do. And no, Google is not going to help, because I wouldn't even know what the hell to search for.

[Voculus]

Alright, here's a log and a debug screenshot, as well.

KSP Log All of the FAR64 errors are at the bottom.

As I said earlier, this happens at Mach 0.6, with any kind of plane, any kind of parts - stock or mod - and without fail. In the SPH, all of the FAR data is good to go, particularly at Mach 0.6, where I'm seeing the hiccup in actual flight. I tried the x64 DLLs with the official 0.14.3.2 release, as well as the latest dev version from Github. If I missed anything, let me know, and I'll try to provide it. Thanks!

[Immashift]

Talking like that makes me wonder why people got upset with you.

Snip

I think the thing here is that you're asking for help doing something that doesn't have a set structure (code for the same thing will vary between mods), and you're asking for help doing something that takes some teaching to really figure out.

People who code mods are generally well versed in the language mods are written in, and it takes someone who knows what to look for to find the bits that check for your architecture and make them go away.

You're trying to mess with code you don't understand, and that has a good chance of breaking things further rather than helping you. I think that's why this thread was created. Anyone who has even a basic knowledge of programming can grab the source, thumb through it and delete what they want and compile. The fact is most people who USE the mods probably don't know the first thing about writing them, and therefore pre-edited versions are the best option.

I think Senshi was right on the whole here. If you aren't already somewhat comfortable with reading source code, you're either going to have to teach yourself some basic programming (google can indeed help here, try looking for beginner lessons in whatever you want to learn), or stick to the pre-edited DLLs that Senshi/folks come up with.

Addendum:

If I wanted to manually edit a mod and had no knowledge of code, I think I'd start by checking google for a way to open the source code files. That would lead me to the software Senshii linked, or alternatives. Then I'd look up what method (code structure) is used to check for architecture, in whatever language it's written in. Once I know what I'm generally looking for, I can scroll through the source and find all instances of it, and either set it to always think it's running 32bit, or comment out (which makes the computer disregard it entirely) the checker(s).

Edited November 4, 2014 by Immashift

[mcirish3]

1. Fix references to all required assemblies (most/all are found in KSP_025_x64\KSP_x64_Data\Managed)
   
   Sorry having trouble understanding what exactly this means? I am getting a build error ( I can try and proved error log if requested) based on what it spit out I am guessing this is the step I did not follow. Please enlighten me when you get the chance. Sorry about being a block head on this.

[Crzyrndm]

http://wiki.kerbalspaceprogram.com/wiki/Setting_up_Visual_Studio or (Not both) http://wiki.kerbalspaceprogram.com/wiki/Setting_up_MonoDevelop

Instructions for everything pre-code editing are there. Following the rest of the tutorials on the wiki may also be helpful

[mcirish3]

Thank you trying again

I do think those wiki pages need some updating, some old info in them.

[NathanKell]

I updated the Setting up VS page about a week ago; it should be correct.

[mcirish3]

Ah, ok perhaps I was thinking the need to change 3.5 was out dated is this still necessary? I got the mod I was testing this on to build by directly referencing the correct .dll files rather than setting up a separate project. ( sorry, if I sound like a newb at this, it is because I am).

Edit: I also use 2013 express not 2012 as is stated in the wiki page.

Edited November 5, 2014 by mcirish3

[Crzyrndm]

No, KSP is built against .NET 3.5 so using anything higher can and will cause issues

Visual Studio version is inconsequential. They all work, it's just that the UI elements may have been shifted from what the tutorial indicates

[Senshi]

@G'th, my blunt reaction was caused by you making it seem like you are not actually willing to learn. A willingness to learn would be indicated by doing at least some research and trying yourself and then asking more focused questions. See how mcirish did it?

He asks a focused question, showing that he has probably fiddled and tried himself which shows a willingness to learn. As such, it is far more inviting to others to invest energy in answering and helping to solve the issue. Not the least because such focused questions actually can be answered in a meaningful fashion.

@mcirish: If you load the complete source of a project (such as usually found on github), they will use path references to libraries (.dll) that are located somewhere else on your computer. This is shown by a warning symbol in the "references" list in the solution explorer in VS. If that's the case, you just add a new reference, selecting the correct file on your local system and VS will update/replace the old reference for you. Once you have all those fixed, everything is good to go, no need for a new project.

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

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.

[mcirish3]

Thank You Senshi, I am sure that I will be coming back to reread your post a few times considering all the new info in it.

[G'th]

my blunt reaction was caused by you making it seem like you are not actually willing to learn.

Which is nonsense. Me saying I'm not willing to learn would be having you do it for me. What I stated was a complete non-understanding of everything involved, mostly due to your "guide" that assumes too much about the person reading it. You can't tell someone what to do but not actually explain how. (because if I didn't need to know how, I would have just asked what code I need to get rid of, not how to go through the process itself)

You can't tell me to use Google when I don't know what to freaking google for.

And FYI, I never asked for help with any specific mod.

[sal_vager]

Hey guys, please keep it civil in here okay? Thanks

[goldenpsp]

Which is nonsense. Me saying I'm not willing to learn would be having you do it for me. What I stated was a complete non-understanding of everything involved' date=' mostly due to your "guide" that assumes too much about the person reading it. You can't tell someone what to do but not actually explain how. (because if I didn't need to know how, I would have just asked what code I need to get rid of, not how to go through the process itself)

You can't tell me to use Google [i']when I don't know what to freaking google for.

And FYI, I never asked for help with any specific mod.

G'th to be fair, the basic guide did assume a bit about the person reading it. This is because there is no "simple" guide to jumping in with MS visual studio and reworking someone elses code. Mucking around with visual studio requires a certain base understanding, of which there are books written on the subject. Quite frankly it is far out of the scope of a thread like this to even begin to give a tutorial on the subject.

[Guest]

This is why this mod is necessary, and will be until the practice that made it necessary is dead and buried. VisualStudio is too complex of a beast to require everyone to learn it just to have their plugins working as they should.

Also, is anything happening on the RSS front? I think I can work with propulsive landings until RealChutes are fixed, but RSS is the whole point of using 64bit in the first place for me.

Edited November 6, 2014 by Guest

[mcirish3]

@mcirish: If you load the complete source of a project (such as usually found on github), they will use path references to libraries (.dll) that are located somewhere else on your computer. This is shown by a warning symbol in the "references" list in the solution explorer in VS. If that's the case, you just add a new reference, selecting the correct file on your local system and VS will update/replace the old reference for you. Once you have all those fixed, everything is good to go, no need for a new project.

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

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.

Hi Senshi, any chance you would be ok with me using the above quote in a tutorial I am putting together on this? (I plan on cutting this up a bit)

[Senshi]

@Irish:Sure.

@Dragon: I wanted to try RSS out myself for some time, but I haven't found the time to set it up. Hence I also had little inspiration to look at the plugin setup. Maybe I'll get to it this weekend.

[Guest]

Great news. That'll leave just RealChute and KJR (just realized this also disables itself in 64bit). Could you also tackle KJR while doing RSS? It's pretty useful, perhaps not 100% essential, but you're going to have a harder time without it.

[mcirish3]

So I was as good as my word and created a tutorial for this you can find it here.

Edited November 8, 2014 by mcirish3

[Mekan1k]

Can you add a module for mechjeb that allows us to slow down the Mechjeb reaction time? I think that factor may be why mechjeb occasionally shakes one of my planes to pieces.

[Senshi]

@Mekan: I fail to see why you think this is the right topic for such a request.

[Kamuchi]

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!

Edited November 13, 2014 by Kamuchi

[mcirish3]

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

Might I suggest putting it here...(tooting my own horn, sorry) I know it is a tutorial page and it is still a bit off topic, but it is a self help page too so perhaps others will come and we can all help each other find the answers.

[mcirish3]

Hi Senshi,

I am not sure if this is a common bug for NEAR, Heck I am not even sure it is a bug. I will grab a log output if you think it might be useful.

It seems that the horizontal ailerons don't seem to work right. They seem to work ok when placed vertical as a rudder. By not working right, i mean I can barely detect any visual movement in them, and can get almost no vertical control form them. I have been forced to use canards to have any vertical control at all. It is odd since when used as a rudder they seem to work ok. Oh and I have used NEAR in the past and the only time I have experienced something like this with it is with surface controls from a mod. Which never really bothered me since I always had the stock ones to fall back on. But now it would seem the stock one doesn't work. I guess what I am wondering did the incorporation of the Spaceplane Plus mod break some references in the NEAR code?

BY the way I am referring to these parts.

Edit:

Reporting a problem. NEAR is disabling the SP+ control surfaces completely. They're just inert and won't move. I'm fairly certain that it is infact NEAR that's causing this.

I reinstalled KSP, tried it without any mods, control surfaces worked. added a batch of mods (not including NEAR), they still worked. Removed that batch and put another batch in (of 5) WITH NEAR, they stopped working. I removed NEAR and they began working again.

So I think that's enough evidence. I am not sure what is going on, I'm currently re-downloading this mod and trying it again. Will report back if the situation changes.

- Xenro66

Xenro66: are you using NEAR on an unsupported KSP? (i.e. not-25, or 25 Win x64?)

Looks like there may a winx64 bock on something else in NEAR beyond what you may have caught Senshi. I will scan the code tomorrow after work unless someone gets to it before I can. I have to work very early Friday morning so not sure I can get anything finished before Saturday.

Edited November 13, 2014 by mcirish3
Updated info