• Content count

  • Joined

  • Last visited

Community Reputation

608 Excellent

About diomedea

  • Rank
    The Right Stuff

Profile Information

  • Location Second to the right, and straight on till morning.
  • Interests astronomy, cosmology, advanced physics and more ...

Recent Profile Visitors

3410 profile views
  1. By default, all threads where a member posts are added to his subscribed threads (one can unsubscribe if feels better so). In Notification settings is possible to choose if/how to receive notifications about subscribed threads. These options allow good customization, to include receiving a summary of all subscribed threads with new content.
  2. Can confirm this shows in stock game (for reference: KSP 1.2.2, build 1622, at least with standard graphical settings). However the effect could be considered correct because of how KSP works. With the light source (Sun) so low to be tangent to the horizon, all vertical surfaces exposed to the source are getting the maximum possible density of light power (Watt/m2). In KSP, at the average distance of Kerbin from Sun, solar irradiance is identical to Earth's = 1361 W/m2) and is normally considered for its thermal effects on ground (being the ground generally horizontal, the maximum effect is when the Sun is at the local zenith, 90° elevation). On every surface, power density goes with the sine of the angle between Sun direction and that surface plane. Therefore, horizontal surfaces are all receiving Pmax *sin(elevation) power, but vertical surfaces receive Pmax*sin(90°-elevation), and the power on them is highest when Sun is directly in front of those surfaces (which happens at Sunrise for walls exposed to East, and Sunset for those exposed West). The effect is starker due to the low illumination of horizontal surfaces at the same time, due to the very low incidence angle of Sun at Sunrise/Sunset on ground. Now, as certainly the many who know about shaders in KSP will notice, a realistic effect should also consider the factor of absorption of light while traveling within an atmosphere (of course goes with the density and length of atmosphere travelled), which would produce a lower Pmax on ground: being the length of atmosphere travelled the longer at Sunrise/Sunset, Pmax should be lower, making those shines less evident. Another effect would be the change in wavelength due to Kerbin's rotation: at Sunrise, the rotation goes "towards" the light source, so the wavelength is shorter (and visible light turns blueish); at Sunset the rotation goes "away" from the light source, the wavelength is longer and visible light is more reddish. Unfortunately stock KSP has none of these effects due to atmosphere absorption and body rotation on visible light.
  3. Moved to Tech Support (modded installs) as clearly related to the presence of add-ons when the craft file was created.
  4. Thread locked because of the n-th derailment from subject.
  5. Now, could we return to the subject of this thread (about Ryzen performance in KSP) before is definitely forgotten? Another post still about AMD vs Intel, this thread goes locked, sorry for the original poster.
  6. Yes, seems like they all do (.eg. https://ark.intel.com/products/88184/Intel-Core-i5-6500-Processor-6M-Cache-up-to-3_60-GHz)
  7. I may want to believe what you claim, if only you showed EVIDENCE supporting it, as already was made clear above. Unsupported claims like this, even worse when clearly contradicted by evidence as linked above, aren't any different than trolling. Now you are REQUIRED to show proof, not empty talk about your supposed knowledge, to avoid your reputation be damaged on this forum. Further violations of forum rules WILL have consequences.
  8. Would have hoped this thread to not sink (at least not this soon) in a fight between AMD enthusiasts against Intel ones. Factual proof is required when asserting opinions that are suitable to be considered incendiary (forum rule 2.2.m), certainly not claims about one own "experience" without any evidence or actual data (or even worse, contrary to plenty of data coming from certified independent labs that run such comparative tests in a professional way). Also, rule 2.2.n, avoid to post in a manner to sound trolling; and 2.2.o, stay on subject: this thread is only about what performance to expect from a Ryzen CPU when running KSP, not about relative merits of different brands whole production. If the discussion again goes to such low as seen above, it will have to be closed earlier than could be useful in the community interest. Or probably better, let it open only for users who abide to rules.
  9. Disclaimer: can't provide factual evidence on the subject; believe a proper answer requires a comparative test, done in a laboratory environment, between systems based on the different processors running a same KSP version and same game situation. In theory, a large common cache would help. I/O from RAM could be less frequent (and in larger chunks), though such operation is required for each thread being processed in parallel, meaning the improvement will be great when a single thread is active, not so much when all cores are working in parallel with different threads. Needless to say, the width and frequency of the main data bus (linking RAM and CPU) and sum of latency cycles with RAM chipset is what gives I/O performance: modern DDR4 SDRAM modules can transfer data at up to 4266MB/s (not-overclocked), which is vastly inferior to L3 speed. L1 and L2 cache speeds are clearly even faster then L3's, but their limited size means more frequent access to the slower external RAM. In the end, all the opcode/data is fetched from RAM, through the cache levels, to the ALU and registers in each CPU core: if there were no jumps in code, doing less often larger transfers (L3) or more frequent smaller ones (L2) wouldn't change CPU performance. But jumps make for non-linear access, and if the new position required wasn't yet loaded in cache, would require to wait until it is (more slowly) transferred from RAM. In practice, seems Ryzen's L3 common cache is underperforming when compared with Intel's PC (see article here, i7 6900K L3 cache is faster in both read, write and definitely has less latency than that of a Ryzen7 1800X). More in general, this and this article hint at Ryzen's performance being lower than IPC in FpS with some games (and we all know how crucial FpS is in KSP) and requiring a good GPU to alleviate the gap. Conclusion: should I buy a new CPU now, it would definitely still be Intel. If AMD proves able to improve on the Ryzen design performance, the choice may change (but will first still see if a Ryzen gets full support from software libraries currently optimized for performance with Intel PC).
  10. Still about the Debug window. Sure you don't have add-ons intercepting Alt-F12: no KSP modder is that dumb to use that key combination, knowing how it is fundamental in KSP (and can't even be changed). I wrote you have another software running in the background that uses that same key combination, and intercepts it while you have KSP active. That other software has nothing to do with KSP. You have a nVidia GPU, so quite probable that background software is nVidia GeForce Experience, it is very well known to use Alt-F12 as default for the FPS overlay enable/disable in Shadowplay. No surprise MSI afterburner doesn't register drops, nor you see peaks with the GFX. Same about CPU, no spikes. As written before, your issue is due to GC or RAM swap, you won't see anything relevant with GPU or CPU. From Memgraph, comes very clear the reason is Garbage collection. Sure the number of parts with a craft can create issues, but what you would most probably see are frame drops due to CPU or GPU solving too many physics. Isn't your case. There is a slight increase of RAM used with a large craft off-rails, as all its parameters are loaded. But unless you keep switching crafts, nothing in RAM would be released and no RAM assigned to new values (not in stock KSP at least). That very intense GC activity shown in the graph means something running within KSP keeps requiring further memory in the heap (probably each single frame) while the heap used is already too high, therefore firing the GC mechanism in Unity. You don't have many mods. But all seems to point that at least one of those you have is at fault, leaking memory like crazy. BTW, having mods makes this thread fit for Technical Support (PC, modded installs) instead of "unmodded installs" where was opened. Moved. Advice for getting help with modded installs is here. Foremost, provide a list of all the add-ons you have (with version). As you said to be having issues since KSP version 1.0, you probably have one add-on that dates back to that version causing this leak. A plugin coded for KSP 1.0 most probably is obsolete by now and could present issues anyway. Then, you should test yourself if the GC activity still goes the same running KSP without selected add-ons: when you find which ones are associated with KSP stuttering, report your findings (Note: a memory leak can be caused by a single faulty plugin, but also by unintended interaction of two or more competing ones: in that case you'll see the stuttering only happen when all plugins are active, though each single one by itself won't cause it).
  11. I'm figuring the kraken getting pop-corn and making itself comfortable to watch the show, sure would find it amusing .
  12. Again I may be missing the point completely. What I'm getting is, MP server dictates common time for all players connected. Doesn't mean all to be tied to 1:1 (non-warping) time, all players may be fine to be warping 50:1 during a same time interval, so the MP serve would be able to allow common timewarping. But any time one of the players requires to slow time flow, either the server complies for all players (which could be pretty annoying to those just waiting time to pass), or the interested player would disconnect from MP, do what maneuvers, builds, or else he needs, do, and then try to reestablish a common time with the server (meaning his time may have to advance suddenly to sync again with others). That player vessels may appear as ghosted in the meantime, as the server can't but keep their positions updated to its own time, rather than with the time current for the player. When reconnecting, the ghosted vessels would be changed to "true" vessels whose orbital state, positions may have changed differently due to maneuvers done in the meantime.
  13. Let me check if I got this right. Planets/Moons orbits are immutable (at least in KSP), so is always possible to determine their position for any specific UT. Same goes for any vessel while on-rails. In those cases, we could totally dispense with KSP simulating time flow, we could just set a new UT at a future time and compute the updated positions. The only problem comes if there are maneuvers done during that time. Is the idea meant to sync times with all players to a unique UT when they all are not warping anymore?
  14. I'm not truly sure about what is being proposed, may have gotten it all wrong. Of course gravitation makes for a specific velocity in each point of a set orbit, and that makes for a specific rate of change of orbital positions with the flow of time. Orbital parameters are Periapsis, eccentricity, inclination, LAN, LPE, Anomaly (True, Mean, or Eccentric), or equivalent ones. Anomaly is the specific angle on the orbit an object has at a specific time; it is valid only in relation to a specified time (generally counted as UT, or Epoch). Removing a correct time reference, the orbital positions are invalid (though the orbits still exist and can be rendered as conics). A ship may then be anywhere (and nowhere at the same time) on all points of its orbit... kind of a quantum physics uncertainty problem!
  15. Didn't ask, but I assumed you be running KSP 1.2.2 (on Windows 10 x64). Debug window opens with Alt-F12 on that. Should you be using the KSP 1.2.9 pre-release, Debug window could also/or open with Alt Gr - F12 (right side Alt button). If you are running a third-party software that intercepts the Alt-F12 combo, you may not see that command work on KSP (this is a separate thing, due to other SW installed with the OS: Nvidia Experience is known to use that combo as a default setting for some recording feature, if that's the case you may have to change that setting in the Nvidia Control Panel to have the Debug window work in KSP). Haven't ever heard of a system where KSP Debug window can't be opened if not due to the above.