K^2

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.

Using UDP? Yeah. TCP tries to serve you packets in order, so if there was some sort of a hitch and one packet got delayed, you're not getting updates until that packet arrives. If you're playing an FPS or any other game where fast reaction is important, you're much better off skipping that packet and looking at the next one as soon as it arrived. Of course, you do have to make sure that your packets are time/frame stamped, your deltas1 can be received out of order, and your rewind2 strategy works with this. This is all pretty standard in modern multiplayer games, though. 1 We typically avoid sending the entire state of game objects for every frame, and instead send just the data that changed from the last update. That's the "delta". You do want to send the full state every once in a while, though, in case a packet somewhere really did get lost. 2 Main way to address synchronization in modern games is for the game to maintain a buffer of game states going back at least a second. If a packet with an important update arrives out of order, steps after the point it should have been received can be re-simulated.

Good notes. Thank you. I guess I just didn't notice. (I do tend to run my desktop way over-provisioned on memory.)

Is this with mods? I haven't seen that much of a problem with leaks in vanilla. Though, I'm sure there are some. C# garbage collection isn't exactly the cleanest or most robust, and a lot of the lifecycle is obfuscated by Unity's scene management, so it's easier to end up with some cyclic references that prevent objects from going away. There are best practices for avoiding that, of course, but when you have large teams, mistakes get made. More in some studios than others. Mods tend to leak like a sieve. They aren't, typically, written by professional programmers, and in my experience, people aren't taught good practices for a particular language until they start working with it in the industry. And every language I know of, with exception of maybe Rust, is leaky by default. C being the worst, of course, but languages like Java and C# create a false sense of safety with their garbage collection, which can actually lead to more code where things seem to work fine until they don't. I've briefly looked at the work experience of the Intercept team members who have it marked on their LinkedIn a while back, and they certainly don't look like amateurs. Hopefully, they'll be able to maintain best practices and deliver code that doesn't leak. If the mods run in Lua, depending on exactly how that's handled, it might even help there. But there are a lot of unknowns in that regard. It depends a lot on how the memory for Lua scripts is sandboxed and on how the asset loading works for modded parts, since it's a lot easier to create a noticeable leaks with art assets than some state variables. KSP is very heavily main thread bound. This is why the improvement from a decent laptop CPU to a high end desktop CPU wasn't that high. Laptops can generally boost one core nearly as much as a desktop, and the main performance edge of desktop CPUs for anything remotely recent has been more cores and being able to boost more of them to higher speeds at the same time. When only one thread in KSP is doing most of the work, a 4600U boosting one core to 3.3GHz or 4770K boosting to 3.9GHz doesn't make that much difference. In fact, it's pretty close to these exact 18% improvement when you look at single thread benchmarks, and for KSP, that's what matters the most. Unfortunately, not a lot has changed on the Unity side in the past decade to improve on that. And while there has been a lot of the improvement in cache and instruction efficiency, most of the tech improvement has been focused on getting more cores in. So if 13700K outperforms the aforementioned 4770K by a factor of 7 in overall benchmarks, the single thread improvement of 13700K is only a factor of two. In other words, if you took a main thread bound game like KSP that runs at 60FPS on a 13700K, it could still manage a marginally playable 20FPS on that old 4600U laptop. That's still an improvement, but not what we usually think of as 8 years of progress. Now, KSP had a lot of problems. There were per-frame update tasks that were very poorly written and optimized, resulting in majority of that performance hit, especially for larger rockets, to come from things that should have been almost instant to compute. We expect KSP2 to have solved majority of these. KSP 2 will also have a much better utilization of threads. They simply have to make good use of threads to get good enough performance out of the consoles, that are kind of running at laptop speeds, but with 8 cores / 16 threads. At the same time, some of the tasks that were expensive in KSP, like trajectory updates and physics, are still here and have gotten a lot harder, because now we have continuous collisions, ships using engines in warp, likely higher warp multipliers to accommodate interstellar, colony management, huge ships built at space docks, and so on. Most games on the market are limited by the graphics. This is why we're used to seeing 10 year difference in tech completely obliterating what used to be considered a high end game. CPUs haven't advanced nearly as much as GPUs, as there hasn't been quite the same market pressures there. And KSP was and KSP2 almost certainly going to be one of the few games where your CPU is what matters. And worse, the specs that matter to these games aren't what we usually see highlighted as important for high performance CPUs. A lot of conventional wisdom about games just doesn't imply. There is every reason to believe that KSP2 will run much better than KSP when benchmarked on corresponding contemporary hardware, but we'll really just have to wait and see how Intercept went about building this game in regards to how it will scale with lower end modern CPUs or some older hardware.

