• Content Count

  • Joined

  • Last visited

Community Reputation

38 Excellent

About Tau137

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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...
  2. @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.
  3. Found it - TweakableEverything (parachute config and dll). Removed, as there is no need for it with RC. Thank you!
  4. @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...)
  5. @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?
  6. 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
  7. @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.
  8. I was pretty certain Kopernicus allowed that... or used to allow?
  9. A question: what is the easiest way to introduce rotation axis tilt on planetary bodies in an existing config (e.g., SVT or OPM)?
  10. 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.
  11. @diomedea Thanks for the voice of reason. On my part, I will try to be less passive-aggressive.
  12. Thank you for your insightful and extremely informative response, it is greatly appreciated!