Hoozemans

The weird thing is that the top station in the initial post was literally teeming with lights - a bunch of projectors at each and every girder intersection you see - and yet its performance was better than that of the station below ... Quick check ... [Turns of lights, attempts docking manoeuvre] I'm not sure. It might have helped a little, but whether it's enough to matter ... ? I should start logging FPS every time I change something. Anyway, thanks for the hint! At the very least, it's worth investigating.

So this is not a new question; I've seen many other posts on the same general topic. The previous one with this exact title was a bit outdated, though, so I thought I'd open a new one. The question is: what can you do to improve performance of your game (outside of bying new computing kit). More specifically: what can you do to improve performance around space stations. The reason I ask is I've been having inconsistent results with my station designs. I've had massively big stations, 500+ parts, with reasonable (given the total part count of station, docking and approaching vessels) though not stunning performance: And then I've had this tiny station ... : (Modlist for above spacestation: https://drive.google.com/file/d/1vajct196DKoGFBZJ_YWFe_QXjAEuXLRe/view?usp=sharing) ... which sports an entirely reasonable 200 parts (including a few docked tugs) but drops my framerate down to single digits per second - and I didn't even try to make the rings rotate (the rings were just a convenient shape for getting stuff to orbit). So obviously, it's not just the part count, but the type of parts that matter. Some guesses as to what type of parts have the potential to affect framerate: Solar panels: they have to keep track of the orientation of the station relative to the Sun and, if they're the tracking type, adjust their angle. Docking ports: they may be scanning for nearby targets and adjust their behaviour accordingly. (Though the first pic shows a station with massive numbers of docking ports that nevertheless performed way better than the one in the second pic...) The USI Kolonization mod I'm using probably recalculates the current life support status of habitation modules every other. In the above stations I cheated by using the UbioZur Welding mod to reduce part count, by welding most continuous 'inactive' parts together (like adjacent crew cabins, girders or fuel tanks). Now theoretically this should reduce the load and therefore improve framerate. But I'm not a coder; I have no idea how the code for this mod works or how the code of the game proper has evolved since this mod was first developed. It may be that it's not just about the actual parts, but about the modules inside those parts, which aren't welded - I presume. So, mods installed, type and number of parts ... what else affects framerate? Can I - can we - come to some kind of consistent set of guidelines for constructing stations big enough to be worth having that don't cause you to grind your teeth at every docking manoeuvre? What parts to avoid, how to avoid them; what mods to install, and which mods not to ... I'd love to hear your advice and your experiences. Thanks! EDIT: Another thing, I forgot, that may have impact: settings. Like the max DT per frame spent on physics calculations. The Max DT was lower with the top station than with the one below, but I've been told that bigger is better in this case. Soit, I'll have to experiment with this a little. SUMMARY TO DATE: Limit the number of docking ports. Docking ports, especially unshielded ones, scan the environment for partners to mate with, which puts extra load on the CPU. Also, if you limit the number of docking ports, you'll be limiting the number of craft that are docked at any given time, which limits total part count. Limit the number of solar panels. All solar panels, not just the ones that actively track the sun, need to be able to calculate their position and attitude relative to the sun, and whether or not any obstacles are present between them and the sun. Limit the potential for fuel crossfeed. Modularize your station: all fuel (or presumably consumables of any given kind) in one section. See Starman4308's mention of Stratenblitz's video here. Following AlpacaMall's suggestion: limit the number of lights. I haven't had this problem myself, but I can see how lights might require CPU intensive calculations. And of course, try to limit the overall number of parts. Mods like UbioZur's Welding mod my help here, or things like the various Station Parts modules I occasionally see mentioned. Sure, you can build grandiose stations just for the kick of it; try and match Stratenblitz's Kerbol 0 if you dare. But if you're looking for something to use as a staging area and (re)fuelling post for forays into the system, then Simpler Is Better (which is what gave me the initial idea for the station in the first pic in this post: basically just a bunch of girders, docking ports and fuel tanks).

