Eric S
-
Posts
1,589 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Eric S
-
-
On 1/13/2016 at 8:36 AM, Majorjim said:
I agree that 1.1 will definitely run better than the current version. It is obvious that PCs have an advantage here and will allow for higher part counts. I know that console CPUs (PS4) are running at 1.6GHZ per core. Now we know unit 5 has support for multi-core physics but Squad have not changed the games code to use this properly.. Squad themselves confirmed this.
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.
-
On 12/31/2015 at 8:37 AM, StarManta said:
The rotational force from fuel churning around in a circle as it does with asparagus staging would destabilize any craft in the real world.
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.
-
1 hour ago, steve_v said:
And nowhere in that post did I suggest switching physics engines. I simply pointed out that there are no guarantees Unity 5 will be a magic fix for the current issues, and that it won't, as you say, address the multithreading request.
Brushing off every "performance sucks" or "the physics are wonky" post with some variation on "U5 is coming, it will make all the problems go away" is getting rather annoying.
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.
-
4 hours ago, steve_v said:
Which, unless you have some extra insider knowledge, does not multithread single vessel physics. And therefore does not address the request.
Will it be fixing the "explodes on load due to sudden physics start" phenomenon? or the "Base explodes on load due to poor terrain collision detection"?
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.
-
18 hours ago, 5thHorseman said:1 hour ago, Zoidos said:
In principle, 5th Horseman is right. If you stand on a merry-go-round and pump water in a circle into the same bucket where it came from, you are still moving mass around, thus exerting force. This will cause the merry go round to accelerate as long as water is pumped. Although compared to a 100t spacecraft the force of the fuel being pumped around is negligible.
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.
-
1 hour ago, 5thHorseman said:
No, it's as true as I think. If you ever get the chance alone on a merry-go-round, get on the edge and slowly make your way around it. You'll notice that the Merry-go-round more slowly (but perceptibly) goes the other way.
Even though there is no outside force on the two of you, your force on it (or more easily imagined the shifting of the center of mass of you two as a pair) causes - when one of you moves relative to the COM - for the other to move to compensate.
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.
-
On 12/29/2015 at 4:52 AM, n0xiety said:
Its great and all but why is this not allready ingame with 8k textures to whoever wants to use them? I would really like to see this in game officially and stable with the 1.1 version or maybe this could be a goal for the 1.2 version. I am allready using 8k textures and it makes the game 150mb bigger so no issue on the size. Why not add it to the main game? That way people with worse systems can also play with the crispy 8k textures.
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 hours ago, 5thHorseman said:
THAT is what is not super realistic for at LEAST the reason that it would introduce torque in the ship, pumping fuel around in a circle like that.
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.
-
6 hours ago, StarManta said:
I believe that that is not so much the "whole point", more of a logical result of the way it is implemented. However, there are at least two exceptions to its predetermined-ness: SOI transitions as noted, and collisions with terrain. This would simply be another exception.
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.
-
1 hour ago, Temstar said:
I took out my credit card within 15 minutes of firing up the demo.
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.
-
12 hours ago, Cdr_Zeta said:
Not getting lost here...please tell me KSP 1.1 will work with Unity 5 and 32bit KSP.
I will be looking at Unity 5; but no intention of using Win64 KSP.
Zeta
It will. At most, there will be an option to use Win64, not a requirement to do so.
-
3 hours ago, Alshain said:
The reason KSP is 32-bit only is simple, Unity 4 did not have a proper debugger suite for 64 bit, so while you can develop 64 bit in Unity 4, it's nightmarish to try and find the bugs.
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.
-
14 hours ago, theend3r said:
For some incomprehensible reason, KSP keeps the textures and models of all the parts in its memory even when you only use 10% of them in your flight scene. There was a mod that partially soved this but it's a problem that needs to be solved by Squad for it to work well.
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.
-
Come on look at how many missions we have in L1 and L2. Look asking for a little more realism (challenge) is not asking for a perfectly accurate simulation of reality. There are a variety of cheats that could be done that can still provide 1) reasonably accurate predictive flight paths and 2) more interesting/realistic/challenging orbital mechanics.
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.
-
So Unity 5 has multi-core support? Squee!
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.
-
I am wonder if is there any thought about multiplayer implementation... Good news are always soon...
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.
Devnote Wednesday: Tuesday Edition
in KSP1 The Daily Kerbal
Posted
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.