K^2

Where kerbals are very particular about their desires. Basically, a Sims mode.

This one's from a MIIS professor, director for East Asia Nonproliferation Project. We now also know that over 2,700 tons of ammonium nitrate was near the location as well as oil, granary, and other potential sources of fuel. That's potential for up to 1.8kT explosion. So now we know what the upper bound on the range is.

Look at the map. It's 600m to buildings that are getting evaporated. Much closer to your 500T footage. Edit: Similar analysis on Reddit. https://www.reddit.com/r/Physics/comments/i3otmk/order_of_magnitude_estimates_of_the_beirut_port/

The last buildings you see shredded before camera turns away are about 600m from explosion (using Google Maps). So the blast wave is a supersonic shock at that distance. Back of the napkin estimate puts energy requirement at about 0.5 kT. That's conservative lower bound, of course. A much better estimate would try to estimate actual speed of the shock wave, and will probably give a higher number. I can see if I can get something a bit later. Edit: @kerbiloid This is what 5000lb of ANFO going up looks like, which is 1.6T of TNT equivalent. I'm not bothering to check your math, but 5T isn't even close to explosion in Beirut.

Yeah, a lot of companies used that as good time to announce delays, as it would be better accepted than without an explanation. But just looking at vacancies at Intercept, they weren't landing 2020 after change of dev team. And again, actual impact of pandemic on schedules hasn't been that drastic across the industry. That just isn't the situation in the field. We're all already used to working with remote contractors, dialing into virtual meetings, and working over VPN. Switching everyone at once to WFH was very disruptive, of course, but most of us know how to continue doing our jobs. After period of adjustment, things are back to business. You could explain slipping by 2-4 weeks with the adjustment, maybe even couple of months, but not half a year or more. And again, that's not to dismiss psychological impact. This is definitely hitting some people pretty hard, and over next half a year, studios might start losing some good people. But it's not going to impact release dates for anything scheduled sooner than Q1 2021. And it's not clear how big an impact it will be even that far out.

That's almost certainly not true. Based on work already being behind, then getting transferred over to Intercept, odds of us seeing the game in 2020 were nil without pandemic being a factor. Also, the impact of WFH policies has not been THAT great. Speaking as someone in a lead position on a somewhat larger project with a fall 2020 ship date, it has certainly been a challenge, but not a "Miss your target by a year," kind. I think, impact on morale and exhaustion levels has been way higher than it has on actual progress. Which is still a factor to consider, and I'm actually more worried about games that were further out in their development cycle. But it's also something the industry overall is adapting to rather better than anyone expected, and in the long run, might become a new norm without detriment.

I can't get into specifics, because this is starting to get very NDA very quick, but the gist of it is that what you can and can't ship is primarily based on your contract with Sony/Microsoft. When Sony/Microsoft say that they will continue support of base consoles, that is reflected in contracts with developers. These contracts frequently get modified for exceptions for certain features that simply can't work with base hardware or without certain specific upgrades. And as time goes on and we enter next gen era, there is no explicit reason why Sony and Microsoft might not start allowing games that only run on Pro/X models of their consoles. And there is going to be a lot of pressure to scale back support for base models. There are a lot of games coming out for next gen that can ship for PS4 Pro and XB1X as well with some features scaled down, but only if base models can be dropped entirely. Early on in PS5/XBSX era this will probably be helping generate extra revenue. First of all, market penetration of new consoles will be low, so license fees from selling to previous generation will be a substantial share of profits. Second, it's a rare time slice when secondary market of used hardware sales is actually beneficial to Sony and Microsoft. If I can sell my PS4 Pro to a neighbor who only has the original PS4 right now, so that I can afford a PS5, that's still a PS5 sale for Sony. No only does Sony get hardware sales, but they can now sell PS5 version of a new game to me and PS4 Pro version of the same game to my neighbor, where porting this game to base PS4 might simply not be feasible. It's even more pressure on Microsoft with their Smart Delivery. If I'm a dev working on a XBSX game, and I come to Microsoft saying, "Hey, we can probably pay this external studio to port our SX game to XB1X, so long as we don't have to support base XB1. Otherwise, we simply can't make it work, and it will be XBSX only," that's a lot of pressure on Microsoft to cave. We'll have to wait and see if we are going to start Pro/X only games being approved, and maybe you're right, and they'll decide that possible backlash is not worth the sales generated. But I wouldn't just dismiss the possibility at this point.

Game is coming out on PS4 and XB1. There is no reason to base min spec for PC on something more powerful, especially, under Unity. The only question is whether base models will be supported, or only Pro/X.

