K^2

Not only that, but often enough the documentation just assumes that you'll be using *nix documentation, despite the fact that there can be substantial differences in implementation. OSX POSIX is particularly bad for this. I've had a misfortune of having to implement memory sharing between processes on an OSX machine, and absolutely nothing tells you that the file mapping path rules are different for OSX, greatly restricting maximum file name length, and the error you get is a generic "access violation," with absolutely no clarification of what went wrong. Identical code ran flawlessly on several flavors of *nix, and all of the documentation said that OSX implementation is supposed to be identical. Not to mention the simple test cases passed because, of course, they had shorter file names. And this is kind of a theme throughout. I live in the Valley, so I know a lot of current and former Apple engineers and in some of the worst cases I was able to just reach out and ask, "what is that supposed to be?" and they'd be able to get me something from internal docs that really should have been public docs. But if you're working for a game studio out in Bellevue or Austin, and you don't just happen to know someone from Apple, you're SoL, and you got to hope that somebody on Stack Overflow managed to track this particular problem down at some point. Or dig through Darwin sources and hope you can figure it out. Writing code for Apple devices, beyond the absolute basics, is all kinds of not a fun experience. And yes, Apple could absolutely have made this better for everyone by staying in more committees and sharing more documentation. Look at CLang. It's wonderful, and everyone loves it, and that what happens when Apple takes a more open approach to a project. Had they stayed in Vulkan and worked with the community to create native Vulkan-to-Metal bridge, I guarantee there would be a lot more games running native on OSX. But as things stand, if I was chained to a computer and told to port a game engine to run on Metal, I'd probably gnaw off whatever limb was attached to the chain. That's not how you want the engineers to react to your platform if you want people to make games for it.

Each pixel on the porkchop plot is an entire mission plan with all of the maneuvers. The plot itself is just a handy way to quickly evaluate what your options are. Once you have some launch windows in mind, you start looking at the details.

