StahnAileron

Have a computer hardware story. It was kicked off by KSP, so that's why it's here. (I just needed to vent a little...) I was playing KSP about two months ago. 1.2 was proving fun once the majority of the mods I use updated. KSP being more cooperative now (compared to 1.0.5; I skipped 1.1.x), I decided to actually build a true space station. A modular one, so I needed to assemble it in orbit. (I can't do the monstrosity launchers some players build and use...) I design it in the SPH. The lag hurts. In fact, KSP crashes several times due to Out of Memory conditions. This on a system with 16GB of physical RAM. (I do have my virtual RAM limited because of that, but still... KSP memory leaks/hogging strikes once more.) I get fed up and decide to bump it up to 32GB. I noticed Windows 7's memory caching feature is pretty nice, so it would help with loading other stuff I deal with often (other games I play, file transfers, etc.) Should be a worthwhile investment. I buy, receive, and install. No problems. Ironically, I wasn't playing KSP as much, but it was more solid when I was and would go longer per session. I was mucking with the Space Station in orbit. I had to dock with it and retrieve Jeb and Val. (They manned the two command modules for the station during those launches as I wasn't willing to add probe cores to the station modules when they had command pods already.) The lag from the part could was tolerable, but kinda annoying. This is on a i7-4771. I weigh getting a CPU upgrade. So last week, I bite the bullet: let's get a used i7-4790K! I got it today and spent the last 2 hours installing it and figuring out why POST wasn't QUITE working. A trip to Intel's site after I got my system in a working config and looking at BIOS updates tells the story: Intel's own DZ87KLT-75K MB does NOT support the 4790K! CRAP! Well, it SORTA does, or else I wouldn't be writing this at this time. (Would've been later with the 4771 re-installed.) It seems support is half-assed since it's just a refresh of the 4770K, I just can't access the BIOS. So I need to run my system is stupid-proof mode. (BIOS is locked out from user access/changes and I assume is using stock defaults.) So the entire reason I have this processor - to overclock the sucker - is render moot currently. SO! A lesson to others: Know your hardware! And its quirks. Anyway, I love Intel as a tech company, but I sometimes hate them as a business. The latter aspect is in full force right now... So I now have a spare CPU and 16GB or RAM laying about. I can either re-install my 4771 and try to offload the 4790K (I lucked out and got it for under typical prices on eBay, so I might at least break even) or invest more money into an obsolete platform. I would need a Z97 MB, which are out of production. Still buyable new at retail; the selection just sucks. Looking at 100-150 more... Or I can get a "server-grade" Z97 MB from SuperMicro for about 225. I used to buy Intel boards for the stability. (They're quirky at times, but damned if I ever had hardware issues them. 24/7 rock-solid operation.) SuperMicro is known for their server equipment... I just don't know if I should bother for that price. Of course, I could just save up and just build a new system, but that's another MB anyway along with a completely new CPU and newer DDR4 RAM (I'm currently a DDR3 home due to the old tech here...) The performance advantage of the latest systems aren't really much better than that of several year ago. (Efficiency has been the main advance, not raw performance.) Not really worth the extra re-investment. On top of this, I don't feel like migrating my current OS install to essentially new hardware. (MB swaps aren't to be taken lightly...) Dilemmas, dilemmas... And I feel so stupid about the compatibility part. *sigh* Any other computer stories out there originated by KSP? (Good or bad.)

LoL, yeah. It's the modern age where anyone can post anything online without necessarily thinking beyond, "I want this." Optional, "And I want it now." "Suggestions" implies more than simple requests (or wants...) in my eyes.

Good points already mentioned, but to also chime in: You can optimize all you want, but performance is ultimately dependent on several factors. Your Hardware (Physical limitations.) Programming Platform/Language (How code is allowed to run on your hardware/ How your hardware handles the code.) What you're trying to accomplish (Some "problems" are harder than others.) How you accomplish it (How the code does what you want it to do. This is what "optimization" usually implies.) (1) is all on the user/player. (2) is a decision made by the developer early on and is expensive to change the deeper/later they get into development. (3) is the premise for KSP. (4) is dependent on how much effort the developer can afford or is willing to commit. SQUAD can't do anything about (1). An example of (2) was the move from Unity 4.x to Unity 5.x. That's a similar platform (theoretically the same) and look at the headaches that caused. Imagine going to a completely different environment like C++ and starting from near-scratch. (3) is the fundamental game itself and the features. SQUAD is trying to add there, not remove. Players would be kinda peeved if features got removed/dumbed-down post-release... SQUAD is already doing as much as they can regarding (4). Unity being C# (which has nothing to do with C++) is a limitation we have to live with until/unless KSP2 gets announced and is developed on something more performance-oriented. Unity was designed for ease of development, not performance. For now, SQUAD is working with what they have that gives them a return on the investment they already put in.

Between 1.1.x and 1.2.x, the codebase for KSP got completely revamped. Plugin-based mods for 1.1 won't work in 1.2 without at least a recompile, if not a rewrite to some degree. I was hoping @Claw would update that mod, but no luck to date. I'm surprised KSP didn't yell at you in some manner for trying to use those mods. (Well, maybe it did in the logs... Unless KSP got smart about ignoring plugins/*.DLLs it can't run.)

