natsirt721

You will probably never see the enhancements you want for two reasons: 1. KSP2 is in development. For any studio this is going to be the primary focus. 2. Its pretty obvious that KSP EE was a cash-grab to try to open the market up to more causal console players. From the sheer number of separate keys I use to fly some of my vehicles it seems insane to attempt to reduce that to controller inputs, but alas, they tried. And failed, from what the reviews suggest. The games runs mostly fine most of the time, and with a 64 on metacritic the aren't going to be too concerned about trying to save that reputation. tl;dr console is not the primary audience, and thus won't get as much effort as the PC build. Sorry you got duped, just get a PC.

Agreed. Engineering is about compromise. Sometimes you're not going to be able to do the thing that you want - that's ok, because you can probably do something similar. I have successfully used the large LF wings on some spaceplanes, but you have to be very careful about your entry angle. I had to add a few airbrakes to the rear and fly with a very high AoA while high up in order to bleed enough speed before entering denser air. Lost a few of the prototypes coming in too hot. I found it helps to keep them as full of LF as possible, increasing their thermal mass and the time it takes for them to overheat. Frankly, they are not designed for spaceplanes anyway, so the fact that they don't immediately poof on reentry is a blessing imo.

Thanks for the reply, I figured something like that was going on. Kinda frustrating that the altitude extends so far up, as you can't really have anything stationary at that altitude given the limitations of the game engine. Also doesn't look like there is a way to modify that without recompiling, so I guess I'm going to have to boost my altitude a bit so I don't run out of power every 3 days.

The problem is that the the closest approach indicator looks for a local minimum distance, rather than the absolute minimum distance along the entire orbit of the vehicle you're planning for (or something like that, either way it doesn't do a good job). For simple orbital geometry this is sufficient, but you appear to have found one of the cases where it is not (planning a direct transfer from kerbin to Moho is another one). Fortunately, there is a workaround, not altogether unlike the solution you have described. When placing maneuver nodes, the closest approach algorithm starts searching from the time of the final node in the plan. If you know approximately when your intercept will be, you can place an empty node at that time, and the closest approach indicator will snap to the time of the node, or the next minimum distance after it (usually the former, in my experience). From here, you can do a two-step dance; tweaking the burn vector slightly and adjusting the time of the dummy node until you achieve an SOI change.

I think I may have found an issue with the way that vehicle attitude is persisted, but I have an old version of the game and a modded install so I'm going to spell out my test case and see if 1) it is actually a bug and 2) ask that someone attempt to duplicate the test case and see if it is actually a bug. Situation I have placed a vehicle in a 30 degree inclined Mun orbit at 55x57 km. I set the camera to ORBITAL, and align it so that Kerbin is in my field of view. I crank the time warp up to 1000, and as expected, the camera remains fixed to the attitude of the vehicle. However, as time passes Kerbin remains in the field of view of the camera. Problem I would expect that in this case, Kerbin would drift off the left edge of the camera plane, and eventually return on the right side of the plane sometime less than one Munar orbit later. The attitude of the vehicle should remain fixed in inertial space, and the camera, being fixed to the attitude of the vehicle should remain pointed at the same location on the skybox. However, by following Kerbin, it seems that the camera is rotating with the orbit of the Mun, and thus the vehicle is also being rotated in the same way. As the vehicle's attitude should remain the same w.r.t. inertial space rather than the local space of its parent body, this appears to be a bug. Help! If someone can reproduce this in an unmodded game on the latest version, then this is probably the result of one of my mods causing the issue - likely Mandatory RCS's persistent rotation feature. I did disable the feature and restart, and while I did observe the same behavior it may be making further-reaching changes that the feature toggle affects.