Everything about metric is great, except the base 10. Base 10 was a mistake. 2 and 5 are just not great factors to work with if that's all you've got, and being able to quickly scale things is the whole point. Two quick alternatives come to mind. First option, keep it simple, doubling only. That gives you 1024 as an increment very close to 1000 we're already using. Works great in computing - we'd just have to implement everywhere else. The only downside is that "A third of a meter" is still an awkward quantity, and we're as far from metric time as we have always been. Second option is to keep compounding factors. 12/60 works great for time and angles, but it's good for distances too. You can say all you want for yards and feet not making sense with larger units, but on the human scale, a third of a foot is 4 inches, and not some nonsense. Full circle being 360 degrees was a miss, though. We should make it 420 degrees. Now we have a factor of 7 in there as well. With another doubling we pick up divisibility by 8, and 840 is also in the ballpark of 1,000, making it another candidate for a better kilo- prefix. It is tempting to pick up another 3, to have divisibility by all factors in 1-10 (I mean, I don't expect the base 10 numbering system to go away, sadly.), but 2520 might be a bit too far from a thousand. It'd be a big change. So we'll probably have to just live with only divisibility by factors in 1-8. But if we do take kilo = 840, we can add prefixes for intermediate fractions. Like, one septantkilometer is 120 meters. Simple, convenient, neat. And we can fold the clock and the calendar into this system without too many problems, because now we have all these additional factors to work with. Take the minute as the new base unit, and now a second is just a sexagintiminute, an hour is a hexecontaminute, and a week is a septuagintimegaminute. Or dodecakilominute, if you prefer. Perfect system. 10/10. No notes.

KSC is located in a high-winds area, so the lightning usually comes down at an angle.

Oh, dear Pthigrivi, it pains me to say this, for it made me feel so very old. I was specifically thinking of Marathon when I wrote the above, so I looked up the release date. It was '94. It's been closer to three decades than two.

That's been Apple's modus operandi for well over two decades.

Pretty sure "teenager" was a critical word there, because if we consider non-teens, there are a lot of us here not on tik-tok.

Are we tagging ourselves? Because this is definitely me.

Indeed. Technical feasibility is definitely there, so it just depends on somebody taking on the project, and there is no way of predicting what idea strikes someone fancy at what point in time. I also know people have transcribed some existing Unity games for native Linux and OSX support. With a bit of extra work that can be used to make unofficial M1 OSX ports of Unity games. That would almost certainly violate KSP2's EULA, though, if it's anything like KSP's, so if a project like this will exist, unless there is some official green light from Intercept/PD, it'd have to exist away from this forum. Though, I'm still hoping that PD goes more lenient on EULA for KSP2 for the sake of mods and projects like this. Personally, I'd be inclined to just wait for the full release, as making official OSX and Linux releases would be very sensible. Unity support for these platforms has improved, and I know Unity has been working with Apple to provide native M1 support. So fingers crossed, the full release will be available for these platforms.

For manned missions, all of that above, absolutely. You generally don't want to shoot a manned mission into the empty space with precise point in time where their engines have to work or its curtains. Using Mars' gravity for a capture greatly increases your options, as you can achieve aero-capture using your maneuvering thrusters if your mains are out, etc. Redundancy is usually of higher priority than the absolute efficiency. For an unmanned mission, you can get creative with gravity. An Earth fly-by a year after launch can give you an inclination correction almost for free, greatly reducing the delta-V requirement in exchange for a longer mission and very strict launch window.

Does x64 compatibility work in M1 Linux? IIRC, the solution to run legacy Intel code on M1 has been to use a combination of some hardware features and software support, and it's that latter part that I have concerns about with Linux. I have zero doubt that it's possible to make a version of Proton that runs on M1, either natively under OSX or by booting into Linux, but it sounds like some amount of work would be involved in getting the binary ready for ingestion by the M1 processors.

By charging the black hole slightly. Ordinary matter couples to electromagnetic fields many orders of magnitude more strongly than to gravitational, so you can literally use a magnet to push against a Kerr-Newmann black hole without any worry about gravitational effects. Thought, to be fair, I haven't ran the numbers on the actual magnetic field strength and the size of the magnet. I'll see if I can put some numbers to this tomorrow. Off the top of my head, all I can say is that this is easier with a larger black hole, which is what we're aiming for with a more sophisticated approach.

Mysterious and moody orchestral music is great for early exploration, but I'm looking forward to the point in the game where I need to strap an oversized NTR tug to a stack of colony modules and resources at a staging point in Kerbin Orbit to take them to a new colony further out in the system, and for that I might prefer something with a bit more kick to it.

You should have the orbital elements, right? I know it's a chore to track down all the correct datums, and transform the coordinates, but there shouldn't be anything particularly complex there. Just tedious. To simplify some of the math, I really don't think you need to worry about radial motion of the planets, so if you simply take the Earth's polar coordinates relative to Sol's barycenter (you can look these up on JPL's Horizons) and convert them to cartesian, you can compute Moon's cartesian coordinates to help you work out the angles with respect to the observation points. For Mars, I think it's fair to assume that we know the plane of motion from other observations as well, so again, I'd use the Horizons data for that, and simply assume Mars is moving in a circle of unknown radius r from Sol's barycenter. That puts Mars' cartesian coordinates as a known function of r and t, and if you work out the apparent position from these, you can then fit to the observations. Since you're fitting just one parameter and I don't expect any surprises with local minima, you can probably just do a binary (or golden section if you're feeling fancy) search for the correct r.

The Earth-Moon / Moon-Mars is a significant lever. I wouldn't be surprised. The latitude difference isn't great but I was taking measurements close to horizon, so the difference in apparent motion of Mars relative to Moon due to Earth's rotation would change a lot more for me between the two measurements than for your measurements, taken much higher in the sky, and therefore, with the apparent motion being close to maximum on both ends. You might have to bite the bullet and do a numerical integration of the occlusion duration by honestly computing both the Mars' and the Moon's apparent positions in the sky over some small time step intervals. I don't think the topography of the Moon will matter, since it's a 1 part in a thousand in the worst case, and I don't think we have that sort of the precision in measurement. Treat all three bodies, Earth, Moon, and Mars, as perfect spheres of the mean radius and just do the position computations as precisely as possible, and I think that's the best chance to get useful results out of this.

The game might run ok on this. It kind of depends on how many visual setting Intercept will add. 2GB VRAM is not a lot to work with, but if Intercept lets you cut texture quality and you don't mind running in something like 720p, that's the easiest part to fix. 670 should have the bells and whistles necessary to run all of the game's visuals, but it's on the slow side for some of them. Not hopelessly so, however. Just like with memory, a lot of these scale really well, and tunning down some rendering distances and fidelity of things like clouds might make the game run well enough. Hard to say for sure, but we should have a better idea once early access is out.

The video is up on TikTok, so if you're in a region where it might be blocked, try VPN.

