RocketRockington

That's going to be an issue even if they fix their joint settings and implement something like KJR to increase rigidity - it's just the way the PhysX relaxation solver works. It does a number of constraint relation substeps for each tick of the physics system to resolve the joints and other forces to a good state. Think of it kind of like how when you shake a string, it takes some time to stop wiggling and relax back to whatever position its going to settle in - basically all the joints are taking their current state, and iteratively moving toward a more 'relaxed' state where the forces are in balance. Even when those joints are supposedly to be simulating rigid metal or w/e, under the hood PhysX still considers them to be springs. However, the less steps you give it to relax, and the more forces you're applying to the system in the meanwhile (thrust, collisions, aerodynamic forces) etc, the more wiggly things get because the vibrations between the joints don't ever have a chance to settle. This is something that KSP2 CAN'T get around because of the design choices they've made. ( mostly in sticking to exactly how KSP1 did it, but with worse tuning). They decided 'nope, we didn't learn anything from KSP1, and we're not going to bother trying another solution, we accept all the issues'. So they have to turn physics off at high timewarp, just like KSP1 did.

Par for the course for how productive most of these threads are though

I looked up the time for version 0.9 not 0.90, no need to be so blatantly rude about a very simple mistake. Nonetheless, still less time and far less development investment than KSP2 has had. Also KSP 0.90 was far far more feature complete than KSP2 is.

That's what I mean by 'solved analytically' as well. And why I was telling cocoscacao how to use the rocket equation to avoid issues with the time step. As for change in position while accelerating ( both due to gravity and due to the rockets acceleration) that is also solvable for a simple gravity field. It has to be solved numerically for n-body situations, but KSP2 doesn't do n-body, and I doubt it ever will - even when they do Rask and Rusk. Not just because you now have to build a totally different motion sim, but also because now you have to teach people new UI for examining their trajectory.

It can absolutely be solved analytically. Have you never heard of Tsialovsky's rocket equation? That's one of the things it's for. But instead of using the change in mass from a full rocket stage to an empty rocket stage, when you're computing total dV, your using the mass of the rocket at time t0 vs the mass of the rocket at time t0+1 tick, based on the mass flow rate of your engines and their ISP, to derive dV (change in velocity) for one tick's worth of acceleration. And change in velocity is precisely what you want to know.

The answer is 'depends how well the devs coded it' and 'how much will the player notice anyway'. For instance, if the developers coded a very lazy numerical integration eg: they use the TWR at the 'start' of the timestep for the whole timestep - you could definitely have divergence at high time warp . However, if the developers coded it well, the solutions for how much dV is produced by engines firing constantly and draining tanks constantly can be solved analytically, rather than numerically, so you can get a perfect dV change regardless of the timestep involved, as long as you account for edge cases like 'the engines will stop firing during this timestep'. And that's not actually that hard, compared to other things KSP does - for instance, when they implemented a Lambert solver for the 1.12 feature, the same stuff that calculates porkchop plots for Mechjeb's advanced maneuver planner. The other question is 'will you notice' Now, of course if you're using a low-ISP engine where that 20s timestep is a meaningful fraction of the full burn time, and they did a lazy implementation - then yes, you'd definitely notice, though you may be more wondering 'how did I screw up my burn so badly by trying to move my time acceleration to 1000x for a 30s burn'. But even with the lazy implementation, it won't be meaningfully divergent to do 20s timeteps vs .01s timesteps vs the analytical solution if your burn is an ion engine firing for 12 hours. Some people are fixated on forum combat and/or doubling down on their calcified opinion from when the hype was building. Its like a religion at this point, I think, an article of faith that the devs are good and naysayers are bad. Standard human psychology, developing in-groups and out-groups, and then doubling down when your in-group is threatened by outside ideas.

I actually haven't asked for more comms from the devs, I don't expect them to make a Uturn away from marketting-oriented falsehoods and PR comms and start acting more like old school Squad. Some have of course, but it's generally been caveated with 'thats actually honest and consistent this time'. I know that's never going to happen however, and I've said so before.

Ok, that's fair! Why are you amazed that what we have now is even possible then, when it was done before by far fewer people in less time, working from scratch rather than from a prior game as a template?

