asmi

That's a lousy argument because KSP has been released via their website long before it appeared in Steam.

[snip] If you need integration - you can't have large timesteps. You can't have it both ways. Worst case is large timestep and tight orbit - which means your vessel is supposed to on the opposite side of celectial after that step. Or maybe even in the same exact spot (relative to the orbiting celectial of course, not in world coordinates). That gives you exactly zero information about possible collision course. At large enough timestep those spheres will be so enormous that you will have to do subsampling pretty much all the time. Which is one of the problems I listed initially. At large timesteps that sphere will be so huge that it will encompass close to entire SOI of a celestial you are orbiting. And the reason the sphere has to be large is to account of orbital motion because that timestep can cover a significant portion of an orbit (or even several orbits). This is the same reason you can't use naive linear propagation integration (S1 = S0 + V0*dt, V1 = V0 + A*dt in vector form of course) to model the orbital motion because this way you will get nonsensical resutls like violating the laws of concervation of energy. This is the sort of thing that KSP1 was doing back in the day, which is why orbits of active vessels were always dancing around - well it was one of the reasons, other included phantom forces from the physics engine. And if you do that, you end up with doing subsampling pretty much all the time at large timesteps, which effectively means that you can't do a large time steps at all. And we're not even talking about such large timesteps - even for low Earth orbit it takes only 90 min / 2 = 2700 seconds to end up on the opposite side of the planet, Kerbin being 10 times smaller this number is even less (20 min / 2 = 600 seconds? I don't remember the period of LKO of top of my head). If we assume "normal" physical timestep of 1/60 seconds (I think that's Unity's standard), that's about 36000x time acceleration. Given that in most saves there is always a metric ton of stuff in Kerbin orbit (from spacestations to comm sats to spent stages and all kinds of other junk), your algorithm will always indicate possible collisions. ------------------ [snip] this collision business is just an example, and I'm personally much more interested in modelling subsystems aboard inactive vessels (like power, comms, ECLSS resources, etc.). THIS is where stuff gets real, and, what makes it worse, there is no big body of academic research like one which exists on a topic of orbital motion, so you are pretty much on your own. [snip]

