John JACK

MM is not a mod by itself, it does not change a game even slightest, it's just a tool for installing mods. No MM means no most other mods, so you are implying that you need ALL of them, or maybe just some you don't want to specify. Most necessary mod for me is GoodSpeed Fuel Pump. Building, navigating or docking big enough ships in stock game is not easy, but kinda fun. Manually managing all the fuel in all tanks, LF and OX separately, is a nightmare without any redeeming challenge, simply waste of time. Also I would be sad without HGR parts pack. 1.875 m size fills a gap between small 1.25 and big 2.5 nicely, Soy modules look both stock-alike and distinct from boring old pods and cans.

Yay, tables of physical dangers! With such wealth of knowledge surely nothing could go wrong for 49.5 kerbals remaining in S.A.V.E.!

Breathing recycled air and eating stale snacks is long known and proven not to affect kerbal health any more than just process of being kerbal. But breathing alien air and contact with totally alien biosphere may have unpredictable consequences. Tylo's gravity is just slightly less that Kerbin's, no problems must be here. Landing cost more fuel due to no aerobraking, but is safer for exactly same reason, especially with Jebs. And taking off is easier — you less dV than on Laythe, and can use effective vacuum engines all the way. Laythe is tempting, but great dangers may be waiting there. Tylo is boring as in "boring for ore every day till the end of universe", but safe. Mostly.

I wonder how does KSS [Redacted] look without hangar bays attached. Vital parts are tightly packed at aft end, and most fore half is just empty space, right?

Yep, and they did not do simulations to fly an airliner without working engines. Until someone mistook kilos for pounds and a passenger plane just ran out of gas. Spaceflight is less about profit and cutting costs, and more about scientific curiosity and military preparedness to anything at all, including sudden green aliens in saucers. Reentry is even not scientifically or logically impossible, so it must be studied.

Crayon badS Eve Tedus is the best Tedus. And also Jeb.

Troll is not an insult, it just shows that that guy 1. did something strange on purpose, 2. gets something even stranger in return and 3. complains about it. Statement about maximum design performance and inaccuracies still applies here. For a very large booster a Flea do not affect dV much either way. Also if Flea is in a same stage with decoupler (as it should be), it must be just ignored in calculations. Before decouple it's a dead mass, after decouple it's away and do not affect remaining rocket. I just use several common sepratrons, and don't care about their weight, or dV difference for entire stack. They are enough to push spent upper stage for ~50 m/s, but spent stages are light and full rockets are not, and dV for going to space is approximate anyway. Sepratrons of any kind are a common case to remember when writing calculator, and a part of stock game, not some weird exception.

If an only station is going down, astronauts will have no things to do at all. Spending several days installing cameras is better than spending several days more retired groundside without even cool videos to watch at old age. And yes that should be not only cameras but any others sensors and means of telemetry. Deorbiting such big object will produce unique experimental data, and even computer modelling is impossible without knowledge how exactly things behave in reality. Was it really from old age and neglect? Accidents and catastrophes in space happen mostly with new hardware. Stuff that worked once and again is statistically more reliable. Mir was scrapped by a political/economical decision, not because of old age or even frequent failures. There were projects to conservate it, but to no avail. Look at planes. Airframes commonly fly for several decades. Some bombers serving in Middle East are older than their pilots parents. Electronics and machinery are not that old, but it can be repaired, refurbished, replaced or upgraded. More literally a family member. Just some guy known as "Grandpa Lenin"

