Eric S

Too many other things that are deemed higher priority. It's not like they've got unlimited time to do everything they want right now, as much as we'd like them to have it.

Squad has said that they haven't done any work to optimize it. However, in the version of PhysX that Unity 5 uses, multithreaded physics are enabled without action by the programmer, so it will be there. Whether or not a single craft can benefit from multithreaded physics is a different question. EDIT: Note to self, read the second page before posting.

On the topic of the Curse Client, a while back the Curse people were talking about the next version of their client, which would support KSP. I haven't heard anything about that version of the Curse Client since then.

That limit on acceleration would produce the desired results prior to 1.0 when we had an atmosphere that caused a lot more drag than we do currently. However, since that has changed, you get a lot more actual acceleration out of your 22 m/s, meaning that you will go trans-sonic.

The fuel decelerating when it exits the fuel line counterbalances the force of the fuel accelerating into the fuel line. So you only get force when you are filling or draining the fuel line, or if you shut off the pump. There's a whole thread dedicated to just this one concept in the science forum here, and the consensus there is that while there would be some torque generated at the mentioned specific points in time, the torque wouldn't be continuous and even when present, would be well within the ability of vectoring engines to compensate for.

Sorry, that came out wrong. I was more saying that if you (generic you, not steve_v you) think multithreading is the only acceptable solution, you're setting yourself up for disappointment. Noone outside of a research project or two is having much success applying multithreading to this particular problem, and I'm not even sure that the methods used by said research projects would apply to KSP physics. So even if you (again, generic you) think that a game engine change should be fair game, it's not going to get you the multithreaded physics you want. Also, I'm not brushing off anything. I expect U5 to bring at least a small performance increase, and potentially a large one. Some of the improvements in U5/PhysX 3.3 may smooth out a few rough edges in KSP's physics simulation, but I'm not expecting many improvements there just from the Unity upgrade. We may even see regressions. I do think that waiting for 1.1 is reasonable since it's getting close and has the potential to have a major change on the scope of the problem. However, even outside the physics engine, there are things that can be done that might improve performance, particularly resource utilization, since it's order(n2) so has a larger impact on ships with more parts.

Well, since there isn't a commercially available physics engine that multithreads single groups of connected rigid bodies to the best of my knowledge, if that's your standard, then there is no solution short of asking Squad to write their own physics code, and I'm not going to bet on Squad doing a better job than people that have been writing that kind of code for years. This isn't to say that there isn't room for improvement. Just switching to PhysX 3.3 should be about a 30% improvement due to optimizations within the PhysX code, and that's almost worst case. Some parts of PhysX 3.3 have been improved more than that. Besiege, which is probably the closest Unity game to what KSP does got a rather large boost from the switch to Unity 5 even though it suffers from the same multithreading challenges that KSP does. On the other hand, just because Beseige got a large boost doesn't mean that KSP will. One of the biggest problems with large craft in KSP right now has nothing to do with physics simulation. The resource code can be a bottleneck as well, since it's order(n2), which means every time you double the number of parts, you increase the work the resource code needs to do by a factor of 4. The devs are aware of that bottleneck and have at least hinted that they're looking into improvements that can be made. At any rate, suggesting switching to a different game engine has been on the do not suggest list for as long as I've been aware of the do not suggest list, specifically because it would almost be starting over. Look how long it's taking Squad to update from Unity 4 to Unity 5. Now imagine how much worse it would be if they were switching to something that doesn't even try to be compatible with the current game engine.

I think I can admit to both being pro-"no net torque" (after the fuel line is filled, at least) and the person who most needs to keep the xkcd "someone is wrong on the internet" comic in mind on the topic. My reasoning (the explanation of which may be fuzzy, I've been having problems sleeping lately) is as follows. There is torque generated as the fuel is accelerated into the fuel line(s). However, once the fuel line is full, the fuel has to go somewhere, and unless it's getting directly spewed out of the craft in the direction the fuel line is run, there will be a counterbalancing torque as the fuel either decelerates or gets diverted. Deceleration would be the case of the fuel getting dumped into another fuel tank or combustion chamber, diverted would be the case if the fuel line makes a 90 degree turn, even if done gradually. Even if the combustion chamber doesn't absorb all of the lateral momentum of the fuel, the reaction mass is getting expelled at better than 2km/sec, so it wouldn't take much engine gimballing to counter the remaining torque unless the fuel lines are setting some kind of speed record. EDIT: the second point is off-topic according to GoSlash27's second post, which I didn't see because I fell asleep while composing the message. Getting 4-5 hours of sleep a night for weeks at a time is far from optimal for me.

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.

Because until 1.0, the default KSP asset loader had memory leaks, and doing dynamic loading when your loader leaks memory would have been a very bad idea. Now that it doesn't seem to be leaking, Squad has mentioned that someone there is working on dynamic asset loading.

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.

It sounds like the steerable/lights issues will be sorted in 1.1, give what they said in the reddit thread on these devnotes. And yes, I too look forward to the fairings with struts :-)

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.

Are you asking for a status update on the already announced multiplayer functionality, or not aware of it? Just clarifying. There haven't been many status updates on multiplayer yet, so I'm assuming that it's not far enough along to be able to have status updates that would mean anything to the players.