Jump to content

Kerbart

Members
  • Posts

    4,572
  • Joined

  • Last visited

Everything posted by Kerbart

  1. Some pundits were complaining about the disproportionate vertex count of the Kerbal's hair and how it impacted performance, which might explain why it was prioritized.
  2. Are you volunteering to finance said two years of development? "Would be nice" and "who bankrolls that" tend to go hand in hand.
  3. I think this is what those of us who stated "this is how software development works" had in mind. And to be fair, I think the second patch will be where everyone wants to be. Most of the bugs that didn't make it in today's patch will be covered as well as the worst of the new bugs (yes, there are going to be new bugs) will be addressed, and then we are at the version everyone hoped (and some expected) to get at EA launch. Which is still pretty fast
  4. If they're releasing today they are likely in the office to celebrate all the positive reactions on the forum and on Discord. Because I doubt there will be any complaints about the patch.
  5. To clarify the Thumbs Up I gave: I absolutely hate Discord, but this is what it is.
  6. The way I see it is that the first patch will address (hopefully) some of the worst pain points. There will be plenty of bugs around, but hopefully those are major annoyances and not (too many) rage inducing bugs. Then a good chunk of those can be addressed in the second patch, which will then be looked out for with less urgency. And then by the time the third patch comes around it will start to address minor bugs and things like re-entry heating.
  7. I suspect that after the first, maybe second patch the game will be a lo better, as the most blatant features have been adapted to aligned with what users prefer.
  8. Far from defending MS here, there are a couple of things going on: The developer is another studio, not sure if they’re owned by MS in a T2/IG type relationship or if it’s more loosely, so it might not be a “regular” Microsoft thing. It’s still a horrible experience though. FS DLC is traditionally outrageously expensive. $45 for a single jetliner seems a normal price. Prices like that encourage piracy Because of that, FS DLC has always been heavy DRM’ed, with all the problems that it causes. I have a few gorgeous RealAir aircraft I can’t install in FSX since the studio went out of business The marketplace seems to be an attempt to address these kind of issues Again, it’s an awful implementation. But I think it shines a light on why they came up with it.
  9. Welcome to the internet. Written communication misses the verbal queues that face-to-face provides. What you think you say, if you're careless, is not what other people think you say. That might be wrong, there might be something wrong with them, but the reality is, that that's how it works. Marketing has a saying for that: “perception is reality” As a communicator it's your job to ensure that people understand what you're saying; it's not the receiver's job to try to figure out what you meant. Unfair? Yes. Learning that lesson here beats learning it by getting chewed out by the VP in a meeting room full of people though. Not automatically, but yes, there's a difference between saying "I think that the game is a steal at $50, it offers 10× the playing time compared to other titles at that price point" and simply saying "the game is too cheap." Context matters. When presenting personal anecdote as pure facts you risk portraying those who report something different as misguided at best and likely a lot worse than that. The thing is, how they interpret it is outside your control. If you don't want your statement to be interpreted as "those who don't agree, are mindless haters" then it makes sense to ensure it doesn't come over that way. You'll find that people will react a lot more favorable when you separate fact from opinion, and provide reasoning behind what you say. Disagreement can certainly be respectful, but you cannot engage in a conversation when you angrily start shouting. Keep in mind that you're making claims in an environment where it's not uncommon to make inflated, unreasonable claims. Certainly you're not the type to make those, but those who read what you write don't know that. So when you make an unsubstantiated claim of "awful performance," is there anything that makes a reader stop and think "great, another kid who wants to show off that he has high standards and who considers anything less than 120 FPS unworthy?" Consider "When I launch a small rocket (less than 30 parts) I don't get more than 12 FPS after launch. That's awful!" It's hard to argue with that, and people don't agree with you, will argue on what their expectations are, instead of feeling attacked. It's the tone that makes the music, not the lyrics
  10. It's not what he syas—most people will respect that. It's how you he says it. A lot of people take the gaeme for what it is, early access. Things don't work, and one can expect that. So, anyone who doesn't find anything recognizable in these comments sees themselves portrayed as naive simps who lack proper judgement. That's quite offensive, and it provokes reactions that can be expected when provoking people. Part of that comes from making exaggerated claims. “Awful performance?” Game runs just fine on my nearly 10 year old hardware. It's not 60 FPS but KSP never was. “Utterly broken?” I've flown around Kerbin, and landed on Mun and Minmus. I'm not saying it's without bugs, but utterly broken? "I tried the game and ran into a lot of issues on my computer. I tried x, y and z and it all failed. The game is not for me." would have passed pretty silently, but stating that you can't imagine why anyone would be insane enough (not said, but implied) to enjoy the game is beyond me... yeah, that's going to get a reaction.
  11. As far as I can tell, no. I tend to do it too, because it looks good, and I feel that "making things look like I think they would in real life" is a sound design principle even when you know it doesn't matter. Based on experience you can consider a strut more like a very stiff beam that handles pressure as well as stress and they just tend to keep points on two parts in the same position relative to each other. But it does work the other way around as well. Surface mounting tanks to other tanks? (To get like a Sat 5 layout with the engines "sticking out")? I usually place a pair of struts at the "engine mount" tanks because it makes the connection that much stiffer, even if it wouldn't be that effective in real life. The surface mount is really just a point-to-point contact, and adding the strut gives you that triangular relation for stiffness. Consider the Kickback SRB. I usually put the radial decoupler somewhere in the middle, have two struts (one on each side) at the top and and two struts at the bottom. Assuming you have two Jumbo 64 tanks, attaching those SRB's that way will result in a very stiff connection in between (the Kickback is a single part with no internal flex). If it connects at the top with a second stage... well, now you're immobilizing three joints (tank - coupler - engine (plate) - tank) or even four if there's a fairing involved. Of course you lose the benefit once the SRB's are jettisoned but by then you should be beyond Qmax.
  12. You bring up a very good point. In fact,@Nate Simpson should consider that for the tutorials. Mechanical design is as much a part of rocketry as celestial mechanics are. Knowing what increases stiffness is easy, probably even intuitive, for those who are trained at it. Knowing why a tube is nearly as strong as a solid pole, why an H-beam is much stronger in one orientation than in 90° rotated, etc. For me, achieving stiffness is usually a matter of placing a few struts. At the right places. If you don't have a background like that you can make your ship look like a porcupine with struts and still have it noodle. "Struts don't help, the game sucks." KSP does a very good job at punishing wrong designs. What's lacking at the moment is it's ability to teach that (other than showing the results) and with the amount of bugs in the game it's easy to blame the game for that, instead of one's design.
  13. The way it's done in discrete mechanics is representing a solid body as a collection of point masses connected to each other with springs and dampers. From what I can tell in Unity those point masses are then replaced with parts connected through joints. It's far from a perfect model but within the constraints of "lego style building" and reasonable performance probably a good approximation. And more importantly: it's what we're stuck with. This is one argument in favor of procedural tanks. In itself having weakish joints is not a bad proxy for the "things gonna flex" design paradigm, but by nature each joint will multiply the flexibility in a system and you're forced to do so; you quickly need multiple T800's or Jumbo's stacked. Here's an idea for the devs that should be relatively easy to implement: automatically increase joint rigidty to "very high" when connecting identical parts (eg T800 to T800) so they behave as one. Good point. The counter argument is that "boom" is a lot less educational than noodling when it comes to bad rocket design, at least in KSP1. The problem is that right now, as you point out, everybody yells "It'S ThE KrAkEn" for everything they don't like. For me, Kraken attacks are when floating point errors go berzerk and that's in a very limited amount of cases. Not that anyone will listen, but what they can do: Increase rigidity Lower joint tolerance for stresses When reaching, say 75% of failure levels (or whatever works) start playing animations of bits and pieces popping off as an indication that things start breaking. Or maybe even at 100% but have some kind of "failure" buffer that starts filling (faster the more you go over max level) and then break once the buffer is full. You'll end up with visual clues that things are going to break apart before they actually do I fully agree with you that failure is a better teacher than noodling. Especially when rocket designers start blaming noodling on the game, not on questionable design.
  14. Show me the F9 with a 12m payload on top.
  15. There's also a tendency for players to model within the boundaries of the game, not within the boundaries of reality. Partly that's ok, the game only allows for so much and the atmo model is not accurate. But at the same time if you play a little bit more within "would this work in real life" constraints you avoid surprises later on. In KSP1 the launch profile often used was "straight up to 10 km, then slam the ship in a 45° pitch" which was most efficient with the pre .95 souposphere. I always applied a gravity turn because that procedure just seemed ugly to me, but the number of complaints on how the game "was broken" since it now it was now "impossible to launch anything into orbit, my rockets spin out of control for no reason..." Same for descent profiles that allowed entering the atmosphere at a 90° angle at 4 km/s—you'd automatically slow down to 100m/s before opening your chutes anyway. Not that anyone cared because you could have your chutes deployed at hypersonic speeds without ill consequences. It's like using a Mk-I lander can for atmospheric reentry. Yes, the game lets you get away with it. That doesn't mean you should do it, though; and don't complain when the game is fixed and doesn't let you get away with it. Noodling is something similar but it got never addressed the right way. It's not an issue if you launch something that doesn't noodle in the first place. Stop launching noodle rockets, and the problem goes away!
  16. The problem with realistic flex is that it's so little that you don't see it. Metal is elastic; everything flexes under stress. But the displacement it causes is so little that we rarely see it in daily life. Apply that to rockets and they would just break. Visible flex is a bit like an early warning system that you're asking too much of the construction. The problem with KSP is that parts don't flex, only joints. Not only do joints have to be overly flexible to compensate for the lack of flexing in the parts themselves, we also have a lot of them. A real-life booster is a single mechanical entity and not cobbled together from two or three tanks. One of the problems is that most people are, truth be told, lousy mechanical engineers. Everybody has their mouth full about the need for more realism with n-body physics, Lagrange points and decaying orbits, when when it comes to unstable contraptions the response is not "let's build something better" but rather "We NeEd AuToStRuTs." I've never used autostruts. I use regular struts where it makes sense (Medium - Extra Snall - Medium? You bet I connect the medium parts with struts). I don't launch a 5m payload on top of a tall 2.5m rocket. My rockets don't noodle. I'm not saying the current setup is satisfying—far from that. Yes, there is too much noodling but the correct solution is make the rocket break apart, not "make the joints stiffer" or "we need autostruts." It means that you can't just build anything you want and expect it to make it to orbit. That's not always easy. But that's why it's rocket science.
  17. On paper not a bad idea. If Intercept had been upfront about releasing a buggy beta version (for$25) it would probably work, Not sure if at this point with the community turned toxic they want to have two bug riddled versions around. The problem with those beta releases is that you tend to get a lot of downloads for the wrong reasons. I can already see Discord being inundated with “the patched version is even worse”
  18. ...and did you learn from it? Like, testing and fixing issues can take time?
  19. Glad to see we still have Dev Diaries. Thank you!!
  20. That is part of testing too. You don't just want to have a working "KSP2.exe" — you want to have one that works after downloading from Steam. So that part needs testing as well. And then there's this other aspect of testing: sometimes they fail. After all, if all your tests pass every single time, you wouldn't need testing at all. So maybe they had planned to release this Friday, but there were a few failed tests—a bug didn't get resolved after all, or maybe it introduced another bug severe enough to be considered "game breaking"
  21. That's not how it works. That's not how any of that works. They (Intercept) are not going to wait for the patch. Software doesn't write itself, you know. They're going to work—I assume very hard— on creating that patch. The ones doing the waiting are us. Not them.
  22. I don't think any of us had imagined the game being released in the current state it's in, so Intercept has already proven to have superior creativity compared to ours. That being said, there's two things to consider: It's hard—nearly impossible— to think about a Science Mode where Science is not used to unlock new features. I wholeheartedly agree. Until we see how it's done and then it's suddenly blindingly obvious. I'm not saying that Science won't unlock things, it's the most obvious way to use it. But who knows? The "unlocking" part is not the shortcoming we have though. It's the “you did a temperature reading on the surface of Minmus and now you can use ladders" part. that irks most who criticize Science. So instead of relying on a singe experiment the gane probabky demands something more holistic Here are some thoughts of I have on the subject: You can divide your science in various areas, like fundamental physics, materials, chemistry, biology, psychology, economy. Perhaps each area has even subdivisions. In each of these areas you collect science at a steady rate which can be increased by having more science labs, equip those labs with more experiments and by putting more scientists in them Certain technology gets unlocked when reaching certain thresholds, and perhaps a combination of them. A hybernation chamber may require certain levels for physics, biology and psychology. But your tech levels also influences how your technology functions. Engie efficiency goes up with increased understanding of Physics and Materials, etc You'd end up with a system where technology doesn't just become "unlocked," but rather gradually becomes feasible. So instead of collecting resources for 10 years to build a colony ship, you'd rather focus on developing science for 2 years and now you only need 6 years worth of resources. That's a system where things don't get unlocked, just become more and more attractive, to the point where you decide that they're now worth using.
  23. The big unknown is how progressive mode is implemented. Just because there's no money (which in KSP1 led to contract grinding) doesn't mean there are no restrictions.
  24. Check your download, I think something is wrong with it. I have absolutely no problem getting something into orbit, and neither does a whole slew of youtubers and twitchers, so maybe it's your installation, or you, who is doing things wrong. Or maybe you're ignoring the fact that it's EA and you're trying to launch KSP1-style rockets? Whatever it is, they do not need another game to get into orbit without noodling.
  25. At this point everything is mere conjecture. It seems logical that Kerbin has an ample supply of basic materials used for standard rocket parts, and you don't have to actively mine them, they're just there (likely brought in by boat, train and/or truck). However some of the higher performance engines require unobtanium that has to be mined on the moon. In itself it's not so weird that you have to wait for enough material to be collected to build rockets; Werner von Braun had to deal with that issue all the time with his early rockets. I just hope that it doesn't turn into a resource allocation game.
×
×
  • Create New...