asmi

With higher TWR you lose a lot for aerodynamic drag, as it's ~v^2 (ignoring Mach effects, which would make situation much worse). You also have higher aerodynamic load on your vehicle (read - you have to pilot it much more carefully as smaller deviation from +VV will be enough for RUD to occur), and higher heating of course. This is why most RL launch vehicles have liftoff TWR of 1.1-1.3.

That was only comedy for the first couple of times, beyond that is was just annoyance. Definitely not miss that crap.

This is actually the way it works in real life. It's all about heat flux, heat shields can only absorb/dissipate so much of it, once it's overpowered, things go south really quickly. Most people think that reentry heating works kind of like frying pan on a stove - it slowly builds up the heat. And it's hard to really blame them, as most people don't really have experience dealing with high heat flux. In reality it's more like aiming a 3000+°C welding torch into the middle of a said pan - the torch provides much higher flux than pan can wick away and dissipate, and as a result you will very quickly have a hole in the middle of the pan. The only unrealistic part of it is that in KSP (both 1 and 2) there is a hard cut-off of the atmosphere, while in reality it's very gradual, if you watch some of RL reentry videos, you will see that windows get charred waaay before they feel any significant G-load. This whole dynamics is actually pretty accurately modelled by late versions of KSP1 (if my memory serves me well, it was implemented in 1.12 when some of modders were hired by Squad to work on the core game), but it is very non-intuitive to most players so it was heavily toned down in stock variant, but since the actual simulation is still there, it can be made realistic with mods. For KSP2 devs decided that it's too complicated for players (which is true), and so they introduced severly simplified system instead which only looks at the temperature of entire vessel as a single unit by postulating that any temperature gradient which is present in vessel will eventually even itself out. The funny part is that reentry (and atmospheric flight in general) is one of flight regimes when this statement is absolutely FALSE, infact the very reason heatshields work is because such gradient exists and can be maintained on purpose (by keeping the heat away from sensitive parts of a vessel), so it's principally impossible to simulate real-life behavior with such approach. What I suspect they've done is basically manually tuned system parameters such that it would work the way they wanted in some finite number of flight scenarios, but since the model they use is fairly crude, you can't really expect it to function realistically. But then again, most players have no idea how this works in the real life, so an argument can be made that maybe they made a right call for majority of players. But of course those who bothered to learn it will not be happy with such approach, and wasn't learning things being marketed as one of purposes of this game?

Good then, what is your problem? Have you got your refund?

Nope, your expectation is your problem and yours only. There are plenty of people who don't have a problem with price. If you do - you walk away and don't buy. Simple as that.

Your expectations is your problem, not that of game developer's.

That's always been like that - stock experience is for notice players, veterans have to rely on mods to give them whatever challenge they desire. Because if you flip things around, there will be no veterans as the game will be way too complex for beginners and they will never become veterans. Take a look at the Orbiter - it's so complex that you need to spend a significant number of hours reading docs and guides before you will be able to do anything meaningful. In KSP 1 (it was v 0.17 when I bought the game) it took me about an hour or so to get to the Mun, in Orbiter even after hours upon hours of reading guides about MFDs it still took upward of 20 hrs to achieve an equivalent goal. Very few people have persistence like that, and you can see results in the number of people playing respective games.

Well you should have had. What kind of fabric would endure a super-sonic shockwave upon deployment? Just to remind you - a speed of sound is about 300 m/s on Earth at altitude of 10 km. ---- One criticism for the update I would add is they should've kept a small solid booster in the default unlock instead of a liquid engine + fuel tanks. It would provide a limiter of sorts without actually having any technical limits. And in general I like solid boosters more because they really reward thrust- and ascent profile optimizations, when by creative use of thrust limiters in VAB + flying a correct trajectory you can take those solid booster really far.

If it's not worth it for you, then don't buy it. What's the problem?

That's one of the things that annoyed me in KSP1 contracts - those random coordinates have no meaning nor logic behind them, my question has always been "what's so special about those coordinates?" If we ever get those missions again, I hope they would contain objectives which actually make sense in the context of a mission and environment, and won't be stupid stuff like "activate a decoupler on escape trajectory from Kerbol".

I've heard the same thing about first patch. And then the second one. And the third one. The reality is any big update is going to bring bugs. That's just the way it is, so expect a couple of hotfixes until it stabilizes enough for long-ish career plays. And no, it won't be "a sink or swim moment", just like none of previous ones was.

Procedural fuel tanks would solve a lot of those issues, as each of those tanks will actually be a single rigid body, with no need for any welding. I know Nate doesn't like procedural parts for some reason, but once I tried them in KSP1 I could never go back to the LEGO stuff.

That is that criminal caveat I mentioned above. Tax evasion/fraud is a criminal offence in most countries, and if director will be convicted, all of what you've said can happen. But it rarely happens in practice for a host of reasons which are offtopic here.

