Padishar

I believe that closed shielded ports are in a different state (Disabled rather than Ready) and therefore don't do the search but I don't think them being inside bays, fairings or service modules will affect it. Basically, any docking port in the Ready state (should be visible in the save file) will do the scan.

Well, yes. That's exactly what it is doing, but it looks at all the parts to find docking ports and checks those for distance. This would be the really important bit. Having the code maintain a list of all the docking ports within the physics bubble would make the code very much quicker. I assume you mean a way for the player to disable vacant docking ports and then they would only enable the ones they actually want to dock. Yes, this could be done, and it would make quite a difference when there are a large number of ports, However, it would still need the list of ports to optimise the scan for the ports you do enable. The code that checks if a particular port is within range and in a good enough alignment to trigger the magnets is pretty decent, the real killer is having to search the partmodule list of every part of every vessel in physics range just to find the docking ports which would still need to be done to test the "active" flag...

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range. So the performance impact is at least proportional to the number of docking ports multiplied by the total number of parts in the loaded vessels. For example, the station in my avatar is 1410 parts of which, 120 are docked ports holding it all together, and 24 are vacant senior ports. Nearly 9% of the total CPU time is spent in ModuleDockingNode.FixedUpdate (and another 22+% shuffling EC around the Vessel from the 360 solar panels and 42 probe cores). Eliminating (or greatly reducing) these two parts could increase the framerate by nearly 50%... The ion engine (when firing) uses a fuel flow mode that involves searching through the whole vessel for fuel tanks both when calculating how much fuel is available (for the fuel gauges) and for actually transferring the fuel. This uses considerable CPU time and also generates a considerable amount of garbage.

The "stutter" isn't a bug, as such. It is caused by the developers not following certain coding principles during early development when the impact of the excessive garbage creation was much less noticeable. As more and more code has been written the problem has got progressively worse. I could see the stutter back in 0.23 though it generally required stressing the game quite considerably. In the latest versions I can clearly see the stutter even in some very low stress situations. I'm not, in any way, saying that the new guys won't solve (or at least improve) the issue. I (and others) have been investigating the worst garbage sources for some time and communicating with the devs about them and I'm pretty confident that 1.1.3 will see a significant improvement in this area and 1.2 should see even more...

Surely the rest of the paragraph you quoted from makes it clear that this is "effectively impossible" and will not be done. Just wait, if it's in QA now it will be in Experimentals shortly and you'll get it soon™. (And no, I'm not calling you Shirley)

When reporting a bug with either stock KSP or with a mod you really should include a log as this will almost certainly indicate the source of this type of issue. Details of where to find this log (and other information about what you can do yourself to locate the source of problems) can be found in the sticky threads in the technical support forums. However, in this case, it sounds like you have simply installed the mod incorrectly. Make sure that you don't have a GameData folder inside your GameData folder. If you do then simply move everything in the "inner" GameData folder (the one with the OPM stuff in) into the "outer" GameData folder (the one with the Squad folder in) and then delete the empty "inner" folder.

I really don't believe you are. This is a common mistake players make due to the totally unhelpful stock fps graph. It doesn't show frames per real-time second, it shows frames per in-game second. This has the effect of making it bottom-out at 1/<max physics delta> fps (1/0.04 = 25fps) regardless of how many actual fps you are getting. If you change the max physics delta option in the settings you will see a corresponding change in what the graph displays. If you set it high enough you will probably start to see variation in the graph again (the max value of 0.12 should measure down to 8.33 fps which should be doable for 1049 parts). There are various mods that give an accurate fps indicator or you can use an external tool such as Fraps to do it. According to the latest devnotes, it has been...

This thread gives details of where to find the logs and what other information would be useful...

Nice... What framerate do you actually get? 945 parts is quite a lot, even for the latest version. On top of this, there are some aspects of the design that are known to significantly stress the game. You have an awful lot of solar panels, each of which has to calculate their angle to the sun and whether they are in shadow, and any that are producing EC have to add it to the EC storage which currently scans the entire vessel. You also appear to have quite a few (20+?) lights which also have to scan the entire vessel to get their EC and also contribute extra to the rendering load. You will almost certainly get a measurable increase in framerate when on the dark side of Kerbin and if you turn the lights off it will be better still... Hopefully, Squad's plans to rework the resource system should improve those aspects. If you really want to see slow, then turn on your RCS, give the station a little 3-axis spin and then turn on SAS. When I do this with one of my smaller stations (only 308 parts) the framerate drops from 60 to <20 and I get a GC stutter every 3 seconds rather than them being nearly a minute apart. I also suspect (though I haven't yet confirmed it) that the labs might be using a significant amount of CPU. Does it improve if you shut them down (maybe by taking the crew out)? As for it being scary when approaching this sort of thing, yes, I agree. When I was building the station in my avatar which consists of 42 vessels launched on 6 separate rockets (5 "edges" and 2 "vertices" each), I was running on a potato of a laptop and I missed my "braking" burn a couple of times because the game froze for over a minute when coming into physics range. Luckily I missed the station though, on one approach, I did have to burn off-retrograde to make sure...

