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

[Padishar]

@Caswallon, yes, it's this pull request on Cybutek's repo:

https://github.com/CYBUTEK/KerbalEngineer/pull/105

 

[Soaperior Soap]

When is this mod coming out for KSP 1.2?I REALLY need it

[monstah]

37 minutes ago, Soaperior Soap said:

When is this mod coming out for KSP 1.2?I REALLY need it

If you look in the signature in the post just above yours, in bold large letters, you'll see a link to a development version that's working just fine.

Please don't bother modders for updates before checking if that hasn't been asked for already, or if it isn't in development already.

[Fwiffo]

I've been using the dev builds of KER for a while; they're pretty good.  I realize there may still be one or two rough edges, but just out of curiosity, what big milestone are we awaiting right now until this gets considered out of "beta" and published to CKAN, etc?

[Padishar]

1 hour ago, Fwiffo said:

I've been using the dev builds of KER for a while; they're pretty good.  I realize there may still be one or two rough edges, but just out of curiosity, what big milestone are we awaiting right now until this gets considered out of "beta" and published to CKAN, etc?

Well, I'm not aware of any remaining serious problems caused by the KSP 1.2.x updates so I'll probably recommend to Cybutek that he looks at merging it and doing an official release shortly after the KSP 1.2.2 release which should be happening soon (it was announced as being in experimentals last Friday).

There are still various new features, optimisations and other tweaks that I have planned but they shouldn't need to delay the release...

[Tyko]

Question about Suicide Burn calculations. There's the Suicide Burn altitude readout - which i thought meant "fire full throttle at this altitude to avoid dying" - but every time I try using that, even padding by 10% or so, ends up with loss of life and equipment.

Am I using it wrong or is this something that's still being worked on?

[Confusador]

2 hours ago, Tyko said:

Question about Suicide Burn calculations. There's the Suicide Burn altitude readout - which i thought meant "fire full throttle at this altitude to avoid dying" - but every time I try using that, even padding by 10% or so, ends up with loss of life and equipment.

Am I using it wrong or is this something that's still being worked on?

You're probably using it wrong... it took me a while to realize that the KER SB calculation only accounts for vertical velocity.  Just get your horizontal velocity to zero before that height and you should be fine.  It's not ideal - indeed it's one of the two things that keep making me think about learning this code base - but it's still more efficient for me than trying to eyeball the full retro burn.

[StahnAileron]

3 hours ago, Tyko said:

Question about Suicide Burn calculations. There's the Suicide Burn altitude readout - which i thought meant "fire full throttle at this altitude to avoid dying" - but every time I try using that, even padding by 10% or so, ends up with loss of life and equipment.

Am I using it wrong or is this something that's still being worked on?

I think it assumes you burn straight down (I.e. toward the surface of the planet). Are you burning retrograde to land? If so, you're (probably) using part of your DV/thrust for horizontal compensation instead of purely vertical thrusting. (I said "possibly" since retrograde can be vertically down...)

I'm not sure if the suicide burn readout takes into account horizontal velocity. You want to negate that as well unless you're landing on a giant flat plain on wheels.

You could test this out by zeroing your horizontal velocity beforehand; very DV-intensive though.

[Tyko]

11 minutes ago, StahnAileron said:

I think it assumes you burn straight down (I.e. toward the surface of the planet). Are you burning retrograde to land? If so, you're (probably) using part of your DV/thrust for horizontal compensation instead of purely vertical thrusting. (I said "possibly" since retrograde can be vertically down...)

I'm not sure if the suicide burn readout takes into account horizontal velocity. You want to negate that as well unless you're landing on a giant flat plain on wheels.

You could test this out by zeroing your horizontal velocity beforehand; very DV-intensive though.

That could very well be. I usually come in at at least a 45 degree angle to the ground which means lots of horizontal velocity. Thanks for the tip. 

Is there a readout in KER that helps with suicide burns and accounts for horizontal velocity?

[Warezcrawler]

2 hours ago, Tyko said:

