K^2

This is why I'm save-hacking for now. I'm sure I'll try a real mission once I have a working ascent vehicle, but fighting Kraken on top of long transfers only to find out that you need an adjustment to design is not working for me. I'm happy enough just "teleporting" a craft from KSC runway to the surface of Jool and making sure I can take off from there. Edit: Need. More. Torque. (But also completely proves that the aerodynamics is bugged, as I can spin up to much higher speeds before detaching the blades.) About 15m altitude reached, which is not as good as 50m I got on Nerva, but then this is pure RTG power.

The second link in @Strawberry's post points to a general discussion thread on the topic if you want to add things there. Or there can be a new topic dedicated to rotorcraft if that seems too narrowly scoped.

With solar as your energy input, it's not bad. Not great compared to ions still, but it has an advantage that you can build up a bit of H2 and O2 and then do a power burst. So you can have high-thrust maneuvers while still being fairly efficient with mass and volume.

Out of curiosity, I did try building the jet/landing gear Kraken drive with NERVA, and it didn't work. That one felt less cheaty, since it at least uses fuel, but either I did something wrong, or it doesn't work with NERVA, or maybe it doesn't work at high pressure. I'm not fully giving up on rotors. I should be able to build a larger rocket with proper hubs that can support debris-based rotor blades. It does, however, mean a much, much larger lander. So that will be an interesting challenge with all the Krakening. Yeah, something clearly changed. Maybe someone was doing "optimizations," and "simplified," some code somewhere. Sometimes, it might look like you can take a computation out of a for-each loop to make things snappier, but for aerodynamics, you really can't.

It seems to work like a wing with particularly large area. So it only generates lift when moving horizontally, but it can generate a lot of it with even slow horizontal movement. This is why I'm not sure which exact aspect of the computation is going wrong. If everything was computed from CoM only, I would expect no difference between having the craft rotating and not, but there is clearly a difference. Perhaps, the AoA computation is relative to part motion, while the dynamic pressure is CoM only? That might be consistent with the observed behavior. Either way, there is a clear bug. These rotors should be generating a lot more lift.

I have not experimented with these enough. There are no thermometers yet, so that's out, but there are enough of small size parts that might be compatible. The underlying physics is largely the same, so the same principles should apply, but the tuning is different, which means other parts and connectors might be more Kraken-sensitive, which leads to problems. I've also encountered some bugs where certain configurations of connections and offsets are just refusing to stay attached, so you get entire sections just fall off your craft. That becomes more likely as you increase the complexity of the part attachments and offsets, complicating this whole matter. That's why I am leaning towards going simple and big, using wheels on round parts, for the next set of experiments.

It sounds like that salt's going around. But yeah, snake oil for sure. 1.8 MJ/kg of some top class experimental batteries vs 9.7MJ/kg of kerolox. That would be nearly half the ISP if you were jettisoning the batteries as you go, but expelling lithium would not only be far more expensive, but also go against their entire premise of environmental friendliness. So you have to drag these batteries with you until stage separation. At that point, a straight up water boiler rocket has better efficiency than the best they can hope for on battery power. My best guess is that their internal pitch must be trying to get ready for beamed power, and keeping their fingers crossed. But you can't sell that to the investors, so they're selling them the battery powered nonsense.

Indeed. I just haven't been able to come up with a better bearing yet. Well, not strictly a bearing, necessarily, but I do need some way to constrain the roots of blades to the hub. I do want to see if maybe we can build something like the old style rotor bearing here, using round structures and wheels. That will be a much larger craft, however. Still, that's probably what it's going to take.