I think you got more or less everything covered, but depending on the nature of the colony some of those may not be strictly necessary. I'm assuming that the environment is friendly or at worst neutral to a human presence, apart from the local fauna - the air is breathable, the temperature is temperate, the soil is rich enough for cultivation. If you don't have some of those then the colony would need some higher tech levels in order to provide e.g. artificial fertilizer, or perhaps advanced drugs to allow humans to digest the local flora, or suits or breathing apparatus - things that would pose serious detriments to the colonists if they were not present. If the colony is relatively accessible, then it can probably sustain a high tech level and can grow rapidly. In this case, you would probably start with a post-industrial tech level. Farming would be largely mechanized, and the colony would closely resemble a small modern town - shops for selling imported or exported goods, healthcare services, perhaps an open-air market for local artisans, but otherwise any profession that you could find in a town of say, 5000 people or so you would probably have there. The colony would start small but would grow quickly if the opportunity for free or subsidized land was accessible to laypeople from the homeworld, and ships would arrive regularly bringing more people, manufactured goods, and other necessities the colony couldn't produce for itself. Within a few decades the population would swell to the point where it was more or less producing all the technical goods that it required, and would be on par with a small city from the homeworld. In order of priority from your original list, here's how I think the population distribution would go in decreasing size: 5 & 6: architects and engineers. I'm considering the people that do the construction as engineers, although many of them would be working under an engineer and may be unskilled laborers. With the colony growing rapidly, the need for new buildings and infrastructure is going to be large, so most of the population would be dedicated to either construction or bootstrapping the industrial capacity of the colony 1: farmers. Farming would be at least partially mechanized, and in some circumstanced may be entirely automated. Still, the farmers would be responsible for maintaining the machinery and providing raw inputs (fertilizer & seeds) and moving food to the populated center. More people means more mouths to feed, so farmers could make up a significant fraction of the population if the work is less automated. Law enforcement. You touch on this with 9: hunters a bit, but law enforcement's role would be more defense of the colony and internal conflict management rather than food acquisition. If the environment is sufficiently hostile, this camp could even be the largest proportion of the population (e.g. RDA security from Avatar). Bureaucrats: someone has to manage the limited resources of the new colony, and nobody better suited to do that than a burgeoning bureaucracy. initially, the bureaucracy may be tiny or nonexistent, but would grow as more concerns needed addressing by central leadership. This category also includes the 'mayor' and other public servants. 2, 4, 8, and everything else: In this scenario, the population is expanding rapidly, so most other fields of specialization would come quickly as more people arrived. Doctors and medical staff would likely be on the first ship down, but aided by their technology and the small size of the colony it is unlikely they would be a significant fraction of the population. Scientific staff: as mentioned by others, scientists would love to get their hands on a new world. If the world is totally fresh, then a wide variety of scientists would be vying for a seat o the colony, but in general they would be a smaller proportion of the initial population. There would be no need for 7 or 3, beasts of burden would be replaced with mechanical counterparts, and no breedstock would be required due to the constant external influx of people from the homeworld. If the colony is not accessible, than things are going to be a little different. In this scenario, it is either hard or expensive to get from the homeworld either due to the cost of interstellar travel, the travel time from the homeworld, or other economic factors. Ships arrive once in a while, but the cadence is significantly slower or perhaps even nonexistent (abandoned colony scenario). For the colonists to survive here, regardless of their original tech level (which we can assume is significant, after all they are interstellar colonists), it is likely that they would adopt a more primitive lifestyle, probably around 1800's tech. The original settlement would be augmented with high-tech things from the original settlers, but the majority of people would likely start out as farmers, supporting a bare minimum number of other specialized professions. Unless the seed colony was large enough to start an industrial base on its own, it is unlikely that they would be able to maintain the high-tech things they brought with them for an extended period of time. In this scenario, it takes decades to even begin the process of industrialization, spurred on by what little technology they have functioning at that time. As above, the roles in decreasing size: 1: Farmers. Farming in this scenario is a manual process, so most people are going to produce their own food. Unlike the previous scenario, the vast majority of people would likely be farmers or otherwise employed getting food (hunters, butchers, etc), perhaps upwards of 80% of the total initial population 7: beasts of burden. Either imported or domesticated from local fauna, beasts of burden would provide much of the 'tractive effort' of the fledgling colony, especially assisting with farming and transportation needs law enforecment, doctors, and engineer(s), and more: The central area of the colony would be small, but it would have most of the necessary professions to keep life going. A professional engineer to repair gizmos (if they are able), a doctor or two for when people get sick and to provide counseling needs, and other basic professions: a tavern, a cooper, a smithy, a potter, a teacher for basic education of children (advanced education would either be inaccessible as children would work on the farms, or done via apprenticeships), basically everything you would find in an early 19th century prairie town. scientific staff, again in the central area. Depending on the circumstances of the settling of the colony, they may not be present at all. There would be no need for breed stock - everyone would be part of the of the breed stock, there is no reason to have people specialize in that. What I might see possible is a sperm/egg bank, or even zygotes for IVF - 200 people is not enough genetic diversity without purposefully introducing mutations in newborns.