That could very well be. I usually come in at at least a 45 degree angle to the ground which means lots of horizontal velocity. Thanks for the tip. 

Is there a readout in KER that helps with suicide burns and accounts for horizontal velocity?

Nope... But if you are at 45 degrees, then expect something like double height... At 45 degrees your vertical and horizontal speed is the same... I use the readout of horizontal and vertical speed as well when landing...

Pure suicide burn is risky business, esspecially when the planet is not as flat as minmus flats.....

[Padishar]

3 hours ago, Tyko said:

Is there a readout in KER that helps with suicide burns and accounts for horizontal velocity?

36 minutes ago, Warezcrawler said:

Nope...

Or, slightly more accurate, not yet.  There is this pull request that adds readouts that use considerably more complex calculations.  Given the release of KSP 1.2.2 will probably be a little longer, I may try to release a test version that includes this code later today as, if it gets tested in the wild (and works well), Cybutek may be more inclined to include it in the next release...

 

[Wyzard]

On 11/28/2016 at 5:21 AM, Padishar said:

I may be adding the ability to totally disable the tooltip separately to the panels at the bottom fairly soon but am unlikely to make this configurable.

I'd be interested in this.  I don't have middle-click issues, but the tooltip gets in the way visually and I'd like to be able to turn it off but keep the panels at the bottom.

[gilflo]

Hello

I have a request: Is it possible to get an option with horizontal speed in knots, height in feet, vertical speed in feet/mn and the distance in Nautical miles ?

That's because it is very useful for plane as when you are a on descent path for landing, as there is no wind in KSP, when you know your distance from touch down point there is a simple relationship between these 4 indicators that can make you sure to reach the ground on your touch down point: A HUD with this 4 indicators in these units will be great for airplanes

Here is the relationship:

1/Calculate your descent path: Height in hundred of feet/Distance in NM gives path in degrees : 3000ft and 10NM gives 30/10=3° . You descent from 300ft every NM

  3° is 5% (1% is 0.6°) and is the commun glide path in aviation

2/Calculate your VS with a given approach speed to stay on path: Speed in kts X Path in % gives VS in ft/mn: At 100kts, to stay on a 5% descent path your VS must be 500ft/mn. At 140 kts it should be 700ft/mn

So with a height and a distance from TCH down point you can calculate a path and a vertical speed to stay on this path at a certain speed. If you keep speed and VS on this path you will be sure to land on runway on touch down point or very near from it. You do not need any ILS.

It you are to high or to low, with a quick mental calculation you can correct your VS to  be on ground at touch down point

[Padishar]

8 hours ago, Padishar said:

There is this pull request that adds readouts that use considerably more complex calculations.

Actually, the calculations aren't as "more complex" as I thought.  The readouts, as they stand, while making it possible to do pretty accurate suicide burns, do still have some accuracy issues and need you to understand what the readouts mean so you watch the correct one to know when to start the burn.  I would recommend that you watch the video mentioned in the pull request linked above.

In any case, here is version 1.1.2.7p including these changes for testing.  This is built from my withpr95 branch.  Issues with these new readouts, ideally, should be added to the author's pull request, but if you don't have a GitHub account then post them here.  I anticipate that another readout that gives "time to start of suicide burn" will be requested.  This should be reasonably easy to approximate from the other values calculated...

1 hour ago, gilflo said:

I have a request: Is it possible to get an option with horizontal speed in knots, height in feet, vertical speed in feet/mn and the distance in Nautical miles ?

I can see the attraction.  The easiest way to implement it is probably to simply add four new readouts that give these values in these units rather than implementing a general system to change the units displayed.  I have a couple of questions though. First, what should the distance be to, a target (e.g. a beacon at the start of the runway) or something else?  Second, what should be used for 0 height, sea-level (messes up nice calculations if landing spot is at high altitude), current terrain altitude under vessel (inaccurate if ground is not level on approach) or the height if the same thing the distance is measured from (this sounds best to me)?

