K^2

In terms of flight physics, I find it mostly salvageable. There are very specific ways in which you build aircraft to make them usable. But that's kind of true of real aircraft as well. I think the bigger problem is that once you collected science and some contracts from areas near KSC there's just no reason to bother with flight. Occasionally, it makes sense to make a suborbital space plane for a contract, but this is just busy work at that point. You never use planes for anything fun after the initial stages of the game. And that's made worse by the fact that a lot of good airplane tech is locked pretty far up the research tree, so by the time you have access to it, you can't make good use of it. Having airplanes as a starting point in career can make that all way better, IMO. And yeah, making aerodynamics a bit more intuitive and providing players with better tools to design functional planes would make it not feel like a waste of time.

Found your problem. I'm very sorry that you've clearly worked only in software sweatshops and never had experience working at a proper studio. Outside of some really bad mobile houses, nobody works this way in games. You'll notice that Intercept doesn't even claim to support these platforms. I get that you're bitter that the system reqs say that Linux and OSX are supported by KSP, but they aren't. Not really. You are running an unsupported version in the most literal sense. Unity has, fortunately, improved CLR on non-Windows machines recently, but none of these changes are ever going to make it into KSP. KSP was built on an older version of Unity that doesn't really support 'nix platforms despite any claims to the opposite. It was bad form of Squad to release it as anything but experimental. Intercept is already ahead of the curve by not claiming that they support Linux. Which is smart. If the version of Unity they settle on will have good CLR performance on additional platforms, they can easily port it. Otherwise, it's not a huge loss to them. Windows machines do not have this problem. Simple as. And your entire pages of complaints in this thread are basically just wining about a broken version. Could have saved a lot of time if you opened with that. I won't. I'll tell you exactly why you are wrong. On every single point. In detail. Anything less would be exceptionally rude.

If a wing moves mostly at speeds and in directions it was designed for, it's aerodynamic properties stay fairly well confined. You can get a pretty good model going by specifying wing area, center of pressure, glide ratio, critical angles of attack, and slope and intercept for the lift coefficient between these extremes. It's pretty close to what KSP does, and if your wings aren't doing anything weird, it's good enough. Of course, KSP wings often do something weird. If you have a procedural wing, you could bake out the same characteristics and still use the simple model, but it's actually more work. What you can do much easier is to treat each section as its own wing. Technically, it's nothing new compared to building out large wings from many, many sections, but such wings already behave better than larger parts. Procedural wing would also eliminate all the self-intersection and overlap problems when you are building compound wing, so you'd basically be getting the best version you could have hoped for with careful design automatically. Now, KSP stock wings have other concessions. They have a floatier feel due to lower drag at high AoA, they generate same amount of lift regardless of position, etc. That's likely to stay as is, by the sounds of it. Which is fine, IMO. Having procedural wings represented as compound sections would give you a lot more in terms of proper feel then a more honest simulation of individual sections.

Look, I'm not even a mechanical engineer, and if someone was to suggest this hack to me, I'd give them a death stare that would instantly make them reconsider. I might be placing too much faith in someone whom I know only from their LinkedIn profile page, but I don't think an FEM engineer is going to accept something with such obvious flaws. Never mind the fact that CoP is not going to move correctly, but you can literally just create a frame of a wing and use it as a full wing in that setup. I know KSP wings do a lot of dumb stuff, but this is an opportunity to do better. And you don't have to do fine simulation to do better. All you need to do is break the wing into smaller sections, each with its own surface area, chord, and CoP. Then just apply a standard lift and drag curves. Bonus points if you increase drag and reduce lift of the end sections to fake vortices. But even without that, simply simulating a wing as multiple sections would be an improvement, giving you both a more faithful simulation and better control over the planes you're building. And given that this is how all but top-of-the-line flight sims are set up anyways, it seems like it'd be a natural path forward with procedural wings and, by extension, flight dynamics in general.

