Padishar

How significant are these surges? Can you run fraps (or some other tool that displays fps) and see what the values are? From your description, the most likely cause of this is the .NET/Mono memory allocator garbage collection. The larger the craft, the more objects the KER simulation code will create and this will make the garbage collection run more frequently. I'll add some kind of option to control how frequently the simulation runs (reducing the rate to, say, 2 updates per second max should significantly reduce the amount of work the garbage collection needs to do) and do some tests to work out if this is the cause and try to reduce the amount of memory allocation churn if it is.

Over the last few days, when I've not been busy coding, I've made a start at dropping a class E on the VAB... At this point I started running into various very annoying bugs. My ship has randomly exploded in non-physics time-warp several times and the multiple RCS thruster craft break the navball when I target the COM from the main tug making it very difficult to set up an accurate burn. It seems to get better for a little while after a quit and restart but soon comes back when you switch between ships and use timewarp. I may have to wait for another patch before continuing but if I make more progress I'll post it...

Well, in my "main" install I only run KER, KAC, DPAI, Editor Extensions and Toolbar so I usually use the circuit board type build and flight engineer on everything. I only have the MM config to add build and flight to all command pods and probe cores in my realism overhaul install (that needs module manager for lots of stuff anyway) though I haven't got around to updating it to 0.23.5 yet due to realism overhaul issues with updated mods. I still tend to stick a build and flight engineer board on everything out of habit. I just wish I could get into the same habit with solar panels/RTGs... Hmmm, perhaps a mod that gives advice about your design would be good. It could display a window listing things that you've forgotten when you go to launch (e.g. if you haven't got at least one RTG or deployed solar panel, or if your staging looks obviously messed up, launch clamps on wrong stage etc) and give you the choice of continuing or cancelling the launch... In my various development and test installs, to speed up the edit/recompile/test cycle, I tend to only have the absolute minimum of mods I need to do what I need to. Testing KER with full realism overhaul is painful as it takes KSP about 8 minutes to start up on the machine I'm currently using...

So, are you saying you don't get the surging lag effect with the version in this thread (that says (Pad) in the KER window title bars)? The current official release of KER has various serious issues with the simulation code and doesn't work correctly with 0.23.5 so you really should switch to this test version until the next official release.

Your craft file still says 0.23.0. Have you updated to 0.23.5? The current test version is compiled against the 0.23.5 code so using it with earlier versions may not work. I can't load your craft at the moment (the load dialog says "Contains locked or invalid parts") but I think I understand why it doesn't work so I should be able to make a duplicate craft. Basically, the simulation code in KER simulates the normal staging process so it tends to get confused if you manually activate and deactivate engines during flight. Also, it looks like there is an issue with decouplers not being ignored when they aren't in the staging (as well as an issue if a decoupler is the root part and is fired in stage 0). Edit: I can create a similar vessel but 0.23.5 doesn't let me remove the decoupler from the staging and the only way to make the craft file match yours is to have the decoupler in stage 0 with the engine and chute. This would then make sense as you shouldn't have any engine still connected but it doesn't explain why the decoupler isn't showing in your screenshot. This is a nonsensical staging arrangement. If you reorganise the staging into 0 = chute, 1 = decoupler, 2 = engine it would make much more sense and should work correctly...

What CPU do you have? I recently changed how the delay between runs of the simulation is handled to improve the update rate but this may have had unwanted side-effects. Does the lag also disappear if you use the toolbar button to hide the KER window (assuming you are using the toolbar)?

Are you using the test version linked to from the first post? That should work much better with the new parts.

What makes you think the deltaV should be ~8000? Have you done the maths yourself? Any chance you can post the craft file?

Can you give screenshots, a craft file or the vessel from the persistence file?

Yes, this is just the difference between vacuum and atmospheric isp/deltaV. If you switch to atmospheric stats in the VAB then the total deltaV drops from 9036 to 6976 m/s. This uses the atmospheric pressure at sea level to calculate the isp and deltaV. When you go to the launch pad the deltaV is 7038 m/s because you start at 122 m altitude (~70m for altitude of the pad and the rest from your rather tall launch clamps) and the air is a little thinner (the isp shows as 320.971s, slightly higher than the sea-level value). As you ascend the air gets thinner and the deltaV of the stages that aren't firing goes up quicker than the deltaV of the first stage is going down so the total increases for a while. The rate the first stage goes down depends on the throttle, at full throttle from launch the total deltaV goes down right from the start.

Basically the staging is weird. You have activated engines in a stage with a decoupler and there is a known problem when the craft has a decoupler as the root part. Basically, the simulation code is assuming the engines will be decoupled from the craft as soon as they are activated. As a workaround, try modifying the staging in flight to move the decoupler from the stage with the engines. E.g have the decoupler in stage 0 and create a new stage 1 for the engines...

Not gone, you just have to go bigger for the same challenges. My Mk2 class E asteroid tug is about 425t payload to LKO. Even using the new parts in a 13 stack asparagus configuration (the total launch mass of the ship is about 2400t, almost the same as the asteroid it is going to be moving), the launcher only just makes it to LKO when you fly a good ascent profile. It took me 3 attempts before I managed to make it with enough fuel left to de-orbit the lifter and then I realised I forgot the electricity supply...

I'm not sure I understand what you are describing. I can't try it right now but it would be very helpful if you could supply a craft file that shows the problem...

Whatever the actual reason it certainly does sound like the parts aren't providing fuel for the simulation. I'll need to take a look with the logging build... From your description you may just be seeing the difference between atmospheric and vacuum deltaV. Can you post your craft file?

For an imgur album you just use: [ imgur]pBzRP[ /imgur] (without the spaces after the opening square brackets)

I'll check this out. I did use the toolbar button in the VAB to hide the window yesterday and it seemed to work fine but I don't think I've actually updated the toolbar plugin since 0.23.5 so perhaps there is some weird conflict with the latest version.

I suspect this is something awkward like the order in which things are being called. E.g. if 0.23 drew the navball text first and then called the mod but 0.23.5 calls the mod first and then draws the navball, then this would explain the issue you are having. I'm not saying this is what is happening but it sounds likely to me. If so, then perhaps there is another method you could put your drawing code in that still gets called after the navball has been drawn...

The orbital pane doesn't need to do much in the way of calculations so it can easily update every time the plugin is asked to redraw the window. The vessel tab has to run complex code that simulates the complete burning of all the stages of the vessel so it is deliberately throttled. I will have another play with the timings and see if basically removing the delay has any bad effect on the game. We certainly don't want to go back to the days when the vessel pane had a noticeable impact on fps... Yes, I understand. The values shown in KER are the max the engine is capable of. The value in the tweakable window takes into account how fast the vessel is moving. A stationary turbojet produces much less power than a fast moving one. All that should be required is that the values in KER are adjusted according to the velocityCurve of the engine. The vessel simulation code currently has inputs for gravity and atmospheric pressure so it shouldn't be difficult to add a velocity input too.

Awww, you missed the VAB... The first asteroid I captured was a class E (I thought I'd aim high) and has a mass of ~2450 tons. It is currently in a highly eccentric orbit at about 45 degrees to the equatorial plane so will take a bit of work to land on the VAB. My tug (4 LV-Ns and enough fuel for ~6500m/s deltaV) only had approx. 50 deltaV once I grabbed the rock but that was just enough for the capture burn. I'll need to design a new booster system that can be refuelled easily to do the inclination change and de-orbit burn required to drop it on the VAB...

It isn't the giving of feedback that people object to, it is the demands that things be nerfed because they are OP. The devs have stated many times that their primary concern is playability, not realism (it is a game, after all, and is supposed to be fun). The game has good modding support and an excellent community of talented modders for people that want to go more "realistic".

This has been fixed in this test version. I'm not sure when (or even if) Cybutek will be releasing an updated version based on 0.6.2.3 for 0.23.5 as he has been working on a major new version that will become v1.0. He is currently waiting on the changes I have been doing to the deltaV calculation code so it can be integrated into the new version. In the meantime I would recommend that everyone running 0.6.2.3 switch to using this test version as a large number of improvements have been made. 1. When you say it is jerky, do you mean it updates too fast? The performance of the new simulation code should be better though it does now split the work between the main thread and a background thread and the code in the main thread needs to create more complex data structures for use by the background thread to avoid various nasty race conditions with the core game code (e.g. the vessel changing while the background thread is running the simulation). I have also changed the way it decides how long to wait between runs of the simulation. The old code runs the simulation and then waits for at least 10 times as long as the simulation took to run before running it again. The new code currently tries to maintain approx. 10 updates per second (which is a bit high really) and usually seems to manage this. I want to slow it down to between 2 and 4 updates per second which should be fine if that is what you mean. 2. I haven't explicitly done anything to the handling of jets though I am aware that they may not be giving correct values. The probable cause is that the thrust generated by jets depends on the speed the plane is flying and this can't be easily simulated in the VAB/SPH. Perhaps there should be a way of adjusting the speed used similar to how you can switch between vacuum and atmosphere. This could either have a settings value to set the speed or maybe even have a slider in the build UI. I don't really want to show another field for high-speed thrust/TWR as I want to add a "max TWR" field anyway (to let people see the TWR at stage burnout) and the window is quite crowded already.

There is something very wrong with your craft. You will notice that the staging is showing 4 engines but only 3 are "visible". One is clipped inside another. Also there is a complete copy of the leg with it (so 4 legs too) and if I try to launch the craft only has 2 legs and falls over. Did you have clipping enabled when you built it? This looks like a case of the VAB getting badly confused and breaking your craft. There is no way I know of that KER could have caused this. I'll try and work out why KER is giving an exception and make the message more friendly/helpful but that won't help with your craft. You will probably need to rebuild it from scratch...

Excellent, I've only ever seen my in-game exception reporting working when deliberately provoked in the code... As for the actual bug, are all the parts still attached or has the editor done something weird? This looks like it might be a core game bug but I'll check it out if you can upload the craft file... Edit: cheers... I'll take a look now...

In what way does the ion not work? Are you using the latest version downloaded from the first post? Can you provide a craft and a description of what you think is wrong?

I managed to find a spare few minutes to give it a quick test and it appears to work correctly with ion engines (I haven't tested monoprop engines but they should work exactly the same) so I have updated the zip linked in the first post...