Test of continuing KER developments [0.24.2]

[How2FoldSoup]

What spec is your machine (specifically CPU type and speed, though any other details you have may be handy) and how big/complex is the ship in question? I presume it is quite complex as you call it a "large mothership". One thing you can do to reduce the lag caused by the deltaV calculations is to right click on the engineer part and drag the slider for "Sim time" to the right. This increases the delay between runs of the simulation code and should improve matters...

Assuming the list of mods it uses isn't too extreme, could you post a craft/persistence/quicksave file that I could take a look at (and a list of the mods)...?

It's got b9 and LLL and scansat. It's just large in size mostly due to the b9 parts. It comes in around 150 parts with nothing in it's bays but I was stress testing with 4x 25 part probes in one of the bays which had it come out at around 250 parts. How can I upload a .craft? I've never done so before.

I will try out the slider on the part itself. I usually always hide it in the craft and never thought to see if I could right click it for options!

Until I upload the craft here's an album before I switched to LLL engines

Javascript is disabled. View full album

I hope that helps

[Padishar]

It's got b9 and LLL and scansat. It's just large in size mostly due to the b9 parts. It comes in around 150 parts with nothing in it's bays but I was stress testing with 4x 25 part probes in one of the bays which had it come out at around 250 parts. How can I upload a .craft? I've never done so before.

I will try out the slider on the part itself. I usually always hide it in the craft and never thought to see if I could right click it for options!

Until I upload the craft here's an album before I switched to LLL engines

http://imgur.com/a/wE3Ve

I hope that helps

You will need to upload your file to a file sharing service of some kind (e.g. dropbox, google drive, mediafire etc) and then post a link to it here.

It didn't used to have any particularly useful controls (only a button to turn it on and off). I added the various sliders it has now to control the simulation rate and the atmospheric pressure and craft velocity used to calculate "correct" engine thrust/isp.

What spec is your machine (specifically CPU type and speed, though any other details you have may be handy)

Can you answer this bit too, please?

[How2FoldSoup]

Forgot about that part, apologies. I've got an AMD Phenom II 3.4GHz and I'm also running 64 bit windows with 8gb but I know that doesn't matter.

Here's the link to the craft

https://www.dropbox.com/s/ltak56fs16pahkc/Seabass.craft

I just realized I'm also using Quantum Struts continued on that craft as well as Kethane. If it's too much of a problem I could remove them and reupload that for you

[Padishar]

Forgot about that part, apologies. I've got an AMD Phenom II 3.4GHz and I'm also running 64 bit windows with 8gb but I know that doesn't matter

Ahhh, another user with a Phenom II reported a nasty lag issue and it turned out to be (mostly) caused by having the AMD compatibility mode turned on. Have a look at this post (and the earlier ones from the same person describing the problem). If you do have this option turned on then I suspect that turning it off will cure the lag (or at least the worst of it)...

I can't take a look at your craft right now (at work) but I will try to take a look this evening. However, I wouldn't expect your craft to give the simulation much of a problem unless there is a specific mod that is causing issues (the most likely offender is probably quantum struts as 0.23.5 changed how struts work and something may not be quite right).

[How2FoldSoup]

I had my shotcut set to ksp.exe itself so I totally forgot there was a launcher with options heh. My compatibility mode is turned off. I'm going to try launching from the launcher to see if that changes anything but I'm not holding my breath. I don't think it is Q struts because my framerate drastically increases once I hid KER or even just the vessel tab in flight. Whenever the dv calculations aren't being shown it goes away. It also goes away if I hide the hud(which is hiding the dv calcs).

edit: I'll also try increasing time between dv calculations and let you know how that turns out

2nd edit: Increasing the sim time only seemed to help a little bit. It made the stutters slightly shorter. Upon trying to launch from the launcher Ksp immediately crashes but continues to run in background processes so that's another interesting bug. I'm wondering if the launcher settings not be used when launching from the .exe. I'm going to try a fresh install of ksp with everything to see if that helps things.

