Jason_25

I just tried overclocking from 4 ghz to 4.4 ghz on CPU core and cache. I also used the Linux cpupower utility to set the performance governor for the CPU. This is a 10% overclock so we would expect as much as a 2 FPS gain or so but FPS was still no more than 23 steady but it did briefly blip to 24. The bottleneck is all inside the game code itself. Games like Starfield and Cyberpunk 2077 and Mechwarrior 5 all run very fast at 4K on this system. On basically every other game you can see all the CPU cores near max usage but this game uses about 20% on all the CPUs and occasionally maxes out one CPU for a split second then goes back to basically doing nothing. So I am afraid I could go through all the trouble to build a new system only to get about 25 FPS max with the way I build ships.

Steam deck and laptops are mobile systems. My Mobile Internet Device project is like a smartphone but will run KSP 1 just fine. Part of the reason for this post is I would like to see KSP 2 running on one of my future Mobile Internet Devices. But the point was these mobile systems are going to be self-limited and can still benefit from tweaks here or there whereas larger systems are limited by the game code itself or relegated to needing hardware upgrades. I think this is why my Durandal Excalibur cruiser runs so bad. It has countless fuel tanks. I wanted to fill all the otherwise useless fuselage space with hydrogen. It Is the "test" vehicle mentioned in this thread and the "control" vehicle is VTOL Quebec. Both can be seen in this mission report: Thanks for all the replies.

I have just finished several hours of testing today to see why I have been getting such bad performance. Instead of posting all my testing results here which would just confuse things I will just post my conclusions. My gaming system has an i7 6700K/32 GB RAM/Radeon 6800 16GB. Linux kernel version 6.5.0-0. Performance was similar on Windows 10. I wanted to preface this by saying this is for gaming systems only not mobile devices that are constricted by hardware and run other games slow too. My system only runs this game slow. Every other game is super fast. So tweaks can still help slower systems. On to the results. 214 part test vehicle has 23 FPS on runway. 89 part control vehicle has 49 FPS on runway. There is no difference in FPS without the launcher and on a "clean slate" and a well used installation with the launcher. There is no difference in FPS between 720p and 4K resolutions. There is no difference in FPS between all low and all high graphics. There is no difference in FPS between all Proton versions available on Steam. There is no difference in FPS between default and the launch switch -screen-quality Fastest or with --screen-quality Fastest. There is no difference in FPS between environment variables listed on the KSP 2 and Proton thread except WINED3D which is slower. We can see that there is a pretty linear decrease in FPS with more parts. It throws a wrench into the interstellar plans for sure and for people like myself that like to build big and comfortable and safe ships. I think that for too long we have been leaning on the rocket equation as the crutch for why large ships are not or should not be built. But there are "bigger" things to consider like aircraft carriers, colonies, generation ships, O'Neill Cylinders, and highly efficient Sci-Fi vehicles that defy the rocket equation. Some people think that we will have single parts that will be very large that will make large vehicles a reality but we need that now. Something like procedural fuselages and fuel tanks. Or they can take an honest look at the problem another way and figure out why a game with cartoon graphics is having such bad performance. It cannot just be the physics that is slowing the game down. We had exploding body physics in games back in the 90s like Unreal Tournament or moving physics objects like in Jurassic Park Trespasser. There has to be some major major problems with the game code somewhere.