NAT definitely works differently in IPv4 vs IPv6, so yeah, I can see how net code designed to work with IPv4 NAT might be a problem here. For a little bit of a context, NAT is short for Network Address Translation, and any additional letters around it point to different ways it can be accomplished. I'm not an expert in how any of that works, but the gist is that under IPv4, because there aren't that many addresses (a little over 4 billion total combinations), your router at home gets its own WAN (wide area network) address, and any computers connected through it have to share it. So, maybe your PC is connected to the router directly, and your laptop and your cell phone are on WiFi on that same router - from perspective of greater internet, they all share an IPv4 address. But for your router to talk to each device, it assigns its own LAN (local area network) address to each device. So when you ask for a page of this forum, the server sends it back with your router's address, and your router has to figure out if you requested it from your PC, laptop, or cell phone (in the above example). When you are connected through TCP (which is used for all web requests), the router can look at additional information in the packet to match response to a request, and it knows which LAN address to forward it to. This gets complicated with games, however. Not only are they using the UDP, but you might also be the one hosting the server. When another player connects to you, the very first packet telling that they want to connect arrives at your router, and without some additional mechanism, your router has no idea where to send it to. Something in the game has to tell the router that you'll be expecting a request and where it should be forwarded. There are a number of different ways this can work (including IP spoofing in some older UDP games...) and none of it is completely fool proof. IPv6 is different. Because there are a lot of addresses available, your router doesn't just get an address, it gets a range. It assigns sub-ranges to devices on the LAN, so if you publish your IPv6 when hosting a game lobby, that address points not just to your router, but to the specific device you used to host the game. However, even here things aren't smooth, because of course it couldn't be simple, and you actually get several different IPv6 addresses assigned, and some of them are permanent, and others are temporary, and you're supposed to use them in different situation because security. And if you simply copy-pasted your old IPv4 code, you're probably publishing the wrong IPv6 address, which means at some point your connection might go away, etc. It all gets pretty complex, and this is why dev ops people and network engineers are paid good money.

It generally shouldn't. Usually, you're being routed through the same gateways, so in practice, there isn't too much difference. And if the servers are cloud-hosted, that will get translated to IPv4 anyways. There might be some issues if one of the players is hosting, and there's a mix of IPv4 and IPv6 addresses being used, but that has more to do with NAT at home router level than anything else. Outside of outright bugs in code meant to handle both IPv4 and IPv6 connections, I can't think of any meaningful differences, but maybe I'm forgetting something.

ISP is still significantly better for ions. Even your cheap grid RF iodine thruster, typical for cubesats, can do 2,000s+, while the absolute best you can do with hydrogen/oxygen bursts is something like 500s, and even that's probably not achievable in a cubesat. But the low thrust of these simple ions is a pretty big limitation in the kind of maneuvers you can do. If you want to actually do orbital transfers, being able to do short burns near apsides gives you a lot more freedom over the weeks-long ion burns. So going the electrolysis route is a very neat workaround. If I wanted to get a cubesat from LEO to LLO, I'd likely be prepared to sacrifice some of that ISP for the burst capability. Even if I'm unlikely to get more than 5m/s per burst.

