Tau137

Ignore

I have been suspecting that there is something odd about latest MM 3.0.1 (have been having issues with patches not being applied, error where were none before), but.... yes, need more testing, logs etc...

@linuxgurugamer: FYI: there is confirmed mod interference with ReaclChutes - stock parachutes drag as if semi-deployed even before activation (mod-added RC chutes work fine). Removing corresponding dll and config (even config itself messes RC-enabled stock chutes) from TweakableEverything resolves the problem. I believe this is new to 1.3.1, as I used both in earlier game versions with no issues. Also reported in RC thread.

Found it - TweakableEverything (parachute config and dll). Removed, as there is no need for it with RC. Thank you!

@allista: Are you aware that you are using wrong conversion coefficients for Monopropellant? You took them from stock mini-tank, and that is the only one (radial tanks are pretty bad, too) that holds almost 3 times as much as it should have, compared to all other containers? As a result, all other non-RCS container (stock and mode), after you patch them, can hold almost 3 times as much RCS fuel as they were supposed to, by volume, and all formerly RCS tanks (except the mini stock one) can only hold 1/3 of other resources (e.g., LFO). If you consider this important (few people would care, presumably, except perhaps those that use NF Spacecraft, where this miscalculation gives almost cheat-leave advantage to monoprop engine over LFO, e.g., on landers), please correct the MM patches; stock mini-rcs tank can be either left extremely overstuffed or, optionally (at your or end-user's choice), nerfed to its proper volume of ~160L. I also noticed some glitchty behaviour with TweakScale, where parts with configurable containers, when cloned in editor from resized parts, get scale factor applied twice (^2) to container volumes... have not figured that one out yet, but it is not a big deal. Otherwise great stuff, I have almost everything "configurable" now, helps a lot with keeping part count low. Thank you keeping up great work, on this and your other mods (I just wish you'd enable orbital option for Ground Construction...)

@stupid_chris: BUG: with the latest RC version, all stock parachutes drag as if semi-deployed before activation. RC chutes work correctly. No physics-altering mods installed,. I checked everything but could not find the root cause (part files, MM patches for RC and Tweakscale, compared to 1.3 configs - everything looks the same). I wonder if anyone else experienced this?

Thank you for quick response and the tip, I will certainly do that. Just looked at the log again - nothing but loading messages for this mod, but here it is (from a crash as I did not have others stored, but that should not matter - crash is unrelated). https://www.dropbox.com/s/fs48g6m28adqm85/output_log.zip?dl=0

@linuxgurugamer: Love this mod (mostly used it to cheat reaction wheels and engine gimbal limits), as well as other great work you do, BUT ...most docking ports (stock) stop working at random. Might connect once or twice, might never connect (fresh ports, no tweaks). Trying to re-dock multiple times, reloading or restarting the game does not seem to help; moving ports with KIS sometimes does. The more complex the ships are, the more likely ports stop working (permanently) - e.g., trying to re-dock interplanetary crewed ship (~70 parts, 5 ports) with its lander (~25 parts, 1 port) is almost impossible). Analyzed everything, scrupulously went through saves, compared before and after, "good" and "bad" ports - nothing wrong, but they still wouldn't acquire! The only extra module in docking ports was from this mod, so I tried removing the tweakabledockingnode (or what's its name) from saves - no change. So I removed the mod completely, and not a single docking issue since. No reason to post logs, as there is nothing relevant (no errors, nothing about docking or this mod, even in verbose mode) in there, and, considering semi-random nature of this bug and a number of mods I have, saves wouldn't be useful either. This bug has been present since at least 1.2.2, but only now I could pinpoint the culprit. My mod list is below. I hope this might help you to track down the issue.

Neat, I did not know that (never played in RSS), thanks!

Thank you for the explanation!

I was pretty certain Kopernicus allowed that... or used to allow?

A question: what is the easiest way to introduce rotation axis tilt on planetary bodies in an existing config (e.g., SVT or OPM)?

This is interesting, but, presumably, graphics (local lighting etc.) would not be calculated in map mode (which is clearly seen in testing, when "time per frame" decreases somewhat, but not enough). And I do not believe I saw any difference between stock settings (8 light count?) in 1.2.9 and my regular setup with that settings maximized (1.2.2). So the core of the problem is not rendering or GPU, it is how mods calls are made (apparently quite irrationally, somehow linked with part count and physics where they should not be). Probably need to make a test with all the mods I can find that have nothing to do with physics or graphics.... just need to yet again overcome this dreadful combination of feelings I have towards KSP - addiction, adornment and frustration.... probably soon, with 1.3 once a reasonable number of mods is updated. Also would like to thank everyone who looked into this thread and started thinking about it (and/or testing) - perhaps we will get something (performance improvement) out of it, eventually, in future versions, assuming Squad ever resumes focusing the development towards more depth and refinement rather than breadth and accessibility.

