RocketRockington

Picking the frame right before the fairing tore off isn't an example of 'bending'. It's an example of something breaking off and it still looking like it was attached because you picked the exact right frame to maximize the visual. It wasn't going to snap back into place elastically like a kerbal rocket. The fact that people are going to such crazy lengths to 'prove' wobble is a thing is just a great demonstration that it isn't.

Looks like KSP2 spent a whole 10 days defying gravity. 1.3 + a hot fix plus the sale plus US holidays all combined to give us 10 days of 500+ peak player counts. Unfortunately, that has ended and things are sinking again, though it looks like it might take 4 weeks or so to sink back to pre-patch numbers. Which is a good thing - maybe if KSP2 could change its patch cadence and introduce more content, it could start getting momentum again. Unfortunately of patch 1.4 takes as long as patch 1.3, I think things will get worse before they get better. I am curious what the sales #s were. Vginsights says sales rates were 3-4x higher last week, and there were roughly 2-3 the # of reviews per day.

Next COVID, then delays to science to science mode will be blamed on it.

The great majority of people on reddit and in this forum and responding to this poll all say "Rockets shouldn't wobble much or at all". But somehow, a few people who constantly post in thread after thread supporting KSP2 also uniformly seem to think that the least popular thing is the right design decision. Curious.

I don't think you're owning the people you're quoting quite the way you think you are.

If KSP2 devs can turn releasing a full game soon to releasing an EA 4 years later, then yes, it will be 10 years 'soon'. Maybe we'll have progress on the roadmap soon too.

I have a lot of doubts many of their team plays the game. Chris and Nate yes. QA yes. Former Squad members sure. The rest? Kinda doubt it.

It's because your control surfaces deflect far too fast for the tuning of that PID. You don't want to make the PID too muddy and slow to react - instead you need control surfaces that don't twitch so fast. Try adjusting your control surface deflection rate, if you implemented one, the prior product has one. It'll help with planes being so twitchy under manual keyboard control too. Feels like its currently set to 240+ degrees per second - try something more normal like an actuator speed of 30-45 degrees per second (eg, what KSP has theirs set to)

Ever heard of 'first mover advantage'? Or does it not occur to you that KSP2 is partially failing to attract player counts despite it's license strength and massive budget behind it because it has a prior competitor and isn't doing anything to outdo it - an issue that Juno suffers from as well as having no IP to bring people in and no marketting budget . Your argument here is [snip] assuming that wobble is the only thing that distinguishes them. It's like saying 'why doesn't this generic cola make the profits of Coke, they're both carbonated!'.

Seems you and IG have similar design philosophies, at least until massive backlash forced IG to reevaluate(somewhat) - since they want money.

[snip] Yes, HDRP is just rendering. But that's not what I was referencing when I talked about physics. PQS and CBT are about how you generate the position of polygons for the terrain. Guess what, that includes collision geometry unless you want your craft floating above/embedded in your terrain, you need to have those match up. And they need to be generated at different detail levels due to distance - but you need them to be consistent when you load up a section of terrain that will be inside the physics bubble of a craft. CBT really doesn't fix the gpu bottleneck at all, which is due primarily to badly built shaders that rely too much on interpolating too many large textures and too many conditional statements, so the processing elements are underused because the card is either paging memory or has its pipeline stalled. Which is likely why we'll never see this 'silver bullet' implemented at all, as it doesn't really address the performance issue, and Mortoc has moved on to do other work while leaving the fans stewing over the devblog he wrote while early in his tenure on the project.

Because of the much more serious problems in the game. And because expectations are so low that people hardly notice/complain about stuff like that anymore

Hopefully when other features of the game are released that needed design work vs just being copies of KSP1 or a couple of high-profile mods like waterful and textures unlimited, they won't be as out of touch with what fans would have wanted as the UI and the wobbly rocket decisions. Cross your fingers for science mode.

That by itself makes it unuseable for terrain that needs to be collideable - not sure how they plan to make this a thing when you need to generate physics mesh from it. CBT seems like the KSP version of Star Citizen 'mesh servers' and 'object container streaming'. Something that is an idea, is not a silver bullet, but both the community and the weird hybrid dev/marketting talking heads from CIG promote to keep people on the hook and give the fanboys a hope that all the problems in the project will be solved once the magic tech is implemented. Should. But lighting is not just good or bad because of tech. A lot of the lighting comes down to art/tech art doing well with it. If KSP2 has been waiting with their crappy overblown lighting for 4 years for Unity to solve their problems for them - its just another dumb magic bullet. Especially so since it will require so much work to rebuild shaders and assets. As you know, the problem shader - plantary - won't just come 'for free' from upgrading to HDRP. Again, its more ways to blow smoke and give the people who don't know what they're talking about fancy-sounding buzzwords to hang their hats on.