Oh really? So you've ran performance captures, analyzed the results, and identified which portions of Unity engine are causing problems for KSP? Well, don't keep us waiting, do share. Now, I happen to know that all of the real bottlenecks in KSP are in CLR code. Unity Engine runs almost no CLR. It's all native code instead. GameObject behavior code does, however. So all of the issues are contained explicitly in game code. I also know what the game needs to do under the hood, and I know how long it should be taking for these systems to run. Again, making sure a game engine runs well is kind of my job. And the games I've worked on are a bit bigger and far more computationally expensive than anything KSP needs to do. Now, I'm prepared to break out the debug tools and we can start analyzing the code. I already know that fuel pathing is one of the bigger resource hogs, which means it's absolute garbage code. Updating debris in orbits is another - also shouldn't be wasting nearly as much time as it currently does. And I'm prepared to drag you through that source code line by line, 'cause "You are wrong. Sorry." is not the right answer.

It's literally part of my job to make sure games run well, which includes engine work, build pipeline work, and asset budgeting. If I couldn't look at how the game runs on a dev machine and anticipate problems in ship, I'd be crap at my job. Nothing in KSP requires that kind of heavy lifting. All of performance issues in KSP are from bad code, bad use of physics, or bad use of assets. Unless they want to try to get KSP2 onto mobile or Switch, they shouldn't need to worry about threading model. Is it possible that Intercept is making just as much of a mess? In theory, but that would imply that Intercept somehow has total amateurs running their engineering, while design, art, and tech art all produce industry-standard work. That doesn't happen in practice. A good tech artist will spot a bad engineer and vice versa. This isn't an amateur project. Intercept clearly knows what they're doing. I don't have a reason to expect them to do great at cutting edge tech, but fortunately, they don't have to do any of that. Just a competent, well organized studio that has people on it with years of prior dev experience is all you need here. If that was the only way to make it work, sure. But you can also include the builder in your binaries and have the mods be baked. That would require a slow load once, and then go back to fast loading unless any of the mod files change. I mean, that's literally how internal build tools work in every studio I've worked at or with. If your game starts with building every time you run it, it's a nightmare to develop on. Not only is it horrible for asset designers, but it's abysmal for debugging. Getting the dev build to load lightning fast is almost more important than getting shipped version to load fast. So a competent, well resourced team starts by making a build pipeline that works with this. For UGC, you recycle this behavior. Of course, it's an overhead. So if you never had an off-line build process to begin with, it's easier to ship as is, but what a nightmare it is to experience! That's amateur work, and as noted above, Intercept don't look to be staffed with amateurs. I've taken a look at selection of LinkedIn profiles. It's a very reasonable collection of backgrounds. Managers seem well seasoned and developers have experiences in the right areas. I see no reason for concern.

Intercept's physics programmer is from FEM background, so I think improvements on aerodynamics are very likely. Also, kind of necessary, since they're going with procedural wings.

I don't think you understand how game development works. Or "garage" startups, for that matter. @Master39 hits the main points. The largest company I've worked for was Google. Smallest rented out office space from a law firm. The smallest game I shipped was considered huge success when it crossed a million registered users after a year of continued updates. Biggest was considered a flop when it only sold three million copies in the first month. And while I'm tempted to nitpick a few things in Master39's post, it overall matches my impression of what T2/PD is doing with KSP2 in contrast to original development. Now, Intercept Games can still screw it up royally, but they are staffed with game dev veterans who know the tools they are working with, have the resources to do things right, and are on a very reasonable schedule to ship this game well engineered and well polished. Things I have so far seen Intercept do in terms of graphics are very performance-friendly. If they are putting the same kind of consideration into components code, it should be fine. The person they have on physics is a little green on game-dev experience, but has excellent academic background, so as long as they are performance-conscious, it should be fine. Finally, KSP's approach to loading assets being, "screw it, we're doing it live," just isn't generally a thing in game dev. I'd be mightily surprised if Intercept doesn't have their own build pipeline and are going to serve baked assets, which will speed up loading tremendously, not to mention help with memory overhead and leaks. At this point, the thing I'm worried about the most is networking/multiplayer, and I consider that to be optional for initial release, so that should help put my confidence level in perspective.