One possible use may be to launch bulk material into orbit, a sort of poor-man's mass driver for an atmospheric body. Water ice, aluminum, steel etc. for an infantile orbital manufacturing industry, until asteroid mining or lunar export becomes practical.

GUT generator attached to a photon drive. Infinite fuel, and a free petawatt laser in case the locals get frisky. May lead to minor vacuum decay.

In the .sfs file, there is a block called FLIGHTSTATE. One of the items in there is UT, in seconds since midnight day 1 year 1. 25 kerbin years would be 230088625 seconds, 25 earth years is 788400000 seconds, not counting leap days.

This reminds of the Alderson drive from Pournelle's CoDominium universe. That was also a jump drive, but it used a fifth fundamental force called the Alderson force. Basically, nuclear fusion affects Alderson force similar to how mass affects gravity, in that there is vector field in the universe, with points of high Alderson potential and low Alderson potential. The drive lets you jump from points of equal potential instantly, but the points themselves are very small, and if you're not in the right place you burn a bunch of energy and go nowhere. The points are only formed between 'adjacent' stars, and are usually (always, I think) very far from the star itself, well away from any planetary system. The irony is that you can travel tens of lightyears in literally no time, but it takes of days even using their multi-gee photon drives to get to any points of interest in the inner system or to the next jump point.

For initial capital dollar per dollar probably not, but if these guys find paying customers and can actually meet their five launches per day target, then the economies of scale should make it worth it.

The SAS feature isn't designed for flying aircraft, its designed stability control in cases where vehicle dynamics are much simpler. The only time I use SAS when flying is during takeoff when I don't want to deal with touchy wheel steering to keep my aircraft on the runway. Instead, I recommend using the trim feature (Alt + WASDQE). You can trim the control surfaces to reset to a non-zero position without any input, and this is a far more effective way to stabilize an aircraft. Keep in mind that airspeed and altitude will change the lift and drag characteristics of the aircraft, and you will need to adjust trim accordingly. For a center-line single propeller aircraft, trimming roll against the torque from the engine is what you want to do, but you'll have to re-trim frequently as airspeed increases and your controls become more effective, or if you change the torque output of the engine. If it feels like your controls aren't enough to counteract the engine torque, there's a simple solution and that is... This is very important when constructing propeller aircraft - the R121 can produce an incredible amount of torque - an incredible amount that you will never need to utilize for any propeller-driven aircraft. I find that 50 kNm is usually more than enough for the heaviest propeller setups, but YMMV - start low and if you can't max out the RPM increase the torque a bit. tl;dr SAS isn't for airplanes, if props are giving you a hard time use less engine torque (especially during takeoff and at low speed) and manually trim so you fly straight, or install something like MechJeb which I think has autopilot.

Even if they do get it working, you aren't going to be able to launch any old satellite on this. 10,000 gee is well beyond the acceleration rating for many sensitive electronics e.g. IMUs. The payloads are all going to have to be incredibly over-engineered just to withstand launch, which is going to cut into their stated cost reduction fraction quite a bit. Not to mention the fact that maybe we should consider the consequences of flinging thousands of satellites into a low orbit every year (I'm looking at you, starlink).

