K^2

By this definition, aren't the Earth and the Moon both moons of Jupiter? Yes, I'm being a bit pedantic, but my point is that the distances have to factor in somehow. And some examples aren't nearly as clear cut. Consider these two moons of Saturn: Janus and Epimetheus. They play an unusual game of tag. The one in slightly lower orbit catches up to the one in the higher orbit and they start falling onto each other. As they pick up speed, the one in the lower orbit moves higher, and the one in higher orbit ends up lower, and they start drifting apart again until they go all the way around Saturn relative to each other and repeat the process all over. It so happens that Janus is a little over 3 times as massive as Epimetheus. So by the mass ratio definition, should we consider Epimetheus to be a moon of Janus? They do get pretty close, closer than they ever get to Saturn. And their gravitational interaction clearly matters to their orbits. But if we say that Epimetheus is a moon of Janus, then Epimetheus completes an "orbit" "around" Janus by going all the way around Saturn and then around Saturn again in the opposite direction. So we really, really have to consider other factor besides mass ratio. You have to establish the hierarchy before you start applying the ratio test, and once you've established what orbits what, it's a moot point. If in order to say that Earth doesn't orbit Jupiter, we first must establish that both are clearly orbiting the Sun, because the Sun is the gravitationally dominant body among the three, and therefore, the Earth can't be orbiting Jupiter. But then I simply go and apply the same logic to the Moon, and end up with the same answer.

That is the definition of the moon that we currently use, yes. However, if you are saying that this is what defines one object orbiting the other and not vice versa, then planets of the Solar systems don't always orbit the Sun. Or that the Sun sometimes orbits the planets, perhaps? Because barycenter of the Solar system is only sometimes contained within the Sun. To be more on point, the barycenter of the Solar System is not currently within the Sun, so the planets aren't currently orbiting it either? Or the Sun is currently orbiting the planets? I'm not sure which one you prefer to imply, but the point is, the Solar System doesn't currently pass the barycenter test. Now, if you do want to claim that sometimes the Sun orbits the planets, that's fine. But I think, most people would agree that the planets always orbit the Sun and not the other way around. So clearly, there is more to one body orbiting the other than just where the barycenter is. If only a definition existed by which every planet would be gravitationally bound to the Sun and most of the moons, at least, bound to their planets. Hm.... Maybe if we went with which body has the strongest gravitational influence? Perhaps? Maybe? To be clear, a star is certainly a different category than a planet. There is nothing fundamentally wrong with having very different definitions for planets and for moons. But if your answer to the question of why the Moon is a moon is that the Moon orbits the Earth and not the other way around, and your answer to why the Earth isn't orbiting the Moon is that the barycenter is within Earth, then, the Sun is orbiting the planets right now, and we're kind of in a bad place. Either you have to have a better argument for why the Moon is a moon than which body orbits the other OR you have to have a different definition of one body orbiting the other than the barycenter. You just can't have it both ways if you want to keep logical consistency. And if you really want to have a barycenter definition for moons, that's technically fine. But then it has nothing to do with which body orbits the other. It's a completely arbitrary definition which we shoehorned to make sure that we keep calling the Moon a moon and no other reason. It's a bad way to define things, but it's honest and self-consistent, at least.

Why isn't the Earth a natural satellite of the Moon?

Specific use case, say I own a rare/unique item. I want to boast about it somewhere without revealing my account. If you have a searchable system where one can look up who owns what items, like Steam Inventory, a unique item points directly to a specific user account. In contrast, if public information is a ledger that only identifies an item and transfer date from creation and until the latest transactions, with new owner identified only by a secret unique to each transaction, then the only info you can get about an item is how many times it's been traded. But if somebody wants to prove that they are the owner, they can generate a time-stamped proof-of-knowledge code that identifies them as such. Technically, that can all be handled with dumb random tokens and server-side verification, but then you have to trust the game devs that the item is truly unique, that no shady transfers have been done, etc. With a public ledger, it's easy to verify any particular history of ownership without revealing the identities of specific players. So you get a bit more transparency about the in-game economy without compromising anyone's privacy. Critically, absolutely none of it requires a blockchain. Is any of this ever strictly necessary? No, not really. But it's not hard to setup and so long as you have central authority that publishes the ledger, this isn't wasteful. It can still be scammy, but only in the same way that existing digital goods systems already are. This doesn't introduce additional incentives or avenues for grift. So if a game is ready meant to have some sort of player economy and unique or rare items, why not? Computational cost of running something like this is negligible compared to your normal server overhead of running a player market. There is really no strong reason not to do this from either the tech or ethics perspective. The problem is entirely in trying to shoehorn all of that into a blockchain. One can have a discussion on whether a blockchain is ever the right solution to any problem, but it certainly isn't for games. Blockchain requires extra engineering effort, even if it's a 3rd party integration, it wastes resources on global scale, and it invites scams due to inherent deregulation. As such, it always makes any game economy, whether in-game or actual monetization economy, strictly worse.