The surface looks pretty intentional. We know that Intercept decided to stick to the metastable metallic hydrogen as one of the fuel types. It is based on an old, outdated hypothesis that hydrogen has a metallic state under high pressures that can be maintained under much lower pressures once achieved. While metallic state of hydrogen is pretty much a certainty under the right conditions, these conditions turned out to be far higher pressure at much lower temperatures than originally anticipated, and there is no longer a reason to believe that there is any metastability. KSP2's Kerbol system is located in a different universe, one where materials have somewhat different physical properties to our own. This is inescapable from the fact alone that Kerbin has 9.8m/s2 surface gravity with a 600km radius. The average density of Kerbin has to be about 58g/cm3. Densest known metal on Earth is osmium at 22g/cm3. We don't know of any materials that would reach 58g/cm3 even at the pressures in the Earth's core. Clearly, planets in KSP and KSP2 are made of some other stuff. Or, at least, stuff that behaves differently. So circling back to the metallic hydrogen, the surface pressure of Jool is a little over 5MPa. That's a touch over 50 bar. The "air" density, however, is only 6.7kg/m3 at 200K ambient. Substituting that into the ideal gas law, we see that the atmosphere of Jool has an average molar mass of 2.23. Which means its' mostly hydrogen. In fact, this is a good fit for 90% hydrogen, 10% helium, <1% methane. In other words, Intercept probably took Jupiter's composition for the basis here. But now we get to the surface. On the real Jupiter, that hydrogen-helium soup turns into a supercritical fluid, which continues getting denser without a big change in its other properties until we get to (what we believe to be) liquid metallic hydrogen layer. That liquid metallic hydrogen "mantle" of the planet extends down to the core, which has a rather fuzzy boundary, resulting in no real solid surface. The transition from supercritical hydrogen to metallic is also likely to be a fuzzy one, meaning there are no sharply defined boundaries anywhere, but we can break down the broader regions into the solid icy/rocky core, liquid mantle of metallic hydrogen with helium droplets, supercritical lower atmosphere of molecular hydrogen and helium, and gaseous upper atmosphere of the same. And now we get into the topic of metastability. If in Kerbal universe the hydrogen becomes metastable, what properties do we expect of this Jupiter analog? Well, we still expect the planet to have a liquid metallic hydrogen mantle. However, as the mantle circulates, the liquid metallic hydrogen that would reach lower pressure and temperature of higher altitudes instead of evaporating to a molecular hydrogen would instead solidify to its metastable metallic phase. This phase transition would expel much of the helium mixed into the composition, meaning the density of MSMH would be slightly lower than density of the liquid metallic hydrogen of the mantle. This is a very similar situation to what happens on Earth with all the molten rock in the mantle - the parts that solidify first near the surface form a lighter layer of various oxides that float on top of a molten metal-rich mantle. We end up with a solid surface. Except, on Jool, it's a solid surface of metastable metallic hydrogen. And indeed, the surface of Jool looks metallic. Naturally, at a low enough pressure, we expect MSMH to sublime into molecular hydrogen. Apparently, in Kerbal universe that happens at around 200K at 5MPa of pressure. Which is fairly extreme, but reasonable enough for storage and transportation for use as fuel. And, well, Jool is the place you get it from. How we're going to be transporting it off the surface remains to be discovered. But in a world where MSMH exists at all, surface of Jool would be one place you'd find it, and indeed, a surface made of the stuff is exactly what you expect and predict based on extrapolating Jupiter analogue planet to Kerbal scale.

This one? There is definitely similar use of strings, but that style goes back to a lot of adventure films, and from there back to classical music. If there is something more similar in Cities Skylines, I missed it. And yeah, this is standard music playing when you take off from Kerbin. There are separate themes for different situations on different planets. Not really sure how detailed it is, but it works pretty well where I've seen it used. I'm sure it'll get old eventually, though. Especially this particular piece if you have to restart a lot for a particularly tricky launch.

There seems to be an aerodynamics bug that currently prevents rotors from working properly, but so long as each wing moves as an individual object, it works as it's supposed to, so separating the rotor blades prior to take off seems to work. Briefly. This definitely needs more work to ensure that the craft isn't taken by the Kraken almost instantly. Still, as it might be the only way to fly on Eve and Jool, this might be an avenue for further experimentation.

That's not even a strawman. That's a crayon drawing of a strawman. Obviously, if someone forced @twich22to play the game, that's bad, and we should call somebody to go rescue them. But I'm pretty sure the implication is that they played voluntarily. They might have been misguided by something that led them to think that it's worth investing more time, but that still implies some sort of a "light in the distance," that the game provided. Nobody would spend more than fifteen minutes on a game if it was actually, literally unplayable as the title suggests.