Does dV make any sense for spaceplanes at all? In space(!) there is no drag or lift so spend dV add directly to your current velocity vector. In atmosphere at some point all engine impulse goes to offset drag and velocity remains constant. Or you can change velocity vector without spending dV at all. I think, it will by right either give unreachable but mathematically correct value, like KER, or replace dV for atmo engines with just maximum burn time and let players trial-and-error™ their planes themselves. If the guy can calculate dV of asparagus with boosters manually — and puts a booster upside down just to complain about wrong readings, that guy is a troll. Best way to treat trolls and excessely kerbal rockets is to just ignore them. Trial-and-error again — if your rocket does not fly straight, you do not need a dV value for it. dV readout must not account for flight plans, manual control or just poor piloting. It's a convenient tool to save rocket builder many minutes of slide rule shuffling and back of the envelope scribbling, not less, not more. It shows maximum design performance in ideal conditions. You surely can get less dV from a design, but you never will get more. Understanding dV calculation limitations and inaccuracies is a challenge by itself — in a late game for experienced players. But to newbies it will be indispensable tool to tell if they will actually go to space today without minutes of errors and ragequit to library for studying rocket science demand a refund. Coding dV calculator may be hard, but a dV readout will may game easier where it need to be easier and more fun and a even better game. The simple way was suggested as a, surprise, simple way. If a simple way is not enough for a production game — that's okay. Right way is better than simple way and doing anything possible right is a right way by itself. But one cannot help but wonder, how many lines of code could be written instead of lines again and again telling how exactly hard it must be. Coding dV readout for KSP is harder than curing cancer, going to Moon, or coding a KSP. That's the best! We know that you can do it and we hope that you will do it. Just little whine to remind that we are waiting. Also a whine sometimes gets really cool answers like resource flow reworking plans or maybe even provides some unheard of suggestions.

Actually it is. NASA shows pretty much most of the interesting things going on. It may not be a direct PR of NASA, but it surely is a propaganda of science. And more public attention to science means more money to spaceflight. No one insists that NASA should launch missions just for fun (although space tourists), but salvaging great and unique footage is not that costly and gives more profit than not salvaging anything. Watching SPACE STATION BURN!!! up close worth incomparably more than blurry video of some fireball. And retrieving footage is not impossible, there are different sample return capsules, that can be rigged to separate after reentry. Shelf life is some arbitrary point when manufacturer does not want to give any guaranties, not when stuff stops working forever. Hundred years old canned goods are edible, fifty years old planes fly, thirty years old cars are sometimes better than new. Malfunctioned space station could be brought online again, conservated station surely would be. Solar panels of Zarya module are folded right now. Don't sure about main panels, but anything that was made surely can be broken. And there at least one "family member" who is kept as a museum piece. Even producing some science by the way I insist not that ISS must stay in orbit by any means possible. But it really should stay in orbit all the time it is useable, and at least until someone launch new stations. Even then it may be refurbished and rearranged to use some parts even longer. But conservation is an option too, not impossible one.

Wasn't it? PR was the main reason to send people (and stuff in general) to space since always. That's the best show of "we CAN do it (and you do not)(so give us moneys)". First Sputnik was just dummy payload for new ICBM that had problems with reentry — hey, satellites do not need to reentry, let's just launch a satellite to show superiors some progress! Public effect of Sputnik was unpredicted, and next Sputniks were cobbled together in much hurry, mostly to keep a show running. USA spend even more money just to get human to the Moon and bring back some rocks, without much hope for profit or even science — mostly to show that we have that money and you do not. Turned off space stations actually are not dead, they can be revived and used again. Salyut-7 suffered an unplanned power failure and was offline for several months, than rendezvoused, docked, fixed, heated, and working again. With planned conservation stations can be mothballed at least for several years, at high enought orbit. Big composite stations like Mir and ISS may have more problems with structural integrity, but spaceworthiness and internal components should survive and remain serviceable. And "sails" are stowable to reduce drag and degradation — several big solar panels on ISS already are permanently folded to allow for docking new modules. Reentry, when it comes to it, absolutely must be controlled. Even of mentioned Salyut some pretty heavy parts reached surface intact. Luckyly, there are not many houses near Pacific parking orbit. And reentry camera footage must be not too expensive and very cool. Expensive space station is falling out of space and burning up anyway, why not film it? People just love watch expensive explosions.