Yeah, when this topic went up, I immediately started thinking about a pixel-perfect conic section curves in a shader. And you can absolutely do this with a screen-space pixel shader, which would be a fairly platform-agnostic solution and you can reduce the overhead by having a single draw call handle an array of orbits, but it's still rather expensive. A better way is a geometry shader that effectively rasterizes a curve, but at that point, performance is comparable to simply segmenting the curve on the CPU side, visual difference exceptionally minor, and you certainly lose some flexibility in terms of supported platforms. Actually, I'm not sure what kind of support Unity even has for custom geometry shaders in the first place. At any rate, yeah, turning these curves into linear splines on CPU and sending them to GPU as vertex buffers is the right call here. Even though the perfectionist in me really wants pixel-perfect conics.

The only possible cause of death is cellular death of neurons in central cortex either due to pathogen or starvation. Both require a physical change. This contradicts your pre-assumption that nothing physically changed about the body. In contrast, human body has a number of options for self-destruction. It is relatively easy to cause yourself sufficient injury to bleed out, for example. Does that count as dying from pain response? *shrug* Processing information and turning it into physical change is kind of our whole deal, after all. So I don't think this is a well-posed question. There is no sharp boundary between autonomous pain response and conscious decision not to withstand the pain anymore. As stated, your question boils down to, "Should person ending their own life count as dying from pain in some cases?" And that's inherently a subjective question.

This exact idea is at least a century old. I'm not saying it's wrong, mind. Just that we haven't made a whole lot of progress on it, and it's unreasonable to expect that it would be resolved in the next decade or two.

And if the robots break? More robots? We can't build robots that don't require human maintenance down here on Earth. What makes you think we can do it on Mars? I mean, sure, if it's a multi-generational project, maybe we'll come up with something substantially better. But again, we can build sustainable - not self-sustaining, but truly sustainable long term - colony on Venus with tech we have right now. We do need a larger lifting rocket, but if SpaceX gets Starship to fly, that basically solves that problem. So we're back to the simple fact that sustainable colony on Venus by the end of next decade is something we can pull off if we re-task existing budgets, and it would be something we can grow incrementally. Sustainable long-term colony on Mars might not be possible this century, and we have to build most of the infrastructure before we send in people.

Yes, but way less light and more weather. And anywhere between equator and poles there is considerable air current moving towards the poles at relevant altitudes. Staying close to the equator allows you to do minimal station keeping while maintaining exceptionally calm atmosphere. Not to mention it's your best place for both launching to orbit and receiving freight from orbit. It's all relative. I would argue that carbohydrates are actually easier to get in moderate quantities on Venus. On Mars, you might be able to get large quantities of ice, but that would require a fairly polar region to have it in good quantities, which is an inconvenience, and it's all going to be dirty ice, so it's still a process. While CO2 extraction is going to be a pain at these pressures. On Venus, water for food and plastics required for upkeep is reasonably easy to extract from the clouds, while CO2 is available in spades. If you want to get enough water to make fuel, you'll need large collectors. So that's definitely not an option early on. But on the net, it still seems easier to get early fabrication going on Venus. And for colony sustainability, having easy, reliable way to fabricate materials for repairs ranks way higher for me than ability to build new structures from scratch and to refuel rockets. That said, yeah, Mars beats Venus in variety of what's easily available. Again, Martian dirt is going to be everywhere meaning that even if your minerals are right there it's actually going to be work, but not as much work as on Venus. Eventually, I suspect a Venusian colony will start dropping drone scoops that will bring up dirt and minerals every time the colony passes overhead, but this is maintenance and maybe slow growth kind of quantities. Venus isn't going to be a booming industry without influx of off-world ores. That said, given how easy orbital mining is in comparison to ANY of this, I'm not convinced we'll be doing a lot of that in gravity wells by the time we're seriously expanding our off-world colonies. So this might all be a moot point.