Oh! I think I know why. I'm going to have to go build a new experimental craft! Edit: Ok, I don't know exactly why, but there's definitely a bug in how the wings are processed. It seems to be using craft CoM movement to either determine the AoA, or the velocity, or both. In either case, that would imply that rotary motion is effectively ignored. I'm playing with stages and seeing if I can come up with some sort of an arrangement that lets me use the torque to generate lift, but I'm starting to lose hope. I'm sure this will get fixed eventually, but that isn't helpful short-term. This suggest that ornithopter isn't viable either. We need an actual linear drive of some sort to maintain forward motion of the craft in order to get lift out of wings. It'd have to be a Kraken drive of some sort, I fear. (Something, something, chosen one, something, something, balance to the force.) Edit 2: Got something very basic sort of working. It takes off. Briefly. Since the aerodynamics of rotorcraft might be of interest beyond Jool exploration, I've split that off into its own topic: Rotorcraft Workaround Edit 3: The small NTR works on Jool, and I have been able to build a nuclear jet airplane, which managed to climb to a little over 50m of altitude. That is currently my record for ascent on Jool. I'm sure that can be improved on, but climbing even to 7k where any chemical rockets become viable seems just as out of reach as before. Experimentation continues.

Hm, yeah, after playing around with it, I think a helicopter is a no-go on Jool. The atmo is just too soupy, so even when I hacked the rotation speed, it'd get slowed way back down again. It doesn't take a lot to get a glider going, though. If one figures out how to do bearings, a prop plane might still be viable. Another potential option is an ornithopter of some kind using bendy physics and maybe landing legs to provide flex? Going to keep experimenting, but I'm back to the drawing board on this for now. A nice thing about KSP2's save system is that it's a lot easier to hack a starting location of a quick save. Here's a location block for starting about 180m over the equator going North at 10m/s. Note that the orbital elements are completely bogus (Carried over from Kerbin), but they get ignored due to the LocationType set to SurfaceCoordinates. If you want to start at a higher elevation, increase the number for localPostion.x. Note that it's from planet's origin, so 6000200 is 200m above the "sea level", or about 180m above surface at the relevant location. "location": { "LocationType": "SurfaceCoordinates", "serializedOrbit": { "referenceBodyGuid": "Jool", "inclination": 0.6278264218015327, "eccentricity": 0.99479775850994834, "semiMajorAxis": 300841.16646634549, "longitudeOfAscendingNode": 130.33767680426303, "argumentOfPeriapsis": 90.173730836902038, "meanAnomalyAtEpoch": 3.1415913216744689, "epoch": 23094.907076562049 }, "surfaceLocation": null, "rigidbodyState": { "referenceTransformGuid": "Jool", "referenceFrameType": "Body", "localVelocity": { "x": 0.0, "y": 0.0, "z": 10.0 }, "localAngularVelocity": { "x": 0.0, "y": 0.0, "z": 0.0 }, "localPosition": { "x": 6000200.0, "y": 0.0, "z": 0.0 }, "localRotation": { "x": 0.0, "y": 0.0, "z": 0.70710678118, "w": -0.70710678118 }, "PhysicsMode": "RigidBody" }, "originatingSimObject": { "Guid": "00000000-0000-0000-0000-000000000000", "DebugName": null } },

Can we do ye olde style helicopter built with reaction wheels? I know they're weaker than KSP's, but you also shouldn't need a whole lot of torque here with the right sort of a build. Procedural wings sure come in handy for building efficient blades.

Most games that come out are designed for about 20 hours of play time. You've spent 50 hours with an unfinished alpha full of bugs. I think that proves the game is very much playable. It's unfinished, yeah, but if people are putting in 50h now, what's that going to be like when all the features are enabled and the bugs are fixed? It's everyone's right to feel displeased, of course, but the kind of thinking that went into the thesis of this thread perplexes me greatly. And that's not to make fun of the OP, or anything, I hope I don't come off this way. I genuinely hope that people who put in dozens of hours before giving up now will be back to put in hundreds of hours more. I just don't understand this logic, is all.