That's not how rocket engines work. They provide fixed thrust (==force), but acceleration is always changing because vessel's mass always decreases We can't know it because we don't know what the trajectory is going to look like as the burn is underway. Also imagine if there is an SOI change somewhere during the burn? That is also absolutely wrong because, remember, ships are moving along orbits, and not just in straight lines. And orbital motion presumes that there is always a non-zero acceleration. ------- I'm not trying to pick on your, what I'm trying to demonstrate is that things are a lot more complicated than they seem to someone who never actually done such things before, and intuitive solutions turn out to be totally wrong. And this is not even considering that in reality there is always more than one celectial body affecting the orbital motion of vessels. Something for which there is no analytical solution at all (at least as of this moment), and the only way to faithfully simulate that reality is by doing many, many, MANY iterations. There is a lot of academic research on that topic, and there are ,any clever solutions, but all of them are based on iterations, and are not analytical (meaning there is no function which would allow calculating position of a vessel at arbitrary point in time based on certain initial conditions (position vector, velocity vector).

There is a reason I said it's just an example. Now remove word "collision" and substitute "possibly ran out of resource", "solar panels might enter shadow", "possible comms blackout", and so on, and so forth. Also remember than space is three-dimensional, and not one, like it was in my example, or possibly four-dimensional once you add multiplayer with it's separate timelines - and the solution becomes significantly more involved, and perhaps even impossible unless you hand-wave away most problematic parts.

That's the problem - often you can't find this out unless you do subsamples. I gave the very simplistic example to demonstrate the kind of problems which can occur, in reality most physical phenomena are not linear, and so you can't use simplistic approach "it was in front, now it's behind - therefore a collision is possible, so need to do subsampling" because you end up subsampling all the time.

As someone who attempted to implement a mod for KSP1 which would do something like that to inactive vessels, I absolutely concur. I had to make a lot of simplifying assumptions (though to be fair some of those were caused by the way KSP1 handles inactive vessels), and yet still I had a virtually endless list of edge cases I had to handle somehow. If KSP2 is going to use the same data structures to hold all vessels (active and inactive, remember that everything in KSP1 was a "vessel"), this might make implementing such things somewhat easier, but the fundamental problem is this - a lot of physical processes don't have analytical solution f(dt) (which would make implementing timewarp trivial as you can simply pass large dt and get an end result), but instead rely on iterative algorithms, and this is a serious problem because if you make timestep too large, you begin missing certain events. Simple example to demonstrate the problem - imagine you have two vessels 100 meters apart flying at a speed of 100 m/s directly towards each other. If you have a timestep of 0.5 sec or less, you will realize that they are going to collide 0.5 seconds later, but if your time step is larger than that, you will not see a collision at all - instead vessels with simply appear to fly away from each other after a single time step. This might sound very familiar to those of us who were playing earlier alpha versions of KSP1.

I fully agree with you, but my big corporate experience also reminds me that liquiding against the wind and biting the hand that feeds you tend to not end well for people doing it if you know what I mean. That would be the reason #0 in my experience. Or, even worse, spam nonsense/intentional falsehood in all fields. Every public project I ever worked on had some of those, there aren't that many of them, but even a single one can do some serious damage.

You don't HAVE TO, but if you want to help them track down the issue, you can. There is no way to know if the bug is already known or not unless some investigation is performed (results of totally unrelated bugs can appear the same to a user - for example all crashes to desktop look the same despite a myriad of reasons which could've caused it. Also, sometimes the single root cause can manifests itself in different ways, and one of those ways might be easier/more convenient for developer to investigate than originally reported repro (it's not a secret that QA engineers tend to overthink use cases while having a blind spot for obvious cases). Finally, even if the bug you've submitted is confirmed to be known issue, the fact that you reported it might change their calculus regarding priority of a fix - it's one thing if a bug appears to be one-off and was never seen again by QA team once logged initially, and quite another if multiple users report it as well.

The game might be unstable at that point and will collect totally bogus data. Or the code that does the collection might itself cause problems and/or has bugs. It's a classic problem in development - you introduce code which intends to watch out for problems with your "normal" application code, but when a problem occurs, you can no longer be absolutely sure if it was caused by your application code, or by the code which looks after it, or by some sort of interaction between both. The only code which is guaranteed to never cause any problem is the one which doesn't exist.

You seem to have serious problems with your memory (or you distort the history on purpose to fit your narrative) . It took over 3 years from the first public KSP1 version to 0.90 (a.k.a. Beta) - sepcifically from June 24th, 2011 to December 15th, 2014. And there were more than 1.5 developers (though likely significantly less than what IG has). I've purchased the game on November 17th, 2012, when it was on version 0.17.1, and 0.18 followed shortly after that which added docking, I also had interactions with pretty much all devs and Squad's QA leads as I was a somewhat active participant of experimentals at the time.

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.

Then you shouldn't expect anything.

My problem is always the limited time I have to play games, not lack of games. So I bought KSP2, played a bit, and shelved it until some "better times". Just like I did to a considerable amount of other EA games, and insidently, a fair amount of them I started playing again several years after my purchase, and they did grow into much better shape than I remember them being when I initially purchased them. Of course, there are some in the list which did turn into abandonware, but that's the risk I've been willing to take when I made my initial purchase decision.

I personally participated in KSP1 experimentals for a while, so that is not exactly true. Also all major modders were given access to experimentals as well, so there were quite a number of people participating, and altogether we squashed quite a lot of bugs.

Maybe as the middle ground they would consider opening a public beta program, which would make a new build available before it was checked off by their QA to those interested to try out new things and report issues back to developers for quicker turnaround? Of course those volunteering mush understand what they are getting into and accept all risks associated with running pre-pelease (and perhaps more heavily instrumented to make debugging easier) software, but this approach has been used by a few games I played and as far as I can it was very successful as long as developers were willing to investigate those newly found issues and see if they can provides fixes quickly. Just a few weeks ago I participated in X4: Foundations beta program for their new version 6.0 release, and devs successfully squashed A LOT of bugs and issues during this public beta problem. So this approach can be absolutely made to work wonders if both sides (devs and volunteers) are ready to contribute their share.

How do you know what was/is important for them?

Actually I think this would be fairly easy to implement - think of it like a meeting via MS Teams or something like that, when one person is controlling the VAB, and the rest are watching, with ability of "organizer" to temporarily pass control over to someone else so that he/she would be able to assist. If you couple it with a voice chat, I can totally see folks collaborating like many do during meetings at work for example. This would be a killer feature for EDU version of KSP2 if it ever sees the light of a day.

One obvious problem with multiplayer in such long game I see is that it will be very difficult to coordinate your friends to actually play for any prolonged amount of time, because we all have our lives, families, kids, etc. I had no end of coop game sessions in, say Supreme Commander, which were cut short because something came up for one of us and we had to either continue without him, or abandon session alltogether. Infact I seem to recall that only about 30% of your game sessions were ever played to conclusion. And that is the game with an average session duration of perhaps 1.5-2 hrs. In KSP1, when I was yonger and had more free time on my hands then I knew what to do with, I used to have 6+ hrs long sessions, but now there is absolutely no way I can ever organize anything even remotely as long as that, especially in a sandbox when you typically don't have a set end goal you need to reach in order to "win" and conclude the session. With that said, the selfish part of me would rather see some other features implemented instead of MP, but since other people seems to want it, I'm OK with it being a thing, as long as it doesn't substantially limit features I do want to see in game.

But that's not the argument you used. You said it has to be there just because it was there in KSP1.

Why? Have they ever said that every single KSP1 feature would be in KSP2? I don't remember them saying that.

Cheaters beware!

As long as there are enough reasons to travel to those 2-3 planets, it won't be boring.

I doubt they know this upfront, usually you only find out these kinds of things with any certainty once you actually implement them - at least in the form of prototype. But let't be realistic - KSP2 isn't likely to ever run well on potatos, at least until it's 1.0 feature-complete because ugly low quality screenshots don't sell the game - for that you want the maximum amount of eye-candy, and so I have reasons to believe that their focus will be on a midspec and higher configurations. That's not to say that performance won't improve on lower-spec configs at all, but it will likely be a side effect of overall improvements.

It's not that I don't trust him, I'm just more interesting in technical aspects of the game, rather than listening to the same marketing bullet points for umteenth time. As for this interview, I liked that interviewer did not get in the way of a person he's interviewing and let him speak freely without interrupting. Way too many of interviews with bigger interviews look like a single phrase of the interviewee following by minutes of interviewer's "smart thoughts" (or so they think) which nobody cares about because people listening to the interview want to hear what intervewee has to say, not smartass notes and grandstanding of interviewers. But like I said above, some of those interviewers are so full of themselves that they can't handle not being in the focus of a video - and the bigger those interviewers are, the more ugly and pathetic this tend to look. In that sense this was a great one, all too rare nowadays unfortunately.

ADDED: I wish they would make somebody more technical available for the interview with perhaps some of current or ex-modders to go a bit deeper over technical aspects of the game. I remember for KSP1 there was like an hour long presentation "decomposing" KSP into subsystems and explaining how they work, it would be of immense interest to both current and aspiring modders in the current environment of total lack of documentation, and since engineers are known to hate writing documents, such interviews/presentations would be the next best thing.