If you're suffering lag with only multiple and/or complex ships, that's more CPU-centric than RAM. (More RAM mostly means more mods and more time KSP can run before hitting the RAM limit since it still seems to have memory leaks.) Physics in KSP is still hard with a lot of number crunching. It can't be multithreaded easily either. (If I recall, it's at most 1 vessel = 1 thread. A single complex vessel can't take advantage of multiple threads/cores.) DX11/OpenGL forcibly uses a GPU's RAM space for texture storage (rather than residing only in system RAM and being transferred as needed. Also, they use better compression/storage algorithms, I believe.) Using DX11 on my install allowed me to recover about my GPU's worth of system RAM. I wound up getting more RAM (16GB >>> 32GB, ~200USD) and I'm hopefully getting a "new" CPU by the end of this week. (eBay'd a used i7-4790k, ~270USD.) I play Factorio as well, so it'll help there as well. (Though Factorio is a completely different experience from KSP: they don't give up on optimizing code and it's written in C++ for performance reasons. I heard they initially tried Java, but quickly learned their lesson.) Factorio 0.15.x just came out last week, so I'm into it more than KSP lately (despite my investments this past month into my system...) Anyway, as noted, keeping part counts low keeps frame rates high. Working on my ~250-part space station crashed my game multiple times. (Both in the editor and after I assembled most of it.) Oh, if you haven't checked, look at the Max Physics Delta option and move it lower (to the left). It let's the system skip more calcs for frames. It's basically a minimum frame-rate setting of sorts for the CPU. I'm not sure how it affects accuracy in the game, like for orbits and maneuvers. At least you'll be able to do them and not watch a slideshow, though.

In theory you could with everything turned down for visuals. However, I might be more worried about KSP doing something dumb with the RAM since it's a memory hog like no other. (Nothing I've ran to date can max out RAM usage regularly like KSP can...) Anyway, KSP is actually kinda light on graphical requirements. All the pretty pictures you see online in-game with fantastic views tend to be with graphical mods installed. If you're running integrated graphics (indicative by the shared RAM specs), I would worry a bit more if the CPU can handle KSP. KSP is pretty CPU-intensive comparatively. Either way, you may wind up running the game in non-real-time. (Time in-game is slower than reality; i.e. One in-game second will last longer than a real second.) If you have more specs (brand, model, etc.), we might be able to give you more detailed feedback.

@steve_v You did the same thing I did and skipped ahead, missing all the posts that addressed the issue already. The mods are eyeing this thread now for content, so let's try to keep on topic as that issue has been dealt with already. If you wish, you may look at the spoiler in my reply addressing that particular post. Just don't comment any further on it. As you can see, @HunHarcos as already admitted to his error.

