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

[ajburges]

Any update/fix/workaround for RAPIER engines?

I have an SSTO where the dv display actually goes up as I disable select tank fuel routing! (Pics available upon request)

Since my current design trend is to include an Aerospike on RAPIER designs to smash the sound barrier ASL, I would settle for just being able to drop them from calculations when they are off.

Edited July 29, 2015 by ajburges

[John Nowak]

The thing for determining distance at closest approach is gone, or was that in something different?

Also, Kerbal Alarm Clock.

[smjjames]

Crossposting from MJ since it's a KER issue as well.

While this is more likely a bug origionating from KER since I know MJ uses the same dataset or something (that might not be quite accurate, I just know that MJ uses code from KER), both MJ and KER don't recognize Karbonite as a fuel.

Using build 500.

[Atros]

Any chance of getting the total and partial wing area CL numbers and energy usage and creation when active/partially passive for components and totals?

[pearldrumbum]

Is it possible to copy my settings over from another save? Basically, I created a new install of KSP, and I'd like to get my old Engineer HUD layouts back without rebuilding them. Can I just copy the settings folder, or is there a cfg file I'm missing?

[Red Iron Crown]

Is it possible to copy my settings over from another save? Basically, I created a new install of KSP, and I'd like to get my old Engineer HUD layouts back without rebuilding them. Can I just copy the settings folder, or is there a cfg file I'm missing?

Copying the Settings folder should work, but it's really just one xml file in there that contains your custom layouts (its name is escaping me and I'm not at my KSP computer ATM).

[SquaredSpekz]

some has reposted KER on KerbalStuff, you might want to check it out and deal with it.

https://kerbalstuff.com/mod/1013/Kerbal%20Engineer%20Redux

[gilflo]

It looks like KER is unable to calculate DV remaining on a SSTO in orbit, once RAPIER and Jet engines have been shut down, and you are remaining on LV-N atomic engines?

KER and Mechjeb see 865 DV remaining on my SSTO and I perform a 827DV run to Mun on my Atomic engines that costed me only 145DV out of my 865 remaining.

In fact it remains around 5 times the calculated DV.

[Red Iron Crown]

Share the craft please, gilflo, not much can be done with a vague report like that. I've experienced strangeness with Rapier/LV-N mixes, cycling the engines fixed it in my case. It might also be possible that there is fuel unconnected to the LV-N by fuel lines, KER will give incomplete readings in that case, they change as you transfer fuel around.

[gilflo]

OK. I am just finishing it and I will share on Kerbal X. LV-N are on Fuel tank but there's no fuel lines, I use TAC Fuel balancer during all flight, that's maybe why calculations are false.

Lot of mod also: OPT engines, Karbonite tank, drill and converter, Scansat......

Edited August 5, 2015 by gilflo

[Red Iron Crown]

I can almost guarantee that it's TAC Fuel Balancer combined with tanks with no direct route to the LV-N. LV-N burns fuel from attached tanks, TAC moves fuel in from other tanks.

[gilflo]

Yes, it's easier to have a spaceplane balanced at any time, especially when you manage to build one where Dry CG and full CG are quite similar.

So is there any means, kind of spaceplane version, where KER would consider all fuel and/or Oxy in tanks that are not shut down, and calculate the right DV

[Red Iron Crown]

As far as I know it only calculates for fuel that has a valid route to the engine, it can't really predict when fuel will be transferred from tanks that can't reach to tanks that can (whether manually or using something like TAC FB). To get KER to calculate it you must either connect the tanks with fuel lines or use engines that ignore fuel flow rules (airbreathing engines, or the Rapier in closed cycle mode).

[Wolf Baginski]

It was MechJeb rather than KER, but I've also had weird deltaV calculations on a spaceplane. I was getting infinite deltaV once in orbit. RAPIER engines, but also the Intstell XE-202 scramjet.

From what you say above, it's possible the problems are connected.

I'm using the B9 procedural wings, which are essentially a radially-attached fuel tank. I've had other problems with radial engine mounts. A multi-engine radial mount was awkwardly different when the RAPIERs switched mode. Adding a call to CrossFeedEnabler fixed that. Air-breathing they were OK, closedcycle they ran out of fuel and stopped.

