Test of continuing KER developments [0.24.2]

[User Unrelated]

Runge-Kutta refers to an iterative method for approximating solutions to differential equations and there isn't any of the sort of thing in KER. I suspect this came from the core game or from another plugin that does do more complex maths...

That was probably FAR, I can't think of any other plugins that do maths...

I'm about to boot the game up again, and I'll see if it happens again.

[Padishar]

Yeah, I was going to suggest it might be FAR but I couldn't see why that would be doing anything in the VAB (unless it had a background thread still going from before you reverted and it got upset when it found it wasn't flying any more...) so I left it open.

[User Unrelated]

Well, you CAN do all those aerodynamic analyses and such from the menu in the VAB... I don't really know what any of it means (I never paid enough attention in fluid dynamics class ) but it looks complicated...

Everything behaved itself this time around. Now I'm having glitches with Infernal Robotics... well, I AM using the rotatrons as wheel motors, so...

[Padishar]

I have just updated the dll download linked in the first post. Not had much time so only a couple of little fixes for now...

Fixes:

Work-around for Horizon Zenit NaN electric charge bug.

Fixed display of silly stage times in Flight engineer when throttle very low.

Edited March 13, 2014 by Padishar

[Tourman]

I have just updated the dll download linked in the first post. Not had much time so only a couple of little fixes for now...

Fixes:

Work-around for Horizon Zenit NaN electric charge bug.

Fixed display of silly stage times in Flight engineer when throttle very low.

I tried your fix but the delta-v calculation is wrong. My craft shows a 0.77 TWR for the main stage, but it has no issues getting off the ground. I updated my craft to remove RT, but I still use TAC Life Support and TAC Fuel Balancer so idk if that will mess things up.

https://www.dropbox.com/s/pamhv9r90eddl9l/Broken%20Craft.craft

[Padishar]

I tried your fix but the delta-v calculation is wrong. My craft shows a 0.77 TWR for the main stage, but it has no issues getting off the ground. I updated my craft to remove RT, but I still use TAC Life Support and TAC Fuel Balancer so idk if that will mess things up.

https://www.dropbox.com/s/pamhv9r90eddl9l/Broken%20Craft.craft

Yes, I haven't fixed the issue with engines that have multiple engine modules yet. Those engines only read as 100kN thrust rather than the combined value of 850kN. The deltaV values should still be reasonably close (unless the much longer burn time causes a difference in staging behaviour)...

[Padishar]

I have updated the zip linked in the first post to include the fix for engines with multiple modules. The Horizon Zenit engines should all work correctly now.

The fix basically treats each individual engine module as a separate engine. This allows modules to use different propellants which burn out at different times (if such engines exist anywhere) and should be easily expandable to account for the thrust vectors in the future.

Note, there is a potential issue with the overall stage isp if a stage contains engines that burn out at different times. The isp displayed is the overall stage isp at the start of the stage and not the effective isp over the whole life of the stage. So, if you have a stage consisting of a long running liquid engine with a good isp and some non-detachable solid boosters with a poor isp then the displayed isp will be that including the solid boosters and will be less than the effective isp as the solid boosters will not be running during most of the stage. This shouldn't really affect anyone as the deltaV calculations will be correct because the isp is recalculated for each phase of the simulation (a phase is as long as it takes to completely drain the quickest draining fuel source). The stage isp simply needs to be recalculated from the overall stage deltaV and the starting and ending masses but it's late and I need to get some sleep so I'll do it tomorrow...

Edited March 14, 2014 by Padishar

[Crazor]

Just wanted to let you know that there are some old .dlls in the output folder in both of your branches over on github. Judging from the reported dates, they don't seem to have been touched in a while. Maybe you should better remove them to avoid confusion.

Other than that, the current build from the first post is running fine over here.

[BudgetHedgehog]

One thing I noticed was that during launch and ascent, the dV updated quite slowly, probably about once a second. I could attribute this to gameplay lag that occurs anyway, but looking at the dV display in the ALCOR pod I was using, it was updating much faster. Probably about normal for it, actually. So there's that..

Also, it still has a problem with docking calculations. While it's usually ok (and pretty fast at updating the display), I did manage to confuse it with this:

It's not calculating for dV for the currently burning engine, since that's staged after separation of the capsule (which would leave the engine on the docked probe left). This meant that the dV displayed is for the probe engine, and obviously increased as I continued burning. Granted, this was obviously a test case with manually activated engines (staged on, turned off, then on before and after docking etc) and if you're paying attention, it's not a problem, but it's not implausible to happen IRL.

