Padishar

If your background thread happens to be reading the values from Aerodynamics.UpdateData[this.part.uid] when PartAeroFX.LateUpdate is halfway through updating them then the calculations could be messed up. This updating of the data the background thread is reading must be made atomic and synchronised. In the case of FAR's aerodynamics calculations, the mechanism you describe will be calculating the drag for different parts of the vessel at slightly different points in time and hence with slightly different input parameters. I suspect this will introduce some odd errors into the calculations that will result in undesirable forces on the vessel (e.g. one wing producing more lift/drag than the other). Also, what will happen when a part's mesh changes (e.g. a solar panel)? You would somehow have to detect and pass the change to the thread. It is certainly an interesting idea but I think you will definitely have issues if the calculations take longer than a frame. If the thread simply sat in a loop and processed items from a queue and stuck them in an output dictionary then you could make each part submit its data in Update and continue. The background thread would wake up when it sees some data in the queue and start processing. This processing would go on in parallel with the core calling the Update of each part. Then in LateUpdate (I presume, I'm not that hot on the KSP/Unity specifics) you would wait for the data for the part to be ready before reading it and continuing. It would also require a cache of your meshData structures that are passed into the queue every time so that they can be updated easily when the part meshes change. It would be possible to share the input queue and output dictionary between multiple background threads if they were appropriately synchronised. It won't really help in this case but my now work-in-progress job manager allows a plugin to create a job object which includes the input and output parameters and pass this object to the job manager for running in the background. There are mechanisms to determine if a job has completed and for the job to provide progress information which the plugin can safely read (for very long jobs). It is intended that multiple plugins can share the job manager so it will require a hard dependency on the job manager plugin to use it so there will only be one copy of the code running. As soon as I'm fairly sure the interface is reasonably stable I'll put it up on GitHub...

I have just posted an update to my development version of KER that includes the button in the flight engineer tweakable I mentioned in the other thread that dumps the part tree to output_log.txt. The info includes the vessel name and type and also the vesselType and initialVesselName property of every part (as well as all sorts of info important to the deltaV simulation code). I'm going to add some more info to it (showing the original root part after docking etc.) as soon as I get a bit more time...

This is sounding like some numeric value in the craft is reading as NaN (not a number) or possibly of zero causing either a divide by zero or generating a NaN value. If a NaN value is used in any type of calculation the result of the whole calculation is also NaN. There was a problem with certain mod engines where they had a tweakable electric charge but a capacity of zero which triggers a bug in KSP when you open the engine's tweakable that results in NaN units of electric charge. KER was including this when calculating the mass of the part which resulted in NaNs in the mass (and hence the TWR, deltaV and burn time) which get displayed as blank. As your thrust is blank but the mass isn't I suspect the thrust correction is causing the NaN and this is affecting the TWR, deltaV and burn time. I'll take a look at the code and check it isn't doing anything silly. I may add some debugging code to detect and log the issue into my latest development version, I'll let you know how it goes... Edit: I have posted an update to my development version that includes detection and logging of a couple of potential causes of NaN in the thrust correction code.

I'm not sure what purpose the memory stream really serves in your description other than to slow it down. KER performs the bulk of the fuel flow simulation to calculate deltaV in a different thread by simply calling System.ThreadPool.QueueUserWorkItem(WaitCallback callBack, object state). This allows you to call a static function and pass an object instance to it. KER creates a Simulation object in the main thread that copies all of the data it requires from the core data structures into its own private structures and then passes this object to the function run in the background. The Simulation generates an array of Stage objects containing all the results which the main thread reads once it is safe to do so. The code is in SimManager.cs and BuildEngineer.cs. I have thought about writing a library that encapsulates (and improves on) this mechanism for others to use but have not yet got around to it.

Good stuff. This should give me enough to be getting on with for the simulated undocking and redocking code in my mission planner. I'll let you know if I find any cases that break the rules or if the coding of the rules sheds any light on how they are probably implemented in the core game. I need to do some KSP/Unity UI research now to work out how it can actually be presented...

I believe this is usually caused by an installation problem, e.g. having files from an older version also present in GameData (or the much older folders). Search through the whole of your KSP installation for all files that look like part of KER and delete them and then install a fresh copy of 0.6.2.4 (place the whole Engineer folder from the zip into your GameData folder). If this doesn't sort it then please upload your output_log.txt somewhere so we can take a look (or look through it yourself to see if you can spot any likely looking errors)... I've compared the parts from 0.6.2.3 and 0.6.2.4 and I can't see anything wrong.

I'll take a look tomorrow to see if Cybutec has accidentally changed the part name...

Sorry, I missed this earlier. Yes, we should probably have taken this elsewhere. Thanks for the new examples. I wasn't trying to say that you were wrong, I should probably have written "I'm not convinced by the evidence you have given that there are any rules like you describe." Thinking back over my time playing I think I have actually experienced the craft I was in control of staying as the root when docking when I was messing with a skycrane to rescue a stranded rover. I have a very useful feature in my dev version of KER that adds a button to the engineer tweakable that dumps the part tree of the vessel into output_log.txt so I'm going to run a whole suite of tests on this because I will need to know the actual rules used for a mission planner plugin I am currently designing. It may take a while to devise and run enough tests to make firm conclusions but I will post a thread somewhere once I have some... Edit: Out of interest, what is the root part of that craft?

First of all, can you confirm which version of KER you are using? If you aren't using 0.6.2.4 (or my latest dev version based on 0.6.2.4) then please update and try it again. I've given it a try with just RealFuels and RftS engines and it seems to work ok. When you say "but often there is a bug" how often do you mean? Can you see any pattern to when it does and doesn't work, e.g. any particular engines or fuel tanks (or complete craft) it goes wrong with etc.? I may have missed a type of RF engine module when I was implementing the thrust correction though I don't see why that would make it behave in the way you describe. Can you post an output_log.txt file somewhere? Run KSP, edit ships until you get the problem a couple of times and then quit (to avoid the log getting too big). If you find an easy way to reproduce it, e.g. load a particular saved craft and add/replace an engine and it always goes wrong, then please also upload a craft file and the steps necessary to reproduce.

Does the thrust behave the same way, initially showing a value and then going to ---? I've hardly run with RealFuels (and I've never run with the RftS engine pack, just the other recommended one) since I implemented the thrust correction so it is quite possible there are bugs. I think you are the first person to mention it since it was done. I've also changed machines since then so I'll need to set up a new install, I've been meaning to just haven't got around to it yet...

