Starman4308

While some of those legs could swiftly get redundant, there are definitely niches for larger command pods and landing legs. Given the current state of affairs, there's reason to have at least 4 crew on a single pod and 3 on a lander. The lander could use a pilot (SAS), engineer (repairs, power modules for Breaking Ground stations) and a scientist (experiment resets, science modules for BG stations), and for LOR* missions, a second pilot remaining in the command module for rendezvous with the lander. *Lunar Orbit Rendezvous, i.e. Apollo-style missions where the command module stays in-orbit with a separate lander. While there are workarounds, many are not particularly aesthetically pleasing, e.g. having a Mk. I lander can on top of a Mk. II can. Adding 3.75m pods, or even taller 2.5m pods with +1 crew capacity could help. In terms of legs, there really needs to be larger landing legs which extend past the nozzles of longer engines. Otherwise, you get awkward things like putting additional fuel tanks outboard of NTR engines just so you can put landing legs which can actually reach beneath those long NTR nozzles.

I've noticed some balance issues with the consumptor mod, mostly due to the linear scaling of power consumed. It's trivial for anything in the inner solar system, and very expensive for long-range communications, particularly for those using OPM or other mods which add planets unreachable by 100G antennas. IRL, an omnidirectional antenna would consume power proportional to the square of distance, which is why pretty much everything going outside of Earth's orbit uses a directional dish antenna: the bigger the dish, the more focused the beam. This is part of why the higher-power dishes in the game are heavier: they're representing more mass dedicated to the reflector. There are three potential solutions, of which I'm trying option #3 (the easiest to implement). 1) Go full on Real Antennas, try to measure the size of the in-game model to figure out the gain, and potentially add a transmitter power value so one can pump more or less power into the same antenna. 2) Assume mass is correlated to the gain, and scale consumption accordingly. 3) Scale all antennas by a fixed power, for which right now I'm trying 0.4. The modified .cfg is spoilered at the bottom. On a sidenote, I've also taken the liberty of replacing the first two :LAST[CommNetConsumptor] statements with FOR[CommNetConsumptor] statements; that makes it easier for people to modify your values later.

You could ameliorate the spin by stretching out your arms and legs, but as mentioned by @Spica, angular momentum is conserved: you have to push/pull on something to actually get rid of said angular momentum. Reaction wheels/CMGs typically don't store that much angular momentum: they're mostly used for fine stability control on telescopes and other devices which need to maintain a very constant orientation. Even then, they occasionally have to use RCS to get rid of angular momentum before the wheels get saturated and cannot store any more angular momentum. IRL, spacecraft are either spin-stabilized, RCS stabilized, or stabilized by both RCS and reaction wheels (EDIT: Or stabilized by more esoteric methods like magnetorquers and solar pressure vanes) . This contrasts with KSP, where spacecraft are largely stabilized by magic torque machines misleadingly called reaction wheels.

If you purchased via Steam, Steam will handle that for you. For direct download from the KSP store website, I'd imagine you would launch the base KSP installer, then each of the DLC installers. There may also be other distribution platforms like Grand Old Games, for which if there are any nonstandard installation procedures, you might try asking that distributor. It would help if you stated where you purchased KSP from.

If everything were coplanar, there would be next to no difference between first going to a parking orbit, and just burning straight from the pad to Kerbin ejection, so long as they both followed a gravity turn. Direct ascent might be a hair more efficient in some cases due to not needing any coast phase, but you will not lose much dV by first inserting into a low parking orbit. Both would be substantially more efficient than anything involving going straight up. However, interplanetary transfers to inclined targets are usually going to favor going to a parking orbit first, for the simple reason that the point at which you want to launch into Kerbin orbit is dependent on the inclination of the ejection orbit, whereas the actual ejection burn is dependent on the location of the periapsis of the ejection orbit. If, for example, you want to meet Minmus 90 degrees after its descending node, you'd want to launch +/- 6 degrees north/south when KSC is underneath one of Minmus's equatorial nodes, and make your Minmus transfer burn roughly 90 degrees before its descending node (i.e. 180 degrees prior to where you want to meet Minmus). So, you meet Minmus +90 degrees after the descending node, transfer -90 degrees before the descending node, and ascend to parking orbit either at the descending node, or -180 degrees before the descending node (at the ascending node), which means a parking orbit. EDIT: One way to think about that minor advantage to co-planar direct ascents is that you still have to achieve circular Kerbin orbit prior to your transfer, but you can do so while still in the atmosphere: you can effectively make your transfer burn from a 50 km Kerbin orbit rather than a 75 km Kerbin orbit, as you don't need your "parking" orbit to be stable.

