Search the Community

tl;dr: summary at the end of the post I am aware the problems of the current maneuver planning tool have already been discussed on this forum by multiple players: the prediction stopping when out of fuel, the inability to set the maneuver at the next orbit, the lack of number entries, the inaccuracy of the progress bar... Here I want to bring a mathematical insight to why, even with all these problems dealt with, the current maneuver planning system would still be inadequate. The current advantages of the maneuver tool are the ability to see the real trajectory followed by the spacecraft during the burn, and to evaluate its end point. It is a huge advantage, especially for long burns. However, the predicted path is computed by assuming the direction of thrust is constant, and set at the beginning of the burn, and that is the heart of the problem. Take for example the following vehicle, that has 4072m/s of ΔV and a TWR of 0.29, placed on a 100x100km orbit. I want it to transfer to a kerbostationary orbit at 2863km of altitude. Picture: Test vehicle With a theoretical instant impulse, the Hohmann transfer is 651m/s for the apoapsis raising (going from the 100x100km orbit to a 100x2863km one), and 424m/s for the circularization at apoapsis (from 100x2863km to 2863x2863km). The return trip costs the same, 424m/s for periapsis lowering and 651m/s for circularization at 100km. These are the ΔV computed by the maneuver tool in KSP1, because it was computed assuming an instant impulse. Picture: Principle of a Hohmann transfer Of course in a real situation the maneuver is not instantaneous, and the player has to find a way to perform the maneuver with this limitation. In KSP1, the usual technique was to point the spacecraft in the direction of the maneuver, and start the burn when the time before reaching periapsis is half the duration of the maneuver. So basically the node is approximately in the middle of the real maneuver. By doing this technique, the ΔV is 659m/s for the apoapsis raising and 424m/s for the circularization at kerbostationary altitude. The return trip costs 424m/s for the departure and 651m/s to circularize at 100km. With different spacecrafts, the ΔV cost varies according to their TWR. For this spacecraft in particular with an initial TWR of 0.29, the cost is very close to the theoretical Hohmann transfer (only 8m/s of loss). Picture: Direction of thrust with KSP1 method In KSP2, the new maneuver planning tool computes the predicted path of the spacecraft during the whole duration of the maneuver, assuming that it is pointing in the maneuver direction. This direction is inertially fixed, and computed in the orbital frame at the start of the maneuver. This means it is no longer possible to place the node at the middle of the maneuver. When planning an apoapsis/periapsis raising/lowering, if the player sets a prograde/retrograde maneuver (as was done in KSP1), the spacecraft will be pointing straight in prograde/retrograde direction at the start of the maneuver, and slowly drift away as the orbital frame changes along the trajectory. By doing this technique, the ΔV is 700m/s for the apoapsis raising and 426m/s for the "circularization", but the orbit is much more elliptic than KSP1's technique (2847x2880km instead of 2863km). And the return trip costs 424m/s for the periapsis lowering and 671m/s for the circularization but again it is impossible to circularize with this kind of maneuver. The resulting orbit is 59x151km. So the ΔV cost is much higher using this naive technique introduced by the new planning tool. This is due to the thrust direction being suboptimal. In these maneuvers (apoapsis/periapsis raising/lowering), the goal is to gain or lose orbital energy. The optimal way is to thrust in the prograde or retrograde direction, every other direction introduces a loss. The greater the direction difference, the higher the loss. KSP1's technique keeps the thrust direction pretty close to the optimal direction, therefore the ΔV is close to the theory. In the naive KSP2 method, the direction is prograde/retrograde at the beginning, but the difference is much higher at the end of the maneuver, therefore the loss is much greater. In this particular case, the loss is 81m/s, 9 times higher than with KSP1's planning tool. Picture: Direction of thrust with KSP2 naive method Picture: Resulting orbit after the periapsis circularization With KSP2 current tool, it is in fact possible to perform the same maneuver as with the KSP1 method, but the player needs to correct the direction of thrust with a radial-in/radial-out component. So the new method would look like this for a circularization at periapsis: set a maneuver at periapsis with a retrograde component so that the apoapsis is approximately at the good altitude; move the maneuver so that the the periapsis is in the middle of the path; add a radial-in component to the maneuver so the resulting orbit is closer to a circle; tweak all three parameters until the projected orbit is as close to a circle as you want. It takes only five minutes to do in KSP2 what took two clicks in KSP1. What an upgrade! Now what I'm proposing is to change the way the planning tool computes the maneuver direction. For these kind of maneuvers, I would like the maneuver to be computed in the orbital frame that moves with the predicted path. Which means, when a maneuver is set with a prograde component, the maneuver marker stays exaclty prograde during the whole duration of the maneuver. Picture: Direction of thrust always prograde This is what happens when you burn always prograde/retrograde in my example. The apoapsis raising costs 652m/s of ΔV. It is very close to the theoretical ΔV, but as a side effect it also raised the periapsis by 7km. Therefore less energy needs to be gained at apoapsis, and the circularization costs only 418m/s. The total is less than a Hohmann transfer. For the return trip, the periapsis lowering costs 417m/s of ΔV. For the circularization at periapsis, I start the maneuver at such an estimated time so it ends at the periapsis, and it costs 644m/s. As I don't have an adequate planning tool, the circularization is not perfect, so the resulting orbit is 97x105km, but still way better than with the current planning tool. Again the ΔV is less than the theoretical Hohmann transfer. The total gain is 19m/s, minus some ΔV needed to properly circularize. The difference is even greater between the KSP2 naive method and the one I propose when the TWR is lower or the burn longer (e.g. for interplanetary departure/arrival). So with this change, the planning tool would allow the player to negate the losses induced by a suboptimal direction of thrust. However I don't think the current planning tool should be totally discarded, because in some cases maneuvers need to be planned with an inertially fixed direction. Here are cases I can think of where the maneuver should have a fixed direction: - plane change (changing the inclination) - fly-by corrections (changing the orbit in another SOI) - target corrections (reaching another spacecraft) It is not anecdotic, so it is better to keep the current tool available to the player. But the default planning mode should be the moving orbital frame, because here are cases where it is essential: - orbit changes (periapsis/apoapsis raising/lowering) - circularization - rendez-vous - lunar/interplanetary departure - interplanetary arrival (injection burn) - targeted landing - suicide burns Theses maneuvers are the heart of KSP2 game loop, there are essential to go anywhere. Ideally, I would like to have an option on the planning tool to compute the path either: 1. In the moving orbital frame 2. In inertially fixed frame 3. As an instant impulse The third one can still be useful to plan certain maneuvers that are not possible with the current spacecraft. For example, the player sets a station in high altitude orbit of Kerbin (with no engine), and now he/she wonders how much ΔV it would costs to reach the Mun with a space tug or a resupply module. With instant impulse planning tool, he/she can have that information that is not available in the VAB trip planner. TL;DR The current maneuver planning tool computes the future path by assuming the spacecraft points in a fixed direction. This is useful only for some very specific cases. In most cases such as orbital raising/lowering, interplanetary trajectories or landing, it is suboptimal to say the least. A better way would be to compute the maneuver in the moving orbital frame. It would be easier to plan in terms of QoL, and cheaper in terms of ΔV cost for most maneuvers. P.S. This posts echoes @Superfluous J tutorial (Don't just burn prograde!), where he/she shows the prograde maneuver is nowhere near optimal in terms of ΔV for an interplanetary departure. However, I would say the title is misleading: you SHOULD burn prograde and stay prograde, just not in the direction of the maneuver

Greetings to all KSP 2 lovers and developers! Sorry for my English, I'm using google translator. I hope he translates correctly. The fact that optimization is extremely important for KSP 2, and that everyone really wants it, has long been known to everyone. But I want to touch on a more specific topic. Where exactly is the very border when optimization can be considered sufficient? I personally think that optimization should be such that owners of not the most top-end computers can build orbital stations, planetary bases or interstellar motherships from 1500-2000 parts without a critical FPS drop. Someone will say that I've lost my mind, but ... we really are all waiting for interplanetary flights and colonization, aren't we? And how do you imagine a starship of 50-200 parts? In my opinion it would be a rather dull sight. In the first part, with mods for interstellar flights, a decent interstellar ship cost me about 1200-1500 parts. And yes, I played with 3-5 fps. In CPS 2, with such crafts, there should be at least 25-30 fps. There are many, many lovers of building complex, grandiose, large crafts. Yesterday I launched a rocket as close as possible to Saturn 5. With a lander and a command module. The craft consisted of 275 parts and I played with 7-11 fps. It's not bad. Before the release of the patch, it was even worse. But... it's only 275 parts. What happens if I want to build an orbital station with 1000 parts? As I liked to do in KSP 1. 1200-1500 parts in crafting at 30 fps, I propose to make it the very bar to which we should strive to optimize the game. Another question is how to achieve this? I have a suggestion. But I suppose the developers may not like it, because. this will require a major overhaul of the game. Now all parts in crafting are physical. Those. each piece carries a rigid body component. I'm right? It turns out that if a rocket consists of 300 parts, then during its flight the physics of 300 components is simultaneously calculated! And their interaction with each other! This is a performance disaster! And most importantly, this is absolutely not necessary for the game. It doesn't help the gameplay in any way. It just brings dangling, flexible rockets like sausages or jelly into the game. And he forces everyone to use uncomfortable struts that only irritate and spoil the appearance. Physics is not needed on every detail! And what is needed? We need one common rigidbody component for the whole craft! The rocket consists of 300 parts, but the rigidbody is one for everyone, common! If a stage separates from the rocket, it has its own rigidbody. Now we have two rigidbody on stage. Not 300, but only 2! If some part undocks, shoots back, falls off, gets damaged, overheats, it gets a rigidbody component and behaves like a separate physical body. But until the craft fell apart - it has only 1 rigidbody component for all its parts. Those who work in the Unity probably understand what I mean. How should parts be attached to each other, if not with the help of physics? With the help of inheritance to each other! Everything is simple! As soon as the part should fall off from crafting, it ceases to be a child for crafting and the rigidbody is activated for it. Why is it necessary? Productivity will increase not by percentages, but at times! Many times! It will be possible to create crafts from 1000-2000-5000 and even possibly 10,000 parts! And this is much more important for the game! Do you agree? Players will be able to build epic interstellar ships, huge bases on planets, complex rockets with complex payloads, cool orbital stations!

The challenge here is to build a craft that can get to orbit twice without refueling, staging, or docking. Score is based on mass - the lighter the craft, the better. Bonus cookie points if you make an all rocket craft. More rules: You must come to a stop at KSC or the ground nearby between orbits. (Screenshot at 0 m/s on the ground). Scoreboard: camacju - 9.2 tons

Hi So I just sold off my RX 580 graphics card and is currently using my backup GT610, and I am wondering if there are any ways to make ksp playable on that graphics card without sacrificing too much. I have a watercooled R5 1600x CPU and 16 gigs of ram, and I am currently getting around 4 fps with settings maxed out. What can I do to get my framerate above 30 fps while sacrificing the least amount of detail? Thanks!

Full disclosure, I'm an irredeemable mod-addict. However, I am intentionally asking in a stock modless context: What roadmap exists, if any, for KSP to receive optimization passes in future updates, if indeed any future updates ever come to pass? KSP is pretty much in a class of very few other gaming titles (Factorio being another notable example) which bottlenecks at the CPU and not at the graphics card. Worse, it's been the better part of a decade since anyone was likely to purchase a computer for use with computer games that had single-core CPUs, yet KSP still only utilizes a single core. Case in point, I run an octo-core i7, and while quads aren't exactly bargain-basement economy models quite yet, I think it'd be equally unfair to characterize hex- and octo-core systems as "newfangled" or "rare." In the context of my admitted mod addiction, I recognize that the more mods one uses (particularly plugins) the more likely any multi-core / multithread / optimization would be to bork the backend stuff that allows said mods to attach to the game so easily. That said... is hoping for 2015-cutting-edge performance here in 2017 really an unreasonable thing for a user to request?

Beware that this is heavy on screenshots, but they serve an important purpose! Dear @SQUAD here is something that really needs looking into if you are continuing the development of this game and that is graphical performance. This might come of as a bit ranty but bear with me. Your game looks like something from the early 2000s. It is not very impressive in the looks department at all. Your skybox is an empty blue, your water looks nothing like the real deal. There are no god rays, there is no bloom, no depth of field etc... There is basically nothing going on and still graphical performance is shockingly aweful. I have here a few nice screenshots that ilustrate this very convincingly. Follow me now on a launch of one of my SSTOs to orbit. Note that this savegame is empty, there are no satellites in orbits anywhere, no space stations hanging about, and no debris. There is only this SSTO. My SSTO is idling on the runway and graphic performance is okay at this point but it doesn't reach a full 60 frames. Notice that my GPU is also nearly idling CPUs are about 50 % used. My SSTO has taken off and is on ascent. I am fast enough and aerodynamic effects have kicked in. 50 % FRAMEDROP. Is my GPU that busy? No. Are my CPU cores bottlenecking? No. My craft is now higher in the atmosphere and the framerate has recovered after the aerodynamic effects are gone. Framerate is even above 60 frames for the first time because nothing but my craft is on the screen Now comes the speed up phase to reach orbital velocity. Aerodynamic and heat effects are visible. OVER 50 % FRAMEDROP. GPU? Nah still bored to tears. CPUs? Like walking to jogging active. The vessel coasts toward the apoapsis, heat and aerodynamic effects are gone so framerate isn't aweful anymore. The GPU is on 1/3 capacity like at all times and the CPUs the same as always. To some it up, at no point was my system overly taxed at all quite the contrary. KSP simply doesn't make use of available resources. And neither the aerodynamic effects nor the heat effects warrant a 50 % drop in framerate when the GPU is basically doing a whole lot of nothing. They do not look anywhere near good enough to warrant this happening. An effect that is so poorly optimized that it can murder over 50% of the framerate should not be in the game! This screenshot is now my SSTO on the runway with the Stock Visual Enhancement Mod which includes EVE, Distant Object Enhancement and scatterer. There are now, clouds, cloud shadows, atmospheric scattering etc. Framerate is significantly impacted by this. But is my GPU taxed to capacity? No. KSP leaves 50 % capacity on the table. The CPUs aren't that much more taxed either. Funnily enough there is ONE scene where my GPU is on full work load and that is in the KSP overview. Squad I don't even know what I should say to this..... Another bizarre thing for performance is the more part mods you have, the more your FPS suffer. What is even happening there? Is KSP rendering all parts including those that are not in use in the background? There must be a way to only bring the parts into the flight scene that are currently in use to circumvent this happening. Maybe you should take a page out of ferram4s book. And I don't mean make his FAR mod stock. As you know FAR makes it so that computation is not happening on all the individual parts but on a voxel model that represents the whole craft. To me that should slim down things quite considerably and help people who build huge crafts not to suffer 4 FPS in Space. I can only stress Squad that I think this should be the next big thing to work on. As totalbiscuit would put it: This is unacceptable opimization work. Please get this sorted out as soon as is viable! This was on KSP 64Bit latest version. I have an AMD System, maybe Intel fairs better? Here are my system specs: Item Details Windows: Windows Version 6.2 (Build 9200) (Win 10) Internet Explorer: 9.11.14393.0 Memory (RAM): 16284 MB CPU Info: AMD FX(tm)-8320 Eight-Core Processor CPU Speed: 4218,3 MHz Sound Card: Lautsprecher (Sound Blaster Z) | SPDIF-Out (Sound Blaster Z) | Display Adapters: NVIDIA GeForce GTX 970 | NVIDIA GeForce GTX 970 | NVIDIA GeForce GTX 970 | NVIDIA GeForce GTX 970 Monitors: 1x; Generic PnP Monitor | Generic PnP Monitor | Generic PnP Monitor | Generic PnP Monitor | Screen Resolution: 1680 X 1050 - 32 bit

Hi, I run KSP 1.2 prerelease on Ubuntu 14.04. I've followed every guide I can to increase my FPS, lowered every setting to the lowest it can be, (My computer is a lemon. Don't even ask!) and have it running as smooth as I possibly could get it to be. The problem is planet terrain. Say I have a ship in orbit around Kerbin and I rotate my camera to face space. Everything runs great. But say I rotate to face Kerbin. Everything starts to run slow and laggy. I've lowered my Rendering to Fastest, my Textures to Eight Res, and even created a custom Terrain Preset, "Lowest", where all minDistances = 3. I am wondering if the terrain detail is what is screwing with me though. Whenever I restart KSP, it defaults to "High." Stupid question, but could this mean that KSP is possibly rendering terrain using the High Preset even when it is set to Low or Lowest? I've also noticed that KSP still creates a log file, even when I turn on the "Do not create log" option in the launcher. Other than that, if anyone has any tips to increasing my FPS, mainly while at Kerbin, any help would be appreciated. This same problem occurs in older versions of KSP (so it's not just because of 1.2), and I've already tried redownloading the stock files multiple times. I can attach my settings.cfg file if needed. Ty ETPOF

KSP continues to show sadly lacking performance for the level of graphics and functions the programming has to accomplish, especially on weaker computers. This game really shouldn't take that powerful of a computer to run at vastly better performance levels than it does now, yet its performance for any given CPU and graphics card setup *is* lackluster relative to what it should be and a sometimes laggy game (especially on weaker computers) is what we have to work with... I have started this thread as a development discussion thread: to solicit discussion of what the devs could actually do, in concrete terms, to improve the performance of the game (this is NOT a thread for off-the-cuff suggestions by people with no understanding of game programming, I want to see people with actual programming and optimization knowledge make specific educated suggestions here), and to remind the devs at SQUAD that the poor performance and lack of real optimization in KSP is still a major issue they need to work on, one that is still very much holding the game back from reaching its full potential. For that matter, a small tangential bit of commentary and a liberty I am taking as thread author (please do not side-track the discussion by commenting further on this, it is only my opinion)- I do not think the game should ever have been declared "released" in its current state. In my mind, the game will never truly be an acceptable product for a released game until it has seen a substantial amount of additional effort devoted to improving the game's performance (reducing lag, CPU load, etc.) within the context of its existing features. Go forth and discuss! And remember to keep the discussion educated, knowledgeable about the subject of programming, and on-topic! - Northstar

Hi! Today I suggest a very simple but useful thing: a part search toolbar. A part search toolbar would be a tool to search parts to construction inside the "vehicle assembly building" and "spaceplane hangar". With every new version added more and more parts, and taking into account the mods, I think that search toolbar would be useful. It would be quite useful at times like parts experimental test mission, for example, where it is easy to forget the name while searching when there are many unlocked objects; another example is in case of have many mods. Do not think you need more details, it is a small utility suggestion without complexity.