RocketRockington

Considering they kept wobble rockets on purpose too, I think its mostly that whoever made these decisions in the early days (and I suspect I know who) thought that some of the goofy/cartoony physics from KSP's early days was one of the things that made it successful, rather than an artifact of KSP still figuring itself out (given that KSP later added autostruts to much rejoicing). It *really* seems like idiosyncratic design vs looking at general community sentiment and the general desires of the average KSP player.

My guess is its because that's the general direction Uber/Star Theory/Intercept took. While they told us they were improving physics and fundamentals - killing the kraken! Better physics in every way! - mostly KSP2 is about applying a lot of shiny paint, adding tutorials to try to get new customers, and then the features they decided to add that we're going to wait (at least) a couple more years for. I've seen basically 0 improvements to anything I'd call a 'fundamental' - same or worst physics. Same or worse aero. Same or worse orbital mechanics(though we're promised some hacked up 3-body for exactly one planetary pair? That seems weird but maybe). No heating - likely 'same or worse' when it gets here. Same or worse power system. Same or worse resource system. List could just go on and on.

KSP used to have some pretty extensive debug info on aero, both in the PAW and visual info you could render . Shame that seems to only be a developer tool in Unity now in KSP2. Since this is a copy of KSP1's system, it's the 'act like it wasn't translated' option.

FAR or KSP1 aren't the only options. You could have calculated drag from a depth & normal-only render of the craft on the fly rather than a pre-baked render of each part that you sum. Because unless the parts have each other attached by their attach nodes and never moved/rotated - or worse, don't even have attach nodes - KSP1's solution starts breaking badly. That would have required more work than just copying KSP1's solution of course - but my god, what WAS 6 years spent on?

No, this is an exact copy of how the KSP1 system works. Redoing the code for KSP2 introduced the bug. Its just a shame that KSP2 when with a solution that's going to have every problem that KSP1's system had with this sort of jank occlusion system.

We kind of do. While vginsights doesn't pull directly from Steam's internal sales information - it does managed to do a very good job of estimating total sales from past experience. I think they have a few developers that are feeding them info and then they can extrapolate from the positions of those games on the sales charts to know what a particular product is grossing, so they're usually pretty close - of course they don't capture sales on other platforms - but those other platforms generally don't make a meaningful contribution to a PC game's sales unless there's a anomalous factor (eg its never going to capture Fornite's revenue correctly.) https://vginsights.com/game/954850

Actually if you check the current dev post, we got just that with a promise of more to come - and most likely due to criticism.

Unfortunately it doesn't work the way you wish it would, it's not very useful. And I'm be 100% ok with people ignoring me if they don't like what I say - frankly I'd prefer that. Plenty do like it.

I think @Meecrob is kidding, that's a $350 dollar card.

@nestor Thanks for the update. Good to hear from someone is is responsible for the velocity! But you shouldn't post so close after mine, people will accuse you of encouraging the toxic individuals.

Probably when low-end integrated graphics chips are being sold that have at least the power & available memory of at least a 1650. I'm sure KSP2's min-reqs will drop some in the future - but not by enough to make today's low-end graphics chips be able to run it well.

They need to start talking about the genuine progress of the feature roadmap, not just bugs. EG: What's the state of science. What's the state of reentry heating. What's the state of other feature work. Also about the state of the team - eg: How many people are actually still working full time on KSP2 nowadays and how many have shifted over to the new project. That is, if they want people to actually have genuine knowledge about what they're buying if they're buying it for the 'potential' vs the 'reality'. And most people bought based off of potential - go read the steam reviews if you disagree - most of the positive steam reviews - especially early on when most of the sales happened - are based off of hope for the future vs the reality of the game as launched. People who actually are getting value out of the game as it is right now, are getting fewer and fewer - this weekend KSP2 didn't even break 300 peak users.

It'll get more optimized as bugs are fixed and performance is addressed - then less optimized as features are added and graphics are improved and those cost performance. Much of the current optimization has been about turning things off, after all. Given how many features are missing - especially multiplayer - and issues with the game's graphical state (terrible AA for instance) - whether or not it will be more optimized than it currently is after(if) those features end up getting added is up in the air.

The reaction to transparency was good initially. It's going to be less and less good if it continues to only be about 10 bugs.

Probably Mortoc is too busy to come back and post about it? His posts were very informative but I imagine he has better things to do.

I'm not trying to abuse any developers. That seems like an extreme position. I'm not saying Nate is a terrible person - just saying his job seems to revolve more about marketting to us. He virtually confirms that, when he's saying his job is about setting goals that may (or often may not) be met than caring about the schedule/velocity. Especially pre-transparency initiative. What I am doing is pointing out that before this new push for transparency, there was a lot of upselling/hyping going on. And ehh - there's still some going on now, but it's better at least. To whit, 6 weeks ago, we're told that the patch is delayed 2-3 weeks, for efficiency purposes. Because, while the 'velocity is good' more will get done if they slow down patches. This was 2 weeks after Patch 2, where people expected another patch in 2 weeks. So Nate was basically saying 'everything is going great, but we're just going to get EVEN more done if we move the patch cadence to 6-7 weeks. 2 weeks ago - 6 weeks after patch 2 was released, when we were supposed to maybe get the next patch - or at least comms that it'll be there - instead we get 'more transparency' but also a clear delay of the patch into June. I applaud the extra transparency, but also at that point, of the 10 major issues they've identified that are affecting players, only 2 fixes being tested (eg, actually possibly fixed) and possibly being fixed (which turned out to need another fix) So if you extrapolate backward - So despite this 'efficiency' post - it's pretty clear that instead, the delay was to get any of the major bugs to the 'being tested' stage. But - you know, Nate won't say something like that. And I don't expect him to - but also noone should expect him to tell us anything that seems remotely negative. Hence my 'Nate upsells' comment - because when you don't post the negative as well as the positive - and you usually overestimate the postive - what else do you call it?