I think what he's going for is "Dres doesn't exist, so these images of Dres don't exist". Which is foolishness. While they may be photoshopped pictures of the Mun, images of "Dres" certainly exist on that page. In seriousness, one possibility is that Dres has been moved elsewhere, possibly to become a moon (similar to what OPM does to Eeloo). I do hope KSP 2 spices Dres up a bit: as it stands, the only interesting things are its orbit*, the canyon, and the sheer meme potential of an otherwise boring planet. *Dres's weak gravity well and moderately distant, inclined, eccentric orbit make it a challenge to capture around. Once you get there, landing and takeoff are easy, but you need a big capture burn with precious little help from the Oberth effect.

I doubt it comes close to eliminating gravity losses: you still have to start with a substantial pure-upwards component to get out of the thickest of the atmosphere, otherwise the aero losses are going to be absurd. As to why 2.4G, my guess is that it's a combination of shared hardware (i.e. the SRBs are also components of other rockets) and use of short-duration SRBs intended to get the core stage up to speed. My other guess, that it's an adapted ICBM*, doesn't really square with Japan's lack of ICBMs. *ICBMs intentionally have very high TWR to help get them through weather and get some distance from their launch site, which is a rather obvious high-priority target for enemy counter-force strikes.

While there are some issues with the stock game and I almost never play bone-stock anymore, name-calling is rather uncalled for. Do note that the original Squad team was made up of amateurs from an advertising company, and the current team doesn't really have the funding to pull out years of legacy code and game design decisions, particularly with KSP 2 on the way. As to why inventories are the way they are, my guess is that they wanted to highlight the new feature, especially so that veteran players knew it existed. I'd rather there be an option to have them collapsed by default, but there was a good reason to have them that way originally.

The stock UI is pretty awful for docking. The navball doesn't give you enough information, and the free camera swiftly becomes very disorienting. Navyfish's docking port alignment indicator mod (which I'm using on 1.11) makes it much easier by clearly displaying your orientation and location w.r.t. the destination docking port, such that the RCS controls become intuitive. Otherwise, @Superfluous J 's advice appears sound for trying to dock with just stock UI elements.

In terms of manufacture costs, I suspect high-performance rocket engines may be more expensive to manufacture than jet engines for a few reasons: 1) Jet engines are giant high-performance turbines, whereas rocket engines are basically large high-performance turbines with some other bits attached. There is likely some additional expense from the larger size of a jet engine turbine, but both are very complicated pieces of high-performance machinery. 2) Jet engines have only the fuel to worry about, whereas rocket engines have to have plumbing for both fuel and oxidizer. This often also means either gearing or a separate turbine is required for the oxidizer pump, plus more complicated injector design. 3) Jet engines typically rely on air cooling, whereas rocket engines require either ablative or regenerative cooling, the latter of which involves a lot of extra plumbing. 4) There is simply more institutional expertise and tooling for making jet engines. That might change, but there's a lot more jet engines being built than orbital-class rocket engines. 5) The margins for rocket engines are even more extreme than jet engines, as the cost of each additional kilogram is steeper.

Ironically, "it takes time to complete research" is my favorite part of Kerbalism. Granted, this is usually part of an RP-1 campaign with construction time, so you have to timewarp anyways. What I didn't like about the research lab was how much additional science it generated, trivializing the research subgame once you had a decent Mun/Minmus biome farm going. What I would at least hope for is more complicated mechanics than "press button when in correct biome". The Kerbalism mechanics already partially address this by requiring collection time, specific orbits, power generation and communications bandwidth, but it took until Breaking Ground for stock KSP science to be even slightly interesting.

