Eric S

I have no clue why the editor is nesting that. Sorry 5th, especially if the forum notifies you that I'm quoting you. I've got a lot of respect for 5th Horseman, but he isn't right in this case. Something in motion doesn't apply a force. Accelerating something so that it does move does. However, so does decelerating. As long as the amount of fuel moving into the fuel line is equal to the amount of fuel leaving the fuel line and the kinetic energy of the fuel leaving the fuel line is absorbed back into the craft, they balance out. If the circular motion of the fuel is redirected downward, then THAT force counterbalances the force generated by fuel accelerating into the fuel line. If pumping water out of a bucket and through a loop back into the same bucket caused rotational acceleration, then why do we use reaction wheels for attitude control, given that those have saturation issues? On topic, I find I stopped using asparagus staging as much when we got the ARM parts, and have almost completely stopped using it in 1.0. Bigger engines made asparagus less appealing. Needing less delta-v to get to orbit, even more so. I still do liquid boosters feeding a central stack fairly often, but almost never more than one pair of boosters.

Xavven, yes, that's the point. The equal and opposite reaction of making the fuel stop moving to the right and move down would cause the merry-go-round to stop spinning (or in this case, counteract the force of the fuel that is starting to go around at that particular moment) and accelerate up. As was pointed out, this is off topic, so I'm in favor of moving the discussion to private messages.

Does the merry-go-round continue to accelerate as you walk around it? No. The only force was applied when you accelerated. Now, stop. The merry-go-round stops because your deceleration applied a force opposing the original force. Now, picture the fuel line shifting fuel. At any given time after the fuel line is primed, there's a balance between the force applied by the fuel accelerating into the fuel line and the force applied by the fuel decelerating as it comes out of the fuel line. Yes, there's a kick as the fuel lines fill, but the launch clamps could absorb that kick.

