A week in... 10% still playing

[J.Random]

3 hours ago, regex said:

I mean, considering KSP1's road to 1.0 (and beyond) I don't think that's entirely out of the question. It fits the franchise.

I mean, you're not _entirely_ wrong. KSP1 had a very rough development and at times developers made asinine decisions. There were phantom forces (leading to Kraken drives) and physical glitches. But I don't recall - ever - saving at KSC just to return later and on load see the game presenting me a scene with one of the previously launched satellites, pretending it's KSC. I can't recall such drastic trajectory changes, where warping to a circularization maneuver I would find ship's trajectory, instead of being hyperbolic, suddenly representing a free fall collision course. The ablility to launch the same ship twice existed in KSP1 since forever. But in KSP2? There is (or was last time I checked) no autosave of the vehicle when you press the "launch" button. So if you try and load previously launched vehicle, you'll end up with a weird half-complete autosaved version of it. Because screw you, that's why. And because devs don't play their own game. At best, they're playing _with_ it.

2 hours ago, Alexoff said:

If the developers do not promise us anything specific, then what should we expect from them?

Pretty sure I said it already in some other thread, but: correct. Don't expect anything. When you're buying an EA title, you're paying the price asked for whatever is available at the time. There is zero (repeat: ZERO, NONE, NADA, ZILCH) obligation to actually finish whatever promised (if promised). You're paying the asked price for whatever is available AT THE MOMENT. End of story. Expect nothing.. And if you don't like it, then don't buy it.

[asmi]

10 minutes ago, J.Random said:

But I don't recall - ever - saving at KSC just to return later and on load see the game presenting me a scene with one of the previously launched satellites, pretending it's KSC. I can't recall such drastic trajectory changes, where warping to a circularization maneuver I would find ship's trajectory, instead of being hyperbolic, suddenly representing a free fall collision course. The ablility to launch the same ship twice existed in KSP1 since forever. But in KSP2? There is (or was last time I checked) no autosave of the vehicle when you press the "launch" button. So if you try and load previously launched vehicle, you'll end up with a weird half-complete autosaved version of it. Because screw you, that's why. And because devs don't play their own game. At best, they're playing _with_ it.

I've seen all of that - and some more - in KSP1 back in the day. Save file corruptions, orbits going bananas, unability to load crafts you've just saved, subassemblies have been causing problems for what seemed like eternity, getting locked up without ability to do anything except for Ctrl+Alt+Delete and force shutdown KSP process. Or, and crashes. No - CRASHES. It was only after about 0.90 that KSP1 has become somewhat stable when stock, but if you start adding mods (and KSP1 circa 0.90 was not playable for me without mods due to soupodynamics instead of aerodynamics, so - in FAR we trust!), it quickly becomes a excrementsshow when even aspects not touched by mods become unstable, even parts-only mods often made game shaky. No need to whitewash the history - there is plenty of people who still remember how it actually was in reality (and there is a ton of evidence on Youtube), and it was far from great to put in mildly, often bordering on rather desperate.

Edited May 9, 2023 by asmi

[RocketRockington]

12 minutes ago, asmi said:

Or, and crashes. No - CRASHES. It was only after about 0.90 that KSP1 has become somewhat stable when stock,

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.  

[Bej Kerman]

1 hour ago, J.Random said:

I mean, you're not _entirely_ wrong. KSP1 had a very rough development and at times developers made asinine decisions. There were phantom forces (leading to Kraken drives) and physical glitches. But I don't recall - ever - saving at KSC just to return later and on load see the game presenting me a scene with one of the previously launched satellites, pretending it's KSC. I can't recall such drastic trajectory changes, where warping to a circularization maneuver I would find ship's trajectory, instead of being hyperbolic, suddenly representing a free fall collision course. The ablility to launch the same ship twice existed in KSP1 since forever. But in KSP2? There is (or was last time I checked) no autosave of the vehicle when you press the "launch" button. So if you try and load previously launched vehicle, you'll end up with a weird half-complete autosaved version of it. Because screw you, that's why. And because devs don't play their own game. At best, they're playing _with_ it.

There's no way you don't remember KSP 1 pulling way worse, especially when you involve mods where half the love that ends missions is trying to wiggle your way through the issues caused by 50 different mods made by at least 50 different programmers, on top of the base game.

[cocoscacao]

39 minutes ago, RocketRockington said:

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. 

