VlonaldKerman

At the risk of beating a dead horse, there is a popular theory that development got restarted at some point in 2019-2020, likely because of unforeseen engineering issues or a different vision (different engineering vision) for the game. This would likely hit engineering/backend much harder than asset creation bc a lot of the models, SFX, etc would transfer right over. Given that they were shooting for a full release with no early access, all the features were developed simultaneously, giving no special priority to the one’s that would appear in an ideal “early access” build. This would explain why a) The cosmetic aspects (aside from technical ones like terrain detail) of the game (parts, SFX, etc) are so advanced relative to the engineering and feature aspects of the game, and b) Why so many “basic” features like reentry heat are missing from the EA build, while there are supposedly distant roadmap features in a relatively advanced state in internal builds. All we can hope for is that the apparent difficulty of KSP 2’s engineering challenges is surmountable to the point where they can deliver the ambitious, performant game that was promised. However, the reasons for skepticism are obvious. In other words, yes, I agree with @Lyneira.

Respect.

I think it’s pretty clear that the language of the rules are intentionally vague so as to allow for discretion of Steam on a case-by-case basis.

At this point, there isn’t really a point to ultra high end GPUs etc for KSP 2- I have a 4090 and I get very bad GPU utilization, and I’m pretty sure RT cores aren’t supported (I may be wrong). So that’s good budget-wise.

I think that these points speak more to the common-sense frustration that people have with the game. Is KSP 2 in clear violation of these to the point where it should be removed from steam? No. But does using these points as a framework for judging what an early access should be highlight the ways in which it is reasonable to expect a better game at launch? Yes.

Ah, yes, good times. Just reminded me of that time early on in every KSP 1 science/career mode that I played where everything I launched I launched with a twin boar engine. I would say that it’s okay for things to need tweaking at launch if there are use cases for the extra gimbal. For example, would you ever find yourself increasing gimbal authority shortly after launch, or for short periods of time? The mere fact that you can make design decisions to reduce wobble doesn’t mean wobble is not a problem. Not saying that’s what you said, but I feel the need to reiterate that, while a lot of people seem to be saying that wobble imposes design constraints and that’s not necessarily bad, even though they aren’t always the right design constraints.

Preface: I’m not a game dev… BUT I feel like things like the joint physics system are so fundamental that you would be worried about those first? Like, why would I try and figure out how the game stores information about active vessels and their orbits in order to have persistent resource consumption and physics applied if I don’t know how part joints work? Maybe that example is bot actually a problem but in general I’d have to imagine that an ideal dev arch follows the (fundamental systems) —> gameplay implementation/system integration —> cosmetics and optimization timeline, perhaps with cosmetic aspects like part designs and music being developed at the same time as the technical stuff. This is what I’ve made several posts (and threads) about already: the problem isn’t that there is a bug that causes rocket wobble, the problem is that rocket wobble will probably be addressed by implementing exactly the kind of back-end fundamental system upgrade that the entire game is predicated on, and that should have been done AT THE BEGINNING! These backend systems are what will make or break the game- modders can add in all the fancy parts they want, but it will be as buggy as modded KSP 1 unless the backend of the game is totally fresh.

In KSP the ground is inelastic and unrealistically frictionless so it’s too easy for crafts to bounce upon landing and slide once they’re landed. Not the same as tipping but other reasons to have some kind of anchor. Myself, I like the act of scouting out landing sites ahead of time so I usually land on a nice and flat surface.

RO allows players to choose the type of tank (structural, non-structural, reinforced in various ways) they use. Beyond that, and with respect to joint connections, would there ever be a benefit to making the joints as weak as they are now? In other words: the game also just decides that your cabin is pressurized. This is not a reason for the cabin to randomly depressurize (rocket wobble), but for it to ALWAYS remain pressurized because the player would never choose to have it the other way (stiff rockets). There is no need for there to be a joint stiffness option if players would always choose rigid. In the suggestion I’m referencing, the forum member gave examples of other ways of giving visual feedback ex. Sparks, visual vibration, an alert system, etc. Real rockets also have internal sensors which give data- I see no reason why this couldn’t be in KSP 2. In the abstract: does it really seem likely that having rockets wobble is the best way of communicating to players that their design is bad? There has to be a better solution.