Mission highlights and objectives: Test stacking several ships together mostly inline as a huge upper stage with almost 50K DV in orbit Test multiple corridors or passages that break up an otherwise linear design Test "fallout shelter" with various objects shielding Spiderbot berths while in transit Test Durandal Excalibur as a carrier with parasite fighter in an extended mission Test VTOL "Quebec" STOVL performance as parasite fighter on Laythe Test Islandhorse with aero drop tanks on bonus Jool mission to establish elliptical orbit and launch probes Test Headless Horseman probe alpha on bonus mission to "land" on Jool's surface Test Headless Horseman probe bravo on bonus mission to establish a low orbit around Vall Test Spiderbot on bonus mission to establish a low orbit around Bop Mission synopsis: With assistance from 2 "Gargantua" class boosters and Islandhorse the launch stack roared into space and established a parking orbit. The frame rate is so low here that any redesign was essentially impossible. This mission had to be one shot once we made orbit in terms of redesign - not so much in terms of save/load. The transfer to Jool went uneventfully and we were set up with luck for an easy burn to encounter Laythe for an aerobrake. It was at this point that we realized that it would be best to begin to deploy vehicles from the stack so the aero vehicles could enter Laythe's atmosphere alone. As outlined in the mission highlights and objectives these bonus missions were successfully spun off. Notably Pol and Tylo were not visited as the goal quickly became to leave hardware on each visited world as a kind of rule. Most suprisingly probe alpha did successfully touch down softly on some sort of surface on Jool after deploying a parachute making for a very strange hazy green view of the sky above. By now, the only bugs encountered were low frame rate during launch and various bugs with the maneuver planner. But that gentle beginning of the mission was all about to change. The trouble really began at Laythe atmospheric interface. 3-4 FPS was all we could achieve here and a series of complex structural stability and other bugs ensued for the aero vehicles. Certainly the aero vehicles have an "aggressive design" with a fair amount of clipping but the game waits to punish you for these things at the worst possible times. Very little could be done but a large amount of save/reload actions here to keep the right wing and right engine from falling off Quebec. This was the first nightmare. We have the terrible heating system disabled so aerobraking slowed us down hugely after working past the bugs. After aerobraking and establishing orbit the aero vehicles were separated. Eventually both Aero vehicles were landed on Laythe's surface. Second nightmare was with Quebec which has a bug with the cargo bays that it thinks it is crashing into ground at 100 meters but a VTOL landing instead of a conventional one solved that. Third nightmare was with the Excalibur deorbit and landing that has 2 separate random structural stability bugs which include random rapid shaking which destroys the vehicle and random loss of part cohesion which could not always be worked around with save/reload or fast forward. To make things worse, K2-D2 does not handle as well as SAS alone, triggers structural stability bug 1 more often, and does not give good feedback during an emergency that it has taken control away from the player. Furthermore, fuel COG is an issue with Excalibur and there are too many tanks for a manual transfer and it takes too long to transfer fuel during an emergency and there is no automatic facility to do so and the game logic does not prioritize fuel consumption well. All of the troubleshooting and desperately grasping for answers happens at 3 FPS which is both a good and bad thing. Ultimately we have found it is best to let Excalibur flat spin towards the ground and orient retrograde at about 2000 meters altitude and fire the engines full blast and switch SAS mode from retrograde to normal. At low altitude it is controllable at a low thrust setting even with the COG pushed far aft and even with structural stability bug 2 happening. This is a good design - the trashiness of the game code is trying to destroy it but it just keeps flying. Eventually Excalibur made a conventional landing around 3KM from Quebec and Quebec taxied over to it because it would have taken hours with the framerate so low to do it the other way. Finally Excalibur takes back off again but not before another bug/poor game design with Jeb not being able to join Valentina because he can not get out of the cockpit of Quebec. Valentina checks out the clouds and gets used to the controls before climbing out using Tylo for a gravity assist back to a Kerbin aerobrake and landing. A bonus nightmare if you will is getting the deorbit right so we deorbit anywhere near the space center and also without a ridiculous vertical velocity but also do not overshoot! Then there is of course the same nightmare #3 that happens on Kerbin after deorbit as well. During landing we had a really strong 7 FPS so that was a happy time The FPS drops a lot when "in play" and the engines are running so the counter does not show how low the typical FPS is. Anyway bugfest complete. Comic strip captions: Upper left - Orbital stack shown. Includes Islandhorse+ and 2 headless horseman probes. Next in line is crew-optional Spiderbot. Above Spiderbot is the interstitial stage. Next in line is Excalibur with the mini interstitial above and then VTOL Quebec above the mini interstitial. Upper right - Landed at Laythe. The aspect here causes Quebec to look larger and Excalibur to look smaller. Note that running through rocks has no affect. The other vehicles at this point are all still in one piece and on bonus missions. The sky is very gray but flying is not much different. Lower Left - Flying in clouds of Laythe. Initially I thought the trailer showed Valentina flying on Laythe but now I see that there is a ringed planet in the background. Also the clouds in the trailer are larger and more numerous than the wispy clouds of Laythe. There is significant haze in the air. Lower right - Stopped at KSC. Do not be fooled by the fuel level because this vehicle has 45K DV when fully fueled. A lot of fuel was used fighting with it due to bugs and design deficiencies with the game. With some reinforcement or structural bug fixing much less fuel could have been used. The lighting is amazing here. Note 1 - If you can not see the comic strip then reload or try a new tab or restart your browser. Thanks for your understanding. Note 2 - Most of these are modded vehicles that I shamefully call "Cheatbirds"

