asmi

Whenever you do something you've never done before, there is an inherent chance of encountering something unexpected, which will throw all your time estimates out the window. And the more "unusual" is your task, the higher is the chance of something going wrong. So by not announcing time IG is managing expectations, or, more specifically, preventing situations when they have to break their own promised timelines due to factors beyond their control. To give you a more easily understood analogy (and please remember that it is but analogy, so don't push it too far), why do you think courier companies like DHL, Fedex et. al. never tell you precise time of delivery? They generally only tell you a day of delivery, maybe a few hours-wide time window if you're lucky, but never exact time. The reason is that there are certain factors which can affect that time, and there is nothing a company can do about them. So it's the same priciple. Another approach to this is a rolling release schedule, when a release happens every X weeks, hell or high water, but the scope of release changes based on what is actually completed as release code-freeze deadline hits. This usually workes better with larger teams so that even if some functionality is not going to be ready, there is always something to release because a chance that everyone in a team will get stuck at the same time is rather low, and get lower as number of people in that team increases. I suspect that this is mostly beyond IG's control, except maybe for overhyping the game before release, but this problem is very typical for EA games as players tend to have over-inflated expectations and become disappointed when reality hits them. As for the good will, IG is not a 100 dollars bill to be liked by everyone, so no matter what they do, somebody will be disappointed. That said, I have a suspicion that a majority of KSP players either bought KSP2, played a bit and shelved it until some better times, or delayed a purchase until that better time arrives, but don't feel an urge to go to forums and scream&moan about it until the pigs fly. I myself bought the game on a release day, played a bit, and shelved it. Every time an update hits, I fire it up to check it out, and leave it be. I want some sense of progression, so I don't think I will be playing a lot until science hits, but every now and then I still fire it up and do something I feel like doing at that exact time.

I can't speak for Redneck, but since I'm a software developer, I would love to hear technical folks. I know they tend to be camera-shy and not really into talking, but still - I want to learn more about ins and outs of KSP2 from technical standpoint. Creative side - not so much, sorry, since my professional deformation (abstract reasoning) allows me to see the beauty in ugly pictures which demostrate some cool technology at work.

This is what a lot of mature products look like in my experience (20+ years of software development of pretty much everything under the Sun from websites and fintech LOB applications to AGV guidance systems and applications for factories' shop floor). It doesn't neccessarily mean that foundation is fragile, but it just happen to not account for certain edge cases that planners/developers/testers didn't think of when they were working on a system. This is where 80/20 rule comes from - it takes a relatively small amount of time ("20%") to implement a system, and then the bulk of work ("80%") goes into ensuring it works over the entire range of cases which it's supposed to work. The first stage ("20%") is usually referred to as "initial development" (or simply" development"), and the second one ("80%") is "stabilization". There is also a rule of diminishing returns - meaning that you tend to get the most gains in the beginning of stabilization stage ("low hanging fruit"), but as it goes on, it takes progressively more effort to achieve the next step. Armed with this information, you can actually get a rough idea of where on this journey each sub-system is - if you see a lot of bugfixes in certain sub-system, that means it's just entered a stabilization stage (and it's got a long way to go), but if you see developers wrestling with the same issues for a long time - that means this sub-system is closer towards the end of stabilization. So as much as I hate SOI and trajectory bugs, the fact that they are battling with them for a while gives me some confidence that sub-systems involved a rather mature. This is obviously not a certainty as it makes certain presumptions regarding the team (like that people working it have enough qualifications to actually complete it, and there are no non-technical obstacles), but this is the best we have at this point. I'm personally more concerned about regressions - while they are inevitable every once in a while, they usually indicate deficiencies in a QA process (not neccessarily with actual QA people, but rather the whole flow from documenting bugs to passing this info to QA, to QA actually understanding info that is passed on them, to them executing testing properly, to passing feedback back to developers).

From my discussions with Ferram, FAR uses voxelization to calculate an airfoil, what I proposed is a more simple model which doesn't account for a lot of aerodynamic effects. That said, it can be extended to do that should they ever decide to - for example they can add a part mask to figure out which part is exposed to airstream so that they can apply forces to it (this gives things like body lift and per-part vessel destruction due to aerodynamic loads) and/or add heating (gives us high-speed/reentry heating). This also "implements" air breaks essentially for free (since their deployments increases an area presented into the airstream, they generate additional drag). Finally coupled with slope calculations based on a depth map this system will also "implement" an actual aerodynamics, meaning not just drag, but also a lift, and allow removing yet another crurch, which is what current lift system is. And knowing slopes + depth you can calculate an airfoil, which leaves a door open for a full-blown FAR-like system with faithfully simulated advanced aerodynamic effects. As far as performance goes, any more-or-less modern hardware should have no problems rendering a few 10K triangles into a texture, and compute shaders are no longer a serious performance drag like it was a some years ago.