It's in good shape for an alpha build. There are a few problems I'm surprised made it this far, like the fuel management performance and world origin relocation bugs, but for the most part, this is pretty much what I expected. A few graphics glitches, some unexpected performance bottlenecks, and frequent visits from the Kraken, but also many QoL improvements, beautiful environments, and overall playable game. So long as you save often and don't mind re-starting when something stops working. Clearly general population of users expected something different. Which, I guess, is not their fault, given that the marketing on YouTube looked pretty crisp and didn't really mention the problems. Although, I think by now people should understand what an "early access" of a game is. We should all get better about the communication surrounding this - developers, reviewers, and gamers alike. Early access doesn't mean you get the finished game early through the magic of time travel. You're playing an alpha, or in a best case beta, version of the game. By definition, alpha means playable to completion with major bugs. You can build a rocket to take you to any of the game's planets and moons and you'll be encountering major bugs. Alpha version - check. I understand that some people have been waiting for the game for a long time, and so falsely believe it should be done. It's not done, and it shouldn't be graded as a game that's done. Once again, for an alpha, it's in a good state, and I'm enjoying the experience. People who can only enjoy a game when it's finished and polished should wait until the game is fully released. And that goes for any game in early access. And yeah, communication about that could and should have been better, and that's a fair thing to call out on any review, but complaining about the fact that an early access game is buggy is just silly.

I like the idea of a bimodal NTR in the game, but it sounds like power generation doesn't take anything away from any existing engines anyways, and I don't see why it would be different for the in-game NTR, so it seems odd to even have an ability to toggle it off even if it's going to work independently of the engine being on. Based on how other parts are implemented in KSP 1/2, it would probably make more sense for a bimodal NTR to simply always have RTG-like power output at all times. The toggle might, honestly, just be a mistake. They might have been playing around with an idea of alternator taking away from engine's ISP, but then decided against it, took it out from all the other engines, and simply forgot to take it out from the NTRs.

You could, but even without caching, so long as you do this right, it's not an expensive algorithm. You can run it every frame and not make an impact. It's only when you screw it up that it gets expensive. I was merely pointing out that there are ways it can go very wrong, still give you correct results, but get very computationally expensive with larger rockets due to bad algorithm choice. It's one possible explanation for performance issues among many. One thing that hints to this possibility being slightly more likely, by the way, is that radial separators seem to have a cross-feed bug and continue providing fuel to the entire rocket regardless of stages. This can all be related. Or it can be entirely coincidental.

A graph with relatively few nodes can have a huge number of possible paths if you have a good number of edges. Note that a lot of these ships have a huge number of struts. If struts are considered for fuel flow, for example, the number of possible paths from engine to every tank can be enormous. A good algorithm doesn't have to touch every single path. We're not solving a traveling salesman here. But it's very easy to make a mistake in your algorithm that effectively results in every single possible combination being tried, and it can be hard to detect that problem in testing. If your test craft had 10 parts and no struts, it will still be instant, and the problem might only appear when you start building giant ships - which, yeah, will show up in testing, but there could have been other performance issues masking it until recently. If this is a problem, it's kind of understandable and should be easy enough to resolve now. It would just be ironic, seeing how that was a known problem with KSP, and somebody really ought to have checked to make absolutely sure they're not stepping on the same rakes. And, of course, it could be something entirely different. It is possible that PhysX itself has some sort of traversal issues with joints that this is manifesting. That might be trickier to identify and solve, but there are certainly ways of solving this one way or another. There is no legitimate reason for that kind of a poor performance. Just a bunch of plausible errors in code that can and should be fixed.

We still have names. Whether you like it or not, people are going to assign genders based on gendered names, which there are a lot of in the original, and it looks like the KSP2 is continuing with that. And if you have Kerbals with masculine-sounding names, it's not players' fault for feeling left out if they want female representation in the game. It's still on the developers to do right. This could have been side-stepped with fictitious names that are intentionally generated to be gender-ambiguous, but the ship sailed on that one. Kerbals are very anthropomorphic, have gender-coded appearance features and traditionally gendered human names. We might as well assume the Kerbals themselves are gendered for the purposes of diversity discussion.

