Starman4308

A lot of your points here run straight into the fact that Squad has a different vision for the game than you do. For example, at least Harvester disliked the idea of delta-V readouts (and presumably autopilots), because he preferred a more seat-of-the-pants, trial-and-error sort of gameplay. On the Mk1-2 pod, I don't think they'll change the diagonal, since so many legacy craft have been built around that oddity. On graphics "without raising the minimum game requirements"... what do you take Squad for, an AAA studio? You cannot wave a magic wand to improve performance; you have to invest a lot of coder-hours finding little tweaks to make, and you get strongly diminishing returns on investment there as you approach the point where you're perfectly utilizing the graphics chip, without a single wasted cycle. EDIT: To perhaps further elaborate on where we're coming from: Squad has already put an enormous amount of effort into KSP. Most video games these days are mostly art jobs, with a little bit of coding and scripting. Squad, meanwhile, has had to put into code orbital mechanics, atmospheric effects, thermal effects, and countless other complicated features that are far from commonplace in video games. The sort of art passes you're suggesting are major investments, and Squad may not even have the talent to get those working; a coder might have had no prior experience making 3D models or textures, but that's what they had to deal with.

To be perfectly fair to Squad, while those are still unpolished, there's a lot more that has been polished. While there may be a bunch of indie games with shinier graphics and more carefully polished gameplay, many probably fit into established genres which are relatively simple coding jobs; KSP was anything but a simple coding job, and probably constitutes hundreds of thousands of lines of code on top of the Unity engine. We have semi-realistic atmosphere, heating/cooling, ISRU, communications, improved orbit stability, etc. While the poor part balance does somewhat bug me, that would probably require a pass over not just the parts, but also the contract and reward system.

I'm not sure what answer you expected posting this question to a forum full of KSP fans. Personally, it's been worth every penny, but I have a personality and interests well in line with this game. I can see why some wouldn't like it that much, and why it might seem on the tin to be a low budget indie game (which it kinda is), and there are some for whom $40 would be a lot, but for me personally, I'm with the bandwagon.

If you have an aerodynamically stable rocket and are very careful and consistent making your initial launch, yes. In practice, most players are going to get that approximately right, but still keep their hands on the controls in case they turned too early or too late and want to pitch up/down a bit.

It's a feature, not a bug for me. Zooming out let's me hear background music instead of a deafening roar.

I think technically the best way to minimize finite burn time effects is to split the delta-V down the middle; while splitting burn time is usually a good approximation of that, it becomes more noticeable for very large maneuvers and if you stage to something with a different TWR. Otherwise, short of using a mod or kOS script that handles finite burn times, you'll never be exactly accurate, potentially requiring a correction burn.

The mighty Kraken struck. The end.

I tried. It's not going to be easy, in large part due to the LV-N being heavily vacuum-optimized. I suspect that if somebody manages it, it's going to involve a lot of LV-Ns and some wing parts parachuting down to Kerbin's surface... possibly even before the plane leaves the runway.

One of the most important equations involved: vsoi = vsoi The velocity you have entering the SOI of the body you're using for the slingshot is the velocity you have coming out... just in a different direction. The amount of velocity you gain or lose with respect to the parent body, thus, is a function of how fast the assisting body is orbiting and the angle between your entry and exit vectors. I don't know the math for this, unfortunately, other than a quick theoretical maximum for the case of a perfect U-turn to accelerate yourself, in which case your exit velocity is 2*vbody-vorig. When it comes to calculating orbital velocities, the most useful equation I've seen is the vis-viva equation: v2 = u*((2/r) - (1/a)), where u is the parent body's standard gravitational parameter, r is your current radius above the center of the parent body*, and a is the semi-major axis. *Do remember that while KSP reports apoapsis and periapsis above the surface, vis-viva works on apoapsis and periapsis relative to the center of the body,

The only things I can think of are: Lots of background processes taking up CPU time. Put the laptop on top of a laptop cooling pad to help remove heat. If it's not a new laptop, consider dusting it out. Graphics driver issue. 20 parts should be quite easy for any relatively recent CPU to handle, and even max KSP graphics are generally pretty easy, so it's unlikely to be a performance issue.

