Jump to content

Eric S

  • Content Count

  • Joined

  • Last visited

Everything posted by Eric S

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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 ha
  8. 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
  9. 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 downw
  10. 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.
  11. 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.
  12. 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.
  13. 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 kill
  14. 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 differe
  15. 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.
  16. 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 :-)
  17. 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.
  18. It will. At most, there will be an option to use Win64, not a requirement to do so.
  19. 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 o
  20. 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).
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...