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

[iFlyAllTheTime]

@iflyallthetime:

Look at the dates on those posts.

Wooow,

how I ended up on page 61 of a 158 page thread, I do not know.

I need a break...

[Jarin]

It sounds like you may have originally had version 1.0 of KER installed but have installed the 0.6 version after your KSP reinstall...

That... would explain several things I'm running into. Derp. Thanks.

[cybutek]

Hey cybutek,

I'm having the exact same problem as well.

Took you advice regarding deleting all the settings and reinstalling. Worked for one launch; the next time I returned to VAB, poof, vessel info gone again.

Here are the logs.

Thanks for the logs... Are you also able to also send a copy of the BuildOverlay.xml settings file? Nothing is standing out apart from some exceptions caused by other mods. I don't suppose you know how to replicate it in stock? Or know if it's a particular mod that could be conflicting? It's not something that I have ever been able to replicate on my end.

[Padishar]

Thanks for the logs... Are you also able to also send a copy of the BuildOverlay.xml settings file? Nothing is standing out apart from some exceptions caused by other mods. I don't suppose you know how to replicate it in stock? Or know if it's a particular mod that could be conflicting? It's not something that I have ever been able to replicate on my end.

This sounds like it is either failing to write anything into the settings file (I saw a problem fairly recently where an empty settings file would break things and wouldn't get reset to defaults) or another mod is throwing an exception which is preventing KER from calling the code that saves the settings at all.

If the settings file is there but empty then try copying your whole KSP install to somewhere else on you hard disk, e.g. C:\Games. If it isn't there at all then it could be the same problem but I would expect it to use defaults. Either way, I think we might need to add some logging to the various related bits of code (e.g. anything that loads or saves settings)...

[iFlyAllTheTime]

Thanks for the logs... Are you also able to also send a copy of the BuildOverlay.xml settings file? Nothing is standing out apart from some exceptions caused by other mods. I don't suppose you know how to replicate it in stock? Or know if it's a particular mod that could be conflicting? It's not something that I have ever been able to replicate on my end.

Here's the file you asked for:

https://www.dropbox.com/s/xem477ry0oxkl5d/BuildOverlay.xml?dl=0

I haven't tried to replicate this in the stock but I can give that a try.

Speaking of exceptions caused by other mods, I'm going to post a thread with some questions about understanding log files.

Thanks

EDIT:

Should the following setting be set to true?

"<SettingItem> <Name>vesselOpen</Name>

<Value xsi:type="boolean">false</Value>"

Edited November 6, 2014 by iFlyAllTheTime

[Padishar]

Thanks for the save and craft. It certainly does sound like a problem with the staging simulation and I'll try to take a look at it later this evening...

Well, I've had a look at the code and there are definitely at least two related issues in the simulation code. First, the stage for the currently active engines is not correctly running until all engines burn out as it is supposed to. Second, the code that works out which parts should prevent staging is not working correctly when nothing is decoupled in any stage.

Fixing both of these issues in the existing code should be possible (i.e. it shouldn't need to wait until my planned major code restructure) but it is rather complex and will need considerable testing with a large variety of craft designs so it will take at least a few days...

[cybutek]

Here's the file you asked for:

https://www.dropbox.com/s/xem477ry0oxkl5d/BuildOverlay.xml?dl=0

Thank you... That file has given me enough insight into what's happening that I have managed to replicate the problem. So a fix will be coming shortly

[iFlyAllTheTime]

Thank you... That file has given me enough insight into what's happening that I have managed to replicate the problem. So a fix will be coming shortly

Thanks for your quick response and help.

[cybutek]

Version 1.0.11.1 is now available! - Get it here!

Changed: Build Engineer now shows stage part count as well as total.

Changed: Build Overlay Vessel tab data:

DeltaV: stage / total

Mass: stage / total

TWR: start (max) <- shows for bottom stage only.

Parts: stage / total

Fixed: Issue with the vessel tab vanishing from the editor.

[KingofDerby]

Love addition of a HUD to the most essential mod in the game!

Two things though...can the position of the hud be editable? The right one goes over the tool bar, so is hard to see...second...I can't for the orbital period of a target vessal...am I being blind? Hope you can help please!

[helaeon]

Love addition of a HUD to the most essential mod in the game!

Two things though...can the position of the hud be editable? The right one goes over the tool bar, so is hard to see...second...I can't for the orbital period of a target vessal...am I being blind? Hope you can help please!

It is editable. If you click on the KER button and then the edit button on the hud you want to move you'll see a background show up. You can then click and drag that window you'd like it can also add other huds so you can have your value read out wherever you like them.

[qwerty12]

So I donwloaded the version 1.0.11.1 and none of the parts are appearing in the construction menu, I am running on v0.25.0.642 on steam KSP, and have no other mods installed in the fresh save I started to see if it'd work. Any ideas on what seems to be causing the issue?

[Shirson]

Hi guys.

How to activate part-less mode in new KER?

[Red Iron Crown]

Hi guys.

How to activate part-less mode in new KER?

Version 1.0.x is partless by default (though the parts still show in the science tab). Version 0.6.x can only be made partless through a module manager config.

Really, you should be using 1.0.x, it has a lot of improvements.

[Shirson]

Version 1.0.x is partless by default (though the parts still show in the science tab). Version 0.6.x can only be made partless through a module manager config.

Really, you should be using 1.0.x, it has a lot of improvements.

Oops, my bad. I was confused with first link in first topic. I already use 1.0.9.

Thanks, you kick me to right direction

[KingofDerby]

It is editable. If you click on the KER button and then the edit button on the hud you want to move you'll see a background show up. You can then click and drag that window you'd like it can also add other huds so you can have your value read out wherever you like them.

Ah! Brilliant! Thanks!

[puetzk]

I'm really loving the new 1.x GUI, great work!

One cosmetic bug report (in 1.0.10): mean Anomaly is being reported in radians, but labeled as degrees. I'm not sure if this was different in 0.6 or not, this is the first time I've gotten fancy enough to use it (trying to launch a tetrahedral commsat constellation). No strong preference whether this gets fixed by converting to degrees or by labeling as radians; it's not a real angle anyway.

Secondly, may I request Right Ascention/Celestial Longitude (relative to the body center being orbited) as an addition to the Orbital category? Off by default, since it's pretty specialized, but it would be useful for tasks like scheduling a plane change such that it results in a particular Longitude of AN).

It would also be really nice to have a Epoch field/mode (maybe with a "Mark" button that sets it to current UT) that freezes the time-varying numbers (e.g. the 3 anomaly values, the "Angle to X" values, maybe also their "Time To X" counterparts). This would make it a lot easier to compute the necessary adjustments to phase satellites that are in different planes (within a plane one can just use the rendezvous phase angle, of course). To avoid confusion, maybe make the "Epoch" field and the values its affecting turn a different color than the usual green when it's active, to show they are linked.

UI-wise, this is a bit like [ktf].VtD's request for info after a maneuver node (that would also be great!), but it should be a lot simpler to implement since it's the same conic; just evaluate the current elements at the epoch instead of the current time.

[ESteve]

What about vertical stopping distance. AKA, where to start that suicide burn.

Using gravity, ship's acceleration and current angle to the horizon we should be able to calculate how far a ship will travel vertically before vertical velocity is reduced to zero.

[Thanny]

Thought I already posted about this, but the forum ate it instead of posting (paid attention this time, and what looks like a confirmation page actually says it can't be posted due to some issue with a mysterious token - apparently I waited too long between typing and hitting the button).

The burn time feature has the potential to be very useful, but unfortunately it's not accurate. I took a look at the source, and if I'm reading correctly, it's dividing the total delta V (of the total burn or the max the current stage allows - which is a very cool feature) by the average acceleration based on start and end masses. While that would be a better approximation than what the game does (which is equivalent to delta V divided by current acceleration), it's still the wrong answer. But I'm not even seeing those results in the game.

For example, if I set up a node for a 2000m/s burn with a 284.395t ship using 20 nuke engines, KE shows a total burn time of 7m 54.0s, with a half burn time of 3m 57.0s.

Applying the Tsiolkovsky rocket equation shows that the burn would actually result in a final mass of 220.474t. That makes the starting acceleration 1200 / 284.395 = 4.219m/s^2, and the ending acceleration 1200 / 220.474 = 5.443m/s^2, for an average of 4.831m/s^2. Using the logic I'm seeing in the source, that means it should be showing a total burn time of 2000 / 4.831 = 413.98s = 6m 53.98s. That's more than a minute off from what's showing in KE. The correct burn time, calculated from the rocket equation, is 418.47s, with half the delta V accomplished in 222.53s.

I don't know where the source of the error is, but I do have a suggestion for improving the result regardless. Assuming a correct mass delta figure can be retrieved from the vessel simulation (i.e. end mass minus start mass, the difference being fuel burned), that can be divided by the fuel consumption rate of the engines to calculate the correct time. The consumption rate (by mass) is simply thrust / Isp * 9.82. It doesn't matter what fuel type it is, either, as specific impulse is related to the mass of the fuel.

So in my example, 20 nuke engines have a thrust of 1200kN and a specific impulse of 800s, which means the consumption rate is 1200 / 800 * 9.82 = .15275t/sec. The mass delta for the example burn is 63.921t, which can be determined with a direct calculation (mass - mass * exp(-dV / (Isp * 9.82))) or a simulation (I wrote one into my burn time calculator, as a sanity check, that updates every millisecond and gets the same answer), so presumably the vessel simulator in KE will expose that information somewhere. Total time is then 63.921 / .15275 = 418.47s.

[cybutek]

Thanks Thanny for looking into the problem and your detailed example. I'm working on a fixing it now

[Thanny]

Just to add quickly, it's thrust / (Isp * 9.82) for fuel consumption. Got stuck in RPN-think, where the stack determines operator precedence.

[cybutek]

Version 1.0.11.2 is now available! - Get it here!

Changed: Gravity measurements for Isp calculations from 9.81 to 9.8066 for accuracy.

Changed: Manoeuvre node burn times are now more accurate.

Fixed: Bug in the manoeuvre node burn time calculations where it was not averaging acceleration correctly.

[Thanny]

Gravity in KSP is 9.82m/s^2. You will get inaccurate results using 9.81 or (worse) 9.8066.

[cybutek]

Gravity in KSP is 9.82m/s^2. You will get inaccurate results using 9.81 or (worse) 9.8066.

To convert Isp in seconds into exhaust velocity uses 9.8066 as a constant and has nothing to do with actual gravity and is just for unit conversion.

Edit: It seems that you are correct. So that means either seconds are not representative of actual seconds in time or the length of a metre is slightly longer than the real world *face palm*

Edited November 11, 2014 by cybutek

[cybutek]

Version 1.0.11.3 is now available!

All of the specific impulse conversions to exhaust velocity are now 9.82. Including the ones used in the vessel simulation that were previously 9.81.