I just thought this lag was my pc but when I minimized ker once and saw it go away I realized how much it was affecting gameplay for "larger" ships in the 200+ range so thank you for helping!

Edited June 4, 2014 by How2FoldSoup

[Padishar]

Yes, I understand that it is the KER simulation code causing the lag. I meant that the way struts are handled by KSP changed and if QStruts hasn't been properly fixed to work correctly with 0.23.5 then this could cause the simulation code in KER to have issues...

How drastic is this lag? Are you effectively getting freezes every time the simulation code runs or is the frame rate just lower in general? Are you using the version from this thread or the official 0.6.2.4 version? Either way, can you also try the other one and let me know how they compare?

I don't suppose you've set the processor affinity to make KSP only use one CPU core? That is definitely not a good idea when KER is installed (and is never really a good idea with KSP because some of Mono/Unity is multithreaded and it runs better on more than one core).

Another thing that may help is for you to post an output_log.txt (from a short run of KSP, e.g. run, load save, switch to vessel or load ship in VAB, let run for a few seconds and then quit). There may be exceptions, errors or other messages in there that may shed some light on the problem...

[How2FoldSoup]

Oh I see. I misunderstood a bit. I will try removing them and throwing the ship on the launch pad and seeing what happens. The game stops every tenth or a second or so. The length of the freeze got shorter when I increased the simulation delay...I'm using the code from this thread. I'll test the official release and report back soon.

All processers are set to run KSP according to task manager.

I also just realized there are a couple KAS parts on the ship as well. Sorry to have the modlist expand. If you need an unmodded(as possible) version let me know. At it's core the ship only needs b9 and LLL

here's the output.txt. I checked the debug menu in flight and didn't see any errors or abnormal messages but I trust your eyes more than mine in this.

https://www.dropbox.com/s/8p03iw51qvfikag/output_log.txt

edit: removing Q struts and using the official release did not fix the issue.

Edited June 4, 2014 by How2FoldSoup

[Padishar]

here's the output.txt. I checked the debug menu in flight and didn't see any errors or abnormal messages but I trust your eyes more than mine in this.

Well, there is nothing obvious in the last little bit of the log after the ship is loaded in the flight scene and all the plugins have started up but there are various worrying messages earlier in the log.

First, you appear to have MechJebRPM installed but don't have MechJeb itself. This could potentially cause an issue.

Second, I wouldn't expect that Kethane is supposed to do this:

Failed to load assembly C:\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

Thirdly, when loading the vessel, most (possibly all) of the parts report a missing PartModule. This appears to be something to do with FAR as the PartModules that don't load are FARBasicDragModel. I don't know if this is significant but I wouldn't expect FAR to cause this sort of log spam when loading a vessel.

Fourth, the Clouds plugin appears to be running 3 times at once. I don't know if this is significant but it could be.

If you drag the sim time slider all the way to the right (1000) and the glitches are less severe but still happen every tenth of a second then it isn't being directly caused by the simulation code as that would only be running every second (the number is the time in milliseconds between the start of one run of the simulation and the next one). KAC uses a 0.1 second timer so it may be worth removing that as a test and see if anything changes...

[How2FoldSoup]

That's interesting...I've only ever used mechjeb once on my .20 game and that's tucked away in another folder completely unrelated. Huh, thats weird. Actually, I just remembered that I did install mechjeb once recently before your last update for the dv calcs to see if it worked better. At any rate I came straight back to KER.

I removed the MechJebRPM folder in gamedata, it only had the config in it for whatever reason, and I removed KAC and still no joy when the vessel tab is being shown. I removed kethane as a test and moved the slider to 1000 with the ship on the launch pad. I almost removed probes I had in the cargo which now lets me run the ship in the green at real time. At this rate it did seem to freeze up about once every second but it a much faster freeze than it had been.

I'm rather unsure what to do about the clouds because I know I have EVE installed and then astronomers visuals pack on top of that. Removing both packs did not fix the issue.