Not quite. AMD is marketing Ryzen in a style similar to Intel's branding. It should have been a i7-7700K vesus Ryzen 7-1800x. The Ryzen 5-series seem to targeting the i5 market. The problem for Ryzen in terms of KSP is that KSP is mostly single-thread limited (the physics). Clock-for-clock, Ryzen seems to have a 10% or so deficit in IPC versus Intel. They attempt to make up for it with more cores. So it's a problem of Single- vs Multi-threaded performance and KSP can't take advantage of that many cores to boost performance better than just raw single-threaded performance. The larger L3 cache helps (less hits to main Memory), but KSP is a memory hog as well, so you'll be hitting main system RAM often anyway. (I can't imagine ALL the physics calculation being able to fit into 16MB.) If you want good performance for a limited budget, Ryzen is great. If you're trying to justify Ryzen on just performance, then that depends on your typical use-case and workload. For KSP, I don't think it's beneficial. You'd need a bigger cache. And that cache won't help much when you need to brute-force physics calculations on a large vessel or multiple complex vessels within physics range. (You might get a slight boost from the lower latency, but you'll still be limited by raw CPU throughput.) Ah... Wait... I think Ryzen could help with multi-vessel scenarios, now that I think about it. Don't separate vessels get their own thread? (Though it'd only help if you had lots of vessel within physics range of one another if that's the case.) The limiting factor there is the largest, most complex vessel in the scene. Though 90% of the time I think users would just be dealing with one or two vessels. I think you'd be better off trying to find and use the highest performing/clocked CPU instead of worrying about it's cache. (Really, cache is more for keeping performance consistent rather than "boosting" it in the typical sense.)

EDIT: Well, I'm stupid... For whatever reason, I didn't notice all the comments/replies after his post that I'm replying to before starting off on my rebuttal. Because I didn't want to waste it, the spoiler contains my original content. It's there for posterity if anyone cares. You can disregard it at this point since @HunHarcos admitted his error about the i5 and apologized. (Please don't take it as an attack. I did try to sound and come across as civil as possible given the limits of text.) I ask the topic addressed in it be dropped at this point. EDIT2: Dammit! Missed another post while I was typing this up. Yes, if anything, AMD definitively gives you the best bang for you money overall. Intel is a premium tax for the raw performance.

Are you sure you're not biased in anyway? Last I recall, ANYTHING from AMD lagged behind Intel's equivalent (much less the top end.) This was true until recently when Ryzen came out and it was considered at least competitive in some cases (mainly if you need a ton of cores). Single-thread IPC from AMD still lags behind Intel from my understanding, so high-end Intel CPUs are still probably the best investment for something like KSP (which tends to be more CPU-limit than GPU-limited in my experience.) As for the topic at hand: I would imagine the cache would help make up for the overall lesser IPC of Ryzen compared to Intel, but consider how much data KSP can crunch, I don't think 16MB would make too much of a difference. However, as @diomedea notes, it's best if someone actually did tests with both platforms in a lab environment for conclusive data and evidence going in either direction. My understanding of how KSP works and how AMD and Intel CPUs are designed would logically make me think Intel has the advantage. I would LOVE to be wrong though (Intel prices would hopefully drop if they had competition at the high-end...)

I usually just change the vessel type to something I don't normally use and hide that type. (Sorta wish KSP allowed custom categories and icons for vessel types because of any changing needs as you play the game and leave vessels everywhere.)

And astronomy/astrophysics is one case where you can come across that deviation often. Thanks for clarifying my statement. I initially made the same mistake when I was doing RT calculations. I caught myself at the time because I was tutoring math at the time, some of it being basic trigonometry. I realized looking at JUST the FoV vs planetary radius would cause me to intersect through the planet (or exclude part of an orbit). With RT, it's more obvious because the highest FoV (at the time) was 45 degrees. Suffice to say my calculations needed total accuracy or else I risked having blackout zones at the most inopportune times. (Which is why I wound doing the basic calcs in the first place as my initial post mentions.) I floated the thought of making a radio tower at both poles. The numbers made it unfeasible.

If you want to keep a particular orientation using the teleport options, you have to use the other orbital parameters. I've yet to figure what the reference point is that KSP uses to define the starting direction. It MIGHT be relative to Kerbin's Prime Meridian, but *shrug*. If you grab MechJeb, its SAS functionality offers many more options by letting you select your frame of reference. I use it to keep my station "upright" relative to Kerbin's surface. My comsats use it to keep their solar panels pointed directly at the sun. (I have both polar and equatorial satellites.) MJ's SAS is also much better with rotation overall: it's more gradual and smooth. Stock is more jerky (because it's all or nothing when active; MJ does proportional inputs and makes use of letting the rotation drift a bit to make it more manageable.)

Did you not learn anything from the prior 2 answers? No logs = no support. We can't help you if we have nothing to go off of. "This thing doesn't work; what's wrong with it?" "Anything, given that amount of (non-)information."

Sounds like the typical phantom forces problem. As I recall, the Klaw is NOT a good idea for long-term "docking". It's meant for asteroids and temporarily joining two vessels together for either maneuvering or resource transfer. Beyond that, you should be using docking ports for anything long-term. You get proper connections that way. The way the Klaw joins vessels together is atypical from what I can tell. I wouldn't be surprise if reloading Klawed vessels back into physics range causes problems. Otherwise, the two Klaws attaching to one common vessel are fighting one another. Again, I don't think the Klaw uses the same type of joints that normal parts connections and docking ports use. Don't take my word on that, though. To date, I think I've used the Klaw exactly once; it was WAY back in 0.90 not long after I got KSP and wanted to rescue a ship stuck in orbit with a kerbal in it. I've attempted to use the Klaw since, designing debris tugs, but I've yet to put those to actual use.