This is a holiday update. I changed the name of the type of thread from hangar to preview because I do not yet have time to post vehicles but have updated a number of them. I think it is fitting though to kind of begin the year of gaming with KSP 2 and end the year of gaming with KSP 2. One of the games I was inspired with this year was Mechwarrior 5. Many times this starship "Leopard" came down from the heavens and saved me and my team. In the game it is impossible to trade fire with this beast. When it takes off it flies away at an incredible speed - this one does not. It is built with around year 2050 technology - my mod - but in the Battletech universe it was probably more like 2700 or so. Pictured is "Super Leopard" with a fair amount of Delta-V but little room to store multi story robots inside. With better technology it would be possible to free up some more room inside for mechs and Major Ryana and stuff like that. I wanted to add that if you had a vehicle with certain engines from an early version of the game then at some point in the summer those vehicles became corrupted and would not load in newer versions of the game. Fortunately I had a backup of the old version of the game and saved the "spaceframe" without systems of a number of the previous vehicles including the SRF lineage vehicles as in the first post. The bad news is that I am finding it pretty hard still to develop heavy advanced sci-fi VTOL vehicles. This current Super Leopard was quite difficult to finish before Christmas. I found the hard way that the center of gravity had to be very far forward from the center of lift in this design to keep from losing control shortly after takeoff. Also to get at least 25K DV, VTOL, and controllability - even with my mod for 4000 isp engines with increased thrust - the Super Leopard footprint was practically required. edit: i have updated the main site link. I did not post the cheatbirds for the same reasons as before. I have not packaged my mod in the correct way for distribution. But mod notes are there and if someone is particularly interested in one I will see what i can do. If you are looking for pictures of Leopard they are on the main site now to keep from linking so many pictures.

I will try and post a screenshot on this thread when I am finished. I do not like to post half-built or broken things. Further, I have not posted the "cheatbirds" craft files in the past because they require mods to function correctly. My mods edit the game files directly and those cannot be ethically posted so I would need to direct someone on modding the files manually which I do not mind doing. Good question on why I need 80 ton wings - why are the default wings that heavy? Every time I try to make a "large" wing larger than you can make with the "small" wing they turn out very heavy. Though like I said modding the density was the key. I tried to keep the game balance the same by modding the density of the small wings also but their initial weight is kept lower. Now the same large wings weigh about 6-7 tons. As far as failing, by that standard everything I have made is a failure. I have a certain visual standard and look that I go for that as just as important as anything else. In terms of performance I also push for 50k DV but I have had to settle for less since we have such bad technology right now. For instance this Thunderbird Bomber with wings as wide as the runway has 33K DV (modded). You only need like 3K DV to qualify for SSTO status. On the subject of struts that is a tradeoff you make when you spend less time building a creation. Sometimes less struts is better than more struts. When you focus time on deciding exactly which strut is necessary or not you can trim the design down. I cannot imagine a 400 part design could not afford to lose a strut here or there. This Thunderbird Bomber is around 80 tons dry and 220 full with just around 160 parts and is quite huge. I have completed some initial flight and orbital tests for this bomber. I am now proceeding to make a multi mission module for the rear of the bomber that will hold extra fuel and engines for a vertical launch. Then will come integration of 2 probe units and the vehicle will officially become a mission and go off to Jool. The mothership bomber should have plenty of fuel to dip down into Laythe's atmoshere and look around for itself if necessary. Since I have wrote an essay already I will include some thoughts I had while building this bomber. Sometimes the wing control surfaces are worth very little. The amount of flex and vehicle destruction they were causing was remarkable with this flying wing design. I have resorted to setting the outer wing controls to be toggleable to allow more control at lower speeds and to be turned off near max-q to keep from destroying the vehicle. I was having to make a gross tradeoff between vehicle stability and vehicle maneuverability. It seemed an infinite number of struts was going to be required until I did the aforementioned toggle and limited the main inner wing to 7.5% authority, and added 10-20 of the largest SAS units from 0 before. These SAS units thankfully took some of the wing loading off the vehicle making the partially SAS-induced aeroelastic flutter hopefully manageable. I am also using modded small nuclear engines which lack gimbals making the previous issues with wing loading worse. The woes of truly large vehicles. It was however good to see no need to invert any flight controls this time either. After thinking about it I suppose a large craft could be made with 5 tries or less. Cockpit, fuel tank, large wings with struts top and bottom and engines balanced with weight and aero and of course landing gear. That would be a challenge all in itself but I do not make ugly stuff so am not interested personally. Would they be able to place just the right amount of struts at just the right place?

