Padishar

Contract Configurator runs some complex stuff in the background for a while after you initially load and then it stops. It only seems to cause the slowdown while this background work is being done. I think this is all explained (or at least mentioned) in the CC thread...

The log shows that those exceptions are happening in ContractConfigurator: ArgumentException: No PartModules found for type 'Wheel'. at ContractConfigurator.Validation.ValidatePartModuleType (System.String name) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.All[String] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at ContractConfigurator.PartModuleTypeUnlockedRequirement.RequirementMet (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.CheckRequirement (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractRequirement.RequirementsMet (ContractConfigurator.ConfiguredContract contract, ContractConfigurator.ContractType contractType, IEnumerable`1 contractRequirements) [0x00000] in <filename unknown>:0 Rethrow as Exception: ContractConfigurator: Exception checking requirements! UnityEngine.Debug:Internal_LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) ContractConfigurator.LoggingUtil:LogException(Exception) ContractConfigurator.ContractRequirement:RequirementsMet(ConfiguredContract, ContractType, IEnumerable`1) ContractConfigurator.ContractType:MeetExtendedRequirements(ConfiguredContract, ContractType) ContractConfigurator.<ContractGenerator>d__27:MoveNext() ContractConfigurator.<ContractGenerator>d__26:MoveNext() ContractConfigurator.ContractPreLoader:Update() Exactly why is not clear but, assuming you are using the latest version, there is probably an incompatibility with another mod. Try having a read through the last few pages of the mod's thread: ...and, if it isn't already mentioned then post there. Also, it would be a good idea to suggest to them that it could be very useful if their exception handler could output a little more info about what part it is (there is a KSP class called Wheel but no (obvious) way of knowing what part it is having the problem...

Is there any chance you have a simpler craft that shows this issue (e.g. one that just uses stock parts and maybe some KSPIE ones)? You have a lot of mods installed and I don't really want to spend time duplicating that entire setup just to be sure I have the mods required to load it...

Are you still able to repeat this using the latest version of KSPI? When I try I get the following with no trace of jumping numbers: Can you upload a craft file and a log of it going wrong?

Probably not necessary, there's only so many things that could possibly be causing that exception in that function. Most likely is that FlightGlobals.ActiveVessel is returning null. However, I wouldn't expect this to be causing any other issues as the exception is caught inside the KER code and shouldn't affect the core game or the other mods. Other mods having the same issue that don't catch the exception themselves may cause knock-on issues so it's probably worth looking at the following exceptions and letting the mods concerned know...

Yes, there have been reports of various issues between KER and IFS. These stem from the changes to IPartMassModifier (and other restrictions on what mods can do to part masses) in KSP 1.1. The changes I made to KER in 1.1.0.2 have not been extensively tested and I've not yet had time to investigate the issues in detail. However, like I said above, this appears to be more an issue with simulation of the fuel flow rather than the masses of the parts. though I will try to find some time in the next day or so to investigate it fully. Do the values change by themselves for you (i.e. switch between values that look correct and ones that don't) or does it always show the same wrong values?

There really wasn't much point in you posting this, considering the issue is already mentioned in one of the sticky threads in this sub-forum: As far as I'm aware, this has been an issue in every version of KSP since I started playing (0.23). Unfortunately, people having a slow loading issue are rather unlikely to find this thread as people don't generally bother to search first at all (or even read the sticky thread mentioned that talks about known issues), this thread isn't exactly named very helpfully if they do search and it will probably drop off the front page fairly quickly so is unlikely to be stumbled across.

I'm sure that thread mentioned uploading it to a file hosting site rather than including it directly in a post, but never mind... Anyway, the log doesn't show anything of much interest. About the only other thing I can think of is that you have VSync forced on in your video card drivers so it is ignoring what KSP tries to do. There used to be an issue where each update of the loading progress screen would wait for vsync (or the framerate limit) so it could only do 60 updates per second. KSP has, for quite a long time now, forced vsync and the framerate limiter off during the loading screen to avoid this issue but if your video driver is set to force vsync on for KSP (or for everything) then this might override it and make the startup slow...

The torque and thrust offset readouts do not consider drag at all. They would consider a slightly shifted CoM if the KER part caused that but I also suspect that KER would try to add the mass to the parent part anyway and so wouldn't show any torque even if there was a bug in the core game causing there to actually be torque during flight. Specifically, a value of zero (the default if the value isn't present) corresponds to the Part.PhysicalSignificance.FULL enum value and a value of 1 corresponds to the NONE value. I believe that NONE is supposed to mean that the mass and drag of the part is added at the parent part's CoM rather than its own. This should result in a single surface mounted KER part not causing asymmetrical drag if it is attached to a part whose CoM is on the centreline of the vessel. There may be a bug (or an undocumented or unnoticed change) in KSP 1.1 that has caused this change (if the change is actually real and not caused by some other factor not being considered) but it will require a series of carefully arranged tests to determine if this is the case...

Yes, the strangest part of all this is how it affects different people in different ways. I've been looking into it for a long time and I am yet to find any definite pattern. Yes, I've tried calling the GC directly (shudder) and it generally doesn't help much. I've also tried various things to pad the heap and, while these do help initially, Unity (at least in Unity4) very quickly frees up the padding due to how the heap management works (all still used blocks get shifted down as part of the GC, moving all the free space to the end and when it sees it has several hundred megs it isn't using it gives most of it back to the OS). I also built a version of your GCMonitor that defaulted to Mono mode and 0.125s and only had the graph in the window because the set-up of the controls at the top of the window was doing quite a lot of string concatenation and it was skewing the results of some tests I was running. If the allocation rate could be got down to a few k per frame (or even a few k per second) then the garbage collection would run much less often (e.g. once every few minutes rather than once every few seconds) and, I suspect, almost no-one would complain about it. At that point it would probably make sense to manually run the GC at points the user won't really notice, e.g. going into and out of map view, pausing the game, saving (including autosave), switching between vessels etc.

Well, things like the stock altitude display have no real need to allocate memory on every frame or when the numbers change, Sarbian was referring more to textual items that need to be specified to the Unity API as a string. Strings are immutable under the CLR so if your code just blindly takes a numeric value and converts it to a string on every rendered frame then this will create a new string object every time. The usual way to combat this is to only recreate the string when the numeric value changes, though this only makes a significant difference for things that do not change very often. For things that do change very often it will make a lot of difference simply not updating it on every frame, even every other frame would reduce the number of new strings created by a factor of 2 and updating a flight data display 30 times a second is still probably far more than necessary. Between 3 and 5 times a second would probably be plenty for most vessel state readouts (between 12 and 20 times less than 60 times per second). In any case, there are still several bits of stock KSP code that are creating far more garbage than is sensible. At least a couple of these should be addressed by the reworking of the resource handling code that got pushed back to 1.2. I would like to see the memory allocation rate down at something like a few kbytes per frame (that should be plenty to cope with creating new immutable strings) rather than the megabytes per frame it seems to do sometimes now...

This problem appears to be that the first stage to fire is burning all the fuel in the whole rocket so there is none left for the following stage(s). Did you notice that fatherdoctor edited his post to say that the community resource pack seems to be responsible? I presume that this is changing the resource flow mode of one of the resources concerned and this isn't being correctly handled by KER. I will investigate further and try to determine the precise cause... Edit: CRP doesn't do anything to the stock resources. Next thing to look at is if KSPI includes any MM scripts that mess with the stock resources (and that only work if CRP is installed). @fuzzywolf, can you run a test? Run the game and load that rocket in your screenshot, then click the Settings button in the KER window and click the button by "Verbose Simulation Log". Once the button pops back out, quit out of the game and then upload your output_log.txt file somewhere I can take a look. Thanks...

Then you almost certainly weren't getting 25 fps. The in-game fps counter in the debug window does not display rendered frames per real-time second, it displays rendered frames per in-game second. This means that it bottoms out at 1/(Max Physics Delta Time) due to how the game slows down real time when it can't keep up with the physics simulation, anything lower than that will require a different tool to measure the fps. I generally use the GCMonitor mod for this but external tools such as Fraps will also give a real-time number. The biggest confusion about the performance improvements seems to be among people whose game was already GPU limited. In these cases, you will not see much of an improvement at all and may even see a slowdown due to differences in the graphics shaders being used. The large performance increases happen where your game is heavily CPU bound which tends to mean having a significantly large part count vessel. E.g. I have an i7-4770K and GTX560ti and my 1410 part station that got between 2 and 3 fps in 1.0.5 now gets 8.4 fps in 1.1. A smaller station (just over 300 parts) that managed a little over 20fps in 1.0.5 is now in the high 50s in 1.1. Those are seriously significant performance increases...

Your log shows the game starting correctly, you changing settings, flew a tutorial scenario (not sure here, you went straight from main menu into flight), loaded a saved game, created a vessel in the editor, flew it, and then quit out back to the main menu before quitting. Also, there is no indication of you having any mods installed. The game overwrites the log on every start of the game so I presume that you tried again without the mods installed and lost the potentially helpful log file. If you can test it again with the mods and upload the log from the problem run then I'll be happy to take a look...

Please supply an output_log.txt file from one of these very long starts. Details in here:

This has been fixed in PR #91 and should be in the next release.

Please see the sticky thread in this sub-forum for details of how to provide a log file: The log almost certainly contains more information about these errors (e.g. a full stack trace showing where in the code the problem is happening).

[citation needed] Specifically, I don't recall ever seeing a post from a Squad "developer" (someone that actually writes code) that says anything like that. While it is true that they are unlikely to be able to completely eliminate it, there is plenty they can do to reduce both the severity and the frequency of the stutters. I've posted about this before in the threads I indirectly linked to above.

Sorry, when I downloaded your output_log.rar I already had a file called that in my downloads folder and didn't notice that yours was renamed to output_log (1).rar. I thought it was a bit odd you using such an old version...

That log shows you running KER 1.0.13.0 in KSP 0.90. Is there any particular reason you're running such an old version? It isn't really obvious what's wrong from the logs other than an exception is occurring in the code that KER uses to update the various data readouts. I don't immediately recall any similar issues from back in the 0.90 days and I don't have time right now to go trawling through the git history to work out what might be wrong...

The usual cause of extremely long loading times is using programs that create virtual network adapters but that should have been an issue with 1.0.5 too. Do you have Hamachi installed or are there any odd looking network adapters showing up in control panel? If so, then try disabling them...

Yes, there have been a number of changes to the steam launch process over the last few days. At one point it was defaulting to 64bit and at another point I think there was a dialog allowing you to choose. I'm not actually sure what it currently does. On a different matter, Kerbal Alarm Clock appears to be failing to load. Does it appear in game? Looks like it needs another update...

Your log shows you are running the 32bit version of the game. Not sure how you're launching it but try running KSP_x64.exe directly from explorer instead.

Because you pass the OnWindow function to the GUILayout.Window function to create the window. This basically says "create me a window and call the function I've given you to get the contents". You define it initially as a new Rect which will have all the values it contains set to 0. The GUILayout.Window function uses the rectangle you pass in to decide where and how big to create it but it can end up being different to what you specify. Because of this it returns the rectangle that it has actually used and you store this away so next time you are passing the correct values. This is important for GUI.DragWindow to work as the rectangle returned will move on the screen when the window is dragged.

Unfortunately, it appears that you restarted the game after the crash before uploading the log because there is no sign of a crash, it appears that you exited from your save out to the main menu and quit normally. The game overwrites the file every time you start the game so, when you do get a crash, you need to upload the log straight away (or at least copy it somewhere else and preferably rename it, e.g. output_log_crashinvab.txt). Also, just saying that your game is crashing is not very helpful. How does it crash, what were you doing etc.?