I shall have to test whether using CrossFeedEnabler for the XE-202 changes anything, since it has the radial mount. On the spaceplane I've been testing the intakes and the RAPIERs are stacked. If I have it right, air-breathers use fuel tanks differently from rockets, and that could certainly give some odd deltaV results. It's making me wonder if there's some common code getting confused by the two distinct fuel-flow systems. Is it in KSP or do the two mods happen to use some similar internal code? After all, why reinvent the wheel?

[Wolf Baginski]

Adding CrossFeedEnabler to the XE-202 didn't break anything new, and it did change the weirdness a little, but it didn't cure the problem with deltaV calculations.

So fuel-flow differences may be part of the problem, but other than that I would be guessing.

[LostOblivion]

It seems like there is a bug which causes the drop-down menu of bodies in the editor view of KER to input-mask a part of the editor even when the menu has not been clicked. If you right click to drag the camera around you vessel, the motion stops and other buttons go gray when the mouse is over this ghost area.

[Padishar]

It seems like there is a bug which causes the drop-down menu of bodies in the editor view of KER to input-mask a part of the editor even when the menu has not been clicked. If you right click to drag the camera around you vessel, the motion stops and other buttons go gray when the mouse is over this ghost area.

Yes, I've seen this too though I've never got around to fixing the problem. It should simply be a matter of not doing the input locking stuff when the menu isn't open though it may be complicated by the support for custom solar systems...

[CoriW]

I'm doing a career game right now, and in the beginning I required the Kerbal Engineer part on my craft, but at some point I had forgotten to put the part on my craft and still had the KER info panel... Tested that I didn't require the part anymore and sure enough with just a pod on the pad, and no other parts -- I was still able to see the KER info panel. Is this a bug or does an upgrade to a building or something allow you to have the info without the part? I'm a little confused.

EDIT: Disregard this, apparently I didn't read the OP well enough -- I have a level 3 tracking station which allows KER without the part.

[Tig]

Anyone else having an issue with excessive drag on the chip itself?

I ran a couple of tests with both a MechJeb and KER chip on the ship, I used the MJ for both the autopilot for consistent results and because it displays the total losses on the ship split into gravity & drag losses.

On a small single stage LKO probe, the losses from drag on the chip were in excess of 150m/s dv, which seems like a lot.

Now if I put it in a container, that loss was prevented, (small dv loss due to the extra weight of course).

MJ modules exhibit the exact same behavior, but it is much less of a loss, perhaps because the MJ module has less mass?

This seems strange to me, since both KER and MJ define their parts with maximum_drag = 0.0 and minimum_drag = 0.0.

I don't believe any of my mods would be changing aerodynamics or those parts (not running near, far, etc). Anyone else seeing this behavior? Or maybe I'm just misunderstanding what maximum_drag really does, I assumed it would make the part essentially invisible to the drag system by setting those to zero...

[BudgetHedgehog]

This seems strange to me, since both KER and MJ define their parts with maximum_drag = 0.0 and minimum_drag = 0.0.

Those cfg values are, as of KSP 1.0 unused. In stead, the game calculates a parts shape automatically and assigns a drag cube to it. These are the drag cubes for KERs parts:

PART
{
	url = KerbalEngineer/Parts/Engineer7500/part/Engineer7500
	DRAG_CUBE
	{
		cube = Default, 0.2473499,0.9958926,0.2092445, 0.2483356,0.9259904,0.1785163, 0.07118542,0.9374977,0.2245481, 0.07118542,0.947473,0.5290721, 0.09238428,0.913208,0.433746, 0.09238428,0.9737182,0.2975699, -0.01382188,0.01758459,0, 0.1731282,0.5843801,0.4430536
	}
}
PART
{
	url = KerbalEngineer/Parts/EngineerChip/part/EngineerChip
	DRAG_CUBE
	{
		cube = Default, 0.01638621,0.9574983,0.330694, 0.01638621,0.9598562,0.2212557, 0.1645844,0.9880887,0.1310383, 0.1653374,1,0.09951028, 0.01599753,0.9719145,0.204602, 0.01599753,0.9565312,0.3259358, 0.001806375,-0.009674875,-0.0005987473, 0.4066688,0.05123883,0.4066688
	}
}

