[1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)

[cybutek]

That will be a problem with the other plugin. KSP cannot process any physics if a part has a mass of 0, because it would mean dividing by zero. Parts must always have a mass, even if it is just very small like 0.000001.

[cybutek]

New 0.4.2 version available!

Hopefully this release will fair better than the 0.4.1 release that needed the quick fix of 0.4.1.1 due to a very big bug that was introduced.

The main additional feature is a Rendezvous Display which will show various details which are useful whilst performing manual rendezvous manoeuvres. Including phase angle, relative inclination, distance, altitude and relative velocities. The other feature is that it now saves and loads the window positions for both the Build Engineer and Flight Engineer. An example of this being useful would be if you like having the Flight Engineer slightly down so you can see the quicksave text, it will now stay there when you quickload.

As usual, if there's anything which is broke, missing or worth adding. Please tell me and I'll fix it or see if it's worth becoming a planned feature for implementation. As some of you have probably noticed, this plugin has a very rapid development life cycle. Being able to keep the updates coming is very much based on ideas and fixes, most of them coming from you guys. With your help this plugin can only get better!

[antbin]

Hi Cybutek, great work on the Kerbal Engineer, it is a pillar of rocket building. I especially like the "stage/total weight" display column.

How difficult is the engines-and-fuel-in-different-stages problem? Do you have a sense if it's solvable?

Many of my ships lately have had fuel droptanks, and I'd really love to be able to learn just how much delta-V improvement I'm getting from staging.

Is it possible to parse the decoupler 'tree' to deduce for how many stages an engine will 'stick around' in service on the rocket?

[cybutek]

Thanks for the compliment, it means a lot to me that you and others are making use of my hard work.

The problem with the delta-v when using vegetablised staging is that I'm going to have to spagettify the code quite a bit... Like the puns? Bad huh

It is definitely something I would like to work on. As like you and everyone else, I also use drop-tanks and vegetarian staging. But because this will be quite an undertaking which will require a lot of thought and time to get my head around, I have focused more on getting out something which works. Adding the bit-sized feature updates with every version along with the bug fixes and general improvements. When I do go ahead with sorting this out, I will have to be certain in my mind that the current version is stable. I've only got a certain amount of free time available for working on this plugin, and all of that will be taken up by this one feature alone. In which time there will be no time spare for bug fixing.

The plugin at the moment on this last update seems to be fairly stable, although I have noticed a typo ;-). There's still a couple minor fixes and some feature polish which still needs to be done. But as long as no big bugs are found, this plugin will be stable enough after one or two quick updates for me to go ahead with this planned feature.

I am at the end of the day relying on everyone's help which comes in. I know it sounds bad, but I do not have enough time to thoroughly test every update in all situations. So all the feedback possible helps me figure out what is broken and what is not. Along with the big game breaking bugs, if anything odd happens it will be helpful to know. Or if it runs perfectly as expected, that also helps me figure out what parts are working well so I can concentrate on others. As I always say.... Any and all feedback is welcome! No matter how small, it could help in more ways than you think.

Example would be that you keep reading the Time to Apoapsis instead of Apoapsis Height, so I'll move it around to make it easier etc.

[willow]

Awesome you've put in the folding of the information blocks. Thanks

I've noticed 2 things using your mod yesterday, first of all, when in flight the mod will at random times move it's window to the top-right of the screen. Even after I moved it to another spot. (On top-right it fights mechjeb for screen space.)

Another issue was that I landed on the moon and did a kerbal eva. The mod was gone when I got back to the ship, it did reappear suddenly when I staged to the final stage entering kerbin's atmosphere. So apparently staging triggers your window code.

Yesterday I used your mod to whip up a few rockets with appropriate delta/v's. They all worked like a charm. The first one was only intended to reach orbit, but once there your mod said I could do a munar orbit, which I doubted but I did and it was right! The second attempt was a munar landing. I really like knowing how many delta-v's I have available on the rocket. I did note your mod makes a pessimistic guess, if mechjeb suggests I need 800 deltav for a munar transfer your mods before and after counts indicate it's only used 600. That could also be the effects of ksp's throttle bug, or mechjeb is wrong, I don't know. Having them be exact matches would be the icing on the cake.

But as it is now this mod is a very valuable addition to my toolkit. Thanks so much for investing the time to build it.

