Iskierka

I have noticed this on a Lynx rover without using Bon Voyage at all, so at most this is likely exacerbated by BV, not caused. It's much less extreme in my case, but definitely there across about half a dozen loads to travel further, and slowly growing. Additionally, when launching this resupply pod back to Kerbin, I had an odd issue where around 20-25 km away it would suddenly crash into ParallaxColliders, resulting in complete destruction, as well as teleporting the rover nearby and *also* colliding that with ParallaxColliders. I was able to resolve the situation by driving the rover away first, but there is definitely something odd when a grounded vessel gets unloaded from an ascending flight.

In that regard, I think the simple wikipedia svgs represent the trajectory poorly - the UVIS diagram shows periapsis being before noon, indicating it was a descending trajectory in solar frame. Given it's close to noon though, I'm not sure there's much boost - its purpose may be more to ensure that it can cross paths with Earth for a big boost that Venus could not provide easily. Still a valuable flyby to have.

Sorry to contradict you so completely, but the 1999 flyby was almost perfectly on the light side: Subsolar point, as google will tell you, is noon. Periapsis is within three "timezones" of the subsolar point. Completely light-side. Can't find details on the 1998 flyby, but that's the one you were uncertain about, and you were wrong about the one you were certain of. As for being able to do a dark-side flyby in stock ... It's in complete stock system, but it's close enough to the real system in ratios for all conclusions to be transferrable. It also starts the world at a convenient point: this game is at T+20 minutes from a complete new game start. All I did was put a test payload in 100x100km orbit then: -Ask Mechjeb's manoeuvre planner to plot advanced transfer to Eve -Select "ASAP", create node -add 2-3 m/s radial velocity to the manoeuvre And we immediately get the above trajectory that goes well above Duna's orbit. I'm more than halfway to Dres on ~500 m/s more than it takes to get to Minmus! For a bonus, trajectory deflection shows you this is also a dark side assist: Your problem is that you simply don't have the right trajectory still. If your source isn't giving you better trajectory conditions, you'll need to set about more experimentation to find the trajectory it's trying to suggest.

The magnitude does not change appreciably under any physical model. This is the point of conservation of momentum. In fact, neglecting the body's part of momentum exchange increases the desired velocity change in the solar reference frame, as it would, insofar as is meaningful, move the body in the opposite direction to what you desire, while your receding velocity will not be changed, thus being pulled back with the planet as its velocity change subtracts from yours. If the trajectory described that you wish to execute is possible at all, it is possible in Principia, despite having only momentum change, not exchange. If the trajectory does not make use of low-energy transfers and other unstable regions of n-body physics, it is 99% likely to be possible in stock KSP. Even if it does make use of such conditions where the approximations of patched conics are made bare, it can likely be approximated in stock, given it has sufficient energy to reach Mars to begin with, it will not be spending humongous amounts of time in these regions.

Or to clarify, it would not be possible to have meaningful momentum exchange even with celestial bodies not being on rails; even the largest Kerbal rockets are completely dominated in mass by the smallest bodies. This means that, even locking momentum of the body, so there is no exchange, there is negligible, or likely nonexistent difference with the fully simulated case, given computation precision limits. Do note that while there isn't momentum exchange, there is momentum change for the satellite; we can violate conservation here with no real consequences for the accuracy of the simulation, as the change would be eaten by double precision anyway. Scott Manley explains how gravity assists actually work, even without there being meaningful momentum exchange, and even in patched conics of stock KSP: How Gravity Assists Work

The problem with simplifying it this way is that g-force did not cause the pogo oscillation; it would not be prevented by shutting down two outboard engines, or shutting down one and gimballing to compensate. It's specifically the inboard engine that suffers and must be shut down, independent of what the acceleration is, and was a problem but tolerable from ignition to CECO. While limiting stress would potentially be an argument for the lower stage, it does fall flat noting, again, that the second stage has CECO at very low acceleration. This is a localised problem to just that engine that must be addressed.

