K^2

Members
  • Content Count

    4,115
  • Joined

  • Last visited

Community Reputation

1,691 Excellent

4 Followers

About K^2

  • Rank
    Particle Theory ABD

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You are getting yourself confused somewhere. When you throttle down, in steady state, AoA stays constant, air speed stays constant, and you descend. Your pitch angle changes, because your relative wind now has vertical component, so the same AoA means a more nose-down attitude. Likewise, if you throttle up, the nose goes up and you start climbing, but again, AoA and air speed stay pretty much constant. And the reason is that airplanes are intentionally built this way. The CoP of the main wing is behind CoG, which means that with no other forces, the only direction a plane would be going is a vertical dive. But the horizontal stabilizer on the tail is built for negative lift and is way behind the CoG. The net CoP is balanced on CoG in level flight. Now, if you apply external force to force a plane to pitch up, AoA on both the wing and stabilizer increases, which increases lift on the wing and decreases negative lift on the tail. This shifts CoP back and causes the plane to pitch forward. Likewise, trying to force the plane to pitch down results in CoP shifting forward and plane pitching up. Assuming all other factors impact your wing and stabilizer the same way, AoA is fixed in steady state and depends only on position of elevators. And because "neutral" position of elevators depends on your trim settings, when you trim your aircraft, what you're really trimming for is specific AoA. And as pointed out, if AoA is fixed, so is the air speed. Once airplane settles down to your adjustments, all forces and torques are balanced. (That's definition of steady state.) That means Lift + Weight + Drag + Thrust = 0. And unless you're doing something really drastic, Lift and Weight are roughly opposed and Drag and Thrust are roughly opposed. With this in mind, what @mikegarrison wrote should make more sense. If you keep your trim settings and throttle down, the AoA can't change, because your elevators didn't move. The lift hasn't changed, or you'd be accelerating down. And so the only thing a plane can do is continue at the same air speed, descending gradually, trading gravitational potential energy to substitute for reduced power from the engine. Now, all of this works to first order. Yes, real planes are more complex. L/D is not constant. It's a factor of absolutely every variable mentioned and a few that weren't. The wing and stabilizer do not respond the same way to air speed changes, because they aren't the same shape and there is air stream interference. If your climb/descent rate are significant, then your lift and weight vectors are not colinear. All of that means that in a realistic scenario, if you adjust one thing, you have to adjust all the others. It's not as bad as flying a helicopter, but you still have to coordinate your inputs. Nonetheless, if you want to descend, you reduce throttle and then correct everything else. If you want to slow down you pitch up, correct everything else, then trim if you're happy with the new speed. The intention is still tied to a specific input, with other inputs being corrective. Mentally, think of it as a difference between making small adjustments to the steering wheel in a car when you're hit by sudden gust of side wind vs making deliberate turn. You're turning the steering wheel in both cases, but intention and how you process it are very different. Disclamer: I don't have significant air time on anything larger than a C172. So this might not strictly apply to airliners, but I haven't heard anything that implies it shouldn't.
  2. You're right. It's an inverse cube. Moon wins. I was extrapolating from actual movements of water levels in deep ocean and, you're going to laugh at this, but I forgot that the Earth spins. When I was extracting relative strengths, I modeled it as Sun going around the Earth in 24h, and Moon going around the Earth in 27 days. When, of course, relative to Earth, Moon goes around in under 25 hours, so the two periods almost match, with envelope modulated by the beat frequency.
  3. Yes, graphics in a game engine usually runs on its own thread. What do you mean, that's not what you've meant? I agree that KSP2 will have to push graphics a lot further than KSP, but I'm not sure ray tracing will help a whole lot, and I'm usually the guy who pushes for broader RT use. It just... Doesn't help you render a planet, unless you throw a LOT of RT power at it. Talking about all the things Ray Tracing can do and how much of it you can support on next-gen is a complicated topic. Especially, because specs aren't public yet, so even things I know I can't discuss. But in broad terms, the hardware isn't quite there yet to just straight up ray-trace the entire scene and completely abandon conventional rendering. You need very complex BVH and a lot of rays to achieve that, and even 2080Ti just can't in realistic scenarios. Instead, what you normally do is render scene as normal, and then use RT to improve lighting or reflections. Again, speaking very broadly, you can improve reflections, global illumination, and shadows. This can be absolutely phenomenal for creating atmosphere in some games, but KSP2 doesn't have scenes where it pays off. Lets break it down a bit. I would broadly break down the components of the scenes into 3 categories. Planets that you're on the surface of or in low flight over, including terrain, sky, and weather rendering as applicable; planets that you're in proximity of, such as when you're in orbit; and your actual craft. You can have all 3. If you're flying over Lathe, you obviously have your craft, the terrain of Lathe bellow you, the sky above, and possibly, Jool occupying a solid chunk of it. All of these have to be handled differently. Lets start with planets you are orbiting. Can you improve these with RT? Maybe, but it doesn't seem cost-effective. The only fancy things that can be going on are things like crater shadows and atmospheric scattering. You can try to get that with RT, but you'll need a ton of rays to get good resolution out of it without noise. It's way, way easier to just write custom shaders for these things. You can get absolutely amazing looking planets with conventional shaders if people writing them understand light theory and scattering processes. If you don't, they won't write a good ray tracer, either, so all around, you're better off with conventional shaders. The planets you're in flight over are more interesting. Here, shadows really can be improved, especially, once you take global illumination into account. You can get better time of day and weather visuals for sure. But RT is still an expensive way to get these. And while it can pay off in very complex scenes, like if you're in a town or a canyon, where there are a lot of shadows from all kinds of vertical objects, you don't get much of that in KSP. The scenes we do get are pretty natural, and you can get very good look out of them by using prebaked lights. Can you get better quality with RT? On a powerful PC, yeah. On console hardware? I'm honestly not sure. But what you'll get won't be worth the effort. So conventional lighting still wins. That leaves the craft. This is the only part of the scene that might actually benefit from RT if it's done right. Baking light probes for your craft doesn't really work because there is staging, moving parts, and occasionally things explode. So getting good global illumination with rays is a lot easier. The craft can also have reflective bits, and SpaceX has demonstrated with a Tesla Roadster in orbit, planets reflecting off shiny bits make for great visuals. This would be a lot of work to get it right, though. Unity's support for ray tracing is still in preview, and you need people who really know what they're doing on this. Realistically, you'll need to hire a dedicated graphics engineer with RT experience just to work on this to get it in time for release. All the racing games devs obviously think it's worth it. But is it for KSP2? I don't know. And it doesn't look like Intercept currently has developer resources to throw around.
  4. Oh, there are so many factors in local tides that go way beyond gravity. The day-night cycle is a lot faster than lunar cycle, obviously, and water has a lot of inertia, which means the two cycles will not have the same effect even if they were at the same strength. If you're living by the bay, the tides aren't due to water in the bay being pulled by gravity, but hydrodynamic flow of water in the sea/ocean around it, which is driven, among other things, by gravity. But how shallow the water is, how wide the inlet, etc, makes way more of a difference. In general, it's still synced to the tidal rhythm, albeit, with a bit of a lag, unless you're directly on ocean shore. And your highest tide is still going to be around the full or new moon, when Sun and Moon work in tandem rather than in opposition. That said, this also has negligible impact on rotation of the Earth. The water that's sloshing around bays and shorelines is just not enough mass to make an impact. And the tides in the open ocean are a lot simpler. There is still a factor of water mass, but topography no longer plays any role. And the Sun has significantly greater impact there than the Moon. Not by as giant of a factor as Sun/Moon mass ratio, of course, due to the distance difference, as you indicated, but noticeably. It's probably sufficient to point out that Moon is pulled on by Sun's gravity more than by Earth's, and Moon's pull on Earth is going to be smaller by the mass ratio of these two bodies. (Edit: Corrected by mikegarrison - tidal effect of the Moon is, in fact stronger. See link in quoted post.) Finally, the tides caused by Sun on Earth have absolutely nothing to do with Earth migrating from the Sun due to tidal effects. You should be looking at tides that Earth-Moon system is causing on the Sun. And that's a whole another story, because the Sun's movement itself is rather complex. It's not even at the center of the Solar System at the moment. So you have to talk about how all of the planets interact with the Sun together to see what sort of tidal effects this results in, and then propagate that back to individual planets to see how much they get pushed around.
  5. True, but Jupiters' migration would have had to have been more extreme than what can be explained with tidal effects alone. So both friction, read, collisions with smaller things orbiting the Sun, and 3rd body interactions, likely with Saturn and the ice giants, were involved if all of this is correct.
  6. No. Certainly not with anything organic. Carbon is even used to strip oxygen from metals - e.g. see how copper is smelted from malachite. There might be some fuels out there that you can oxidize with carbon dioxide, but they aren't anything that's going to be practical. And having either reduced carbon or carbon monoxide as part of your exhaust isn't going to be great either.
  7. Yeah, outside of what's needed to survive the launch, they don't have any physical protection. Some warheads are designed to maneuver in atmosphere on re-entry, though.
  8. Not sure that's necessary. A near light-speed beam is not going to diverge a whole lot. You can either think of it as relativistic effect or as magnetic field generated by the plasma current. Either way, with enough energy, there just isn't enough time in proper frame for plasma to dissipate. I don't know if there is any advantage whatsoever over just lobbing a projectile, but making plasma beam weapons is actually way more plausible than you'd normally think.
  9. Releasing cross-gen should be fairly straight forward with the next generation. Microsoft actually has a Smart Delivery program that lets you publish your game for XBox One and Series X as a single SKU. It's basically counted as a single game on your XBox account, and it will download appropriate version for the correct system. We're yet to see if Sony has anything similar planned. There is going to be far less change in hardware between generations this time around. We still get substantial performance upgrades, but the core architecture stays the same. The shift from Cell/Xenon to Jaguar during last generation meant backwards compatibility was hard to achieve and even ports had to be rebuilt to fit new consoles. This isn't the case this time around. All four consoles in both generations from both Sony and Microsoft are built on AMD x64 technology. So the amount of work necessary to make games cross-generation is comparatively small. This is made further true in KSP2 case, because it is built on top of Unity engine. Almost all of the platform specifics are going to be handled by Unity. Odds are, the PS4/XB1 version of KSP2 will just build for PS5/SX if you simply select that build target in Unity when exporting the game. Naturally, to take full advantage of new capabilities, some additions will need to be made. Primarily in UI, social/match-making features for multiplayer, and graphics. At a minimum, you'll probably want higher resolution textures for next gen. But the team might want to also adjust things like LoD settings, vegetation and rock densities on planets, and other little improvements to the look of the game. This kind of work isn't exactly free, but it can be handled by a small group of devs, as it doesn't actually involve remaking content.
  10. Yes, railgun will still fire. Water isn't THAT conductive, even sea water, and path of least resistance will still be through the projectile. Efficiency might drop both due to resistance and to some of the current flowing via other paths. It might also fry control systems or the capacitor itself, as it's likely to draw more current than normal shot. And just like toaster in the bathtub, it's not inherently deadly. There still needs to be a reason for current to travel through your body. It doesn't take a lot of current through human heart to stop it, and there is going to be quite a bit flowing through water, but the electromotive forces are going to rapidly decay away from the rail, and you still need to create a potential across the heart, which would take some unfortunate positioning of things. I wouldn't feel confident firing a railgun under water just for the hell of it, but if it's a life-or-death situation, I'd probably take the risk.
  11. It should be pretty easy to park a rocket in an eliptical orbit with periapsis just above the atmosphere. Then pick a much bigger circular orbit to try and match. You have two good options for a transfer burn. From periapsis or from apoapsis. Both can get you to the target circular orbit with two transfer nodes (one at your original orbit, and the other at target to circularize). And it should be very easy for you to compare the amount of fuel required to complete either of these two maneuvers.
  12. You're not wrong about current gen of console CPUs. But KSP is also the kind of game where it matters the least. There are basically two things the CPU is in charge of. Feeding the GPU with draw calls and running the game. The former can be pretty complex in general, depending on how busy your scene is, but even on the planets, there just isn't enough going on to give even the base model PS4/XB1 any difficulties. The fact that it's Unity is a significant overhead, as specialized engine could have taken better advantage of nuances of the game to make rendering even cheaper, but even with Unity, there just isn't enough complexity to make it a hard problem. So we are left with the rest of the game. AI is only expensive if you have complex path finding or strategic gameplay. We can discard it right away. Even if KSP2 has some sort of AI ships, Total War it is not. You can do all necessary nav computations on a TI-83. The real sinks of performance are usually animation and scripting. The later almost exclusively due to poor implementation, but nonetheless, it is a fact we generally have to live with in game dev. Writing a scripting system that will keep your designers happy, prevent them from doing horrible things to your game, and at the same time runs at a reasonable pace requires an horde of developers. Because we have budgets and you just can't make designers write better scripts (we tried), sacrifices in performance in the name of simple, maintainable code base is how it goes. Fortunately, KSP is not the sort of game where you have five thousand behavior scripts running on every single component. All of the critical systems are hard-coded in C# and what little scripting you need for missions is cheap. Animation - I don't think I need to even talk about this. I'm sure the anim graph for that one kerbal you have running around the surface is actually quite impressive. But you're still animating just one character at a time. Even scaling up to a few in multiplayer is not breaking any CPU budgets. On to the exciting bit. Physics! Normally, in most games, this is barely a speck. The reason is, you can't write a physics engine if you don't know what you're doing. You can write a script parser following a YouTube tutorial. You can write an A* path finder following the Wikipedia article. You can even write a crap renderer by following one of these "Make a Game" books. You aren't writing a physics engine if you don't have a few years in Classical Mechanics, Differential Equations, Numerical Methods, and a lot of CS courses (or equivalents!) to tie it all together into practical understanding of simulation. So you know which part of absolutely every game engine I've ever worked with is polished to an absolute perfection? No, actually, the math and vector libraries, but physics takes a close second. The simulation itself isn't always great, because some games have taken an oversimplified approach, but if you have a good quality simulation, it's usually one of the most performant parts of the engine as well. You just can't screw it up without screwing up the simulation itself and having absolutely everything explode instantly. Unity is built on top of nVidia's PhysX engine. I have many complaints about that one, but performance isn't one of them. That thing has a multi-body solver that is well optimized and it's paired with a very robust collision detection. KSP has a bit more going on in terms of physics than most games, but it's still a pretty straight forward proposition. The absolute worst case is a ship ascending through atmosphere. You are on high part count, there are a whole bunch of active weld points acting as constraints on a multi-body solver, majority of the parts are generating aerodynamic forces, there are more potential intersections than ever to keep collision detection busy, and you might have physics warp enabled on top of it just to make things extra bad. You can throw enough parts at a simulation to make it a workout for any system. But the crux of it is that this won't get any worse in KSP2 compared to KSP. This is just something that the game has to deal with. And if KSP runs fine on a current gen console, there isn't really anything you can add to this in KSP2 that would require the next gen CPU power. Oh, sure, there will be a lot of advantages of running on next gen. You can throw in way more parts and still have a good framerate. A complex rocket on a large planetary base in KSP2 might give current gen of consoles a heart attack, while running perfectly fine on PS5 and SX. But this is something that PC gamers already have to deal with. If you want to build a giant monstrosity in KSP and have a smooth framerate, you better have a beefy PC to run it on. It's not really a reason not to allow PS4/XB1 players to even try. There will be a whole bunch of other things. The GPU on next gen can handle a lot more, and that means it will require a lot more of the CPU attention. Multiplayer servers could have much higher player caps if the host is running it on a next gen console or beefy PC. There will be good reasons to play KSP2 on either a next gen console or a modern PC, I have no doubt. But none of it makes the base game fundamentally unplayable on PS4 or XB1. Or on essentially the same PC hardware that KSP currently runs on. There could be any number of additional considerations going on in the background. I'm not going to pretend to have all the pieces of the puzzle. And overall, KSP2 can end up being way more CPU intensive than KSP, requiring a lot of people to upgrade. But saying it's unwise to try and get any next gen game to run on PS4 and XB1 is uniformed. KSP2 is a perfect example of a game where simultaneous release on current and next gen makes perfect sense as an attainable goal. It will sell way more units this way, and if you throw in a free next-gen upgrade on consoles, you might even be able to make deals with Microsoft and Sony to subsidize you somewhat, because it will help push next-gen sales down the line.
  13. Yes. A 24h real-time build delay, which you can't speed up with warp for an unexplained reason, but you can rush with Kerbal Diamonds. What are Kerbal Diamonds? Glad you asked. They are a new resource you can use to speed up construction of rockets and buildings, buy research levels, and customize your Kerbals! You get 100 Kerbal Diamonds just for signing up, and after that, they are available with convenient purchase options for $2.99, $7.99, $14.99, and $49.99 for the best value! Just joking, of course. (I hope. ) But in all seriousness, if construction time is tied to the simulation time, the only thing it really changes is you have to leave yourself margin on transfer windows. You can always warp forward to when your ship is ready to go. So I don't really mind either way.
  14. Mars is low enough gravity and thin enough atmo for rail launch. It's effectively free to ship cargo from Mars once you have an industrial base there.