Padishar

I believe it uses a Markov chain type mechanism to generate the description text which results in some being very odd indeed... I only ever look at them for the novelty value, the important info about the contract is reported much more precisely...

Well, that does look a bit strange though I don't remember if the same pattern occurs with the "Hamachi" issue. The audio files are each taking about 3 seconds to load. The first chunk of textures (from Agencies and Contracts) load very quickly but then everything from Flags onwards again takes 3+ seconds for each one. Presumably the code that loads the Agencies and Contracts textures is a little different and this may indicate a potential way of Squad working around this for the other files...

I'm not picking on you explicitly, loads of people have said similar things, but, I don't actually think this is true. Sure, there would be some complaints, but I think the number is being exaggerated and could be significantly lessened by clearly explaining the assumptions the calculator makes and coding it so that when difficult situations are detected, the numbers that are "incorrect" would be flagged as having a problem. E.g. for the classic case of root part being decoupled in an early stage, the numbers for the stages after the root is decoupled could have a warning triangle on (or be a different colour as suggested above) and putting the mouse over it would open an explanation of the issue, "the calculator can only calculate the deltaV that the defined stages can apply to the original root part of the vessel, the root part is being decoupled in stage <n> so all following stages do not provide it any deltaV". The other classic is deciding when a stage that decouples stuff but doesn't affect the engines or fuel quantities should be staged, e.g. you can have a "stage" that just ejects a fairing and you fire this part way through the burn, the exact time that you eject those fairings will have a noticeable effect on the deltaV. In this case you could either provide a way for specifying the timing (or fuel use) of each stage or you could simply pick a time and flag the relevant readouts as being inaccurate (e.g. both the fairing stage and the one before would have indicators and an explanation "the calculator can't determine when stage <n> is fired during the mission so the numbers are calculated assuming it is fired at <whenever>.") As for how difficult it is to implement, I'll be the first to agree that it's a much more complex thing to do than it initially appears. The mods that do it need to reproduce a lot of stock code for determining which tanks are being drained at what rates. The "rules" are complex and not documented well which makes it more difficult to account for edge cases. If this work is done at the same time as the rework of the resource handling system then the data structures that store resource information in parts and the code that determines fuel flow etc could be made shareable between the part code and the code that simulates the vessel, e.g. it has to create a "copy" of the vessel to simulate it (at least those bits of the data that affect the calculations) and if this simulation copy can use the same data structures and code as the actual resource draining code then there will be a lot less room for error. Currently, various important parts of the information are derived from Unity classes (e.g. PartResource is actually a MonoBehaviour) so can't be "directly" copied and couldn't be passed to other threads for calculating in the background.

Yeah, I understand that, needing to download and install something complex to diagnose a problem can be a pain, especially for users with less technical knowledge. Luckily, baretail is a plain exe, so no installation is necessary and you just have to confirm a security prompt or two (depending on browser and OS settings). Then it's a simple matter of dragging the relevant log file into the window...

Great advice though you may find it easier to Google for a program called baretail and open the log file in that. It will display the file and update live so you can see exactly what is happening.

@JPLRepo's advice is the most important thing when reporting any issue with KSP or mods. However, in this case, you have almost certainly installed the mods incorrectly. For KER you should have a folder called KerbalEngineer inside the GameData folder in the KSP install. You should definitely not have a GameData folder inside the GameData folder. If you do then simply move everything from the "inner" GameData folder (the one that doesn't contain a Squad folder) into the "outer" one (the one that does contain the Squad folder) and then delete the empty GameData folder. For the other mod, it should also be a folder in the GameData folder. Are you in sandbox mode or career/science mode? If the former then the parts should be available when correctly installed, but if in career or science mode then you may need to research and/or unlock the mod's parts in the R&D building.

