diomedea

Don't even name torrents again, that's against forum rule 2.2.a (discussing piracy) and will get you banned before you even realize it. Not joking! And besides, true those can hold all kinds of malware embedded in them. Both the official KSP Store and Steam still hold KSP 1.0.5 for download. Possibly other retailers do as well, but I can't check with them. Should you need specific instructions about how to download 1.0.5 from one of the sites mentioned above, tell which one you bought KSP from.

That error.log shows your system to have only 2GB RAM and the crash being caused by trying to write to a protected memory location, that is what happens when system is required by KSP.exe to allocate more memory than it has available. Stock KSP recommended system specifications has 4GB RAM, game may still work with less but isn't advisable; installing add-ons (especially heavy ones, EVE certainly takes a lot memory) further exacerbates the issue with scarce RAM. Advice to get better support: don't link only the error.log, follow what suggested here.

Why you don't ask directly on that add-on thread? The author is around and would probably answer. Maybe even to tell you the mod is already updated. Locking this one.

Since hours have passed without showing any proof to the contrary, seems more than possible truth has emerged to demonstrate add-ons installed in an obsolete way don't necessarily work. Whatever the result, however, spreading invalid information with the only possible result to create confusion in less expert KSP users isn't allowed. Have to thank all the many who have posted above showing how to correctly install and what could result from use of deprecated folders. In the interest of new KSP users, who may search for advice with installing add-ons, I'd rather point to the KSP wiki page than letting this thread around any further to receive more attention than it deserves. Thread locked for now; would hide if not for the many good replies it summoned.

Really your system has only 2GB RAM? KSP Recommended System specifications are 4GB. Given the OS itself reserves a good chunk of RAM for its own use, applications (as KSP.exe) will be able to use only a part (probably 1GB, which is probably not enough to even load KSP). Also, recommended VRAM (Video Card) is 512MB, your log shows 426MB: probably this latter is the cause of the white screen. KSP runs definitely better the more RAM and VRAM it has available, but given you are running on a i3 @2.10 GHz the CPU will also be a serious bottleneck (I'd say you aren't going to find the lag with that system enjoyable at all), so rather than considering to improve RAM/VRAM, I'd consider to switch to a more performant PC, also to be able to run newer versions than KSP 1.0.5. On top of the above, that log has this line: The file 'C:/Users/PC/Documents/Kerbal Space Program/KSP_Data/sharedassets0.assets' is corrupted! Remove it and launch unity again! which would require to reinstall KSP (in theory, you could just copy that file from another install where it certainly works). Please know that file corruption may come both from a bad write to disk, but also because the disk itself has damage in sectors allocated to that file (unless you are sure about your disk health, my advice is to run a disk check so to mark any damaged allocation sector before reinstalling).

Really, only 3241 MB physical memory (~3GB) ? That would be lower than the recommended system specs list for RAM (4GB). Is your Operating System 32bit? Or, somehow, is a Virtual Machine configured for that much memory? Also, as reported, user address space (memory available to applications) is just 2GB, that's all KSP (with or without add-ons) could use. The footprint in memory of KSP (1.2.2 build 1622) is around 1.4GB just after initial load, around 1.7GB while starting a new sandbox game. With every vessel you build or launch, memory footprint increases: a moderately complex game will easily require beyond those 2GB, making a crash inevitable. And that is not even considering other applications memory requirements.

Well, it seems it was your lucky day ! But agree, could be considered a issue worth reporting with the bug tracker (open a new issue with the green (+) "New issue" button, top-right).

So, first things first, welcome to the forum. About Tech Support, first follow advice as provided here. You may notice isn't KSP.log, but the Output_log.txt that should be uploaded on an external file service and linked in your post (and NOT, NOT, NOT directly appended to your post: such long files are extremely hard to read on a browser but create a lot of traffic). Nobody wants to lose some hours of his time scrolling a post trying to get some evidence, without much of the functionalities textreaders provide to compare things. Now, in case of crashes, KSP creates a folder (within the root KSP path) named after the datetime of the crash (which graciously includes Output_log.txt). Content of that folder is often better to diagnose the issue(s) in case of crashes. So, DO subscribe to an external file service able to store such amount of info (e.g. Dropbox, Mega; NOT Pastebin that only works with txt files of moderate length); Zip (compress) the content of your most recent crash folder; upload that Zipfile to the file service; copy a link to that zipfile from the service and paste that link in your post.

Clearly KSP only provides key binding support for its own commands (not sure, how could it do for add-ons where the commands aren't even known to KSP?). Clearly no keys conflict management too. Could be an idea for another add-on. Anyway, short of making some sort of UI for just the need to allow rebinding this (which seems overkill to me), could a very simple config file be used to store the selected key, which seems easy enough to edit to a user liking?

The kind of problem exposed has got my interest since quite some time. Don't want to annoy the whole audience, many have already shown important equations (in particular, about gravity acceleration) so won't repeat all that stuff. However, let me show a couple very important equations valid for any elliptical or hyperbolic orbit, including suborbital trajectories, that I haven't seen reported yet: - r = a (1-e2) / (1+ e cos(θ)) - v2 = Gk Mb (2/r - 1/a) with r = distance of object from focus (mainbody center); a = SMA; e = eccentricity; θ = true anomaly; v = velocity; Gk = gravitational constant; Mb = mass of mainbody. Those two equations are all that is required to derive exactly the speed at any point, including at the specific distance r = (body radius + altitude of ground ASL) where the vessel would impact the surface. Unfortunately, those aren't enough to provide an analytical general equation for the problem of arriving at 0 speed. Energy equations provide an elegant solution but still can't handle changes in vessel mass during a deceleration burn. Don't want to show what came when I tried to integrate just one of the variables (pitch angle φ) in time trying to find an analytical equation for this problem. In the end, I am using a numerical solution (currently have it on a spreadsheet) that effectively solves the problem perfectly. Which is actually alike what I could find used by all space agencies in reality.

Nothing worth to keep discussing. Locked.

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.

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.

Moved to Tech Support (modded installs) as clearly related to the presence of add-ons when the craft file was created.

Thread locked because of the n-th derailment from subject.

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.

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)

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.

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.

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).

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).

I'm figuring the kraken getting pop-corn and making itself comfortable to watch the show, sure would find it amusing .

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.

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?

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!