Irrelevant, because the g-force measured is the acceleration of the rocket; as it is in no way connected to the ground, gravity does not influence experienced forces, as all things are falling uniformly, and the only non-body-force is that of the engine's thrust. The F-1 engine would also be capable of throttling with minimal modification; the required pieces of flow control valves, flow sensors, and control feedback systems were already all established in the engine to maintain proper operation at a fixed throttle. The only modification required to get some throttle capability would be a control unit that could accept a requested throttle and adjust the feedback loop accordingly. While the original engine could not throttle, it was not a physical limitation of the design, simply a practical matter. The CECO shutdown was also not to limit g-forces, although the pilots may have appreciated that factor more. It was to limit pogo oscillation, as the vehicle becoming lighter, as well as the increased duration of flight and reduced atmosphere damping meant the centre engine would start to bounce back and forth, restricting fuel flow as it came forward and compressed its supply line and increasing it as it fell back from reduced thrust. The thrust structure supporting the engines was only mounted to the main body around the outside of the vehicle, so the centre was not fully secured to prevent this; rather than add structural mass to do so, they stopped the engine before it became a problem. The reason is pretty much the exact same in stage 2, where you may note that the g-force CECO occurs at is significantly lower than stage 1 CECO, or especially stage 1's peak acceleration. This acceleration is clearly tolerable, so it's an engineering reason for stopping the engine.

The point is that the evidence still points to the exact same patterns of mixed scale/feather as we've seen in more complete but smaller tyrannosaurids. And regardless of scales or feathers, they're birds, not reptiles. https://en.wikipedia.org/wiki/Avemetatarsalia contains both all dinosaurs and all of the families that are popularly thought of as dinosaurs but not actually dinosaurs. The argument of size against insulating layers also fails as feathers are not purely insulating layers, as seen from the fact birds are mostly covered in feathers regardless of the temperature of their typical habitat. As for warm-blooded-ness, they have to be meaningfully warmer than reptiles, fish or amphibians. Many of them would be simply unable to possibly exist with the tiny metabolic rate of cold-blooded animals. There's also some more obscure-to-the-layman but equally telling features like microscopic bone structure, that points to rapid growth cold-blooded animals can't achieve. They possibly didn't meet modern definitions of warm-blooded from modern mammals and birds, but they definitely had elevated temperatures they were dependent on, and evolving towards modern bird's ability to regulate completely.

You posted previously in the Otter submersible thread, which has been packaged into the Exploration pack and so is not updated. If you have the USITools version from that, you are not running the latest version. Delete USI Tools, download USITools itself fresh from the catalog page, and install that.

"Most high TWR craft" is very few orbital rockets, however. In fact, I can only think of a few to be all-solid first stage (two to have flown, at the moment. Might be a couple more), when I could give a huge list of all-liquid launch vehicles. It's also incorrect to say that solids don't have heavy engines - as the entire container is an engine, and the entire thing must contain the pressure of the burn, solid booster casings are very heavy, are very dependent on the thrust they produce, and likely work out worse than liquid engines. The advantage of solids is they're cheap so it doesn't matter they have low performance in Isp and mass ratio, you can pack more to meet a bigger mission quite easily. ICBM design also isn't aiming for optimal at all. It's aiming for response time, and to minimise a potential risk of early-stage intercept (which is the most vulnerable part). They go way beyond what is helpful for TWR, and have considerably more aerodynamic loss because of it - much faster in low atmosphere, and must turn earlier to deflect their trajectory away from the vertical, whereas an orbital vehicle spends significant time thrusting up to gain apoapsis hang-time for upper stages to work. Adding more fuel significantly increases delta-V, at very minimal cost to TWR. That's the point of them being higher Isp, big changes for little cost. They go low TWR as there's nothing to be gained from more, and whether it was solid or liquid, more TWR would be more mass, and therefore a little bit more fuel and welcome to the rocket equation. Even solid payload assist motors largely only look at about 1g, tops. There's also never been note that rocket engines have struggled with g-force. Even in high-g malfunctions they have not had failures related to loads. Liquid engines are exceptionally high performance, and notably the SSMEs, which are hydrolox fuel and therefore incur a significant mass penalty for requiring two fuel pumps, were higher TWR than the STS SRBs, at 68.5:1 versus 64.4:1. Yes, this does not account for the fuel tank mass associated with hydrolox, but it also doesn't account for getting nearly double the specific impulse once a little altitude is gained.