Yes they are linked, as developer himself said above. No, it doesn't reward part-clipping, what it does reward is making designs aerodynamic. Which is what it should do. Part clipping is facilitated by VAB editor, not by aerodynamics. A couple of things: 1. FAR used approach functionally similar to the one I proposed for years, and I can't remember ever seeing anybody do a clipped fuel tanks spam. 2. Even if it would be true, why do you care how others play their game? I know I won't be doing this even if it would be beneficial. For example, asparagus staging has always been a preferred way of making launch vehicles, yet I've never built one in my entire 1000+ hrs of playing KSP because it's unrealistic. And most youtubers I've watched didn't do this either. ------ And my point still stands - it's not a job of aerodynamics to penalize players for abusing game bugs and glitches for fun and profit. Instead those bugs should be fixed, and - if part clipping spam is indeed considered undesired from gameplay point of view - then VAB editor should prevent such things from occuring, and/or adjust fuel capacity/loadout in case that happens.

That wouldn't be much better. For example, it would fare just as bad as a current system in the abovemention example of a solid axis-aligned unit cube - and for the same reason.

My point is - whatever the situation with clipped fuel tanks is, it's not the job of aerodynamics to "penalize" for it. This idea to link clipped tanks with aerodynamics is so absurd that I question the sound judgment of whoever came up with it, and also wonder what other similarly insane ideas found it's way into the codebase. That is a very depressing thought, and it gives credence to naysayers' claims that the tech team behind this project simply lacks technical expertise required to deliver the project with quality that most people expect.

The problem with cubes - which devs don't seem to get judging by their posts, is that it only works somewhat well with smooth convex shapes, so that if your part/vessel flies 45° into the airstream, you can interpolate between drag area "up front" and "side" and get somewhat realistic value for drag. But when was the last time you've seen anyone makes a vessel with smooth convex shape? Let's take a trivial example - an axis-aligned solid unit cube (1 meter in each dimension). If you precalculate it's drag surface from each cardinal direction, you get 1 sq. m. for all directions (because a cube is axis-aligned). But what if you "fly" that cube by the edge into the airstream? You should get 1.41 sq. m. because the airstream will "see" two sides of a cube at 45° angle each, and total area will be sqrt(1^2 + 1^2) * 1 ≈ 1.41, but you can't get that value by interpolating between sides, as they both are 1 sq. m. And so the "cube-based" drag model will treat a cube as if it's a unit sphere, which of course is completely incorrect. So if a model fails with a simple cube, can you imagine how it's going to work with more complex non-convex shapes? Well, you don't need to imagine - just fire up KSP2 and you will see that it's bevavior defies common sense in almost all cases.

That is ridiculous. The proper way to solve this problem is to disallow such clipping, and absolutely NOT to introduce yet another bug-o-dynamics instead of aerodynamics. Aerodynamics is - and should be - governed by the outer shape of the vessel, it doesn't and shouldn't care about internal construction. Besides, since you plan to only penalize clipping fuel tanks on top of each other by drag, does it mean that you have absolutely no problems with such "designs" when they escape atmosphere? Or you didn't think this far yet, and when you do, you add some other ridiculous penalty - like tenforld increase it phantom forces from buggy physics engine? Honestly reading such dev posts makes me lose confidence in a technical competence and decision making of a dev team. The job of air drag system is to simulate drag, not to resolve shortcomings of VAB editor by inventing fake penalties which will leave players scratching their heads thinking "why the heck do I have so much drag?" when the answer is "you clipped one too many fuel tanks" (a face palm smile goes here). There is absolutely NO way in hell the player will ever figure it out, that has NO basis in reality and therefore should NOT exist. So, pack up that existing drag system in a box, seal it and throw away that crap as far as you can, and implement this system properly. Existing system has so many holes and edge cases I can come up with right off top of my head, that I can't believe the tech leadership didn't shoot this idea down right from the get-go. I know I would've done exactly that.

Watch the player count over a day or two after update - you will get some idea as many people I suspect would want to try out a new update.

No it's not possible, because the shape presented to the airstream is going to depend on a direction of that airstream relative to the vessel, and so it's not feasible to pre-calculate all possible directions in advance, especially since every time the craft changes, it will have to be re-calculated. Also real-time calculations will take into account things like flexing, which can also lead to a change in a shape presented into the airstream.

They don't solve any problems, they just mask them. But at some point they still rear their ugly heads.

