asmi

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.

Yes they are linked, as developer himself said above. No, it doesn't reward part-clipping, what it does reward is making designs aerodynamic. Which is what it should do. Part clipping is facilitated by VAB editor, not by aerodynamics. A couple of things: 1. FAR used approach functionally similar to the one I proposed for years, and I can't remember ever seeing anybody do a clipped fuel tanks spam. 2. Even if it would be true, why do you care how others play their game? I know I won't be doing this even if it would be beneficial. For example, asparagus staging has always been a preferred way of making launch vehicles, yet I've never built one in my entire 1000+ hrs of playing KSP because it's unrealistic. And most youtubers I've watched didn't do this either. ------ And my point still stands - it's not a job of aerodynamics to penalize players for abusing game bugs and glitches for fun and profit. Instead those bugs should be fixed, and - if part clipping spam is indeed considered undesired from gameplay point of view - then VAB editor should prevent such things from occuring, and/or adjust fuel capacity/loadout in case that happens.

That wouldn't be much better. For example, it would fare just as bad as a current system in the abovemention example of a solid axis-aligned unit cube - and for the same reason.

My point is - whatever the situation with clipped fuel tanks is, it's not the job of aerodynamics to "penalize" for it. This idea to link clipped tanks with aerodynamics is so absurd that I question the sound judgment of whoever came up with it, and also wonder what other similarly insane ideas found it's way into the codebase. That is a very depressing thought, and it gives credence to naysayers' claims that the tech team behind this project simply lacks technical expertise required to deliver the project with quality that most people expect.

The problem with cubes - which devs don't seem to get judging by their posts, is that it only works somewhat well with smooth convex shapes, so that if your part/vessel flies 45° into the airstream, you can interpolate between drag area "up front" and "side" and get somewhat realistic value for drag. But when was the last time you've seen anyone makes a vessel with smooth convex shape? Let's take a trivial example - an axis-aligned solid unit cube (1 meter in each dimension). If you precalculate it's drag surface from each cardinal direction, you get 1 sq. m. for all directions (because a cube is axis-aligned). But what if you "fly" that cube by the edge into the airstream? You should get 1.41 sq. m. because the airstream will "see" two sides of a cube at 45° angle each, and total area will be sqrt(1^2 + 1^2) * 1 ≈ 1.41, but you can't get that value by interpolating between sides, as they both are 1 sq. m. And so the "cube-based" drag model will treat a cube as if it's a unit sphere, which of course is completely incorrect. So if a model fails with a simple cube, can you imagine how it's going to work with more complex non-convex shapes? Well, you don't need to imagine - just fire up KSP2 and you will see that it's bevavior defies common sense in almost all cases.

That is ridiculous. The proper way to solve this problem is to disallow such clipping, and absolutely NOT to introduce yet another bug-o-dynamics instead of aerodynamics. Aerodynamics is - and should be - governed by the outer shape of the vessel, it doesn't and shouldn't care about internal construction. Besides, since you plan to only penalize clipping fuel tanks on top of each other by drag, does it mean that you have absolutely no problems with such "designs" when they escape atmosphere? Or you didn't think this far yet, and when you do, you add some other ridiculous penalty - like tenforld increase it phantom forces from buggy physics engine? Honestly reading such dev posts makes me lose confidence in a technical competence and decision making of a dev team. The job of air drag system is to simulate drag, not to resolve shortcomings of VAB editor by inventing fake penalties which will leave players scratching their heads thinking "why the heck do I have so much drag?" when the answer is "you clipped one too many fuel tanks" (a face palm smile goes here). There is absolutely NO way in hell the player will ever figure it out, that has NO basis in reality and therefore should NOT exist. So, pack up that existing drag system in a box, seal it and throw away that crap as far as you can, and implement this system properly. Existing system has so many holes and edge cases I can come up with right off top of my head, that I can't believe the tech leadership didn't shoot this idea down right from the get-go. I know I would've done exactly that.

Watch the player count over a day or two after update - you will get some idea as many people I suspect would want to try out a new update.

No it's not possible, because the shape presented to the airstream is going to depend on a direction of that airstream relative to the vessel, and so it's not feasible to pre-calculate all possible directions in advance, especially since every time the craft changes, it will have to be re-calculated. Also real-time calculations will take into account things like flexing, which can also lead to a change in a shape presented into the airstream.

They don't solve any problems, they just mask them. But at some point they still rear their ugly heads.