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