No. By the definition I am proposing here, the body has to pass other tests for planethood, including hydrostatic equilibrium and clearing its neighborhood, and always accelerate towards the star in order to be considered a planet. Moon is the only body in the Solar system that is not already a planet that passes this test. All other moons of all other bodies accelerate away from the Sun during part of their cycle. And this is specifically because their parent planet is the dominant body in their neighborhood. Moon's trajectory is dominated by the Sun's gravity, and it is the only such object.

There's some nifty math behind crypto. The concept of proof of ownership via proof of knowledge stored on a public ledger is good tech, and there are good, legitimate uses of it. The problem is that what we're seeing promised and hyped is more like these ads for magnet bracelets that "improve your circulation". Yeah, magnets are amazing. Yeah, there is some great research on fluid flows interacting with magnetic fields. But that magnetic bracelet is doing nothing with your blood flow, and the person trying to sell it to you is a con artist. When talking about NFT and blockchain tech, I think it's important to distinguish between underlying tech and places it can be used vs the product that's being pushed on the market. Because there are good and exciting things about the former, and the later is a pile of dung. And the fact that there are good and legitimate uses of technology is only accenting the fact that what we're actually seeing isn't some well-intended fiasco, but a genuine scam. If you're running an MMO, for example, and you have items that you want to feel unique and rare, and you want people to have ability to claim ownership anonymously, for example, a public ledger with concealed identities and proof of knowledge system is a good way to achieve it. There is just no reason for that ledger to exist on a blockchain, because if your items are tied to a specific game, then that game's server should have authority to write the ledger. And even if you are pushing some sort of cross-game compatibility, you are still relying on central authority to introduce and track items, so again, that authority can simply be in charge of keeping the ledger. Making it decentralized is stupid. And if you take the blockchain out of it, you can have NFTs in all but name minus the environmental impact and minus the fraud. Of course, artificial scarcity and FOMO in games can be exploited even without additional shady layers on top, but it's not inherently bad. It's all about how it's monetized. Getting a rare or unique item after putting in a lot of time into a game can feel rewarding and be constructive to game experience. Having it sold to you in a loot box, well, that's a different matter. But that's precisely the point I'm trying to make here. We have the tech and opportunity to use the crypto technology in games in a way that does not cause a drastic increase in power usage with every transaction, having negative environmental impact, nor encourages fraud. Just like there are good ways to use artificial scarcity in games to improve player engagement without being exploitative. And yet, we are not going that route. Now, I don't think anybody's intentionally pushing NFTs to increase harm we're doing on environment, so the fact that people pushing them are resisting this concept makes me fully convinced that fraud is precisely the point.

You still want to run drag and lift computations over multiple points along the wing, and that does still scale with the wing span, and you need at least one point for every aspect and sweep change along the length, but these are relatively cheap to compute compared to the rest of it. And yes, absolutely, on everything else! There will definitely be improvements to stability and performance of aircraft due to introduction and use of procedural wings, but as you say, not because of any specific changes to the actual physics.

So Earth doesn't orbit the Sun? Seeing how it's center is deflected from orbit by nearly 5,000km by the Moon's gravity. And neither do any of the other planets. Not a single one of them is in perfectly elliptical orbit, after all. Some perturbations always exist, even for Venus who does not have a moon. And then there was even that big shebang about Mercury's orbit precessing, which was eventually shown to be in part due to General Relativity preventing nice elliptical orbits in the first place. Seems like a crap definition, if you ask me, if it doesn't apply to a single body in all of Solar System. Nothing's orbiting anything else. That doesn't seem great.