You are showing a lot of evidence for us studying Mars, which makes perfect sense. We can send rovers there and even get sample returns in the future. There is a lot of science to be done on Mars which can tell us a lot about history of Solar system, Earth, and life in general. There is no reason not to sand probes there. But none of this prepares us for putting boots on the ground, let alone build anything for staying on Mars. Curiosity and Perseverance are large enough to start testing ability to dig and lay foundation on Mars, but these weren't the missions they were tasked with. Absolutely nothing we've sent to Mars actually puts us on the way to a colony. Everything else is just posturing and PR. Idea of Mars colonies is popular with public. Martian made good bank. NASA is riding on it, so is everyone else. But it's still just science fiction at this point. I seriously don't think you're putting in perspective the amount of infrastructure necessary to survive on Mars more than a few months. You can't progress from one to the other on Mars. You can't just keep landing modules on the surface and assemble them together like in a bad sci-fi movie or a game. To survive long term on Mars, you have to go underground. That means digging out thousands of metric tons of dirt, assembling structures underground, then covering them back up. You need digging machines to do that, which needs their own infrastructure to support, and you'll have to bring thousands of people for short term stay to operate all of that machinery, oversee construction, and possibly do some manual work that the machines aren't specialized for. Construction of a sustainable colony on Mars is comparable to construction of an aircraft carrier or a nuclear submarine. But underground. In toxic dirt. In near-vacuum. On a different planet. Comparing absolutely everything we have planned for Mars to that effort is like saying that making a model rocket is a serious first step towards orbital launch capability. No. Precisely because dirt and rock are nothing like regolith nor Martian dust. Dust on Mars isn't as abrasive as regolith, but it's exceptionally fine and chemically reactive. It will get into every single joint in machinery, contaminate lubricants, and absolutely wreck any bearings. Not to mention power and cooling requirements. Mars has virtually no atmosphere, so anything that generates any amount of heat is a huge problem. All of the machinery for digging on Mars has to be purpose-built. Absolutely nothing we build on Earth is usable on Mars. Even electronics are going to be a bit problematic. Though, I suspect, for day-to-day use you'd be able to live with crashes and bugs, similar to how they make do on ISS. Contrast this to Venus where the only serious problem is corrosive atmosphere, which means you can't have exposed metal structures. But you'll probably want to build out of plastics anyways, and there are plenty of options if all you have to worry about is sulfuric acid. You'll still probably want to custom-build things, but you can at least use off-the-shelf parts like electronics, batteries, motors... An electric rotorcraft built for operations on Earth just needs some protective polymer coating in the motor coils and it can be used on Venus as is. Most crucially here, I think, is the fact that we can test pretty much everything on Earth and not worry that it will behave different on Venus. You keep saying that. But if your goal is to stay there, ability to stay long term has to be more important than ability to return. Sure, you don't want to fully deny ability to do so, but you don't need to ferry back absolutely everything that's heading to Venus. You just need to have capability to lift crews to orbit. Which is why it's not considered for absolutely any other purpose. Oh, wait. Starship is designed for Mars because that's what NASA was throwing money at. The moment they indicated they'd be open to spending on Lunar mission, suddenly Starship is a perfect fit for that as well. But in reality, it's just a convenient reusable rocket. It works great with direct landing on Mars because there is an opportunity to refuel there. Well, in theory. Infrastructure for it is another matter, and money to donuts that idea will get shelved for a LONG while. But that's an aside. You simply wouldn't use Starship for trips to and from Venus atmosphere. You would use a modified Starship or something similar for trips to and from Venusian orbit. It's a perfect craft for doing round trips between orbit of Earth and orbits of Mars OR Venus, and that's by design. It's meant to be versatile. And if you don't need to land, Starship is perfectly capable of bringing enough fuel for a return trip. That means the rocket you bring to atmosphere of Venus only needs to be capable of bringing colonists from Venus out to an orbital facility for transfer to Starship or another interplanetary vessel. A Falcon 9 delivered to Venus can easily lift half a dozen people out of that gravity well. But in the long term, I imagine we'd switch to an SSTO plane of some kind. It would be parked in orbit where its cryogenic fuels won't cause problems until it is needed. At that point, it can dive into atmosphere, dock with the colony, pick up passengers, and take them to orbit where it would be refueled by one of Starships or w/e. The turn-around can actually be more efficient than Earth-Mars missions and you wouldn't rely on refueling infrastructure in the short term. Like I said, I expect actual manned Mars missions on Starship to end up being similar, requiring an orbital refueling. Yeah, but Pilgrims didn't need 21st century Plymouth just to survive. The environment was habitable. There were local food sources. And while there were new local sources of mortality, they didn't have to deal with anything like ever-present radiation and toxic dust flying around near-vacuum. You simply can't build a Mars colony incrementally. It's too hostile of an environment. You can on Venus, because Venus is very nearly habitable in the cloud layer. But Mars is just too much. Well, sure. Once you build something of that scale. On another planet. In near vacuum. In soil whose characteristics we do not fully understand yet. Derinkuyu took centuries to build. And we don't have lift capacity to make the progress a lot faster. Plus, exposed rock as your walls isn't an option. Absolutely everything you build must be air tight. Which means you'll have to deliver materials for structural support, wall paneling, airlocks, etc. Like I said, a better comparison is building an aircraft carrier on another planet. US managed to build a dozen on this planet. I don't think we can be expecting serious progress on it this century. Venus we can colonize incrementally. We can have first people on Venus next decade who will permanently stay there if desired, provided continued supply deliveries from Earth. It is a simple impossibility with Mars. I don't see how this is even an argument when one can be done in a decade and another takes a century at best. And it's still life underground in low gravity vs open skies of Venus. Why is this even a contest?