As this is the first such report after quite a few days I have to suspect there is a problem with your install rather than a general problem with the release. Try looking in output_log.txt (or do a quick test run of KSP to generate a nice small log and post it up somewhere for us) for any error messages that might explain the problem. I suggest you completely remove KER from your game and then reinstall it by simply copying the entire Engineer folder from the zip into your GameData folder. There should be three folders inside the Engineer folder, one for each of the parts, and each one should contain either one or two folders (all three have a textures folder and the two chips have a mesh folder), a part.cfg and either a .dae file or a .mu file.

In all your examples, the thing you are docking to becomes the parent of the craft you are controlling. I'm not convinced there are any rules like you describe. It would be much simpler to implement if the craft you are controlling is always re-rooted and attached to the other craft as a child of the docking port. HarvesteR describes this here.

It is swings and roundabouts really. Using a pure garbage collection based allocator should mean it is impossible for code to still have a reference to an object that has been deleted. This is one of the most common causes of access violations in programs written in C/C++ (after code simply not checking a pointer isn't null before dereferencing it). Your example of cross references is not a problem for the Mono/.NET garbage collector. It is designed to correctly handle loops of references between objects, e.g. if you have a linked list of objects where each object has a reference to the previous and next objects in the list and you have a variable that contains a reference to the first object in the list then, when you set that variable to null (or it goes out of scope if it's local variable inside a function) then the garbage collector will realise that there are no external references to the data structure so all the individual objects in the linked list can be released. In a correctly written program this will not cause a significantly different amount of memory fragmentation. It is no harder to write a correct C# program than it is a C++ program, in fact, it is usually easier as it requires less explicit boilerplate code to be written. The main difference is in how bugs manifest themselves. If you have a program that creates objects and passes references to them to several other objects, e.g. you register the object with a number of different callback providers, then, when it comes time to delete the object, you still have to remove the object reference from all of the callback providers or you will have problems. In C++, if you delete the object and have left it registered then you will be accessing memory that is no longer valid, it could have been reused for a completely different type of object or have been unmapped from physical memory and this would cause a crash. Unfortunately it may not have been reused yet and then the call can appear to work just using the potentially unsafe data in the object whose destructor has already been called. In C# this is impossible as if you leave a reference with a callback provider then the object will not get deleted so the memory can't possibly be reused or unmapped. Obviously, in each case, you need to do the same thing, unregister the object from all of the callback providers, then it will be safe to delete in C++ or it will be collected in C#. One way of "automatically" handling deregistration in C# is to make your callback functions have a way of indicating that the object is no longer valid. Then, all you have to do is tell the object to do this when it is called and make the callback provider detect the special return value (or however the indication is done) and unregister the object. It means writing a little extra code in the callback function and the callback provider but also means you don't have to explicitly unregister the object from all the different providers it is registered with but you still can manually unregister the object if you don't want it sticking around in a "dead" state until all the callback providers have tried to call it. TL;DR Neither approach to memory allocation is "better", they both have advantages and disadvantages, but the level of memory fragmentation is not significantly different in either case. That is affected much more by changes to how the algorithm works than whether you are using garbage collected references or pointers...

