asmi

In order to execute maneuver node, we need to be able to get its' attitude vector (or, better yet, ability to "lock" onto it), and either a command for engines to execute X m/s burn (like it is in RL spacecraft like Soyuz), or expose more information about spacecraft propulsion system to script (at very minimum, current/max thrust and Isp), so that we would be able to write a script for that.

That's my guess as well, but I would like to get official confirmation.

What about partless mods like FAR? How would they "fit" into the picture?

Can you please elaborate on what do you think is realistic? Real-life spaceplanes (Buran and Space Shuttles) reentered with stalled-wing configuration which lead to the bulk of braking happening high in atmosphere where air is thin, so unless you enter apmosphere with insanely high velocity and angle it's simply impossible to break plane apart - at least I've never had that happening, and I had done some very agressive maneuvers like aerocapture on Duna/Kerbin/Eve straight off interplanetary trajectory.

I use many mods, but if I am to pick one of them, that would definitely be FAR.

As I've said, it's hard to suggest anything useful without seeing your craft. With FAR, shape is everything.

AWE API uses PAE internally. I agree, but your statement was absolute. I can name at least one user-mode application that uses AWE (and so PAE) - 32bit builds of MS SQL Server.

It works just fine with spaceplanes, just as with rockets. Infact it's primary purpose is to make planes work like they actually fly in the air, not in weird fluid. If you can't do that, you need to learn how to do it, not assume that it's FAR's fault - this mod is pretty solid at the moment, and if you go through FAR thread, you'll see plenty of accusations like your, and almost all of them turned out to be design issues with vessels, not with the mod. There recently was a big thread on SSTO designs with FAR, so I'm far from being alone in making it happen. If you want, you can go through that thread and maybe it will give you some clues as to how to do that properly. And if you want to get some help, please post screenshots of your vessel - there are many knowledgeable people over here, and I'm sure they'll be able to figure out what is wrong with your designs.

Actually it's not entirely true as there is a way for Ring3 mode process to access over 4GB memory if OS have such API. For example, here is Windows AWE API for that: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx. Right now there is not much point to use this API since transistioning to 64bit is so much easier, but remember that PAE first appeared in Pentium Pro CPU!!

I will look into it once I'm done with Newton physics mod. Right now I'm working on optimizing algorithm's performance. This is different - in most microcontrollers FP operations are emulated by int-core, while in x86-compatible CPUs all FP operations are performed by separate co-processor that is on the same die with main CPU, but it still is separated, even to the point that it can work asyncronously with main CPU unit (so CPU and FP/SSE command can be executed simultaneously), and that co-processor have FP operations implemented in hardware. This is why FP commands use separate from main int-core CPU registers (XMM). And that co-processor (commonly called FPPU or FPU) doesn't care about CPU's operating mode, and as such, all FP commands work the same way regardless of weither main CPU works in 32bit mode or 64bit. I don't feel like going into more technical details of this, but if you want to learn more, I'd highly recommend you to take a look at Intel developer manuals - they explain these things in great details. As a developer, you most likely know that optimization is hard. There are many reasons as to why it's so, but the problem is that in our world hard equals expensive. And Squad have just so many developers AND those devs are busy doing other great stuff. So from a practical standpoint, getting customer to buy additional memory is way more efficient in terms of effort/benefit. Unfortunately it's a trend in a real life that most projects don't give high priority to optimizations, and as concequence vast majority of software in alpha stage are memory- and CPU time hogs. So if they'll find a way to make 64bit build of KSP, they'll solve this problem for the time being, as they can always tell to complainers to get more memory, and so there at least would be some way to work around the problem until they will have more time to deal with optimizations.

This is not correct. RAM bus width is 64 bit times number of channels (128 bit for dual channel, 256 bit for quad channel) and CPU utilizes the full width regardless of the mode it's operating (be it 16 bit mode, 32 bit mode or 64 bit mode). What is referred to as 64 bit mode is the width of pointer to memory location (it's 32 bits for 32bit mode and 64 bits for 64bit mode). I have to notice that even in 32bit mode it's possible to address more than 4 GB of memory (CPU's physical address bus is wider than 32 bits for quite some time) via mechanism known as PAE (physical address extension). I won't go into technical details as to how exactly this works, just want to point out that 32bit Windows OS since Windows 2000 were able to use more than 4GB of memory. P.S. There are so many myths and misconceptions regarding this subject, sounds like an article is in order...