Aw... I have to uninstall B9 Pwings and FAR from my 1.11.2 game until I get a chance to RTFM - or until there's an update for 1.11.2, I suppose. I haven't been able to design a plane with lift yet - note, I'm not exaggerating: none of my designs so far have produced any lift whatsoever. There's no upward arrow to be seen in the SPH no matter what I do. Also, I haven't yet figured out how I can set control surfaces to only pitch, yaw or roll, and not attempt to do all three regardless of how I configure the controls. If anyone can point me to some helpful reading material or interesting videos to help me with spaceplane design using B9PW 0.4X in KSP 1.10+ that'd be nice. I had a couple of nice designs in KSP 1.9 using B9PW, but I may have to relearn some things.

Phew. For this kind of delay I want to see the physics - and the physics engine - completely redone. Multithreaded, with real gravity - for the orbits of all the celestial bodies too. That's no guarantee. Big software projects have this tendency to implode if you allow them to continue, grow, redefine scope for long enough. And in a market as volatile as the gaming industry...

I took the latest releases of https://github.com/net-lisias-ksp/KSPAPIExtensions, https://github.com/net-lisias-ksp/UbioWeldContinuum, and https://github.com/net-lisias-ksp/ModuleManager, installed them as per instructions, and then it worked. Before I was trying to make it work with the main repo of the MM, because I am worried about compatibility with new releases - but I figured we'll solve that problem when it becomes one.

Hi! I'm coming up against the limits of what my hardware can support in terms of part count, and welding currently seems like the best solution. I wouldn't have to weld much; just a few assemblies of structural parts and cabins for my bigger stations and vessels. I've been trying for some time now to get UbioZur to work with 1.9.1, but no luck so far. I'm obviously doing something wrong. Query: does the UbioZur welding mod currently work for KSP 1.9.1, and if so, where can I find the proper releases, installation and troubleshooting guides? -- EDIT -- I got it to work with the forked MM; that'll do until a more permanent fix comes along. Thanks!

Put a rotor on top of an engine mount plate. The engine mount allows you to have the top and bottom part of the ship non-rotating while the parts attached to the rotor spin (you need a fair number of SAS modules to keep the rest of the ship from spinning - either that, or build two counter-rotating rings). Attach spokes with three way symmetry, then attach Mk2 cabins to the spokes, rotating each of them until they form a ring (takes a bit of doing). The spokes are attached to the rotor by two Jr. docking ports per spoke, so that you can't get the angle wrong when you connect them up. There's also Jr. docking ports between the segments. The cargo bays in each segment have a docking port for RCS-tugs to attach to. I launched each segment separately, then attached them to the main body by RCS-tugs - and as difficult as that was, that was only the beginning, because at this point framerates started dropping seriously, and I still had to dock with the spine and the engine section....

Yeah, I'm keeping that in mind as well: it's likely that new kit will help a bit, but that we really need a software breakthrough to make it work. I wonder how the KSP2 dev team are hoping to tackle the issue. I have some vague ideas for using GPU's for physics calculation based on how libraries like Tensorflow do their thing, but I'm likely to be miles off Anyway, it's still not a bad idea to have a dedicated machine, optimized for playing KSP.

I tried that shortly after I chucked the craft files, but I can't load the results. My game was stock plus both DLC's, and a single mod that allows you to reconfigure tanks (Configurable Containers). I haven't tried to debug the code yet, but I'm guessing that mod is what kills the export. Soit. Since I'm a couple of hundred bucks away from my savings target for the new machine, I can think about whether I want a desktop or flaptop a bit longer. And perhaps find other ways to optimize the game as well. I've always wanted a bit more realistic gameplay (ie. limited life support etc.) but at the same time play as stock as possible - but all of this has made me set up a few new copies of the game for checking out USI/MKS and such. Wouldn't it be something if I end up buying this complete beast of a computer, only to have KSP2 solve all the issues I was having a few months later? Nah, who am I kidding: I'm doing this for the joy of buying spiffy new kit as well as playing games