I’m not an expert, so please correct me if I’m wrong, but I’m pretty sure that in real life, rockets very rarely fail due to structural wobble. This is either because it’s such a solved problem that it never goes wrong, but in principle it might, or because the way rockets are made minimizes wobble naturally and easily. In the dev chat, they alluded several times to “realism”, and to be sure, in reality things bend under torque. But I’m reality there is also n-body physics! Would it be accurate to say that, in many or most cases, a jointless or nearly jointless approximation would yield sufficiently realistic results, in the same way that Newtonian gravity simulation does? I think the answer may be yes. I like the solution one forum member came up with wherein torque was calculated for certain joints within a vessel, but rather than bend, when a joint experienced torque beyond a certain threshold, the joint would fail. Again, this would mean no bending, so less realistic, but as they said in the chat, “[we] could make a perfectly realistic physics simulation that runs at one frame per five seconds” or something like that. If we’re already resigned to approximating, as far as I’m concerned, the aforementioned approximation is fair game. Again, I say this with little actual knowledge. But if I’m wrong, someone is yet to explain why, I think.

Motion to send everyone who voted Jeb up in my next KSP rocket

Dub. Looking forward to it.

Fair example. Though, I think it is pretty much the only one. And to this point- I actually saw a video of someone who modded multiplayer crudely into the game… so at this point I’ve seen more footage of player-made multiplayer functioning than dev made… I suppose I agree. This relates to a common pattern that I’ve noticed whereby a substance problem is misconstrued as a communication problem. KSP 2 has a SUBSTANCE problem, as you’ve alluded to, and the only thing that would solve that is SUBSTANCE, not STYLE. I suppose we just disagree on the extent to which style can mitigate community ill-will.

I don’t think anyone would accuse them of lying about good news if, alongside the good news, there came any evidence that the good news was true! Would you like me to list all of the pieces of “good news” that have been false, again? This is why I think dev gameplay of new features and internal builds would be so positive. Can you give any examples where people have accused the dev team of lying, when the respective statement was true?

My boi really poking the beehive 0_0

This is actually one place where, in my opinion, KSP 1 mods haven't really figured this out. There are a few mods that allow you to store crafts and parts and add in construction time, but I always found them more tedious than interesting. In practice, "refunding" a ship was enough for me. The main reason I wanted to add in construction time in the first place, actually, was to increase the importance of planning ahead and having rescue plans with my life support mods. That way if Jeb gets stranded on the Mun, I can't just design and build a new rocket to save him instantly. I either need a rescue ship ready, or I have to big-balls it. This sort of connects to discussions elsewhere about finding ways to make "time" a meaningful resource. The other gameplay purposes of storing crafts are less interesting to me.

That would be amazing Imagine tuning into @DakotaTV? I'd gladly do so Actually, in a previous thread, I suggested this as a solution to their communication issues, by saying that this sort of absolute transparency is what early backers (which is what we are) should have, and I was shot down as being too demanding. I feel like we should see the internal builds of the game that the devs have been hyping up for years.

I think I made a post about this a while back, and I agree. I would add one thing- the ability to plot a trajectory using the “fixed” point-thrust mode, then convert it into a relative one (approximately). One of the main issues with the new maneuver nodes is that you can’t just make a maneuver at your apoapsis to circularize- where you make your maneuver depends on the length of your burn. You should be able to make a maneuver in this simple mode, and have the game recalculate to find a true trajectory of best fit which approximately matches the trajectory you made in instantaneous impulse mode. I haven’t really thought this through, but I THINK this solves your cosine loss problem. The cosine loss is really just burning at the wrong time in your orbit. I THINK… PS if you have math that shows I’m wrong I’d be interested.