Possible, but I'd rather go with a dedicated inflatable section. Breathable air is a lifting gas, so you can have an inflatable greenhouse floating alongside the main habitat. So long as you bring plants that require small amount of soil and can be sustained with drip irrigation, the whole thing can be light enough to require almost no additional support. Since you'll have plenty of sunlight and you can run the greenhouse a bit CO2 rich, you can have very fast growth cycles with some plants. Fully sustainable might still be a reach for something that can reasonably be deployed from a single launch, but it can certainly supplement mission supplies allowing for much longer stay before resupply is needed. Under peak CO2 conditions, plants can get to about 5% efficiency of incident solar to carbohydrate energy. Venus gets 2.6kW/m2 under direct sunlight. That's about 400W/m2 of average* insolation. A 2,000cal diet averages out to about 100W, so you can in theory sustain a person with just 5m2 of plants under ideal conditions, but I don't think anyone has figured out how to get these levels of efficiency from agriculture. It does sound like a possible avenue for exploration, though. The other limiting factor is water. You have about 0.1g/m3 of sulfuric acid haze at relevant altitude. I don't know how much water content is in it, but worst case scenario, if it's exceptionally dry, you get 18g of water from 98g of pure sulfuric acid. The 2,000cal diet is designed around 2L of water intake. Biosynthesis of 2,000cal of starch will take up another 300g of water. So very conservatively, say about 2.5L per person per day. So that comes out to capturing almost 140,000m3 of atmosphere for the condensers. That isn't actually that much, as it's just 1.6m/s average through a 1m2 aperture, which is a very reasonable flow, but it's a significant amount of hardware that has to work day and night for the duration of the mission. But again, all of this can be improved with resupply. We don't currently have anything like a working plan for a self-sufficient colony on Mars. I mean, there are ideas, but they all involve massive infrastructure - nothing you can bring along on a few Starships. So if we're doing a resupplied mission either way, Venus is still way easier, as you won't have to worry about gardening or water capture. And if we want to go towards self-sustaining, there is a clear opportunity to gradually scale up operations on Venus, vs having to build entire infrastructure on Mars before it's even a consideration. * Note that for day-night cycle, we really don't care about planet's rotation, as it's super slow. But the winds super-rotate, resulting in a day-night cycle of about four Earth days. So at equator, the average insolation is roughly 1/2pi of peak.

