chefsbrian

I appreciate the clarification, that makes far more sense. All I have to add is that I really hope its taken to heart going forward that communicating the actual, explicit reasons for things is vastly preferred over nebulous mystery playing. Folks are still back and forth on whether there will even be any talks of substance at SCD this weekend due to the fog of mystery that's been attempted on the whole thing. And yea I know its not your doing, QA bro, you just happened to reply so I'm replying back The fog of mystery is for when a community is relatively happy and being teased new things. Its not a good tool to use when a community is discontent, as there's no benefit of the doubt left.

Grats to the guy for getting the job, but why exactly is this leading to a KERB delay? He doesn't even start until monday, and the KERB report was for this week, so why wouldn't there be any progress from these prior periods? It really feels like a limp excuse rather than an actual justification for the action. You guys do realize that part of promising the community that you'll be delivering more regular communications is actually sticking with those communications, right? I've been a strong defender that the KERB's are probably going to be of minimal update value just by the nature of bugfixing, but that's not the problem here, the problem is not even delivering 'em.

Yep, you can contact steam support directly, and appeal, but they're unlikely to do anything unless you are only marginally over the play time/buy time windows. If you bought it back at launch, your pretty much outta luck for any refund, been way too long. Your remaining options are limited and generally destructive - card chargebacks are an option your financial institution might permit, but at best steam will pretty much blacklist you from buying titles, at worst may ban your account. Would not recommend trying your luck on it at all. Don't fret it too much though, everyone gets burned on one or two EA games, and learns to either not buy EA if there's anything else you might wanna spend that money on, or gets very good at watching that 2/14 window and bailing out. I've still got Starforge and Godus in my library, so I've been there and know how you feel lol.

Bit weird that the messaging went from "We'll have a post up after the event for you all" per the dev tracker to "Well if it is that big, you should expect a post" - If there is a post, bit late to be playing coy, and if its gone from "yes definitely" to "well if we're ready to show what we wanted to show" that's not great. This is what happens to a starved community though, every bit will be analyzed lol.

Why would he? He's a low level hobby youtuber, not a journalist. Set expectations appropriately, yknow. Probably better to be asking why are none of the gaming sites out there coming out and asking whats going on. RPS and Polygon haven't talked about the game since May, IGN hasn't mentioned it since June, and I can't find anyone else who's done anything other than reference those RPS and Polygon articles.

Pretty much exactly it - a family oriented event to encourage interest in space among kids. Which actually makes it a pretty decent place for KSP to go - One of the major goals for the game (Or at least a favorite marketing line) is to get folks interested in space. They probably invited KSP, not the other way around. I will admit that I'm disappointed at the associate implication that information the community is desperate for was withheld to be shown off in Germany as a marketing move, I'm also willing to recognize that in all likelyhood, this event was scheduled 6 months ago and they probably thought they'd be showing off something they'd released, along with teasers to new things, rather than still waiting on Science. But this really, really needs to deliver more substantial information than another surface level "this is how hard building these things are" presentation.

A worrying possibility, but something in my gut tells me this unannounced game is basically going to be KSP Mobile, with a focus on simpler missions and rocket builds for the platform/audience. Fits with the effort to expand and monetize KSP as a wider franchise, and current market trends. Here's hoping that I'm not just overly optimistic on that front.