All that said, I can't remember if this was an issue with the 6.2.2/3 or not. So yeah, there's that too.. but the first point I made still stands, it updates dV quite slowly.

This was the rocket I used (fairings decoupled for visibility), using a mix of KW and stock engines. Despite looking like it has major oomph, it's got a **** poor TWR, but this was just slapping as many bits on to confuse KER. As it stands on the launchpad, stage 1 is separation, stage 0 is probe engine.

Edited March 14, 2014 by ObsessedWithKSP

[Crazor]

Since issues are disabled on GitHub, I'll report this here. I had a crash switching from the runway to the SPH, and while looking for the culprit, I found the following in the log:

[LOG 14:03:46.931] Exception in StartSimulation: System.ArgumentException: An element with the same key already exists in the dictionary.

at System.Collections.Generic.Dictionary`2[Part,Engineer.VesselSimulator.PartSim].Add (.Part key, Engineer.VesselSimulator.PartSim value) [0x00000] in <filename unknown>:0

at Engineer.VesselSimulator.Simulation.PrepareSimulation (System.Collections.Generic.List`1 parts, Double theGravity, Double theAtmosphere) [0x00000] in <filename unknown>:0

at Engineer.VesselSimulator.SimManager.StartSimulation () [0x00000] in <filename unknown>:0

There are three other log entries after that, so maybe KER didn't cause the hang (KSP didn't really crash, I had to force-quit it), but I thought you might want to know about this.

[Padishar]

Just wanted to let you know that there are some old .dlls in the output folder in both of your branches over on github. Judging from the reported dates, they don't seem to have been touched in a while. Maybe you should better remove them to avoid confusion.

Other than that, the current build from the first post is running fine over here.

Yes, I've only created the fork to prepare (and update) a pull request to Cybutek's version. I haven't been updating the compiled versions (I don't think they should be in the github repository really) but I will do from now on to avoid any confusion.

[Padishar]

Since issues are disabled on GitHub, I'll report this here. I had a crash switching from the runway to the SPH, and while looking for the culprit, I found the following in the log:

There are three other log entries after that, so maybe KER didn't cause the hang (KSP didn't really crash, I had to force-quit it), but I thought you might want to know about this.

I'll look at enabling the issue stuff on github. Thanks for reporting this problem, it looks like adding a Part to the Part->PartSim dictionary is failing because it is already in there. Should be easy to fix.

This shouldn't have caused anything to crash but I'll take another look at the exception handling to make sure...

There should be another update later today with various optimisations and code cleanup/commenting and I'll try to roll these fixes in too...

[Crazor]

As I said, the freeze was probably not related to KER... It's just what made me find out about this message

Also, this happens frequently after a few takeoff <-> SPH turnarounds (I suppose it also happens after a few launch <-> VAB cycles):

That's supposed to be the KER window!

[Padishar]

Did that effect with the window happen with the latest version of the code? Are you certain you don't have more than one version of KER installed?

I'll try out switching from runway back to SPH (and pad to VAB) a bit more. When testing the code I usually go to VAB, load a craft, check build window, fiddle with ship a bit checking window, go to launch, check window, launch and check window update, revert to VAB, load another craft, repeat. I don't generally keep the same craft through multiple cycles so this may have something to do with it. I'll have to take a close look at how the PartModule is being called on scene changes.

Incidentally, I've enabled the issue tracker on my github fork.

[Padishar]

One thing I noticed was that during launch and ascent, the dV updated quite slowly, probably about once a second. I could attribute this to gameplay lag that occurs anyway, but looking at the dV display in the ALCOR pod I was using, it was updating much faster. Probably about normal for it, actually. So there's that..

Yes, it is a bit sluggish. It isn't at any sort of fixed timings. It runs the simulation and times how long it takes. Then it waits for at least 10 times that long before it will run the simulation again. So if the simulation takes 100ms then it will update approx. every 1.1 seconds. This delay strategy is left over from when the simulation ran in the foreground thread and it can probably be changed to update more quickly now that it runs (a large part of it) in a background thread.

Also, it still has a problem with docking calculations. While it's usually ok (and pretty fast at updating the display), I did manage to confuse it with this:

http://i.imgur.com/z3sMK4b.png

