Incarnation of Chaos

Bethesda always hypes their games, but they do it with a plan. Little teasers years beforehand, an info dump here and there to keep the fire stoked, then a ad blitz as release approaches. They have the benefit of mass market appeal, and a loyal fan base (less so post FO4 and 76). So it's a model that works for them, and we'll. KSP2 has been delayed twice, is a niche product that even with COD levels of advertising and product placement would never achieve a mass market appeal. I have significant doubt a similar model would have success with KSP2.

I think procedural generation would be best used for reducing the time it would take to make a planet pack tbh Like if you can generate basic terrain, water features and an atmosphere based on a set of input variables, then you can focus more on the details and sculpt it to your liking

Oh i'm pretty sure we're getting DLC no matter what, and mods will require it at some point. To be honest there's honestly no real solution to this, if you force mods to have a default level of compliance then you limit the possibilities capable of being performed by them. Which then encourages mods to step around these systems entirely, ah la KSP original. People will absolutely write custom code and inject it at load time if the need is there, and there's nothing KSP2 can do to make it any more compatible with versions released afterwards. As for managing mods on their own, i really hope you're just talking about an ingame mod manager lel. Because even a robust conflict resolution/exception handling system will require user intervention at some point.

Well to be honest with you, when I say SDK I'm more thinking about a gui front end for the kopernicus analog that could also get code if needed. So I misused the term lel Yeah about that, this stuff is on rails. You change anything as far as orbits and atmosphere? Reload.

Workshop is fantastic for the simple things, so crafts, part mods using stock assets and patches could easily be there. The dangerous stuff should definitely be in a box with a large "you waive any rights to cry if you do this" sticker in top lel

Yeah one time i had a multiple segment nuclear mothership that i had spent several real life days assembling in orbit, manuevering to a duna insertion, actually conducting the burns and then finally got into Duna orbit and detached the lander. So here i am, real life days later. Just happily mining with the lander on it's third excursion between ike and duna, and i just think "I should probably check the lab on the mothership" and change focus to it without a thought. *EXPLOSION* The docking port sr had just decided to explode, for no reason. It wasn't clipped, it hadn't been docked to (If anything the load on it was less, as the lander wasn't attached). So either i could design an entirely new mission, perform a mid-mission segment exchange in orbit after the mission had been mostly completed due to a kraken attack with no physical or logical basis. or i just go into the .cfg and trip the flag disabled... guess what your boi did? he tripped that flag, took that boat all the way to freaking jool and back and never had a single issue with that docking port again. In fact, one of the 6 lander legs breaking is what caused me to scrub. Because while it was plenty stable with 5, it would mean any further legs lost might have been unstable.

Sadly neither of these are true Base PS4 is a Radeon HD 7700 Equlivilant APU, Base XB1 is a Radeon HD 7750 equilvilant APU Both paired with Kavari Architecture cores that even a sandy-bridge i3 would absolutely trounce at desktop speeds....except they're heavily underclocked with the PS4's coming in at 1.45ghz and the Xbox One's at 1.55 or something So the architecture at base is deficient, further made worse by low clocks, and the GPU's are 8 year old cards that barely handled 1080p medium back then. PS4 Pro has a RX 580 (Slightly above it shader wise) equlivilant APU, with the same garbage cores at 2.2ghz. Xbox One X has a piece of silicon in it that has no direct desktop analog, but lies between the RX 580 and Vega 56. With the same cores, clocked similarly low. Basically, the previous generation of base consoles is using what at their release were 6 year old mobile parts...and now are going on 10. And the "Enhanced" consoles are massively held back by their anemic CPUs. So considering KSP2 is still using the same rigid-body approximation for vessels (Making multithreaded implementations difficult at best), but far more optimized in terms of how they're actually conducted. I think the base consoles will be decent at KSP2 if people are willing to settle for 720p @30 fps.... Enhanced? 1080p at 30fps still, CPU's just won't allow cranking framerate in anything but the most GPU bound titles. PS5 and Xbox Series X? Sky is basically the limit for them, they're essentially desktops using a Ryzen 2000 series and a freakish half-breed of Vega and RDNA that tends to approach RX 5700 levels of performance.

I can land boosters far easier than aircraft, completely manually. Normally i end up using a drogue chute or two to keep them stable once they end up in the thicker portions of the atmosphere, but other than that it's much easier pointing a brick in the right direction and letting it fall than maneuvering an aircraft in KSP. Plus with the terrain the way it is, landing aircraft is 9/10 times pointless due to krakens shoving the gears through the wing roots. So i actually end up using TSTO reusable craft much more than aircraft, just less to go wrong lel. I think what KSP2 needs more than automation is tools, it wasn't until 1.10 that we got a altimeter that accounted for elevation instead of assuming sea level. Trajectories in stock would also allow much, much easier piloting, and just getting rid of the buggyness of wheels would solve so many issues it's not even funny. And I've even tried to use mechjeb before, and it's always easier in the end for me to do whatever it could manually. So i know I'm pretty biased here, pretty much the opposite of all the people who say they couldn't play without it.