Supersonic, yes. Hypersonic, yes but it's harder. Supersonic is relatively easy, depending on the total mass of the craft, a few Panthers should provide enough thrust to break the sound barrier. I have a small Mk3 transport that weighs 60 tons, can carry 68 kerbals, powered by two Goliaths that tops out around 550 m/s (Mach 1.65 at sea level). If supersonic is your goal, the Panther is probably the best engine; avoid the Goliath and Wheesley as they're up the the task, but tend to overheat. Hypersonic is usually defined as mach number in excess of 5, and for that you definitely need to use the RAPIER. The Whiplash thrust curve peaks around Mach 4, but falls off quickly to 0 at M=5.5. The RAPIER fares better, with peak thrust around M=3.5, but with a gentle taper to 0 at M=6. So yes, the engines support hypersonic travel and it can be done. I have a small spaceplane that weighs 77 tons, crew capacity of 20 and a moderately-sized cargo bay, and is powered by 4 RAPIER in the tail and 2 Whiplash in outboard nacelles. It can reach a maximum Mach 5.5 at 15 km. I'm sure that you could do better by removing much of the rocket fuel and reducing the size of the crew compartment. tl;dr, supersonic is easy, hypersonic needs RAPIERs

I don't think that NASA would do it this way given the choice, but their priorities and timetable are being set by the white house, not by internal processes. Leads to some unfortunate results, like that price tag. Now that I think about it, cost-plus for a PDR does seem a little strange, but I'm not well versed in contract norms. I guess the incentive in that case is to work quickly?

I don't approve of sole-source contracting, but this explains why they did what they did. Thales doesn't own the IP for Cygnus, NG does, so they can't bid to produce a Cygnus derivative, they would have to start from their shuttle-based cargo module or from scratch. Definitely not. Cygnus has minimal life support capabilities and is designed for a short-term mission, most of which is spent docked to the ISS which has its own supporting systems. The gateway is going to be around for a long time, and is a lot further away from Earth than the ISS - the subsystems will have to be very robust in order to last for the duration of the DSG mission. Its not that its easy to convert Cygnus to a standalone habitation module, its that its easier to do that than to start from scratch, which is what the other bidders would be doing. Especially given that Thales already has production lines setup for Cygnus components.

That's par for the course for spacecraft development. Ok, 100 is probably a bit low. I'd say low hundreds probably, but that's not all going towards salary. Also, from the article: So they're shelling out for hardware procurement already. Nothing too fancy probably, but I'd bet that eats a fair bit of that 187 mil. Additionally, with that kind of contract if the actual costs run low, NASA pays less overall, but NG takes a greater proportion as overhead. It's likely that the total value was high-balled by NG in order to get a larger amount of incentive dollars - a safe bet for a PDR.

If these are scifi (read: high-tech) missiles, then they are almost guaranteed to have some sort of closed-loop guidance, and you are probably dead if your best defense is running away (or 'evasive maneuvers', as the pansies like to say). If you do have some sort of point-defense (railguns, cannon, lasers, other missiles, etc.), you stand a better chance of surviving, but then the ball is totally in your court as to whether or not you defeat the missiles - PD performance is almost as highly debated as the laser-missile superiority argument. At these kinds of speeds, the distance between the incoming missiles is probably very large, to the point where you need at least one PD missile per incoming, and probably three or more if you want to actually survive. Also, any astromilitary worth its salt is going to have multiple silos situated very far from each other, so best case you still need one missile per silo. You definitely don't need to match their acceleration, even a few gees should put enough distance between you and the missiles at the time of detonation. Making them slower means they're cheaper and lighter, which means you can carry more of them - a quality that PD systems should have, especially missile versus missile systems. In general, given approximately equal technology levels, planetary defense systems are going to clobber anything in LEO nine times out of ten, simply because the planet has more of everything than the spacecraft does. More electrical power, more space to put things, more weapons installations, more computing resources, more targeting radars, etc. etc. Your best bet is just to stay the hell away.

