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

[jfrouleau]

Hi, I was building a rocket yesterday and wondered how to design a vessel with optimal staging. While having each stage delta-v is very useful, I never know when it's better to raise delta-v by using a bigger stage (tank + engine) or to add another stage. I think the optimal way may be to have the biggest delta-v with the less possible mass because we know that the more mass you have on your upper stages, the bigger the lower stages have to be to lift them off. So I have a suggestion for this mod if it's possible to implement it : having a delta-v to mass ratio displayed for each stage. The bigger the number, the more efficient the stage is for its weight in its current staging configuration. What do you guys think ? Would it be useful ? Or maybe there is a better way to do this.

[BudgetHedgehog]

I have basically hacked around a bug in TweakScale.

Interesting stuff. Hopefully when Biotronic comes back, he'll fix this (if possible) so it won't happen again. Thanks for the reply!

And also, bug report time! It appears that having a deactivated engine in the current stage will return 0 for current dV, ISP and mass (along with the total dV not updating).

Javascript is disabled. View full album

(Tested on stock 0.24.2 + KER 1.0.9.1. Easily reproducible so I won't include the craft or save here)

I remember a similar bug (activated/dead engines in non-current stage = broken VES tab) during 0.6.2.X developments - maybe it's related?

Edited September 18, 2014 by ObsessedWithKSP

[Padishar]

Interesting stuff. Hopefully when Biotronic comes back, he'll fix this (if possible) so it won't happen again. Thanks for the reply!

And also, bug report time! It appears that having a deactivated engine in the current stage will return 0 for current dV, ISP and mass (along with the total dV not updating).

http://imgur.com/a/2nVHb

(Tested on stock 0.24.2 + KER 1.0.9.1. Easily reproducible so I won't include the craft or save here)

I remember a similar bug (activated/dead engines in non-current stage = broken VES tab) during 0.6.2.X developments - maybe it's related?

Well, it is, sort-of, related but your vessel, with the staging set up like that really doesn't make sense. KER should be simulating the engines that are currently active (until all engines stop burning) and then run the normal staging process. I would expect the "current" to consist of the bottom engine burning all of its fuel, S1 to basically be skipped as nothing "important" is dropped by S0 and S0 be the top engine burning its fuel. However, in this case it seems to be skipping the "current" stage and going straight into activating stage 1. Any chance you can upload the craft file so I can take a closer look (or I'll knock up a duplicate a bit later)...? Incidentally, am I right in assuming the lander can is the root part of the ship?

[BudgetHedgehog]

Well, it is, sort-of, related but your vessel, with the staging set up like that really doesn't make sense. [...] Incidentally, am I right in assuming the lander can is the root part of the ship?

I know, that's just a replica to show it. It happily appears on stuff like spaceplanes (all engines are in lowest stage, switch between them with action groups). Or any time after docking two crafts together that the engines end up in different stages.

Yes, the lander can is the root part. The craft is easy enough to replicate - lander can, fuel tank, engine, decoupler, fuel tank, engine. I only put the RTGs and girders on because I'm paranoid.

[LostOblivion]

I love what you've done with the mod adding all this info. I have only two requests, and that is to make it less obtrusive when not having KER open. I'd like to see all info hidden when it's not open, like hiding the bottom left dialogues and hiding the tool tips, only showing them when KER is open.

Also, I think having to click the middle mouse button every time I hover over a new part to show its info is not good. Only showing its name doesn't make sense and I think it would be better if you showed everything once you hover like a few versions ago. Hiding the tooltip if KER is not open solves this problem in a better way.

Sincerely, Lost

[Drew Kerman]

I'm helping Arrowstar (KSPTOT/Mission Architect) work out some apparent issues with the Longitude reporting in his application. It seems to be off for some bodies, but not for others. During testing I've used VOID, Engineer and SCANSat to give me readouts and have checked them all against each other at periapsis crossing. Well, here's my check of Duna:

This is one of the planets Mission Architect got right - it told me my craft would be passing over 138E Lon at periapsis. Both VOID and SCANSat concur. But Engineer tells me I'm at -221 Lon, which makes no sense as longitude only goes to 180 in the game. I only sampled Duna, Eve, Laythe and Eeloo this was the only mis-read I saw

[cakepie]

They're equivalent.

360 - 221.53556 = 138.46444

Edited September 18, 2014 by cake>pie
typed too fast, one digit short

[cybutek]

I have to admit that the longitude and latitude readouts really need a bit of work done with them. Right now they're just pumping out whatever KSP is giving it, which as you've probably noticed can sometimes require doing a little mental gymnastics (or calculator usage) to make sane. KER 1.x is in alpha, feature incomplete and this is one of the bits that requires some polish. I'll try to give it a shine in the next update

[Arrowstar]

Hi guys,

Author of KSP TOT here. Can you guys show me where in the Engineer code the spacecraft latitude/longitude is computed? As Gaiiden mentioned, there are some discrepancies between my software and KER. I hesitate to change my code because I appear to match what KSP computes in the SFS file, and because I don't understand the source of the differences. Any help you could provide would be great.

Thanks!

[Drew Kerman]

For additional reference, the post where I expose some discrepancies between KSP TOT and Engineer, VOID and SCANSat is here. The real oddity is that it's not always wrong...

[zeMightyOuiche]

Hey, got a bug (maybe ?) to report

KER does not take into account the weight and the impact on the deltaV of a few parts (Commutron-16 antenna, both RCS thrusters, the static solar panel and all the radial-attached batteries). Is this normal, or will I end with less deltaV than I expected ?

Anyway, thanks for this mod, great work !

[dzikakulka]

Hey, got a bug (maybe ?) to report

KER does not take into account the weight and the impact on the deltaV of a few parts (Commutron-16 antenna, both RCS thrusters, the static solar panel and all the radial-attached batteries). Is this normal, or will I end with less deltaV than I expected ?

Anyway, thanks for this mod, great work !

It's quite possible KER does recognize physical insignificant parts which is good and these won't have impact on your deltaV

[Padishar]

It's quite possible KER does recognize physical insignificant parts which is good and these won't have impact on your deltaV

Indeed, all the parts you mention (and some others such as ladders and most of the radial attached science experiments) do not have physics simulated during flight and hence actually have no mass despite what the part descriptions say. KER doesn't include their mass in the calculations which results in correct calculation of deltaV.

[zeMightyOuiche]

It's quite possible KER does recognize physical insignificant parts which is good and these won't have impact on your deltaV

Oh, I absolutely didn't know about that, thanks !

That's good for me, I would have had 30% less deltaV on the satellite I am designing

[SirJodelstein]

is it possible to configure this to work with KIDS (Kerbal ISP difficulty scaler) and the "ISP reduces thrust" setting? KER correctly recognizes the modified ISP values, but the atmo thrust/TWR readouts in the VAB are wrong.

KIDS has an option that corrects the behaviour of engines under atmospheric pressure: Instead of "same thrust, higher fuel consumption" (stock), the fuel consumption is the same, and the thrust is reduced accordingly to produce the ISP value of the engine.

[Padishar]

is it possible to configure this to work with KIDS (Kerbal ISP difficulty scaler) and the "ISP reduces thrust" setting? KER correctly recognizes the modified ISP values, but the atmo thrust/TWR readouts in the VAB are wrong.

KIDS has an option that corrects the behaviour of engines under atmospheric pressure: Instead of "same thrust, higher fuel consumption" (stock), the fuel consumption is the same, and the thrust is reduced accordingly to produce the ISP value of the engine.

I'll have to take a look at KIDS to make sure but this sounds exactly the same as what RealFuels does so it should be pretty easy to make it work. Just need to find out how best to detect KIDS being installed and test if the setting is enabled...

I presume the thrust/TWR readouts during flight are correct.

[brusura]

I guess there is no option to add an estimated node burn time to compensate the stock one, you know when you trust lower than 100% or load a save the timer on burn time is wrong.

Something like node burn time at max thrust , all the data is already there afterall

Edited September 20, 2014 by brusura

[SirJodelstein]

I'll have to take a look at KIDS to make sure but this sounds exactly the same as what RealFuels does so it should be pretty easy to make it work. Just need to find out how best to detect KIDS being installed and test if the setting is enabled...

I presume the thrust/TWR readouts during flight are correct.

Maybe (if you cannot detect if the setting is used) just add an option to KER to use the alternative calculation? And yes, the in-flight readouts are correct.

[inigma]

Hello!

I wanted to invite you cybutek to a discussion on a mod list I'm testing. Let me know in that thread if you would be interested in helping test other listed mods with yours, or if you already have.

Inigma's KSP Essentials Mod List

http://forum.kerbalspaceprogram.com/threads/94353-WIP-Inigma-s-KSP-Essentials-Mod-List-%28in-Testing%29

[gilflo]

I noticed that when one window is open with the Kerbal engineer redux 1.0.9, the game is awfully lagging....As soon as I close the window it runs normal speed.

It's the vessel window that slow up very much the game...

Any feed back about that?

[cybutek]

I noticed that when one window is open with the Kerbal engineer redux 1.0.9, the game is awfully lagging....As soon as I close the window it runs normal speed.

It's the vessel window that slow up very much the game...

Any feed back about that?

This is caused because of the underlying vessel simulation logic required for the readouts used under that section. It runs perfectly fine on most machines but given a large enough vessel or a computer lacking in power, this can slow down. There is a readout under the miscellaneous category for solving just this problem, it allows you to adjust the delay between vessel simulations. Install this readout into any section and adjust it until it doesn't cause lag.

[gilflo]

OK thank's, but I don't find this read out on Curse, nor on Github

Edited September 23, 2014 by gilflo

[Nori]

OK thank's, but I don't find this read out on Curse, nor on Github

He didn't mean install as in a new file to install. What you are looking for is editing the window from within the game and adding the sim delay portion to your vessel readout.

You can simply do this by clicking edit at the top of the vessel readout. Then click the dropdown and select vessel and add the sim delay portion.

[gilflo]

Hi Nori, thank you!

[Drew Kerman]

I have to admit that the longitude and latitude readouts really need a bit of work done with them. Right now they're just pumping out whatever KSP is giving it, which as you've probably noticed can sometimes require doing a little mental gymnastics (or calculator usage) to make sane. KER 1.x is in alpha, feature incomplete and this is one of the bits that requires some polish. I'll try to give it a shine in the next update

I pointed Arrowstar to this document on KSP physics from the Tutorials forum which includes Lat/Lon calculation and his response was

Ah! So that document actually doesn't compute the longitude correctly because it assumes that inertial X is aligned with body X at t = 0. That's not the case for most KSP planets and moons. If that's what SCANSat and the others are using, then it would appear there is a flaw in their code.