I suddenly want some media interpretation of this where all the superheroes and supervillains are paid actors as part of the conspiracy by the police and organized crime to both bolster the police funding and for the real criminals to do their criming undisturbed. As for the topic, though, yeah, I think a turbine-powered hybrid vehicle is a good approach. I'd take something like a helicopter kerosene turbine or maybe even a train/submarine/tank diesel turbine for power, and have both a CVT drive from that turbine to the wheels that can be used at high speeds, and a generator/battery/electric drive setup to be used at lower speeds for optimal torque. This is similar to modern supercar hybrids (Lamborghini Sian FKP 37, Corvette E-Ray), but going with a turbine would allow you to go with even better power-to-weight ration at the expense of, well, making it very expensive. But a turbine intake in the hood of a Batmobile is a classic, and I think that's enough of a reason to go with this design. I don't think actual rocket boost makes a lot of sense, though. Yeah, it can give you accelerations significantly higher than 1G, which you might want, but it's a nightmare to build. Although, if we use bleed air from the turbine and run it into an afterburner style booster in the back... I mean, it'd give you the cartoonish flames out the back and maybe another half a G of acceleration while eating half of your fuel tank for that one silly boost. That actually does sound very Batman. Yeah, lets go with that. No real jet power, but a jet afterburner utilizing bleed air from the compressor on the main power turbine. Other than that, armor plating, obviously, but I think it should be kept to critical systems. If you start building a turbine-driven tank, fifteen minutes in you'll realize you're designing an Abrams, and that doesn't seem to fit the style. Just your basic ballistic protection against gun fire for the driver and critical systems. Tires I would make airless. They're a hassle for civilian vehicles, but are used in some military vehicles, and I think they're a must for this build. One less thing to armor, too. Can't have any weapons on Batmobile, which is a shame, but harpoons aren't as silly of an idea as it might seem and would fit the style. You can design a launcher based on a standard police grenade launcher - might even be able to repurpose the ammo from either gas grenade or beanbag rounds. A fairly simple harpoon will puncture most street cars, embed well in a trunk, and allow you to bring that vehicle to a halt. Especially, seeing how this Batmobile is probably going to weigh like a semi with everything we're putting into it. Finally, one thing I haven't seen a lot of in Batman films/games (I'm not much for comics) is cammo. I don't think we're going to be disguising this version of Batmobile as someone's sedan, but there are now adaptive e-paints for cars on the market, that might help it blend in better with the environment in the right sort of situations. Failing that, just paint it black. Like, the blackest black. Add some infrared lights to go fully dark, and good luck finding that car at night. Again, very Batman, if you ask me.

As above, but also, water can exist in a lot of states. Some of these are simply traces of more abundant water in the past, which can establish both a firmer timeline of when the water disappeared off the surface and why, which is of obvious importance to us, humans. And yet another aspect of it is finding water that still in the state that might be useful to either some extant life on Mars that eluded our detection until now, or more likely and practically, for any future missions to Mars. A common argument against habitation of Venusian clouds, for example, is lack of water vapor, but water locked in sulfuric acid is just as useful for a colony. You literally just need to heat the atmosphere to a few hundred °C, then cool it back down to extract water. On Mars, we're definitely out of luck with atmospheric water and water ice is heavily contaminated and locked away in hard to reach areas, but some hydrated rocks are just as good as liquid water if you have the right equipment to extract it. Finding a lot of water in the right type of rock could make the idea of sustaining a colony and even refueling rockets entirely with local resources a very plausible concept.

You absolutely can. This is a Unity game. Even if all the assets were locked away inside the package files, there are ways to inject replacements. And if it's like KSP, where the part files themselves are loose, then it's just a matter of reverse-engineering the file format and writing a custom exporter, like a Blender script, for it. No decompilation or any other EULA-violating intervention required even. Hex editor and a bit of savvy is all that's needed. So we can have part mods within days of the early access released. Functional mods are another matter. That might take a while, and without an official API, I don't know if they'd be possible in a way that would be consistent with forum rules. So we might have to actually wait for the Intercept to release a modding SDK to have anything like robotics parts, for example. And yeah, if nobody else is going to be looking into it, I'll take a crack at a Blender script for part mods. I should have time over the weekend.

That might work. But again, I'm definitely not the right person to ask.