There are a few places where you're asking which values for ISP to use, and some of these numbers are clearly meant to be in m/s and some in s. The easiest way to check which ones to use is plug it into formula and see if the units work out. If your dV didn't end up in m/s in the end, the input units were wrong, so you know to use the other convention. And the conversion factor is always 9.8m/s2. I strongly recommend keeping these in any computations as well. First of all, it's a simple way to check the results, and second, if any conversions have to be taken care of, they are plainly available.

Setting aside the question of whether that will be the only way to build fusion engines, I don't think even that's going to stop some players. I'm sure somebody's going to end up building these giants in orbit, then entering atmosphere to land at some suitable clearing to pick up cargo. Getting TWR for takeoff will be tough, but again, I'm sure somebody will figure it out. We've seen people do space planes powered by ions, after all.

You had to go and jinx it... v_v I don't think Intercept would be able to sell it directly. The publisher/developer relations are a lengthy topic, but tl;dr is that it would be exceptionally unorthodox for Intercept to be handling any sales directly. Private Division has a storefront, where I would fully expect KSP2 to show up once it's up for preorders, but that storefront simply redirects you to the Steam/XBox/Playstation/Nintendo stores as appropriate. So I suspect, the PC and possible Mac/Linux version(s) will be available through Steam only. Interestingly, KSP is up on PD store, and it does feature a DRM-free copy you can purchase from PD directly, but that must be an exception due to agreement with Squad during acquisition. I don't see this done for any newer games, so I highly doubt that this will be done for KSP2. But if there is ever a PC/Mac/Linux version that's sold directly without using an intermediate platform, like Steam, GoG, etc., that's where I'd expect it to show up.

@SciMan is correct, though. Procedural wings do not imply better aerodynamics or physics. They do encourage a sensible lift model, but even that would basically mean about the same quality as KSP is now. Which, honestly, I'm fine with. Some changes would be welcome, like transonic effects and lifting body forces, but there are more important things to get right in physics and simulation in general, IMO.

It was (and still is) a sort of RPG where all your powers are home-in-on-target and run on timers, so it's actually playable at 15FPS, just looks a bit crap. Obviously, everyone wanted a solid 30 or better, but this was landing on fire, we had a week before that version headed out to cert, which we were under contracts for, so 20 was good and 15 would have been acceptable. Also, XB1 was still new at the time, we were one of the very few F2P games on it, and in some regions the only one available, so the expectations and the bar were low. Of course, later, the XB1 version ended up doing really well and priorities shifted, but that's a different story. I don't really want to mention the game or studio by name in an open thread, but if you're curious about any of my work, feel free to DM me.

Having a physics engineer on board is a good sign. They're a bit green as far as formal experience with game physics goes, but good acafemic background and I'm sure a number of side projects. So hopefully, they'll do a good job. It sounds like KSP2 still runs GameObject system, rather than ECS, so we're stuck with PhysX as a base. That's the same physics engine as KSP, so some problems are likely to remain. However, it has been confirmed that we are getting continuous collisions, which helps a lot when two ships collide, and there has been talk of "physics LoD." We don't know exactly what this means, but likely, ability to simulate fewer joints by combining some parts into rigid bodies. If Intercept can manage to make that work without struts summoning the Kraken, it could easily improve performance and stability for larger rockets. So we're definitely getting some improvements, but how much difference these will make remains to be seen.

Depends on the stage of development. Early on, it's more about feature testing, since most of the bugs are kind of obvious. Later on, yeah, it turns more into data gathering on performance and bugs. But there's also the aspect of trying to keep the team motivated. People tend to do better work on a project when they understand the project as a whole and are invested. Having everyone try various builds of the game early is a good way to achieve that.