Short version: Minmus injection burns do not actually require 930 m/sec of delta-V. Those dV maps are more for planning out how to build your ship, and so include a small overestimate for safety. If it takes that much to capture, that's a clear indicator that you're going into Minmus's SOI with excessive velocity. Dial back your Minmus injection burn until you have the bare minimum of delta-V expended, and attempt to capture when traveling approximately parallel with Minmus.

While it's probably not worthwhile to set up a Dres -> Jool slingshot, there are two common slingshots that are used to get there. 1) As Aegolius described, use Tylo to brake yourself into Jool orbit. While your initial orbit afterwards will be highly elliptical, you can then set up further gravity assists to brake yourself down into a more circular orbit. If you want to practice this first, you might try using Ike to gravity brake into Duna orbit. 2) Inner-planet slingshots. Using a KEKKJ (Kerbin Eve Kerbin Kerbin Jool) window, you can get out to Jool for around 1100 m/sec, little more than the initial transfer to Eve. The simplest path that gives significant dV savings would be the KKJ path, costing around 1550 m/sec. To execute a KKJ path: your initial ejection from Kerbin should have an orbital period of 2 Kerbin years, resulting in an apoapsis around 2.17x Kerbin's orbital radius. This means that, when your probe returns to periapsis 2 Kerbin years after the initial ejection, Kerbin is exactly where it needs to be to get a slingshot. It's not quite as efficient as something like a KEKKJ path, but has the advantage of being much simpler to set up.

I forget which mod pack adds it, but there's a trimodal LV-N kicking around somewhere that has improved thrust at the cost of specific impulse. My absolute favorite (keeping in mind that I play with Real Fuels-Stockalike) is the 0.625m "Sparkler" engine from Modular Rocket Systems. It fits beautifully in between the Ant and Terrier, offering a reasonably efficient engine powerful enough for a surprising number of my designs, either in singletons or in small clusters. If I had to pick something from stock, I'd go with the Kickback SRB, which has an excellent aesthetic, and burns for about the length of time I actually want SRBs to burn.

4 satellites will still permit gaps in coverage; while the probability of a gap in coverage is reduced, you're still going to get effectively random misalignment over time if you don't either use station-keeping burns or orbit editing. There is also still incentive to put a communication network around Kerbin; if you want to communicate with stuff on the surface of Kerbin or in very low orbit, you still want an orbital constellation to rebroadcast signal back to the surface. I've had a mission fail in the past because I neglected to consider that the probe was going out of LoS of the KSC station and the next ground station wouldn't appear until after I'd reentered atmosphere.

No, I don't think I will trawl through years worth of mission reports when, if your conjecture is true, you should be able to just point us at a case of this occurring. If your evidence is that your network fell out of alignment? If you placed them there in normal gameplay, of course it'll fall out of alignment, because there's no way to, short of editing, ensure your satellites all have exactly the same semi-major axis, and thus exactly the same orbital period. Show us a case of a satellite, that stayed on-rails throughout, that was not subject to any sort of orbital decay or persistent thrust mod, that did not cross any spheres of influence, that changed its orbit. Two possibilities: First, a lot of these values do become poorly defined or degenerate when inclination is exactly zero. Second, when you switched away from the vessel: were you in on-rails warp, or in normal physics flight? Regular, non-timewarp physics does exhibit orbital perturbations thanks to the limits of numerical precision.