So running from the top: Just because you studied design doesn't make you an experienced programmer/artist/designer. Nate, for instance, according to his LinkedIn has been working on games for 25 years. Are you claiming experience has no value at all? I mean, based on the results of KSP2, I'd have to agree, but normally experience does have value. Also your 'programming is programming' thing makes no sense. There are a variety of talent levels, and having prior knowledge of developing certain systems - physics, graphics, etc, is relevant. Sure if you're doing very basic programming work, a lot of it is similar but then you might as well say 'work is work'. You can find a low-bar of how many devs work at intercept by looking at their linkedin page for the company. It was 46 last I looked Note that some developers - like Nate and the QA team in Las Vegas - actually work directly for Private Division, the publisher, though, so an exact count is difficult - it's likely higher than 60 now with the extra QA. @Gotmachine , who is a very experienced modder in the KSP1 community, inspected (euphemism for something that we can't speak of) the executables for KSP,2 and found that many places reused the same algorithms, though things like namespaces changed. When I say 'used the code' I include adapting a copy, not just direct cut and paste, which is still a huge time saver when you're not having to code up orbital math equations from scratch, or figure out how to do aerodynamics. Overall though - you often demand a lot more proof and logic in arguments than you give, it's not a good look when you complain about others doing the same thing.

I love how you're comparing a game developed for 8 months (at that point) by 1.5 developers with no game dev experience, from scratch, and saying it's only *similarly* stable to the game developed by 50 developers for somewhere between 3 and 6 years, using a bunch of code prior code and (if you use the short timeline) the lesson of what not to do when they mucked it up the first time. You're right though - saying that KSP1 was never as unstable - if you dig back to the time it was a free pre-alpha demo to toy with - as the $50 hyped and marketed release by Intercept is untrue.

The difference is only how you evaluate the things the devs say. I find it funny that some people here are perfectly ok with the idea that the devs were lying through 2019 through 2022 but take what the devs, Nate in particular - say now at face value, and tell others they're doomers for not trusting the devs - when there is extremely good reason not to trust them. Of course if you're asking in more.of the general ' what does it matter even if the devs are lying, the game is the game', then I guess just refer to its present state, where it keeps losing active players. It does matter if you are thinking about KSP2s future though.

@LyneiraI mostly agree with all of your points. However in terms of unbroken promises, I'd say KSP2 did do quite a few of those. Eventually they backtracked from them and people's memory is often short, but until it was painfully obvious that they would have to ship, and what they had to ship, they continued to sell a party line that delays were for improved quality( implying improved over KSP1, not improved over a dumpster fire), that the game was going to outshine KSP1s stability, physics system, and gameplay, and that everything was going smoothly with production, that delays were just due to expanded scope or one-off events. There was no indication during these delays that the play was to ship a shoddy EA/tech demo. I don't, at all, trust Nate Simpson's positive outlook on anything, after comparing his words to what was built, and the time frame involved - he strikes me as very similar to Sean Murray, with the exception that Sean didn't get the many extensions that Intercept got. No man's sky got only weeks worth of delays - imagine what Intercept would have shipped if they had to stick that closely to the 2020 deadline - or heck even the 2022 deadline (pre-EA announce). No, the only thing that saved Nate from being an even bigger demonstrated prevaricator than Sean was all the extra time - something no studio can absolutely count on.

It's not even that NMSs game loop isn't something I enjoy - I enjoyed all those activities in a variety of games, especially in Minecraft. First of all, it was that this purportedly sandbox style game felt like it needed to drag me through its systems with a hook in my nose in unfun ways. No nice 'take it at your pace' branching questing like you might see in certain Minecraft mods, it just felt forced on you in a linear and banal fashion. Add that to how unpolished most systems, especially the UI was- it was just a joyless experience. I did like the look of the procedural planets, but unfortunately I know too much about proc gen systems to be really amazed by what's in NMS, that part is on me to some extent.

Yeah ditto. I tried to get I to NMS a year or two ago because of how many people were saying it's awesome now... It was one of the most awful new player experiences I'd ever had, the 'tutorial' was hours long, incredibly boring and the UI was painfully unintuitive and cumbersome for what I was being asked to do : simple crafting and mining and equipping things to myself and my ship - solved problems in other games, not rocket science. It felt like a hodgepodge of disconnected features thrown together and half-finished. One of the reasons I'm so against KSP2 is not because I don't think it will get better - it will, given time, if it keeps getting funded, it can hardly get worse. But better is still not good. It's just a horrifying shame how much potential was lost, and what people will eventually accept as 'good'.

Your advice about making valid points and adequate counterarguments here was good.

Thier past slow development to date, as I spoke of in my post. What proof do you have that they are making good progress?

I'd like enough procedural randomization to offer good replayability. That and something more like Kerbalism,.ideally leveraging resources or the colonies to extend the variety. I'm concerned that science is coming out standalone, but that's the world we're in with their roadmap. Either the first version will be lesser by not involving the other game loops - or we're still going to be in another wait-and-see limbo as Intercept tells us that the science system, even once released, is still placeholder and 'just wait some more, promise, it'll be better in the future'. So I guess I hope it's just one good concrete feature by itself, even if it would have been better to leverage other game elements.

As much as I'm also dissatisfied with KSP2, try to get your facts straight. It's only been out 2.5 months. And we do sort of have a next patch date - somewhere between 6-7 weeks after the last patch (Nate said they're adding 2-3 weeks more, and patch 2 took 4 weeks). So next patch at the end of May, if he's to be believed.

I have this suspicion as well. No way was project management on Intercept communicating the true state of the game to corporate when corporate started and then had to quickly pull a marketting campaign. I suspect that similar things happened at Star Theory - it's not uncommon actually for a developer to oversell the state of the game to a publisher. It's somewhat uncommon for the publisher to discover it and then re-entrust the same project to the same project management again. Someone at PD or T2 was way too trusting or gullible, I'd guess. But the devs don't have to look at star citizen for an answer - KSP1 has a good public bug tracker which Squad used and actively managed. I think it's even open source! I'm sure @nestor has recommended it.

I think it's being realistic. Science, the first step in their roadmap, and the least technically challenging, is going to be at least 5 months post launch, at the earliest, due to their new release cadence and science clearly not coming to the next release. More reasonably it'll be 6 or 7. 6 months per roadmap update puts them at 2.5 years from 1.0. 2.5 years is within the ballpark of calling it a 'few' though if you want to quibble over it being also 'a couple' you can argue that. (I won't bother to reply) Pessimistic would be saying 'never' since the odds of it failing to get to 1.0 are not trivial - but I think there's a chance they'll do a console port even if it never gets to 1.0, due to $$$$. Maybe they'll call it console EA lol.

FTFY.

Lay off the sarcasm. Darrin mentions multiple places to post bugs, just because it's not your preferred location doesn't mean it's invalid - and last I checked, no one from the dev team is marking bugs in the bug subforum as reviewed or addressed either, they're just as much of a blackhole as discord or reddit or private emails or smoke signals at this point. Yet another reason a public, one stop shop bug tracker would be a good idea.

@Strawberry Yeah of course we're speculating here. Maybe science will be this amazing experience that justifies the time investment. However, two things make me doubt that immensely. First, every time Intercept has done this "We just need time, trust us" they've either come up with new reasons for further delays, or they've released something awful. Second, they don't hold their cards close to their chest Anytime they've got something remotely good already, they've posted it as some screenshot - I can't think of a single meaningful thing in the game that was launched in February that was not shown off months or years ahead of time. (Except how buggy it was lol they waited till the ESA event for that ) Squad used to only show previews a couple weeks before release to make sure they were actually going to be able to release what was promised - Intercept has shown bullshots of colonies and interstellar stuff that are unlikely to make an appearance for 4-5 years after they were previewed. This indicates to me that thier velocity w/regard to getting science, the first step of the roadmap done is abysmal, as they have nothing worth showing yet, when they should already have a version ready to go if their pace was actually good.

I know you meant this in jest, but John Coding (or many really good programmers I've known) would have Science mode - at least a functional version - finished in far less than 3 months - because it's really not that tall of an order, technically, especially if many of the assets are done. Don't believe me? Read what dropped in KSP v0.18( which added science mode) which was only one month after the prior release, with a smaller team than SoTF and much much smaller than KSP2. Every impression we've been given is that science is not in the next update, which now has an ETA of 3.5 months after launch. If it's in the update after - that'll be 5 months in. Or maybe it'll be the one after that.. who knows. All we do know is that the first two updates only fixed bugs, didn't address enough to satisfy the community, and that the creative director thinks slowing down further is still a good pace.

@Strawberry looking at bug counts fixed is not an interesting metric, I'm sure you'd agree. How severe the bugs are, how many bugs there are to fix, how much low hanging fruit/easy fixes were available, team size, etc, are all factors that can't easily be rectified against other games. What Sons of the Forest is managing though is to keep its community happy and interested, which is reflected in its reviews. It's in the survival genre with many competitor titles - KSP2 has almost nothing but KSP1 to compete against and is failing even against it's predecessor. When Nate says the KSP2 velocity is good - that's purely laughable because we can see that not enough is being done. The many failed deadlines and launching in such a shoddy state shows that even by the metrics of their own development priorities, velocity hasn't been good. Further comparison against what Squad was managing to do in similar time frames with a much smaller team and no prior art/borrowed code to crib from just further demonstrates this. So in what world is their pace of development good.