Keep in mind, there is some variation, because it's not like there is a committee that decides what you should call each stage of development, but generally speaking, there's pre-production, pre-alpha, alpha, beta, release candidates, and release/gold. With day-zero patches, that whole beta-RC-gold becomes a little blurry. Like, when you're playing a "beta", especially if it was a pre-order incentive, it's often actually the RC version. But then, yeah, most of the promo footage would get captured in beta, because people almost never do these captures at the last moment. And even if the promo footage is captured super late, you usually wouldn't use the release version, because you often rely on dev tools, and there might not even be a dev build of the release version. In which case, one of the RC builds is usually used. As for whether that will actually be called "beta footage," probably not. Devs aren't required to put that message there. That message exists when they know they're showing something unfinished that definitely will change. If there's beta footage that looks identical to shipped game, nobody's going to label it as beta footage. Edit: Eh, that doesn't have to be an indicator. We had all-hands play tests of games while ridiculously early in pre-alpha at one studio I worked at, and I've never been at a place where you can't just ask one of the engineers or designers for a build. Game studios generally encourage anyone on the team to play the games they're working on.

Definitely not. Beta is "Finished game, some bugs." I don't think summer was ever realistic for KSP2, so if we're looking at a fall release, there are 6-8 months of work until release, so maybe 4-7 until RC submission. Depending on the kind of game we're talking about, maybe it should be well into alpha by this point, but for a game like KSP, the alpha phase is going to be pretty short. Alpha is feature complete, fully playable, but potentially with major bugs that prevent completion of the game start-to-finish. If you're making an open world RPG game, going from alpha to beta can easily take a year or longer. But for something like KSP2, once it's in alpha, it's a stone's throw away from beta. And beta is basically polish. Unless they're coming in hot, with a pile of bugs, beta might be the last couple of months before RC is submitted. So even if it really is still in pre-alpha, which we don't know - all of the footage we have is potentially months old - even then, there is time for a fall '22 release. Though, it is, potentially, starting to get tight. And if the game has already entered alpha, then it's well on schedule.

A lead is a team manager. They are very important in the long term, but a team can hobble along for a while without one if they have good leadership structure above and good production. It's a lot more work for the directors when they don't have good leads, but it's manageable short-term, so even if several leads leave the studio, things don't grind to a hold. The number of leads also depends on the number of IC roles. So if the teams have been growing through hire, the need for new leads might have only recently formed. And that's if the positions are vacant already. We know that Intercept has been working on spinning up a small team for a new project, and it's possible that these vacancies are to replace people who will be moving to a new project. That would mean that the leads are still on KSP2 until new people are hired and teams are rearranged. This is normal practice for studios that want to keep their lights on, as they are basically paid to make a game for the publisher and a big chunk of income disappears once the game actually ships. Intercept is owned by T2, so the pressure isn't as high, but generally, their budget is still subject to approval, and approval is subject to Intercept showing that they're working on another game. So all in all, this doesn't have to be an indicator of any sort of a problem.

I wonder if the rounder structures are craters, volcanos, or a mix of both.

Even in KSP, there are edge cases where this assumption breaks down, but in KSP2 this is completely unworkable. First of all, multiplayer. Anyone can take over any ship at any time. Second, some ships are going to be traveling under power for a long time. Again, there could be arbitrarily many of these. And crucially, if you are flying a long duration mission, you've set your thrust, you checked the trajectory, and then switched to a different craft, you can't have the trajectory change. Which means, it has to stick to the n-body. Since the game isn't clairvoyant in so far as what you want to use for your missions, that means that any part that came from any ship that has been flown should be considered still a part of the mission, and therefore be on n-body system. And that's basically everything in the game. So it's really an all or nothing. You can't swap between n-body and patched conics in KSP2 in any remotely reasonable way. It might be ok if you're just doing it to handle the Risk system, but not as a general solution.

This is one of the few things that would make me instantly pass on KSP2. There are good uses of cryptography and public ledgers in video games. But none of it needs to be distributed. Absolutely nothing in any video game has any business being attached to a blockchain. Which means, any time you see a game using a blockchain, at the absolute minimum, the developers have chosen an option that is explicitly harmful to environment for no gain other than using buzzwords. Potentially worse, there have been enough outright scams involving blockchain. So at best, it means the developers have no idea what they're doing, and possible implications only get worse from there. Either way, I want nothing to do with it and will not willingly contribute to any product going this route. And I sympathize with some smaller startup studios, because I get to deal with a CEO who's constantly exposed to dozens of crypto startups who got VC money to push blockchain as a product, and I have to keep explaining to said CEO why we don't need that technology, and why for every single "benefit" we can get the same exact functionality cheaper and without dumping literal tons of CO2 into the atmosphere. But "everyone's doing it," is a very bad reason to do things, and I am appalled that there CTOs and engineering VPs out there willing to go along with this either because of peer pressure or because they're literally getting payed to.