There's a key flaw in your logic here. A vessel in orbit around, say, Tylo, does not move with respect to a global coordinate frame. It moves with respect to Tylo. In that reference frame, there is an easy mathematical expression to say exactly where the vessel should be at any given time relative to Tylo. The game first updates the clock. The game then updates Jool's position relative to the Sun. This calculation is independent of where Jool was the tick before, it only depends on Jool's orbital parameters and the game clock. The game updates Tylo's position relative to Jool. You can then calculate where Tylo is with respect to the Sun by adding Tylo's Jool-relative position to Jool's Sun-relative position. The game updates your satellite's position relative to Tylo. If the game notices that your vessel's path crossed through Tylo, it explodes; if the game notices your vessel's path takes it out of Tylo's sphere of influence, it moves your vessel into Jool's sphere of influence and calculates a new orbit. If neither of these occurred, however, your Tylo-relative orbital parameters do not change. Again, the game is not calculating the force of gravity for on-rails vessels. It is using nice, simple formulas to calculate where the ship should be given the parameters of its orbit and the game clock, and adjusting those orbital parameters only if you have an SOI transition or surface impact. Under the Keplerian 2-body approximation, these nice easy formulas mean you never have to calculate the force of gravity, and the only sources of error are: 1: When going from off-rails to on-rails, there is some imprecision in converting your current position and velocity to orbital parameters. 2: There may be some minor issues when passing between spheres of influence, and I'm not 100% sure what the math is for that transition. 3: A very, very minute amount of positional error based on the fact that you still get your output coordinates as floating-point numbers; this error is effectively random and has no impact on future timesteps. EDIT: The issues you are describing would be true for an iterative orbital-mechanics integration scheme, such as would be used for N-body gravitation. Key to KSP, however, is that Keplerian orbital mechanics are very simple and provide easy analytical formulas for position with respect to the parent body over time, and that by defining clear spheres of influence, you can say exactly when a ship crosses over between spheres of influence and the orbit has to be recalculated with respect to the new parent body.

Could you kindly cite me these observations of orbits changing? Ensure the following: The vessels did not change spheres of influence or collide with a body. At no point did they exit on-rails physics, either by directly switching to that vessel, or moving an off-rails vessel close to them until they entered the iterative physics bubble. If it refers to an alignment of vessels, such as a keostationary communication network, those vessels were placed by Hyperedit or similar so they had exactly the same semi-major axis, and not just approximately the same semi-major axis. I will point out that nothing I've said contradicts "it is virtually impossible to set up a perfect keostationary network in KSP without mods or save file editing". There's simply too much imprecision in the off-rails, iterative physics calculations to get exactly the orbit you wanted, no matter how careful of a pilot you are.

There's something beautiful about the Keplerian 2-body approximation when you ignore collisions and SOI transitions: You don't need to calculate forces, velocities, positions, or anything like that timestep after timestep. You don't need to integrate any laws of motion, because there's a closed-form solution to position given time. You just take your 6 stored orbital elements, the current clock, plug it into an equation, and get out your new position. That's largely what KSP does: it checks each vessel to see if there's an impact or SOI transition it has to handle, else it simply just updates the clock, and moves the vessel to the new position blissfully ignorant of where it was before. Again, I tested this. I set up a constellation of satellites using Hyperedit, warped time forwards a few years at max timewarp, and they were still perfectly aligned. If using some sort of iterative physics solver, solar systems will tear themselves apart given time. Even under Keplerian 2-body physics, unless you have an integration scheme that conserves all the relevant quantities, it'll tear itself apart due to these floating-point issues. Under N-body physics, not only is an iterative physics solver necessary*, it's a chaotic system; the solar system will fall apart, with some bodies colliding with the central body, and other bodies ejected off to infinity. *Technically there's a non-iterative way to do it, but it's an infinite sequence of terms that, even when truncated, is very impractical as more than a demonstration. While setting a large timestep makes inaccuracies manifest themselves sooner, an N-body system such as the real-world solar system is literally fated to fall apart. Major changes have already happened; it's thought that Uranus and Neptune switched places long ago in the early Solar System, and we quite possibly had another body ejected from the system entirely. Even if you had infinite precision and an infinitely short timestep (no numerical issues at all), N-body physics is inherently chaotic.