Well it's great to get a direct reply. But... Your words are reasonable taken in isolation, but comparing where you're at to what you've delivered - it's clear that its a consistent pattern of upselling everything. Think back - has there every been a SINGLE thing that you projected to the community that would be done in X time and it was actually done in less than X time? Or was literally everything you talk about delivered late and/or in worse quality than you initially spoke of it in (not counting things that were shipping in a week or two). You say you're communicating 'goals' and you're not responsible for velocity (yet you keep giving us dates). So basically you're agreeing that you are someone who's job isn't to communicate with us accurately, because you will set the highest goal you can and don't really know when it'll be finished. I don't see how that's different from me saying you upsell things. Also - I dunno if you've worked for a manager before that perpetually set unrealistically high goals and then left it up to the team to try and meet them - but it's not a great situation. Is the 'high morale' you spoke of a few weeks more of a goal as well?

Sure the stated reason was it was more efficient. But given the progress they're demonstrating with these updates, the actual reason is that they would have had virtually nothing in a patch of it was released 4 weeks after the previous one. 10 weeks later and they're only patching half the big bugs and have a few engines in as a consolation prize. You have to remember that virtually everything Nate has said or written except very close to an actual release has turned out to be a huge upsell. He's marketting when he speaks to us.

No the PAM also sucks when there's a lot of parts and you have to try to scroll through them all to find the one you need - heaven help you if you have a lot of copies and you haven't memorized all the samey tank names.. Maybe there's a sweet spot at 25 parts, half of them clipped into other parts. :p. Mostly it's just a terrible change that I can only imagine is there because it might work better on console, as it can be hard to pick a part.on a craft with a controller. But given the console release, if it ever comes, is like 5 years away... What's extra scary is that the flight UI was clearly one of the earliest things they did and iterated on - and this terrible design persisted since 2019.

He mentions having 3 engineers working on just one bug in a prior update. Given that - even if the other bugs are only getting one person a piece working on them - and given that these bugs have to be the top priority (not to mention the more minor bugs that are likely to be included in the patch) - do you really thing they have any spare engineering capacity to do anything else? You can see from the slow progress week on week that the bugs here aren't the quick-fix deluge they gave us in the first two patches. It's good that it seems they'll have tackled 5 or 6 of the top 10 after 2+ months of additional work since patch 2 - but it also likely means that science has likely seen no attention from engineering. That's why they're giving us random parts vs new gameplay systems - and why heating, which apparently only needed some polish work 3 months ago, isn't announced for this update either.

Plenty of ways have been discussed previously. To summarize, there's a bunch of ways to give feedback in a way that's more realistic, performant, and interesting: 1. Have a rigid body forces simulation (eg: Polybridge, among many games that do something similar. Many games with far less investment pull this off) that determines strain between rigidly attached parts. 2. Have the parts that are reaching their limits give off some feedback - sound, visual crinkling, etc. Add debug UI or in-game telemetry visualization for more precise info. 3. Just like KSP does now, break up the ship when tolerances are exceeded.

Yeah that's what I was suggesting. Joint rigidity is separate from joint breakage anyway. It's weird they used 4 joints - 2 would be just as good given where they're placed. Three or four with two of them above the other joint(s) would give better stability. That's how KJR does it afaicr. Tbh I don't think they should add wing flex either, given the massive amount of work they have in other places. - but they definitely shouldn't have wings that flop around at their attachment point, that's less realistic than rigid wings. Yet another good reason they shouldn't have used KSP1s jointed parts system, just to keep the 'lol noodle rockets' hilarity that's only funny for a few newbies who mostly drop the game after an hour or two.

My post was two hours ago - and was clearly meant to be a joke. But yeah, we'll see if it lands on the 20th, this far out hopefully their estimates are better than the dartboard.

I guess we'd need to see it in practice, but there's a reason wings are attached on real aircraft to the Wing Box. Not the wing plank, or wing -infinitely-narrow-plane, but the box. Because there's rigidity in all directions. Wings do flex, but not at the root like they're attached to a hinge, but along their span. And in general you've erred FAR too far in the direction of "LOL everything falls apart so easy" so far, according to the majority of the community, so I don't really trust the direction of 'yeah we just want things to fall apart anyway, oh so Kerbal'.

This fix seems like it's only going to address the wings falling off in one direction - from drag - rather than helping with forces in the dorsal/ventral direction. Maybe try triangulating those joints a bit, or you'll just continue to have wings that flap like a bird's. Way to throw QA under the bus for that .1 release.