Not to mention its usually a good idea to have role overlaps since people like to take vacations or get sick (maybe they don't like that part lol) or even get new jobs and need to be backfilled for. A bit of redundancy is good stuff.

It does though - Publishers can, and do, take community sentiment in mind when it comes to projects. And while I believe the team 100% when they say the team is currently fully funded and staffed and that's not a worry right now, its also guaranteed that its not in perpetuity. When the next budget cycle comes up, the community sentiment and its impact on future revenues will be considered - People don't want to buy a 'dead' game, and even success stories like NMS show it takes literally years upon years to turn the sentiment around once the wider, non-owning public whom you rely on buying the game to continue justifying its development. There's no reason for leadership to rush into making any funding decisions about the games future as of right now, but if they let the sentiment tank hard enough that the pubic narrative becomes "Games abandoned", they would be remiss to not consider whether they're about to throw good money after bad. Remember, massive community support and excitement is what originally made the publishers agree to a scope increase and three additional years of development over the original plans and release date. Massive community rejection can very much do the same in the other direction.

Agreed in theory, but unfortunately that ship has sailed. They've come out multiple times making promises to improve communication frequency and quality, to attempt to address community concerns. Stepping back now might cause worse damage as the optics of the situation among the most negative become "First they abandon their release cadence, then they abandon any reasonable content schedule, and now they abandon even trying to tell us what's going on - All that's left is to officially abandon the game". That's why I say that I think their early mistakes have really screwed the team over on the whole situation. They tried to commit early to things that now are evidently not feasible, but those commitments were efforts to address initial genuine concerns in the first place. Trying to roll back to quiet mode now would be an absolutely huge blow that'd undo any and all efforts to maintain positive sentiment about the game. And I want to touch back onto the very start of this post, where I agree "In Theory" to quiet mode. In practice, if KSP2 were to be judged by its actions and not its words, it'd be judged as abandoned or a scam. If the team had said nothing about all the things they say are in the pipe, and all we had was the release day messaging and the following patch notes, then stuff like reentry heat would be burning bigger holes in the community confidence than it already is. The wording back then about it being a brief period would make the lack of it and lack of communication over the following eight months a glaring indicator that something has gone terribly wrong. So yea, they're stuck in a pickle. They launched the game in a very rough state, and made a lot of public promises about how they'd progress on fixing those, along with how they'd communicate about those fixes to us. They're now failing to deliver those promises, and can't just walk it back since its tied into the whole correction of the rough state of the game - abandoning one would be tantamount to abandoning the other. And they can't realistically expect the community to accept some new solution either - They've already shown by action they can't deliver on game or community update promises, and we've unfortunately no reason to believe any new plan would be any different.

Were it so easy, but when do we come back to actually get news to talk about? One of the glaring gaps in the communications has been the inconsistency of it. Right now, we're actively encouraged to check in every day, because there's absolutely no consistency in the current communications - You can sometimes predict when the next bug fix news will be, but for anything substantial people care about, its a big old series of question marks. There is nothing consistent of substance - No "Come back on the first thursday of every month for a content blog" or the like, no ticking "Next patch on X" (Stealing shamelessly from my prior comparison to The Sons of the Forest) indicator for the community to operate off of. If anything, the nature of current communications in KSP2 indirectly encourages complaining and negative discussion. As long as it doesn't get spicy enough for Mods to shut it down, the dialog tends to force actual updates from Dakota and the like that something around X is coming soon and just not ready yet. The squeaky wheel gets the grease, and it feels like if we don't squeak to the max, we don't hear anything at all.

For the forums, sure - Maybe it'd be better received in the first months, but by now the sentiment would be about the same. Once it starts to become reasonable to the average person to describe the time since launch in Year{s} then things get pretty normalized. And that would only really apply to the forums - the average user on steam who didn't know or care much about the game until the launch marketing started, and set their expectations according to the market as I described before. They're the reason the games rocking that mixed/mostly negative and still trending down. Most of us hardcore and passionate people got in early and reviewed early, the new stuffs the new blood or review updates.

While I think some of the active hate for the game can be heavily questioned, the pessimism is unfortunately well earned. At the grounds of it, the current game state is such - Slow bugfix patches with major issues still persisting well after launch. Communications are vague (unfortunately an impossibility to fix in the world of bug fixing) and therefore discouraging to the average person. New content is nearly non-existent at this stage - Plenty has been promised, some has been shown, but the current nature of communications around these things have been a lot of window dressing with little promise of delivery. Not to say that they are actively not going to do it, but a dev update about how hard or complex designing for X or Y is does not assuage the concerns of a community wondering when they will get it. Efforts to increase communication have been unable to address this timeline concern, which have been leading to more speculation as to why not, which generally degrades into negatives, as people speculate as to why they can't answer these questions and provide timelines. From the business perspective, making promises you can't keep is a bad idea, and rightly so. From the consumer perspective, people just want X features per the roadmap, and in line with their general perception of what is reasonable, and failure to at least provide corrections on what reasonable should be just feels like weaseling out of the problem. This problem gets worse when the community was told that bug fixing isn't taking time away from milestone work - Now the community is under the impression that bugs still exist because features are being prioritized, but these features also aren't materializing, so what's going on? One or two mild comms 'mistakes' (Only mistakes by the context of whats happened since, to be honest) has really damaged the entire communications plan of the whole early access launch. Simply put, nothing has gone 'right' in this early access launch for either timelines or communications, the developers cannot say with confidence when it will get better, and the request to trust them has either exhausted said trust, or never earned it in the first place for many. That's a recipe that's guaranteed to generate pessimism. As for the whole "Why does KSP2 not get the leniency KSP1 had" debate back and forth, its apples to oranges. Consumer expectations for what early access is and means are wildly different - By the time KSP1 was in an era where early access was more 'normal', the game was also very matured, and wasn't hurting for expectations or defects in its update gaps. KSP2, meanwhile has launched in a period with relatively high expectations from games on the quality front in particular, alongside the expectation of more frequent content. Blame other AAA games for launching in such a horrible state that rapid bug patching of initial versions is expected and resented in equal measures. And blame the seasonal content model for people expecting content updates to be frequent, even if not substantial. KSP2 has peers right now in games like Sons of The Forest, maintaining much more active release cycles. Consumers can often have unrealistic expectations about things, but its difficult to argue its unrealistic when teams with less resources are meeting those expectations across the board.

The most likely reason is that, unless they've got a special contract, you need to be on 2021LTS for console development and come April that requirement is going to jump to 2022LTS assuming that 2023LTS launches in that time window. This isn't a Unity requirement specifically, this is part of the requirements and contract with Microsoft and Sony to get access to their SDK's.

With your income how it looks, I wouldn't worry too much about picking out parts just yet. It will take a while to save up the money for a build, and in that time period, a lot of new hardware will come out. By the time you're ready, you will almost assuredly be able to build a better computer for less money. If you can save up $1,000 USD, you should be good to go. And by the time you've done so, KSP2 will hopefully have most of its big new features out, and a robust modding community for you to enjoy.

Nothing wrong with that, we're all spitballin' since we don't really have a full architecture doc for how it all should work. But on paper, it really shouldn't be this bad. Objects not under active acceleration can be packed up and put on rails with a static orbit until they reach a SOI intersection, assuming their orbit is capable of one. The entire physics load of it should be nil, with the actual compute overhead coming from deriving where it should be right now for display on the map. In practice, there's some overhead for checking those SOI transitions and probably a few other things, but nothing that should be making a performance impact without hitting absurd levels of independent tracked objects. Objects under active acceleration are a bit more complex in that your constantly adjusting that orbit, but unless they're unpacking and loading the full physics of the object to allow for bad designs to fail to go in the direction you wanted them to go (Spin out, etc), its a fairly constant overhead to deal with. The other half of the packed objects is calculating the whole resource flow for them. This is the one that could get exponentially bad if its not designed cleverly, but also has very flexible granularity - you could check every second, but in reality you can likely get away with most resource flows operating on a courser timescale - doing something less often is one of the easiest ways to make it more performant . However, right now, we're not equipped with the tools as players to really stress this part. All we really have for passives is fuel and electricity, so unless you've got a fleet of ion probes at full burn in the background, neither should have any appreciable impact. If I were to speculate, orbital decay and these performance bugs may be hand in hand - if ships are holding onto phantom forces, however trivially small they are, then the on-rails system is going to be doing constant trajectory updates for what it thinks are vessels under acceleration. So instead of going hands off, the systems treating everything as close to live as it can be. Its also possible the resource system is dealing with ghosts - If it has an outflow, and the outflow goes to 0 resources out but never actually gets removed, and then another outflow is added later, they might stack up and add up. Its easy to forget to deregister things, and while a check that ends up doing nothing is fairly cheap, having a lot of them can get expensive fast. And its easy to assume that resources will just be responsible for their own mess, because the alternative is trying to second guess every calculation, which is worse.

Extremely unlikely. DOTS isn't really something you 'turn on', its a series of tools that you use ground up to solve certain problems that engines might otherwise struggle with. Any of the problems that they have had that also could be solved by use of the DOTS tools, is something that I really hope they've already solved themselves, like better multithreading for background processing. I guess they could maybe try using the burst compiler, but its optimized to work side by side with the Jobs system, not whatever homebrew threading they're running. Might help, probably won't, doubt its worth the time to explore it so late in development. DOTS is one of those things you start using at the beginning of a project, because its so foundational. They could, but I'm not sure it'd help. Most bugs are, frankly, simple solutions while the problem is often just a simple human mistake or assumption. The difficulty is really in finding and often reproducing them. Trying to describe why this is difficult to someone who has never programmed, never tried to debug decoupled code, is like trying to explain why space travel is difficult to someone who doesn't know how orbits work. To them, you just turn your engine on and point at the target. To us, we're figuring out launch windows and phasing orbits, which mean nothing to that person without explaining the foundational reasons for it.

I'm somewhat in agreement here - The commitment not being met sucks. But I think its because they chose a really, really bad metric to try and report on. Very few games use their bug log as their major development communications for a reason. Most games do some regularly scheduled feature blog, or developer touchpoint or design talk. But Intercept is extremely reluctant to talk about that due to prior delivery promises slipping, and the longer they go without talking about them, the worse the potential response gets. After all, if they come talking now about the absolute barebone basic design principles of science, people will assume that they're only now just nailing them down. And god forbid if they're playtesting and find out something they designed isn't fun and needs rework (this is a common occurance) and the community gets it in their heads that they're incompetent at gameplay design. I've mentioned before how the relationship has gotten adversarial. Every communication is carefully crafted, curated, and reviewed because they're frankly afraid of making it worse by saying something wrong, and a lot of us are seeking blood in the water - we're mad, some of us probably excessively so, and we're looking for justifications for that anger. We're well past the point that we could get a post from a science guy talking about this cool part he's messing with, because next week it'll be scrapped cuz it wasn't fun to design missions around, and the community will riot. They chose bug fixes to report on because nobody can get mad at a bugfix, and then I'm guessing the delivery keeps slipping because they're holding out for every last possible little fix - it may be seen as preferable to delay an update so that the update has at least one changed status, over posting an update early that just shows nothing moving 'cross the board.

Yes, because I can tell you this right now, as I'm currently lurking in a meeting about exactly this in my dayjob, that if you have a "General" status report your customers will immediately come down the pipe and ask for explanations on what this means, in detail, because most people do not understand how this stuff works - especially with external customers. People want details, because details are to them understanding and the opportunity to try and 'help', as useless as it tends to be in bugfixing. And thats not to mention how you can, at no fault of anyone involved, regress from any of the above states immediately back to 'Investigating' because bugfixing is not a checklist, it is a nightmare morass of discovering the guts of your software don't behave right. You can easily make it almost to the end run and think you fixed it until you discover at the last moment there's multiple parallel ways for an issue to trigger, occur, and progress, and you just spend the last weeks having only discovered and iterated on one of them.

You'd really think that, but then that requires me to stop pulling my hair out over why this isn't working for five minutes to actually provide a meaningful status update of any sort. Trust me, its like herding cats in software development. When it comes to bug fixing, anything more substantial than knowing who's working on what at a given time is usually pulling teeth, because I can't effectively explain what I don't understand, and if I understood it I'd have already fixed it.

Speaking as a professional software engineer, If I'm busy chasing bugs down the last thing I want to do is write a daily status update that amounts to saying "I have no idea whats going on" - even if its accurate, fair, and everyone knows to expect 90% of it to be that, we don't want to say it because it makes us feel like we're bad at our jobs. As a result, you usually have to actively pursue us to get updates that aren't 'positive'. Especially when we feel like the solution should be right around the corner, and if I spend just five more minutes maybe I'll find the real answers.

Possibly - If the players decisions around strength had an impact on the weight of the parts, or perhaps resources consumed, then it would be a decision to be made. You might get more Delta V or use less Structural Steel if you tie them together with Twine and hope for the best. Its very much a game design decision on that front though. If wobble is intended to be a gameplay mechanic, the player should have gameplay methods by which to interact with it. If its a realism decision, then the player should have realistic means by which to address it. If its not intended to be either and its just a passive side effect of the simulation, then I'm of the opinion that the aspects of a simulation that cannot be influenced by the player should not be hostile to the players goals

I wouldn't say your wrong, rockets don't really wobble IRL for a variety of reasons (Internally pressurized tanks just so happen to really dislike being flexed along their length which certainly helps). Part of the problem is that the player doesn't really have any engineering tools to control those joints, or the ability to make any of the engineering tradeoffs that could be used IRL. We've got lego bricks, and the bricks go together as the developers designed, and we have no ability to sneak in with a bit of superglue to fuse that lego together. We just got a system where we get what we get, but what we get isn't presented or explained to us, we just get to observe improvised slinkies and question what we could have done to prevent this. We can change the nature of the problem and the thresholds, but there's no great way to go around any system that has failure states that can't be effectively communicated or influenced by the player. I think that's probably part of why there's so much uncertainty about where this should go so far as a solution design is concerned - It appears the goal is that the player shouldn't have to worry about this actively, but also the player shouldn't be able to get away with clownishly impossible rocket designs.

My point is that the long term solution is not somehow immune to that either. Both have the exact same risks per change made. The difference between a long term solution and a short term solution is magnitude - a long term solution is usually considered long term because you have to do a lot of things to make it happen, meaning a lot of change work, a lot of resultant errors, and a lot of fix work. The short term solution is the thing you can do with a far lower magnitude of changes, so far less immediate effort and far less things being touched that could break. So you can get it out in a measure of days or weeks, not months, even when things catch on fire. Its also not really representative to think of the time spent on the short term solution as simply wasted effort that should be spent somewhere else. Both the short and long term solution for a given space address mostly the same general systems - If there's an underlying physics occlusion bug (Completely made up) that's impacting joint rigidity, then that issue is going to be encountered regardless of whether you're doing a quick change or an in depth one. Unless your short term solution is bizarrely and fantastically out of line from the long term goal, they're walking the same code paths and are gonna hit many of the same issues.

That's not really how it works. The dev team doesn't really waste time hunting and fixing bugs - The bugs will, for the most part, exist regardless for a given feature set, the question is whether the dev/qa team catches them proactively, or after launch. Either way, they spend the same amount of time actually fixing things. Being over aggressive trying to paper everything out to try and spot bugs before code enters the system can be counter productive, as most bugs are based on false assumptions (IE This resource will be available, this system won't produce bad output, this function produces this kind of output reliably) that stem from developers simply not being able to know every detail of every aspect of the vast codebase of a game. Flawless resource management might reduce some of that by making sure the expert/veteran in a given section of the code is available for a given change, but nobody is perfect, and the veteran in one space is often the veteran in many, so its triage - someone's gonna end up working with stuff they're unfamiliar with, all the time. A good QA can help make sure more of those bugs and bad assumptions are caught in the pre-launch window rather than the post-launch window, but you generate bugs regardless, and spend time fixing them regardless. Just the nature of the beast. The alternative is to just not develop a feature at all - But until you develop it, you have absolutely no idea what the possible time commitment required for error fixing will be. And sometimes it can turn out to be a complete nothingburger - You might have your experts spend hours theorycrafting issues to watch for an address, only for absolutely none of them to manifest because, to quote a master of 'good enough' game developing, "It Just Works". Letting that uncertainty prevent you from attempting action is how you get nowhere with a project. Its about deciding which risks you want to take, rather than none at all.