Another way to think about what Corona and I have been saying: Position during iterative physics is a function of where you were before. Keeping things simple and ignoring acceleration: x(t0+dT) = x(t0) + v*dT Thus, x(t0+dT) is a function of x(t0), and the error in x(t0+dT) is a function of the error in x(t0). Given floating-point errors, you have issues because of an imprecise x(t0), imprecise v, and potentially even imprecise dT if you choose a strange timestep. What's worse is when you consider future timesteps. x(t0+2*dT) = (x(t0) + v*dT) + v*dT x(t0+3*dT) = ((x(t0) + v*dT) + v*dT) + v*dT You get compounding sources of error taking your ship farther and farther from where it should truly be. So, the error in x(t+3t) is a function of the error in three prior timesteps. Position during on-rails orbits is not a function of where you were before. x(t) = f(SMA, eccentricity, inclination, argument of periapsis, longitude of the ascending node, mean anomaly at epoch, t) You can calculate this for any time t, without ever needing to know x(t0). While you have seven sources of uncertainty (6 orbital elements and time), six of them are consistent for any given time t. So, if you Hyperedit vessels into a perfect constellation (same plane, same SMA), they will remain in that constellation forever, plus or minus a few meters' wobble around the true position. Without Hyperedit or similar, you're never going to get quite exactly perfect without extreme luck; even if you're utterly precise with your burns, there is some uncertainty when going from iterative physics to the 6 orbital elements; the game isn't completely precise storing your velocity and position when in iterative physics, so it won't be completely precise converting that to an orbit. Once you're on-rails, though, there are only five things that can possibly change your orbit: 1: Switching back to the vessel, thus switching back to iterative physics. 2: Transitioning to a new sphere of influence. 3: Impact with a planet. 4: Deleting the vessel in the tracking station. 5: Editing the orbit using Hyperedit, save file editing, or similar.

Not strictly correct. Onion/asparagus stages not only remove empty fuel tank mass, they also remove unnecessary engines. Especially for something like Eve: you're going to start off needing far more thrust than you need at the end. If you put all your engine mass on the central stage, by the end of your staging, you have a lot of thoroughly unnecessary engine mass on a ridiculously overpowered core stage; if you spread out the engines and drop them every so often, you can keep your vessel more trim and avoid losing delta-V to having more engine than you actually need. Also, one note for the OP since I haven't seen it mentioned yet: these sorts of staging setups (onion, asparagus, droptank) etc are generally considered a bit unrealistic because of the mass and mechanical complexity that would be required to pump fuel very, very rapidly from the radial tanks to the core stage. That's why real-world rockets tend to stick towards simpler staging setups.

Right: I'm not arguing that. Except maybe the "cheating" thing; I'd hardly call it cheating to use Hyperedit to move an almost-perfect constellation with a synodic period measured in decades to a perfect constellation. Your original post, however: What I had an issue with was the assertion that you get compounding floating-point errors* for on-rails vessels any time you do anything. The only sources of floating-point error relevant to maintaining a keosynchronous communications network come from using on-physics flight to set up the network in the first place. Once you stop flying the communications satellites, loading, saving, reloading the game, switching to other ships, etc, has no effect on your constellation. *Technically, there's a small error in calculating its position each timestep; it's just an independent, random error that doesn't affect its calculated position in the next timestep.

To the best of my knowledge, no floating point rounding errors occur for on-rails vessels beyond what occurred when they last went on-rails. I'm testing things right now (just got 3 vessels Hyperedited to have the same SMA, now timewarping), but my understanding is that, for an on-rails vessel, its current position is calculated from 6 stored orbital parameters and the current game clock. The only reason those stored orbital parameters would change is if the vessel encountered a new SOI, or impacted a celestial body. If you have a stable orbit in KSP, it remains in that stable orbit forever; with the Keplerian 2-body approximation, there are closed-form solutions for position given 6 orbital parameters and a time. So, if you have 3 vessels in orbits with identical semi-major axes, plus or minus a bit of wobbling if they're not perfectly circular, they will stay in phase forever. The trouble is that, sans Hyperedit and similar, you're never going to get absolutely identical SMAs, because you do get floating-point errors in position when in physics, and unless you have absurd luck, you're not going to click "return to space center" exactly when you have the correct SMA. In the real world, constellations like that do go out of phase for a million reasons. However, real-world satellites have paid control crews who do maintenance burns every so often to keep satellites where the're supposed to be; there's no such luck in KSP, where the control crew is one dude who may or may not have a good understanding of orbital mechanics. EDIT: Ran the clock forward almost seven years. First, the testing is a success: while the satellite I jumped back to developed a minute error because of a moment of off-rails physics, the error is consistent when I look at either of the two untouched satellites. MechJeb is reporting the synodic period to both of the others to be exactly equal: 67014 years, 189 days, 16 hours, 38 minutes, and 11 seconds (Earth time). When I use MechJeb to reposition the satellite back into a perfect orbit, that synodic period is reported as infinity. To clarify why this can occur: for on-rails vessels in a stable orbit, KSP does not calculate position at timestep n based on its position in timestep n-1. It calculates position based on 6 orbital parameters and the current game clock. The only reason you need Hyperedit or save-file editing to ensure absolutely perfect stationkeeping is because it's generally impossible to get exactly the correct SMA while in physics; micro-jitter induced by floating-point errors ensures you have to be incredibly lucky to get that. In real life, as stated above, there's all sorts of things causing errors in your trajectory (solar wind, etc), and they just use small stationkeeping burns every so often, something most KSP players don't have the patience for; thus, why I'll often get an almost exact communication constellation, and then Hyperedit them into a perfect constellation.