You think that's too high? Keep in mind, this is for the entire PDR, that includes PDR for all of the subsystems and sub-sub systems. There might be a hundred engineers working this at any given time, including however many levels of subcontracting overhead (plus NG's corporate overhead). I think this is quite the fair price. And lets be real, that's not even that much money.

Suggestion: Add a PAW item to disable non-deployable antennas. I have a station in LKO with a DTS-M1 and a bunch of service vehicles using the 16-S docked to it, and my data rate is pathetic because I can't turn off the 16-Ss. Not sure if this applies to the antennas in probe cores, but I wouldn't think so because they can't transmit science. Alternatively, don't use multiple antennas if one is enough to do the job (start with the highest power one, if that can't get through add the next strongest one, etc.) but that seems overly complicated.

I can't speak as to the nature of the 'conference call', but in the case of e.g. a spacecraft around Mars relaying for a lander, you would probably have two different antennas on two different bands. The long-range antenna will likely use a high frequency with a moderate-to-large diameter in order to get a high enough transmission power to communicate with DSN. When using this antenna, the vehicle will have to orient the dish towards the earth, which heavily constrains the attitude of the vehicle. For the rover antenna, you would use a much less powerful antenna with a more symmetric radiation pattern, allowing the orbiter to communicate with the lander regardless of the vehicle's attitude. I would think that uplink data would be timed to arrive at a time when the orbiter and lander have line-of-sight, but it wouldn't surprise me if the orbiter has on-board memory capable of storing a few commands to relay later. I would almost certainly expect that the orbiter would have memory designated for stashing telemetry data from the lander. Interestingly enough, Curiosity has a high-gain antenna that it uses for direct-to/from-earth communications, but also has a low-gain antenna for relaying data via Odyssey or MRO. The link below is worth a read, and talks about curiosity, MRO, Odyssey, and the various communication technologies they use. https://sandilands.info/sgordon/communications-with-mars-curiosity Edit: from the above source, a direct answer to your question:

The biggest thing that I have picked up from reading sci-fi is that, it doesn't really matter so much if something is 'possible', what matters is how the author justifies it. Justification can range from the hairy and explicit (e.g. that bit in The Martian where the author discusses the nature of the failure of the first Iris launch) to totally implicit (relying on the reader's comprehension of the word the author has created) - as usual, the best works lie somewhere between the two extremes. Often times, the technical details aren't particularly relevant, after-all this is science fiction, and that gives the author quite a bit of leeway as to how they craft the world the story takes places in. What does matter is internal consistency. This is where the true art of the trade is shown; by crafting a believable setting, telling a story, not breaking any important laws of physics[1], and having the reader come out the other side smiling. That is the real mark of a successful work of science fiction, not whether some scenario is physically possible. As the author, you should try to decide what the outcome is ahead of time to meet the needs of the narrative, then craft the world to result in that scenario, not the other way around. I don't mean bore the reader with technical details about the ship and the missiles (although bridge-crew dialog is a great way to drop hard numbers into a story without force-feeding them through narration), but I think if you go at this from the other side you'll have a more fruitful experience. So back to the original question: Pretty much any combination of ship acceleration and missile performance can result in anything from the total vaporization of the ship to the UN shaking its fist as you zoom off to your next destination unscathed. In this case, you should pick what you want to happen first, and craft the performance of the ship and missiles to result in that scenario. I'm assuming you want the ship to escape in this scenario, and also that the ship is going to be a somewhat important part of the story going forward. Start with the class of the ship. Is is a military grade cutter, capable of pulling 8 gees but can't go past the moon? Is it a dilapidated cargo freighter from the last century, barely able to pull two unladen? Once you know the performance of the ship, choose the performance of the missile. If you want them to get away easily, a few dozen dumbfires at 500 gee might make for a good hair-raiser. If you need some battle damage, proximity warheads (high-explosive frag or nukes) could batter the hull a bit, or perhaps result in a propellant leak. If you need a mission kill, a lucky hit to the engine or reactor might force an emergency shutdown. Any or all of these are valid scenarios given different combinations of ship and missile performance, but if you make that 70 year old cargo ship dodge a barrage of state-of-the-art ASAT missiles, you better tell me how that happened. As a reader, thats the kind of thing that will bother me - I could care less about the exact acceleration and guidance capabilities of the missile and the ship, as long as the outcome is believable. Maybe the pilot is Rain-Man. Maybe the ship has an experimental AI-controlled EW suite that confused the missiles' guidance. Maybe you jettison your cargo to act as a decoy. Maybe the astromilitary's missiles are designed for low-maneuverability targets. Any of these are good answers, but it is up to you to pick one that makes sense within the bounds of your setting. [1] FTL is ok sometimes, but if you're working strictly inside the solar system I would recommend against. Trying to deal with breaking causality can be a real nightmare if you aren't read up on your special relativity. Above all, avoid breaking conservation of momentum (i.e. reactionless drives) - or be prepared to deal with a world where every spacecraft is potentially a life-exterminating WMD.