[togfox]

Loving the dV window. This is what sets this mod apart and if you had just the dV window then I'd be just as happy.

Potential bug: the dV in the VAB is not the same as the dV in the flight window at launch. I have a VERY unorthodox design with complex staging (drop tanks working from bottom up, SRB's firing in bizarre combinations) but despite that, the total dV in design and flight should be the same. VAB reports 4765 and flight reports 5147 at launch. Not sure where the extra 400 dV comes from.

I'll use a very simple design with no staging and test this further. I'll see if I can work out this discrepency. I understand more work *might* be done to account for drop tanks, but even so, the total dV in design and flight should be the same. I'll see if I can uncover anything.

Great mod.

[cybutek]

Strange one... The code doing the all the magic is totally modular and is used for both design and flight. I just give it all the parts of the ship and it does all the sorting and working out. Then I select a stage from it (in flight it will always be the current stage) and pull the data from that. The only differences in practise, is how the parts are chucked into this code. As the editor and in-flight parts of KSP work differently in this regard. (Could be something as simple as it not accounting for the command pod or something silly perhaps?) Going to have to check into this!

[togfox]

Launch clamps a factor? Ill test further.

[togfox]

So, doing some intense testing:

- the Kethane 1m tank is NEVER considered in the VAB and SOMETIMES counted in flight engineer. This explains the dV discrepency.

It's a mod of course and you can't be expected to account for every mod but it might highlight a gap in your generic calculations somewhere.

To test:

command pod

LF tank

Kethane 1m tank

LF engine

Check dV in VAB and flight mode. They'll be different. However, if you place the tank differently then the tank is not considered in flight mode and dV is the same. I suspect it is being cross fed at 'fly time' and is providing extra dV.

Mind you - the Kethane tank is NEVER considered in the VAB. This means the mass is not included and dV is incorrect. Same applies in flight - if it is not cross fed then it does not have weight (according to your mod) so the dV is over stated becuase the tanks mass is being ignored.

But - Kethane is a mod and not a stock part so treat as you will. This took me a solid 40 mins to work out!

[cybutek]

Just had a few minutes spare and took a look at the Kethane source code... Looks as though all the mass is calculated through the plugin, apart from the tank's dry mass which is coded in as 0.25... So the mass in the VAB of the tank should be 0.25 as it only gets updated within flight.

My plugin parses through the ship parts structure only when it needs to, so it does not slow the game down by looping and searching when it is not needed. It is quite possible that some of the time my plugin gathers the parts and looks through them before Kethane has updated and done its thing, so the deltaV is wrong. Sometimes my plugin could run after Kethane has done its thing, so the deltaV is right.

I will go over my code and see if it is possible for me to work around this. A fix for this plugin would of course solve problems with other plugins that work on the same principle.

[antbin]

Hi Cybutek,

Love the new release of the Flight Chip. Have been trying to get a flight to Duna working, but the chip's rendezvous information is hard to understand. For example, the Interplanetary calculator provides me a phase angle, but I can't find the equivalent in the Kerbal Engineer. The 'phase angle' listed for Duna changes with the the KSC launch pad's daily rotation, where to time my orbital rendezvous I need Duna's phase angle relative to my current position and Kerbol.

Is this a planned feature or 'out of scope'?

[cybutek]

Yup, a heliocentric phase angle is planned for the next version... Also there is a slight error in the relative speed directions but it is accurate with regards to magnitudes. The rendezvous system was released in this current version so there's definitely a few quirks to be ironed out, especially for the new planets.

[Nadrek]

Thank you for taking up this amazing mod; I hope you choose to work out complex fuel line based rocket staging. My best designs have an onion shape, and lose fuel tanks (and every 3 sets of tanks, a set of engines) in pairs and quads for the main rocket. Massive booster stages for getting entire interplanetary missions up, well, those aren't as elegant.

[MaverickSawyer]

OK, tried this today in 0.17. No major issues to report during use. This is an excellent tool for use during all phases of the mission. However, could you add an additional feature to the Flight engineer in the next version? I think a Maximum G would be a nice tool. anything over 15 would mean you killed your crew.

[EndlessWaves]

There seems to be some sort of bug with failures, often those on the launchpad. I've noticed when a rocket fails but the pod and flight engineer survive then the flight engineer window can go blank and it interferes with the escape menu making it go invisible. It might be something to do with all parts in a stage getting destroyed as hitting the next stage button fixes it.

I would love to see spaceplane support in flight engineer as that's where I really struggle. Building a working design isn't too difficult but trying to judge the optimum build or flight angle is next to impossible without the numbers. I'm not sure what numbers will ultimately be the most helpful but the lift vector(s) and drag from wings seem like a good start.

Edited September 25, 2012 by EndlessWaves
Clarification

[BloodyRain2k]

What I'd really want to see is not only an engines thrust and weight but also it's fuel consumption. I already looked in the configs but there's nothing, where the hell do they hide that info and why is that important info not in the vanilla tooltip? >.<

It would make choosing the right engine easier, like comparing thrust vs fuel usage vs weight. Though I usually only care about the first two.

I know this is unrelated in that way but would it be possible to make the engineer add that info to the tooltip or display an own one with infos about an engine when hovered over it or such? Dunno if that's possible.

[gosnold]

I can't seem to have correct delta v estimates for stages with not stock engines. The program thinks their fuel consumption is the Isp or something like that. Any chance to see a fix?

[EndlessWaves]

What I'd really want to see is not only an engines thrust and weight but also it's fuel consumption. I already looked in the configs but there's nothing, where the hell do they hide that info and why is that important info not in the vanilla tooltip? >.<

It would make choosing the right engine easier, like comparing thrust vs fuel usage vs weight. Though I usually only care about the first two.

ISP is fuel efficiency. Higher is better, it's independent of thrust amount and it scales linearly - 400 ISP will use 33% less fuel than 300ISP when producing the same amount of thrust.

ISP is given because it makes it simpler to work out DeltaV but I can look up the formula for working out fuel consumption from ISP and Thrust if you want.

Edited September 26, 2012 by EndlessWaves
less is more

[Kellis]

The problem with the delta-v when using vegetablised staging is that I'm going to have to spagettify the code quite a bit... Like the puns? Bad huh

It is definitely something I would like to work on. As like you and everyone else, I also use drop-tanks and vegetarian staging. But because this will be quite an undertaking which will require a lot of thought and time to get my head around .....

Before I get into things - thanks for this plugin - for simple designs, it can be pretty dang useful. For more complex designs, it can still help a lot for upper stages...

That said: Wall-o-text warning... tl;dr calculating delta v and algorithms and math. Hopefully, even, correct math. Maybe.

...I can't believe I'm registering for a forum account just so I can discuss fuel flow and delta v calculation under complex staging situations, but.. ..there you have it.

Anyhow.

To calculate delta v, we need to know just where the fuel is coming from, and when, and when we're decreasing the amount of dead weight we're hauling around. That leads to a few issues that need to be solved.

When do we get rid of dead weight?

We're getting rid of fuel weight all the time - that, alone, is several problems, actually - but we only drop dead weight when we stage - or explode, but it's not like that would ever happen, would it?

So that means we need to know just when each bit of the rocket falls apart. ...assuming no explosions.

Parts look like they're attached to each other as a tree; you can only attach parts to parts that are already attached to other parts, and you can't attach a part between two other parts. So to find out when a part falls off (no explosions!), start from the center of the graph (the command capsule), and work outwards. A part falls off when the decoupler it's attached to falls off. Walk the graph and just assign each part a number based on the highest stage of the decouplers you passed in the graph to get there. It's absolutely possible to stage a decoupler in stage 1 when it's attached to a part that is attached to a decoupler that detaches in stage four. Wishful thinking aside, any parts under that stage 1 decoupler will still be gone in stage four.

So now you can get the stage where anything falls off.

What engines do I need to care about, right now?

Hey - an easy one! Engines first fire in a designated stage and stop being important when they fall off the ship. We care about all the engines that have been staged, and haven't fallen off the ship. They may not be firing because they're out of fuel, but we have to figure out they're not firing to figure out delta v - so we still care.

Where is the fuel coming from at any point in time?

Assuming a graph you can follow around fuel using, providing, and transferring items...to determine where fuel is coming from for a particular engine, start with that engine as the first node on the graph, and start walking.. Here's what my experimentation has shown me regarding fuel flow:

1. If there something attached to this node using fuel line(s), then fuel will arrive via the fuel lines. All of them. If fuel arrives via fuel lines, it will not arrive via direct attachment. So for each part attached via fuel lines (that has fuel), go to that part, and follow this algorithm. Recursion! Yay!
   
2. If you're not receiving fuel via a fuel line, and there is something (with fuel) attached to an attach point, then fuel will arrive via the attach point. If you're using a mod that provides fuel-flow-capable objects with multiple attach points, then fuel will arrive via all of those attach points where there's fuel. Unmodded, this really only applies to fuel tanks, as far as I can see. Again, recursion and track where the fuel is coming from.
   
3. If nothing else is providing fuel, then this node is providing fuel. If it has any.
   

Fuel flow comes equally from all places it's coming from. If I attach two tanks to an engine using fuel lines, then half of the flow comes from each tank. If I attach two tanks to one of those tanks, then there are three tanks fuel is coming from, and equal flow comes from each. I do not split the flow in half from the first point where there are two lines, and then split it again from the second. There are three tanks providing fuel, so each provides one third of the fuel for that engine.

It doesn't matter whether a "node" is an engine or a fuel tank - you can attach an engine directly to a fuel tank, and then run a fuel line from a different (unconnected) tank to the engine. The engine will feed through the fuel line first, and only use the direct-attached tank when the fuel line isn't providing fuel anymore.

If you use a fuel line to pull from the middle of a stack of fuel tanks, you will end up pulling fuel from both ends of the stack. Want a truly delightful experience? Stack three tanks on top of each other. Stick one tank off to the side. Put engines under both the stack and the single tank, and run a fuel line from the middle of the stack to the single tank. Light that sucker off, and look at the flow rates. Single tank? No flow - fuel is being piped in from the stack. Center of the stack? Again, no flow. Bottom of the stack? Half of the flow necessary to fuel the engine over to the side. Top of the stack? The other half of the flow for the other engine, and the full flow for the engine directly beneath. Distance traveled seems to be completely unimportant.

Rocket surgery. What can I say?

Once a tank is empty, it stops providing fuel, of course, and you need to re-calc the graph. When that top tank in this example runs out of fuel, then the middle tank is supplying all the fuel for the stack's engine, and the bottom tank is supplying all the fuel for the engine under the single tank. Fun.

This becomes important when we start caring about how much fuel is coming from where.

Confused, yet?

We're just getting started.

Fuel density

For the stock parts, fuel is an even 200l/kg. (0.005kg/litre; whatever) Not so, unfortunately, for modded parts. Parts specify a full weight, an empty weight, and the litres of fuel that fit. This becomes important, in a bit, because it can really futz with our math..

Fuel flow over I_sp or Modded parts and the amazing changing fuel density

This is a little off-to-one-side, but will become important for calculations... Fuel flow is calculated in litres, and part weight in kg in the VAB. There is no direct relation between these two numbers. Stock parts all have 200 litres to a kg. Mod parts may not. Why is this important? Because the I_sp on the engine is calculated based on the assumption of 200 l/kg. Start using modded parts, and the weight of the fuel changes, and you end up with different actual I_sp.

You can still calculate the flow through an engine based on the provided I_sp, and the fuel flow rate remains unchanged despite the weight of the fuel in question. So it's better, for each engine we're playing with, to know the flow rate per second, instead of the I_sp listed on the part. Oh - and we want to calculate this for both atmos and vacuum.

What information do we have?

I_sp - measured in seconds.

Thrust (F) - measured in Newtons, or kilogram-meters-per-second-squared. (kg*m)/s²

g - gravity; 9.8 m/s²

expected fuel density - 200l/kg

From this, we can get flow rate of litres per second. Eventually. Actually, I've read hints that l/s is provided for the part; maybe I_sp(s) is calculated? If so, that cuts out this little section. If not, though...

From I_sp, we can get effective exhaust velocity - which is I_sp*g. From effective exhaust velocity and force, we can get the burn rate in kg/s. From that, and the expected fuel density, we can get litres per second - even if the density of the actual fuel changes, the litres per second burn rate still holds true.

An example. If you take a 1.125 ton fuel tank and stick an aerospike on it, you'll last about 15 seconds at full burn. How do you math that out, though?

I_sp = 390s, g = 9.8m/s², so effective exhaust velocity = I_sp*g = 3822m/s

That effective exhaust velocity is producing a force of 250N, or 250 kg m / s²..sooo... 250 kgm/s² = ??kg/s * 3822m/s

??kg/s = 250N/3822(m/s) = 0.0654107796...kg/s. Yes; remember that the VAB speaks of kg, not metric tons.

We have 200l/kg, so that little bitty number ends up with: 0.0654107796...kg/s * 200l/kg = 13.08l/s.

Our aforementioned 1.25 ton fuel tank has 200 units of fuel. At 13 per second, 200l / 13l/s = 15.288s.

So the flow rate for any given engine in l/s is (200*F) / (I_sp * 9.8). Plug those numbers in again, just for paranoia. Yup, (200*250)/(390*9.8)=13.08l/s

So we can now find both the atmospheric and vacuum fuel flow rates for any given engine.

Good. We'll need 'em.

Solid Boosters or Hey, look - a simple bit!

Solid boosters are quite a bit simpler. We know right out their thrust, full and empty mass, and burn time. Calculating their burn rate in kg/s is a trivial (full mass - empty mass) / burn time.

The Algorithm or Where the *yay!* is he going with all this, anyway?

Judgement call time. Maybe even two judgement calls.

For any given stage, we need to know whether we should calculate under atmostpheric conditions, or under vacuum conditions. We can try to math that out and come up with current altitude based on expended delta v, mass, g, air density and drag... or we can just ...gently caress the matter and let the user poke a toggle. I vote the latter.

Likewise, we need to know when the user is going to want to eject a given stage. Which is most important? As soon as possible, as long as we don't drop empty tanks? Or maybe wait until no engines will be ejected that still have access to fuel? Another user determined option, perhaps?

Regardless, for a given stage, you have a known current mass (we start with all pieces except launch gantries, perhaps), and a number of engines that could be firing, based on their positions in the staging list.

So. Starting stage is max stage number...

Start loop.

Check to see if we should stage.

• If the user wants to stage as soon as it won't drop fuel, then check all the fuel tanks that will be dropped by staging. If they're all empty, it's time to stage. Decrement stage counter, drop any items that should be dropped, and recalc your current mass.
  
• If the user wants to stage only once you won't kick off any active engines, then find the engines that would be dropped next stage and see whether any of them have fuel. If they're all out of fuel, it's time to stage. Decrement stage counter, drop any items that should be dropped, and recalc your current mass.
  

For each solid fuel booster that should be firing:

• Remember how many seconds of firing remain, and remember or calc mass remaining.
  
• Seconds remaining = (max seconds) - (seconds fired already)
  
• Mass remaining = (empty weight) * (seconds remaining)
  

For each engine that should currently be firing:

• Find out which fuel tanks it's drawing from. See above notes on tracing fuel flow.
  
• Find out how much it's going to draw from those tanks. Essentially, calculate the l/s flow for that engine at full blast and tag each affected tank with that number. Keep in mind that each tank can have multiple engines drawing from it.
  
• When doing this, remember whether you're using atmospheric or vacuum flow rates.
  

For each tank that has engines drawing from it:

• Remember how much fuel it theoretically has - if it's already been used, it's not full any more..
  
• Find out how much fuel is being used per second from that tank - sum up all the tags from the firing engines.
  
• Find out how many seconds of burn are left at this burn rate.
  

For all solid rocket boosters and fuel tanks, find the minimum number of seconds before something is empty.

Drain all affected tanks and rockets by that many seconds, based on the burn rate. Calculate current mass. Clear any tags for the next time through the loop.

Run the rocket equation. Things get just a tiny bit wonky, here, since you don't have a total I_sp for your ship. So calc one. Remember that F = I_sp(m/s) * mass flow rate, so I_sp(m/s) = F / mass flow rate.

Mass flow rate = kg/sec. How much did things weigh before? How much to they weigh now? Divide the difference by the number of seconds this time through the loop, and we have a mass flow rate.

Sum up the forces granted by all active engines, then divide that by our mass flow rate. We now have an I_sp(m/s) to throw into the rocket equation.

dv = I_sp(m/s) * ln(m0/m1).

(or I_sp(s) * g(m/s²) * ln(m0/m1) ..you can calc I_sp(s) from I_sp(m/s) by dividing by g... sooo technically, dv = (I_sp(m/s) / g(m/s²)) * g(m/s²) * ln(m0/m1), but that's just a tiny bit silly.)

That's the dv for this little segment. Now it's back to the top of the loop and do it all over again. Sum up these dv for each stage as you go.

Now isn't that simple?

Mind, I'm not sure it's worth it to you to run something like this, and there's no absolute guarantee my math/algorithm isn't missing a step somewhere, but if I haven't slipped a few gears, I think this is an algorithm to calculate the dv for a complex-staged vessel. Egads..maybe there's a simpler one? Please?

[Analogy]

Apart from figuring out how to work with rockets that use fuel lines, you also need to make it ignore sepratrons.

[cybutek]

Whoa, wall-o'-text indeed ... Wish you came along when I was first putting together all the deltaV stuff, would of been a great help. You've definitely got some good stuff there which I can use. Main problem is that I'm not sure how good the performance will be of this kind of recursive function. Performance is something I've got to keep in the back of my head, running (guessing here) somewhere in the region of n log(n) iterations every frame could get quite demanding. Especially considering that the whole point is for it to help out with huge and complex rockets to begin with

Will work with what you've given me and try to find some less iteratively demanding ways using built-in functions.

P.S. I wish there was more time in every day and I didn't need a real life job. Got an update on the burners as I type this, going to contain a couple small bug fixes (inc. accurate phase angle calculations for new planets/moons). Also if anyone's got accurate gravity parameters for the new planets, it would be very useful so I can plug em into the Build Engineer's Thrust/Weight section for tonight's update.

Gotta dash, my job as a corporate slave in retail beckons me

Edited September 26, 2012 by cybutek

[Kellis]

Whoa, wall-o'-text indeed ... Wish you came along when I was first putting together all the deltaV stuff, would of been a great help. You've definitely got some good stuff there which I can use. Main problem is that I'm not sure how good the performance will be of this kind of recursive function. Performance is something I've got to keep in the back of my head, running (guessing here) somewhere in the region of n log(n) iterations every frame could get quite demanding. Especially considering that the whole point is for it to help out with huge and complex rockets to begin with

Yeah, for something like this, you'd probably want to only calc the numbers at button press during construction. You know - "Hey - what's it look like now?"

And what I scribbled doesn't even get into the whole boosters-with-fuel-lines thing, or circular maps of fuel lines (...ack) or inexact floating point numbers, so you're not really looking for empty tanks with ==0 in the first place, or...

Silly fuel lines, you might at least be able to detect and refuse to try. Encourage smart rocket design, and all.

I'm tempted to see what the API is and what data would be available, and what it would take to throw that sort of algorithm together. The one you're currently using absolutely has simplicity as a virtue.

[EndlessWaves]

KSP seems to use 9.81m/s as gravity rather than 9.8m/s so you get 13.069L/s consumption on the aerospike rather than 13.08L/s. Engines used to be fixed fuel consumption in Litres/second but now solely use ISP - you can check the part folders (cfg files) for the parts and what parameters they have.

The wiki has gravity figures for the new bodies but I don't know how accurate they are:

http://kspwiki.nexisonline.net/wiki/Celestials

Edited September 26, 2012 by EndlessWaves

[BloodyRain2k]

ISP is fuel efficiency. Higher is better, it's independent of thrust amount and it scales linearly - 400 ISP will use 33% more fuel than 300ISP when producing the same amount of thrust.

ISP is given because it makes it simpler to work out DeltaV but I can look up the formula for working out fuel consumption from ISP and Thrust if you want.

Yeah, I've read up about the ISP now (which I should've done before) but I'm none the wiser how to know how much total thrust I get out from the fuel I'm carrying : / Is that this delta V everyone means? XD''

But with the last part you confused me, bigger is better was pretty clear, the example after that was the opposite, unless you meant that 400 ISP will use 33% LESS fuel than 300 ISP for the same thrust x.x

[EndlessWaves]

you meant that 400 ISP will use 33% LESS fuel than 300 ISP for the same thrust x.x

I did, sorry about the mistake.

And yes, DeltaV is essentially the total thrust/range of the rocket.