It's hard to say for sure how much KSP2 will push the hardware, but even original PS4 and XB1 have GPUs with substantially more performance than a 1030, never mind the mid-gen upgrades. If we're looking at nVidia 10th gen, 1050 might be min spec for KSP2 if the baseline is going to be first generation PS4/XB1. Of course, KSP tends to be playable even at lower frame rates, so if original consoles can handle 25-30FPS, the 1030 should be capable of at least 20FPS+, and maybe that's good enough. If they target PS4 Pro and XB1X as baseline, then 1030 will probably not do well at all, dropping bellow 10FPS into slideshow territory.

Name is a bit misleading and largely historical. In modern context, any program you run on GPU is going to consist of one or more shaders. If you'll ever want to play with GPU code, but don't want to have to write a bunch of scaffolding code around it, the best thing I can recommend is trying out Shader Toy. There are tutorials for how to use it, and the site is full of examples written by other people, and some of these examples are absolutely bonkers. All of the stuff you see there runs through the browser on your own GPU. (It has no access to your disk or even RAM, so it's safe.) People have used it to show off fluid simulations, amazing volumetric renders, including for things like clouds, and all kinds of procedural generation. Not all of it scales well, but there are great examples there that do.

I don't know why you think it wouldn't be possible to achieve. It's exactly the sort of simulation you can run in shader very well. If we're talking about Unity, your options are basically doing work in shader, C#, or via plugin. C# is not as bad for performance as it used to be, with JIT doing a pretty good job, but there's still a significant gap with well-optimized native code. If you have to do this work on CPU, a plugin is definitely the way to go. In terms of what you write your plugin in, you have options, but realistically speaking C/C++ are your best options, as you get really good optimization with modern compilers along with all the benefits of high level code. And unless you sabotage yourself with doing something like unnecessary virtualization, C++ will be just as good for performance as C here. Not to mention standard C++ libraries like <thread> and <atomic> making your life a lot easier for splitting the work between the cores. And yes, absolutely, this kind of simulation can be distributed. Otherwise, wouldn't be much of a point trying to make it work on a shader. Typically, with this type of fluid simulation, you'll ignore vorticity and encode the state as pressure, density, temperature, and flow potential. That last one is a scalar field such that its gradient gives you the flow. Then you rearrange your differential equations so that you can update these buffers one at a time. For example, rate of change of density is just divergence of the flow. Rate of change of flow is a function of pressure and density. Pressure is updated from change in density, and finally temperature can be computed from pressure and density. This way, you never write to the same buffer you're reading from, and so you can have as many threads working on the problem as you like. Just make sure that you have some sort of signaling to ensure that all threads working on step 1 finish before you go to step 2. You can use atomics and condition variables to help you with that. On GPU, you'd instead write each one as separate shader and rely on fences.

That might just make neturonium the most convenient fuel for sci-fi setting. "Where did you get all this neutron matter?" - "Get in, there is not time to explain!"

If you want to make it into a KSP mod, might be easier and way more efficient to write it as a shader. First of all, it's a lot cheaper to do the simulation like this on a GPU, which will become super important during warp. Though, for really high warp, you might want to cheat and just select a randomly pre-generated starting point that matches time of the year. Second, most of the times you'll be using the results is for visual effects, so having to do a lookup into some textures for things like cloud density isn't a big deal if everything is already stored as textures on GPU. Finally, if you do want to hook up something like wind being dependent on weather simulation, you can still do it via a compute shader really efficiently, so that the weather maps don't ever have to cross the CPU/GPU boundary. For KSP2, things are a bit more complicated because of the multiplayer. Floating point computations are notoriously variable from one GPU to another. GPUs are designed to do math very, very fast, and some sacrifices to precision are made, and not all GPUs take the same shortcuts. So even starting with identical state simulating the same number of steps with the same time step you aren't guaranteed to get the same results on two different graphics card, and that means conditions might not be identical for two players. And sending the entire texture across the network is going to be costly. So that's a good reason to run weather simulation on CPU in KSP2. That definitely needs to be written as a C++ plugin and there are a bunch of optimizations that will have to be done, including distributing workload between multiple frames. But the way CPUs do math is way more stable, so long as you avoid certain SIMD instructions, and it's way easier to synchronize for multiplayer. Another alternative is to have all the GPU math done in integers. I have experience doing that for some procedural generation, when we needed to make sure things generate the same way for all players, but I've never tried that with any sort of simulation. In principle, any floating point math can be replaced with fixed point math. GPUs aren't as performant with integers, typically, but so long as you can keep orders of magnitude reasonable, you can still do more math on GPU in integers than you can on CPU with floating point. Well, for most typical configurations and target consoles, at any rate. And it's current gen of consoles where I"m most worried for CPU performance, so that's probably the benchmark there. Oh, I wouldn't recommend starting on something like this NOW if they hadn't planed on it. This is more of a hope that it's already part of feature creep that already happened. Things like making adverse weather effects optional, if weather effects are happening, is still something they can add, though. So it's the sort of thing worth discussing.

Without immense gravitational pressure, neutronium decays. Half life of free neutrons is less than 15 minutes. Without pressure exceeding electron degeneracy pressure, neutronium will not fare much better. It will make for a very bad shielding material, being radioactive itself, and as fuel, will have very short shelf life.

No, but there are Disney lawyers, and they terrify me far more.

First of all, if there are any weather effects that impact gameplay, whether directly or through reduced visibility, they should be optional. Probably as part of "difficulty" settings when you start a new game. Personally, I would really like to see wind be a factor on planets with atmosphere. On Kerbin, I don't think it'd be particularly fun to have very strong winds, but a bit of a cross wind when landing a plane could be a good challenge. On some exoplanets, maybe more extreme wind conditions would seem appropriate, actually making landing on them very difficult. Nothing we currently have in KSP seems like a good fit, but maybe some planets in other star systems of KSP2 could work well with this. Other than that, rain, snow, and dust storms seem like they'd be good additions, and will make operations a bit harder due to reduced visibility. Fog should be easy to implement if there are good clouds in the game, and clouds are definitely a must, but I'm not sure if it would actually be fun to play with. This also introduces an entire topic of low visibility and zero visibility flight and instrumentation associated with it. Personally, I would enjoy a bit of IFR, but that does come with some design challenges and a pretty steep difficulty curve that not everyone might appreciate. Then again, if it's optional, why not? Real destructive weather/events like storms, tornadoes, volcanic eruptions and so on don't seem like they'd be adding anything of value. All it really does is saying, "Well, stay in orbit/VAB and timewarp until it passes," and that isn't anything fun. P.S. A simple 2.5D fluid sim that lets you make believable, if not 100% realistic, weather simulation on a planet isn't that hard to write. Keeping it synced across multiplayer might be a bit trickier, but still very doable. So we can absolutely have realistic cloud patterns that form around low pressure systems as well as cyclones and everything that comes with it. It is about a month of work for a senior engineer with a math background, though, plus maintenance and design work afterwards. So not the cheapest thing to implement, but very doable. If anyone's interested in a lecture on Euler equations for fluid simulation on a grid, I can fill in more details.

I think the big difference is that life support limits your ability to plan missions without adding anything interesting. Even if you allow for it to be regenerated, it's one more resource to keep track of, and losing a ship due to some life support problem seems like the most anticlimactic thing ever. I don't strictly oppose it, but I don't think it's necessary and it doesn't add to the game. Colonies only make sense if they grow. So population being a factor makes sense. Yes, not strictly necessary, as you can make colony growth be purely industrial, but I think it actually adds something to a career-style game. Colonies you've established early on have time to grow and become more prominent. And that's a good way to mark progression through the game. It's rewarding, and therefore, a good mechanic. Again, just because a mechanic is good doesn't mean it has to be in any particular game, but it's worth discussing at very least. And if we're saying that population growth is a factor, then there need to be rules for it. Like I said, the simplest thing is to simply have exponential growth and have population increase until you hit the limit afforded by amount of habitat space built. It's simple, it requires no special planning beyond hab space, and it gets the job done. When I suggest the second option with complex dynamics, I by no means want to see it turned into Sims. There's reason I brought up Dwarf Fortress, where player has rather minimal impact on these things. And in a game like KSP, I would suggest having no impact at all. It's just a mechanic that happens in the background. Since you have the data, it could be fun to add little text descriptions for individuals and what they've been up to, but this would have no gameplay impact. The way such a simulation does impact gameplay is that it lets you introduce some additional parameters beyond just hab space that influence base growth and also requires a larger initial population, which means you can't start a colony by just bringing a couple of kerbals on a rocket and waiting long enough in time warp. You'd have to actually organize at least a few colony ship flights, possibly through some automation system similar to the cargo routes that have been mentioned. And yes, there are ways to get that second effect through just coming up with a pop growth formula with enough tuning parameters. But a simple rules-based simulation is a much more fun to achieve some complex behaviors without having to write anything complex and fits the theme of the game better. All in all, this is all about you building a base the way you want, while still having a sense of progression, as the population grows and you can expand your base. Whether mechanics for growth are very simple or very complex, the level of interaction is still about placing buildings and delivering resources necessary to do so, which is what KSP2 gameplay seems to be all about. With all of the above said, absolutely, sandbox should still be a thing, and even if there is population growth mechanic that limits colony growth in career-style game, in sand box, that shouldn't be a factor. You should simply be allowed to place whatever modules you want for your bases and that's that.

I thought this might be a legitimate topic about colonies and population growth. And then I saw the picture. Personally, I think there are two routes to take with population growth. 1) Ignore nuances of reproduction entirely. Given right condition, where there is one kerbal, there will be more! Maybe they're budding, maybe it's spores. Who can say? 2) Go full Dwarf Fortress on it and model complex social dynamics and relationships, meaning you'll probably need a few dozen kerbals in a colony before two of them decide that they like each other enough and you even have a chance at population growth. Anything in between feels half-baked.