As I understand, electricity is abstracted in the following ways: First, batteries can charge and decharge arbitrarily fast, when real-world batteries don't do that. Power is not an issue, just energy. Second, voltage is completely abstracted away. Between the first two points, batteries are magic energy storage and delivery devices. Third, real-world equipment decays with time, whereas KSP batteries fail primarily when you misjudge your Mun landing. Fourth, KSP batteries appear to have very poor energy/mass density. I run with 1 EC being approximately 1 kJ of energy. KSP batteries thus store 20 kJ/kg, embarassing next to the 360-950 kJ/kg energy density of lithium-ion batteries. Even the RO assumption of 1 EC = 1 kWh brings KSP batteries to a whopping 72 kJ/kg. So, the question is: which of these abstractions are sound for gameplay? On the first: I could see this becoming a togglable difficulty option. It'd break legacy craft if always turned on, but I could see a max charge/decharge speed, though it'd take a bit of fiddling, since right now stock resources are consumed from storage as fast as the consumers need them. On the second: I agree with this abstraction. Not all that many players are going to want to play Electrical Engineering: The Game. On the third: this can be lumped in with "part failures in general", to which I'd say "if Squad had infinite code monkeys, sure, but I'm fine leaving this to the modders". On the fourth: it's mostly an internal game balance issue that mostly becomes a question when you start to do large-scale modding, and I can't exactly comment on the balance of the stock game when I haven't played the stock game seriously in years.

Nope. The primary issue is that real-world equipment is generally lighter than KSP equipment, and, much more importantly, the real Moon is much, much bigger than the Mun. Low Mun orbit is at about 540 m/sec. If I did the math right, low real-world Moon orbit is around 1670 m/sec. The advantages of an LOR (Lunar Orbit Rendezvous) over direct ascent: You get to leave all the return-home propellant and other consumables (fuel, CO2 scrubbers, etc) in orbit, and not have to drag it down and back up the moon's gravity well. You get to leave the heatshield (and a generally structurally stronger capsule) in orbit. Some redundancy: see Apollo 13. The disadvantages Duplicated life support, communication, and other equipment from needing a separate lunar lander. In some cases, duplicated engines. Docking equipment is necessary (unless you're the Soviets). More complicated to pull off. KSP exaggerates the disadvantages and ameliorates the advantages of an LOR profile: engines are heavy, command pods are heavy, decouplers are heavy and absurdly expensive, and the delta-V requirement is low. There's basically no point to an LOR profile for the Mun when you can land and ascend on less delta-V than it takes just to land on the real-world Moon, particularly when the mass of duplicated equipment is exaggerated.

There's also a legacy reason: Most of Unity works in single-precision floating-point, which is fine for most games; not so much for a game like KSP which has an entire solar system to model. Originally, part of the 1:10 modeling was to reduce the size of Kerbin so the floating-point rounding errors had less effect on the game. If you used the center of Kerbin as the origin, single-precision has an uncertainty of +/- 1.8 cm in your position; at full scale, that would be +/- 18 cm. While KSP still runs primarily on single-precision, the rounding errors are largely dealt with via the Krakensbane update; the origin of the game's coordinate system is no longer the center of Kerbin, but starts centered on your vessel, and if you move far enough away from the origin, KSP pauses, and moves everything else in the game with respect to you. I still wish there was a full double-precision mode.