DibzNr

@Whirligig Girl Merged your report with this one

@WingC3 Merged your report with this one

@jclovis3 This feels like more of a discussion subject than a bug report, so I moved this post to the discussion page

@Jeq Merged your report with this one

@Pat20999 Merged your report with this one

@Byzantion_dockyard Merged your report into this one

With KSP2 performance on the rise, it'd be great to have a benchmarking tool in-game that could allow users to consistently test their performance across a wide variety of game scenes, something akin to GTA V's "Run benchmark tests" option in its settings where the game runs through a series of in-game on rails scripted scenes designed to test the computer's performance, gradually sloping up in intensity and then outputting the results to a log file, having these scenes be scripted and consistent would allow for highly accurate measurements of system performance to be taken and make it much easier for users to quickly tell if they can run the game, as well as what effects graphics settings will have on the game's performance, it'd also aid a lot with user-polling of performance data across hardware.

That was to demonstrate the fact that the wings could sustain those sorts temperatures in the dense atmosphere for prolonged periods of times, I was never implicating that the wings overheating there was somehow incorrect, for them to be able to take that heat in the lower atmosphere and then almost immediately overheat and explode in the upper atmosphere travelling just 300m/s faster when the air pressure up there is less than a few pascals is absurd

Please bring this back, it was so funny watching Kerbals just tumble around like that

Just a small balancing suggestion, with the removal of the direct vs relay distinction between antennas (all antennas function as relays), it gives the KSP1 relay parts very little reason to practically exist compared to their deployable counterparts besides being immune to aerodynamic forces (Which, while giving a genuine decision making process for the smaller antennas, falls off with size due to the larger antennas often being very draggy). An example; comparing the HG-55 to its non-deployable counterpart, the RA-15, it's clear that the HG-55 outclasses it in virtually every conceivable way: It's much lighter (0.075t VS 0.3t) It has a much higher transmission rate (12.5 KiB/s VS 2.5 KiB/s) It uses much less electricity per KiB sent (0.7e/KiB VS 5e/KiB) \ The deployable antennas are lighter, deployable, more efficient and (barring the 88-88 vs RA-100) have faster data transmission speeds than their heavier non-deployable counterparts, to remedy this in my opinion the non-deployable antennas should be given significantly faster data transmissions speeds than their deployable counterparts (on the order of 3x their deployable counterparts) and better electricity/KiB efficiency, this would them much more of a gameplay distinction than their deployable counterparts and gives a genuine reason why players might choose to go with the much heavier non-deployable antennas compared with their deployable counterparts (Especially for missions that include time-critical EOL situations, such as an atmospheric entry probe that needs to transmit its science before being obliterated)

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB Severity: High Upper atmospheric heating (within the first 20km of Kerbin's atmosphere) seems to be oddly brutal, quickly building up heat and destroying most parts with even relatively low heat tolerances, particularly small and medium wings which are usually destroyed within the first 5km of the atmosphere, this issue currently renders most spaceplane designs much more difficult to use in missions as they are simply incapable of surviving atmospheric re-entry without propulsively slowing down to a safe speed to survive this atmospheric layer, which is highly impractical. I also experienced nearly identical results on Laythe, except even quicker. This is clearly an issue with the upper atmospheric layer, as the small wings are capable of surviving all the way up to 1.8km/s in the lower atmosphere (Where the air is much denser and therefore heating should be much worse), once this upper atmospheric layer is broken through heating drops off and returns to what would be expected, as shown in the attached video (Notice that the heat is dropping even through the craft has slowed by less than 100m/s). The lack of re-entry visuals in the video may be related to me teleporting into orbit, not entirely certain, could possibly be a separate bug. Included Attachments: Demonstraing the small wings "true" heat tolerance in the lower, much thicker atmosphere, they only just fail at around 1.8km/s (Air is much denser here, so they should at least be making it a good amount into Kerbin's atmosphere before exploding during reentry) Reentry time-lapse (5x speed), showing the wings overheating in the upper atmosphere very quickly and then mysteriously beginning to cool down after passing 50km despite barely losing any speed and being in thicker air. ksp2_x64.exe2023_12.16-22_18_53.16(1)-Trim.mp4

FOR SCIENCE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Amazing to see how far this game has come this past year, can't wait for For Science!!

Amazing job to the entire team!

Modelled it up, also used photoshop to make the icon render

Made them myself!