No, this is incorrect. I had exact same problem in my own engine, and successfully solved it. First problem is with graphics: "Conventional" graphics pipeline follows this order for coordinates transformation: model space ( * WorldMatrix) -> world space ( * View Matrix) -> view space ( * Projection Matrix) -> clip space ( perform "W-divide") -> normalized clip space. This order used to be mandatory until programmable pipeline stages (via vertex/pixel shaders) had been introduced. Naturally, KSP's problem is a combination of two factors: 1. Unity takes care of calculating these matrices. BUT - it uses single-precision math for that. 2. Their world-space coordinates are HUGE while view space are small. So what happens is that model space coordinates (ones that were created in model editor) get multiplied by HUGE number (which leads to loss of precision), and then is multiplied by another HUGE number (to bring them back into view space, which leads to another loss of precision). The problem can be trivially solved by pre-multiplying World and View matrices using double-precision and only than converting it to single-precision as needed by GPU. But I don't know if it's even possible at all to force Unity to use provided World-View matrix, as due to (1) it's Unity who is responsible for doing so. However, this is a trivial thing to do in your own engine since you have full control over the GPU pipeline. Second problem comes from physics engine, which operates at single precision, but for obvious reasons is required to work in world space, and so will incur big loss of precision. Again, a problem that is forced upon devs by Unity, as there are physics engines out there (even free ones!) which works with either single- or double-precision, so essentially eliminating that problem as well. So let's see - too biggest KSP's issues are induced by the engine...

I can't help but notice that the bulk of problems they had to overcome were caused by Unity engine itself - and by themselves these are not that big of a problem. What they call "origin shift" is known in the industry as "view space" and is used since...forever (typical pipeline is - local(model) space -> world space -> view space -> clip space -> normalized clip space). It takes one matrix multiplication to transform coordinates from any of abovementioned spaces into another one.

This is how myths are born. It's simply flat out incorrect. There is absolutely no difference in precision between 32bit mode and 64bit - both of them can use single- of double- precision floating point numbers.

For me by FAR the hardest thing is waiting for the next update to come out...

@yongedevil: I can't say "thank you" enough times to give you a justice! This is the final piece of a puzzle. And a couple of feature requests if I may: 1. Provide some documentation on how to write config for other parts, not included into the package (I've got some rescaled SRBs since there clearly is shortage of them, and AdvSRB are a bit awkward to get used to since none of dV calculation mods support it). 2. Add ability to modify thrust profile throught burn. Ideally allow customization a-la MJ's ascent profile editor, at minimum allow selection among preset profiles (constant thrust, "hammer" thrust - when there is a big hike in the beginning, and then it mellows out, decreasing thrust - useful for stand-alone first/second stages).

There is a fair amount of people who want realism - I'm among them. And please don't tell me what to do and what not to do - I'll figure it out myself.

TS has told me that he actually run full n-body simulation for the whole system, and all celestials were OK, except for Jool's moons. Looks like it was made artificially unstable. I wonder what would it take to stabilize them. But let's not get ahead of ourselves and do vessels-only sim first and see what happens. So far results are encouraging.

They will be on rails, just different ones

And what's the problem with doing just that? The biggest challenge is to find a way to relinguish trajectory control from the core system and take charge of it, if we'll manage to do that everything else will be just a technicality. Besides, why do you think that everything will immediately fly away just once you turn on Netwonian simulation? The only noticeable difference with existing system would be when object flies near SOI border on very high orbits. Most stations are in low-to-middle orbits, and Newtonian laws will yield trajectories very similar (if not exactly the same) to Keplerian.

There is another less obvious consequence of implementing this - once we have trajectories under our control, nothing prevents us from implementing auto-stationkeeping even for inactive vessels.

Is there any way to make it work with modular fuel tanks mod?

It's not - 0.22 is not even in testing yet, therefore it's at least few weeks away (likely more).

As far as I know, Bobcat uses 64% scale for his parts.

Keplerian equations is what is used by KSP now (patched conics are based on Keplerian laws).