Graphics-wise, I don't see any problems. Some of the techniques that Intercept is using are VRAM heavy, but we ran slightly scaled down versions of similar techniques on PS4 Pro hardware just fine. So, like, obviously you won't be running on ultra settings, but there is absolutely no reason you'd need to completely disable any of the visual flare to make it run smooth on a 1080. So long as Intercept lets us adjust fidelity on some of these things, like quality of volumetric effects, it can be dialed in to where you'll barely notice a difference running at 1080p. CPU-wise, again, lets hope, but my confidence isn't there. It depends a lot on how much of the optimization is in threading. Single thread on 4770K is actually pretty good, it's from the era of Intel processors when they were absolutely kicking rear in single thread performance. But if they game is heavily optimized to make full use of all 16 threads, there could be problems. That said, it would be amazing if you post your results when you get a chance to try the game. That 4770K would be a very good data point to try and figure out how the performance actually scales with hardware. As a matter of fact, we should probably have a thread somewhere, closer to early access release, where we have a set of save files with different rockets of different complexity and in different conditions, that people can run and post their hardware specs and uncapped frame rates for each of the examples. That way we can do proper science to it. It might help a lot of people, especially these with older hardware, to make a decision. Plus, if there are oversights, it might give Intercept an opportunity to locate additional improvements for the full release.

There are different ways to handle that from perspective of both the game code and design. While it seems reasonable at first to just make it a colony to conserve the effort of re-implementing the build system for KSC expansion/upgrades, the fact that KSC has a lot of custom structures might make it too complex. E.g., I'm pretty sure runways at KSC aren't going to be built out of colony tiles, in which case, you wouldn't be able to expand these trivially. So the KSC might not be a colony for the purposes of how things will be built. Though, I'm sure a lot of the code and assets will be shared, so I have no idea how much of a distinction there would really be.

Not "have to". It'd certainly be preferable. But technically, the plank for "has to perform well," is gen 9 consoles. If the consoles can handle it, you can ship the game, and odds are, your sales will be mostly fine. The rest is a bonus, as far as min spec for a title goes. It's a nice bonus, I'm sure Intercept is going to try hard to get the min spec as low as possible, and I hope they are successful in this, but there is no concrete obligation, either financial or contractual, so until there are official specs, 3700X is the floor of what we can be absolutely certain of. Likely, it will be lower, of course. As people have mentioned above, they really ought to try to hit good performance at least on recent R5 and i5 chips. But I don't think it will go a lot lower than that, and I'm skeptical of support for some of the older hardware. We do, indirectly have a lower bound as well. We know that the plans for gen 8 release have been nixed, kind of predictably. And I'm confident saying it's not because of the graphics. So we know the min spec is going to be significantly above what the PS4 Pro and XB1X are capable of. The CPU on these was very different from anything AMD released to the public in that exact architecture, but it's effectively two 4-core modules, each very similar to what they later released as part of their A8-6410 APU. So if you think of PS4 Pro or XB1X CPU as a pair of A8-6410s, you won't be far off. I've seen people compare it to FX-8150, but while there are a lot of architectural similarities, the FX chips run at much higher clock, 3.6GHz in the case of 8150, and so each core is nearly twice as fast as that of PS4 Pro/XB1X CPU. So the only way your FX-8150 might perform as badly as a gen8 console is if you have it severely thermally throttled, causing it to drop to ~2-2.5GHz and staying there. Needless to say, we can be all around confident that the min spec won't be that low. But there is a LOT of room between a pair of A8-6410s and an R7 3700X. The min spec for KSP2 is somewhere in there. You might call that uselessly broad, and I won't be offended, but honestly, that's all we have concrete data on. Everything else is speculation and some degree of wishful thinking.

I'm sure someone will come up with a mod like that if there are no stock hangars, though. Or we might be able to use colony-building tools at some point to just add them to KSC.