[Jackelmyer]

Hey guys,

I'm a fairly new KSP player and have been playing purely stock for a while now (ignore the conflicts of this statement pls) .  This Mod seems to be the best mod I've noticed in various videos at combating the ever challenging balance of "I'm playing a Game" and "I've started a new job by playing a game...".  

 

Just wondering if I should wait for the final release of this Mod for the 1.2.1/1.2.2 KSP version or if I should go ahead and pull the Dev version.  Any suggestions/insights?

Edited December 1, 2016 by Jackelmyer

[monstah]

2 minutes ago, Jackelmyer said:

Just wondering if I should wait for the final release of this Mod for the 1.2.1/1.2.2 KSP version or if I should go ahead and pull the Dev version.  Any suggestions/insights?

The dev version works just fine. I think they have some problems with calculating dV when using one of the fancy new fuel flow modes, but otherwise go right ahead.

[Jackelmyer]

7 minutes ago, monstah said:

The dev version works just fine. I think they have some problems with calculating dV when using one of the fancy new fuel flow modes, but otherwise go right ahead.

Thanks Monstah!  As I'm using all Stock otherwise, is this fancy new fuel flow mode something that I'll run into?  Honestly, other than fuel lines, I don't really know what "fancy fuel flow modes" means. :-/

 

Thanks again!

[Superfluous J]

4 minutes ago, Jackelmyer said:

Thanks Monstah!  As I'm using all Stock otherwise, is this fancy new fuel flow mode something that I'll run into?  Honestly, other than fuel lines, I don't really know what "fancy fuel flow modes" means. :-/

 

Thanks again!

If you turn them on in game settings, you can set each tank's priority level. Even if you don't do that, you can enable fuel flow through radial decouplers which can have unexpected results (Like engines still burning even though it *appears* that their fuel tank are totally out of fuel).

As this is all new, KER must be coded to take it all into account for dV calculations.

[Jackelmyer]

Ooooh.  I do tweak decouplers enable/disable fuel flow option on occasion.  Haven't seen those unexpected results, but it's great to know!  I assume if you got nudged by such a bug, you'd actually have more dV than stated by KER right?  Not... a bad thing... per say...  Or am I being brain dead?  

 

The help and info is much appreciated!

(Thanks put on do..loop..) 

 

[monstah]

8 minutes ago, Jackelmyer said:

Ooooh.  I do tweak decouplers enable/disable fuel flow option on occasion.  Haven't seen those unexpected results, but it's great to know!  I assume if you got nudged by such a bug, you'd actually have more dV than stated by KER right?

I don't think it's that easy to say. It will probably depend on the direction of fuel flow relative to which engine is the most fuel-hungry. Best is do to test drives for designs you're not sure about.

[gilflo]

20 hours ago, gilflo said:

Hello

I have a request: Is it possible to get an option with horizontal speed in knots, height in feet, vertical speed in feet/mn and the distance in Nautical miles ?

That's because it is very useful for plane as when you are a on descent path for landing, as there is no wind in KSP, when you know your distance from touch down point there is a simple relationship between these 4 indicators that can make you sure to reach the ground on your touch down point: A HUD with this 4 indicators in these units will be great for airplanes

Here is the relationship:

1/Calculate your descent path: Height in hundred of feet/Distance in NM gives path in degrees : 3000ft and 10NM gives 30/10=3° . You descent from 300ft every NM

  3° is 5% (1% is 0.6°) and is the commun glide path in aviation

2/Calculate your VS with a given approach speed to stay on path: Speed in kts X Path in % gives VS in ft/mn: At 100kts, to stay on a 5% descent path your VS must be 500ft/mn. At 140 kts it should be 700ft/mn

So with a height and a distance from TCH down point you can calculate a path and a vertical speed to stay on this path at a certain speed. If you keep speed and VS on this path you will be sure to land on runway on touch down point or very near from it. You do not need any ILS.

It you are to high or to low, with a quick mental calculation you can correct your VS to  be on ground at touch down point

 