I have now implemented the simulation of active engines during flight. I have resurrected my old test thread for people to get the updated DLLs and give feedback.

I have now implemented this and, rather than posting a new thread, I have resurrected this one as it contains various posts about this issue (and others that I will be working on). During flight, if the currently active engines are different to what should be active in the current stage then an extra "stage" of calculations will be done with just the currently active engines. This stage is reported in the VES window as "DeltaV (active)". The simulation runs the current engines until they are completely out of fuel and then continues with the normal staging process. This should make KER much more useful in situations where engines are manually stopped and started differently to the defined staging. Please give it a try and continue to use this thread to report issues or give other feedback.

Your RAM does matter to whether or not KSP has to start using virtual memory. It should be possible to get up to 3.4 gig memory usage with only 2 gig of physical RAM in the machine but it will likely thrash the VM pagefile quite a bit. The important thing is whether the working set (the bits of memory the program has allocated that it is actually using, e.g. lots of part and planet textures that you aren't currently seeing can be swapped out of physical memory) fits into the available physical RAM. On a machine with 16 gig it is unlikely that any of KSPs memory would need to be paged out unless you are running other programs that are using lots of RAM and/or accessing large amounts of disk data making the disk caching use more memory.

Thanks for the response. When you say "the default assignment of stage numbers" which member of the Part class are you referring to? Does it simply use that member of the mono/xenon tanks to group them? I can (and probably will) run some tests to see if my "count of decouplers between tank and root" is equal to one of the Part member variables. The trouble with all this is that the game allows you to create a vessel where the decouplers are not in a simple sequence and/or the root is not in the last stage. The simulation code in KER (and MJ uses something virtually identical) uses a strange function that scans up through the parent links looking for decouplers to determine in what stage a part is decoupled because there doesn't seem to be any member of the Part class that is set correctly. However, this entire approach is flawed because it is possible to create a rocket whose root part is in the initial launch stage and when this gets staged, all the wrong parts get removed from the simulation because it causes the parts above the decoupler to be removed from the vessel rather than the ones below. I've done some thinking about how to fix this (see the KER thread) but, to do it properly will probably require the simulation code to actually split the part tree into two separate vessels when a decoupler is fired (just like the game does) and either decide which is the important one or possibly continue simulating both of them. I also would like to see the staging mechanism overhauled. It could be very useful if anything that can be added to an action group could be assigned to a stage, effectively making the stages into a list of action groups. I would particularly like to be able to decouple docking ports and extend solar panels using staging. I would also like to be able to remove engines and decouplers from the staging list (there is at least one mod that allows you to do this).

I suspect there are a number of bugs in the core code that puts a vessel onto rails. There seem to be various issues in 0.23.5 that could be explained by this. I would check the output_log.txt for anything nasty around the time the vessel goes out of range (e.g. a null reference exception or similar) as this would interrupt the code putting it on rails so some important things might not get done. Generally speaking, "mark and sweep" garbage collectors are very reliable but it is still possible to cause leak-like issues if you accidentally keep hold of a reference to an object that you shouldn't. All other objects it references, and so on, recursively, will not be collected. In event driven systems (where you generally pass an object reference to several other objects) this can happen even if you are quite careful...

I suspect you will need to give more information. Is this during timewarp (either physical or non-physical)? Does it happen if you go to the station immediately after running the game? Does the station have SAS and/or RCS enabled? Are you trying to move the station? What have you done before you switch to the station? Are you using any mods? Etc, etc, etc... Pictures, video and/or the persistence file (or a quicksave file) may be required for an accurate answer...

Right, well, basically the structure of your craft is one that is known to give KER problems. The method used to determine which stage each part is decoupled in has a serious flaw causing the staging to not simulate correctly if the root part of the rocket gets decoupled. Basically, the simulation does what I described in #902. Even though the engine is initially active, the flaw causes KER to think the payload is what is being decoupled and, since it doesn't have any active engines or fuel, it does this immediately. The engine and fuel tank are still attached to the root of the vessel (and the decoupler is as well but this doesn't cause an issue) so the deltaV shows up in S0 (and is higher than it should be because the test weight has gone). I think I can fix this in the simulation code without needing the full vessel splitting algorithm I described above but I am currently in the middle of fixing it to correctly take into account which engines are currently active when in flight, so it gives more sensible numbers when you manually activate and/or deactivate engines, so it may take a little while before I get on to it. It would make more sense if you rearranged the vessel so the test weight was the root part (I assume this is possible with the test weights) as this would allow you to detach the transfer stage and make it a subassembly so it can easily be attached to the real payload and would also allow KER to simulate it correctly. These two craft files are simplified, stock only versions of yours. The bug one is the same arrangement as yours and the fixed one is rearranged to work properly. Bug Gaiiden.craft Fixed Gaiiden.craft

This is a subject that would benefit from an in-depth analysis along the lines of your fuel flow thread (though there probably aren't as many cases to consider). I believe (mainly from the evidence of the MET, I haven't done any explicit tests) that when you dock one craft to another it re-roots the craft you are flying to have the docking port as the root before attaching it to the destination port. I don't know what it does when you undock again, it may leave it with the docking port as the root or it may remember what the previous root was and reset it when you undock. It would also require some sort of plugin to display (or at least log) info about the crafts so you can see what the root is at any particular point. The latest version of KER has some useful code for dumping out the whole of the part tree. I'll have a look at adding a button to the engineer tweakable window that simply dumps the part tree to output_log.txt and then run a few tests...

This doesn't make sense. Are you actually running KSP 0.23.5? Does it behave the same if you replace the test weight with a standard command pod? After the decoupler fires when stage 0 is activated there should be no engines (or fuel) attached to the craft so there should be no way that S0 can have any thrust or deltaV. Do the stage labels (S0, S1 etc) always not line up with the data in the window? I have never seen this happen in any version of KER that I have run or in any other users' screenshots or videos. Is there any particular reason that you haven't provided the craft file (and a list of the mods it uses) for me to look at? It really would help diagnose the issue if I could run a debugging build of KER with your craft to see what the simulation code is doing.

Well, originally the simulation was timed and then it would wait for ten times that long before running it again. For simple craft on decent CPUs this results in it running far more often than necessary and on very complex craft, especially on slow CPUs, it could update very slowly, e.g. if one run took 500 ms then it wouldn't do another run for 5 seconds (this is especially annoying during development when the output of lots of log messages makes the simulation run very much slower, my 370 odd part ARM tug launcher can take over 5 seconds with maximum debug trace meaning it wouldn't run again for nearly a minute) . The newer simulation code uses a different strategy, it times the simulation and then subtracts that time from 100 ms and waits for that long (if the simulation took more than 100 ms it doesn't wait at all) so it basically tries to maintain a rate of 10 updates per second. The tweakable slider simply lets you adjust that 100 ms anywhere from 0 ms to 1000 ms in 10 ms steps (except that the KSP sliders snap near the ends so it goes: 0 ms, 50 ms, 60 ms, 70 ms etc. and the same at the high end, e.g. if you are within 5 times the step of the end then it snaps to the end).

Sim time limit The Build Engineer adds this in the VAB/SPH and the Flight Engineer adds it during flight. It controls the amount of time in milliseconds between one run of the deltaV simulation and the next one, so setting it to 200 should give approx. 5 updates of the build engineer or the vessel tab of the flight engineer per second. Setting it to 1000 should give 1 update per second. This allows the user to find a decent compromise between speed of update and impact on game performance. Pressure % The Build Engineer adds this in the VAB/SPH. It is not present (or shouldn't be) during flight. It sets the percentage of sea level atmospheric pressure that the "Atmospheric Stats" button uses to calculate the deltaV so you can see figures for different altitudes. This value may be changed at some point to be the actual altitude, 0 to "top of atmosphere, of whichever body is selected" if I can figure out how to dynamically change the range of a tweakable slider while running. This may also require the tweakable slider to use a logarithmic scale to give enough control which they don't support by default (if I can work out enough dynamic control of the slider then I should be able to implement the logarithmic part myself). Both of these settings are saved in the craft/persistence file so this allows you to set a larger delay for larger vessels and it will remember the setting. Thanks for that. Can you either provide the craft file (you can PM me a link if you don't want it public) or answer the following questions: Which is the root part of the vessel (the part that lets you move the whole thing in the VAB)? Which part does the decoupler remain attached to when you trigger it? It looks to me as if the decoupler is simply removing the test payload from the rocket, and KER is assuming that since no engines or fuel are removed then it is ok to fire that stage. This is an area that is very tricky to simulate without user input. Really the user needs to be able to specify how long the first stage should burn for and then fire the decoupler and go on to simulate both resulting vessels (assuming they both have workable engines and a way of controlling them). I have a plan for how this could be implemented in the simulation code (it would require some substantial reorganisation of the code) but working out how to present the controls and information to the user in a nice way is quite awkward especially for someone with my level of experience with doing UI things in KSP/Unity. This would basically become the bones of a mission planner. The idea is to allow the user to specify that any particular stage should only burn for a certain time (or possibly a percentage of the available fuel because setting an accurate time would require backtracking in the simulation which would be inefficient). E.g. for a simple vessel consisting of a pod with fuel and an engine on top of a "lifter" that also has a pod this might initially look like: Stage 0: 3000 kg, 1600 m/s Stage 1: 50000 kg, 5000 m/s The user could set the burn of stage 1 to give it enough deltaV to reach LKO and the display would change to show something like: Stage 0: 3000 kg, 1600 m/s Stage 1b: 8000 kg, 1000 m/s (values for the remaining burn of the first stage after separation) Stage 1 (90%): 50000 kg, 4600 m/s (values for the initial part of the burn of the first stage) However, it starts to get more difficult to lay out the data for more complex designs where the vessel may have to split into more than 2 independent pieces. It should also be possible to allow docking ports to be undocked at particular points (e.g. to create a "dummy" stage that decouples a port) and re-docked again. It would also be nice to be able to specify that detached sub-vessels be re-docked either back where they were or to a different port or even a different sub-vessel. It should even be possible to create "dummy" stages that activate or deactivate engines out of the normal staging sequence. As I said, working out a decent UI for this will be tricky and it will also require various other, quite complicated bits of code in the simulation. It will need to be able to accurately simulate what happens when a vessel splits into two getting the part trees of the two vessels correct. Rather than simply being discarded, all the decoupled parts need to be put into a new vessel tree using the correct part as the new root. It would also need to correctly handle some odd cases, e.g. if you build a rocket with the root part being the first decoupler to fire then the current simulation code stops generating stats for all the later stages, or if you put a decoupler on "upside down" so the side that remains attached is connected to the parent part (and hence, ultimately, the root of the vessel). None of this is impossible by any means but it would require quite a lot of careful thought and it isn't really worth me starting to do that until I can come up with some ideas for the UI so, it is unlikely to happen in the near future...

I mean the "Show All Stages" button in the KER Build Engineer window. It shows the stages that it thinks have 0 dV and may shed light on what is going wrong...