Can't really compare on GHz alone. This tells you that the most basic instruction, or a cycle, on CPU takes one 4 billionth of a second (0.25ns) to complete. But overwhelming majority of instructions take multiples of these cycles to finish. There was a lot of improvement in instruction efficiency in the past years. A lot of heavily used instructions have been reduced by a factor of 2 to 3. Integer division was something like 20 cycles. Now it's 4-6. So a modern 3.5Ghz CPU runs circles around the 10 year old 4GHz processor. And that's just raw compute. The other huge improvements have been in cache, scheduling, and branch prediction. Big chunk of CPU performance comes from how little time it spends not doing anything useful, and it comes down to knowing in advance which operations will need to be performed (in case of a branch) and having the data available, which is what the cache is responsible for. Modern games are pretty hungry for cache, so even if raw performance of CPU is there, if it can't feed all the data for all the necessary operations because of small cache and slow RAM, well, the raw performance just doesn't matter anymore. If we take that same AMD FX-8350 and compare it to a Ryzen 7 3700X, which is pretty close to what PS5 has, a single thread of Ryzen is going to be able to do nearly twice as much work in the same amount of time as a core on FX, and Ryzen can run two threads per core. So even though FX is 4GHz and has the same 8 cores as a Ryzen at only 3.6GHz, Ryzen's performance is nearly 4x as high. And the benchmarks I'm looking at aren't that cache-heavy, so I expect this will be an even greater gap in games. This won't be a problem for a lot of the games out there, but because we still expect KSP2 to be CPU-heavy, the only real benchmark we still have is that it has to run well on gen 9 consoles. So we know the performance will be at least decent on Ryzen 7 3700X, which is why I keep bringing it up. But will one quarter of that be enough to be playable? It's very hard to say. We will really have to wait and see some real KSP2 benchmarks on variety of CPUs once the Early Access is out to start getting a measure on this. It might be that I'm being entirely too pessimistic, the game will be optimized well enough to blaze through on consoles, and it will be very well playable on a good CPU from 10 years ago. But it might also not be, and at this point, I think best we can do is wait.

I can't imagine it's anything but historical. The entire rocket (some animated bits and robotics parts aside) could have been a single rigid body. If you don't care about the flex, it's very easy to solve the constraints matrix for the weld joints once and then you can compute stresses for joint limits very cheaply, and unless a joint somewhere fails, just treat the whole rocket as a rigid body. You only have to solve the constraints matrix every frame if the configuration of the ship changes every frame. The reason this wasn't done early on, I imagine, was simply because nobody thought about this being necessary. The first rockets were very, very simple, and you were supposed to just use a tank of the right size for the job, not stack four of them together. By the time players got their hands on the game and started building Kraken-summoning totems out of the parts given to them, the bendy, wobbly rockets were engrained in the players' minds. I'm absolutely sure that there was at least one meeting during KSP2 development where somebody on engineering said, "You know, we could just make the entire rocket rigid, and then we don't have to worry about any of this," and somebody on the design team would have to say, "No, we want them bendy," to that. By now, it got to be an intentional choice based on historic behavior of the rockets in the original game.

According to Unity's manual, it only needs the SSE2 extensions on top of the standard AMD64 set, which 1100T has, so technically, it should work. But I would expect it to struggle really bad. Only 6 threads, each one with a little better than half performance of modern equivalents, and not a lot of L3 cache - all of that is going to hammer KSP2 performance pretty bad. If you're going to not be running it native on top of that, like through Proton, I don't expect that you'll have a great experience. I would definitely recommend waiting to see how well the game runs for other people.