Because shuttles and planes with "ship" reentry capsule look real dumb and tend to mix up with real capsules. Landed on Kerbin, on LKO, or even at atmospheric planets there may be both single use capsules and reflyable planes, even SSTOs. The game has separate SPH and airstrip, why not the separate icon? There is no need to clutter UI with separate icons for subsonic planes and for spaceplanes, but some icon for winged craft is required.

Right, that asparagus is slightly more complex. But you can still count fuel flows from all tanks, divide it by fuel consumptions of relevant engines, and get a time to first checkpoint, when some tank goes dry, and that gives a "craft dry mass" for that step and "craft wet mass" for next. I suppose, fuel flow in ducts is fixed, and one engine will drain fuel from two ducted tanks symmetrically. There is fuel flow logic, it works in game, and developers surely can apply it to calculations. There is a finite number of parts, so no infinite possibilities here. Just some common cases, some uncommon cases, and other cases that better should be left unmentioned. No need for AI here, just a flowchart to handle possible cases. As far as I know, that's everyday work for programmers, not something esoterical. Your argument is invalid. Living body is [adjective] complex up to atomic level, very poorly documented and somewhere even unobservable at all. It's not infinite, but close to it. A game is at contrary a finite, legible, structured (or I hope so) code that you can just take and read. Even not too huge, compared to operating systems, graphics processors and whatever, and without decades of legacy. Getting some numbers from that code and processing them is possible even for outside addons, and is surely possible and easier for authors. ONLY problem here is not to actually plan and write a code, but to pretty please convince Squad to find some time to do it. And telling that coding a dV readout is impossible is just illogical. It is already done even not once. If you fear that stock dV readout will somehow spoil your fun challenge, surely there will be an option or a mod to hide it.

There is a digital heading display just under a navnall. 90 means east.

But a new player is not told that they need exactly 3400 dV to make orbit. That value or dV map is not stock, and should never be stock. But even new player should be able to figure that (for example) 3000 m/s of vacuum dV get rocket to edge of atmosphere, 3500 suborbital, 4000 is orbit with good piloting and 4500 allow for most errors. Nope. It's supposed to be fun. Good game is easy for beginners and progressively more harder to offer challenges for seasoned players. And any game should not take a lot of math just to make simplest things work. Math and studying theory should help make late game — not possible at all, but more efficient. It's arcade vs simulation holywar all again, and you tell that a cartoonish game without n-body physics should be harder that real life. That was not pseudo code, that was a general description of what draft for a simpified base for a pseudo flowchart for that code should be like. I'm not a programmer, I do not work for Squad or even do not code for money or for fun. Thought I do understand logic and sequences. And I do have a slide rule. As for your lifter, it's not complicated at all. Fuel ducts just pump fuel in direction of arrow at very high speed, until one tank if empty or other is full. At first fuel only from 95% skippers will be used for all engines. First 2x20 t used — check mass, praise Tsiolkovski, drop stage. Second fuel from 80% skippers tanks goes to three remaining engines. At last, you have just single stage of Mainsail with full tank. You have dV values for all stages, just add them for total amount. Right, late or early staging will lower real effective amount of dV. But here comes trial-and-error™. Determining right safety margins and factor of ignorance is left to player, a game just do numbers. And code DOES has prior knowledge of craft. All parts, their hierarchy, tweakables, routing and staging already are right there in code. Well, there is no general order to forbid being Kerbal.

Nah, Cobra is possible only with thrust-vectoring engines. And it's done by turning nose up, and back down again, without backwards flip. That scene is just Nesterov's Loop. Performed with impossibly tight radius and at ground-car speeds. More realistic and Messer would just zip past by the time Mustang pitched nose up by 30⁰ and be long gone at the end of loop thirty seconds later. It better would be barrel-roll or scissors. Doctor Who is a fairy tale to Star Trek and Star Wars science fantasy. Because stuff. In space anime there is common trope. Things can low orbit indefinitely, no trace of atmosphere, but go closer to a planet by several METERS and find yourself in a reentry, swiftly turning deadly. No exceptions, from Gundam to hard and realistic Planetes. And of course all action is near that very real border. At other hand, Gundam series have at least many visual nods to science. From zero-g scenes to planetfalls with inflatable heatshields not unlike 1.1 and spaceship launch with strap-on solid boosters.