US wants to go to Mars, because that's where they wanted to go to during cold war to beat USSR and back then, we didn't know just how crappy Mars' surface is. Not that we cared too much. All you had to do was get boots on the ground, not establish any sort of long term colony. Today, China just wants to go there to compete with US, and that's it. Russia's claims about having a Mars program aren't even credible, and even China's are in way too early of a stage to call it anything concrete. So really, US wants to go to Mars as some sort of cold war vestige and publicity stunt, and that's about it. "Every single national program," is such a huge overstatement here. And do what with them? Surface structures on Mars aren't suitable for long term habitation. Between radiation and toxicity and abrasiveness of Martian dust, just waiting out for next departure window on Mars is a huge challenge. You have to dig to build anything remotely sustainable for long term habitation. And that's not something you're going to be able to do with a few landers. You need to land an entire infrastructure on Mars before you can make it habitable. There are a few projects that suggest turning Martian dust into printable material to construct mounds over landed habitats, but even that's a huge undertaking. Contrast this to Venus where a single lander with a balloon and additional inflatable sections can be suitable for long term habitation. Something like Starship would actually work perfectly, as it can survive the re-entry and has enough volume to bring in the inflatables. You'll have to find a way to resupply it, and you'll have to find a way to dock a return vessel to it, but at least you don't have the fundamental problem of people not being able to survive there with minimal equipment. No. It's a problem for humans, though. A big one. And since we're trying to find a place where people can live long term, picking a place that's better for equipment is hardly the best criterion. Yeah, it's a lot easier to organize a return trip from Mars. So if you want to just visit it for a few months, just to put a check mark that you've had boots on the ground, by all means. Go to Mars. I mean, honestly, that's all these gov't space programs are trying to do. Get good publicity stunt of having people walk on another planet. But that solves absolutely none of the long term issues. Gravity problems can be overcome if you have enough space, and radiation if you have enough shielding. You can't do either with a few landers. You have to build major infrastructure. And then you're still living short miserable lives in cramped underground tunnels, because that's the best you can hope for on Mars. I just don't even see the point.

While a particular low periapsis near a neutron star should result in orbits that are noticeably not Keplerian, the tidal forces at that distance will also rip apart any ship. If we were to have something like a neutron star in the game, I think it should simply have a "kill" radius similar to how the gas giants work. It could probably even be marked as "sea level" in UI so that you know to stay above it. And anything safe distance away might as well stay on rails just like with every other body in the game, as deviation from classical orbit wouldn't be high enough to bother with. Unlike neutron stars, black holes don't really have an upper limit on mass. At least, not that we know of. And particularly massive black holes can actually have very low tidal forces all the way down to event horizon. You can survive a dive into a supermassive black hole like the one at the center of our galaxy. Well, survive passing the event horizon. Once you're through, all trajectories lead to singularity, and at some point tidal forces are coming for you anyways. But the point is that you can't handle supermassive black holes with the same approach as neutron stars for purposes of the game. You'd have to actually model all the nonsense going on if you wanted to be remotely realistic, and that's a bit much even for a game running on a completely custom engine, let alone poor old Unity. So my vote would be a definite no on black holes, but a maybe on neutron stars. Just treat them basically as compact stars with a tidal stress kill radius and no special physics beyond that.

Their arguments certainly involve the broadest topics, subjects of matter, and you simply cannot deny the gravity of it all.

Fractal universe would imply that average density is a function of distance over which you are averaging. If you plug something like that into GR equations, there are consequences to how the universe expands. There might be some observations that are more consistent with expected behavior of homogenous universe vs fractal universe. But this goes beyond my expertise. We're firmly in territory where you need a real cosmologist to clarify things. The only thing I'm fairly certain about is that none of this puts fundamental physics into question. Just our understanding of structure and history of the universe. Which might be completely earth-shattering discovery to cosmologists, but for anyone in adjacent fields it's, like, "Oh, cool. Doesn't change any of the physics I have to worry about." I've left academia long ago, but that attitude probably won't ever go away. XD