18 hours ago, Padishar said:

 

I can see the attraction.  The easiest way to implement it is probably to simply add four new readouts that give these values in these units rather than implementing a general system to change the units displayed.  I have a couple of questions though. First, what should the distance be to, a target (e.g. a beacon at the start of the runway) or something else?  Second, what should be used for 0 height, sea-level (messes up nice calculations if landing spot is at high altitude), current terrain altitude under vessel (inaccurate if ground is not level on approach) or the height if the same thing the distance is measured from (this sounds best to me)?

Yes, it's simply to add 4 new reads out.

The target can be whatever point you need, you just need the coordinate of the point where you want to touch down and its altitude: it can be the runway start or a point you designed on the ground, when you want to land out of a runway, where you have enough place to perform a landing run. The waypoint manager mod allows the selection of any point on any planet but gives the distance to target in km and it also give you the path in degree depending on your altitude. The distance to target must be the horizontal distance.

The the height must be the height over the point if you want your path to be correct. So your indicated altitude must be your sea level altitude minus the height of the target point.

The ground may be not level in approach, that's not a problem if you know your altitude to your target . Then if there is slope on your landing site it's up to you to perform a good flare to land.

The last thing that could be great, but it's not a KER implementation , would just be an HUD line, which iss just a visual indication (through windshield), that shows you the touch point on the ground. That's the visual approach help on aviation HUD that you can see  through your windshield. it is just the projection on ground of your speed vector, which is continuously calculated with the the settings i explained. In the real world you have to integrate the wind effect, so calculations are much more difficult.

Here, with no wind, it's more simple, if i take the example I gave on your 5% path with 100kts and 500ft/mn, if you maintain strictly this setting your HUD line should be on your target touch point. Let's say you take 400ft/mn somewhere on your path, your touchdown point will be behind the target and your HUD line will show you your new touchdown point on the ground. Same if your increase your speed, but keep 500ft/mn, you will be on a higher path.

So this HUD line can help you to maintain your path settings, without looking at the values, you just have to look at the line projection on the ground. In the example,  if your line goes behind the target, that means you are going to high on your path, because you have lowered your VS, so you push on your stick, to align the HUD line with the target, but by the time it will increase your speed, so you will have to correct it also...

To keep a path, knowing horizontal distance and altitude, you just need to adapt your speed to your VS or your VS to your speed, you just have to coordinate stick and throttle.

I hope it's clear enough.

[Red Iron Crown]

21 hours ago, gilflo said:

Calculate your descent path: Height in hundred of feet/Distance in NM gives path in degrees : 3000ft and 10NM gives 30/10=3° . You descent from 300ft every NM

  3° is 5% (1% is 0.6°) and is the commun glide path in aviation

I would greatly prefer that KER not include inaccurate math like this. It would be better for it just to calculate glide slope correctly for you.

[Padishar]

In the interest of (hopefully) removing confusion about the fuel flow changes in KSP 1.2.x, I will describe the main differences here:

