Search the Community

This is the new thread about Kerbulator. Here is the old thread, where the plugin was called Kalculator. Turned out that name was already taken. One of the big joys of Kerbal Space Program is that game progress is not based on experience points, or character level, but based on your own knowledge about orbital mechanics. Maybe this is why I don't like using MechJeb much, its free progress in the game. Inspired by Scott Manley's videos about 'orbital mechanics on paper', I spend an afternoon thoroughly enjoying myself deriving various formulae. Oh, how much fun the creators of MechJeb must have had with it themselves. So I created a mod that lets you put your own formulae in KSP and named it Kalculator Kerbulator. It is a small plugin that allows you to program mathematical equations, run them to see the output and create maneuver nodes. Of course, your calculations need various inputs (like the mass of the body you're currently orbiting, the value of the gravitational constant, etc.) and for this, Kerbulator aims to strike a balance between providing enough useful variables to be productive, and not supply too much information and rob you of the joy of calculating things for yourself. The current guideline is that Kerbulator gives you access to all the various numbers that appear in the vanilla KSP GUI. So, what are you waiting for? Download the plugin or get the source code Read the manual And start learning interesting math Author: Marijn van Vliet License: GPL v3 Feature highlights: Create manoeuvre nodes and alarms (if KAC is installed) based on your calculations Open windows that continuously evaluate your functions and present the result Unicode aware, so you can use math symbols for operators and greek letters for variables Contains a numeric solver to approximate answers that cannot be calculated analytically Edit functions in any editor you want. Returning to the KSP window will reload all functions. Current verion: 0.51 Changelog --------- 0.51 Small bugfix release, thanks to @linuxgurugamer. Fixed bug where exception was thrown if no explicit output was specified 0.5 The mechanics for creating maneuvers and alarms have been overhauled. See the manual and language reference for the new syntax. Thanks to Thorulf Neustrup! Language features: New notation for defining maneuvers New notation for defining alarms Added ability to create multiple maneuvers and alarms in a single function 0.46 Bugfixes. GUI features Fix clickthrough prevention logic not releasing the lock when closing a repeating-function output window Fix toolbar button not being removed when exiting the VHB or Hangar 0.45 Add support for KSP version 1.9 0.44 Add support for KSP version 1.4.4 GUI features Kerbulator now makes use of the clickthrough prevention logic 0.43 Recompile for KSP 1.3 0.42 Recompile for KSP 1.2 0.41 Bugfixes. Globals Added Inf and ∞ globals to denote infinity Fixed some globals that were in radians instead of degrees (e.g. θ) GUI features Fix function name validation in GUI Fix column indicator in error messages Fix missing expression error message Fix behavior when running a repeating function that contains an error Fix a bug where the output of the previously run function was shown Fix delta-V in normal direction when placing maneuver node 0.4 Some welcome additions to the language. Language features Add boolean operators: < > <= ≤ >= ≥ == != ≠ ¬ ! ∧ and ∨ or Add support for piecewise functions (a.k.a. if-statements) Add support for specifying pre- and postfixes for output variables GUI features Add support for showing pre- and postfixes for output variables An error message is shown when the user tries to save a function with an invalid name 0.36 Add support for KSP version 1.1.3 GUI features Remember window positions 0.35 Add support for KSP 1.1.2 Language features Added global `Sun` 0.34.5 Recompiled against KSP 1.0.5 0.34 More globals. Thanks to Emanuele Bardelli. Language features Fixed `{Body}.AtmosHeight` global Fixed `{Body}.AtmosPress` global Added `Craft.Rel.AN` global Added `Craft.Rel.DN` global Added `Craft.Rel.Inc` global 0.33 Small maintenance update. Thanks to Emanuele Bardelli. GUI features Fixed support for blizzy78 toolbar Language features Added build-in function `atan2` Added build-in function `atan2_rad` !! Breaking backwards compatability Kerbulator used to store its files (.math) outside the main Kerbulator folder, which is a violation of the guidelines laid out by Squad. Function files now go in the `PluginData/Kerbulator` folder. 0.32 Kerbal Alarm Clock integration GUI features Maneuver node button hides when not in flight Added button to add alarm Language features Added ability to add alarm when KAC is installed 0.31 KSP 1.0 Compatibility GUI features Added support for the stock application toolbar Kerbulator now available in all scenes, not just in flight Globals *.AtmosHeight and *.AtmosPress currently disabled as KSP 1.0 changed things 0.3 JIT Compiling baby! GUI features Added GUI for calling functions that require inputs Added ability to run functions continuously and pin the output to the HUD Windows can be resized Language features Functions are now JIT-compiled and run at native .NET speed. Added Nelder-Mead solver for numeric approximation Added build-in function `mag` Added build-in function `cosh` Added build-in function `sinh` Added build-in function `tanh` Geometric build-in functions now work in degrees by default *_rad function added that work in radians Build-in function `dot` can now also perform matrix multiplication Globals Craft.Inter1.TrueAnomaly is now in degrees instead of radians Craft.Inter1.θ is now in degrees instead of radians Craft.Inter2.TrueAnomaly is now in degrees instead of radians Craft.Inter2.θ is now in degrees instead of radians !! Breaking backwards compatability Geometric build-in functions now work in degrees instead of radians. Use the *_rad functions to get the versions that work in radians. 0.23 Bugfix. Thanks to Bas Cornelissen to patiently work it out with me. Language features: Properly deal with `\t` and `\r` 0.22 Better errors and more globals. Globals ([URL="https://github.com/wmvanvliet/Kerbulator/blob/master/doc/globals.mkd"]description of all globals[/URL]): Added {body}.Inc Added {body}.LAN Added {body}.Ω Added {body}.SOI.ÃŽâ€t Added Navball.Heading Added Navball.Pitch Added Navball.Roll Added Navball.OrbitalVelocity Added Navball.SurfaceVelocity Added Navball.VerticalVelocity Renamed Craft.Inter1.sep to Craft.Inter1.Sep Renamed Craft.Inter2.sep to Craft.Inter2.Sep GUI features: Better error messages. Hunt down the bugs in your code with more ease. 0.21 Bugfixes. Thanks to Teseracto for finding them. GUI features: Fixed losing changes on window switch Closing main window no longer breaks toolbar button Language features: Operator precedence fixed. (Added some unit tests for these cases) 0.2 Renamed the entire project Kerbulator, since [URL="forum.kerbalspaceprogram.com/threads/66881-0-23-In-game-scientific-calculator-Kalculator-v0-1-1-1-24-14"]Kalculator[/URL] is already an excellent mod by agises. Globals: Fixed µ globals GUI features: Added support for blizzy78 toolbar Icons for some buttons 0.11 Fixed bug where sometimes the run button did not work. 0.1 Initial version. Language features: Functions Expressions Lists List unpacking Globals: All celestial bodies Current orbit Orbit of target Target intercept information GUI features: Function list Description of input and outputs Very basic support for error reporting Editor with keyboard Re-scan function on window focus Add maneuver nodes

Maybe it has been asked and answered and I just don't know how to search for it. I know there is an answer but it's the question that I think is off. So... I suck at math. I can do a little basic algebra. That is why I am playing a game that is all about engineering and math! I have been going through sites reading about orbits and have found this. e=c/a where e is the eccentricity, c is the focal distance, and a is the semi-major axis. I know e and I know a. So c=a*e? Can I determine a periapsis and apoapsis from this and establish an orbit with the desired eccentricity and axis?

Quick explanation: Sidereal time vs solar time. Above left: a distant star (the small orange star) and the Sun are at culmination, on the local meridian m. Centre: only the distant star is at culmination (there has been a mean sidereal day since above left). Right: a few minutes later the Sun is on the local meridian again. There has been a solar day since above left. (from Wikipedia) As you can see, the sidereal day is the time that a planet takes to do exactly one rotation around its rotation axis, whereas the solar day is the time between the moment of two consecutive days when the Sun (or the planet's star) is the higher in the sky. So the question is, how do you calculate the length of the sidereal day of a planet, if we know the length of its year in days (Earth is 365.26 days) and the length of its day? Try to guess! Also please put your explanations, if you post any, in spoilers.

It's not effective, either to have a single gigantic tank for Tylo and back, nor having two hundred separate stages for a trip to Mun. Is there a formula to calculate the minimum fuel to dead weight ratio for each stage in order to have a net delta-v gain for adding that stage?

Hey there, I am new at asking questions so please be gentle. I am a PS4 KSPEE player and I am trying to perfect my landing on the launch pad, now with that being said it is going to require allot of math and I just don't know the formula, I was thinking about how it should include the TWR, the weight of the object being landed, how quick the fuel is being drained, it is kind of like the rocket equation but with added steps and it will lead to a different outcome, if there is someone who could make a calculator I know that not only I will appreciate it but so will the KSPEE players and the stock KSP players alike. Thanks everyone!

I'm planning my first asteroid capture mission, and (without having played the tutorial mission) I got curious to learn how much fuel and thrust I would need to put on the capture vessel in order to bring the asteroid into a useful orbit around Kerbin. I spent a lot of time trying to learn something about it, and thought I would share. I would really love to hear your thoughts and feedback! The lovely little space rock I have in mind to make my own is one SDD-569, a class A asteroid. SDD-569 is approaching Kerbin for a leisurely flyby at a periapsis of ~2,079 km, well inside the orbit of the Mun. This puts SDD-569 into a sharply looping orbit around the planet, before it flies back out into parts unknown. I'd like to drag the asteroid into a circular orbit, and then bring it down to about 500 km for future research and exploitation. Can we calculate how fast is SDD-569 going with respect to Kerbin, based on what we already know? Since energy is always conserved, the total kinetic energy for a given object (from orbital speed) plus its potential energy (from gravity) never changes. The relationship of kinetic energy to velocity is a consequence of Newton's third law: In other words, for a constant mass, v2 is a measure of kinetic energy. The vis-viva equation describes the conservation of energy for a small body orbiting a much larger one: GM, also known sometimes as μ, as is Kerbin's gravitational parameter, which the KSP wiki reports is 3.5316 x 1012 m3/s2. This parameter is the product of the gravitational constant of the universe with Kerbin's mass, which is effectively constant. a is the semi-major axis of the orbit as measured from the center of the celestial body. Kerbin's radius is 600km, so we add that to the altitude of SDD-569 at periapsis to give a = 2,679km. r is the distance between the two objects at a given time. An object moving fast enough to escape Kerbin's gravity is in an orbit with a semi-major axis that is effectively infinite. At periapsis, this simplifies the vis-viva equation to describe the kinetic energy that an object must have in order to overcome Kerbin's gravity from a given distance r: In other words, escape speed from Kerbin orbit at the moment of periapsis (r = 2,679km) is ve = 1,623 m/s. But since SDD-569 is tracing a hyperbolic (i.e. open) trajectory through Kerbin's SoI, it must be traveling faster than this, or else it would be captured. How much faster? Consider the other extreme case of the vis-viva relation, where the asteroid has shot past Kerbin and the distance r between them trends towards an infinite apoapsis. Setting r =∞ in the vis-viva equation tells us how fast the object is still going at that point, which is called its hyperbolic excess velocity: (where μ = GM) So for the flyby of SDD-569, the hyperbolic excess velocity is v∞ = 1,148 m/s. This characteristic energy is over and above the energy needed to escape Kerbin's SoI from that distance, so the total energy possessed by SDD-569 relative to Kerbin at periapsis is: This gives a total velocity for SDD-569 relative to Kerbin at periapsis of 1,988 m/s! By how much do we need to reduce this so that it drops into a nice 2Mm circular orbit from periapsis? In a circular orbit, the distance between the two objects r and the orbital radius a are always the same. Thus the orbital velocity is: Not coincidentally, this is the same as its hyperbolic excess velocity, because r = a. So at r = 2,679km, an object in a circular orbit around Kerbin travels at 1,148 m/s. So, to get SDD-569 into a circular orbit from its flyby periapsis, we need to bleed off Δv = 840 m/s. To then bring SDD-569 down to a more convenient altitude of 500km, we would do a Hohmann transfer, which can be calculated with the standard formula, and works out to another 614m/s Δv to descend to a 500km circular orbit, for a total of 1,454 m/s. What’s more, the spacecraft sent to capture SDD-569 needs to match orbits with the asteroid in order rendezvous. That means that if the spacecraft starts from, say, 500km above Kerbin, it will need to expend that much to get to the asteroid in the first place. So, starting from a 500km orbit around Kerbin, the total Δv budget for this mission is 2,909 m/s. Next up: Asteroid capture planning, part 2: How much fuel do we need to bring? Mission to SDD-569: Where the rubber meets the regolith! Did I get this right? If you have feedback or ideas, I would love to hear them!

Hello, this is my inaugural post on the KSP forum. To learn some more physics and calculus, I'm trying to create an analytical equation for the path of a solid fuel model rocket fired vertically. I first made an equation assuming no atmosphere and no orbital mechanics, which I am satisfied with. I'm currently making an equation that accounts for drag, and assumes there is no change in atmospheric density and no wind. The equation I am using is from Wikipedia, specifically vertical motion upward and vertical motion downward. I am not sure how to adapt this equation to work while the thrusters are still active. If anybody can help me with this, I would be extremely grateful. The work I have done so far is here: https://www.desmos.com/calculator/ncmd38rosu The Variables folder contains all variables, the No Drag folder contains a complete equation that I have made personally, and the drag folder contains what I have done so far to account for drag. I am more than happy to explain my thought process/reasoning on how I have come up with what is on there so far. Thanks, and I look forward to spending more time with the KSP community.

Hello guys. I am an amateur Kerbonaut and I want to start to calculate dV by hand since it is so nice and fancy to do. When I looked up, I came across this formula: dV = Isp * gravity * ln(m0 - mf) Everything is fine, but when I utilize this equation and check the results with VAB, I get HUGE differences for other planets. Currently I am trying to visit Eve and comeback. My lander should have God knows how much dV. So, for a stage (mid), I put: Rockomax 32 (x1) FL-A215(x1) FL-A151S(x1) Skipper The upper payload is 4.090t. Therefore, according to the equation: Isp = 280 Gravity = 16.7 m0 = 32.740t mf = 9.940t and dV should be 280 * 16.7 * ln(32.74/9.94)= 5579.9 m/s but VAB says it is 666m/s. What I am doing wrong? Good luck in your space journeys

I'm trying to write a python script (using the kRPC mod) to do a suicide burn. However, so far I always reach a velocity of 0 a few hundred meters above the ground and then proceed to plummet to my death. My assumption is that the problem is a mathematical one, as the code is fairly simple. So I'd be very grateful if someone could check my math. Alternatively, if anyone has a different solution for what I'm trying to accomplish, I'd be happy to hear that to. For simplicity's sake I assume that my spacecraft is always pointing straight up and falling straight down. I also assume that there is no atmosphere and thus no drag. So here is what I have come up with: (Handwritten version of math) t: Time since start of the burn in seconds (s) Fe: Thrust of the spacecraft's engines in Newton (N) M0: Wet Mass of the spacecraft at the beginning of the burn in Kilogram (Kg) g: Surface gravity of the body I'm landing on in meters per second squared (m/s^2) W: Weight of the spacecraft in Newton (N) W = M0 * g F: Net thrust of the engine when decelerating the spacecraft in Newton (N) F = Fe - W K: Fuel consumption of the engine in Kilograms per second (Kg/s) a(t): Acceleration (or deceleration, depending how you look at it) of the spacecraft after t seconds, taking into account the decreased mass due to fuel being burned. In meters per second squared (m/s^2) a(t) = F / (M0 - K * t) Tb: Duration of engine burn in seconds (s) Dv(Tb): Speed change of spacecraft for a burn of Tb seconds in meters per second (m/s) Dv(Tb) = Integral from 0 to TB [a(t)] dt = Integral from 0 to Tb [F / (M0 - K * t)] dt = (F/K) * ln(1 + Tb * (K/M0)) Up until this point everything is based on this reddit comment. However, I am not sure if the integration for Dv(Tb) is correct. If I do it myself I get a different result, but the dimensional analysis for my result doesn't work out, so I've been sticking to this one. v0: velocity of spacecraft at the beginning of the suicide burn in meters per second (m/s) To calculate Tb, let Dv(Tb) = (F/K) * ln(1 + Tb * (K/M0)) = v0 and solve for Tb: Tb = (e^((v0 * K) / F) - 1) * (M0 / K) Da(Tb): Distance the spacecraft falls during burn of Tb seconds in meter (m) Da(Tb) = Integral from 0 to Tb [-v0 + Dv(Tb)] dt = Integral from 0 to Tb [-v0 + (F/K) * ln(1 + t * (K / M0))] dt Because I couldn't find an analytical solution for Da(Tb) I decided to solve it numerically every tick. I now run the above calculations every tick (multiple time per second) and then check if the resulting Da(Tb) is close to (within 10m) of the current altitude of my spacecraft. If it is I know I have to start the suicide burn. However, as mentioned above, it always starts a few hundred meters to early. It shouldn't be relevant, but this is the spacecraft I'm using to test my code. In case the above is to confusing to follow, here are my handwritten notes. They should contain the same information as above but more neatly formatted. Beware my handwriting though Also, is there a way to insert latex formulas in my post? I think that would have helped a lot. And this is a copy of my code so far, if anyone is interested: So, again, if anyone is willing to check my math, I'd be very grateful.

How do I calculate the surface longitude where I start my transfer burn to geostationary altitude, given the surface longitude where I want my satellite to end up, my current altitude and orbital period, and my current longitude? I'm trying to write a kOS program that puts a satellite into a precise-ish slot in geostationary orbit. My probe is powered by a single ion engine and has a wet mass of 1.726 tonnes.

Just a thread to discuss math things, I guess I havn't seen one so here.

A while ago I had a question that went a little like this: "Planet Kerbin has a radius of r from its center and gravity of G. Two identical rockets launch from the equator at opposite sides, and start accelerating along the rotation of the planet with the velocity of V. At what time after they finished acceleration did they reach maximum distance from each other, and what was the distance?" It also said in its prefix that "people attempting this question might want to find out a little about Kepler's laws." I think I got the answer, but I am not sure if it is right, as I didn't know any good method of doing such a calculation. Could you please help me by telling me how do you find out these variables algebraicly? I also found the only picture that I had of this question, and here is a graph that went with it

Hi there, I'm an aerodynamics student and am looking to do the same kind of medium-fidelity aero modelling that's done with Ferram Aerospace - the calculation of aerodynamic coefficients, stability derivatives, and the like for some arbitrary body, and as functions of Mach number, AoA, etc. Does anyone know if the developers compiled a bibliography/list of references/papers for the algorithms they implemented? If not, is there any information on how their algorithms work, or could anyone recommend some papers I can look at to get started? (I'm familiar with basic flight dynamics theory already, and am more interested in the actual computational component.) Thanks!

Hi, I've made a quadcopter and found I cannot control it. If I attach rotors to yaw/pitch/roll and thrust I am able control thrust but yaw/pitch/roll override each other so only one is effective. Thrust works because it's incremental while yaw/pitch/roll are absolute. At first I wanted do demand multiple overlapping controls to work additively (and they should) but then I realized that won't be enough. The collective throttle must lift the craft while axes control should only modify torque to control its movement and may work much weaker. So the torque for single engine could be calculated by a formula T=(1 - 3k)t + ky + kp +kr, where T is torque, t is throttle, and y, p, r are yaw pitch and roll, respectively. k is axes to throttle coefficient, let it be 0.1, for example. Now, this cannot be done. So I think the formula controller should be available for our creations. Of course this will be usable not only in quadcopters. Why not control ailerons in function od speed? In supersonic flight they are too strong while in low speed maneuvering they could work stronger. We could also describe by formulas hinges' movements as a function of time or the controller's value (then a controller's path could be a variable, not necessarily bound to a part).

Is there an equation to calculate the heading I need to fly to reach an orbit of a certain inclination, based of the latitude of the launch site?

Before Reading I'd recommend that you'd watch Bradley Whistance's video on his stock prop speed test. The method he outlines is not relevant to the actual math work, and simply affects the values I will be plugging in. https://www.youtube.com/watch?v=J7oc1FLnWlY&amp;t=438s I will only discuss the resulting data in this thread to keep things simple, if you have specific questions about the math, let me know. With that out of the way, let me preface this discussion. The dominant method of powering stock props is by using RTGs, which makes sense. They continuously generate power, allowing stock props to run forever, this is great for Duna, Eve, and Laythe exploration. However, I commonly see this used on props built for fighter craft, transport aircraft, and others. While there are some cases where endless flight is desirable on Kerbin, such applications certainly do not qualify. Most people don't fly a single stock prop fighter for hours on end (without crashing). This leads to the question, are RTGs the most efficient way of powering these props? Short answer, no, but I'll explain in more detail. I am taking efficiency to mean weight in this conversation, although other uses of the term, such as part count, may also be referenced. First we must establish all of the possible methods of powering a stock prop: RTGs (duh), batteries, and fuel cells. RTGs we already discussed. Batteries would simply run the engine using their stored electric charge, and the flight would end once they run out. Fuel cells would burn LFO (Liquid Fuel + Oxidizer), continuously generating the engines power needs whilst draining LFO from on board tanks. Of course, I wouldn't even consider the fuel cells to be an option unless I had a good reason. Doing some simple math, we can find that all batteries hold 20,000 units of electric charge per tonne. How much electric charge, then, is LFO equivalent to per tonne? It depends on which of the fuel cells you are using, but for the small fuel cells this comes out to 79,934 units of electric charge per tonne of LFO, and for the large fuel cells it is 81000 units per tonne. Looking at the raw data, fuel cells are the obvious winner. However, the additional weight associated with fuel cells throws a wrench into the works, and in either case this tells us nothing about how RTGs stack up. So I will analyze these three choices in an applied setting, where I will test their mettle in a hypothetical prop that utilizes 10 of the 1.25 meter reaction wheels with 2 dumpling fuel tanks used as bearings. I did these calculations presuming that this engine would also utilize the trick described and demonstrated by Bradley Whistance's video. Using this method the reaction wheels consume roughly 2.73 times their normal power (according to my own testing), I'm using ball park numbers so any small discrepancy is irrelevant. RTGS: The 10 reaction wheels consume 13.65 units of electric charge per second, as such the engine would normally require 19 RTGs to run continuously, which themselves would weigh 1.52 tonnes. BATTERIES: To run this engine for 1 hour you would need 49,140 units of electric charge. This would require 2.457 tonnes of batteries, so those certainly aren't the best solution, although using the largest battery bank available, this would only require 13 batteries. Since the weight of the batteries required scales directly with time of flight, they are likely the most efficient in very short flights. FUEL CELLS: The smaller fuel cells generate 79,934 units of electric charge per tonne of LFO, meaning only .615 tonnes of LFO is required to run the engine for 1 hour. This amount of LFO is almost perfectly held by the 2 dumplings in the bearing, plus two oscar tanks which altogether hold .62 tonnes of LFO. In total the tanks would weigh .698 tonnes (including dead weight), and this engine would require 10 of the small fuel cells to run continuously. This adds another .5 tonnes to the total weight, bringing it up to 1.198 tonnes. As well as 14 parts, but really that's 12 since the dumplings have to be there regardless. In every possible way, the fuel cells are more efficient, while the use of dumpling bearings may seem to bias the fuel cells, in reality this does not affect the weight, and only affects part count. Using a different bearing type would only add 1 additional part, making it on par with batteries and superior to RTGs. None the less, it is far superior to both in terms of weight. This leads me to conclude that Fuel cells are the superior method for powering stockprops intended for short to medium flight times. It should also be added that it is of course possible to mix these methods together. In this one instance, it is actually beneficial. While 10 fuel cells are required to meet the continuous power generation needs, this is only by a small amount, the raw value is 9.1 fuel cells. This adds the equivalent of 540 additional electric charge generation required over the hour of flight. Since fuel cells come with 50 units of electric charge storage each, this means that 9 of them would have 450 units total, leaving us 90 units short. These 90 units can be accounted for with a single of the smallest battery pack (which has 100 units). Weighing in at a mere .005 tonnes, this change leaves us with the original part count of 12 and a reduced mass of 1.153 tonnes. So yes, it is possible that adding batteries will lead to a net increase in efficiency, however, the instance described above is the only type of scenario where this is actually the case. So limited is this possibility that even if the real value turned out to be just 9.3 instead of 9.1, then using batteries would result in a net increase in weight. Again, these results may be different for engines of differing sizes. however I can only see fuel cells being knocked from their throne with very different total flight times. For instance, short flight times where batteries' ability to instantly deliver power gives them a major advantage, and long flight times where RTGs' endless power generation eventually overcomes their initial mass costs. This may be obvious already, but just to clarify, the fact that the math above uses reaction wheels affected by Bradley Whistance's technique IN NO WAY affects the actual math or conclusions. The math above is roughly equivalent to if you had simply used 27 reaction wheels functioning under normal conditions. The objective of this thread was to demonstrate that fuel cell powered props are a lighter and more part efficient approach to powering certain stockprops. While it took a decent amount of complex work to arrive at this conclusion, in actual application fuel cell powered props are no more difficult to build or use then RTG props. There's also the small fact that a fuel cell powered prop will not only start out lighter than a RTG powered prop, but it will also get even lighter as LFO is drained throughout the flight, further increasing performance. I appreciate any questions or feedback you may have. If I made any mistakes, please let me know, and I would love to hear your thoughts on the topic. @klond I think this may interest you.

Hello! Firstly, I know questions like this one have already been made both in and out of the forums before, yet every thread I found and read do not fix my problem or give me an idea of what I'm doing wrong. Also, sorry if this ends up a bit too long and technical, I want to try and make it as clear and detailed as possible, especially when explaining the math I did, so it doesn't confuse or give the reader a headache. So... I finally decided to play KSP [more] seriously, disabling "revert flight" and trying to calculate the rocket performance and everything else before launch to minimize failures. I'm playing the Enhanced Version for the Xbox, which should be pretty much a 1.2 stock for PC. The rocket I have is comprised of two stages: the first one has 3 engines, a center Swivel one (with 2 FL-T800s on top), and two radially mounted Reliant engines in an asparagus setting (so they have one FL-T800 on top each, with both of these fuel tanks feeding into the center one directly above the Swivel - this way, once the radial tanks are expended, they will be jettisoned with the Reliant engines). The second stage is the orbital stage, having a single LV-909 Terrier with a FL-T400 on top (will talk about it later on). The goal of this rocket is to carry scientific equipment to a space station at a 200km circular orbit over Kerbin, where it's currently being assembled for a mission to Minmus. The problem I initially has is that the Delta-V calculation I done for the first stage gave me a result of ~1899m/s², which theoretically should not have been enough to allow me to leave Kerbin's atmosphere (as "Delta-V out" of Kerbin is 2500m/s²). Yet, I managed to dock with the intended station with about 60% of fuel remaining in the second stage (no cheats involved, I swear). I've done all the calculations based on what's available at wiki.kerbalspaceprogram, making use of the "Advanced Rocket Design" and "Cheat Sheet" topics. Will go over the math now: Starting up, I calculated the average Isp of the three engines at sea Level, which was pretty much: (F1+F2+F3/(F1/Isp1)+(F2/Isp2)+(F3/Isp3) being F=Thrust at sea level. This gave me an AvgIsp of 261 (which I called Isp1). Right after, I got the total mass of the craft (M0=28556t) and the first dry mass (aka: the mass with empty radial tanks before dropping them and the Reliants; which I called M1=20556). I also calculated the new mass right after dropping the radial tanks and with full center tanks and swivel engine (M2=16646); and dry mass for empty center tanks (M3=8646). Based on this, I calculated 2 delta-Vs for the first stage: Delta-V1, while both the Reliants and Swivel were firing; and Delta-V2, after the Reliants were dropped and only the Swivel was firing and taking fuel from it's own tanks now. So, Delta-V1 = Isp1(261)*g[9,81]*ln(M0/M1)[0,32] obtaining a value of ~819m/s². Did the same for Delta-V2, calculating the Isp2 for the Swivel only part of the flight, for which I got an Isp2 of ~167.9; then Delta-V2 of 1070m/s² I then made the sum between both Delta-Vs, obtaining that nasty odd value of ~1889m/s². As for the second stage, it gave me a Delta-V value of 276.6m/s², adding the whole sum to 2175m/s² (which shouldn't even be enough to take me out of Kerbin's atmosphere, let alone docking. The whole flight from Launch to a circular 200km orbit should require ~4844.88m/s², more than twice what I had! Some thought and considerations (and questions): 1. I know the Delta-V I calculated is lower than the real Delta-V, since, for all the first stage engines, I only accounted for the Sea Level Isp and ignored the Vacuum Isp - while in reality the higher I went, the more Isp I'd have, thus increasing my Delta-V - although I don't believe it would have such an impact on the Delta-V. 2. I tried being efficient during the atmospheric flight, avoiding overspeed and unnecessary drag, which caused me to lower the throttle quite a bit (especially while the 3 engines were firing) and in turn increase the engine-on time, resulting in more Isp since I was ever higher with the engines on. This goes back to point 1, since I only considered Isp for Sea Level even though half of my fight happened at high altitude / low pressure / higher Isp environments. Could this also justify the Delta-V discrepancy? 3. Is there a way I can calculate Isp at an specific altitude so I can be more accurate (instead of only taking into account the Vacuum Isp for the 2nd/orbital stage and ASL Isp for the first stage)? 4. I tried repeating the math but assuming I'd not fire the Swivel until the Reliants were dropped. In the end it gave me a noticeably higher Isp and Delta-V, although still not as high as theoretically necessary. This is kinda odd though, shouldn't firing all engines together but feeding only from the radial tanks be more effective? Thanks. Would love to hear what I've been doing wrong and hope I didn't give too much headache to people trying to read this. (And yes, I'm super jealous of you PC players with all the fancy Kerbal Engineer calculating stuff!) Cheers.

I have Asperger even if I was kid I was suspected (wrongly) that I have ADHD I could not learn the multiplication table, which was required in my country, Poland I can not do it until today, and I am almost 33 years old I often flunk math I could make calculations, but only with the help of a calculator. I remember once from boredom I started playing with a calculator and started to add numbers to each other. The teacher saw it and asked what I was doing? I apologized to him, and I said I was just having fun. This teacher said that I was just doing the Fibonacci sequence, do not even know it, and that I would not put crap on him, that I do not know mathematics, because from what I see it could be quite a good mathematician xD One of my friend who is also having Asperger advised me to learn to programming in Python, that is the easiest programming language to learn. I bought a course on Udemy and start to study, but I'm afraid that I'm too old https://answers.yahoo.com/question/index?qid=20190124084232AA3Yh98

What do you think about using calculators in math classes? https://answers.yahoo.com/question/index?qid=20181217235050AACyVCW What do you think about using calculators in math classes? During my mother's time, and most of my school education, students were not allowed to use them Hi, I'm from Poland, my mother who died in 2015, she learned in the so-called (tehnikum) technical school, some kind of specialized high school, that was less material in one matter and more in other technical stuff a bit more college like In my mother's case it was a technical electrotechnical (electrical engineering) technikum, graduates of this type of school was known as technik (technician) for exemple my one of my best friend who had Asperger (i had it too) graduated as "technik informatyk" = IT technician xD So when i was young it was forbidden to use calculators in schools it was allowed about in 2000 when i was in middle school. So my mom once told my story, that teacher who once forbidden to call him professor even it was a custom in Poland to call High School teacher that way, saying that if they could refer him as Mr. Engineer because it title he hold or simple Mr Teacher. And said that they would use paper and pencil and pure math, that they could use, they can use logarithmic sliders, even if it's lame in his opinion, but ministry of education allowed it But if they bring "Imperialistic" portable calculator swank how they are awesome, he would put said calculator in their "rectum" soo deep that it would come with their mouth xD My mom teacher said that they probably wouldn't newer work for in "our Soviet comrade's cosmonautic space programme nor for imperialist American NASA" and they would need calculators. My mother's teacher was before 30, but he liked to beat students talking on his lessons or behaving rudely with his ruler on their neck or palms, only a few students ware girls rest of them was boy (I'm a man too) My mom said that most girls there was in love with him, that he was so handsome and yet so intelligent and commanding xD My mother told me this when I said that I would probably newer found a girlfriend because of I'm Kujon (polish slang word for Nerds) and have Asperger Syndrome (now I'm known that i'm gay even though I do not look like gay :-) I think my mum suspect something xD My mum said that some girls like kujon (nerds) that she considered herself to be intelectualist (nerd) herself :-)That she married my dad because he was Intelligent and funny, the only fault was he's short tamper (dad died in 2002) that now after I was diagnosed as Asperger that dad had it too :-)

In my latest career mode game I am planning to start a Laythe colony. I am using MKS and USI Life Support, with the lowest levels of Interstellar Extended's power and propulsion tech unlocked. In short, no transit times to Jool that would be less than two years or so, at least while carrying a reasonable (30+) number of passengers per trip. I plan to use the Cycler to only carry colonists, building more as time goes on to eventually have a voyage every year or so. Cargo deliveries can be done with traditional Hohmann Transfers. Unfortunately my math and coding skills are not up to the task of determining masses and orbital parameters for this vehicle. I am hoping you nice folks can help me figure these parts out. My questions are as follows: 1. How many ships would be needed for one to arrive at Jool every year? 2. What would be the parameters of the Cycler's initial orbit? 3. How much Delta-V would I need for course changes, ideally or worst case, per trip? Could I use the Joolian moons to reduce this? 4. Is there a more resource-efficient way of doing this cost-wise? I figure that the Cyclers will pay themselves off within two or three voyages because the fuel and construction costs to carry the supplies and crew would be far greater for a similar ship that had to decelerate at either end of the voyage. Once I unlock the more powerful fusion drives this design will be obsolete, but in the interim I have contracts to do things near Jool, and I want to simulate the rotation of specialist personnel that such a facility would experience. As for off-world infrastructure, I currently have a mining and science base on both the Mun and Minmus, a big orbital fuel processor around Minmus, Science/tourism station orbiting the Mun, a science base on Duna with a fuel plant on Ike, and a fuel depot in Geosynchronous orbit over Kerbin, with smaller tugs to carry fuel to crafts in LKO.

(deleted)

When calculating Delta-V manually the equation would be DeltaV=ln(m_start/end)xISPx9.8m/s^2 Now my question is when traveling to the moon would you change the 9.8 to calculate delta v? Im just confused as 9.8m/s^s is acceleration of gravity on earth. Thanks, Jonda

I have an equation that shows the target speed you need to reach to have a successful hohmann transfer: V = 1878968 * sqrt(2/RInitial-2/(RLowest + RHighest)) It's always worked in the past, but I recently tried to use it to find the target velocity for a transfer around the sun. When I plug in the numbers, I get a ridiculous answer of 16 m/s, and I don't know why. The weird thing is, I tried looking this formula up on Google to see if I missed something, and I cannot find it anywhere. Has anyone else used this formula?

WARNING, Math ahead. So I was trying to find an intuitive way of approximating the reverse rocket equation by hand (without havinng to developp an exponential) : M = m.exp(DV/ve) And came up with that : (1) M1 = m.(DV/ve) As the mass of fuel required to propel the playload mass up by a desired DV, with an exhaust velocity of ve (conservation of momentum). (2) Mn+1 = (Mn/2).(DV/ve) As the mass of fuel required to carry the mass of fuel Mn while accelerating (by summing over a triangle, one can see you only need to propel up to Dv/2 on average). Edit : here is exactly where the above formula comes from : If DV < 2.ve, then the sum (Mn)n>=0with M0=m is convergent and easy to compute by hand. Its sum is : (3) M = m. (2ve + DV)/(2ve - DV) Which is not consistent with the correct reverse rocket equation. Close enough for small DeltaV : if you take r = M/m, and z = DV/ve, we find r(z) = (2+7)/(2-z) = 1 + z + z2/2 + z3/4 + o(z3) Instead of r(z) = exp(z) = 1 + z + z2/2 + z3/6 + o(z3) For r > e, (z > 1), at interstage mass ratio that are not unseen, the approximation gets significantly off (in a conservative way at least). https://prnt.sc/jnq406 But more importantly, I don't know why I don't end up getting the correct formula, altough I strongly suspect step (2) to be at fault, and I'd like to be enlighten.

I recently desired to take a small manned craft into polar orbit, so on an unrelated mission I hauled up a pod stuck to 800 fuel and a tiny engine and hurled it into the void. But going from equatorial LKO to polar LKO is not best done from LKO. If I did a single maneuver the delta-V would have come close to 3200! I know that with large inclination changes it can be cheaper to raise your apoapsis, do the inclination change, and then re-circularize, and that was certainly the case here, but is there any easy method to determine whether this is the case? Or more importantly in the example, is there an easy way to approximate how much the apoapsis should be altered for the most efficient maneuver? Or a ratio of altitude delta-V to inclination delta-V? I just did a bunch of permutations of the two maneuvers until it seemed like the diminishing returns weren't really worth the effort anymore, but I was wondering if there was a "right" way to figure this out that doesn't require an actual rocket scientist.