If you own an incorporated company (LLC or Feredal Corporation), then you are not responsible with your personal assets (again with the caveat about crimial nature of your actions or inaction), and this is the same whether your company is a one-man-band or a multi-billion international enterprise. It's the company which will cover damages with it's own assets. That's the whole point of incorporation, it segregates owners' personal assets with that of an incorporated entity, and limits the personal liability. This is what allows startups to exist and try to invent new great things - as you probably know, most of startups fail, but people who organized those do not go to jail nor are they ending up on a hook for the rest of their lifes to repay investors' money. So on balance such setup is good for economy overall, as it allows enterpreneaurs to try risky things hoping to come up with something new, cool and useful, but of course any particular investor does end up losing money, infact VCs lose money all the time, but if they are smart and at least some of their investment do pay off, such payoff easily covers all losses. In your example, company would either purchase an insurance policy that would cover damage to third parties, or (if it only needs a one-off job) it would hire a contractor who would have his own insurance policy that covers such damage (or he self-insures and in that case pays from his own pocket/that of his employer). That's the way it works. To be fair, management of public companies are financially incentivized to make sure a company does good - their bonuses and stock options depend on company doing good, not to mention bad top managers risk losing their job and becoming unhireable elsewhere as their reputation tend to follow them, so no sane top manager would willfully run the company into the ground.

Before this plan ever reached the Board, it went through executive office tops who actually prepared it, you know drawing all those PowerPoint presentations with arrows going up into the stratosphere, and all of that. So if this proposal reached the Board, you can be sure that it was approved by all vices, SVPs and other folks from executive office. No, this is not how it works, none of directors are responsible with their personal assets, they are in the same boat as any other employees - unless a criminal negligence or criminal intent will be proven in a criminal count of law(which is extremely unlikely), the worst can happen to them is that they will be fired without any additional compensation. I happen to be an onwer and a president of a federal corporation under Canadian feredal law, and even I am not financially responsible for my bad decisions unless someone manages to prove in count of law criminal negligence/intent on my part. I suspect the law in US works the same way it does here in Canada.

Very few people have the guts to say "no" to their boss, especially a passionate one (even if for all the wrong reasons), as it can put their career at risk. As the old saying goes, a failed project is a failure for grunts (engineers and regular line workers - you know those who actually get stuff done), but it's "gained experience" for managers. All those vice's are probably seeing themselves in a CEO chair one day.

The problem is not the price itself, but the fact that it's outside developers' control, and there is nothing they can do to affect that. Don't like an update a developer made to your favourite game? Write a simple shell script that installs/uninstalls the game 10000 times - and BOOM - developer has become $2000 poorer! Multiply it by a thousand of unhappy users (and no matter the nature of a change, in any large enough userbase somebody isn't going to be happy) - and that turns into $2M down! Numbers of course are made up for illustration, but the point here is that this policy is so susceptible to abuse that I feel like it's been designed to be that way on purpose. Add to that non-transparent "Trust me bro" billing, when Unity will charge devs whatever it "believes" the install count is with no way to prove it and no recourse on the dev's part, and I can totally see why so many devs are very uncomfortable with the change, even if it won't affect them immediately. And even if this change will be walked back and/or watered down, there is still a breach of trust - and remember this is a matter of devs' ability to put bread on their families' tables, so they will take this extremely seriously.

I don't think it's legal to change conditions of a contract retroactively.

I've been modding since 0.19 (I think), and I gotta say, things were way worse back then. The last version I monitored was 1.2 IIRC, and there was a ton of bugfixes specifically along stock-mod interface. For example, one bug I still remember (because it gave me no end of headaches when I was working on a Engine Group Controller mod, which was included into RSS mod - and maybe still is?) was related to engines thrust limiter, the problem was in the stock code, but this bug was not reproducable in stock because of the way engines were configured, and it took a big fight on my part over multiple KSP versions to get this one fixed. Also part g-limits was introduced at my recommendation (intended use case was for solar panels, so that you had to fold them during maneuvers with high enough acceleration). These are just a couple of those I remember from many years ago, but there were much much more. That is not to take away Harvester's achievements of creating the game, but he made a lot of bad calls towards the end. The deltaV number was just one example, if my memory serves me, he was also against introducing realistic thrust model (engines have higher thrust in vacuum vs in atmosphere, back in a day engines had the same thrust everywhere).

Absolutely NOT in my opinion. He made so many wrong calls, that KSP1 started progressing in a right direction only after he left. if you talk off-record over a beer or two to any of late KSP devs who has seen Harverster's late days in the team, you won't hear many good words about him. That's not to take away his achievement of the very creation of KSP, but at some point things turned for the worse. That just shows once again importance of leaving at just the right time before your star has finally set for good.

You're wrong, and you're bad (C)