I would love to, but I'll have to dig for the actual launch files of the bugger. It's a 555 part exploration vessel, and assembling it from its constituent parts in orbit was such a hellish experience that I chucked the craft files, so it only exists fully assembled in a savefile right now. Thanks for the advice, though! (EDIT: I did find some of the staging files, though - they're older versions than the ones I eventually launched, though.)

Assemble this in orbit: At 2 frames per second. (That rotating ring affects the trajectory, by the way. Almost ended this little venture by smashing straight into Duna...)

Hi. I'm running KSP on an old office notebook, a MacBook Pro 15, with an i9-8950HK, 32G of RAM at 2400Mhz and a Radeon Pro 560X with 4 GB. It's a pretty good piece of hardware for the work that I'm doing, especially since most development is being done in clouds anyway, but now that my KSP vessels have grown beyond 500 parts (after launch), I'm starting to feel the pain: FPS is down to single digits most of the time; the mission clock doesn't ever show green anymore. I'm not sure what KSP does to my CPU, but it sure as hell gobbles up all the memory, to the point where I'm having trouble running an 8G VM alongside it. Docking a 500 part exploration vessel to an 800 part space station for refuelling is an amazing experience even without the Kraken intervening... Since removing all competing software from my office notebook isn't an option - I do have to occasionally do some work - I figured it's about time to start thinking of a machine specifically for playing KSP, on which I can tinker with the game's configuration and settings without that nagging feeling that I really shouldn't be doing this on my office laptop. This would be a machine that's designed around KSP, that has the sole purpose of making me not-eat-my-fingernails during docking manoeuvres. I want to explore two options: A notebook: I figure it'll give you less bang for buck than a desktop solution, but I like being able to drag it along to the back yard and sit in the sun for a bit, with my game of KSP and a cold beer. A desktop: less mobile, but more easily upgradeable, and more power for the same money. Things to consider: CPU: AMD or Intel? Which has the best IPC and clock speed? Which models have a good cache speed? Where can I get the best single core performance for the notebook and the desktop solution? There's plenty of benchmarks to be found on the web, but which ones are useful for gauging KSP performance? Mainboard: in case of desktop, I'll have to think about the mainboard under my CPU. There's plenty of options for most CPUs on the bench mark lists. What should I look for in a mainboard that's relevant to KSP performance? RAM: more is better; faster is better - I think I will be able to manage that part. GFX card: I'm getting mixed messages from the boards about how much and in what ways KSP performance is affected by which items, but most people seem to agree that if you're not playing with all graphics and visual mods maxed out, then CPU performance is probably more of a limiting factor than GFX card performance. So I'm going to go with a budget card. What affordable cards are available that perform okay for KSP? What should I look for? Of course I've been reading through these forums, trying to glean some understanding from the discussions here, but there's so many contradicting and/or confusing opinions that I thought I should add some more to the mix. Most of those threads are pretty old anyway - very little info on the most recent Intel/AMD releases, yesno? (Which brings me to another question: why isn't there a section of the forum dedicated to hardware discussions? Or is there and did I just have the wrong glasses on? Should I move my question somewhere more appropriate?) So if anyone wants to tell me what hardware they're using to get a decent framerate with 500+ part vessels, or what characteristics I should look at in the bits of hardware I need to purchase for a dedicated KSP machine, I'd appreciate the input! Gr, H.

Commenting on one out of a thousand similar questions is probably a waste of time, but I often run multiple instances of KSP so that I can sandbox new designs while editing them at the same time. This is a bit harsh on my not-game-optimized old laptop, though. And my desk is a bit small for having two KSP-dedicated machines on it... Having a standalone VAB/SPH editor would seem a nifty thing to have. The best argument against is is that ' nifty thing to have ' probably does not make it worth the effort of developing and maintaining it. I, for one, couldn't be bothered - I'll just have to get a bigger desk

Unfortunately, the manoeuvre occurs at the very end of the burn to maximize apoapsis, after the vehicle has already left the atmosphere. I probably will, though I suspect that all automated ascent routines will seek to make tiny corrections when the trajectory deviates from the ideal.

Thanks for the carbs. I'm getting an FPS of less than 2 with some of my 1000+ part launches, on a pretty decent i7. I'm guessing we're just scr*wed unless someone comes up with an entirely new physics model.

So, I've been messing around with a huge launch vehicle, trying to get my latest versatile asteroid hunter into orbit in one piece, rather than having to break it up. There's a problem with the design, in that there's a lot of stress on some of the key components of the structure. I got the design to work, as long as there aren't any huge lateral forces applied to the structure. And there's a problem with that. Because each launch attempt takes almost an hour to run, at about thirty frames per minute, and it's nearly impossible to manually control the rocket under those circumstances, I've let Mechjeb do most of the work. But Mechjeb has some peculiar notions when it comes to thrust vectoring. It thinks its a good idea to start its gravity turn by making a sharp turn as soon as vertical speed exceeds 100m/s, applying lots of lateral stress. My game pauses, the program takes a couple of minutes to think about the development, and then I get to see my ship do an extremely slow unplanned disassembly. I've tried to disable thrust vectoring in the editor - but Mechjeb doesn't seem to care. Likewise if I tie thrust vectoring to action groups: thrust snaps straight when I lock engine gimbal, and then, next frame, is vectoring again. ... O. While I was typing this, I was running an experiment with the gimbal not locked, but limited to a few percent. And Mechjeb doesn't seem to ignore gimbal limits. Currently the game is thinking about the next frame. I hope it's just staging, not a SUD. Anyway, my original question remains of some interest, I think: is it true that Mechjeb ignores gimbal locking? v1.7.2 64bit/Linux

Another tip that's been of much use when I first started: Build your rockets top-down, starting at the last stage, and adding each prior stage to the bottom, keeping an eye on the total dV. - For a simple 90km-orbit-and-return mission, start with the part that actually gets to orbit: give it just enough dV to return from orbit, say about 100 m/s. TWR doesn't matter at this stage, just dV. - Then start building the stage below that: give it just enough oomph for a final kick into orbit, assuming you've gotten your apoapsis up to 90 km with a surface speed of some 2200m/s: the circularization burn. If you do your gravity turn right, that's somewhere around 1000 m/s. Again, TWR isn't really important at this stage, as long as you can apply the final 1000m/s before you re-enter atmosphere. - Then you build the part that actually gets your apoapsis up to 90km, and delivers that first all-important 2200m/s surface speed. At this stage, TWR is, naturally very important. If you've got powerful engines (eg. Mainsails), use them. If you don't, keep strapping on boosters until you've got that 2200 m/s And then it's just a matter of using all that dV in a more or less efficient way: start turning to the east as soon as your vertical speed exceeds 100m/s - but don't turn too fast: you're aiming for an angle of approx 45 degrees at 10000 metres. At 30000 metres you should be a few degrees from horizontal. Keep an eye on your apoapsis and periapsis while doing your turn: you don't want to reach your apoapsis too fast, not before you've gotten your periapsis as high as possible: that way, you can have a relatively short circularization burn, and aren't risking re-entry before you get to deliver the final m/s. O, and don't worry about details like max Q or friction: KSP is quite forgiving, and it's easier to just give your rocket a few more m/s of dV than to fine tune your ascent to deal with them. Anyway, that's how I got started. Took me a few launches before I had anything that didn't simply fall apart before getting up to a decent speed, mind you.

I have considered the possibility of hooking a couple of dozens of her up to a water reservoir, so creating a steam powered lift vehicle. I'll start working on the Girlfriend Fury Steam Engine Mod as soon as I've taught myself to program.

Perhaps something like "stress X on component Y exceeding threshold Z", for preset thresholds. But that's for another thread. I've been browsing threads on increasing performance of the game, but other than porting KSP to some as yet not extant experimental quantum computing system, I guess there's no such thing. I've been setting my 1000+ part launches to run overnight, but my girlfriend isn't happy with the noise of CPUs crunching physics...

Thanks for your response! F3 gets me part of the way, certainly. But often enough, the first sign of anything wrong is a reported 'collision', where there should be no parts actually capable of colliding, unless there were some really peculiar sheer forces working on them. I'd like to understand the failure mode a lilttle bit better. I suppose trial and error is the best way for now.

Good morning! I've been searching the forum for a bit now, and I don't doubt this question has been asked before, but it's been hidden so well that I thought it easier to just post a new one. As my contraptions have grown ever more massive, so has launching them into orbit become more of a chore to my CPU, and myself. Especially since the increasing stresses on the various components of my ships make failure at some point during the launch more and more likely. From the KSP.log, I've got a pretty good idea of the cause of most failures, but I'm still lacking a log that tells me exactly what the failure mode is, eg. [2019-07-05 17:39:59] AFF59 Aeroshell ID=237849 failed because number of transverse Gremlins (6) exceeded max design limitations (5 transverse Gremlins). Is there a standard feature of the game that does something like this, or is there a mod or other bit of tooling that might tell me more about the exact failure mode? Playing KSP_1.7.2 64bit on Linux, MH + BG DLCs installed, with basic utility mods, but no parts mods. Thanks!