asmi

In this case your code would help a lot to me. I know C/C++ just as good as I do C#, so language is not a problem at all. If for some reason you'd prefer your code not to be published, feel free to PM me a link to it.

Why don't you use quaternions to avoid gimbal lock? They're seems to be quite easy to use once you figure out what they actually are.

Acceleration will affect your speed on next iteration. But it doesn't change the current one. Remember - it's integration. There is absolutely no reasons for orbital calculations to be in the same thread as physics.

Acceleration doesn't affect orbit - only velocity and position do. And you know that because...what? The point is - there is no way to know until you try. And that's exactly what I'm planning to do. This is not possible due to different behavior of L points (L1-L3 actually push the vessel away in certain cases), not to mention singularity at the exact center point.

I didn't reply to anybody in particular, I've just gathered this across multiple threads on a subject. As for trigonometric functions, there are easy approximations (like lookup tables) - infact some earlier video cards used built-in lookup tables for them instead of actual computations. For the GPU - allthough recent generations of video cards have pretty good built-in support for double precision, there are ways to achieve double-precision (and even quadruple!) using single-precision math, there are many articles on the subject so this is not that big of issue. But I agree that optimizations can wait a little and proof-of-concept have to be built first. At first I was thinking about implementing a mod that would calculate and display in map view "real" trajectories along with built-in ones so we would be able to validate that calculations work as we expect them in all modes, including time warp. This sounds like a good enough first stab at subject. What I need is state vectors propagation function (over integration step). Essentially, it's the function (x1, v1) = f(x0, v0, dt). I do know Newton's second law (dv/dt=F/m) that would allow to come up with simple function, but it's not going to be accurate enough for our case. Let's leave rotational state propagation alone for now - we can always add it afterwards once we're done with the main thing. In addition it would be great to have some sort of interpolation function that would provide ability to calculate state vectors in between steps (i.e. let's say we have a lookup xi => t0 + i * dt, but we want to estimate x at the moment of t0 + (i + 0.3) * dt). And as a bonus it would be great to have a function that would allow calculating Keplerian orbital elements (eccentricity, semi-major axis, inclination, LAN, argument of periapsis and mean anomaly) from state vectors since that would help with displaying this info. I could come up with this function myself, but if you happen to have it handy, I'd appreciate if you'd share it. Please create a thread in "Addon Development" section since that seems to be more appropriate place, and let's go from there. I can't promise anything until the weekend, but I show have a fair amount of spare time to come up with some prototype. Thank you! KSP PhysX issues have nothing to do with orbital calculations (see my post above about that), and indeed it's trivially easy to calculate orbits for different objects in parallel (just as there are ways to make "regular" physics algorithms parallelled, it's just a bit more involved).

It's time to debunk some myths about KSP: 1. Orbital calculations DO NOT use PhysX - it's completely custom algorithm. 2. Orbital calculation DO use double-precision variables (double type), not single-precision (float) as many seem to imply. 3. Patched conics calculation is VERY cheap, you'd need to have tens of thousands of flying orbital objects before they incur any serious performance penalty. To the OP - I was thinking of implementing something similar to what you're suggesting in a mod, but run low on spare time to do so. But I'd like to point out that orbit propagations can happen in parallel for several objects at once (and even more if offloaded to GPU), and over long time there could be some sort of combined approach (like "orbit stabilization" in Orbiter). I honestly suck at math of all of this (I know how this works on a fundamental level, but lack mathematical details), but if you would be so nice to provide all equations, I'd find some time to try implementing something like this for CPU and let's see what happens.

@Majiir: Using shared resources among different mods needs to be very careful as some things could have difference meanings in different contexts. Not to mention what would happen if one mod dev would decide to change it for whatever reason. I'd keep them separate just to be safe. As for localizing non-plugin parts, in can be done in a manner similar to what ModuleManager does. We could override stock part descriptions with it and come up with some sort of special syntax that would instruct MM to look up localized string. It could also provide API for plugins to do the same. There is one problem though - this all is applicable to strings only, but there might be cases where other resources would need to be localized as well, so we'll need to think about that as well. Regardless of how this will do, I would offer my assistance in this project. I'm professional .NET developer with over 10 years of experience in this field, and although I generally don't have as much spare time as I wish I'd have, I will do my best to help out.