Important note that this is a true but naive description that assumes flat surfaces and directly what is absorbed/reflected by the material. Vantablack is not a (very) good absorber as a material itself, as it is just carbon nanotubes. Vantablack is so black because the nanotubes are stood on end and any light they reflect bounces inward, into the forest of nanotubes, and will eventually be absorbed by something far more often than it manages to find its way back out again. Because of this, Vantablack is a major exception to the rule and is also a very bad emitter - any light it tries to emit is also likely to get trapped in the forest of tubes, and so be re-absorbed, and the energy is never lost. This does not, however, actually give anything you could really call an advantage. With normal materials that do follow that rule, all will equalise at the same temperature, as they emit as well as they absorb, but black materials do it better so will equalise faster. This would mean white materials are preferable for something you have to cool, as the rate of heating from the sun that you have to fight is lower, if you want to maintain a different temperature from that equilibrium. Vantablack is very bad here, because it does not equalise at the same temperature - it is an excellent absorber, but a terrible emitter, so it captures light, and never lets it go, getting hotter and hotter and hotter. Because of this, by the time it equalises, it will be having to dump a LOT of light at a very unusual and noticeable high-temperature wavelength, and if you're trying to manage the heat actively, you need HUGELY powerful systems to do it. Purely optically, Vantablack might technically work well, but it creates an engineering nightmare that is hard to work with and very visible to technology.

Those are KSP Interstellar radiators, by the right-click menu. The mod as a whole can be ... wonky, and doesn't like to use stock mechanics, which NF does for heat and such. Use a radiator that doesn't have the wasteheat resource assigned and try again.

The rule of thumb given here is one megawatt per kilogram (of ship), nothing to do with Isp. We can, however, infer Isp from that. Assuming an acceleration limit of 5g, we have 10 MW/kg / 50N/kg = 1 MW / 50N, which equals 20,000 m/s. A quick sanity check on the definition of thrust power ( P = Tv/2 ) tells us we need to double this to get the actual exhaust velocity, but this is only 4,000 seconds still, and qualifies as a torchship. To qualify as a torchship at 1g, we can now quickly infer an exhaust velocity of 20,000 s (multiply by 5). Very high, but not ludicrous for the kinds of technologies you would look at to make one. Interesting side-conclusion: the Sprint missile was a torchship. 100g acceleration, 20x higher than first calculation here. Divide the Isp by 20 to balance and it qualifies as long as its Isp is greater than 200 s.

The point of methane is it's only mildly cryogenic, and therefore fairly trivial to store long-term anyway. Cryogenic power requirements are, frankly, quite tiny if you plan them from the start. At 4:1 it is also probably the best ratio of hydrogen other than hydrogen itself, and high enough that it likely has better volumetric hydrogen density than most other options, despite having a low density itself. Of course, all of these suggestions are terrible if you are looking to use hydrogen as hydrogen in-flight, as they all require considerable power and heavy machinery to extract the hydrogen in the first place, ammonia borane for the heating to extract it and then machinery to do so safely, methane or hydrazine or other reasonable-density options for the chemical plant to separate it. Given this, it's very obvious that the best option, even for very long-term flights, is to simply store it as hydrogen in a double-walled tank, if you need to use it as hydrogen. Double-walled allows you to put a vacuum layer around the main tank, from which you can pump any escaping hydrogen back into the main tank - leaking being considerably more of a problem than cooling. Storing hydrogen in something else is only useful if you only need it at the very end (transport, where the place you're delivering it can provide the machinery to extract), or if you only need very tiny amounts released slowly, such as a car, with much lower power requirements than an aircraft or rocket, and few restrictions on the mass of the fuel. Volume matters for a car, not so for a plane or rocket - but mass does matter, a lot, and you're always putting a lot of not-hydrogen in the way.

It may be somewhat more compact, but that is an absolutely dreadful ratio of hydrogen by mass, which is the only thing aircraft or rockets care about. Methane is considerably better and nearly as workable, if you must find a way to make it denser. Nitrogen and boranes also sounds like a good combination for high toxicity and instability, though ammonia borane itself is apparently stable, you're gonna get nasties around it with repeated heating and reacting.