Do you have any SENTINEL satellites in orbit of Kerbin itself? My guess is that they detect/spawn asteroids for the body they are orbiting.

My understanding is similar to that of @sevenperforce: most of the factors discussed above are irrelevant. The exhaust velocity of a rocket engine largely depends on three factors: 1) Specifics of the combustion chamber and nozzle geometry, which I will largely ignore. 2) Molecular mass of the exhaust gases: lighter molecules travel faster at the same temperature. 3) Temperature of the exhaust gases at nozzle entry: higher temperatures mean higher particle velocities. The lowest molecular mass exhaust gas you can find is hydrogen: H2, at 2 g/mol. The next best exhaust gases are all substantially heavier, e.g. methane at 16 g/mol, water at 18 g/mol. The advantage of NTRs is that you can have a pure hydrogen exhaust: even though the temperature is often lower than a comparable hydrolox engine due to more sensitive machinery, the very lightweight exhaust gases mean much, much better specific impulse. While you can still get acceptable specific impulses from methane and ammonia in a NTR, that's largely because those gases will often dissociate and produce some hydrogen in the exhaust. Water is a poor NTR propellant, as it's very stable and you get very little dissociation. Similarly, in chemical engines, you often see non-stoichiometric fuel:oxidizer ratios to bring down the average molecular mass of exhaust gases. Hydrolox (hydrogen + oxygen) rockets generally run very fuel-rich, such that the exhaust has large amounts of unburned hydrogen in it.

If it's a quadcopter, you could maybe achieve the effect by having the rear pair counter-rotating? I can't say I've experimented with quad-copters: the only helicopter I've tried so far was a pair of stacked, counter-rotating rotors. Which was fun, though those rotor blades made the descent through Eve's atmosphere painfully slow.

If anything, I'd maybe go for per-body skins for the same sets of buildings. Colder worlds, some insulation is evident. Laythe and Kerbin could use hard angles where most worlds would require rounded buildings built as pressure vessels. Airless worlds, you see some Whipple shielding for MMOD protection. Hot worlds, the non-radiator surfaces are uniformly white to reflect as much heat as possible. That would, of course, mean a lot of work by the art team, and I wouldn't necessarily expect it, though "we did a big art pass on all the planets" suggests the art team might have time for little touches like that.

It would almost certainly be cheaper and safer to have the nuclear power plant generate fuel on land (e.g. via the Fischer-Tropsch process), and run the aircraft on that fuel. There might be tactical reasons to have a nuclear-powered military aircraft, e.g. to have a very long-endurance bomber, but midair refueling makes that much less important as well. The big, expensive nuclear reactor with loads of radioactive fuel can power aircraft perfectly well without ever leaving the ground.

The goal of this challenge is to get to orbit of any body or otherwise conduct a mission without substantial LF/O tanks: it should be made as needed from ore using the ISRU converters. The Rules: 1) The only mass which may be consumed in-flight is ore. In stock, this means no ion drives, and solids may only be used for staging. Do note that due to ISRU converter warmup time, a small amount may be consumed at startup, so long as the tanks are small and replenished once the mission is complete. 2) If the craft uses electrically-driven propellers or other electric propulsion methods, keep onboard electrical charge to a minimum and use solar panels, RTGs or fuel cells to generate power as needed. In short: no batteries if there is an electric propulsion mechanism onboard. 3) You may use the debug menu or Hyperedit to get your craft into position for the launch, and it may start with pre-filled ore tanks. We can assume a separate vehicle filled up the ore tanks prior to launch. 4) Minimal liquid fuel and oxidizer storage, preferably less than 5 seconds' worth. As I found in my own attempt, though, the ISRU converters take a few seconds to come up to optimal temperature. 5) Disclose any mods in use. 6) The spirit of the challenge: make the resources you need as you need them, with the primary buffer being ore storage. 7) Screenshots, videos and craft files are highly encouraged. 8) Scoring: No formal scoring system will be used: this is a largely free-form challenge. The Demonstration As a demonstration of this challenge, behold the creatively titled OreToMinmusOrbit, capable of lifting off from Minmus using only ore. This is not a particularly exciting example: it's an ugly brick thrown together in a few minutes, and it was vast overkill for reaching Minmus orbit. It also runs an electrical deficit if the solar panels aren't perfectly aligned with the Sun. List of Submissions Minmus: @Starman4308 (See above)