That's not as true as you'd think. Except for when the fuel lines are filling or draining, there's always the same amount of fuel being accelerated into the pipe as there is being decelerated when it comes out of the pipe. Generating torque out of that situation would be the same as being able to push against yourself. What is true is that if the craft starts rotating and goes unchecked, there will be a force trying to cause it to rotate faster. That would be conservation of angular momentum from the fuel that is getting transferred to the center core. On the other hand, what kills asparagus staging IRL is the fact that it's heavily reliant on turbopumps, and from what I've seen, those are probably the most common non-human cause of rocket launch failure going. That said, it's going to take about 70 years for the single layer concept to go from conception to practical application (conceived in 1947, if I remember correctly, and a practical application in the F9H which hasn't actually flown yet), so I wouldn't be surprised if it takes another 50 years for us to develop turbopumps that are reliable enough for asparagus usage. After all, KSP players didn't invent asparagus staging, we just live in a world with perfectly reliable infinite-fuel-flow turbopumps so it was easier for us to implement the concept.

While I agree with most of what you're saying including thinking that this would be nice to have, the point of on-rails physics is to have mathematically derived orbits so that we can throw the current time into an equation that spits out the craft's position at that time, barring SoI transitions and lithobraking. Unpowered trajectories fit into this quite nicely. Powered trajectories would complicate this. Feel free to derive the required equations and donate them to Squad. That's for the general on-rails usage. We could get around this by making active-craft on-rails handled differently than inactive-craft on-rails, though at that point, it might be better to alter physics-warp to allow for higher levels of physics-warp under specific circumstances (low thrust for one), though that would have its own set of issues.

Same here. I became aware of the game from a kurtjmac youtube video, paused the video to download the demo, and had bought the full game before I made orbit.

Using Caps Lock to turn on fine control will significantly improve the RCS handling on unbalanced craft from what I've been told. There's some logic in the RCS control that tries to correct for unbalanced RCS when fine controls are turned on. They added this after I started using RCS Aid, so I can't personally testify to its effectivenes.

It will. At most, there will be an option to use Win64, not a requirement to do so.

It was actually worse than that. Unity 4's Win64 code was buggy, and probably still is. When Squad first tried a Win64 client, it would randomly crash every minute or two. I suspect that the cause of many of those crashes was the Win64-specific bug that was described as "random crashes in the ray casting code" in the Unity release notes when it finally got fixed. KSP uses ray casting frequently, so there was no chance of a Win64 client until that bug got fixed. Even later versions of Unity 4's Win64 client, while better, were still problematic. The devs for Cities: Skylines gave up on Unity 4 and switched to a beta release of Unity 5 late in their dev cycle, not something I imagine they would have done without good reason. That should give you an idea how recently Unity 4 had problematic code in the Win64 client.

Again, not incomprehensible. Until 1.0 or so, KSP had a memory leak in asset loading. The LAST thing you want to do when your asset loader is leaking is dynamic loading. The memory leak was fixed in 1.0, and dynamic loading is already being worked on (I haven't heard either way whether they want to get it into 1.1, but I think they should prioritize that).

Funny thing is, one of the devs recently commented on those animations almost being ready to go live. I don't remember where the comment was made, otherwise I'd provide a pointer. So maybe in 1.1.

I've seen quite a few people suggesting cheats on something like this, fake SoI being the most common. I haven't seen one that would meet your first criteria. Without n-body physics, Lagrange points would be about as gross an approximation as pre-1.0 aerodynamics were, basically just giving you some place new to orbit a satellite/probe. Too much of the KSP UI depends on the predictability and ease of calculations of patched conics to make n-body physics part of the base game.

Yup, it really depends on what Unity 5 features you're using. The closest game to KSP that I know of that managed to switch to Unity 5 (Beseige) just released their Unity 5 version two weeks ago, I think. And that's a game with almost no UI and has been in development a much shorter time, so less likely to depend on deprecated functionality.

Yes, though there will be limitations on it. No one outside of academic research that is doing general connected rigidbody physics simulation is splitting a set of connected parts between multiple threads yet that I can tell, so it looks like you're still limited to a single core for a single craft.

The microbenchmark for non-threaded connected rigidbody physics simulations shows about a 50% improvement in most cases, seldom more, and sometimes less. As I understand the biggest problem with part count scaling (resources), the algorithm used is o(n^2), so a 50% increase in parts would result in 1.5*1.5 (or 2.25) times as much computation required. A doubling in parts would result in four times as much computation required, resulting in a quarter of the display rate if you were computationally bound to begin with, looking at just the resource utilization code. On the more optimistic side, the most KSP-like Unity 5 game I'm aware of, Besiege (think KSP but making medieval siege machines) had some rather significant performance improvements in their Unity 5 update which just came out Friday. Now, Besiege doesn't have the resource tracking issues that KSP does, but they are seeing 3x simulation framerate improvements even in times when multithreading shouldn't have been a big win (still a minor improvement from multithreading because Besiege almost never has a single collection of parts loaded, since there has to be a target). Then again, the demo the devs showed with that much improvement could have come from the improved collision detection, which I don't think is that big a deal in KSP. Basically, there's a lot of things changing under the hood which could improve same-craft performance in switching to Unity 5, but without having code profiling statistics for the current version of KSP, it's hard to predict how much these improvements will improve the overall end result. Having one part of the code running 4 times faster doesn't help much if that code is only running 5% of the time and the other 95% of the time it's running code that hasn't improved. Having one part of the code running 50% faster doesn't mean an overall 50% increase in speed unless either some other code has been improved even more or ALL the code is running 50% faster. Personally, I don't think we're going to see a huge increase in usable part counts on crafts until the scaling of the resource allocation code is improved, either by caching the results (which the devs have discussed) or by finding a "better" algorithm. Or better yet, both, because an order(n^2) algorithm is still an order(n^2) algorithm after caching is added, it's just a much faster order(n^2) algorithm. Then again, arguing worst-case conditions may not be the best approach when discussing KSP since it's possible for something that behaves "better" in an absolute worst case scenario to be slower during any conditions where the game would actually be playable. With all that said, my prediction matches cantab's prediction. I don't think it's impossible that the actual results will be outside that range (in either direction), just unlikely. If I had to do an over/under on that prediction, I'd probably hem and haw and never give an actual over/under, since the pessimist in me thinks it's more likely to be under 20% than over 50%, but the kid in me looks at the Besiege improvement and goes "ZOOMMMM!!"

The 64-bit changes are strictly a matter of usable memory space, the accuracy won't change between 32-bit and 64-bit, since the 32-bit code is already capable of using variables larger than 32 bits. On the other hand, it's possible that this issue may get improved by general code cleanup/debugging in PhysX, Unity 5, or the KSP client itself.

That's because Windows has the habit of switching a running program between CPU cores, so instead of one 100% maxed out core, it looks like 4 25% utilitized cores, unless you're looking at much more detailed information. Also, on the Unity 1.1 comment, we have reason to believe that a single craft will still be simulated in a single thread. The only people I've seen simulating multiple connected rigid bodies (the type of simulation KSP uses) have been research projects, not commercially available toolkits.

I'm pretty sure that I've read somewhere that they're aiming 1.1 at 64 bit for all current platforms.

There are caveats, but Unity does support on demand loading and unloading of assets. http://docs.unity3d.com/ScriptReference/AssetBundle.html As for the main topic, Maxmaps suggested that 64-bit addressing on all platforms might open up the possibility for more stock planets during one of the Squadcasts, but it was only a discussion of the possibility and his personal interest, nothing like "We're all excited about the possibility of more planets, YAY!"

Claw is right, the 64-bit addressing space isn't represented in the save file in any way, so that won't be the cause of problems. If I had to guess, I'd say that wheels would be the most likely cause of save-game incompatibility since they're getting reimplemented. That said, Maxmaps said that while they're not certain, save compatibility is looking good for 1.1.

Specifically, the Unity 3D editor is now available for Linux.

Well, from a purely code-optimization point of view (without algorithm changes), 50% isn't that modest, and that's what the connected rigid body microbenchmarks are showing (unless I misread them). Not saying I expect to see a 50% overall improvement, but it's within the realm of possibilities. I do think that they'll need to optimize the resource algorithms in order for us to see that kind of improvement, though.

I'm hoping to have been wrong as well, I'm just not certain that this isn't the case of a non-programmer (Maxmaps) getting something wrong when talking about something technical.

They showed a 2.5m jet engine during the squadcast, so you might get at least some of your wish. Actually, one of the modders they brought in is working on at least some optimizations. Not dedicated to it, however. Trying to find a reference to that comment.

No, the 64-bit stuff being discussed almost strictly affects addressing space (amount of usable memory for the most part).