So this is where English gets weird. Syntactically, the breakdown is mo-du-le. I mean, that's what that 'e' is there for, to give you an open 'u'. And 'o' also ends up open. An open 'e' at the end is silent, so that one's easy. Open 'u' makes that 'you' sound, and open 'o' can have a bit of an 'ow'. So what you have is mo(w)-d(y)u-l(e). Now, hardly anyone actually pronounces it this way, but we have the word modular, and mo(w)-d(y)u-lar is a common enough pronunciation. But for module by itself, language happens. First, in modern English, terminal 'e' is just silent, not reduces. So these sylables merge. You get mo(w)-d(y)ul(e). Now that second sylable is a truck for your tongue, and that's probably what accounts for the drift from d(y)u to dju. As discussed, difference is mostly in voice timing and tongue position. But once it's there, it changes sylable timing and, therefore, boundaries to mo(w)d-jul(e). Final change is that first sylable sound closed now, so the 'o' is no longer drawn out. You get mod-jule. And yes, because of this, that also carries to mod-ju-lar, even though that has nothing to do with pronunciation rules. But the critical thing is that even though complexity of the sylable is what makes "correct" mo(w)-d(y)ul(e) pronunciation awkward and uncommon, that same drift from d(y)u to dju can hppen anywhere, even at the beginning of the word, where it won't impact sylbic structure.

Presumably. The problem is that if this relevant size is larger than observable universe, it doesn't help us any. It also makes the question of whether it really is homogenous on grand scale untestable. Technically, fractal fractal distribution of matter is still on the table, and that can have some interesting consequences.

How would that even happen? A syllable only begins with a vowel if there is no consonant before it.

The only reason Dres looks weird is because it's alone, and I think that's purely a limitation of a game being a game. If we were to see Dres as just largest of the belt asteroids, its orbit looks like remnants of a failed planet formation which could be due to interaction with Jool. A rogue planet can definitely be captured if it interacts with any planets within the system, but stable orbits involving more than two objects are exceptionally rare. The only exception I'm even aware of that occurs naturally is the Janus / Epimetheus situation, and that one's only possible due to both of them being light compared to Saturn that they are in orbit of. There are some theoretical multi-body structures that are gravitationally stable, but they are all too precise to occur naturally. (See N-Body Choreography). So a rogue planet is bound to remain a true rogue unless captured, potentially passing through star systems, but no more than once. For the purpose of a game like KSP2, I would be happy with a rogue planet just having a fixed position - same with stars. You can have considerable relative velocities between stars, but in a game, that introduces a lot of technical questions that just aren't worth addressing, IMO.

I'm not aware of any consequences to fundamental theory. We expect universe to be homogenous on large enough scale, but what exactly is "large enough" is not fixed by anything specific as this is an emergent behavior. I don't think we learn anything about fundamental properties of gravity from this. However, cosmological models usually assume that observable universe is homogenous. 3bly structure challenges this assumption. If that assumption is wrong, we can't rely on simple models of universe expansion, meaning their predictions might be wrong. Again, I don't think there are qualitative impacts, but we might be wrong about age of the universe by a few billion years, or something like that. That's my read on this, but I'd definitely run it by somebody who has more expertise on cosmology to be sure. I could easily be missing something.

Nothing terribly useful, I'm afraid. If we were to imagine that Eeloo's orbit is caused entirely by some external source, then it has to come close to Eeeloo's apoapsis, which is actually not all that far out. If some mysterious planet X is lurking far away from Kerbol, surely, it'd be much further than that. However, the fact that Eeloo's periapsis is close to Jool's orbit makes it way more likely that Eeloo's orbit was altered by Jool's gravity. In the latter case, current orbit of Eeloo tells us nothing about what deflected it into inner system to begin with. Now, Eeloo and Jool don't currently pass all that close to each other - closest approach is about 16 million km due to inclination, which is greater than distance between Kerbin and Kerbol. If Eeloo was deflected by Jool, the orbits had to have come a lot closer than that some time in the past. It's hard for me to say if perturbations from Jool's gravity alone could account for that much drift. But then, there is no other obvious source. Unless a rogue planet happened to pass through Kerbol system at some point in the past, I have no other explanation.