This bit means it is a 32 bit version of Windows. The game has a number of issues that cause it to gradually (well, fairly gradually) use more and more memory until it either reaches the address space limit of the process (this is 2GB on Win32 so the game can only allocate ~1.7GB, on Win64 the 32 bit version of KSP has a 4GB address space limit and can allocate ~3.5GB, the 64 bit version's address space is effectively unlimited) resulting in a crash or your machine runs out of physical memory resulting in either a crash or the game running so slowly that you'll probably rather it crashed... So, the only thing you can do is reduce the memory usage of the game as much as possible. The usual ways are to either reduce the texture resolution in the settings (on my Win32 3GB laptop I run at minimum, 1/8th res) or to use the -force-glcore or -force-d3d11 command line options to force use of either OpenGL or DirectX11, either of which should reduce the memory usage considerably (though they may introduce various rendering artifacts). Also, your KSP folder has 1.0 on the end. Are you actually using version 1.0 or is that just left over from when you were? Have you tried using the latest version (1.1.2) instead?

How about you stop shouting, tone back the attitude in your posts and go and read the last two devnotes which make it very clear that they aren't sleeping...

See my second edit, makes life a bit easier, at least you may not have to add a PartModule to every part just in case...

Because the game only calls it on PartModules that implement the interface... If you actually mean "Why does the game only call it on PartModules that implement the interface?" then you would need to ask a Squad developer, preferably the one that originally implemented it if they're still around. I haven't looked through any older versions to be certain but, since ModuleAsteroid is the only stock class that implements it (so that unclawed asteroids revert to their asteroid name rather than becoming "MyFunkyAsteroidTug-Ship"), I suspect that it was actually added in 0.23.5 (the ARM update) which was well before VesselModule existed... Edit: I also suspect there is a quirk to how it is called, e.g. it is only called on the first part in each new vessel that is created. This would work fine for asteroids. So, depending on the tree-structure of your vessel and which part(s) has the PartModule that implements it, you may find it doesn't always get called. For example, if you build: Pod Decoupler Fuel tank Probe core Fuel tank Engine ...and have all pods and probe cores implement it then you may find that it doesn't get called on the Probe core when you decouple and the game instead checks the top fuel tank to see if any of its modules implement it... Edit 2: Actually, it's "probably" better than I expected. It should call the GetVesselType function on every PartModule (that implements the interface) in the vessel, sort them in descending order of vessel type and then call GetVesselName on the "first" one...

This line implies he is running a 32bit version of Windows so the game can only allocate ~1.7GB before it will crash. This would be my guess too. I presume the "delete local content" didn't get rid of settings.cfg because it isn't part of the original install.

The game is only available for purchase online...

Perhaps try reading the thread, it's only two pages...

It would probably be better if it were a stock feature of the targeting system, though I can see a way of doing it with another mod that I'm writing. The recent release of 1.1, the imminent release of 1.1.3, and my current crusade against garbage thrash have kept this on the back-burner but I hope to get back to it fairly soon, if only with a proof-of-concept development release.

The thread below gives all sorts of information about how you can troubleshoot your modded game including details on where to find the log files that indicate what mods are being loaded and what they are doing...

Yes, I can see this could be useful (at least for when a vessel is the target, less useful for a celestial body) so I've sent a PR... However, I suspect cybutek is likely to wait until the release of 1.1.3 before releasing a new version...

Yes you should. And also an output_log.txt/player.log file (see the How to get support sticky thread for details of everything you should do).

If the game maintained a list of ports then further optimisations wouldn't be nearly as necessary (though I would like to be able to disable ports). It's the nested loops of partmodules within parts within vessels that really hurt and these would completely disappear. Only if you had an extreme number of active ports would there still be any issue...

Well, not really, though it is related. Claws are not docking ports, they use ModuleGrappleNode instead of ModuleDockingNode and they work in a very different way. Each claw doesn't scan all the parts in the physics bubble though it does do a raycast to detect if they've hit something and this can also be quite slow (especially when there are a lot of parts around). I believe there was also a specific multi-claw issue in earlier versions that was "fixed" quite a while back. Yes, there is. As was mentioned earlier in the thread, the best way to fix docking ports would be for the game to maintain a separate list of all the ModuleDockingNode part modules that are currently loaded. This would hugely reduce the CPU needed. There isn't a similar way to fix claws as they don't do a scan (well, they do but it's inside the Unity raycast code). While this would be a nice feature to have anyway, it wouldn't do anything to improve the scans done by the ports that are active. They already do. It's only ports that are in the "Ready" state that do the scan.

He didn't call you lazy, nor did he ask for your life story. Also, your "child" remark is horribly condescending. If I had to guess based on the very limited information available, I would say he's probably in his early thirties, e.g just like you used your birth year in your username, I suspect he did too... So, in your opinion, which particular "bug" is he experiencing? I think you're being condescending again here but I can't actually work out what you are trying to say. Again, what bug do you think it is? His problem (it isn't really a bug because it's expected behaviour) is that his game is running out of virtual address space and failing to allocate memory because he is running on 32 bit windows where the game can only use ~1.7GB. The only actual bugs he is having are probably the memory leaks (mostly on scene changes) that cause the memory usage to grow over time. In any case, neither of your messages in this thread have been at all helpful and they certainly don't give a very good impression to a newcomer to the forums. Are you deliberately trying to drive people away?

If your CPU supports 64 bit windows then that is easily the best course of action. On 64 bit windows, even the 32 bit version of KSP is able to use 3.5GB of memory and the 64 bit one is basically unlimited.

RAM is most definitely the issue. On 32 bit windows the game (like any other process) can only use a maximum of about 1.7GB of RAM. Once KSP tries to allocate more than this it will fail and usually crashes. Sometimes, the initial failing allocation will not crash the game and this can result in strange rendering (e.g. the internal VAB textures being missing) or other weird effects but the game will usually crash pretty soon after. Your only real solution is to reduce the memory usage of the game. There are two main ways to do this, either reduce the texture resolution to the minimum setting or run the game with the -force-glcore or -force-d3d11 command line options.

No, that sounds about right. However, note that, even with my 1410 part vessel with 24 active ports, it "only" uses about 8% of the CPU so you have to get to serious part numbers before it makes a large difference...

Yes, a new save with a single test vessel would be best. Launch it, quicksave, search the .sfs for ModuleDockingNode and look a couple of lines down for the "state = " line.

Can you explain why you think a mention of "leaky meshes" supports your "analysis"? Or was there something else said that you think supports it?