.NET runtime has built-in support for internationalization through the use of sattelite assemblies. It only requires that all localizable resources (not just strings, but any other resources) are put into .NET resource files (*.resx). Then by creating a copy of this resx file with language identifier (for example, if your "language-neitral" resource file is called LocalResources.resx, you create a copy named LocalResources.fr.resx - for French, LocalResources.ru.resx for Russian, etc), translating resources inside these localized versions, and compiling all these. If you want I can create a sample project to demonstrate this approach. I'm also working on small GUI library for KSP projects that is XML-based and provides WPF-like interface, the library itself is almost complete and I'm working on creating samples and testing it out. I was thinking about integrating internationalization support into this library, and looks like I need to do just that

Isn't it using OpenGL? Anyways I think it's worth trying.

Hello all, I've got a question that bugged me for few days now - why Kerbin's atmosphere is so small? If I understand the physics of it right, atmosphere size is proportional to the celestial's mass. Kerbin's mass is just a bit smaller than that of the Earth, so the atmosphere have to be similar, hasn't it? I'm looking forward for your opinions on the subject.

Windows' task planner can shift task to another core at any time it deemed necessary. When we say "single-core" we mean one core at a time, but it doesn't have to be the same one all the time.

I wonder why everybody seem to think that first rockets used solid fuel... All early rockets (V-2, R family, Redstone) used liquid fuel - solids came much later.

2G is too low imho. Soyuz rocket pulls up to about 4G, and that's manned rocket.

That is editor issue that's been around since introduction of action groups. You'll need to reassign action groups for symmetrical parts every time you detach them.

@ferram4: Why don't you compute the mesh that represents outer "shell" of the whole vessel (the minimal mesh that would contain every single part of the vessel inside), and then calculate aerodynamics for that shell, instead of calculating aerodynamics for each individual part?

Hello, As you might know, it's possible to load your own shaders into KSP that uses fixed pipeline, but not custom CG shaders as runtime lacks CG compiler and so it's unable to compile the shader. Well, as it turned out, it is possible to do that with little trickery. Here's how: 1. put your shader into some Unity project 2. open it in Unity 3. find the shader in the asset explorer, right click it and select "Reimport" 4. navigate into your Unity project's Temp folder. There will be a file named "CgBatchOutput.shader". Open it up and it will contain your compiled shader. Now you can load up it's contents however you want (hardcode it into the code, embed it as a resource in dll, put it as a stand-alone file), and the pass this text into constructor of Material object. Bingo! Now you can leverage however complex and cool shaders you want! A word of caution though - if you opt to use some advanced shader features (like Geometry shaders for example), be aware that there might be users with hardware that doesn't support them. In this case you can either provide a fallback solution, or provide some other sensible reaction to the user.

There is a thread full of SSTOs made with FAR: http://forum.kerbalspaceprogram.com/showthread.php/47347-The-supplementary-SStO-thread-FAR

If SRBs are involved than I keep LES until they're gone, otherwise until about 10 km. I use LES from Soviet pack.

Awesome work, guys! Here is my Koeing-737 landing in the new airport: http://imgur.com/a/VNpmW

Just found this video: http://www.youtube.com/watch?v=SnNNa_kmKyU Flat spin is obviously not a problem for this plane! Just WOW!

The solution to the chute problem is to activate it once subsonic. No chute can survive when deployed at 3M.

Well Buran didn't really have rocket engines (small OMS thrusters don't count) so it couldn't possibly get into space if started horizontally. I've heard accounts saying that Buran was much better aerodynamically than Shuttles were, but I don't remember the source. If you don't mind sharing *.craft file for the vessel, I could play around with it to see what's wrong with it. It's hard to judge by picture.

I'm not sure about space shuttle, but Buran airframe was able to take off just fine when fitted with jet engines: http://en.wikipedia.org/wiki/OK-GLI Infact that's how they were "debugging" landing autopilot to the point that it actually landed itself completely autonomously on the first flight. Try that and see what happens Just make sure you have really high AoA - to the point the plane would stay that way with little to no input.

I've stopped using and deleted all wing parts the moment we've got procedural wings as they offer unparalleled flexibility in designs while still looking very good and without any clipping-through and other tricks commonly used for stock designs.

Most of my SSTOs have around 1k dV when they are fully loaded, but if launched with empty cargohold, dV is usually in excess of 1.5k. As for aerobrakes, if you're talking about B9 airbrake, it's way too overpowered IMHO for it's size, so I don't use them. I always stall my planes during reentry as it allows to decelerate significantly while still in high atmosphere, which gives me assurance that I won't over-G nor burn up once I go deeper in atmosphere. There is nothing tricky in doing that once you do that few times and get a "feel" for it. Just make sure to pack enough RCS to be able to recover from stall when time is right. And remember that both real-life spaceplanes (Shuttle and Buran) used that technique for reentry.