Indeed. @KasperVld!

Well, there shouldn't be but the various steam related extensions include native code (not just C#) so there is an inherently higher risk of an issue in that code causing a game crash rather than just logging an exception and continuing to run fine. This isn't really true. The exe in a Steam version is exactly the same as the one in the store download (certainly the last time I checked) but there are a number of Steam-only DLLs/libraries, both managed code and native that could, potentially, be causing issues when not run from Steam. I virtually never run the game from Steam or even run the version installed by steam directly at all because I like to keep the steam version totally stock and unmodified so that updates don't cause a problem. I always copy the game from the Steam folder to another location (I have a C:\KSP folder that currently contains 49 different installs of various different versions going back to 0.23) and run it from there. I do see the steam related errors in the log but I very rarely have crashes from any version (that aren't obviously caused by out-of-memory issues or me making silly mistakes in mod code ).

Why have you posted this? In what way is that page at all relevant to either the OPs problem or anything I wrote? If you think the bit that says "can directly access at most 4 GiB of byte-addressable memory" supports your argument then you are mistaken. It clearly states "(though in practice the limit may be lower)", which in the case of 32bit Windows operating systems, it is. User mode processes can only address 2GB of memory. The exe and all the (non-system) DLLs it uses are included in this 2GB so the amount of memory that can be allocated is significantly less than 2GB. I have been a professional computer programmer for over 23 years and was a highly talented and knowledgeable amateur for the ten years before that.

The log clearly shows that this is an out-of-memory problem (just like it clearly shows his screen resolution and what GPU he has). KSP can sometimes use very slightly more than 1.7GB on Win32 (e.g 1.8GB of "commit size") but any more is totally impossible (without tweaking the Windows boot-time option that increases the address space available to user mode processes and this is likely to cause other issues and is not a good solution). Yes, I know that, my reading comprehension skills are really quite good. This is why I wrote:

It doesn't suggest that at all. It simply says that the video driver failed to allocate memory for a texture and the game crashed shortly after... Again, no it isn't. That is just the size of the texture that the video driver was trying to allocate, it has absolutely nothing to do with the screen resolution which the log file clearly shows is set to 1366x768. This is the important bit. The game can only use a maximum of approx 1.7 GB of memory on 32 bit windows and it is simply exceeding this amount and crashing. You will need to do something to reduce the memory usage. The first thing you should try is to find the TEXTURE_QUALITY = line in the settings.cfg and change the number at the end to 3 which will change to using 1/8th resolution textures. If the game starts then you may be able to increase this in the settings screen in KSP. The most likely cause of your game working and then stopping working is that the settings file became corrupted at some point and this has caused KSP to use default values, including a texture quality setting that is too high for your system. This line in your logs is also somewhat concerning: [KSP Version]: 1.0.5.1024 (WindowsPlayer) ==================================== This was the original version of the 1.0.5 release before it was quietly patched. The "correct" version for 1.0.5 should be 1.0.5.1028. However, this would also be out-of-date as version 1.1 (and 1.1.1 and 1.1.2) has been released since then. Whether you want to use 1.0.5 or 1.1.2, you should download a new version from GOG...

No, ntdll.dll is a fundamental part of the Windows operating system. This crash basically means that the program passed a dodgy pointer (i.e. a memory address which doesn't actually have real memory behind it or an address the program doesn't have permission to access in the way it is trying to) to an operating system function (probably a memory allocation/deallocation function) and the 0xC0000005 exception code is how the operating system tells the program it has done something very bad. It is not (usually) sensible for a program to continue running after this sort of exception as it generally means that some of the program's data is in a very dodgy state and it is safer that the program just dies than, e.g. trying to write out a save file and corrupting your save. This is a promising line of investigation as the problem is very likely to be caused (or, at least, exacerbated) by multi-threaded code. The VAB/SPH actually do more multi-threading than most other parts of the game. If the crashes really don't occur when set to a single core then this could be very useful information for the devs to know... There is always a log. There may not be a specific "crash" log but the output_log.txt (or player.log on Mac and linux) file is always recreated every time you start the game. Programs do not magically start losing track of of their data once it gets over 4 GB. In any case, plenty of people have reported crashes in stock installs which use significantly less than 4 GB. Assuming that by "garbage cleaning process" you mean the Mono garbage collector, then it certainly isn't deleting things it shouldn't, it simply doesn't work that way. You have to write some seriously hacky C# to cause the garbage collector to reclaim any memory that is still reachable by the program. However, the Unity API does provide a couple of potentially dangerous functions (e.g. DestroyImmediate) which, if used incorrectly, can cause the Unity player to crash in nasty ways. If I had to guess then I would say that some bit of KSP code is probably calling DestroyImmediate on a Unity object which happens to be being used by a background thread at the time and this causes corruption of memory resulting in dodgy pointers being passed to operating system functions and crashing.