I agree that publicly deriding programmers is not a productive thing. In fact, you can look back through even my most critical posts and see that if I tentatively blame anyone specifically, my hypotheses tend to blame management. However, counterproductive != abusive. Bad? Maybe. Morale draining? Maybe, though I would venture that is something that individual people whose moral is being drained have a lot of control over it. Throughout history, by this standard, most working people have had to tolerate “abuse”. Many or most of them took it on the chin. For some reason, we have either lost this expectation in the modern age, or at least don’t revere or encourage it. That’s a massive tangent, but the reason why I think it’s relevant is that it would be neither accurate nor fair to blame “the community” for almost anything associated with the game going wrong. I mean that both in the present sense, and in the future if people are doing postmortems talking about “what went wrong”. When we act as if devs are irrevocably harmed by community members lashing out in frustration at a bad game, we both fan the flames of anger and provoke backlash, and also rhetorically strip individual developers of their agency with respect to their own feelings and morale, thus potentially condemning them to emotional fragility and demotivation. I mean this in the broadest possible, culture-wide sense. When I get criticized unfairly over something I take pride in, I try my best to channel my frustration into proving those criticizing me unfairly wrong. Criticism, however unfair, is not an excuse for well-compensated developers. I’m not necessarily saying that you said it’s an excuse, but I feel that it’s the water in which your opinion swims.

Man, if the level of criticism you’re expected to handle as a game dev is so low, I want to be a game dev! It’s abuse to say I might be incompetent when my work product is disappointing (seemingly)? Where do I sign up?

I agree with basically all of this, including your view on USI LS. I think that a resource-based system with supply chains is something that could be balanced to be a net-positive for the game. One thing just occurred to me though, which some have alluded to… when you start sending your first interstellar missions, they will take a LONG time. That’s the sort of thing where it’s reasonable for the player to want to be able to time warp for long amounts of time, because much of the rest of their missions are probably comparatively small or at a standstill. So they would have to be really careful to make sure that you can feasibly use automation, etc. to set up a system that requires no player intervention for LS. Edit: I just saw that this is literally what the previous two posts were about, lol.

I’m the dairy analogy, I think it was advertised that there would be some substantial cheese off the bat. But that has already been litigated. MOOOO!!!

No- it’s like you spent $50 for a months supply of milk only to find that they are out of stock for the foreseeable future. In that scenario you are expecting something from the supermarket.

I really like a lot of aspects of your suggestion, especially the concept art. However I’m worried you’re solving a problem that may not be there. I understand the problem is, “We like LS because it makes time important, but it seems too punishing to a) “one mission at-a-time” people, and b) casual or new players. I feel like the solution to this is UNCREWED exploration. I agree that having Kerbals onboard should increase your science yields. But this should come with some disadvantages. Namely, the added risk of losing a Kerbal (will there be penalties for this???) and the extra mass needed to keep them alive. Also, I feel like the ship has sailed (no pun intended) on catering to “one mission at a time” players. When colonies are introduced, the player will probably have to have multiple colonies running concurrently with missions being conducted on or around each. Eventually, the player will have to begin managing several missions at one time. This seems like a natural part of progression. It follows, then, that as the player becomes more advanced, they begin to use crew and therefore run multiple missions at once, which acts as a natural buildup towards colony gameplay. As I understand it, the goal with KSP 2 is the same goal that many sequels have: decrease or maintain the skill floor, while raising the skill ceiling. KSP 2’s new player onboarding and similar gameplay will fulfill the first requirement- and it seems like the addition of basic (one-resource) LS would be a natural solution to the third. I think there’s a more general point here, about the fail to learn, DIY spirit of KSP. The nature of a rocket sim is that it is difficult, and not for all kinds of players. It is impossible to FORCE or FACILITATE someone’s developing proficiency at KSP. This is a fundamental element that won’t change unless they drastically nerf gameplay. In my experience, LS is not, as a feature/consideration, wildly difficult relative to all of the other challenging aspects of the game. And the fact that players may struggle, or even fail with it, maybe several times before succeeding, sounds like more of a POSITIVE for a playerbase like KSP’s than a negative. Perhaps they want to change the playerbase drastically to accommodate less intrinsically motivated or interested people. I think this is a mistake, and fundamentally impossible. I fell in love with KSP because I could immerse myself completely into a mission. I could transform my room into a ghetto KSC planning room with whiteboards full of mission profiles and weighing the pros and cons, etc. I feel like a LS system that’s all carrot, no stick is inconsistent with this vibe, and I may be wrong, but this vibe is that which I feel is fundamentally associated with KSP in a unique way.

Actually, it could be- never mind, I’m not gonna finish that joke…