Unpopular opinion, but i honestly hope KSP2 stays exactly the same as KSP1 in this regard. Do you know how many games allow me these days to have a separate install that's effectively version locked? Basically 2, and that's counting KSP. And whenever i do have a mod in KSP, it's not in some proprietary archive i need special tools to poke around in if there's an issue. The raw files are right there, and easily modified or dissembled. The most problems iv'e had is when games try to "Simplify" modding by "automatically" "Updating" my install, and wrecking it because the update service doesn't know better, heck i even abandoned CKAN because it often got dependencies wrong or incorrect and i had to install them manually anyway. Heaven forbid we have to go through workshop for mods, that's honestly something that would seriously make me consider not purchasing the game tbh. I have nothing against some alternate system being in place (Workshop or a stock CKAN), but if they don't allow sideloading and freely copying installs I'd be very, very disappointed in them.

I cannot say how happy i am to see someone finally just straight up say it. I'm definitely not a KSP modder, but iv'e played numerous other games where map creation/level creation tools were made available and while some user-made maps were decent. The majority were low-quality spam, trolling or otherwise just not unique. I definitely don't think stock planet creation tools would even be available in game tbh, the way the physics and the game itself handles planets would prevent new systems from being spontaneously loaded in unless KSP2 changed a decent chunk of their backend (Might very well have going by the latest posts). But i also think that eventually some type of GUI front end for planet creation will emerge, especially since KSP2 has API's that could be hooked and make a program like that far, far more useful. But it won't be something for the casual user, it would be an SDK that would require a decent amount of knowledge about how KSP2's planets/star systems are put together scripting wise. This definitely ties in with the above, even a 2D map for an RTS (Let's use Tiberium Wars III as an example) requires far more than just it's bare essentials to look passable. Sure you can make a functional map with nothing more than a barren landscape, a few resource deposits and a couple goodies to capture. But it would look terrible, the AI pathing would be defective, and no interesting gameplay would come from nothing but flat terrain for miles in every direction. A truely decent map took major effort to create, and required a fairly in depth understanding of how the game handled AI, encounter zones, scripting, and then finishing it off with Buildings to break up the wastes. Then you also had to consider those small little details, where to place impassable terrain? Water features? Hills and valleys to slow down or funnel advancing armor? Any bridges? Are they destructible? Do you have multiple bridges? Or force the players to contest a single crossing to assault each other? ALL of these make a major difference in the moment-to-moment gameplay, and even how a player decides to conduct their entire strategy. KSP2 isn't an RTS, but i'd imagine the same principles hold. Terrain, elevation, ore/resource deposits, atmosphere, liquids? All would change how the player tackles the planet, and would be incredibly difficult to do automatically.

If they were the modders would be under NDA, so i doubt a solid answer is even possible. That being said, solid documentation and tools being available day one would be awesome

Actually more RAM is even more important for people who still use spinning rust. Since being able to load more into memory negates many of the issues associated with hard drives. Also the difference between hitting the page file and ram is several magnitudes of order worse than even the slowest DDR even on high performance SSDs. Even ones that can in theory approach transfer speeds close to dual channel DDR4 (which in practice won't happen) can't even come close to the IOPS of RAM. In english, SSDs are fast. But they still can't handle the CPU asking for multiple unrelated bytes nearly as well or quickly as RAM. So basically the short version....get as much RAM and as fast RAM as you can afford at the time. It'll benefit you in the now and tomorrow. PS - Not really criticism, just wanted to further explain.

See I'm the opposite way, for me at least I found it way easier to control a deorbit burn to get a landing within the vicinity of KSC than fly there.

oof, I'll concede.

There shouldn't be a risk of snapping with 2D perfs either lel And there's going to be an abstraction layer no matter what, because KSP2 isn't going to be VR-only. So why not work on what the majority of people are going to use instead of this?

Yeah the more I've thought of it the more i've realized KSP stock already does this on a limited extent. I think I'm just not as familiar with Reference Frames in general as i should be.

Mods always come with overhead, they have to be loaded into memory afterall. So slower computers aren't going to be having a good time with ANY mods aside from the most basic. Secondly Tweakscale support for many of his parts isn't that easy due to modules, fuelswitchers etc. Plus you could always roll your own Tweakscale patches if you really wanted. He did the hard work of making the models, texturing them, updating them from KSP version to version and then releasing it all for FREE for us to use. A few minor things doesn't take away from that, dude is awesome imo. You're free to disagree, but i find your reasoning rather weak tbh.

All i was saying is those 3D coordinates exist, and can be mapped to "2D peripherals" fairly easily. Far easier than making an entire system to handle VR.

Which KSP2 devs already said they'd have tools for since the standard node system couldn't handle them at all.

It's still a projection on a monitor.... The monitor is just strapped to your face instead (and then is 2 monitors with slightly different depth to trick the eyes). Otherwise you wouldn't even have the performance issues that come with it, since the GPU wouldn't be doing any translation from the 3D to 2D. But I'm not going to get incredibly technical, since that's not the point. You already have "the exact 3D coordinates" for these objects VR or not (the game is still 3D internally, always) So if that was truly the issue, you could solve it easily (you'd have to store them somewhere, and update it). Either way, you're now suggesting having two completely different ways of handling input for parts. Which is kinda proving my point. Most people here are asking if their potato laptop from 9 years ago can run KSP2. So spending time and resources to build essentially a game within a game just for the limited number of VR users just strikes me as absurd. Plus the bugs and conflicts introduced would probably make KSP look tame lel. I think we both agree that KSP2 should definitely have a much better system for parts and selection. I'm just of the opinion that VR should be literally the last thing added. So I think we'll have to just agree to disagree on this one, besides intercept is the one that'll make the decision. They could drop a dev blog tomorrow for VR, and I'd have a hat to eat (made of cookies)

What...core layout.... what? It's a single call to grab the system's core count, and then you can build up from there. Having a static const variable that says " int xboxCC= 7" and using it instead is not going to be a massive speed difference. Why? We're not using assembly here, so all the functions that handle threads, cores, locks, etc. Are generic anyway, because of how C# is built. It's also an interpreted language, so there's overhead from that. Background processes? Alright I'll give you there's probably going to be some difference on a machine that literally has nothing else... But that's not the current consoles either, they run a full OS under the hood. And it's not just doing games either, it's handling updates, media, network traffic and so on. And they have less RAM than most to do it also (Xbox one has 6GB for games, 2 for OS. And they share the 6GB with the GPU....so even less.) And mind you as core counts increase, so does the impact of the background processes decrease since they have more places to spread out. And they don't tell the cores what to run, the OS and it's scheduler actually handles it. All they do is write code, and then setup the functions for being sent out to multiple threads. If you wanted to do that, you're looking at some C++ or C. Something basically intended for OS development. But just using a compiled language would blow the doors off C# lel So I'm incredibly skeptical about any real performance gains from console from the hardware and "minimal OS" alone. Whatever performance disparity between the PC and Console versions of a game is, often comes down to a bare minimum port job.

I mean not really, because it doesn't actually generate any thrust. You'd be better off powering a lightbulb with them....or using a solar sail. Basically if they add it, it would be an April fool's joke made as a part. ec consumption? 1500 kilowatts for 0.0 kn of thrust, and can consume up to 1500 megawatts for additional 0.0 in. I hope people have realized by now this thing is bunk, and has been tested and given a fair shot. There's no novel physics in the EM drive, just a bit of geometry that focused some radio waves that didn't even replicate in the later test. Yes, even the tiny bit of thrust it supposedly made was ruled out. I know people want a slipspace drive/warp drive/magicalunicornnegativeEntropiclelomgwotisC drive but it isn't the EM drive lel Humans are clever though, we'll keep testing (exploding) things until eventually we brute-force our way to something. As for the OP, look at near future electric and it's VASMIR and other drives. Then grab some atomic rocket's and thank nerta for being awesome. Not only are they actually possible, but they beat the stock electric drives by far. Not reactionless though, but that's just physics.

Well that's the beautiful thing about math and computers, nobody said that you have to plug realistic values into your equations. You want KSP style lift? That's a single change to buff all wings, and then you get to see the corresponding increase in drag. I actually think letting people play with the aero models parameters and seeing how it would affect everything else has a massive educational potential. Kinda like universe sandbox for little green space monsters and their cute planes. You can also have the settings as sliders (with the scale from "realistic" to "full kerbal" ) for the people who don't think reading about the XB-70 riding it's own shock cone at 3AM is a good time. And then an actual panel for raw input for nerds or debugging. But I'm not going to bet money for seeing any of those, since the dev team mentioned KSP style aero a long time ago.

Gents I'm talking stock KSPs behavior in VAB, and how parts will occasionally "snap" to literally the last thing you wanted. And how moving parts certain ways can send them several dozen meters through the VAB with no way to get them back in focus. These are some of the primary reasons I always run hanger extension mods, even if I'm not making huge rockets. VR isn't going to change the snap system, just abstract it away from people. Which is fine, but my overall point basically was. "they probably should make sure KSP2s implementation of snap and construction is way less quirky before even considering VR"

Yeah I think you're spot on, so KSP2 would just have to move some of the functions out of specific actions and into a more general panel of options.