I'm having flashbacks to being tasked with bringing framerate in a certain RPG ported to XB1 to "playable" during an important raid. The demo file I was testing against would dip down to 3FPS. Following considerable amount of optimization, I had it running above 20 95% of the time. I was later told the studio would have been happy with 15. So "playable" FPS is definitely a stretchy subject.

They are identical for gameplay purpose. We aren't looking to fully simulate the dynamics - that would by the very definition require full N-body simulation. But it's also not what people are asking for. What people want is be able to place a replica or re-imagining of a real or proposed spacecraft that utilize these points. For gameplay purposes, you can place a spacecraft near the location where L3, L4, or L5 would be found in the real world and have it stay in general neighborhood of that point arbitrarily long. There are no perturbations or sources of external force, so having an equilibrium is all you need. Already addressed in the thread. In general, a 3 body problem, with 3rd body of negligible mass, produces a chaotic solution for that 3rd body. There can be closed form approximations for certain special cases. Some of them are well known. However, it does not cover the general case, which we need for the game, and approximations aren't always good enough even for cases where they are available. So while yes, there are things you can do to clean up the problem and use in things like mission planning, if you are simulating the game, you still have to rely on numerical integration, and the fact that the system exhibits chaos, would require very fine precision as you are integrating forward. This isn't impossible in principle, but given that even at 100k time warp, which is the limit in KSP, any sort of interstellar mission would take a while and there can easily be dozens to hundreds objects one has to simulate, this becomes a very hard numerical problem. Add to it the need to project orbits forward and all the shenanigans that come with multiplayer, then consider requirement of this whole thing running on a console and not even natively, but via C# compiled to CIL? All of these things you can work on. You could maybe discard debris a lot easier to keep number of simulations down. Maybe not project future trajectory as far forward or not worry about potential SoI intercpets as much. You can compile native code to run the integration more efficiently. You can do very fancy implicit integration methods to reduce errors. There is a lot of room for optimization here. Or you can just keep using patched conics and fake what you need for gameplay. Again, keeping in mind that we're more interested in supporting the mission profile than providing 100% accurate simulation.

Performance-wise, it should be fine. There will almost certainly be some "ultra" settings that this card will struggle with, but I would expect even "high" settings to be within reach. Rendering just isn't a likely bottleneck for KSP2, and I've seen the fancy vegetation and clouds similar to what we are seeing for KSP2 running on a PS4 Pro just fine. GTX 960 outperforms that by a good margin. The only thing that might be a slight concern is VRAM. Some of the techniques Intercept are going for are very VRAM hungry. GTX 960 came in a range of variants equipped with 2GB to 4GB of VRAM. I find it extremely unlikely that more than 4GB will be needed on high settings, because that's kind of a lot even for gen 9 consoles, but there's a chance that you'll need more than 2GB running everything on high. Specifically, you might have to bring in render distance for vegetation, and/or shadow and cloud quality down a notch, as these will take up the most VRAM. Still, I expect the game to look very good on GTX 960. I'll be surprised if you'll have to sacrifice a lot of quality with that card. Depends on the generation of that Ryzen 7. If it's at least a Zen 2 (gen 3 of Ryzen), then you'll be fine, because that's pretty much what PS5 and XBSX are running, and you should be able to boost your clock more than either of these systems. If it's an older R7, then it's harder to say. We don't really know what the requirements will be for the CPU, only that it will probably be on the high side, and that Intercept has to get good performance out of PS5, so it can't be higher than that. Bellow that, it's hard to say. Ryzen 3700X outperforms the 2700X by about 20-25%. It's a pretty significant gap going from Zen+ to Zen2. So if you have gen 3 or newer, you're fine. If it's older, we don't know yet.

We already know that they're trying to get early pre-production ball rolling on another project, which is normal for a studio that wants to keep everyone's paychecks coming after the current game is delivered on. And I don't see any significant changes with positions they have open for that. All in all, no real change in status from any of this information. KSP2 is still planned for sometime later this year, and since I wouldn't have expected the game before late summer anyways, the fact that it's fiscal '23 is as expected.