[Padishar]

I have just updated the zip in the first post with a fix for the "fuel tank with disabled crossfeed" issue. This affects some nosecone parts when using Modular Fuel Tanks or Real Fuels. I have also slightly optimised the GetSourceSet function to eliminate lots of pointless recursive calls.

[somnambulist]

Padishar - would it be possible to update KER to work with Cross Feed Enabler?

[BudgetHedgehog]

Noticed a little bug - adding a (dummy) stage below the current one seems to break most of the info:

Javascript is disabled. View full album

Without the stage, all the info is there. With it, most of the info, aside from dV, is gone. I think I remember seeing something similar to this before, so I think it could be triggered by other things as well, not just this.. might be the simulation failing to calculate all info for the active stage? I dunno.. but yeah, there's my little bug report

EDIT: that said, this was with the version previous to the current one.. I'll update and see if that has any effect.

[Padishar]

Padishar - would it be possible to update KER to work with Cross Feed Enabler?

Interesting... I think it should be possible to make it work but I will need to investigate what it is doing to see if it will need to be handled differently in the VAB to in flight. I've added an issue to my GitHub...

Noticed a little bug - adding a (dummy) stage below the current one seems to break most of the info:

http://imgur.com/a/lfzfy

Without the stage, all the info is there. With it, most of the info, aside from dV, is gone. I think I remember seeing something similar to this before, so I think it could be triggered by other things as well, not just this.. might be the simulation failing to calculate all info for the active stage? I dunno.. but yeah, there's my little bug report

EDIT: that said, this was with the version previous to the current one.. I'll update and see if that has any effect.

Yes, I noticed this a few days ago when testing another issue with docking ports but haven't had a lot of time recently to get to the bottom of either one. I suspect what is actually happening is that KER is simulating the "active" stage because the engines currently active aren't what they should be for stage 2. This gives a dummy stage 3 used to calculate the deltaV and other values but it looks like most of the values in the VES tab (except for the deltaV) are output using the last real stage so the numbers are all zero. I've added issues for both this and the docking port issue to GitHub.

Hopefully I'll get a bit of time to work on these over the next few days...

[Padishar]

Hopefully I'll get a bit of time to work on these over the next few days...

I have just updated the zip linked in the first post to include support for CrossFeedEnabler and to fix the VES tab when the extra "active" stage is shown (and to fix the docking port issue I mentioned).

This has involved changing how the simulation code deals with fuel lines but I'm pretty sure it's all working correctly...

[Padishar]

I have just updated the zip linked in the first post to add readouts of the biome you are currently over and the biome you will impact in to the SUR tab.

[somnambulist]

I have just updated the zip linked in the first post to include support for CrossFeedEnabler and to fix the VES tab when the extra "active" stage is shown (and to fix the docking port issue I mentioned).

Perfect. Thanks Padishar!

[Alexander_bike]

I made an account just to post this.

I do not know if this is possible however it would be the ultimate addition to your already amazing mod. When in the VAB it would be great if you could select an itinerary e.g. kerbin -> duna -> Kerbin. Once the itinerary is selected there is a list of delta-v requirements that you can set for different stages e.g. stage 1 duna kerbin transfer, stage 2 low duna orbit to escape, stage 3 duna surface to low duna orbit etc.

I am not sure how hard this would be to do however it would be such an amazing addition

[Padishar]

I made an account just to post this.

I do not know if this is possible however it would be the ultimate addition to your already amazing mod. When in the VAB it would be great if you could select an itinerary e.g. kerbin -> duna -> Kerbin. Once the itinerary is selected there is a list of delta-v requirements that you can set for different stages e.g. stage 1 duna kerbin transfer, stage 2 low duna orbit to escape, stage 3 duna surface to low duna orbit etc.

I am not sure how hard this would be to do however it would be such an amazing addition

Well, it isn't actually my mod. KER was created by Cybutek (the main release thread is linked in the first post of this one) and I have been making various fixes to the deltaV calculation code and various other improvements while Cybutek is busy with a major UI rewrite that will become the next major version.