While it only gets the Kerbals to level 3, it's relatively quick to have them plant a flag on the Mun and Minmus, then briefly pop outside Kerbin's SOI to get "orbited Kerbol" and the last few XP points needed to hit 3 stars. After that, though, you do need to go properly interplanetary. On the Kerbol excursion, a good way to do it is to exit time warp just before exiting the SOI, point retrograde, engage stability assist, and fire to cancel and slightly reverse your Kerbin-relative velocity once in Kerbolar orbit.

I believe Waterfall is meant to be installed on top of Realplume, and Realplume plumes get used if there's no Waterfall plume available. The primary issue is that Waterfall is still fairly experimental, so it's a question of whether you want to potentially deal with issues with the relatively new Waterfall mod.

The term "moderate" comes from the notion of moderating discussions, keeping things from getting too heated and keeping the discussion productive. Ideally, moderators should not need to use their unlimited power, but sometimes they do have to go full-on forum police.

To be more clear and helpful: The problem with this is Newton's Third Law of Motion: all actions are matched by an equal and opposite reaction. If A pushes on B, then B pushes on A. If A pulls on B, then B pulls on A. If the rear half of your spacecraft is attracted to the front half, then the front half is attracted to the rear half. You can't have one side pushing and the other side pulling. Otherwise, you get a universe without conservation of momentum or conservation of energy. It's why spacecraft usually use rockets*: with nothing substantial in the environment to push off of, the only thing they can push off of is themselves: thus, plumes of rocket exhaust exiting one way, the spacecraft accelerated the other way. *With the exception of things like solar sails, but those wouldn't work in an idealized vacuum.

I'm not entirely sure that, by itself, it's an interesting question. It mostly comes down to "how many identical mini-satellites are you willing to put on the same vehicle before you decide KSP was not meant to be a slideshow?" The primary issue is often that going big is usually limited by framerate rather than any aspect of the in-game physics, so it's a matter of patience and possession of high-end hardware moreso than any real skill at KSP. One excellent entry in the field, however, comes to mind.

Revamped art doesn't sound to me like something that would delay release of an already-way-behind-schedule game like KSP 2, especially when the planets already looked good enough. As such, I suspect the art team is just taking advantage of delays elsewhere to really polish up their work.

This seems to me like it'll wind up as a tradeoff of three things: 1) Packing as much fuel as possible relative to dry mass. An idealized aircraft would be nothing but Mk. 0 fuselages, with an 11:1 wet:dry ratio. Incidentally, this caps the minimum score as being 0.0055. 2) Maximizing drag. While there can be some drag from the fuel tanks, wing parts will likely be necessary: any fuel which isn't burned can be replaced by draggier parts. 3) Maintaining lift and controllability throughout the entire flight. This will mean even more parts which are not Mk. 0 fuselages. It also means the aircraft cannot be too draggy, else it'll simply fall out of the air. Ralanboyle's submission could likely be optimized with a few tricks: 1) Place fuel tanks radially rather than axially. All his fuel tanks were in-line with the cockpit, so their front nodes weren't generating any drag. Egregious part offset shenanigans may be involved. As an example: it might work to place the intake(s) on rear nodes, then rotate and translate them to face forwards again. That leaves the front nodes of whatever they're attached to exposed to drag. 2) Any tanks which aren't burned get replaced by draggier parts. 3) It might be more (in)-efficient to replace the wings-plus-spoilers design with a single surface tilted to have a high angle of attack. This way, one wing part can serve for both lift and drag. 4) Land only at the last possible moment, stopping at the eastmost point of the island runway.

There was some thread here a long while back with more detail on the clockwork rover designs. Long story short, I'm pretty sure NASA was envisioning a hybrid, using clockwork wherever possible so as to minimize the need for proper electronics, which are going to be bulky, expensive, and slow. Even with this, they've tested such amazing electronics as "4-bit multipliers", which suggests to me that we're not exactly going to be able to do optical hazard avoidance: a mixture of clockwork and high-temperature electronics is likely necessary.