Those numbers mean various things, but the good news is, for rectangular boxes, they're usually pretty accurate. 150m/s isn't that big of a loss, really - you could easily gain it back with a different ascent profile, or you could lose that and more on a poor one (yes, I know you use MJ for launches, but still).

[Tig]

Those cfg values are, as of KSP 1.0 unused. In stead, the game calculates a parts shape automatically and assigns a drag cube to it. These are the drag cubes for KERs parts:

Ahh, thanks much, I'll look into that further.

Those numbers mean various things, but the good news is, for rectangular boxes, they're usually pretty accurate. 150m/s isn't that big of a loss, really - you could easily gain it back with a different ascent profile, or you could lose that and more on a poor one (yes, I know you use MJ for launches, but still).

Well in the meantime I setup a test to see exactly what kind of loss we're talking about, it's fairly significant...

Craft 1:

2445 kg

3810 dv (atmospheric at alt 0.0)

Surface TWR at launch 1.34 (rises to 1.4 within 5-6 seconds due to the light craft weight)

MJ and KER chips inside of a Service Bay

Craft 2:

2433 kg

3853 dv (atmospheric at alt 0.0)

Surface TWR at launch 1.34 (rises to 1.4 within 5-6 seconds due to the light craft weight)

MJ and KER chips attached to the body of the ship

Here is an album for anyone interested:

Javascript is disabled. View full album

Both flown with MJ's autopilot for consistency (i normally like to fly my own craft ), limited to 19 m/s acceleration, at 35km acceleration limiter turned off. Gravity turn started at 110 m/s, ascent path 50 degrees.

Craft 1 w/service bay:

At 90 seconds after launch, Pure drag loss is 3.4 m/s^2.

At orbit gravity loss is 1291 drag loss is 359

Remaining dv at orbit is 269 m/s

Craft 2 w/chips attached to body:

At 90 seconds after launch, Pure drag loss is 6.6 m/s^2.

At orbit gravity loss is 1369 drag loss is 553

Remaining dv at orbit is 43 m/s

TLDR: Putting a KER chip on the outside of a ship reduced dv at orbit by ~270 dv. (The difference between the 2 ending orbit dv and the starting dv). That seems like an enormous loss for a thin 5kg chip on the side of a craft imho... should that be happening? Am I just completely ignorant on aerodynamics? Totally willing to admit if I'm wrong, just seemed like a lot to me.

----

PS. Obsessed, you're completely correct a different ascent profile can have a profound effect, that said I tried to find numbers that were efficient enough and worked with MJ. For example with a shallower ascent profile at 45 degrees (reduced 5 degrees), lowering the acceleration to 14 m/s, gravity turn at 75m/s, the crafts don't even make orbit. Other tests (16m/s, 48 ascent, 90m/s turn) just led to lower numbers remaining dv in orbit. I know MJ isn't perfect, but like I said... more about the consistency for testing purposes rather than ideal flight paths.

PSS. The same effect happens with a MJ chip on the side of the ship, but to a much lesser extent, and it becomes almost negligible if the MJ chip is tweakscaled down a step. Not sure if it is because of the mass being 1/50th of the KER chip or because of the "drag cube" I'll try to test that next time.

PSSS. To anyone wondering why I put the chips on Craft 2 on the rear end of the craft by the engine... i was testing whether putting them on the side versus underneath the tank would make a difference. My thought process was that the tank might shield the chips from creating drag. Short answer: Nope.

[Red Iron Crown]

I just turn on partless mode so this is never an issue. The chip part is vestigial for me.

[Tig]

Just did a quick test lowering the mass of the KER chip from .005 to .0001. Basically no effect, slightly higher dv at the end, but only due to the mass reduction (about 20 additional dv at launch and at orbit).

@RIC, yeah that's a good point, I put KER on all my ships as well, and I thought about doing that. Perhaps my bigger concern is with how this will play out with all parts, e.g. does putting a thermometer on the side lower my dv by 150? idk yet.

Edited August 23, 2015 by Tig

[Jumpyyoza]

Just out of curiosity, can anyone upload the formula used for the calculations?

[Padishar]

Just out of curiosity, can anyone upload the formula used for the calculations?

Which calculations?