Starman4308
-
Posts
1,751 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Starman4308
-
-
17 minutes ago, Intercept Games said:
-
.png ":1437623226_rocket_1f680(3):")
Maneuver plans are now constrained by available fuel and will no longer provide false projections that extend beyond vehicle's capacity. R.A.P.I.E.R. engines must be set to Closed Cycle mode to allow accurate orbital maneuver planning.
Is there still a way to plot maneuvers otherwise? I haven't played KSP 2 yet, but I'd much rather have a warning of "not enough dV" than not be allowed to plot at all.
For example, I often stick a satellite in low equatorial Kerbin orbit to plan out interplanetary launch windows, but that satellite wouldn't actually have enough dV to go there; it's just for coarse pre-mission plotting.
-
-
On 4/13/2021 at 2:55 PM, swjr-swis said:
Just a FYI: SAS only cares about keeping the nose/front of a craft (*) pointed at the marker. It doesn't at all care about the craft's orientation around the axis towards that marker, so it literally does indeed do nothing to stop or avoid rolling.
(*: more accurately, it cares about pointing the control direction of the active probe core/command pod/docking port at the marker. Generally that will be the nose/front of your rocket though.)
Is that for the hold-prograde mode? In the stability-assist mode, SAS does damp out roll. I will also note that the Smart A.S.S. module of MechJeb lets you specify the roll, plus offsets to roll+pitch+yaw from surface-prograde.
To the OP: try whacking alt-X in case, for some reason, you have some trim set. Otherwise, roll can be caused by flexible joints (both axial and on radial boosters) and SAS overcompensation. To avoid the SAS overcompensation, as mentioned by @swjr-swis, reduce your control authority: limit engine gimbal and roll control on aerodynamic surfaces. To minimize flexibility, try to avoid wide-narrow-wide joints, and consider using struts, particularly for radially attached boosters. I usually attach an extra strut from the top of the booster to the core stage to help keep them pointed straight and avoid inducing roll.
-
My vote's on false vacuum collapse.
Sure, you'll die too, but it'll be an unstoppable, near-light-speed wavefront that effectively nullifies chemistry as we know it by dramatically changing how particles interact... and also releasing tremendous amounts of energy along the way. It may well be that new processes, possibly new life, can evolve in a post-vacuum-collapse universe, but virtually everything that depends on how particles currently interact is kaput.
If it's possible, it will almost certainly happen in the extreme-far-future (i.e. heat death), potentially reheating a frozen universe to something which can once again sustain complex processes... but such a universe would behave quite differently from our own.
As an analogy: it is entirely possible that there was some sort of gravitational chemistry going on in the very early universe, maybe even life. If intelligent life evolved from that, and you described an atom to them, they would see it as a result of heat death, because those can only possibly form at ludicrously low energies and low densities, and would interact based on forces which aren't generally meaningful*. A post-vacuum-collapse state would be to us, as we would be to a hypothetical early-Big-Bang civilization.
*Due to the sheer abundance of mass in the early universe, the non-gravitational fundamental forces we are familiar with (electromagnetic, strong nuclear, weak nuclear) would've been irrelevant.
-
Leftover satellites are also very convenient for the Grand Slam passive seismometer experiment (Breaking Ground): I've ended a number of probes' lives crashing them into airless worlds for the seismic science.
This... doesn't work so great on bodies with atmospheres, even Duna's relatively thin atmosphere. Without a heatshield, you tend to either burn up too quickly, or lose too much speed.
-
At very high timewarp values, I've noticed that EC drain becomes inconsistent with what's experienced at lower timewarp.
As to non-cheaty solutions: it's either RTG spam, fuel cell magic*, or installing a mod like Near Future Electrical which has nuclear reactors.
*At least with an engineer onboard, you gain more EC from burning LF/O in a fuel cell than you lose mining and refining ore to LF/O. Suffice to say, that isn't how things work IRL.
-
1) Computational fluid dynamics simulations, something of which I have no familiarity.
2) Build it (or a scale model of it) and test it in a wind tunnel.
3) Guesstimate the ballistic coefficient based on published ballistic coefficients from similar-looking rockets.
There is no easy, analytical formula for drag: everything is either an approximation, or computationally demanding and an approximation, because differential equations are fun like that.
-
Some of the engines don't really closely match their real-world analogues' performance, as they were designed to fit gameplay niches first, historical accuracy second. This is why the pressure-fed hypergolic AJ10-137 equivalent (the Wolfhound) has the best chemical vacuum Isp, whereas the hydrolox J-2 and RS-25 engines (Skiff, KS25) have relatively mediocre specific impulses.
On a sidenote, the RS-25 did have a relatively narrow vacuum - sea level performance gap, part of which was the extreme chamber pressure, and part of which was a specialized nozzle design intended to salvage as much vacuum performance as possible while avoiding flow separation at launch. It's not that much wider than that of the KS-25 engine, which spends more of its burn time at sea level.
The other component that would be missing from real-world performance is tank dry masses. In KSP, a tank is 1/8 as massive as the fuel it contains (a 9:1 ratio). The Shuttle External Tank, IIRC, was something like 98% propellant, 2% dry mass, a roughly 50:1 ratio.
-
In theory, so long as you plan and execute your first Mun encounter perfectly, you can get a flyby of every body in (almost*) any order on a single burn of less than 900 m/s. In practice, you're going to need to pack some dV for correction burns, and some flyby orders are going to be easier than others (e.g. it's probably easier to set up a Moho -> Ike -> Dres sequence than an Eeloo -> Gilly -> Bop sequence). The problem with this is largely one of human precision, with a touch of machine precision, as the longer your mission plan is, the more even a slight error in velocity or position will propagate to ruin the planned sequence.
*The Mun has to be first, and the second target has to be easily reachable from there (e.g. Eve, Kerbin), but once you get some orbital energy, you can go nuts. Just... not so nuts that you hit Kerbol escape velocity without a braking flyby set up.
-
For a low delta-V option after LKO science, you can also do a free-return around the Mun (and Minmus): with a scientist and experiment containers onboard, that should let you harvest all the materials science + mystery goo, thermo+baro, crew report, and at least some of the EVA reports from space high/low over said moons.
Do note that a perfect free return is difficult to get without a relatively high flyby of these moons, so I usually reserve a bit of delta-V for a correction burn.
EDIT: For bonus points, slingshot from the Mun to Minmus, then back to Kerbin, possibly using a second Mun encounter on the way. One low delta-V mission with a quite high science reward.
-
If you're willing to use lots of gravity assists: less than 1500 m/s from LKO, enough to set up an Eve flyby, then small correction burns. Were I to do it, I'd probably pack 3 km/s or so, on account of being OK but not amazing at setting up gravity assists.
If you're wanting to land on every body, that's going to take some doing, and would be most practical via use of ISRU. For that, in addition to gravity assists, I'd probably budget at least 4 km/s on the main transfer vehicle, and probably put Eve, Laythe, and Tylo landers in orbit of those bodies ahead of time.
Well, I'd actually just skip Eve, but the principle stands: a main transfer stage, an ISRU tanker/lander attached to it, and pre-place specialized landers near every body for which the general-purpose tanker won't really work. I'm sure people have done single-launch missions to the surface of every body including Eve, but I'm willing to do multiple launches.
-
It's the same as the question "why have an extra pilot on a mission?" There's sometimes call for a pilot to remain on an orbiting mothership and have one on the lander so both have probe-core-less SAS, but admittedly pilots are relatively easily replaced by probe cores once you have relays set up.
-
1) Assuming an ore concentration of 100% (I haven't actually done any asteroid mining), 6 junior drills would be 6*1*1*1*0.05 = 0.3 ore/sec, for a mass flux of 3 kg/sec. As to why mass is not conserved... are you playing with a stock game, or running with mods?
-
On 5/21/2021 at 1:22 AM, SOXBLOX said:
Summarizing the AR link I gave above, as fuel rods are used in chain reactions, they fill with "nuclear poisons" (so called because they poison the reactions), which hinder further reactions. A Dr. John Schilling says maybe a full day of full power operation would create enough poisons to require reprocessing (i.e. melting down the rods and removing the poisons). Some other guy says you could get perhaps 20k hours from a reactor using HEU and special techniques. Higher enrichment means longer runtimes. Usually only 15% of the available fuel is actually consumed; the rest is just trapped in poison.
I suspect that "full day of full power operation" might be "if it's run for a full day, the fuel rods are no longer safe to handle without full-on nuclear-waste precautions".
Either way, I'd be surprised if an NTR had to be refueled at all unless it was also being used for electrical power during downtime, as it's trivial to run a nuclear reactor for far longer than an NTR will be used as a rocket engine.
-
Magnetic accelerators in space wind up being very similar to rocket engines: in order to deal with the recoil, you still need to eject something out the back, which means reaction mass. The energy can be obtained from solar panels, an onboard nuclear reactor, etc, but you still need to chuck something out the back.
Even ignoring that, there's another issue. A GTO transfer is, IIRC, something like 2.2 km/s. At an acceleration of 5Gs, you need a 48 km accelerator to reach that velocity. Escape velocity is roughly 3.9 km/s, so a 152 km accelerator. A higher acceleration will be very problematic for fragile cargos, especially untrained human beings. Even then, the rule-of-thumb is "5Gs for 5 seconds" for the general public, and either of these accelerators are going for much more than 5 seconds.
*I'm going off of memories from playing RO, so the figures may not be exact.
-
One issue there is that it doesn't really fit an in-game niche.
The real-world air-breathing ion thruster works at a transition zone between "really high atmosphere" and "really low space", where there's enough drag over days/weeks to cause a deorbit without propulsion. It's not powerful enough to go anywhere, it's just there for station-keeping.
In KSP, there's a hard boundary between space and not-space. Maintaining a stable orbit is as simple as reaching a periapsis of 70001 meters. There's also the fact that in the not-space zone, rails timewarp is prohibited, so you can't get a useable orbit there without painful amounts of 4x physical timewarp.
There's no real station-keeping in-game, which is this engine's sole niche (and even then, it's a niche-of-a-niche only applicable in a narrow transition zone where there's enough atmosphere to run the engine without being so much that the ion drive can't counteract atmospheric resistance).
-
I've started landing burns on < 1. You don't need to start with TWR > 1*, you just need to end there.
*Throughout, I'll be referring to local TWR, dependent on the body's surface gravity.
The theoretical optimum depends on the moon and engines in question, as it's a tradeoff between minimizing engine mass and minimizing gravity losses. High TWR reduces gravity losses, as you spend less effort hovering, but involves a larger engine mass.
Smaller bodies will tend to favor higher TWR, as there's less time to burn off propellant, and the mass cost of increased TWR is lesser. With bodies like Tylo, you can burn off so much propellant in the early stages of your descent that your TWR at landing is noticeably higher, and trying to increase TWR means a lot of engine mass due to Tylo's high surface gravity. With a 30 ton craft at Gilly, going from a TWR of 1.5 to 3.0 means adding a second ion engine.
In practice, higher TWR landings are easier, especially if you want to land on a precise spot. If you descend too fast and are about to smack into terrain, high TWR lets you pull up much faster.
EDIT: It also depends on whether you expect to utilize ISRU refueling for the ascent. If your vessel has a TWR of less than 1.0 when fully loaded, you are not going to be able to take off with a full tank. When landing, minimum fuel mass coincides with highest gravity losses (just before touchdown), whereas for ascent, highest gravity losses occur at maximum fuel mass.
-
It sort of represents dwarf planets like Ceres and Vesta, due to its moderately distant orbit and small size.
I'm really hoping KSP 2 planets will be more interesting, even if "dull gray rock" or "frigid iceball" are two of the most realistic planet types.
On a sidenote, if you can transfer direct to Eeloo, you should probably be able to transfer direct to Dres.
-
While the inclination is a problem, it's not the biggest problem. The biggest problem is that Moho is in a much lower specific-energy orbit: if you transfer straight from Kerbin to Moho, you're traveling several kilometers/sec relative to Moho at the encounter.
What can save you several km/s is using gravity assists off of Eve and Moho to shed some of your orbital energy. It's a little tricky to set up courtesy of the differing inclinations of Kerbin, Eve and Moho, but a careful series of gravity assists can really help you shed energy and enter Moho's SOI with a much lower excess velocity.
The three tips I can give: take careful note of where you encounter a planet when setting up a gravity assist (as you will always wind up returning to roughly the same spot), it can help to set up resonant orbits (e.g. having a 2:1 vessel:Moho orbital period ratio so you re-encounter Moho in two of its orbits), and remember that gravity assists can change inclination as well as orbital energy.
EDIT: And if you're wondering what I mean by "shedding energy", that's basically just going to a lower orbit. While going into a lower orbit means you pick up kinetic energy, you lose more gravitational potential energy than you gain in kinetic.
-
Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.
-
Minimizing the potential for fuel crossfeed may also help significantly, as evidenced by Stratenblitz's recent megaton rocket: https://www.youtube.com/watch?v=iaZ3U6lNvBQ . As a corollary, it may be best to have fewer, large RCS tanks vs. many small ones placed where there's room.
-
65C is actually quite tame. I'm given to understand most chips are designed to run up to 90-100C.
As to the "memory leak", odds are that's just lazy garbage collection. If your system was actually running out of RAM, Windows would refuse to allocate more to KSP, and KSP would do more frequent GC runs.
-
Eh: to me, it just looks like a really deformed cube.
Obscure jokes aside, I wonder if Puf might have a moon to which it is mutually tidally locked, similar to how Sputnik Planitia is at the Charon antipode of the Pluto-Charon system.
-
That FAR is a thing indicates it should be possible to have a relatively realistic aero model. The stock KSP aero model is roughly reasonable for craft which look at least a bit like real-world planes and rockets, but swiftly breaks down once you learn and begin to exploit the rules of the stock model.
-
6 hours ago, Spacescifi said:
Air is a lot less dense than water so you need more kinetic energy to apply to it to get it to do work for you.
Not really. The astronaut there generated very little kinetic energy, as evidenced by his very slow movement.
He generated plenty of thermal energy, because the conversion from chemical to kinetic energy was very inefficient. Without a large surface area, something like a wingsuit, the human body is hard pressed to transfer much momentum to the surrounding air. While travel in air is typically less energy-efficient, the full story is more complicated than that: it's a matter of engineering moreso than theoretical physics.
Pretty much all atmospheric or water-based engines exist on a spectrum between giving a small acceleration to a lot of fluid, or a large acceleration to a small amount of fluid. The first is more energetically efficient, as while momentum transfer is p=mv, kinetic energy transfer is k=1/2*mv^2. As such, the ratio of kinetic energy to momentum transfer k/p = v/2.
With air, each liter contains very little mass, so atmospheric engines tend towards the high-exit-velocity low-exit-mass end of the spectrum, as you would need a very large propeller or jet engine to act on a comparable amount of mass.
With water, the surrounding fluid is roughly 1 g/mL, making it much easier to engineer a propeller or turbine moving a large mass at a low exit velocity. On top of that, instead of using lift to avoid falling to the ground (necessitating high speeds and high atmospheric drag), ships primarily use buoyancy. They don't need to go fast, so they can optimize their speed almost solely based on water resistance.
The key reason why it's difficult to make atmospheric engines as efficient as water-based engines is simply due to difficulty in getting enough surface area to intake the necessary quantities of air, but that's an engineering restraint, not a law of the universe.
6 hours ago, Spacescifi said:Air is a lot less dense than water so you need more kinetic energy to apply to it to get it to do work for you.
Not really. The astronaut there generated very little kinetic energy, as evidenced by his very slow movement.
He generated plenty of thermal energy, because the conversion from chemical to kinetic energy was very inefficient. Without a large surface area, something like a wingsuit, the human body is hard pressed to transfer much momentum to the surrounding air. While travel in air is typically less energy-efficient, the full story is more complicated than that: it's a matter of engineering moreso than theoretical physics.
Pretty much all atmospheric or water-based engines exist on a spectrum between giving a small acceleration to a lot of fluid, or a large acceleration to a small amount of fluid. The first is more energetically efficient, as while momentum transfer is p=mv, kinetic energy transfer is k=1/2*mv^2. As such, the ratio of kinetic energy to momentum transfer k/p = v/2.
With air, each liter contains very little mass, so atmospheric engines tend towards the high-exit-velocity low-exit-mass end of the spectrum, as you would need a very large propeller or jet engine to act on a comparable amount of mass.
With water, the surrounding fluid is roughly 1 g/mL, making it much easier to engineer a propeller or turbine moving a large mass at a low exit velocity. On top of that, instead of using lift to avoid falling to the ground (necessitating high speeds and high atmospheric drag), ships primarily use buoyancy. They don't need to go fast, so they can optimize their speed almost solely based on water resistance.
The key reason why it's difficult to make atmospheric engines as efficient as water-based engines is simply due to difficulty in getting enough surface area to intake the necessary quantities of air, but that's an engineering restraint, not a law of the universe.
EDIT: Please let me know if this double-posted: I wound up having to click "Submit" twice.
.png ":1437623226_rocket_1f680(3):")
Maneuver plans are now constrained by available fuel and will no longer provide false projections that extend beyond vehicle's capacity. R.A.P.I.E.R. engines must be set to Closed Cycle mode to allow accurate orbital maneuver planning.
[1.12.x] SystemHeat - a replacement for the CoreHeat system (October 9)
in KSP1 Mod Development
Posted · Edited by Starman4308
You may not have the nuclear engines module installed.
Anywho, bug report of my own for the CryoEngines patch: if the loop temperature exceeds the boiloff point, it doesn't seem to ever stop boiling off. What I suspect is happening at the code end is right here:
https://github.com/post-kerbin-mining-corporation/SystemHeat/blob/master/SystemHeat/SystemHeat/Modules/ModuleSystemHeatCryoTank.cs#L659
The radiators on my craft are probably asymptotically approaching 300K from above, and are at something like 300.00001K. However, it's a strict <= comparison, so it needs to actually reach 300K to stop the boiloff. 299.99999K is alright if you start from below, but 300.00001K isn't.
The quick-and-dirty fix is to multiply getMaxSourceTemperature() at that line by something like 1.001. The more elegant fix is to have the loop temperature setpoint held a few Kelvins below the boiloff point.