Jump to content

Tau137

Members
  • Posts

    133
  • Joined

  • Last visited

Everything posted by Tau137

  1. So, I finally came back to playing KSP, gradually and carefully built my mod list... only to realize that the game is unplayable with my mod setup (nothing excessive, mind you - all fits under 2Gb). I have not "the latest and greatest" but still a pretty decent CPU, GTX780, 16G ram. EDIT: Removed "observations from prior versions" comment because I did proper testing with 1.1.3 and found that it was just false memory on my part - tendencies are the same in terms of slowness (except that 1.1.3 is ~25-30% slower overall). Now in 1.2.2 (identical behavior in 1.2.9, at least for those mods that work with it) I see huge performance hits. Example: a 300-part airplane on the runway: 1. Full stock: 50fps, down to 35 over ocean (btw, why such a drastic drop in fps, when there is little to render and nothing has changed in physics/parts?) 2. Scatterer: 48-35 fps 3. Scatterer + Kopernicus + SVT: 41-29 fps 4a. SVE + SVT (+EVE, Kopernicus, Scatterer)): 21-12 fps 4b. Same mods, but flying Aeris 3a: 60-44 fps (!!!) 5. KJR only: 31-12 fps (!!) So, these are heavy visual mods and one physics mod, so one would expect a performance hit (even though it was not nearly as noticeable in 1.1.3). BTW, at no point do I get 100% CPU core usage - at most it goes up to ~75%, with a couple more cores at ~25-30%. Graphics is definitely not the bottleneck either (see 1 and 4a/b above). So, what if we install a few essential and light-weight mods that should, in theory, have minimal impact on in-flight performance? 6a. MM, Toolbar, Better burn time, Better time warp, KAC, CCK, CRP, CTT, AGX, EasyVesselSwitch, EditorExtensions, KAS, KIS, MechJeb2, Docking alignment, Vanguard Parachutes, no KJR, same 300-parts airplane: 31-25fps (just a reminder - 50-35fps in pure stock). 6b. Same mods, but flying Aeris 3A: 60 fps (limit!!!). At some point I tended to blame the total memory footprint as being the culprit, but it does not seem to be the case - although total RAM consumption and part count (existing in game, not on vessel on in the scene) does have some effect, it is nothing compared to number of mod DLLs installed. Conclusion: what (tf) is going on here? Why mods that should not work on per-part basis (visual enhancements, utility non-physics mods) slow the game down proportionally to the size of the craft? And even if, for some bizarre reason, they are called on each part, why the execution is so slow for what is essentially just a few lines of code (from my long-past days of hands-on programming, this feels like every call to third-party procedures is wrapped in several layers or extreme debug exception handling - btw, no exceptions reported in the log)? Do you experience something similar, or perhaps you have 200 mods and more than 5GB in GameData folder and yet everything runs just as smoothly as in stock? Either way, please report your experiences here (keep it civil, avoid excessive quoting, and include your rig configuration and specific test results if available).
  2. The error is generated for every part that has GroundWorkshop module, on every part count change (crash or decoupling).
  3. Yep, I already realized that. Sorry. Also, it is only on somewhat critical for nuclear (other electrics will never be run in atmosphere, except perhaps by accident; and ions are easy fix as they only have one effect). Now playing with SmokeScreen to see if I can come up with something comparable, but doubt I will go further that just modifying settings for existing RealPlume prefabs.
  4. Comment of engine effects (cfg files, easy fix): ALL visual (particle) effects should be moved under Power (plume), keeping audio as it is - this will make exhaust behave more "realistically" in atmosphere by proportionally scaling back the whole exhaust (currently only "plume/dust" component is scaled, while "core/running" effects stay at full power, creating noticeable dissonance). This applies to applies to NF-P and NF-SS engines as well.
  5. 1. I know the start is red, but the flares are not. Main flare is about 3:2:1 (R:G:B) - moving in towards dirty orange; SunSipkes is better - about 3:1:0, just barely orange, and very clean. Since I presume you want main flare to be brighter, you can certainly raise the intensity but it should be done proportionately until you get to saturation point, or you just get grey tint (and/or screw the hue). 2. This is a game with a lot of graphical limitations, and the (primitive) way these effects are setups creates a visually unpleasant transition between white flare and yellow Sun when zooming in and out (same as above, from orange-brown-grey flares to a red star). Keeping the flares very bright but still tinted with correct color will alleviate this discomfort significantly. If/when I have time, I will try to re-color them. 3. Perhaps I should try that, too (only looked at the images, did not have time to play yet). But your are the creator and the end result is your choice, I was just to trying to give some feedback - I hope it was not too annoying or pretentious.
  6. Comment on flares (IMHO, of course, and not a big problem): 1. Valentine flares (new versions) look too orange, perhaps even with with some green to them... old ones were better, albeit too bright 2. Sun flares should perhaps have a bit more yellow to them, not just pure white 3. Valentine ghosts should not have been completely deleted, just reduced in intensity and colored a bit differently.
  7. BTW, please not forget to kerbalize the distance to Valentine in the next release, because 1 light year is way too far even for experienced players with a bunch of semi-realistic future propulsion mods. Even 0.1 ly is too far (more than 24hr play time at x20 physics wrap to get there with USI WarpDrive). 0.01 ly could be a reasonable compromise (100000 times further than the orbit of Eeloo); you can just include an optional tiny MM patch that increases the distance for RSS players and other masochists. Let's see if Persistent Thrust mod works as advertised...
  8. Here is the Heba fix for anyone interested: 1. Open GameData\Extrasolar\ValentineSystem\Heba\heba.cfg in any text editor 2. Add two lines as indicated below 3. Save file 4. Enjoy!
  9. 1. Still x20 output and only x3 the mass of A-RTG, at the same price and at very low tech level... Mind you, I will use it extensively, but it is just so easy to send ion probes and fly propeller planes on Eve with just this reactor... Talking about Decaying RTGs. Half-life is an order of magnitude too short. I understand the reasoning (Kerbal scale is 1/10), but transfer times to not scale linearly. It is ok for stock but not enough for OPM. Perhaps another patch in Extras to set it to proper 88 years? 2. In-game. And to answer "why" - for the sake of consistency and simplicity. And for my own understanding. Your point is correct (about efficiency of heat production per unit fuel), but the generator output should probably only be dependent on total heat (and operating temperature, and generator efficiency) as the only type of energy that can be converted, at least for near-future. From gameplay perspective... you are right, there are more important things. Looking at the whole picture, it does not look bad - decent progression, very good efficiency benefits at top tiers. Except KerbPower. 3. Abstractions aside, it is just perfect that only waste heat gets dumped to the part core; but then I just do not understand how Hermes manages to heat up at all.
  10. 1). I think that a fission reactor that weighs 300kg is a bit of a stretch at "the first step" in nuclear power tree. Yes, it has by far the worst efficiency, but its small size and decent power makes it just too good for exploration and comm probes, as well as general vessel support (greenhouse, comms, drilling etc.) Hence my suggestion to move it up the tree by a couple of nodes (assuming CTT). And raise the cost a lot, but that is a whole different topic. 2. I am talking about heat production per unit fuel. While for 0.625 it is about 31G, then goes down to 27G for 375-1 (which is fine, reactors are getting more efficient). Suddenly 25-2 goes down even further to 23G, and the new 375-2 reactor - to 18G. This should mean that they are more efficient, but they are not, because the EC production per unit fuel is actually lower (albeit slightly) than that of 375-1. So that means that a lot of heat energy just disappears. 3. After a second look... Yeah, I mistakenly read it as x5 instead of x50 (which I assume is general conversion between heat units and KW). But beyond that everything seems pretty-straight forwards, yet I am obviously missing something "behind the scenes" 3a. I'd define efficiency as it as fraction of total heat produced that was converted to electric energy. If reactor produces 300K heat (presumably 6MW), and all of that heat gets taken away from the reactor to produce EC - then it would be 100% efficient. With that definition, KerboPower would be 40% efficient. And total heat produced should always be in direct and constant proportion to fuel consumption, no matter the reactor (which currently it is not). Ok, you say that config files are not straightforwards (they should be, imho, but it is not my decision, obviously), but I cannot figure out where does the 12500 power figure for Hermes comes from - would you explain, please? Also, what does PowerCurve do? It is only present in 3 top tier reactors, and is the same for FLAT and Hermes, yet different for Excalibur. I know it is temperature-related, but what is the parameter being regulated? Why is it exactly 4000 (or 6000 for Excalibur) at nominal temperature? Finally, does the FissionGenerator actually takes heat away from the reactor/core to produce EC (and the core heats up less as a result)? That is kind of important...
  11. Original DELETED as outdated, checking not-yet-relased "re-balance" version(s). Will add comments here as they come. 1. NFE reactor 0.625 - heat and consumption is just right, but the reactor power is OVERKILL. This must be either trimmed down in half along with heat, or moved to the save tech tier as 2.5-2 or even 3.75-2 reactor (advanced tech, miniaturization etc.) with higher cost . Btw, it still costs only 1/4 of advanced RTG; I know RTG price comes from stock RTG scaling and reactors have a different category and scale, but still - this little reactor is just way too damn good. 2. 2.5-2 and especially 3.75-2 reactors fall out of line - they are running too cool (based on EC production efficiency per unit fuel). The should produce 245K and 465K, respectively. 250 and 450 would be close enough, if you like round numbers. 3. FissionGenerator numbers are not right. Looks like you are always taking 20% of total reactor heat and then convert to EC with 50-100% efficiency... does not make sense. I'd instead take the heat in direct proportion to efficiency, and then convert 1:1 to EC (as is 3.75-2 reactor) - this would be more "realistic" in terms of energy conservation, and then you can just calculate total heat production based only on consumption (or vice versa), no extra coefficients. Simple. Everything can be automatically calculated, no need for tweaking (expect perhaps to match radiators) once you know the desired EC output and efficiency. 3a. IMHO, efficiency of top-tier reactor(s) should go up to 30%, not 20% (10% for low-tech, as it is now, is just fine). Also, see (1) above - miniature nuclear reactors should always be less efficient, but they should be high-tech still. More to come later...
  12. Please do share the IR fix when it is done. Thank you in advance (assuming that this will happen sooner than 1.3 when we will be up to yet another couple to infinity weeks to see our favorite mods updated
  13. I know that procedural wings "somewhat" work, but it looks like the lift and drag are not correct; control surfaces are barely functional. Same of OPT wings and controls. Judging from config files included in the latest releases, lifting and control surfaces must be reconfigured to use FAR aero model, and I would like to know more about what each parameter means and how it is related to wing's original stats and geometry.
  14. I wonder if I should wait for 1.3 or try to squeeze in some play in 1.2 still?
  15. A couple of questions. 1. How does FAR (latest/dev) work with TweakScale? 2. About making part/wing mods compatible with FAR. If there a guide/wiki to explain all the parameters and features needed to play correctly with FAR (e.g., I love OPT, and would love to make a FAR patch for it - if only I knew how; same for procedural wings, although, presumably, the latter is going to be a lot more complicated). Thank you in advance.
  16. Here is what I see as problems (please note that I have very little time to play for the last month or two, have not even downloaded the latest version yet). 1. (NFE + KA, high priority) - reactor heat-up time for solid-core nuclear engines is too long (even if startup is linked to throttle and all heating issue addressed, it is still a problem - actual "core" in such engines should be is extremely small, only about ~100kg for LVN, so I should not babysit the engine ready for 3 minutes before launching). 2. (NFE + KA, high priority) - reactor "post-wrap" calculations that tend to blow up ships on load (only when physics-loading another ship with a reactor or fuel storage on rendezvous; when in control of a ship, switching from high warp to physics is handled ok). Perhaps this was resolved in the latest version, dunno, but for me it was such a frustration (possible to avoid by doing numerous vessel switches just before rendezvous to settle things now, but that is also painful and time-consuming) that I literally removed NFE core and replaced reactors with stock or USI converters (modified) in the latest game. Feel really guilty about it, but... c'est la vie 3. When using LF patch, mass of high-tech engines such as CSGC is excessively high (effectively x2, too much). 4. Nuclear turbojet/ramjet is missing.... Pretty please!? Atomic Age model is bad since 1.2, SXT version is just too unwieldy and ugly (I still used it though, even equipped it with NFE reactor), and I could not find any other decent models for such an engine. Interstellar has thermal jets, but I do not want to use interstellar in its current form (love realism, but only in homeopathic doses; and do not want to see "waste heat" as a resource). Beyond that, I think that Kerbal Atomics is great, love it. A few more comments that should go to other threads, but again, no time... 5. (NFP only) - Choice of engines is excessive. This is not a bad thing, and not a complaint, but (in my personal opinion) this makes the mod somewhat overloaded with parts and options. Yes, there is variety, great choices.... at the cost of extra game loading time and lag in editor (talking about lag - later versions of NFSS really lag down my editor, especially fuel tab; of course, I have tons of other mods installed). I would prefer to see more concise and distinct choices in engines. Just my opinion, I am sure many will disagree, which is great... and I can always just do what I usually do - cut Vasmir and Pulse and unlock 1.25 and 2.5 ions, cut all argon tech to simplify choices and improve performance. Also, the whole NFP in general is so damn great and efficient.... making KA practically obsolete, except perhaps for Duna and Tylo heavy landers. 6. (NFE only) Reactor heat production is inconsistent and often too low across reactor sizes (e.g., 0.625 should produce at least twice as much heat). Should be easy enough to calculate proper numbers based on fissile fuel consumption (just take something as a base number and go from there, does not have to be "realistic"), adjusting slightly for efficiency of generators in later, higher-tech reactors. I had the numbers somewhere when I was going through adjusting everything in NFE two months back, but cannot find them any more, sorry. I am looking forward towards playing again (with NF*, of course) as soon as/if I get a chance. And thank you for keeping up the work on your mods, my playthroughs would not have been the same without them!
  17. BUG: Mechjeb cannot handle "infinite" engines (e.g., Nuclear Turbojets, where the only propellant in ModuleEngineFX is IntakeAtm, fission fuels are handled through Near-Future reactor), it throws exceptions when trying to calculate dV. This results in game stutter and quick crashes. Applies to latest release (exceptions in VAB/SPH and in flight) and latest dev build 685 (exceptions and crashes in flight only, VAB/SPH dV calculations work and just ignore "infinite" engines). This has already been reported by someone as issue #818 on github, but, considering that it has been a while, I would like to bring it to your attention once more. [LOG 08:12:56.427] [MechJeb2] Exception in MechJebModuleStageStats.RunSimulation(): System.Exception: FuelFlowSimulation.SimulateStage reached max step count of 100 at MuMech.FuelFlowSimulation.SimulateStage (Single throttle, Double staticPressure, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 at MuMech.FuelFlowSimulation.SimulateAllStages (Single throttle, Double staticPressureKpa, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleStageStats.RunSimulation (System.Object o) [0x00000] in <filename unknown>:0
  18. Thank you for quick response - I will try to give you a reproducible "clean" save with latest NF version on stock, but cannot guarantee it (RL time limitations), sorry
  19. @Nertea Glad to see you back, and it's great that the reactor fuel consumption is fixed (to be tested today). I have been using pretty much all of your mods for quite a while, even if I had to "cut corners" in certain areas (e.g., use KA engines but modify them to use nuclear fuel yet avoid the fuel consumption bug - which is hopefully now gone; more so, just yesterday I finished gutting your reactors to use stock converters, mostly to avoid the bug described below). Another bug/issue to report though (it applies to previous version, but I do not see anything related to this particular issue in the changelog): overheating reactors and fuel containers. Symptoms: when coming back (vessel switch, or physics load due to proximity, for example when trying to rendezvous with a IP vessel with a reactor in LKO to retrieve crew and science), a lot of parts "explode due to overheating". My assumption, somewhat supported by observation of "backlog processing" happening on vessel load, is that background processing is limited/non-existent, and the calculations of fuel consumption and heat generation are happening on load, resulting in tremendous amounts of heat being produced and redistributed too quickly (backlog)... usually the parts with least heat tolerance, such as crew cabins, explode, first. I understand that there are or could be engine limitations to implementing this correctly, but it still "bugs" me. It is really difficult to give you a "clean" example/save to test on, as I am using a bunch of mods, quite a few with custom modifications, and am actually playing the game. This behavior is not 100% consistent, either - e.g., a vessel may explode on loading, but if I restart the game and try again - it will be "hot", but will not explode; also, sometimes (not always) switching vessels at short/medium time before rendezvous will allow everything to equalize, thus avoiding explosiveness on encounter (again, behavior will be somewhat different if I do that on a long game session or restart the game just before trying again). P.S. Should I sign this post as "The Demotivator"? I hope not, as my intentions are exactly opposite.
  20. @ferram4: Could you say why you set viscosity for Duna and Eve's atmospheres so drastically higher than that of Kerbin? If anything, @194K, viscosity of CO2 gas should be half that of a air @288K, not four times as much...
  21. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) ERROR Operation is not valid due to the current state of the object IN ModuleLifeSupport (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) ERROR Operation is not valid due to the current state of the object IN ModuleLifeSupport
  22. Nertea, CoreLifetime readout does indeed reflect lifetime as it should be, the problem is that actual lifetime (as measured via clock using moderate non-physics timewarp, or by observing resource consumption rates) remains the same no matter power level or throttle (e.g., just over 5hr for Squad LVN, even if reactor is set to 0%, and 0% throttle).
  23. Nertea, thank you for (1) still working on your mod (to the benefit of many, myself included), despite all lackluster/negative/indifferent comments, and (2) responding quickly and in a reasonable manner. As I said earlier, I meant no offense, it was MY frustration (an therefore my personal problem) that lead to that emotional spill in AE thread (which was mostly because, as was already outlined before, Nertea's mods are most reasonably balanced near&far-future propulsion and energy generation option there is so far), and my apologies where included in the earlier posts. BTW, if anyone desires to bash me personally for being negative, disrespectful, inadequate etc. - please do, but, if you would, please keep it in PM to avoid contaminating the thread. Meanwhile I will continue to submit bug reports and I the accompanying information Nertea requires, whenever possible (unless Nertea himself tells to to bug off forever). Jeez, everyone is suddenly soooo emotionally fragile, like, *literally* needing a safe (save?) space.... Anyway, back to the topic. Nertea, I removed all mods except NF* and those that come packaged along with them... and so far was not able to replicate the behavior of "loosing NFE reactor control on right-click" issue mentioned earlier, so perhaps it is a mod interference and not NF* problem after all. I will test further and report (with data) when I can.
×
×
  • Create New...