I think that KSP must have at least tutorial-level dV calculator. Maybe just more detailed page in KSPedia; with interactive Equation if possible. To tell new player how to guess dV manually without lurking forums or studying books. And I understand reasoning for making it right at first try. Thought I do not agree, there was and still are things not perfect even after 1.0 release. Right now porting to Unity 5 is absolute priority, but the point of this thread is that stock dV readout was important for a long time. No dV at all is bad and not noob-friendly at all. Before making replicas new player (not rocket-geek with a slide rule) should at least be able to make some rocket and fly it somewhere and beck with only ingame knowledge. And even for experienced one addon readouts may be too overloaded. Perfect dV readout is not simple. But dV readout is necessary and please make it a priority.

Okay, writing perfect simulation to compute dV up to 0.01 m/s is not simple. Thought it may be possible to "simulate launch" on demand, second or two delay after pressing a button is not a problem. Framerate isn't important in VAB at all, and KER somehow does calculate dV without affecting it slightest. But taking default staging with similar engines and calculating dV from mass with and without fuel IS. And it gives good enough guess whether going to space today or not. There is a reason not to give us perfect dV readout, but there is a reason to include simplest dV readout in stock as soon as possible. And what exactly staging sequence is if I didn't adjust it after adding all parts top-to-down or if I clicked a "reset" button?

Sure, player complaining that display numbers are wrong in some not-so-common situation is much worse that player refunding a game because there is no display numbers at all to make any sense for not rocket-geek. Actually to complain about wrong numbers one must know right numbers, and the point of stock dV readout is to help players who don't know any numbers. Just a "deltavee" word from KSPedia. And to complain one must go to forum, right by Add-on Section. Isn't overriding of flow modes handled already by game code? The same code that can be used for simulation? There is no need to handle ALL situations, like fiddling with thrust limiting in flight, manual transfer or early staging. dV readout should display just maximum design performance or something close. Jet and monoprop engines can be just ignored, for there is only one Puff, and dV is useless for aircraft. I'm not saying that calculating dV for any random craft is simple. Thought it's certainly possible. But I insist that in stock there must be any dV readout. Even simplest one (that may be not correct with more complex design) will introduce player to crucial foundation of rocket science and will give a base to trial-and-error from.

I remembered to ignore fuel pipes. Plumbing is researched much longer into a tech tree, when player already should understand more than basics (i.e. can find a mod). Simple step of finding out resource available for each engine is simple. Each engine can use fuel only from tanks it's mounted on. Just like that is found in-flight. That does not account for radial-attached engines, but they again appear later. Shortly, finding resources is not a problem — code for handling fuel flow is already there. For next steps dV calculator may actually simulate burning and staging. I suppose that's what mods do. - check takeoff mass, take weighted average ISP of all lower stage engines; - remove fuel according to tweaked consumption of engines until some tanks are empty, check mass, count dV; - stage decouplers if any, check mass, retake average ISP of remaining or freshly started engines; - continue removing fuel again. Yes, that must be repeated every time when player change some parts in VAB. But that's just math and modern computers do math like it in no time. Also realism. A game must be not harder than reality. In reality every Head Designer does not grab a slide rule for every pencil stroke on a draft, they have an army of interns with slide rules to do math for them. KSP is already harder than real life for you can't calculate orbits and maneuvers in advance with any kind of precision. Eyeballing that is part of the fun, but running out of dV is frustrating. And dV readout at least in VAB will help to not to run out of dV most of the way out there without grossly overengineering rockets.