The sort of thing you are suggesting has been proposed before (basically a mission planner that allows you to design for a whole mission profile) but it will require some complex UI and would need to be carefully designed from the outset to be able to support more complex mission types, e.g. even a simple "Apollo" style Mun mission requires being able to specify that the vessel splits in two and is then redocked, needing to track multiple craft. For a grand tour type mission things would get very complex and it would also need to support missions that are refuelled in LKO before departure or refuelled elsewhere (and even with onboard kethane equipment). Devising a decent UI to allow all this sort of planning is tricky.

[Alexander_bike]

Fair point I was only thinking about stages I did not even contemplate undocking redocking and refueling. I can see how once people got the very simple stuff they would just want more.

[Padishar]

I have just updated the zip linked in the first post to include a slope angle and heading display in the SUR tab. The readout shows the angle of the slope from the horizontal to 1 decimal place and the compass heading of the downhill direction.

[Padishar]

Another small update to the zip in the first post. Now only calculates the slope if the reading is shown plus a small tweak to the launching of the background thread.

[Padishar]

There is currently a fairly serious issue in the simulation's staging logic during flight that is causing it to not stage when it should. This is most noticeable with asparagus type designs, where the individual stage deltaV values can disappear just leaving the first of the asparagus stages (with the wrong total deltaV as it is assuming you don't drop the stages as you go so are pushing more mass).

I will try to fix this issue as soon as possible...

[Padishar]

I will try to fix this issue as soon as possible...

Unfortunately this is not simple to fix. Basically, during the update on 14/05 I accidentally reintroduced the "struts feed fuel during flight" issue that first cropped up when 0.23.5 was released which is what broke the calculations for asparagus designs during flight. I will release a fix for this after work today but there will still be staging related issues.

The problems boil down to it not being easy to (reliably) tell when the next stage should be fired. In a simple, serial staged, design it is trivial (just stage once all the engines have gone out) but the user is not limited to such simple designs. A simple onion or asparagus staged design still has engines burning at the point when you want to stage so it needs to look at which engines are decoupled in the next stage and only stage when all engines that are decoupled have shut down. Unfortunately, this doesn't handle drop-tanks correctly so it also has to check if all the fuel tanks that have been drained during this stage, and will be decoupled in the next stage, are empty.

In the general case, a stage that doesn't decouple anything and doesn't enable any engines should not be activated until the stage that follows it needs to be activated (and that may need to check the next one too). This ensures that the deltaV for the stage appears under the correct stage number. E.g. in a simple pod/chute/SRB design with the chute in stage 0 and the SRB in stage 1, the deltaV readout should show the deltaV in stage 1. However, at present, the code only checks the next stage and, if nothing is decoupled then it doesn't activate it until all the engines have shut down.

These issues also combine such that if you add an empty stage between asparagus stages then the simulation will not fire the empty stage until all the active engines (and hence all the asparagus stages) have burned out. This results in the deltaV being calculated as if you don't stage once you get to the empty stage until all the engines stop. This lumps all the following asparagus stages into the stage before the empty one with a much lower total deltaV because it is pushing all the dead weight of the empty stages.

To fix this "properly" will require significant changes to how it works. It should be possible to examine the whole craft at the start of the simulation and determine the necessary conditions for each stage to fire. This list of conditions can then be checked for the current stage during the simulation. This should require less work to be done during the simulation loop so it should be more efficient.

TL;DR

I'll fix the struts issue that confuses things during flight this evening but a full fix to the staging logic will take longer...

[Padishar]

I have just updated the zip linked in the first post to fix the "struts feeding fuel" issue. I've started working on the replacement staging calculation described above and, hopefully, I'll manage to get it done before 0.24 hits and needs other fixes to be done asap...

[KerbMav]

Should we give up hope then?

Or is the silence a sign of you getting a .24 already to update KER properly for the new version?