I am just curious where you find all that data. Correct me if I'm wrong here. Doing a quick research, Felipe Falanghe did study game design. No prior experience on the job, sure, but most of the things I do today, I didn't how to do 2 years ago. Programming is programming. Judging by dev videos from 2020, things add up somewhat.

Haven't googled how many devs are working on ksp 2.

I highly doubt they could've a reused lot of prior code due to new game mechanics. I'm amazed that what we have now is even possible, but that may be my ignorance.

Also, here's an interesting video regarding ksp 1 development.

[RocketRockington]

2 minutes ago, cocoscacao said:

I am just curious where you find all that data. Correct me if I'm wrong here. Doing a quick research, Felipe Falanghe did study game design. No prior experience on the job, sure, but most of the things I do today, I didn't how to do 2 years ago. Programming is programming. Judging by dev videos from 2020, things add up somewhat.

Haven't googled how many devs are working on ksp 2.

I highly doubt they could've a reused lot of prior code due to new game mechanics. I'm amazed that what we have now is even possible, but that may be my ignorance.

Also, here's an interesting video regarding ksp 1 development.

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.

[cocoscacao]

11 minutes ago, RocketRockington said:

Overall though - you often demand a lot more proof and logic in arguments than you give

You're free to ask it back

[RocketRockington]

16 minutes ago, cocoscacao said:

You're free to ask it back

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?

[cocoscacao]

4 minutes ago, RocketRockington said:

Why are you amazed

Uhm, yeah. I kinda written that post in a bit of a rush, so specifics are left out...

I was mostly thinking about the ability to burn under time warp. I'm far from being expert on the subject, so anyone who has more info, please enlighten me.

I guess there's a reason why KSP 1 had 4x time warp limit with physics on. Simulating engine burns sounds like a freakishly heavy computational task, especially when you include recalculating orbits. That part was probably overhauled, and I'm genuinely curious how they've accomplished it.

[AtomicTech]

[snip]

2 hours ago, cocoscacao said:

I guess there's a reason why KSP 1 had 4x time warp limit with physics on.

You could use BetterTimeWarp and push it further; I've found it to be mostly acceptable.

Edited May 10, 2023 by Vanamonde

[Bej Kerman]

[snip]

I'll take their comments about Nate seriously as soon as they show their own no-doubt impressive Linkedin page. Until then, my prior comment goes without saying.

Edited May 10, 2023 by Vanamonde

[AtomicTech]

Just now, Bej Kerman said:

I'll take their comments about Nate seriously as soon as they show their own no-doubt impressive Linkedin page. Until then, my prior comment goes without saying.

I'm aware of that, my comment was that perhaps we should try to remain civil in this thread, rather than starting to make particularly, shall we say, insensitive comments.

[cocoscacao]

5 minutes ago, AtomicTech said:

You could use BetterTimeWarp and push it further; I've found it to be mostly acceptable.

I've used it. I don't remember if it allows bigger time warp with physics on, and I don't know if trajectory precision suffers on larger time warps. This must be absolute top-notch polished feature, if we're getting interstellar.

[AtomicTech]

1 minute ago, cocoscacao said:

I've used it. I don't remember if it allows bigger time warp with physics on, and I don't know if trajectory precision suffers on larger time warps. This must be absolute top-notch polished feature, if we're getting interstellar.

Definitely.

I know that I often loose control of spacecraft during high-level timewarps through the SAS freaking out. A stable, large time warp engine will definitely be required for interstellar.

[Gotmachine]

39 minutes ago, cocoscacao said:

I guess there's a reason why KSP 1 had 4x time warp limit with physics on. Simulating engine burns sounds like a freakishly heavy computational task, especially when you include recalculating orbits. That part was probably overhauled, and I'm genuinely curious how they've accomplished it.

The answer is that they didn't kept the "physics on". The only thing preventing running at arbitrary timewarp speeds with engines burning in KSP 1 is that joint/RB physics are unstable at large timesteps.
There is no additional computational cost to running at large timewarp speeds. The game engine is still running at 50 ticks/second, which mean that at 1x timewarp, each tick is 1/50 = 0.02s.
To accelerate time (ie, timewarp), you instead pass a higher elapsed time (the "timestep") for each tick. For example, if each tick is 0.08s, that gives you 4x timewarp. If you pass 20s, that gives you 1000x timewarp.
The underlying difficulty is that whatever subsystem runs in each tick must behave consistently whatever timestep you feed it. In KSP 1, most systems are actually designed to accept that.
However, RB/joint physics simulation stability is heavily timestep dependent, that's why vessels have a higher probablity of experiencing instabilities in phys-warp in KSP 1.
KSP 2 isn't different in that regard, what they did is just disable physics when timewarping, and are directly summing the forces resulting from engine thrust to compute the frame displacement (ie, the vessel acceleration).