@diomedea Thanks for the voice of reason. On my part, I will try to be less passive-aggressive.

Thank you for your insightful and extremely informative response, it is greatly appreciated!

1. Irrelevant, as it does work. Also irrelevant because it was not used it the test cases presented. 2. Yep, never argued that. 3. Google! Yes, I never realized it exists, thank you! KAC: this one was brought up as an example of a mod that should not be affected by part count, and yet there is a noticeable hit. Same way as EVE, in theory, should have a "constant" (not dependent on part count) performance hit. Let's consider this simple example: stock vs. visual mods (EVE+Kopernicus+SVT), huge craft. Let's further simplify that each frame game spends most of cycles on graphics and physics. STOCK: 50fps, 20ms per frame. P+Gc+Gu=20 (Physics, Graphics-craft, Graphics-universe) MOD: 20fps, 50ms per frame. P+Gc+MGu=50 (modded graphics - universe). Result: MGu >= 30ms Now let's fly the simplest smallest craft possible (P2+Gc2 << P+Gc): MOD: 60fps, <17ms per frame. P2+G2 + MGu = 17. Result: MGu <= 17ms Anyone else noticed an inconsistency? Somehow the mod graphics (terrain & clouds) work twice as slow for 300 part ship vs. 10-part ship! Or we have to assume that somehow Physics depends on the presence of modded graphics. Either - or, as these mods do not touch physics or craft rendering. Some might say (or direct me to Google) something regarding 3D rendering and how it is done and why computational complexity of drawing an object within a background scene would be affect by the way background is drawn. True, but only partially, and most importantly.... absolutely irrelevant to the argument, as the performance problem remains even in map view with almost nothing to render! Now, what else have we missed so far that can explain this? Perhaps collisions (Kopernicus), that could explain it.... except it does not, because the same behavior is evident without Kopernicus, with just EVE, or with a bunch of mods that have nothing to do with part count whatsoever, and yet each adding a bit of lag on per-part basis! I do not have fps numbers handy for these - I might have time to get those, too, and I encourage everyone to test this "assumption" themselves! Conclusion: physics (or something else related to part-count) is somehow affected by presence of graphics (and other) mods. This means that something out of these mods is being called in each physics processing iteration! And THAT is the problem I am trying to bring up here. So, instead of misdirecting and implying my utter incompetency (it is only partial, not total), would you be willing to run similar tests and present results here? The purpose is to either: 1. Prove that the problem is specific to my computer and vast majority of users are not affected. If that is the case, I'll gladly admit that it is "my" problem, and will shut up. 2. Bring more factual confirmation that the problem does exist. Perhaps it is Squad coders' mistake, perhaps it is an inherent Unity issue - I do not know (again, Unity and C# programming is definitely not my strong sides), but that is even more reason to get devs' attention - in the interest of all players, especially those who actually do extensive career and exploration sessions and build ships and stations with hundreds of parts, those who love the game and want to make it better - even if all they are able to put in the pot is a few tests and observations.

Thank you for the tips, I will check out Memgraph. I always run x64, but not forcing DX11. I should test DX11 and OGL and see if that makes any difference. My main concern is that even utility mods slow the came down in proportion to part count (how clouds can be so much slower on 300 part ship vs 10-part ship? Why it is noticeably slower with just Alarm Clock?) - the rest is kind of self-explanatory, given that any improvement demands some performance sacrifice. UboWelding - I use it occasionally, but its limitations (graphical for animated parts, and need to restart the game - and that takes at least 5 minutes with my 2GB mod setup... with the game installed on SSD) make it not ideal for routine tasks, mostly useful for one-of-a-kind space station or IP mission (and those I tend to assemble in space with KIS and Konstruction, and would like to start utilizing GroundContsruction more, but it has one annoying glitch that throws exceptions on part count changes).