It's not calculating for dV for the currently burning engine, since that's staged after separation of the capsule (which would leave the engine on the docked probe left). This meant that the dV displayed is for the probe engine, and obviously increased as I continued burning. Granted, this was obviously a test case with manually activated engines (staged on, turned off, then on before and after docking etc) and if you're paying attention, it's not a problem, but it's not implausible to happen IRL.

All that said, I can't remember if this was an issue with the 6.2.2/3 or not. So yeah, there's that too.. but the first point I made still stands, it updates dV quite slowly.

I suspect this was an issue with the old code too. The code simulates the normal staging process and doesn't make any effort to work out issues like this. It isn't easy to decide what it should display in this sort of case...

This was the rocket I used (fairings decoupled for visibility), using a mix of KW and stock engines. Despite looking like it has major oomph, it's got a **** poor TWR, but this was just slapping as many bits on to confuse KER. As it stands on the launchpad, stage 1 is separation, stage 0 is probe engine.

http://i.imgur.com/6eiRjAl.png

I presume the stages have sensible burn times in the VAB.

[Tourman]

Padishar,

The latest update breaks compatibility with Horizon. Now I just have a blank window, where before the first stage was simply calculating the wrong dV.

[Padishar]

Strange, it was working for me. I'll give it a try using the versions from the zip as soon as I finish work. Is this the same Broken Craft.craft file you posted before?

[Padishar]

Well, it was still working fine for me. Does your output_log.txt show any exceptions or other errors?

However, I have now pushed several new commits to my github fork and updated the download in the first post again.

Fixes:

Now correctly calculates effective stage isp when some engines don't burn for the whole lifetime of the stage.

Avoid exception (and blank window) when a part appears in the part list more than once. Now simply logs the extra copies of the part and continues.

Various optimisations to eliminate lots of scans through the whole part list.

Improved exception handling to avoid possibility of KER stalling after an exception in the PrepareSimulation method.

[NathanKell]

Padishar: does this take thrust correction into account? (i.e. where thrust varies with Isp, rather than fuel flow varying with Isp)

[Trann]

"It works great!"

For the last few weeks, I've been left with the empty KER bar and thought it was some artifact of so many docked ships with KER installed or too many parts (building a space station) or some other issue I would probably never pinpoint.

This has brought KER back and I'm bringing up even more parts to my station without problems. My deepest thanks.

[Padishar]

Padishar: does this take thrust correction into account? (i.e. where thrust varies with Isp, rather than fuel flow varying with Isp)

Well, not explicitly. How exactly is this implemented in whichever mod (Real Fuels?) it is? Does it dynamically change values in the engine modules or do something else?

The code in KER reads the following members from the engine modules:

maxThrust

thrustPercentage

requestedThrust

atmosphereCurve

throttleLocked

propellants

It then calculates the isp for the module by calling atmosphereCurve.Evaluate passing either the actual atmospheric pressure (flight) or the relevant pressure value for the selected body (build/atmosphere) or zero (build/vacuum). It then calculates the resource consumption rates using the isp and relevant values from above (in flight it uses requestedThrust and in all other cases it uses maxThrust and thrustPercentage and when landed it also uses the main throttle position). I presume this would need to change to leave the consumption rates static (at vacuum level?) but I don't know how I will need to (or if I will need to) change the thrust displays.

I'm willing to try to make it work but I will need to investigate the mod concerned or ask lots of questions of the author to work out how to detect the mod and how to modify the calculations...

[NathanKell]

Cool.

Lemme dig up the PM I sent cybutek when cybutek asked how to support it.

[Padishar]

Another small update to remove some accidental log spam. Writing a line of output for each part in the vessel each time the simulation is run slows it all down a bit...

[Paul Kingtiger]

Working well for me! Thanks for the updates.

I'm getting an issue with the interstage fairings on Procedural Fairings, when building Apollo style craft, but I always have. I don't consider it a big issue as the DV is shown correctly for everything under the decoupler, which allows me to build my CSM, LM and booster with the right DV values.

[Padishar]

Working well for me! Thanks for the updates.

I'm getting an issue with the interstage fairings on Procedural Fairings, when building Apollo style craft, but I always have. I don't consider it a big issue as the DV is shown correctly for everything under the decoupler, which allows me to build my CSM, LM and booster with the right DV values.

Could you describe the issue please? What it does and what you think it should do (with pictures if helpful) and I'll see what can be done...