Introduction VTOL aircraft are awesome, they're fun to fly and land and generally are super cool: A big problem however is that KSP2 does not have any robotics parts, which severely restricts the options available when it comes to building practical VTOL aircraft in the game, and even when worked around you're still enduring a heavy performance penalty (both in terms of the aircraft's capabilities and your literal PC's performance) when compared with anything you can build in KSP1, those Whittle clusters and reaction wheels cost quite a bit! So, with the understanding that robotics aren't coming anytime soon, I figured I'd put forward my own suggestion for a nice alternative that'd fill this role perfectly, in the form of a brand new jet engine part: Introducing the J-8B "Karrier" Mass: 0.8t Maximum thrust: 80kN (Lifting capacity of 8.15 tons per engine on Kerbin) ISP: 6500s Alternator: 0.5 EC/s Deploy range: 90° (+10° single-axis gimbal, for a total authority range of 110°) Modelled after the Hawker Siddeley P.1127's engine nozzles (One of the experimental aircraft designs that eventually led to the Harrier Jump Jet) This engine is designed to be radially attached in pairs on the sides of an aircraft and can deploy for a full 90 degrees of freedom, plus 10 degrees of single-axis gimbal, giving it a large range of pitch control to alleviate the need for large numbers of reaction wheels to counteract torque. It can rotate its thrust vector downwards for vertical take offs and landings: And then, once off the ground, it can swivel its thrust vector around for horizontal flight: It can also be freely deployed to anywhere between the two angles to facilitate short take offs or other use cases people may think of. This engine fills a much needed niche in terms of VTOL jet aircraft, and would allow for so much more creativity in terms of plane design and functionality, as well as making it possible to build VTOL aircraft that are actually aerodynamic and aren't hard capped to the sound barrier (Whittle clusters suck). Balancing In terms of its stats, it needs to have a high amount of thrust for the obvious purpose of being a VTOL engine, and it also needs to be relatively light and not use too much intake air, that leaves its ISP as the main variable in terms of balancing this engine against other jet engines (Particularly the Panther, which it is rather close to in terms of thrust), I also didn't quite want to give it terrible ISP either as it may be used as the primary engines on certain aircraft designs. In the end, I decided that 6,500s of ISP feels like a nice middle ground, it's far more efficient than the three hypersonic jet engines (Afterburning Panther, Whiplash and Rapier), but simultaneously it's still well below the standard Panther and Wheelsley in terms of efficiency, ensuring that it does not replace either of them for general usage. Conclusion Generally (in my very totally unbiased opinion) as someone who's spent a rather unhealthy number of hours designing VTOL aircraft across both games, I believe this would be an amazing addition to the game that would open up so many new opportunities for aircraft design and construction, the specific stats I've laid out for for this engine are not solid "this is absolutely how it must be implemented" caps, but just represent how I personally feel it'd be best implemented should it become a real part in the game, I hope this post reaches the development team and they seriously consider implementing a part like this to fill this role.

Reported Version: v0.1.5 (latest) | Mods: Micro Engineer, Lazy Orbit | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB A somewhat minor issue, but for some reason panther engines while in afterburner mode are incredibly prone to being occluded, causing them to abruptly produce no thrust in spite of being functional with even the slightest amount of clipping. .ipsImage { width: 900px !important; }

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5500 | GPU: RTX 2060 | RAM: 40GB Pretty simple, the default ALT+X hotkey to reset your trim while in flight also cuts your engines due to the X button also being the cut engine button, this doesn't impact gameplay too badly since you can just immediately hit Z to bring your engines back online but it's still rather annoying to deal with.

Jaypeg ordered me to upvote this, so I shall

Another great update, good job!

Me leaving my game AFK for 8 hours straight

Great job to the entire dev team

Obviously members of the development team have said before they don't enjoy life support, and that's perfectly understandable, a lot of people don't enjoy the prospect of needing to deal with such extra constraints in a game that's already very heavy on resource management, but there's also a large potion of the community (Myself included) who enjoy the additional challenge offered by imposing life support requirements quite a lot, simultaneously of course forcing life support requirements on the side of the community that doesn't enjoy it would be tremendously bad in a large multitude of ways (As the development team has highlighted before). My suggestion is to take a sort of "best of both worlds" approach; adding simple single resource non-fatal life support mechanic and making it only enable with Hard mode, with the option to make it fatal not being enabled until Rocket Scientist difficulty. It being behind Hard mode means that newer players just starting the game won't immediately default to having life support requirements enabled, which prevents it from interfering with the game's initial learning curve while also giving users who wish for the extra challenge the option to enable it, furthermore making it non-fatal allows for it to factor into gameplay without being a significant source of frustration for players, at least until they feel ready to subject themselves to that experience with the Rocket Scientist difficulty. You may be asking; "But Mr. DibzNr, if the life support is non-fatal then what's the point of it?" That'd be an interesting problem, the original Snacks mod for KSP1 simply made Kerbals fall unconscious and thus lose vessel control when they ran out of food, I don't think the player's first experience managing life support resources should be so punishing through; instead my idea is that you could impose a number of smaller penalties like, for instance, tying it into the G-Force mechanics such that Kerbal's G-Force tolerances get scaled back the hungrier they are, you could also take a Minecraft approach and make it so that they can't sprint on EVA if they're out of food, incentivising the player to keep their Kerbals fed without imposing too tremendous of a penalty for failing to do so. Simplifying it all down to a singular resource (Instead of many interconnected resources) also helps to keep things simple overall, and also lets you implement a singular bold "Are my Kerbals suffering" bar that could go right alongside the other "Are my Kerbals suffering" bar, which aids in UI readability, and could also integrate well into colony mechanics. Much like most KSP1 life support mods, the rate at which Kerbals consume food could also be determined by a slider in the difficulty, with it being laxed on Hard difficulty to not make things too overwhelming overall, and then stepped up for the Rocket Scientist difficulty.