Actually, shouldn't the radius be at a right angle to the edges of the FOV rather then the centerline? Unless the FoV can see through terrain to some extent, as your graphic shows, you would technically be blocked from seeing the maximum amount of the sphere. (The LoS pierces the circle; it should be tangential, no?) I've done similar calculations for RemoteTech. (e.g. Figuring out the altitude I would need to be at around the poles to get line-of-sight to equatorial satellites at various altitudes. It was for drone planes; I once lost an unmanned cargo shuttle because I had it de-orbit at a pole without full planetary coverage.) Of course this all depends on the "penetrating" power of the signals.

@Angel-125 FYI: the RemoteTech patch for Pathfinder is out of date. The Gaslight has a name error (GasLight rather than GasLight2), the TERRAIN scanner has an odd config (should it even have a RT config?), an the Satellite Dish doesn't even have a config. There's also an AntennaRange patch, which I think has been deprecated ever since 1.2 came out. (What with 1.2 having satellite comms as stock.) If the file dates in the mod are to be trusted, you have a handful of MM patches that probably need to be checked as they predate 1.2. (The RT patch for sure; AR patch can probably be removed.)

This usually means a memory issue (Out of Memory) or a buggy plugin trying to do something stupid in my experience. Anyway, as @ExplorerKlatt notes, logs help. You should post the both the output_log.txt and the KSP.log files so we have a better idea of what is happening.

If this is the case, I'd rather see it as a mod via IFS or B9PS as a fuel-/meshswitch. Though really, as a spaceplane advocate, it's not really needed on any of the spaceplane parts unless you're coming from one hell of a apoapsis. Or you're hitting up Eve or Jool for an aerobrake. Personally, I don't think building spaceplanes is the hard part (it's not too much different from building a regular plane); it's finding the right ascent profile for a design. (And with part mods, the problem is trying to not burn up on the ascent rather than the descent.)

Odd. I had crashed vessels in water before that broke up. In a recent case, the crew pod survived, so I recovered (would've reverted, but KSP had crashed on me prior while in space, so I had to continued from the auto-save.) The debris was still there, floating around. I had to manually recover them from the tracking station. I'm thinking you other pods haven't truly "settled" on/in the water. Dunno, though. If you wish to continue the discussion, you should probably take this to the gameplay sub-forum at this point.

In what way? Any landed vessels don't get de-spawned. If you have to bail, wait for both to hit the ground before recovering. The only way I can see this being a problem is if the part gets labeled as "Debris" and the player has the "Debris" Options setting at zero. Otherwise, the main concern is physics range in atmosphere.

It looks like your ModuleManager.dll is missing or corrupt. All the CFG file errors are from mods that use MM to EDIT part CFGs. MM uses a different syntax, so KSP won't know what to do with those files without MM. (*.cfg are used by both MM and KSP for configurations/settings.) There's a possibility the KSP install itself is corrupt somehow if it can't compile parts, but I'd look at ModuleManager first. MM is needed for pretty much 99% of the time for mods to function. You could just stop the main MM thread and grab a fresh copy. CKAN has been known (so I've heard) to break installations for no apparent reason or some such. I personally install and manage my mods by hand. (I tried CKAN once back in the 0.90 days. Didn't care for it; wasn't all that robust IMHO.) Some users can get away with it, but now that I think about it, it tends to be the heavily modded CKAN users that run into trouble at some point. Those who use less mods tend to not have many problem if at all. (Maybe it's just me, but CKAN users tend to run mod counts of over 100 whenever I see support requests...) Not to bash completely on CKAN, but when I run into mod/KSP problems, I tend to have an idea of what could be causing it because I know what I last did to KSP or a mod; I had to touch them to make changes. CKAN itself doesn't test for incompatibilities or anything; that's all based on user feedback or modder declarations. Anyway, TL;DR - Check ModuleManager. The errors point to it somehow missing, being corrupt, or just not loading for some reason because KSP has no clue what to do with CFG files that I know depend on MM.

Didn't realize this was here, but I'll link to my thoughts on this in another related thread:

While I'm willing to accept and mostly agree with that reasoning (I would add lazy, BTW) about (habitual) cheaters in general, I see @hazard-ish as an entertainer. While it's disappointing he did the video and passed it off as stock, I'm not going to ding him as harshly because I don't see his video as true gameplay videos. (I.e. how to play the game well.) I see them as having fun with the game. I've seen other video with "cheats" as well, the difference being they disclose (or even advertise) that fact. The fact he's willing to (now) disclose it is a step in the right direction. It would've been better if he did this from the start (disclosures, craft files), but hindsight and all that at this point. We'll see once the work with @Matt Lowne is done. I still value his work for the entertainment value. They may not be as impressive now, but they're still fun videos to watch, "real" or "cheated". Now for a bad pun: pretty "hazardous-ish" of him to claim it was a stock vessel.

@sh1pman, @Majorjim!, @TeiTimidea: Limited time availability, apparently - Posted FYI.