

chefsbrian
Members-
Posts
172 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by chefsbrian
-
Release KSP2 Release Notes - Update v0.1.5.0
chefsbrian replied to Intercept Games's topic in KSP2 Dev Updates
The problem with offering multiple potential paths for submission is that users tend to take the path of least resistance, even if its not correct. Again, I get that in your situation its an unneeded PITA, but multiple processes is a much greater PITA on the rest of the team, I've been there and it sucks lol. -
Release KSP2 Release Notes - Update v0.1.5.0
chefsbrian replied to Intercept Games's topic in KSP2 Dev Updates
its a catch-22 sorta deal: players may think they're the exact same bug report because the symptom is the same, but from the developer perspective it could be an entirely different bug report for tracking purposes because the root cause is the same. Having everything submit separately and be merged after review if determined to be indeed duplicates is the best way to handle it, usually. Your experience shows the other side - users aren't workers, and are entirely capable of saying "not worth it" and just not bothering with a report. Ease of report submission alongside quality of report submission are two metrics that are forever at odds, especially since ease of reporting influences quantity of reports as well. For what its worth @Dakota, The way you do it now is probably the best way. The number of hours I've wasted as a developer hunting down a bug in a completely wrong avenue because the bug that "returned" only happens in entirely different reproduction circumstances that were never documented because the user just reopened the last incident instead of a new one have probably cost my company a fortune. -
Glad to see Waffle Irons being included as a sneak peak into the science experimentation modules, should add some diversity to my usual Mun Lander Pancakes.
-
Couldn't have said it better myself, the proposed changes make no sense, mechanically or in world. I'd have to disagree here - Discovering Cryogenics via Duna's poles, for example, doesn't make a lick of sense or teach the person anything. I do also feel that this specifically locational approach to science ends up just making science a mediocre, one-shot resource system. Assuming its delivered as generally presumed by the community, Resources are the incentive to go specifically to Duna's poles with a specific piece of equipment. Just instead of it being some scientific payload, its a motorized shovel, scooping out that deposit of Dunite, an economical mineral that can be refined into Steel with hydrogen as a byproduct, which may make Duna more suitable to certain ship construction than if you'd focused on a different location for early industry.
-
KSP2 Tech tree and For Science! VAB (and analysis)
chefsbrian replied to Strawberry's topic in KSP2 Discussion
Yes and No - The community does want more involved science, but I can't possibly imagine minigames actually holding up. KSP is not a game about running science experiments, KSP is a game about building rockets and going places with them. Science was always a system aiming to add reason to go to specific and different places, via mechanical rewards that gave you new parts to build new rockets. Which is why colonies was the natural progression of things, as it provided more things to build, more places to build rockets, and more places to fly those rockets to and from as a result. Science was just a decent gameplay loop to drive that. Any advancement of that system would have best been served by increasing the involvement in rocket design required to accommodate science. Which is a difficult ask with the foundations being on 'complete' piece lego building and all in one style designs. The only design and engineering challenge for most parts is "Do you have the Delta-V to move them into orbit", as there's no situation where you have to consider at all how its actually built onto the ship. You can slap a materials bay experiment under a nuclear reactor, have two NERVA's blasting out on either side of it, and get a perfect environmental sample result regardless of the surrounding ship. Design simply doesn't matter. But on the flip side, adding those constraints would lead to 'optimal' builds and discourage or prevent a lot of experimentation, which goes against the teams wider design goals. Long term experiments are fun on paper, but in practice most players just slap time accel and wait for it to finish, then carry on with the mission anyway, so the mechanic becomes a minor inconvenience at best. Transmission time at least is an engineering challenge, a check if you've got sufficient power generation and storage for the data volume. Still, I understand how they failed to find a solution that worked, and fell back onto what they already had. What I don't understand is why it took them so long to figure that out, when the KSP1 modding scene had mostly figured that out by 2017 or so. -
Well, I will give the team credit, I had given up on Science this year and expected it as a February release, so you've beaten my expectation. I wouldn't exactly call it High Praise, as that expectation was in the gutters from the prior performance, but its there. I can't say I'm impressed though. We were being lead to believe that Science was being rebuilt from the ground up in a new way to avoid the old "slap all the parts on and fly about" system that the old KSP science encouraged. And now what's being delivered to us after this extended wait, is exactly that, but with some bonus points for hitting Points of Interest. Even down to allowing some of the science value to be transmitted, and the rest of it needing to be recovered, in variable amounts for the different experiments. I was running this exact gameplay system yesterday over my lunch break in my KSP1 save. I will however, give props to the one design addition that I think was absolutely worthwhile, the tabbed science tree. Assuming modders can (at some point in the future) add too the trees and add whole new tree's, you've quite possibly made a science system framework that's much more parts modder friendly. I think for me, and others in this similarly 'not quite impressed' state, this update is gonna be leaning much more heavily on the stability and QoL changes. Having mechanical reasons to launch missions and favor parts over others, and having my ships not just fall apart, wobble themselves to death, deorbit, or decide that my docking port has run outta hugs juice, that will be what makes the patch for me. Achieve that, and you'll be at feature parity for everything except modding support, which is understandable. If you guys can pull this off as presented and without any new or returning major game breakers, I'll probably be able to say that the games finally as good as, or better than, KSP1. If things are royally busted on launch and its a repeat of February, I worry it'd be the last straw for the wider community. Sucks to say this, but its gonna be a sink or swim moment for many.
- 305 replies
-
- 15
-
-
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.
-
Bug Status [10/4]
chefsbrian replied to Intercept Games's topic in KSP2 Suggestions and Development Discussion
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.
-
Bug Status [10/4]
chefsbrian replied to Intercept Games's topic in KSP2 Suggestions and Development Discussion
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. -
Bug Status [10/4]
chefsbrian replied to Intercept Games's topic in KSP2 Suggestions and Development Discussion
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. -
Bug Status [10/4]
chefsbrian replied to Intercept Games's topic in KSP2 Suggestions and Development Discussion
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. -
Bug Status [10/4]
chefsbrian replied to Intercept Games's topic in KSP2 Suggestions and Development Discussion
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.