I see the aerodynamic bug was fixed and I am sorry to have even mentioned it. It does look like the unused medium nuclear engine was removed. Maybe it will make a comeback some day. There is even a dev blog entry for it from a while ago. I was using the in/out animation functionality to tradeoff between the large turbofan engines and the rocket engine in my F-32 design. So you chose one or the other. When the engine was deployed, only it's thrust was useful, and when the engine was retracted only the turbofan thrust was useful. So it made an interesting design where you chose one or the other instead of having the rocket supplement the jets. I have now instead modded the small nuclear engine because it is a piece of junk and nobody uses it anyway. Same 4000 ISP in space and 1200 ISP medium level and 750 KN thrust as the modded medium engine from before. All the cheatbirds I made from Patch 2 will need to be stripped of the medium engines with the Patch 2 version of the game to be moved to this version because they are very bugged in Patch 3.

It appears that they have moved the part configuration files into separate Unity addressables files instead of one large obvious file containing all the part configuration files in one. There is no conspiracy here and they probably did it for performance or maybe organizational reasons. It does not look like there is anything keeping anyone from adding fuel tanks to the wings and it would probably not be that hard. Anyway I changed the density of the wings to like .01 from like .150 and that fixed it up nicely. Now the wings weigh like 6 or 7 tons a piece which is reasonable. Now there is really no more "room" for fuel tanks and thus nothing to complain about. As a bonus the wings don't instantly fall off and require 50 struts like they used to. Game performance is better and the vehicle is far more realistic. edit: I wanted to mention that the weight edits to the wings did not work within the craft file itself. It had to be modded.

This thread is about big spaceplanes though. Of course you can build something small and have it work first time. This is the intended way and what the developers have tested for. But for big spaceplanes, I just tried to build one without cheats and wings were 80 tons a piece causing the vehicle to fail instantly. Also I was needing to make numerous strut connections between the "350" series hydrogen tanks before they would randomly stop exploding. This is much more punitive than KSP 1 though it may be due to the weight of the parts being higher than typically used in KSP 1. Modding the density of the wings cured the first problem and trial and error strut additions cured the second problem. I am still faced with the standard "large space plane falls apart right at V1" but that is to be expected and something that we faced in KSP 1 and is going to require more careful wing strut additions and possibly control surface tweaks. Each large vehicle in this game takes me at least 50 hours but I am trying to do this one in less than 20 hours.

You should build basically one piece at a time and see if it explodes after adding every piece. Once you have enough fuselage pieces add some landing gear and send it down the runway without wings. Then add wings and do a series of high speed taxi tests. That is kind of the only way for large planes right now. You cannot just build it all at once and then tweak a few things after a few tests like with KSP 1. After several hundred or thousand iterations you will then have a flying example. With that said, I am working on another flying wing that is as wide as the runway.

Use the "workspace file name" field and ignore the "vehicle name" field. The overcomplicated nature of it bothers me too but this method should work. I am suprised you do not have an auto save. The game makes like 50 auto saves an hour for me and I hate them and never use them. Once you get into the habit of saving files like spaceship1, spaceship2, spaceship3 and so on you will never need the autosaves anyway. With drive space like it is today, you can save a new file name for every single change if you want.

I am not having any luck modifying any of the game files any longer. I can not find the JSON configuration for the stock parts. Additionally, they appear to have removed the unused medium nuclear engine I was using as a modded engine. Is there a way to upgrade engine thrust or ISP in the craft JSON file? So far, changing the REALISPVALUE for engines does not work to change the ISP. This is because the "real" ISP setting is the ATMOSPHERECURVE setting for the engine which is not available in the craft file. Nice red herring thrown in there. Similarly, I can find no way to increase engine thrust. I have successfully modded the weight of the large wings because that is still bugged. My large wings weigh 80 TONS a piece. That is heavier than an Abrams tank on each wing. I have reported the bug months ago and it is not going to be fixed. Anyway the MASSMODIFIER setting can be changed to around 1 ton or so. They should be heavier than this but I am trying to get all the performance advantage I can. Unfortunately, this must be modified every time something is changed in the game so is ultra tedious. A script could be used here to automate this I suppose. It is easy enough to check if it works, the wings still simply fall right off without being modded so that bug has not been fixed either. Wings still do not have integrated fuel tanks either which is something we have in KSP1 and would at least be an excuse for why wings are so heavy. So you can see that it is quite pointless to post on the bug tracker and the only hope we have for this game is to take the problems into our own hands. I cannot provide any meaningful feedback anymore either because I cannot work with 300 ISP deathtrap vehicles with no fuel reserves. This was supposed to be the big upgrade to KSP where we do not have to worry about modding in better engines but here we are left with very little or nothing on that front.