I was looking into some benign biohacking on some plants, and was surprised to find that synthetic plastids are something like less than a dollar per base pair with something like a 400bp minimum, making it exceptionally accessible for basic edits. Great for someone like me who just wants to make a fruit taste like something it's not supposed to, but it also makes me realize that I can put a custom antibiotic resistance into an infectious bacterium or protist for less than $2k in equipment and material. And I have bare minimal microbiology training. I'm kind of terrified of what someone with knowledge and a grudge can do with this.

Best indicator that an idea you've had is good is that somebody already implemented it. Though, I still say it would have been better as "Snax"

Create a new crypto fad. Just a few more of these, and catastrophic global warming will be inevitable.

The crux is that the nVidia main business is GPUs, but in the B2B space. So their B2C is effectively a marketing arm of the operation, meaning, they don't need to sell quantity. They need to sell prestige. Saying "something has to give," about the way nVidia has been cranking up the prices on their flagship GPUs is a bit like expecting Lamborghini to start marketing cars to general population to stay in business. The only reason we have a mid-range market on nVidia GPUs at all is that you end up with a lot of dies that don't quite make the cut for the top tier, and so it makes sense to have a tiered approach to your product to avoid taking a pure loss on sub-standard dies. So I don't expect any of this to change. But yes, it does leave room for alternative mid-range and low end chips. I'm just not sure just how much interest Intel and AMD have in that market either, and besides them, there aren't really any serious alternatives. Likewise, but with a healthy dose of skepticism mixed into that as well. I happen to have crossed paths with a lot of Intel's graphics engineers both professionally and socially, and I still don't think I have any better idea of what exactly Intel's plan for ARC is than a general well informed consumer does. Intel is clearly invested in making sure that their integrated graphics can handle at least the entry level gaming, but beyond that, I have no clue. Fortunately, I don't think all of this impacts KSP2 a whole lot. It doesn't look to be a graphics beast. I'm sure there will be a lot of bells and whistles you can crank up and make a mid-high graphics card work to keep up in 4K, but I haven't seen anything that can't run on a five year old solid middle of the range graphics card with some settings turned down.

If we're going to have a "life support" resource, it should be "Snax". Refineable from basically any rocky body, and work like electricity for cores. If you run out of Snax, your kerbals refuse to perform any ship duties, including piloting, and basically require a rescue. Other than that, they can sulk snaxless indefinitely.

We'll definitely get some patches. I don't know how serious the content will be, but getting some updates is pretty standard. Plus, I'm sure there are at least a few DLC in the pipeline. The interstellar mechanic opens up possibility of DLC-only star systems, which will be a considerable amount of art work. So there's definitely still going to be things to do even after the full release. But Intercept was also looking at spinning up a team for another game about a year ago. I imagine that got delayed a bit with the delays to KSP2, but if that plan is still alive, right around now would be the time to kick that into proper pre-production. Usually, if you want your studio to run smoothly, once the main production on one project is finished, you want to roll people over to another production. In this case, it would be right around the time of the KSP2 full release. And you generally have a lot of pre-production work that needs to be done by another, smaller team to create a foundation. Concept art can be needed for either of these two directions, so I don't know if we can make any specific conclusions.

Without better documentation, it's hard to be certain, and I'm sure at least some of the descriptions could have been either (e.g., graveyards at thunderstorm could be electrical due to lightning strike on metal as there's usually a lot of iron there, but can also be organic decomposition gas from graves getting forced out by rain water), but usually, the behavior attributed to ball lightning is more consistent with an electrical phenomenon. The way people claim it "passes through" walls would make sense for a slightly charged plasma ball getting smeared across the wall surface due to electrostatic interaction, causing it to cool instantly, which can look like it's passing into the wall. Also, in attempting to replicate the phenomenon, what I've seen from electrical setups is most promising. So while I'm sure a lot of anecdotal documentation can be getting crossed, I think what people normally think of as ball lightning is electrical, and will-o-the-wisp is organic gas, and if in some cases these get conflated by the witnesses, we should attribute it to them being mistake about which phenomenon they're describing, rather than alternative cause of the phenomenon, if that makes sense. Id est, just because people might have seen will-o-the-wisps at graveyards during a lightning storm, doesn't make it a ball lightning. Just a graveyard appearance of the wisp. And vice versa, if a lightning found some metal to strike in the swamp, the resulting ball lightning (presumably) might be mistaken for a will-o-the-wisp, but we shouldn't consider it one. Of course, that's just a matter of terminology, which for something so poorly described might be a moot point, but I think the above approach leads to less confusion and gives us a better path to categorizing these properly.

Kerbals are like lobsters. They don't die of old age. Only from accidents. That makes them perfectly adapted for long interstellar voyages. You just have to pack some board games so that they have something to do.