Whenever you do something you've never done before, there is an inherent chance of encountering something unexpected, which will throw all your time estimates out the window. And the more "unusual" is your task, the higher is the chance of something going wrong. So by not announcing time IG is managing expectations, or, more specifically, preventing situations when they have to break their own promised timelines due to factors beyond their control. To give you a more easily understood analogy (and please remember that it is but analogy, so don't push it too far), why do you think courier companies like DHL, Fedex et. al. never tell you precise time of delivery? They generally only tell you a day of delivery, maybe a few hours-wide time window if you're lucky, but never exact time. The reason is that there are certain factors which can affect that time, and there is nothing a company can do about them. So it's the same priciple. Another approach to this is a rolling release schedule, when a release happens every X weeks, hell or high water, but the scope of release changes based on what is actually completed as release code-freeze deadline hits. This usually workes better with larger teams so that even if some functionality is not going to be ready, there is always something to release because a chance that everyone in a team will get stuck at the same time is rather low, and get lower as number of people in that team increases. I suspect that this is mostly beyond IG's control, except maybe for overhyping the game before release, but this problem is very typical for EA games as players tend to have over-inflated expectations and become disappointed when reality hits them. As for the good will, IG is not a 100 dollars bill to be liked by everyone, so no matter what they do, somebody will be disappointed. That said, I have a suspicion that a majority of KSP players either bought KSP2, played a bit and shelved it until some better times, or delayed a purchase until that better time arrives, but don't feel an urge to go to forums and scream&moan about it until the pigs fly. I myself bought the game on a release day, played a bit, and shelved it. Every time an update hits, I fire it up to check it out, and leave it be. I want some sense of progression, so I don't think I will be playing a lot until science hits, but every now and then I still fire it up and do something I feel like doing at that exact time.

I can't speak for Redneck, but since I'm a software developer, I would love to hear technical folks. I know they tend to be camera-shy and not really into talking, but still - I want to learn more about ins and outs of KSP2 from technical standpoint. Creative side - not so much, sorry, since my professional deformation (abstract reasoning) allows me to see the beauty in ugly pictures which demostrate some cool technology at work.

This is what a lot of mature products look like in my experience (20+ years of software development of pretty much everything under the Sun from websites and fintech LOB applications to AGV guidance systems and applications for factories' shop floor). It doesn't neccessarily mean that foundation is fragile, but it just happen to not account for certain edge cases that planners/developers/testers didn't think of when they were working on a system. This is where 80/20 rule comes from - it takes a relatively small amount of time ("20%") to implement a system, and then the bulk of work ("80%") goes into ensuring it works over the entire range of cases which it's supposed to work. The first stage ("20%") is usually referred to as "initial development" (or simply" development"), and the second one ("80%") is "stabilization". There is also a rule of diminishing returns - meaning that you tend to get the most gains in the beginning of stabilization stage ("low hanging fruit"), but as it goes on, it takes progressively more effort to achieve the next step. Armed with this information, you can actually get a rough idea of where on this journey each sub-system is - if you see a lot of bugfixes in certain sub-system, that means it's just entered a stabilization stage (and it's got a long way to go), but if you see developers wrestling with the same issues for a long time - that means this sub-system is closer towards the end of stabilization. So as much as I hate SOI and trajectory bugs, the fact that they are battling with them for a while gives me some confidence that sub-systems involved a rather mature. This is obviously not a certainty as it makes certain presumptions regarding the team (like that people working it have enough qualifications to actually complete it, and there are no non-technical obstacles), but this is the best we have at this point. I'm personally more concerned about regressions - while they are inevitable every once in a while, they usually indicate deficiencies in a QA process (not neccessarily with actual QA people, but rather the whole flow from documenting bugs to passing this info to QA, to QA actually understanding info that is passed on them, to them executing testing properly, to passing feedback back to developers).

From my discussions with Ferram, FAR uses voxelization to calculate an airfoil, what I proposed is a more simple model which doesn't account for a lot of aerodynamic effects. That said, it can be extended to do that should they ever decide to - for example they can add a part mask to figure out which part is exposed to airstream so that they can apply forces to it (this gives things like body lift and per-part vessel destruction due to aerodynamic loads) and/or add heating (gives us high-speed/reentry heating). This also "implements" air breaks essentially for free (since their deployments increases an area presented into the airstream, they generate additional drag). Finally coupled with slope calculations based on a depth map this system will also "implement" an actual aerodynamics, meaning not just drag, but also a lift, and allow removing yet another crurch, which is what current lift system is. And knowing slopes + depth you can calculate an airfoil, which leaves a door open for a full-blown FAR-like system with faithfully simulated advanced aerodynamic effects. As far as performance goes, any more-or-less modern hardware should have no problems rendering a few 10K triangles into a texture, and compute shaders are no longer a serious performance drag like it was a some years ago.