I have been digging into the game files since patch 3 and I can see that a lot of things have changed. I no longer see a file that contains all of the configs for the parts in one place. Before, even without modding this engine into place the game would recognize my vehicles with them. Now there is an error. This error combined with not being able to find the medium nuclear engine part anymore leads me to believe it was taken away. I was using this engine along with modifications to 4000 ISP and 750 KN thrust as a kind of placeholder until an Interstellar mod comes along or the developers release the nuclear salt water rocket or Orion. Now my totally cool vehicles based on it are broken. I do not like to have only enough fuel to scrape by and this was a better alternative than using infinite fuel as 4000 ISP is the max conceivable efficiency for a nuclear fission type rocket as I understand it. Since they have not added anything interesting since the last patch and there is apparently a big aerodynamics bug now I am disappointed. I am having trouble coming up with the energy to restart development due to this.

Are all of those bug reports where they should be, in the bug reporting forum? Not to toot my own horn too much but I have over 30 bugs submitted on there and do not see your name much in there at all. Guess what? You will know what happened to those bugs when you have placed them onto this forum into the correct place. When you use your "privileged" line of communication with the developers it keeps the rest of us in the dark. I would say get to work on putting some of the bugs on the forum where they belong.

They took away the aerogui so it is harder to design for aerodynamics. You sometimes have to balance space performance and atmospheric performance. The airliner jet engines on there do not go very fast and are very efficient as you can see in the first picture so there is not much need for aerodynamics. The "DIY interstellar" modded nuclear cheat engine in center has no need for that either as it is very efficient with 4000 isp and 750kn thrust. Additionally, the real F-32 is not super aerodynamic but as I mentioned the "Mike" model I made is more aerodynamic but will never be going to space by itself because it has a thinner body. I like the idea of huge fighter planes so adding more and more fuel is fun even if it makes the vehicle look fatter. This vehicle is a true VTOL with enough power with 4 panther engines under afterburner to easily lift it with the huge DV loadout. I typically launch it like a rocket with small long rockets under the wings and with hydrogen droptanks on the other hardpoints. Before they took the aerogui away I noted that launching like a rocket somehow gives a plane a higher top speed at least with the whiplash engines. I will keep those SAS units in mind but I do not plan on doing more extreme landings like that. Other vehicles in the line like "November" are for lunar landings with 2 small nuclear vertical engines. There is another variant "Lima" with aerospike vertical engines with more TWR. Then there is "Papa" with rocket style landing only with a cocoon of liquid engines and parachutes around it for venusian operations with mega TWR. Balancing fuel manually and changing one set of vertical engines thrust limiter dynamically are other ways to balance without taking a hit on DV. I should have added that I did try to transfer fuel optimally manually before the summit attempt but control was still marginal at that altitude especially when perched at an angle. This vehicle is duel fuel with hydrogen for the cheat engine and methane for the large jets and panther vertical engines. It does not seem possible to design this vehicle in the way that methane flows evenly. This is because hydrogen fuel has been prioritized over methane because I never want to get "stuck" in space. So roughly speaking the methane is at the front, the engines are at the back and the hydrogen is evenly distributed along the sides. Because there is so much engine weight at rear a hydrazine "ballast" would need to be inserted at the nose which would affect the vehicle's ultimate fuel mass percentage. But I only use ballast on planes if I have to and never on space vehicles because of the aforementioned problem. So unbalanced methane on the nose it is. There is enough time to transfer fuel on the go under SAS control or after an austere STOVL landing. To me the in-game lighting both at the space center and on vehicles is really weak right now compared to KSP 1 and I did not want to go overboard on the parts as it was around 100 already. The mountain was unrealistically pitch black but I landed anyway. But the real problem was suspension settings causing a bounce and flipover. The save/load system works perfectly for me and with the morning light and brake and suspension and fuel distribution tuning the landing was successfully accomplished on the next try with a little luck. It would have been better to have an antimatter powered nuclear thermal engine because even with 12000 isp or whatever I only get about 2 hours flying time given that so much fuel weight has been prioritized for hydrogen. I need a good 100000isp or so and about at least 50k DV to really be happy. So the suborbital jumps were necessary unless I wanted to sputter around at 150 mps and then run out of fuel shortly after. I refuse to dedicate more mass to terrestrial usage though! It pains me to think of having to add a bunch of whiplash engines on there just to slow the game down and get a pathetic speed boost compared to the Interstellar engines I am used to working with. The technology we have to work with now is just absolute Oregon Trail trash and it is a miracle that I could accomplish what I did with that mission.