NoPersona

KSPAPI extensions was only just updated. I'm sure that this mod will be updated when taniwha has time to work on it.

I was getting bad slowdown with DRE. Since I removed it, things started to work right again. *Edit* Although obviously, now that I want to repro it, I can't. So in the interest of doing this right. Before I changed my mod configuration, I had the issue that when Deadly Re-entry went in, all of a sudden it would slow down to a crawl. After I removed it, then the game would go fine again. So it seemed as if DRE and some mod configuration that I have totally forgotten was the cause. I have updated some things since then, so I would say, make sure all of your mods are up to date and try to round it down into a reproducible configuration. Copying your entire KSP directory somewhere else and using the copy to test things out in if needed. I am also aware that this isn't a case of do what I do.

The FAQ on the front page doesn't seem like it has been updated to account for the changes added to version 1.0 of the game, which made the stock aerodynamics much better. In general, FAR makes the aerodynamics more realistic. There are some things that the new stock system doesn't model, like accurate things happening as you are approaching and just passing the speed of sound. FAR also has nicer control over the control surfaces, allowing you to choose how much a surface takes part in pitch/yaw/roll, allows you to specify how much they actually deflect by, and more with angle of attack offsets, spoilers and flaps. While the stock game has some of this, it doesn't have it to the extent of FAR. In short, it allows you to crash planes and rockets in much more interesting ways while you are inside an atmosphere.

Have another "great work". After playing around with FAR for a bit, it feels great having my planes doing interesting things again. Enjoy your well deserved break. Even if you don't have one planned, you should have a break because you deserve it.

I must have remembered something silly along the way, thanks for this explanation and setting me straight. Keep up the awesome work with this mod.

Just one question about nuFAR. Will the new approach allow you to model dynamically changing wing shapes, for example, like using Infernal Robotics to fold the wing back? Or will the voxel model only be calculated at certain times like loading/launching/staging?

I'm going to add my opinion here. Users on this board sometimes seem to be pessimistic/fatalist when it comes to things. When the destroyable buildings were announced for 0.25, the reaction that I saw was people not wanting to believe that it was the foundation for the upgradable buildings. Unless there are major hints given or the plans are outright stated, we can't really know what is going to happen for any future release, so speculating on what to come is a waste of time IMO. While it hasn't been totally satisfactory at times, Squad has been trying to make the game mod friendly, so besides finalising the internal API, I really couldn't see them turning around on that, especially with how popular the game has been because of the scope that you can modify the game. But well, this is my opinion on this matter, so obviously people will disagree with me. The one major thing that I will say that I know isn't opinion, ferram4, this mod has added so much fun to the game for me. Rockets and planes falling apart, things doing cartwheels and other interesting dances in the air. I appreciate all of the hard work that you have put into this game, and I will be really sad if this mod does get blocked or you decide to stop working on it.

I haven't double checked with the release of 0.25, but with 0.24 the DX11 mode fell back to OpenGL. From what I can tell, Squad used a shader that was not DirectX 11 compatible.

There still isn't any tweakscale interaction. The tweakscale library that is supposed to come with it still doesn't exist, and as such, changing the size of the tanks with tweakscale doesn't work. In fact, looking at the makefile it doesn't build the tweakscale module, and the Visual Studio project for MFT actually has it named modularFuelTanks.dll too. This would overwrite the proper MFT.dll on build because it would get built second. After fixing what is needed and building it myself, there is proper tweakscale interaction.

Half baked? It is well known since the release of 64 bit Windows that the compilers follow a LLP64 model where the Linux community decided on LP64. That is Windows is long long and pointers are 64 bit, Linux is long and pointers are 64 bit. Microsoft chose LLP64 for a very good reason, so that when companies started moving towards 64 bit, nothing changed in their build process. There are lots of companies that like to build with warnings as errors, and this would have been a breaking change with a sudden load of warnings, treated as errors, that brought the build down. Now the problem with calling it half baked is that there are well known standard types that come with the compiler like size_t, intptr_t, uintptr_t, ptrdiff_t and the whole stdint.h header that include typedefs that name the size of a variable (like uint64_t). So there is nothing half baked here, the Windows compiler follows a well established format. The size of the types are published and well known and the C/C++ standard doesn't actually dictate the size of the types past how big they are in relation to each other, with char being the smallest. So if you want to blame and find fault with anyone it is the Unity devs not using types like size_t, which are always guaranteed to be the same size as void*, instead using platform dependent types like int or long.

Well, I'm on the other side of this fence. I think something warning users that there are some issues with the x64 version of Unity is a good thing. Besides the other opinion that I expressed, the only thing that I think would be required is for sarbian to keep up with the releases of KSP, so that if/when there comes a time when the x64 version becomes stable, the message goes away.

.24.2 had issues under the 4GB limit too. Just adding two part packs guaranteed that it would crash for me. Oh, and the OpenGL version for .24.2 actually crashed at ~10GB address space usage, so it wasn't anything to do with the process address space usage.

Well, I did say "more" accurate not "completely" accurate. :3 Since "Unity for Windows x64 must die" is a bit too long, how about "Winity x64 must die"? The game has known to be more stable when using OpenGL not Direct3D. So the Unity player may have defaulted to that allowing it to seem more stable.

Porkjet: geeky joke here, but if you were to extend Spaceplane Plus, would this become Spaceplane Plus Plus?

Just because I feel like being annoying and picky here. It shouldn't be named Win64 must die edition, because that can imply to some that the problem is with Windows x64. I propose Unity x64 must die edition, that is more accurate \o/.

I apologise for jumping in at random here. But since .NET assemblies are strongly versioned by default, (this is the whole point of the assemblyinfo.cs file and specifically the AssemblyVersion attribute that you define in there), unless you are using reflection or you somehow messed up the versioning of the assembly, surely you are never able to touch things from a differently versioned assembly in the process. I'm wondering this because the rules that I know for the Microsoft .NET framework has assembly loading based on file name and version of the assembly. This is quite clearly specified in the MSDN library. So unless mono has done something different in their implementation of the CLR, it should only be binding against the version that it was built with.

@Nsomnia: Try running the game in OpenGL mode. You can do this by running it with the -force-opengl command line option. I would also suggest using texture managers like Active Texture Manager basic or TextureReplacer. Even though their reason for existence is to help ease the 32 bit process memory situation, they help a lot with the 64 bit version too. This reduces the memory footprint of the game and makes things load quicker. But this is just opinion. @trackpad.user: The OpenGL version works quite well. So I would say that it isn't completely broken. The Direct3D9 version does have more issues though, and since the Unity runner defaults to that, then I would guess that is why people claim it is broken.

I'm not convinced there is a memory ceiling, I'm thinking more of an issue with the D3D renderer. Loading the game with OpenGL rendering, I have seen less of an issue with the game. It is still slower/more jittery than 32 bit KSP but the mod compliment that I currently have in, without ATM/Texture replacer, puts the address space usage up to 5,294MB. *Edit* After I wrote that, I got the game to crash at around 10GB. Even if you are using the x64 version, Texture Replacer's ability to do compression helps a lot. So even if you don't use it for anything else, at least use it for the compression. You can also use ATM basic on top of that too, the savings are quite interesting.

Out of curiosity I took a little look at the pre-release code available on GitHub, there are fixes in there for a few issues. So no, 0.12 isn't just moving to TweakScale. I think he mentioned that there was also going to be some rebalancing too.

In the WarpPlugin directory there is the science.cfg file, you probably know this already since that is the file that you have to delete. If you open it up in your favourite text editor, there should be three lines !MODULE[ModuleScienceExperiment] { } If you remove these and save the config file, then you should have both experiments.