• Neither fuel lines or node attachments now have priority for providing fuel to a part.  Pre 1.2, fuel lines were always scanned first and if any fuel line managed to provide fuel then the scan would stop. If they didn't provide fuel then it would go on to scan the node attached parts, then the part itself and finally, a surface attached parent.  Post 1.2, priority is handled completely differently (see below) and fuel lines have no effect other than allowing fuel to flow between two parts that don't have a direct, crossfeed enabled, connection.
• Fuel can now flow both ways between a part and a surface attached child.  Pre 1.2, a part would never draw fuel from a surface attached child part.  A part surface attached to its parent could draw fuel from the parent but only after fuel lines and node attached parts had provided all their fuel and only if the part had crossfeed enabled and the part wasn't an enabled tank for the type of fuel.  Radial decouplers had their crossfeed enabled so they would draw fuel from the parent tank (usually) they were attached to but a fuel tank attached to the decoupler wouldn't be able to draw fuel from it due to being a fuel tank.  Post 1.2, fuel will happily flow both ways across a surface attachment, only being prevented by the crossfeed setting on the parts.  This is why, in 1.2, the boosters on your old asparagus designs (or new ones that don't use fuel lines) no longer stop burning when the fuel in the boosters runs out.  You need to explicitly disable the crossfeed on the radial decouplers and still use fuel lines (to get a one way flow across the decoupler) rather than trying to use the new priority mechanisms to control the flow.

Basically, the way the fuel flow now works is that it follows all part connections subject only to their crossfeed settings and adds all the parts to a list.  It then draws the fuel from all the parts that share the highest priority number (and have some fuel).  E.g. if an engine can draw from 4 tanks with priorities 0, 1, -10 and 0 then it will initially draw the fuel only from the tank with priority 1.  Then it will draw from the two tanks with priority 0 and finally it will draw from the tank with -10.  When drawing from multiple tanks simultaneously, it will drain proportionately to the amount of fuel in each tank, e.g. if you have two tanks containing 10 and 90 units and something draws 10 units, the old system would draw 5 units from each but the new system (the _BALANCE modes, specifically) will draw 1 unit from one and 9 units from the other.  The only ways you can affect it are:

• Adjust the priority offset of the tank in the advanced tweakables.
• Change the stage the tank is considered in (the base priority is 10*stage, a tank that never decouples from the root part is considered in stage -1).
• Change the crossfeed setting of parts or insert crossfeed disabled parts between other parts.
• Add fuel lines to create one way connections between otherwise disconnected parts.
• Change to a non _BALANCE flow mode to restore the "equal amount from each tank" behaviour.  This should work, in theory, but needs to be done in the engine's config (or possibly using a TweakableEverything type mod).

This system is much easier to understand than the old system was but it isn't directly compatible and you may need to tweak more advanced vessel designs (both planes and rockets) to make them behave the same as they used to...

3 hours ago, gilflo said:

The distance to target must be the horizontal distance.

I know your intent is for landing approach so things are generally flat, but it should really also work when you're a significant way round the planet where "horizontal distance" isn't well specified.  I presume you actually mean great-circle distance at the altitude of the target point.  A bit picky, but when there is significant curvature it will be quite a difference...

3 hours ago, gilflo said:

I hope it's clear enough.

Well, if I'm reading it right, then it's going to be some kind of target point, usually near the start of the runway.  I'll initially implement it just reading the normal target (with a beacon vessel) and see how that works but I'll also investigate Waypoint Manager and see if that can provide a point to use (e.g. if there's an easy way to read the next waypoint location from another mod then I can probably use that).

2 hours ago, Red Iron Crown said:

I would greatly prefer that KER not include inaccurate math like this. It would be better for it just to calculate glide slope correctly for you.

Don't worry, KER won't be doing any inaccurate maths.  It'll just be providing a number of readouts using different units that real pilots are used to using for quick mental maths.  Adding a calculated current glide slope readout (and slope to target) would also be a good idea.  Would it be best as an angle (e.g. 3°) or as a ratio (e.g. 1:20), or even switchable by clicking on it...?

Edited December 2, 2016 by Padishar

[Red Iron Crown]

@Padishar Maybe degrees and percent? If you can only do one percent is probably more useful, doesn't require trig in one's head. 

Edit to add: The distance and altitude used for the calulation should be the vertical height and horizontal distance to the target, not the slant distance and reference or AGL altitude.

Edited December 2, 2016 by Red Iron Crown

[Bit Fiddler]

for the glide slope value I would not make it a set number.  let the user define the wanted slope based on a per use basis.  just set a value on some UI control and it will use it.

 

EDIT:

oh I think I misread the post.  you do not mean set it to 3 degrees, you mean just the units to display it in, no matter what the actual value is?  in this case I would make it click to change so it can be cycled between degrees, ratio, percent (3°,1:20, 0.05) thus no matter what the user likes to see it is there.

Edited December 2, 2016 by Bit Fiddler