Question/poll: how much effect does KJR have on your framerate? At what rig specs? Example: Intel E5-2690 2.9-3.8GHz, 16GB RAM, GTX780 300-part plane on runway and in flight (six A300s linked in one airsnake). Stock:50-35fps. With KJR: 31-12fps. Flying Aeris3A - 60fps either way. Same thing in 1.1.3 (just a bit slower overall). Another interesting observation about stock 1.1.3 that I completely forgot - the joints flex a lot less compared to 1.2.2 with rigid attachment enabled on all parts (no autostruts, as they tend to twist and warp my ships - quite literally - after prolonged timewarp)! Almost feels like I do not need KJR there... almost, and that is only true for light planes, not for heavy rockets or SSTOs. @ferram4: is that normal? Also, are there any plans for KJR-lite, something that just takes care of the Kraken (if that is even needed since 1.2) and tweaks stock settings instead of going full-bore with proper connection recalculations? I can live with some flex but not with 12 fps ()and yet cannot live without KJR in 1.2.2), and 300 part count is not uncommon for my stations and IP missions... Of course there are also issues in general with how KPS handles active mods (slowing game down noticeably for large vessels for mods that should not depends on part count at all, such as EVE, Kopernicus packs or even utilities such as KAC), but that is a subject of a whole different thread.

x64 uses more RAM, but, on the other hand, is not limited to 3.5GB cap as 32-bit version is (only relevant if you use mods). I have not found any difference in performance/fps between the two.

Please: less praise (after all, every one of us have already given them our support in monetary form; some people - more than once), and more push towards quality and accountability, otherwise they will keep sitting on their behinds focusing on commercially and politically appropriate localization efforts instead of actual game development. "The old guard" is mostly gone, and the tendency towards bureaucratization of the whole thing becomes more and more apparent with every passing month.

I have never used it. Presumably, it could be useful for science return capsules, but not much beyond that.

1. Play the game, keep failing 2. Watch Scott Manley 3. Play more, read articles on orbital mechanics 4. Research and install essential mods. watch a lot of youtubers for learning and new ideas 5. Play the game, get some hands-on experience using what you have learned (see above) 6. Enjoy!

Two days ago, I finalized my mod setup for 1.2.2 and did a lot of performance testing. Yesterday and today, I argued with a moderator about his "excessive use of force" on my (quite benign) comments

Once you've done this a few times (and/or have Kerbal Engineer or MJ to get all the TWR and DV stats needed), there is really no need for abort sequence in 99% of launches. And if you do something really weird non-conventional, it is likely not going to save your green dudes anyway. Essentially, it is just a homage to real space programs - cute, but rarely useful/used is KSP, unless it is your first playthrough, or if you are a real stickler for no reverts and no quicksaves (and even then, for complex accent vehicle you will need quite elaborated escape sequences; pis is part of fun, just depends on hoe much time you have to play and how much of a masochist you are). Just IMHO.

First - not applicable, all mods are latest and greatest, compiled for 1.2.2 (the only exception is KJR, 1.2.0). I guess I should have stated that in the first place, but I presumed that to be self-evident (for every self-respecting and at least somewhat experienced KSP player). Second - reasonable assumption, but I cannot localize ONE single mod(s), and there is no garbage in the output log (does not negate your argument completely, but still) - it looks like EVERY SINGLE mod I add creates more problems/slowdown (I can even see slowdown on high-partcount ships with just KAC(!) installed). GC Cycles... does not help me to understand why the performance is so abysmal on my rig, while not being neither graphically nor CPU bound. Surely, if I have a mod that is not optimized and, on every cycle, keeps pulling a lot of info or doing a lot of stuff - that could be a culprit. But how would a visual enhancement mod (textures, clouds, shaders) be so much slower on a large ship compared to a small one (even though the mod has nothing to do with object interaction aka "physics", and there is a plenty of other objects/vertices to render in the scene, so part count on the vessel should not matter that much - after all, somehow I get better fps flying around KSC compared to flying over the ocean with nothing in sight)? BTW, comparing frame rate in flight scene vs. map view (while flying) - map view is better, but not by much (~25-50% fps difference), so looks like it's mostly in physics and/or external (mod) calls - still somehow dependent on physics/partcount. Performance tab in KSP is a big lier - actual numbers (as reported by Windows and NVidia) are quite a lot different (significantly lower fps, significantly higher actual RAM consumption; and the performance tab tends to freeze often, showing nothing after a while). Anyhow, the idea of this topic was not to try to discredit one's observations/experience, but rather to collect more of them (preferably supported by not just "feelings" but actual recorded/verifiable numbers) to be able to make any sort of fact- and statistics-based conclusions - to (hopefully) bring this issue to the developers' attention. In other words, are you in a similar (mod-wise) situation to one of those described above? If so, what are your benchmarks compared to stock game? At what PC specs? THAT is what I would like to see in this thread, and would greatly appreciate if the (mostly) irrelevant arguments were kept out, despite the oh-so-sweet urge to comment