The current version of the game is 1.1.2.1260. Unless BD Armory is specifically built for 1.1.0 then you should update KSP to the latest version. Also, on 32 bit versions of Windows you can only run the 32 bit version of KSP. It will only be able to use approx 1.7GB before it will crash so you will almost certainly need to do something to reduce the memory usage (reduce texture res, run with the opengl command line option etc) or you will have regular out-of-memory crashes.

All of those things have been acknowledged by Squad as being issues...

Thanks, I'm only going to be delaying the deliberate unloading that happens rather than automatically unloading after a timer so I think it should be safe... I have now updated the test DLLs I posted before with my latest tweaks. I'm hoping this will reduce the fps drops when panning the camera around even more. As before, simply download this zip and extract the two DLLs it contains into your GameData/Kopernicus/Plugins folder. The unload delay is currently set to 10 seconds so if you stop panning for longer than that then you will still get a glitch when you next pan a body into view. I intend to also make the delay configurable later today... Edit: I have just updated the DLLs again to include the onDemandUnloadDelay configuration setting. This can be set to the desired delay in seconds with the following MM config: @Kopernicus:FINAL { %onDemandUnloadDelay = 30 }

Is this "waggle and spin" in map mode or normal flight? If normal flight then we could probably do with delaying the unload of the various other planet related textures (MapSO, CBAttributeMapSO and PQSMod) so rapid camera movement doesn't cause them to be discarded and immediately reloaded. However, I see there has been timer-based code to do this in the past but it has been removed so I'll need to chat with @Thomas P. about it to ensure there isn't a general problem with doing it. Edit: I've reimplemented the delayed unloading of the other stuff but I haven't been able to test it yet because I'm on a Win32 machine and an OPM install just won't stay running for more than a scene change or two, even with all but a handful of the Squad parts removed and the settings tweaked for minimum memory use. Before I trimmed down the parts it wouldn't even get to the main menu, but now I can manage to put a very simple vessel on the pad but trying to recover it, or even just returning to KSC, crashes it due to running out of address space. I might be able to hyperedit it to another planet but I suspect it will immediately crash so I'll just wait to test it on Win64...

You're welcome...

I'm beginning to think this is a stock bug with escape trajectories. Unlike the decaying orbit while off-rails issue, some people have reported their orbit gaining energy very fast when on an escape trajectory and there were a number of changes to the Orbit class in the last update that could have broken something. I very much doubt that reinstalling KER will make any difference. I'll try running a few tests of escaping Kerbin later this evening and submit an official bug report (or add to an existing one if there is one) if I find anything weird...

It certainly would be magic because the code concerned has nothing whatsoever to do with GC stutter. The bug is not "unnecessary" anything. When a vessel is off rails, Unity/PhysX changes its velocity and acceleration constantly and these calculations are not as accurate as the on-rails orbit calculations. This means that adjustments are required to the off-rails vessel to try to stop the reported orbit changing. There was always a periodic change to the orbit of off-rails vessels but this didn't result in the specific orbital energy changing (much). An attempt was made to improve the drifting orbits and, while it did greatly reduce the periodic nature of the drift, it also effectively caused the energy of the orbit to decrease constantly. Squad have clearly stated that they are looking at this and it should be fixed in 1.1.3 but it has nothing to do with GC stutter and the fix is unlikely to affect the performance in any noticeable way.

It doesn't look like it fixed existing posts with the problem. I'm not sure about whether the editor quoting glitch that caused it is fixed as I'm not really sure how I hit the problem in the first place.

Yes, it does seem the link in the OP is broken (I believe the maintainer had some problem with their forum account). However, there's a link to the new thread in the post immediately before yours...

I'll take a more in-depth look at the full logs a bit later but it looks like your orbit became degenerate and this caused issues both for the stock game and for mods. I don't think there's anything that KER does with the orbit information that could cause KSP to crash even with a "bad" orbit so I suspect some other cause for the crash. The UI related exception in the KER log indicates that the orbit probably changed between two of the calls made to KER's GUI function in a single frame. I presume that several of the readouts disappeared from the KER window while the orbit was dodgy but that it came back once the orbit got better.