That would be a plumbing nightmare. Not to mention the engineering challenges associated with developing a cryogenic gasket to keep the propellants from leaking back into the empty space as the tanks drained. Instead of a plate, you would use a blowdown bag, think a plastic bag inside of a thermos. As the propellant drains from the plastic bag, inert gas is pumped into the space between the bag and the thermos walls, keeping the edges of the bag taut. But, as has been said before, all these schemes add weight, and *say it with me folks* every gram counts. It simply isn't worth the weight, because given enough man-hours of engineering effort, a computer can be taught to fly pretty much anything, stable or not.

For equatorial launches, timing isn't important, except for reducing travel times. Phasing is pretty cheap if you're willing to wait for it, so I usually try to get close but err on the side of behind. For LKO intercepts like saving kerbals in <80km orbits, you probably have to go high to phase anyway, so timing is less important. For inclined intercepts, timing is incredibly important. Plane changes are hands down the most expensive maneuver, so if you can inject close to (preferably directly into) the target's orbital plane, you can save a ton of propellant.

The reason you need tensile strength is to overcome tensile forces. Whether those forces are because of gravity or due to pressure across a membrane doesn't matter. This is why, in the thought experiment, the plastic can survive as long as the area is small - the total amount of force is small. When the area increases, even though the pressure is the same, the forces increase. At some point, the plastic will fail - not because of the pressure, but because the total force on the plastic is too great. The experiment may have been a little misleading, because I emphasized the weight of the water - the critical piece isn't the weight necessarily, it's the pressure * area on the plastic that causes the failure. It doesn't matter that the pressure is caused by the weight of the fluid. In space, there's no weight, but there is fluid pressure. Fundamentally, it's the same problem, just with different geometry. The 2d plastic across the bottom of plexi column becomes the surface of a sphere, and the pressure gradient is from the vacuum of space (0 atm) to the internal pressure of the tank (1 atm, or whatever) instead of from the weight of the water. Yes, I would too. Plastic is good for containing things when the pressure gradient is low. But in space, the pressure gradient is not low, so you need a stronger material. Here's where the confusion lies. Materials don't withstand fluid pressure, they withstand stresses. Structures withstand fluid pressure, by determining how the pressure is translated to stress, and where the concentrations of stress are. The '6mil plastic at 20-60psi' figure is confusing - fundamentally it doesn't make sense because of the above. It could be that you are quoting the tensile strength of the plastic, but 140 kPa is a pathetic strength. Frankly, the cryostorage solution is a pretty good tank-fluid mass ratio - as long as your polymer can withstand cryotemperatures without being structurally compromised and you have a practical way to deal with debris strikes, it's not a bad solution for moderate amounts of propellant. A 2 cm thick bag 4 m in radius is certainly plausible.