Nobody has detected anything that has been identified as dark matter. First of all, it's not conclusive that dark matter isn't just ordinary matter that we aren't accounting for in our standard models of stellar evolution. Yes, scientists are starting to lean away from it towards something more exotic, but since we've never observed any directly, it's not conclusive. Now, if it is not ordinary matter, given that we haven't detected any, it ought to be interacting very weakly, if at all, in all fields besides gravity. Something that interacts with ordinary matter this weakly would also be produced in high energy experiments with ordinary matter very rarely. Which means that very occasional mass defect we'd see in experiments that actually have produced something like this would be well within error bars and would be indistinguishable from noise. So I don't know if it's fair to say that we never made any, because we wouldn't know if we did. That said, whatever's responsible for dark matter might also be very massive. Be it a new particle or something like tiny black holes. In that case, yes, none of our accelerators would have energy to have made any. But there's no way to know. We might have made some dark matter and not notice it or we might not have capability to make it at all. We're going to have learn way more about what it actually is before we can say.

Black holes do that in all theories. Exactly how they manage it varies from theory to theory, but any black hole can convert up to 100% of mass it consumes into massless energy (photons). But the fact that they have to do that is just consequence of General Relativity, which is just a consequence of space-time symmetries. I mean, technically, that's also a theory, but we have better confirmation of that than Earth being a spheroid, so there is very little doubt that provided we have access to a black hole, we can generate energy with it.