@schlosrat Ever see that kids in the hall sketch where the guy has intrusive thoughts about putting salt in his eyes? That's PD/TW and DRM - they just can't help slamming this sort of stupidity into the game. Even after they got burned with KSP and redshell - well, now they figure they've already burned all the community good will they can with a terrible launch and terrible progress on getting the roadmap done - might as well see if anything is left to burn with more stupid launchers and DRM. Because heaven forbid you launch a game without them slamming some extra marketting in your face. It's going to be at least two years until they can sell DLC per their promises (which are worth - not much) but they're still gonna try to sell you a bunch of other stuff first!

Lol the one time a fix is applied in a reasonable amount of time...and they also use it to add DRM into the exe so you can't open the game without the launcher anymore. I was all ready to light the fireworks and call for the ticker tape parade, eat some crow for doubting anything ever about this project wouldn't be persistently disappointing. It was like after 4 years of highschool, always getting an F in every class, the school delinquent turned in a paper for a C+. Except it turns out he also got chat gpt to write it. Never change IG/ST/Uber/PD, never change.

A lot of people in this forum posted that they thought it was a good idea that they spent $50 on KSP2 because even with a rocky start, it was going to get better and also because it was going to go up in price. Besides one post buried in a discord by PD Dakota - well after launch - the dev team did not go out of their way to change any impression that was promoted by Nate's statements of the price going up on launch. And I didn't see other people jump in to correct them either, even though now after the fact people are saying it's ok because none of the fine print actually said KSP2 wouldn't do sales, only that on launch specifically the price would go up - even if multiple sales happened before, after, maybe immediately after launch, who knows, anything could be lawyered into being true if you're willing to allow a sale to not be included in those statements. This is a continued pattern where the KSP2 team says things like "We're slaying the kraken" (not T2 marketting, that was a dev) which lead people to think "oh the physics are actually going to be better in KSP2" - something any reasonable person would take that to mean. But after the fact when those statements obvious implications are clearly not true, supporters put on their lawyer hats and now it's always 'caveat emptor ' and 'read the exact letter of what they said, they didn't say we 'slayed' the kraken, it only means that was something they might be doing', yadda yadda. But also those supporters still keep saying say 'trust the devs'. Which is it? Trust the devs, or caveat emptor?

You'd be wrong about that. I think KSP1 works pretty well, and even better with mods. It's the exact same aerodynamics model.

Most every other EA developer would have told us a hotfix for a new bug like the drag issue was incoming already - not that there was just 'discussion' about whether to do a hot fix. It's kind of shady that one of the most-promoted fixes by the team, with a whole devblog talking about how the fix was getting addressed, and multiple updates on its progress, has not just fallen flat, spawning a new bug worse than the original, and apparently they don't even know whether they're going to fix it soon or wait (3,4, 10, who knows how many) weeks to get it into the normal release cycle.

The situations between the two titles is not analogous. KSP1 was genuinely developing and evolving due to player feedback, and due to being a title unlike any other. KSP2 knows exactly what it wants to be, and has been promoting the same set of features, graphics, and UI since 2019. Further KSP going to EA only had about 2.5 years of genuine, small amateur team development behind it - 2 years of that as a viewable demo. KSP2 has 6 years of closed door development by experienced developers. Its like someone picking up a rock for the first time and thinking about how to properly launch it vs someone who already has a blueprint for a catapult and a full engineering team to build it and extra years to test it, looking at the trajectories for both after their throws, and saying it's totally ok that the the rocks went the same distance.

The last two patches, numbers tripled from pre-patch, even without a sale. 1.1 went from ~1000 to ~3000. Lasted about a week and a half. Patch 2 went from 500 ish to 1200+. Lasted about a week and a half. This patch may have a more durable effect both because # were so low pre patch and because the sale has added some new players, but it's a little early to celebrate KSP2 changing direction - you'll also note that for patch 2 and patch 3, # barely jumped to pre-patch player counts from the previous patch. If that holds true - patch 4 may see numbers jump from 100 back up to 300. Patch 5 - 33 back up to 100. Etc.

This was exactly my suggestion earlier in the thread, which was pushed back against. Rendering it constantly would be the best solution - and doable by the GPU. But the current system doesn't render from the direction of airflow, so just using an orthographic cube map of the vessel which would better account for occlusion would still do better than the current solution which uses orthographic per-part and a hack to account for some occlusion.

Them restarting in August 2022 would actually be a good thing - it would mean the pace of dev is extremely fast.

I asked Nertea about that, he said relying on debug information for aero data was a bad idea. Obviously he's not the final call, but its definitely not a sign its coming anytime soon.

[snip] Also this was not the update on science I was hoping for after Nestor's words last week. Oh well - Rule #1 of KSP2 club is always expect disappointment. No exceptions.