I think you're a bit out of date on solvers. Modern Havok solver, which is what's in Unity with ECS, uses an updated flow based on the work of Erin Catto. While the underlying principles are similar, the algorithmic approach is quite a bit different and results in much higher stability for long chains and much better performance. When implemented correctly, you should see no springiness at all outside of extreme mass differences in the chain. That is, if you have two 1T modules hooked up to a 1kg module in between, yes, you'll see problems, though, even these can be tuned out, and if you throw a single strut between the 1T modules, that will go away completely. The bending you see with KSP is virtually nonexistent with the new solver. You literally can slap a single constraint at every logical joint and be fine for most practical cases. It is also far more performant. I have looked at possible room for optimizations in Crystal Dynamics' implementation (see numerous physics puzzles in reboot Lara Croft games,) and I found no reason to mess with the solver itself. We had thousands RBs with thousands of contact points in a scene for Avengers, with no ill effects. (Avengers' overall performance sucks, but none of that is on physics.) Collision detection was absolutely the limiting factor for complex scenes, and that's the part that is most readily parallelized, so it hasn't made a performance difference either. If your experience with solvers is PhysX, Bullet, and Havok as it worked around 2017 or earlier, you might want to get a refresher. Physics in modern solvers just isn't done this way. Better examples include Crystal Dynamics' Foundation Engine, which is the first one I'm aware of implementing the new solver for a AAA game, modern implementations of Havok, and Chaos Physics from latest Unreal. The latter was still a bit unstable when I was doing evaluations for it, but that was in early private Beata of UE5, so I'm told these problems got fixed and it should be a good representation. Alternatively, you can go to the source, and see how Erin Catto himself implemented it for Box2D engine.

For KSP, absolutely. There is going to be a lot more pressure on physics in KSP2, though. It's a little hard to say exactly how hard Intercept is riding the physics engine in KSP2, but it's clear that they're stepping it up. Continuous collisions have been indicated in one of the blogs, which require more expensive spatial queries, and we don't know exactly how much physics will be done at what levels of warp, but it's clear that physics warp is going to be a more central features. This might be where the "physics LoD" is supposed to come in play, which I'm guessing is the treatment of larger sections of the ship as a single rigid body, but we don't have enough details on that yet. On the net, I expect both more optimization and more usage of the physics system in KSP2. Eh... This is one of the places where the boundaries gets fuzzy. I can certainly query PhysX in parallel job threads, but then do what, disable collisions for the main scene and manually create contact points as joints? I mean, it's possible, but then I have to manage my own collision cache, since PhysX won't know that these are the same collision points from frame to frame, and at that point, I should probably be using my own solver for it - no need to jam that ugly hack into PhysX. And then to avoid causing hick ups in PhysX, maybe I'll do my own BVH management. Of course, that would require a custom collision broker as well, and then why am I using a PhysX scene at all? You can replace pretty much every part of Unity with custom parts. You can also make a completely custom engine. That's a lot of work, though. So it's really not fair to say, "It's developers' fault," when Unity's implementation of PhysX is just bad, and would require you to rewrite the entire physics engine to get rid of all the problems. Admittedly, PhysX gets more crap thrown at it than it deserves for how it's implemented in Unity, but even so, it's a sub-par physics engine, and replacing that with Havok and building a new threading model around that with the ECS was the best way Unity was able to resolve all of that. Last time we got any concrete updates on this side of the tech, it sounded like Intercept was still using game objects, meaning they'd be stuck with the old style PhysX simulation. But that could have changed. ECS is becoming a new standard, and isn't that much work to convert to, so it's entirely possible that we're going to be looking at Havok physics, where there is way more flexibility in terms of how things are processed in threads. Plus, a way more stable solver.

Oh, yeah, for MP, you can treat each player's physics radius as its own scene. I have no idea if Unity actually has support for multi-threading parallel scenes, but for any custom engine this would have been an absolute freebie, for sure. And yeah, I'm one of the relatively few people still specializing in in-house engines. Fewer and fewer studios do this, but also, there aren't a lot of specialists who can jump in and work with a game engine from the ground up, so the pay is still good.

https://store.steampowered.com/app/1583540/Meco_Rocket_Simulator/ Definitely going to cost less than a house, and there's a thread about it in the community/science section.