Jump to content

Search the Community

Showing results for '�������������������������������������������������TALK:PC90���'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. It's a little bit hard to be certain in retrospective. I said a few things about that already, but some expectations we've all had about where the engines are going in 2020 have came to be, and others not so much. The landscape change quite a bit, and it's hard to now talk about it without the benefit if hindsight. In a similar vein, what we know about the project has changed. Even just talking about what is believed to be the scope of the KSP2 plan in 2017, 2020, and 2023 are likely to have been quite different. So there are quite a few blanks to fill in with any number of plausible options. Lets start with a slightly different hypothetical, one that's almost plausible, albeit very unlikely given the ownership chains and realities of the game market. Say the game goes on ice. About a year from now, my boss tells me, "Hey, Kat, <our company> is in talks with T2 to rebuild KSP2 under license. Want to take this one?" In this hypothetical I have a pretty good picture of what sort of resources and budgets we'd be operating with, as well as have specific people in mind for some of the work. And unless I have to be very scrappy with this, like I get only a skeleton team and just need to make the best of it, I would scrap the code and rebuild everything in Unreal. This is despite the fact that I have access to some amazing Unity engineers in our organization. The mid-2024 reality of Unity vs Unreal is that this is a better route. In part, I'm taking into the account the disaster areas of the KSP2 and that a lot of the code would have to be scrapped anyways, but it's a little bit bigger than that. The advantages of Unreal for KSP2 are quite enormous. I'm not usually this generous towards Epic Games, but they have made several bets and investments in tech that have payed out. Crucially to KSP2, the three areas that are important are the physics engine, procedural placement, and large worlds. Chaos physics is good right now. It is better than Havok and quite a bit easier to use in your flows in Unreal than importing Havok as a middleware. That last part's just the advantage of it being already integrated, of course, and not a dig at Havok. Going with Chaos in 5.4 would eliminate a lot (not all!) of the problems with simulation stability and networking. If you were to start building KSP2 code base from scratch today in 5.4, there is zero reason not to have multiplayer enabled from the go and do all of your testing in server-client configuration. In a similar vein, basically all of the work that Intercept did for planet tiles, painted procedural biomes, and origin relocation for interstellar scaling comes out of the box with Unreal 5.4. We are talking probably the past four years of Intercept's work, about half of their team, possibly more, were building stuff that just comes packaged with 5.4. And it's better. The performance is better, the stability is better, there are more features and options... Note that this all hinges on some assumptions I'm making about the content, and that we'd be able to port over the art and tech art work that was done on planets and rocket parts over. I'm prepared to scrap the code, because in about a year of development we can be fully caught up, and have almost all of the problems fixed "for free" because they are already fixed in the engine. But I'm not prepared to scrap the art in general, and there's a lot of fiddly planet-building work that's gone in, much of which we haven't even seen yet, and throwing that away is a much more expensive proposition. So if we were just starting KSP2 clean today, no contest - Unreal, if we're trying to salvage parts of KSP2 (which is more realistic) I still want to say Unreal, but I'm making some assumptions which might change under closer examination of what's there in the dev folders. Alright, sorry about the long preamble, but that is to set up the question of what would be the correct choice for Intercept in 2020. With hindsight in mind, still Unreal - no competition. Without, there's a lot we didn't know back then. Unreal 4 was well established, and we have seen a lot of 5.0 previews to know what Epic is promising us, but there were a lot of undelivered promises in 4, so grain of salt. I started evaluating Chaos in late 2020, and it was raw then. I think in early 2020 when KSP2 dev work started, my realistic options would have been Havok or Havok. I sort of understand why "Lets use Havok in Unity," wasn't the go-to for Intercept, but I think I would have been prepared to take the risk on ECS and DOTS even if decision was made to go with Unity. PhysX just comes with way too much baggage, and Intercept has rather predictably struggled with it. The only choice besides Havok was building custom, and as fun as that would be, I don't think I'd get a sign-off on the extra budget. So Havok it would be. Now the actual choice of Unreal vs Unity would have been a little tougher back then. The team had experience with Unity and the advantages of taking parts of KSP1 that do work fine or work well enough as temps to bootstrap some parts of development are pretty clear. So it looked like a decent enough choice on the surface but. The big tipping point is what we didn't know about the scope of KSP2, but that was clearly in Nate's mind back then. I'm pretty sure that one meeting with Nate about the art/design direction of the game would have made it clear that scalable, procedural environments for the planets with modern visuals was a big part of the 2020 pitch. And with that in mind I would have pivoted hard towards Unreal. The reason is that the proc gen stuff was already in 4. In a somewhat early form, but we've seen it in shipped games by that point. Unreal 4 also supports tiling and virtual texturing out of the box, which I know are major boons to large world development. One thing I absolutely had in my bag in February 2020 is a year of working on building these features for an in-house engine and I would feel like shaking anyone who says, "We're going to build all of that in Unity." To Intercept's credit, and part of why I'm probably less critical of them than most people here, they made that part work, and it's a monumental amount of effort. Just that alone would have probably freed up2-3 engineers and a tech artist to work on other things in KSP2 for 3 years until EA release. And even Unreal 4's implementation of these things is a bit better peformance-wise. So you'd have better framerate, Havok out of the box, and all the things that would get fixed/built with the extra technical people freed up from that work. That would already put KSP2 in a much better place, and this is just from things that would have been known to me in 2020. Looking back, it's clear that going with Unreal 4 in 2020 would have led to a switch to Unreal 5 in late '21, early '22 and make things even better. There are still a lot of things that needed to be done differently in KSP2 in terms of architecture to make it stable and performant as a game overall, but the engine choice would have been a leg up. If you look at the speculation we've had around early 2020, you might even find some posts from me unsure on whether Unity or Unreal is a better option, but a lot of it was coming from our best guesses on the art/design directions back then, and a lot of that came from by-then outdated articles and previews. tl;dr, a well informed and competent TD in 2020 should have chosen to go with Unreal. Going with Unity was a big mistake, and likely caused by the narrow experience of the technical leadership at the time, who knew Unity almost exclusively. Do keep in mind that I am saying that with the advantage of hindsight, as much as I try to compensate for it. Rolling back to 2017, we're in a completely different world. Not only is the tech different, with a lot of the features that would make Unreal a clear winner still very early in development or even entirely as unannounced plans on the roadmap, but also the scope of the game was different, as far as we know. I'm not going to spend too much time going over this. Assuming that I understand correctly that the pitch for KSP2 was, "Take KSP1, make it look shinier, add a star system, and do some cool colony-building gameplay," Unity was the right call. You'd be able to reuse much of the work that KSP1 team did, both under HarvesteR and later with new tech team at Squad. And while at the time it would have meant steaking with PhysX, we're also talking about a smaller game where a lot of KSP1 patches on top of that would have been adequate. Especially if multiplayer wasn't planned at the time. So I think Star Theory's plan for KSP2 was fine and probably would have panned out if the scope didn't expand so much. We'd probably get KSP2 in 2020, and it'd probably look like KSP1 with some visual and interstellar mods and colony gameplay. Hopefully, with some loading issues addressed, since ST would need to improve on them for interstellar. It'd be fine, and most KSP1 players would probably jump over to it. In terms of general changes I would make compared to how KSP2 seems to have been developed across both iterations, I'm just going to run through bullet points. Introduce compound rigid bodies. It'd be exposed to Chaos/Havok/PhysX as a single rigid body, but we'd be able to compute the stress on implied joints between the actual component parts of it. So if any limits are exceeded, it can still break, and if it crashes into the terrain, parts of it could be destroyed rather than all of it at once. I've mentioned advantage for colonies, but you can also use it for physics LoDs and crucially for things like a tank with a decoupler or docking port on it. The latter parts are very light compared to the tank, making the joints flimsy. Turning this into a single rigid body would make all the joints so much more stable even if we're talking about KSP2 2017 and we're doing this in PhysX. So many physics problems would just not. Don't rely on game physics for any part of orbital motion simulation. The CoM of every ship should be on its orbital element rails, with any external forces (sum total of all engines or a binary planet situation) added together and applied to the ships in this bespoke simulation. So even if you're focused on a ship, yeah, it should be simulated for any rotation, part flexing, joint stress, etc. But the net force applied to it should go to the external, bespoke orbital mechanics sim that just moves the ship's CoM. And in your local view, the ship's CoM should be reset to that position on every frame to nulify drift from any Kraken forces. Energy and momentum should be conserved, full stop. Build the data representation incrementally, testing along the way. Playtesting, QA testing, and unit tests everywhere. The KSP2 data mess looks like the team that worked on saved games, editor, and actual simulation never talked to each other. I don't know how that happened, I wasn't there, but I'd like to think I can avoid that kind of a disaster. It's just bad. There are also performance considerations that are graphics related. I'm not a graphics engineer, though. And I don't know how much of what we've seen in KSP2 is really a tech problem, and how much is just tech art not having had an optimization pass. It's very easy to make a quick and dirty shader that does the job but is awful on rendering performance, and you see a lot of that in early alphas. Given that EA is pre-alpha, I'm not sure how harsh I should even be on this. But the bottom line is if there were tech issues, I don't know if I'd know how to fix them. But I also don't really need to. The most important bit is knowing how to find people who can do these tasks. I think a lot of bad calls in that regard were budget restrictions, but it also seems like tech leadership at Intercept hasn't done an ideal job of it. So that's sort of the final part of it. And as a final note, a lot of what I wrote here is criticism, but I know where some rakes are hidden, and I don't know how many rakes Intercept avoided that they knew about that I don't. I think I could have made a much better KSP2 from the purely technical perspective whether I was given the TD on it in 2017 or 2020. Would KSP2 be a better game overall? I don't know. It'd be less broken, but would less broken KSP2 that looks like garbage and has almost unusable UI and editor be better? (Not saying as a necessary cost, but purely as a hypothetical, knowing that these are areas where my own expertise wouldn't be enough.) I don't know. So don't levy all of that against ST or Intercept. This is purely a list of ways that would have been available to make things better if somebody with the right talents was on the team, but everything's an opportunity cost.
  2. Building with FAR 101 – Barebones Basics First off, I''d like to thank tetryds, both for advice and corrections he provided in the course of writing this tutorial, as well as the awesome BAD-T tournament he is running that led me to write this tutorial in the first place, that it might be of some use to those who want to enter but might not be familiar with FAR . With that out of the way, lets begin. Ferram Aerospace research is a mod that aims to bring real-world aerodynamics and aerodynamic principles and mechanics to KSP. As a result, building an aircraft is now a bit more complex than in the rather more forgiving stock aero model, as planes must now be built to take into account various real-world aerodynamic design considerations. This will not be a comprehensive overview, it won't tell every trick in the book on how to make a competitive performance dogfighter, but it should adequately cover the basics sufficiently to build a successful subsonic aircraft that avoids plowing into the ground seconds after launch. Lets start by building a basic airframe: This consists of a KAX D-25 radial engine, a structural fuselage, an inline cockpit, a liquid fuel tank, and a tail adapter. Now, before we add some wings, we should first know where the Center of Mass (CoM) is. This is important, as it will greatly affect wing placement and aircraft balance later on. On the sample craft, the CoM is here: Also activated are the Center of Thrust and Center of Lift indicators. Now, the CoL indicator here looks different from stock; there's no arrow. In FAR, the CoL functions similarly, but not identically, to Stock. In stock, it indicated the net direction of lift provided by lift forces from the wings and other lift surfaces, in FAR, its simply the Aerodynamic Center. It can still be used to get a rough approximation of craft balance, but for learning precisely how a craft is balanced requires the FAR editor readouts, covered later. So lets add some wings: With wings on, it's looking more like a plane, but there's still some work to do. Control surfaces need to be added, and the plane balanced – as seen the CoL is slightly ahead of the CoM; this plane will want to pitch up, potentially leading to a stall and possibly crash. For a successful, easy to fly craft, the CoL should be behind the CoM, the aircraft should want to naturally pitch slightly downwards while in flight without control surfaces. To correct the imbalance, there are a few available courses of action: The mass of the craft could be shifted forward, the wings moved farther back, or the empennage lengthened to shift the tailplanes back and offer better leverage on the craft once control surfaces are added. A quick craft re-arrangement later, and : A bit unorthodox, perhaps, but serviceable. The wings were moved back, and the structural fuselage behind the engine was moved to behind the fuel tank, which puts all the heavy things at the front of the craft. As a bonus, the main wings are now on the CoM, which will help with performance, as the main wing is the point the craft will want to pitch up or down; the closer the CoM is to this axis, the less leverage needed to affect pitch. Additionally, the main wing is also located on the fuel tank, which means as the craft files and the tank is drained of fuel, the overall CoM of the plane will more-or-less remain where it is. Knowing where the Dry and Wet CoM on the craft is good to know. If the CoM shifts too much as fuel is used up, it may result in the plane becoming unstable. To control the aircraft, control surfaces are needed. Lets add some: The craft now has a pair of ailerons, a pair of elevators, and a rudder. The ailerons are located at the main wing tips, and provide Roll authority, the elevators are on the horizontal tailplane and will control Pitch, and the rudder on the vertical one will control Yaw. keep in mind the principle of leverage; ailerons/elevons (control surfaces that control both Roll and Pitch) that are located near the fuselage will be less effective at rolling the craft then if they were placed further down the wing, likewise, the further from the CoM the elevators are the more efficient they are at pitching the craft. Elevators placed inline with the CoM won't have any effect at all (i.e. if the ailerons in the picture were set to control pitch, they would have negligible effect due to how close to the CoM they are).. By default, a newly placed control surface will be set to respond to Pitch, Roll, and Yaw commands; while leaving control surface inputs default generally speaking won't keep you from flying, it may cause the craft to do weird things, since the rudder will be trying to pitch or roll the plane, the ailerons will be trying to adjust the craft's Yaw, and so forth. To adjust the control surface's inputs, right click on it to get a context menu: Std. Ctrl is the control settings needed here. Flp/splr controls flap and spoiler settings, covered later, and curWingMass is how much the wing weighs, with Mass-Strengt... 1 is the wing/control surface structural strength, also covered later. Clicking on the Std. Ctrl button opens a new menu: A few more options than in stock, no? Pitch %, Yaw %, and Roll % are pretty explanatory, these control that respective input. The 100 means that at present this surface will fully deploy in response to an input. This number can be changed from -100 to 100. having a Pitch at less than 100 means the surface will only deploy partially in response to an input, and a negative setting will have the surface deploy upside down, useful for things like front canards and so forth. AoA% is the Angle of Attack percent. Instead of reading a P/Y/R input, it reads the crafts current AoA while in flight, and dynamically deflects the surface in response to it. This can be set from 200 to -200; useful for things like wing slats or having a plane that could automatically pull out of a dive, that sort of thing. Brake Rudder sets if the control surface can be used for affecting Yaw like an A.I.R.B.R.A.K.E.S. part – perfect if you want to make a Ho-229 /B-2 type flying wing, this lets you maneuver without vertical rudders. Ctrl Dflect is important. This determines, in degrees, how far a control surface deflects. The lower the number, the less deflection, and the slower the pitch/roll/yaw effect propagates in flight. Because FAR models aerodynamic stress failures, or in other words, too aggressive a maneuver and the wings rip off, being able to adjust the control surfaces so they don't result in a 15 G turn and Rapid Unplanned Disassembly of the craft is vital. The other, less immediately fatal thing adjusting Control Deflection will do is help prevent stalls from overaggressive maneuvering. Too much control authority for your elevators and you risk pitching the craft's AoA too far from prograde, resulting in at best higher drag, or worse, throwing the aircraft into a stall. A lifting surface stalls when its cL falls too low; in other words, when a lifting surface stalls, it drastically reduces the amount of lift it generates; too little lift, and the craft falls out of the sky. Now, what about the Flp/Splr setting? Lets take a look: Clicking the Flap setting will designate the control surface as a Flap; flaps are useful for take off and landing, when extended, flaps provide greater lift at lower speed; they also cause more drag. Flaps shouldn't be extended much or at all in normal flight. When a control surface is a flap, extending/retracting can either be done via right click menu while in flight, or via action groups. Clicking the spoiler button actives that surface as a spoiler. In KSP, spoilers are basically airbrakes; they are automatically added to the Brake action group, and when the brakes are activated, the spoiler will deploy. Be careful when placing spoilers; place a spoiler in the wrong place or upside down, and you may discover that rather than a brake it is instead acting like a flap or an elevon and affecting the craft's flight differently than intended. Now, lets talk about Mass-Strength. Mass strength adjusts both the mass and the strength of a wing. The stronger the wing, the more aerostress it can take before catastrophically failing. The slider goes from 0.05, for a wing that is basically made out of paper mache and prayers to 4.0 for a wing made out of adamantium. For a a spaceplane, a wing setting of 0.4 or so should generally be sufficient, for a subsonic stunt/sport craft doing acrobatics at low altitude, a higher wing strength is recommended, something like .6 or so for a light weight craft. Keep in mind, that a wing strength that works for turns at 100m/s might not be sufficient for puling out of a dive at 240 m/s. While there is nothing wrong with a higher wing strength, keep in mind that stronger wings are heavier; the standard Wing Connector A, with a strength of 0.05, weighs 15 kg, the same wing at 4.0 strength weighs 1237 kg! With a basic plane built (yes, it still needs things like landing gear, but those are unneeded for now), its time to see how well it will fly (theoretically). To do this, open up the FAR editor window in the SPH/VAB by clicking on the FAR icon in the toolbar. When this is done, it brings up this: This is the Flight analysis graph, which will display some information on the flight characteristics of the craft in various flight regimes. Currently here it is set to AoA analysis, which will show how the craft will handle at various angles of attack. It can also be set to show how the craft will perform at various mach numbers by clicking on the Switch to Mach Sweep button. The numbers at the bottom adjust the parameters to be tested. By default it is set to examine the craft from 0 to 25 degrees AoA, at an airspeed of mach 0.2 The side bar buttons are craft and environment settings. Want to know how the craft will fly on Laythe? Select it from the celestial bodies menu. You can also see how the craft will fly when flaps and/or spoilers on the craft are deployed. Lets see how the example craft will fare: The mach value has been adjusted to 0.35, (around 120m/s), and the upper AoA limit has been increased to 50 degrees. The graph displays a number of lines: The green line what the craft's lift/drag ratio is as the craft sweeps from 0-50degrees AoA. Looks like the craft will get the best lift for the lowest drag at around 5 degrees AoA. The Blue line is coefficient of Lift – how much raw lift does the craft generate. The blue line goes steadily up until about 35 degrees AoA, and then starts falling. As the line goes up, the more lift the craft is generating. The tip of the cL curve at 35 degrees is important, this is the point the craft will begin to stall. The red line is drag. As AoA increases, more wing surface area is exposed to oncoming air, generating more drag. Here, the line increases until about 40 deg. Of note is the area around the intersection of the red and blue lines. At 35 degrees, L/D increases slope slightly, and at 40 degrees it begins to plateau, combine that with the the correlating decrease in cL and it shows the aircraft stalling at 35 degrees and coming to a full stall at 40, pitching the aircraft that far up should be avoided. With stalls, main wings are the easiest to stall out, other lifting surfaces like tailplanes are a bit harder. The final line, the yellow line, is a measure of craft stability. The lower the line, the more the craft will want to return to a neutral state. Here it steadily goes down, looks like the craft will automatically recover from an AoA induced stall of the wings and bring the nose back down to a prograde vector. The value of the line factors into this; the steeper the slope of the line, the more aggressive the return to a neutral state. the more aggressive this movement, the higher the G force the airframe is subjected to, the more G's, the stronger the wings will need to be. The second page of the FAR editor window that is important is the Data/Stability Derivatives. This page can be access from the drop down menu in the upper left currently reading Static Analysis going to it, and: A bit scary and technical, isn't it? Lets walk through it. At the top there is a planet selector (again, if you want to know how the plane will do on Laythe/Duna/Eve, or for the suicidally insane, Jool). The next is altitude, in kilometers, from sea level. As atmospheric density and temperature change, so to does aero performance. The last is speed, in mach, for the same reason; higher mach results in different aerodynamic considerations and fun engineering challenges like dealing with the trans-sonic region supersonic drag, which won't be covered here. Lastly, flap/spoiler settings can be set. On to the numbers. The Calculate Stability Derivitives button has already been clicked, so the stats have data to them. The first set of numbers at the top are technical data about the craft. Of note is the wing area, which can be used to determine the craft's wing loading. The higher the wing loading, the more mass per square meter the wing is supporting, and the stronger the wings have to be, but higher wing loading also means less drag. Lower wing loading means the craft has more drag, but is also potentially more maneuverable, dependent on control surface settings. Also of note is the level flight numbers,which tell the the chosen mach speed in m/s, AoA, and the coefficient of lift for level flight at the selected planet, altitude, and speed – in this case, the craft needs to have an AoA of ~2.4 degrees when flying at ~119m/s (the input mach 0.35) for level flight at sea level. The coefficient of Lift can also be used in conjunction with the static analysis graph, go back and look, and the cL of .157 shown here will correlate with the blue line on the graph. Next up are the Longitudinal and Lateral Derivatives, each of these reference a particular type of movement about an axis. These should be green, any numbers in red indicate the craft will exhibit an unwanted behavior, and the higher the green number, the less that particular kind of negative craft behavior is a concern. In particular, lets look at Mw. This number tells how much a craft will pitch up in neutral flight. The number is -.114, which means the craft will very slowly pitch down in normal fight, which is to be expected with the CoM head of the CoL. But what if we moved it? Lets see what happened: Mw is now red, with a value of 0.08. the craft will now want to pitch up in normal flight. It wont pitch up very fast, but it is still a motion that will have to be actively corrected through trimming the elevators or applying active inputs to them every so often. As with higher numbers being good when green, higher numbers when red is bad, the higher the number, the worse the detrimental effect. When a number is red and very low, it isn't the end of the world, and can easily be corrected by the control authority the plane has. For numbers bigger than around 0.5 - 1.0, a redesign of the craft is suggested to reduce the number, or even better, make the value in question green. In many cases this will be minor tweaks to wing and control surface placement. In the case of large numbers (3.0 - 4.0 and above) major structural redesign will be necessary.
  3. Vitriol doesn't make this argument any more sound, not that it had any substance to it to begin with. We can talk about which game you like all day, but if you wanna talk objective stuff like the technical side, there's no place for opinions there. KSP2 is a broken, unplayable, badly designed mess, left incomplete and wincing painfully on the ground after being unable to gather interest, sales, or any sort of trust in whatever might come out of it long term. This is not to say that KSP1 is perfect, far from it, but hey, one is still being played by thousands, with a myriad more playing hyper modded saves, making vessels in the thousands of parts, adding planets to it, clouds, obscene levels of detail, gigabytes worth of parts, mission packs, entire mechanics, and it refuses to break under all of that except for some very specific cases.
  4. People do not like to admit culpability in a situation like this & Nate is ever the spin master. Anything taken from Nate will always be "We did an amazing Job. Things were out of our hands" or something similiar. Where I personally do not think that the responsibility lies with the individual developer. Even if it did, No one will come out and say "we did a bad job" .. "it's our fault" The game WAS pushed out in a rather poor state and could support the Parent say this outcome and was preparing for it.. but I'm just saying.. Nates literal job is to talk a good game.. and he's good at it.
  5. Out of curiosity, especially since you clearly have, likely, the most (and most relevant) experience in game physics programming out of everyone who frequents this forum: if this were your project and you were in the position were you got to make the decisions, what game/physics engine would you use (for sake of relevance, say, both if it was started now and for if it was started in the 2017-2020 range, like ksp2 was)? Since all we can really do now is talk about what ifs, and I (and others, I think) always value your insight, it would be quite interesting/educational to read. Also, If you want to go into what your overall approach would be if you were engineering and/or game lead, too, please be my guest (it would be quite interesting, I imagine). I know, though, that you've given aspects of that already (though putting it all together would still be of value), and it would easily be mass wall of text that you may or may not feel like like writing, so do what you feel like. (for a given value of force). But, if you genuinely WANT to, please do.
  6. I have seen Satire of this very situation on television. It is a trope I feel has been displayed enough to have been immortalized. Random individual conveys some sentiment with simple arithmetic to emphasize a general feeling of disappointment. Then a figure emerges from the back of the room. Crowd parts & a shadowy out of focus frame slowly center on the individual. Long well oiled mustaschio twirled idly between for finger and thumb... " weeeellll... seems we have a misunderstanding. Let me educate the poor farmers" proceede with circular talk to convince *farmers* some unrelated point in somehow relevant to their disappointment.
  7. This discussion reminds me too much on my time in World of Warcraft. I spent almost all my teens on that game. Was it part of my life? Clearly. Did it teach me something? Certainly something about progress, motivation and goals. But is something lost because I don't play the most recent patches since many years now? I didn't play as much KSP as some of you guys - shameful 2~ years to be accurate - but a big take away from my gaming experience is that the biggest slice of any game teaching or telling you something is always achieved in the first steps. Most things happening afterwards are reiterated over and over again until the player is mastering his skills to meet some kind of end goal proofing you're a specialist. There is only one problem: Some games have no end goal. KSP is just such a game. The deepening of some skills might be fun and such but there is nothing obvious you lose. If you can talk about life altering things you probably have learned it already. You have taken it and nobody can steal it from you anymore because it's in your mind now. The only thing you really lose - and that's very precious for many people - is your passion. I understand that. Passion never really falls from the sky at any time. It's like a rare moment in life where you make the right decision and hit the point and now you ride a wave for a longer period of time. But at the point where you only feel pain or think your life depends onto it you should try to rethink whether you still ride this wave or not. Maybe you're on the surfboard, thinking you have a safe stand these days but in fact the sea is just dry and your board standing still on the sand. Maybe -and I certainly don't want to judge - you just don't want to see it like it is. If you play this game for so long it makes sense to me. Nothing holds up to eternity. It didn't do it for me at least. I see it like this: If I hadn't stopped WoW, I would never have played KSP. Maybe there is the next best thing around the corner waiting to be found. You just don't know it yet. Endless missed opportunities because you play KSP for so long. Oddly, no one is talking about that.
  8. The title is pretty self-explanatory. On the anniversary of a milestone of aviation and spaceflight history, post about it here. It can't just be events you think are significant; the name of the game is "This Day In..." The event in question has to share the same month and day as the current date. e.g. if it took place on December 17, 1903, you'll just have to wait until December 17, (whatever year it is now) to post about it. Replies discussing events already posted DON'T have date limits; just the events themselves. In other words, you're free to talk about any events mentioned on here as far long or as late as you wish. Links to sources are highly encouraged. Even if you first learned about it from the Air Force Museum calendar, we would all benefit from some corroboration. It can be as significant as a first test flight or a shuttle crash to something not-so-well known - such as the Army Air Corps delivering mail for the first time or the first successful V2 rocket launch. The choice of event is yours, but the "Anniversary Posting" rule still stands. Have fun, and I can't wait to read what you all come up with. I'll start us off. October 14th, 1947 - U.S. Air Force Captain Charles "Chuck" Yeager becomes the first man to break the sound barrier using the X-1 rocket plane. Source: https://airandspace.si.edu/stories/editorial/breaking-sound-barrier-75th
  9. Well... I just learned something about medieval history. Probably can't teach it at my school, even though I do talk about some of the crazy shtuff the Normans got up to back then.
  10. Yes. Big part of that is the handling of non-owned vessels in multiplayer, to make the physics of N-parts aircraft manageable in a game that allows you to shoot off every single part individually. The solution they found "sacrifices" wobble (lol) amongst other stuff, to make offloaded vessels a single integrated part, but keeps the capacity to calculate hits and damage to individual parts. It's very probably an iteration of the KSP1 proto-vessel method. Mind you all vessels are still able to grab fuel/battery from their containers correctly. Like really, at this point you're just throwing vitriol around with zero knowledge of what you talk about. You hate HarvesteR and KSP1? fine. But don't try to pass your hate as anything more but your personal views.
  11. Im pretty convinced at this point they'll leave that roadmap on the steam page after firing everyone until there's a lawsuit more threatening than the sucker-sales of people who don't know its abandonware--which is never. I will never buy a product from PD or T2 ever again and I'll warn off everyone I talk to about games. These are trash people.
  12. Like the majority of the community, I am sickened by what is happening. I feel like we got bamboozled, even worse now than when TT put the game on sale 3 months after selling it at a premium price. I was pretty vocal then that it smelled fishy, and that it reeked of greed that the company would sell it at $50 to those of us who wanted it right away, but then decreased the price as a "sale" to get more buyers. It sounded like they were fishing for more revenue to justify keeping the lights on, and some of us were pretty loud about that. Couple that with the complete lack of communication we had to go through. EA, at its core, is supposed to be a way for developers and consumers to interact while a product is being developed, right? They push out an incomplete game, we buy it, we give feedback, they communicate that they've received feedback and are implementing x fixes, we get the updates, we give more feedback, they talk to us, round and round we go. Right? Not here. Not with KSP2. We begged for the company to talk to us. Tell it to us straight; we aren't going to be upset if you have to delay or come back and say that things aren't going the way you wanted them to. Just talk to us. That's all we asked. And they refused. They got our money and then left us in silence. Sure, we got a dev blog about this lighting issue, or eclipses. We had, at one point, the KERB to tell us what they were working on...but then they took issues off that list before stopping it altogether. All told, we were taken for a ride. And we paid for that privilege. The company said "Hey, we've got this thing that isn't done yet, but give us cash and we'll call it EA and you'll eventually be rewarded". And like horses to water, we lined up and shelled out our hard-earned money. Which they took, and then gave very little - if anything - in return. We paid for the right to be ignored and shut out of development news. We paid to have the community fractured, friends yelling at each other, and the company laughing at us the whole way. We paid to go through this. This exercise is exactly why I didn't get into EA releases with other games that are in my library. I only 1 time before entered EA or a beta-playing phase of a game before, and that was for Harebrained Schemes' Shadowrun. Which went off without a hitch, by the way. But even with that good experience, I had read too many times where things just fell apart and didn't work. Heck, I was close to going in on Cyberpunk, and I'm glad I didn't. But KSP? I couldn't resist. My better senses were telling me to wait, but my heart over-rode them. And Take Two broke it. All told, and to finally respond to what you wrote (I took long enough to get there, didn't I?), I doubt anyone gets a refund. Doesn't matter if you went Epic or Steam, the refund "rules" are pretty clear: less than 2 hours played, less than 2 weeks after purchase. And TT will hide behind that as a way to make sure they don't have to fork the cash back over to Steam or Epic. It would be a nice gesture if they did...but it won't happen. That money is already pocketed and spent (so to speak). So what can we do? Nothing. Not a damned thing. Sure, we can post and protest. Sign one of the petitions going around right now. Take up coding and try to create your own game if you must (even I downloaded the Unreal Engine last night and am going to give it a whirl). But nothing we do is going to amount to anything. We aren't going to change their minds, we aren't going to get our money back, we aren't going to be able to save the franchise or the studio or the employees who are out of jobs. Nothing we do in the end will matter. Where does that leave us? Hopefully being cool to one another. Perhaps talking about KSP1. Maybe finding other games to enjoy. But KSP2? Gone before your time, and we barely knew ye.
  13. I think there's more than one thing that's going on. Modern approach is to use velocity constraints with Baumgarte stabilization for drifts. Baumgarte does work a bit like a spring coefficient, but the velocity constraint already has damping built in. So with a sensible choice of coefficients, any perturbations should naturally decay, rather than lead to more oscillation for any single joint. Unfortunately, systems of joints can still misbehave. The worst case is usually a light object sandwiched between two heavy objects. Unfortunately, I just described every single stage separator and decoupler, which immediately becomes a problem in KSP if you don't add additional joints to stabilize it (such as multi-joint connectors, autostruts, etc.) A very good read on the topic is Erin Catto's GDC presentation from 2009, Modeling and Solving Constraints. Every modern physics engine I've seen goes back to this talk. At a minimum, Havok and Chaos do, as well as Crystal's and Blizzard's internal engine implementations because Erin Catto worked there and was instrumental in making sure these engines worked. Now, not every engine uses impulse exchange as their iteration method, but all iterative solvers are going to behave similarly. I think Erin really likes impulse exchange mostly due to its logical simplicity compared to pure linear algebra methods. Crucially, the PhysX version that ships with Unity predates the industry's switch to this as the main method. So their constraints handling might be a little different, and I haven't looked at the code for that specifically. Though, it might be interesting to try and dig up the source for a relevant PhysX engine and to make sure. In general, even the older physics engines had to solve the same fundamental problem of enforcing constraints. And even if you start with position constraint (rather than velocity constraint) and work your way from there, you are still building a damped harmonic oscillator, but your coefficients might be less "magical" and require more careful tuning. So we're still dealing with what's ultimately a damped harmonic oscillator for each individual joint, but what can still fall into some sort of a bad feedback loop between multiple joints. And we know that mass ratios are a problem for the PhysX joints as well, so whatever the solver is iterating over, it's not that far different. So that's one part of it. Even with a good solver, there are bad configurations that you need to learn to avoid, and for something like KSP that means either merging some rigid bodies together (e.g., if you made decoupler and whatever it's permanently attached to into a single rigid body) or doing what KSP1 does and adding additional joints in a way that avoids the unstable configurations. The second part is, I think, what muddled the situation for KSP2. And here we're back to logical connection vs actual joints. I have seen a number of times when a ship spawns in (either at the launch site or from a save) with some parts detached. And it's one thing to just watch some part of your ship drift away, and another is if it's some internal part with collisions that ends up doing a ragdoll-spaz inside the ship. I don't know how many of the KSP2 physics explosions are due to bad joint configurations and how many are due to a part getting loose and spazzing out. I've definitely seen both, but I wouldn't be able to identify each particular case. And I think that might have been why Intercept kept having these issues creep back up, because there are several different bugs they're trying to fix that can be reported as one bug: rapid disassembly without any obvious cause. All of this is kind of self-inflicted, but I do sympathize. Again, it's a hard problem, and unless you happened to have worked on these exact problems before, it takes time to catch up on all the terminology and required reading.
  14. I feel there was a balance they failed to hit (talking about direction as in the general sense of the finalized vision for the game). The heavy work on tutorials already tells you they were going for "we take this niche game and make it accessible to even more people, it'll definitely sell more." FS! followed on that by simplifying and linearizing the tech tree and having science be a single magic button, where you can absolutely skip even the timers so long as you hit it every time it flashes. Lastly, they also wanted to tell a semi-linear storyline through missions, discoverables and their lore. That part was really good, the new user onboarding was a magnitude better than KSP1. On the other hand, the game really required a strong technical foundation because by the time the difficulty curve of rocket launches and SSTOs is over, almost every player just goes big. Here is where to me they completely failed, by making a game that doesn't support this second bit. Of course now it'll all be woulds and coulds, but it's not hard to see that even without colonies we were already still finding the limits very easily (another example, another one, another). 8000 parts might sound like a lot on that bug report, but that's about a constellation of satellites, a couple rover missions, and a Jool 5 vessel. Meanwhile the game was supposed to allow you to do that on multiple star systems, whilst supporting trust under timewarp... and just no, the game could never be able to do that with the foundation it has. Also, as a last nail in the coffin, they forever handwaved the explanation of how Rask & Rusk (the binary system) were going to work. So yeah, we have a game built on flimsy foundations that they just outright refuse to talk about (remember the promises of HDRP and the system that'd replace PQS? I do), we have only the most basic stuff (yes, science and a tech tree is very basic, deal with it) implemented and none of the complex problems, and not just that but whatever little we have is already making those foundations quake... That's why you can google me saying "technologically bankrupt" multiple times. The balance they failed to implement in game by only including stuff for new people and nothing for veterans, was the same thing behind the scenes: they were doing only the easy stuff whilst completely neglecting the complex stuff and much less having the stones to talk about it. At this point I doubt they even had a plan past "cut everything down as manageable as possible", which is what net us all in one parts, gimped heating, the horrible coordinate reset on ground vehicles, and so on. I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.
  15. The problem for Take Two is that they are in a position whereby anything they do is doomed. There are only 4 scenarios that play out for them this morning. Scenario 1 Take Two comes out with an announcement indicating that yes, the studio is closing, but they are going to continue development under a new studio. So sorry that this had to happen, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry and we promise things will be better from here on out. The community will respond with varying levels of "you went through this with Star Theory" and "you have continuously delayed this game" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 2 Take Two comes out and completely dismisses the rumors and stories, indicating that things are just fine and there is nothing to worry about. So sorry about the misinformation, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry and we promise that this will not impact KSP2 in any capacity. The community will respond with varying levels of "we've been asking for more communication" and "you have lied to us in the past" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 3 Take Two comes out and flat admits the project is canceled. So sorry this had to happen, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry to anyone who purchased the game. The community will respond with varying levels of "we told you this would happen" and "you made all these promises" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 4 Take Two says and does nothing. No explanations, no messages, no communication. The community will respond with varying levels of "why aren't you telling us what's going on" and "we just know it's canceled so rip off the band-aid" and they'll raise pitchforks and burn TT's buildings to the ground. There is nothing that Take Two can do in the immediate future - today, tomorrow, perhaps the coming weeks? - that will ease tensions and make this all right. Unfortunate for them, and unfortunate for the community.
  16. The CMs certainly are not at fault. They only acted within the scope of their abilities at any given time. Thay must have been a pretty excrementsty burden to bear... wanting to talk about really cool stuff thay was almost ready .. just need to figure this out or that.. and not getting to talk about it at all. I feel like the CMs kinda got the crappiest deal of all. The industry has exploded since early 00's. A vote based system to enter EA is longer relevant. And I know nothing is perfect.. a large group of angry incels could still slam whatever feature and initiate unfair action. But with people behind the oversight, this would be obvious. This sentiment has been fermenting for a bit over a couple (one) other titles I wanted to be excited about but feel developers employed less than genuine approach to EA. It may shape up to be alright in the end.. the massive breach of trust doesn't occur in the community over singular incidents. It's not like we freaked out over price, or routine delays in communication, then postponed delays of communication, lack of technical dev blogs, incinere AMAs... it was a culmination effect. @chefsbrian obviously titles with awesome customer relations and positive review rating would not be one brought to question. im not asking anyone to adopt a unilateral set of qualifiers for EA. Merely adhere to the standard each puts forth on their own EA store page. Each one answers certain questions about what EA means to them & how they intend to approach various benchmarks for the guidelines. There isn't even a scope set forth in the guidleines with a set of minimum acceptance criteria.. beyond game must be playable & not provide blatantly inaccurate info. There is no minimum required engagement for the community feedback nor a set bar for how frequent we should get announcements of any kind. But the development staff sets that expectation when they fill out the little questionnaire & it enters into writing. That is the first step of a relationship where trust Is a factor. That trust is based on what we read on that page. (Very few read anything outside the Steam page)
  17. I've been working on a CubeSat for the past 2 years, mostly software and testing, and we uploaded the final code onto it yesterday, it is flying to Texas for integration in a few hours, and will be launching into space on Cygnus NG-21 probably sometime in August, and ejected from the International Space Station probably in Fall or early Winter. (picture was very zoomed out, that's why it is a bit fuzzy, I zoomed in) This is CySat-1, a mission to prove the viability of measuring Earth's soil moisture levels using a software defined radiometer (and also to prove that an undergraduate led satellite program at our university is viable). There's many subsytems involved: Endurosat OBC, tells everything else what to do Endurosat UHF antenna and transceiver, how we talk to the satellite, has the worst documentation of any of the modules and took us a long time to figure out how to use. CubeSpace ADCS, has magneto-torquers, star trackers, Earth sensors, a magnetometer, GPS, and a reaction wheel to figure out where the satellite is and point it in the right direction. Endurosat EPS, manages power collection, the batteries, and power distribution throughout the satellite A breakout board with numerous electronic components soldered onto it for toggling power and converting voltages PumpkinSpace solar panels, we bought them (really expensive) after failing to build our own Analog Devices AD9361-Z7035 FPGA/SDR/SOM/whatever you want to call it. Power hungry computer that is only on sometimes, and runs our scientific program using GNU Radio and Python on an Analog Devices Linux Distro Analog Devices ADRV1CRR-BOB Carrier Board, holds the other Analog Devices board and distributes power and data to and from it Mini-Circuits Low Noise Amplifiers and Bandpass Filters to amplify the signals from the radiometer antenna A custom antenna for the radiometer And on the ground: An Ubuntu desktop computer running a GNU Radio flowgraph to talk to the satellite A software defined radio and antenna (we will get a bigger antenna in the next few months, the one we have is temporary) A Windows laptop running a python program (the ground station front end/GUI) to communicate with the Linux server I have been a programmer for CySat-1 for the past four semesters, programming lead for the past three semesters, and the only programmer for the last semester. My job has been to get these 7 computers made by 4 different manufacturers running 3.5 different operating systems in 2 separate programming languages talking with each other seamlessly. For the most part, we have succeeded, and the satellite has worked during short term ground testing. Unfortunately, we ran out of time for long term testing due to an issue with charging the batteries. This project has been one relentless string of failures and setbacks and frustrations, so long I'll probably make a video essay about it at some point. It felt like bashing my head up against a wall repeatedly only to find another wall on the other side, over and over and over again. I'm not very optimistic about our chances for successfully completing the mission, we have at least one possibly unresolved critical bug with no leads (and no time to fix), and given that we were discovering bugs literally up to and including the very last day, there's probably more we don't know about. But I learned a lot, enough that success is one of the possible outcomes. While it is supposed to do a lot more than beeping, I will be happy if it beeps. I'll be even happier if it will beep on command. Anything after that is purely bonus in my mind, especially given that half of university CubeSats don't even get a beep back, so I'm told. I'm proud of how much we managed to overcome, and that this thing finally got shipped off after years of delays, the satellite having been originally conceived sometime between 2002 and 2017 depending on what you take as the start date. That picture is an expression of equal parts "We finally finished it!" "Oh boy, what if I forgot something? What if it fails because I forgot to change a line of code, and I won't know for another six months!" and "What now? This has been my big thing for 2 years, where do I go from here?" In a really roundabout way, KSP is one of the reasons I found myself on this project. Part of that was just because it awakened my love for space, but another part of it was that the organization that manages CySat has a bunch of other project teams, one of which was a KSP simpit. I was on that project for one semester because a friend told me about it. When the KSP simpit project shut down, that same friend invited me to join CySat. It has certainly been an adventure that took me far outside my comfort zone. When I started, I didn't know a lick of C, and barely knew two licks of Python. I came in wanting to do structures/CAD stuff, as I felt that would be what I would suck the least at. But through a quirk of fate, got put on programming instead, something I did not at all feel confident doing. After a lot of pain and a lot of learning , the inter-computer links fell one by one, and we got it to a point where everything (discounting the single use stuff we weren't able to test) works in short term ground testing. While obviously we would have preferred to do more extensive testing, at this point, for a variety of reasons, we've just got to send it. About eleven years and about two weeks ago, I launched my first Kerbal into the sky, and now, a spacecraft I worked on is getting launched for real. Hopefully, when it gets up there, it shows up as a probe and not as debris!
  18. Sounds like management wants to keep the product page up and just not have to talk about it again. It got full funding for as long as it was going to. It just isn't worth it anymore compared to other places to put money. So unless the cost of carrying financing drops to nearly zero again, I'd say they've put their money where their mouth is by firing the developers. They just want it to stay on the books to pad the portfolio for investors.
  19. I think my main concern that causes me to question definitions of harm is people being overbearing. I think people (above the age of consent/legality or whatever) should be allowed to make their own decisions, but given a good education of the pluses and minuses of the possible choices at hand. Unfortunately I feel people (at least my age, early 20s) don’t really get taught the skills necessary to properly weigh pros and cons and end up going more with their emotions. It’s hard to find the balance between a warning and an order. I am terribly sorry but I must now correct myself. I was using the wrong term. Some families in Nepal practice polyandry, not polygamy, although polygamy can be found in Nepal too, it is not what I studied about. The way it works is one wife usually marries an entire family’s brothers. The husbands are not drawn from different families. Tension is mainly around personal issues. It’s been several months since the anthropology class and I don’t seem to have taken notes on the subject, but I recall that having two males helps raise lots of farm hands and keep the population stable. I’ve found the TED Talk I watched during my studies. I don’t know if it’s okay to post it, so just Google “Are five husbands better than one TED Talk” and you can find it if you’re interested.
  20. THE SECRET SPACE PROGRAM - YEAR 4, DAY !̶̨̛̤̰͈̥̫̯͎̻̘͕̭͎̣̠̠̯̩̦̫̣̦̤̼̯̿̏̈͛̐̉̈́̀̈̾̓̈́̊̃̈́̒̚̚̕͠*̶̬̺̜͎̳̠̦̗͕̝̠̖̭̝̟̝̠̻̭͉͛̂̈́́͒̽́̀̈́͌̑̂͝ͅ@̸̢̧̢̨̻̟̱̖̤̠͉̠̪̮̭̝̯͚̝̠̺̗̤̪̠̔͋͐́̔̈̒͋͂̾̍͂̋̔̎͒̎͘ͅ^̴̨̧̧̛͕̦̱̜̩̗͎̲̰͔̤͎̪͔̪̭̬̤̈́̾͆̾̑̃̔͠$̶̢̛̭͉̳̭̤̹͔̝͔͌͐͗̿̈́̽́̔͐̑̿͊́̓̍͆̈́͗́̐̄͜͝͠͠͠͝͝͝@̶̦͇̮̠͍̬͙̻͕̞̭̠̅̾̀̍͜ MISSION OBJECTIVE: Send crew to the Secret Space Station CREW: [NO DATA AVAILABLE] It's ya boy [REDACTED] back with another update at Kerbin's most secret of space programs. The Dessert Launch Center (DLC) has had some extreme overhauls recently, including the construction of a much more streamlined VAB. Instead of rocket parts being built is separate buildings and then assembled on the launchpad, it can all be built and assembled right there, and then rolled out. Also, the launch control center is no longer a small tower, but now a full fledged center for launch control. And new barracks have been constructed, which I must say are pretty snazzy, especially for a crumby government facility. Now, onto the important part. This mission will be sending a new crew to Triple-S (as most of us on base call the space station), where they will continue to monitor the Mun and signals coming from it. A recent burst of energy has been detected from the surface, higher than anything we've seen. Almost like something has just come through the portal. Rumors have also spread that they'll be working on an unmanned lander mission that will investigate the structure further, but truthfully we have no idea. Sure, shipments have arrived at base, but these could just be for any old satellite launch too. I don't have clearance to enter the VAB, and those who do are ordered not to talk about what's happening inside. Hmm... The new crew who I still don't know the names of make their way to orbit. "Proceeding with orbital insertion burn." - Unknown Commander "Burning for Triple-S." - Unknown Pilot Now we sit and listen. For any little sound movement or smell coming from the Mun. We finally have eyes up there again, and I will do as much as I can to tel you what those eyes see. What secrets do you continue to hide?
  21. Not at all; and I highly doubt they mention anything in regards to plans for KSP2 specifically on the earnings call; other than the potential for more clarity on the closures and the reduction in costs related to it. KSP2 was already dropped from their quarterly reports last year where it was previously still noted as having an expected console launch... checks date... Oh, it was already supposed to have launched on console. In this call, they talk numbers not specific details of future plans; and any forward looking statements they do make are going to be focused on positive outlooks, such as expected revenues from GTA6.
  22. At this point, not surprised, just disappointed. I knew this was a mess on launch but I gave them my $50 anyway because I wanted to support it. But clearly someone high up said to shove this out to early access way too early and unstable and feature incomplete to inject cash into someone's pocket. It should have been at least as feature complete as KSP1 before launch, if not have 1 of the new flagship features or 2, like multiplayer or colonies, or physicalized asteroid belts, you know, the trailer bait. I hope the project lives on in some productive fashion, either in another studio or made open source. From the offset though for my part the problem seemed to be Unity and how it was implemented. KSP2 never made significant stability changes to how KSP1 worked, large craft would still bring supercomputers to a crawl etc. and it didn't help that the game implementation was, hey, stack 30 of this same part together and let it all wobble every tick. There didn't seem to be much tricks used under the hood to make the game stable, because it can't decide if it's a space crash simulator or a space program game. So lo and behold, let's calculate all these trusses every tick, let's not lightweight these parts/payloads hidden behind a faring at launch, and watch framerate go poo and watch things spontaneously wiggle themselves into a billion pieces, let's make it practically impossible to maintain fixed orbits for all your relay sats because of floating point error, etc. - those kinda issues bug me more than a lack of multiplayer and colonies, the base game should be running and operating a lot smoother, and a lot more like a refined game that knows what it wants to be. Extremely Weird. It leaves the community to run wild with our thoughts and no direction, and the silence is deafening. If there was short term hopefulness for the direction of the game you'd anticipate an official word from someone at the studio other than the boilerplate 'talk when we can lol' that we have. It leads to deductive inferences, like either nobody at the studio can talk competently about the future of the project, or because they are part of the layoff, they don't want to, like the community manager appears to have effectively said 'no, I'm not polishing this turd for the higher ups anymore, I'm mentally checked out, have to figure out how I'm going to eat this July.' And that would be completely understandable, despite frustrating as a supporter? backer? gamer? customer? victim? mark? In this debacle. And the corpo statement just reads as 'no no no this wasn't a rugpull, please don't delist our game and issue millions of dollars of refunds, new infrastructure update in 2 weeks! Make Kerbal Great Again!' For all we know it boils down to putting the game in maintenance mode and keeping it propped up like Bernie from Weekend at Bernies.
  23. I cannot stress how HARD I bounced off the game. I KNOW it's not the game for me. I didn't return it (like I did Stellaris, another game everybody loves but I knew INSTANTLY I'd never enjoy after about 15 minutes) but still, it's far better off pimping in my uninstalled games list, than it is getting sweared at incessantly as I think of the dozens of other things I'd rather be doing than hands-on learning a billion undocumented ways I'm not supposed to fly my ship. Maybe it's better now. Steam says I last played it in 2018. I'm not really all that willing to find out. Steam also says I put 7.5 hours into it, which frankly shocks me. You talk about docking protocols. I never even made it to a space station.
  24. It's the problem with Google, it will trimm the results to your profile. This is a list from mine (using the very same link I used above): Jovem Nerd Estúdio de Kerbal Space Program 2 será encerrado após demissões 2 weeks ago UOL Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer Dec 22, 2023 IGN Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer 2 weeks ago UOL Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer 2 weeks ago Game Developer Update: Take-Two confirms Kerbal Space Program 2 is safe despite Seattle layoffs 2 weeks ago PC Gamer Kerbal Space Program fans react with anger over Intercept Games closure, and you know what that means: Review ... 2 weeks ago Epic Games Our guide to exploring deep space with Kerbal Space Program 2's For Science! Update Feb 6, 2024 Space.com Kerbal Space Program game director and ULA CEO talk STEM collaboration and companies' futures (exclusive) Feb 23, 2024 Olhar Digital Jogue como Elon Musk! Kerbal Space Program está por menos de R$ 20 no Steam Jun 9, 2023 Terra Jogamos: Kerbal Space Program 2 é mais acolhedor que antecessor Feb 24, 2023 <some others I'm omiiting> Yahoo Finance Canada Take-Two is shutting down the studios behind Rollerdrome and Kerbal Space Program 2 2 weeks ago TechTudo Kerbal Space Program 2: veja gameplay, história e requisitos mínimos do jogo Feb 25, 2023 And so goes on. You see, your initial statement: It's a heck of an overstament at best, or just don't hold itself at worst. For the best or for the worst, KSP in on the media.
  25. Marginally? What exactly makes KSP1 only marginally better than KSP2? I agree that KSP1 has its flaws and problems. But if you think that the buggy dumpster fire that KSP2 was at launch, or continues to be today, is only marginally worse than KSP1, then nothing anybody says here will make any sense to you. I mean, of course it doesn't make sense to me. It is like how a Flat Earther sounds when trying to explain their beliefs. Right. But they do those "man on the street" things on the late night talk shows all the time, and they ask people general questions. "What's the capital of the US" and "How many ounces in a pound" and "Show me where Maine is on this map". And you know what? Most of the people that they show - not that they ask, but that they show on TV - can't answer the questions correctly. By your own definition, that makes basic US geography and simple weight conversion mathematics niche areas of interest. Again, bad analogies. I'm not on about asking "do you know what color the 0.625m stack separator is in KSP?" or some ridiculous trivia like that. I am on about asking people if they are even AWARE of this game's existence - caps for emphasis . It might shock you to know a game hardly anyone is aware of outside a specific industry is basically a niche, even if you may find it possibly shaking to think that a core aspect of your life is inconsequential to most people. A lot of people heavily invested in niches seemingly tend to go through some kind of denial, exhibit A ; ). Frankly, I have never heard anything said about this game unless I went out of my way to look for it so I'm leaning towards niche.
×
×
  • Create New...