Actually a hacky crap that was described in the article will give you no end of headaches due to endless supply of edge cases. The proper way to do it is to render vessel from the airflow's POV with orthographic projection and linear depth, use shader which captures depth into texture, and then run a simple compute shader over it to calculate a drag based on how much of a texture has depth written out (this is the simplest possible model). More advanced model would calculate slopes (dz/dx and dz/dy) and drag values would be based on those slopes (this way more "aerodynamic" shapes would indeed be more aerodynamic and have less drag). This approach also provides a permanent fix for cargo bay occlusion problems as a free bonus with no further hacks required (because what's inside the bay will not render into depth texture at all, or will be overwritten by closer surfaces depending on how you set up your render pipeline and how good you are at culling stuff). And - most importantly - since this approach actually models how airflow works (ignoring mach effects and some other things like skin drag, flow separation, shock waves, etc.), it does not depend on part setup or vessel composition - it only cares about the shape which is presented to the airflow. Which is how it should be. If you worry about possible performance issues, you can only run these calculations every X frames as opposed to every frame, and interpolate drag in between. This might even be a configurable option in the settings.

Exactly! We can hope for it, but expect - not.

And that was very prudent of them, because whatever number they would've said would end up being wrong as it heavily depends not only on user's hardware, but software too, and you can get wildly different results on similar (on paper) systems.

I've watched it all, and nowhere had Nate said that 1000+ parts vessels are going to be possible at reasonable framerate. Infact he didn't call out any particular number, he just said "I hope that limit will be much-much higher than KSP1". Hope is not a promise, it's just that - hope. And for what it's worth, I hope that too. But software developer in me says that it's unlikely to happen any time soon, and I doubt this will be their focus at least until after few roadmap updates knocked out so that the game will be stable enough for such experiments. Right now even if you build a 1000 part vessel and somehow launched it into space in one piece, it will still probably tear itself apart at some point due to phantom forces, especially if you like save/load gameplay style. That question is completely irrelevant to this thread, as no amount of money will make Cyperpank 2077 run on potatos with any quality to speak of.

I would love it to support 1M parts vessels, but I know it's not gonna happen. And I doubt that 1K is going to become a reality either. Most of my crafts in KSP1 are on the smaller side because I like the challenge of achieving as much as possible with as little as possible parts (though I prefer using procedural parts which tend to reduce parts count compared to crafts created using regular parts). I think my largest craft was a space station with about 200 parts, but most "mission-oriented" crafts were/are <100 parts. If I get 60+ fps with such vessels, I'm happy. But again, my point is that no hard numbers were ever given by devs, and so I try to set my expectations lower in order to avoid being disappointed.

It doesn't matter if I agree or disagree, it's about managing expectations. As someone who did a fair bit of graphics programming, I know that to be true for sure. I wasn't hyperbolic nor did I attack anyone, I simply used the same language you did.

Who said that? That was never promised, not it is in the roadmap, therefore it's very unlikely to ever happen. KSP1 still chokes on 1000 parts crafts today, despite huge progress in CPU and GPU horsepower, and I see no reason it will be any different with KSP2.

Who said that? This is nonsense. How beautiful the game is has very little to do with performance, especially since "beautiful" is very subjective. To the OP - may be one day integrated graphics will be fast enough to run anything other than desktop and a decade-old CS, but that day is yet to come.

You should read again what he said. He is not disappointed that Nate responds to complainers, but that he didn't respond to non-complainers.

There is a rather simple solution to this problem - when nothing departs or arrives to the vessel, it's orbital parameters should be locked. Because physics (REAL physics, not buggy physics engine). Orbital parameters shall only change when something impacts the vessel (collision), or something departs it - it can be exhaust (covers cases with thrust and RCS impulses), or some parts (covers the case with decoupling or jetissoning something), or when there is some external force (covers the case with entering atmosphere). Another common (and super-annoying) problem is landed vehicles jumping around when switched from/to or upon loading the save, one of solutions is to temporarily increase physics frequency (by reducing the delta time of physics engine and thus effectively slowing down everything) right after switch/load to give joint system enough time to stabilize calculations and dampen any large oscillation caused by integration errors.

This might influence a decision, but ultimately it's still in the eye of a beholder, err, a buyer if it's worth the money or not. Basically if someone bought it and did not return (got a refund), then he/she thinks it's worth the money. One can debate the rationale different people used to justify this decision, but everyone's probably got a different one so there is no point debating it.

I, and almost every developer of RSS and RO, would hug the entire team for this feature alone! We've collectively spent countless hours trying to convince KSP1 devs to implement axial tilt, but they resisted, and - judging by the troubles you're having - for a good reason. This limitation of KSP1 made modelling Earth axial tilt so awkward for us, when we had to "tilt" the entire Solar system instead. Now I'm super glad that it won't be neccessary anymore for KSP2!

I think our petty earthly political squabbles have absolutely no place in the game about science.