Thrust does not matter for dV. Only ISP and fuel mass. Start from the bottom of staging. Look what engines are started and what tanks they are under. ISP - check, mass - check, math - done. Decouple now-empty tanks with engines, fire next stage, repeat. Right, in R-7 or Atlas or Shuttle style rockets there are different engines working simultaneously for different time with different ISP and mass flow, and that greatly complicates things. But default KSP staging is serial, not parallel. First fire solid boosters, decouple them, then fire central liquid stage, decouple, fire upper stage. Simplest dV calculation will work for simplest rockets and greatly help new players. Next steps may vary, from showing dV of only lower stage, approximating by adding up dV of parallel blocks, to counting burn times of every engine or actually accepting KER code or something. But just basic dV readout is that 20% of work that gives 80% of results to 95% of players who actually need it.

I think, a game need just two new types of craft. Plane (or Spaceplane) is anything 1. created in SPH (that is not a rover) and maybe 2. with a plane cockpit instead of crew capsule or probe core. Type of engine or wings are less important. Rocket or solid fuel plane is still a plane, and wings are great structural elements for spacecraft and fins for boosters. Sattelite is hidden by default like Debris, but is not autodeleted. Because even stock contracts require to launch sattelites that do nothing but clutter map with their orbits. That type is assigned only manually, like Bases and Stations. Sattelite contracts may need type of craft to be Sattelite, or not. Also it can be used for used probes.

I want to thank GoodSpeed as the original author, and all of you people who continue to support the mod through all the new versions. For it's single most useful, helpful and simple to use add-on, flying larger vessels would be much more sad without it.

Hello everyone! Played since .22, singed in just now to add my 5₪. We now have article about "deltavee" in KSPedia. There is explained that is a delta of velocity and mentioned some equation. Also we had dV value in maneuver nodes since forever. And the game is sorely lacking of 1. explanation of the "deltavee" stuff and 2. simple display. In KSPedia there must be a page telling that delta V is and how it's calculated. Basically, amount of velocity that vessel can gain by burning all the fuel depends on proportion of fuel mass to craft mass, and on engine ISP. Less basically, just spell Tsiolkovski's equation. Simple display may be not so simple to program, that's absolutely and undoubtable correct. Thought considering all and every possibility of craft being Kerbal is not necessary. Stock delta V readout is most valuable to new players, early in Career mode, when resource transfer, docking and even fuel lines are not yet available. First readout can just take single-stage craft wet mass, dry mass, engine ISP, The Equation and display number. Next stock staging mechanic can be accounted. Game knows parts are still attached to rocket at any given stage, what engines are burning and how much fuel they have access to. Engines have ISP and fuel has mass and we have The Equation, so we can calculate delta V for all stages. Right, there are many ways to kerbal it. But here comes "trial and error". Actually, delta V can be pretty easy calculated manually in VAB/SPH. I do that for estimating monoprop thrusters dV, because KER do not. Detach anything that would be staged, Engineer Report shows wet mass. Empty all relevant tanks — Engineer Report shows dry mass. Look in parts list for ISP. Then get your slide rule, ask someone for right value of "g", multiply, add all stages, repeat all above when change any part. Implementing that in code really should be not that hard, but will spare me couple of minutes some hundred times. And when player overgrows simple rockets, they always can install a mod, make a spreadsheet, or make staging not to mess with calculations. But to new player even simplest dV readout will be a great help in understanding rocket science! TWR readout by stages or just at launch will be easier — just add all lower stage engines thrust and divide it by gross mass. But IMO it's much less necessary than dV, because adding all engines together is simple, and lack of thrust is amended by MOAR. Blackboard with cartoon rocket going to space or not going to space may seem simple, but really is not. You need not to calculate dV first, but consider all stages thrust, aero, poor piloting, and after all that compare result with some empirical value to get go, no go, or maybe go. Delta V display is absolutely not about trial and error. It's about noob-friendly, to learn difference between bad and good rockets. And it's about quality of life for not-so-noobs, that can count all fuel tanks and get a slide rule, but why should they when it can be done by computer in millisecond. So, SQUAD, please, add dV readout in stock. No need to make it correct for every situation, a simple display for simple staging is good. That will make game easier where it can be easier, and leave more player time to actually have fun making rockets and flying them where they want.