The curvature bit is more complicated, because there are shear terms in the tensor, so even with a choice of coordinate system, you can't just reduce space-time curvature to energy/mass density alone. In general, how that mass/energy moves is important. Rotating black holes are a great example. Another caveat is that you're spot on about nomenclature being outdated. Early relativity papers still used the word "mass" to denote inertial mass, and that's where we get mass-energy equivalence from, which is the topic. But modern scientists almost never mean that when they say "mass". Instead, they're talking about rest mass, which is the pole in the propagator of the particle field. Rest mass can be created, provided you have sufficient energy to do so, which is why there is confusion. Two historically related, yet completely different meanings of the word "mass" being mixed together into one discussion.

It's also pretty easy to get an H shape out a point source due to a slight imperfection in optics of the eye. It's really hard to say without testing you with a bunch of different shapes of different sizes to see which ones you can distinguish.

I'm not sure above is average. It assumes healthy retina, center of visual field, and, crucialy, in focus. I'm not sure average eyesight is good enough without correction. With glasses, though, yeah most people will visualy resolve a minute of arc.

If that whole thing's a mirror and it's aimed at you, you'll definitely see it. So if you're intentionally trying to make it visible, there are ways. Otherwise, see above.

Or a more direct kick to Earth itself, greatly increasing its angular momentum. Yeah, either way, the total angular momentum isn't there intrinsic to Earth-Moon system itself, so it'd have to come from outside. That part of a reply was more of an "what if?" What if something provided a gentle push to slowly raise Moon out of Earth's SoI? It doesn't look to me like we'd have collision risk for a good while after that. Instead, Earth and Moon will occupy the same orbit around the Sun, with moon going to slightly higher or slightly lower orbit during each approach, resulting in a planetary game of tag. Like I said, we see it with Janus/Epimetheus. Though, masses of these two are more similar, and they are moons. So maybe perturbations on Earth/Moon dynamic will be stronger. It'd be kind of an amazing setup if it can be stable, though. To have another planetary body that's within almost as easy of a reach as Moon is now for a few decades out of a few centuries, and then being harder to get to than Mars for the rest of that time span, because it's effectively on the same orbit on the other side of the Sun. The fact that we don't see these arrangements more often does suggest that it won't be that stable, of course. But a few million years is an instant when we're talking about billions of years over which star systems evolve, and it's still a huge amount of time on civilization scale. There's probably a planet out there with population that's looking at the former moon coming in for another close approach going, "Now! Now is our chance to go there and plant a flag on it!"