[Superfluous J]

13 hours ago, RocketRockington said:

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

I find it funny that people who think they've been lied to by the entire dev team for the past 4 years still want communication from the dev team, as if you'd believe anything at all they said.

[RocketRockington]

5 minutes ago, Superfluous J said:

I find it funny that people who think they've been lied to by the entire dev team for the past 4 years still want communication from the dev team, as if you'd believe anything at all they said.

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.

[Vanamonde]

Some personal comments removed. Keep it polite. 

[Alexoff]

9 hours ago, J.Random said:

You're paying the asked price for whatever is available AT THE MOMENT. End of story. Expect nothing.. And if you don't like it, then don't buy it.

It's good that T2 decided for me and forbade everyone in my country to buy this early access

[cocoscacao]

7 hours ago, Gotmachine said:

KSP 2 isn't different in that regard, what they did is just disable physics when timewarping, and are directly summing the forces resulting from engine thrust to compute the frame displacement (ie, the vessel acceleration).

Yeah, but I'm assuming that TWR changes with each passing tick (fuels consumption -> less mass -> larger TWR). That would imply that burning with/without timewarp will produce different orbits. The bigger the warp, the bigger the difference. Right?

Unless, as you said, underlying subsystems have to remain consistent. I don't know if orbit calculation is one of those systems.

I forgot if this is the case in KSP 1, and I'll have to retest KSP 2 again.

[Mantarochen]

2 months in, with ~380 players at peak a day still playing, the devs "slowing down the rate of updates" and the previous 2 patches being a joke in terms of actual fixes, even patching in some more in some circumstances... 

-How is anyone still defending this piece of turd? I mean for real. 

I understand how everyone was hyped when the game released, even when it was buggy, because "it will get fixed". But at this rate? 

How long until take2 cuts losses? 3 months? 6 months? 

With the current trend in player numbers, the game will probably have peaks of ~100 players by then anyway. 

 

Sad to see such a (potentially) fun game with promising features go down the drain because of the clusterlove the development has been. 

Edited May 10, 2023 by James Kerman
Reinstated by a moderator

[J.Random]

7 hours ago, Bej Kerman said:

There's no way you don't remember KSP 1 pulling way worse, especially when you involve mods where half the love that ends missions is trying to wiggle your way through the issues caused by 50 different mods made by at least 50 different programmers, on top of the base game.

Oh, I remember KSP issues. But you do understand that this unironic comparison of yours is kinda ridiculous, right? On one hand you have a supposedly AAA sequel from a game studio led by somebody with a couple of decades of experience, bankrolled by a huge publisher, and, as claimed, building on top of previous success, taking into account all the previous errors and so on, on the other hand there's an actual indie game from a tiny inexperienced team, originally a single dev, branched off from an ad agency. And you had to add the "50 conflicting mods" strawman to the latter and, imo, still failed to make the comparison even remotely favorable towards KSP 2.

[RocketRockington]

3 hours ago, cocoscacao said:

Yeah, but I'm assuming that TWR changes with each passing tick (fuels consumption -> less mass -> larger TWR). That would imply that burning with/without timewarp will produce different orbits. The bigger the warp, the bigger the difference. Right?

Unless, as you said, underlying subsystems have to remain consistent. I don't know if orbit calculation is one of those systems.

I forgot if this is the case in KSP 1, and I'll have to retest KSP 2 again.

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.

2 hours ago, Mantarochen said:

-How is anyone still defending this piece of turd? I mean for real. 

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.

[Alexoff]

It seems to me that some people have firmly connected KSP and developers in their heads. they believe that if someone scolds KSP2, then this is a blow to the franchise. On the contrary, I think that it was the developers, together with T2, who dealt a terrible blow to the KSP. In my understanding, they just used the fans and the franchise to make some free money. It most likely failed

[cocoscacao]

1 hour ago, RocketRockington said:

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,

I'm not sure if it can be solved analytically. Also, I doub't dV has anything to do with it. dV is constant (mostly). Only TWR changes, which effects how fast trajectory is changed between "engine ticks".

Edited May 10, 2023 by cocoscacao