Thomot512

It would be really fun to have an in-game scripting tool such as the one of Juno new origins.

F12 is not working for me anymore. Neither ALT+F12, nor SHIFT + F12, CTRL+F12, or any combination of those. My steam screenshot is not F12.

I already made a post about this issue, but it went sideways, and for readability reason I'm making a new post. KSP Version v0.1.1.0 Operating System and version Arch Linux x86_64, Kernel 6.2.7-arch1-1 CPU and GPU models, any other system information which could be relevant AMD Ryzen 5 7600X, AMD ATI Radeon RX 7900 XTX Description of the bug. Expected Behavior In level flight, the 4 forces acting on an aircraft are the following: Lift, is a force acting perpendicular to the flight path or the airflow; Drag, is a force acting parallel to the airflow or the flight path; Gravity, or weight, is a force acting toward the center of the celestial body, and should in level flight be acting parallel and opposite to the lift; Thrust, is the force produced by the propulsion system . Those 4 force in level flight should be in equilibrium. Source: NASA In order to simplify the calculation thrust will be assumed to be parallel to the airflow and opposite to the drag. With this in mind, in order to achieve level flight, the drag must be the same intensity as the thrust, and the lift should be the same intensity as the weight. In this case equilibrium is achieved and we can fly without losing altitude or accelerating. Observed Behavior In order to achieve level flight, the airplane require much more lift than it's weight. This requirement appear to be link to the longitudinal static stability margin of the aircraft. Steps to Replicate Use this aircraft. (I don't know how to upload save file so I copied the whole .json file in the following spoiler). Moving the main wing front and back should allow to change the longitudinal static stability margin by moving the relative position of the center of pressure in function of the center of mass. The design below has been chosen to simlify any calculation. The wing, horizontal tail, and vertical tail are square. The propulsion is aproximatly inline with the center of mass. Flying and trimming the aircraft while monitoring the aeroGUI should allow you to observe the same issue. Fixes / Workarounds (if known..) None. A list of ALL mods. If the list is long, please consider using a spoiler window. None. Other Notes / Screenshots / Log Files (if possible..) The test below show the effect described above. The airplane is flown and trimmed until it reach quasi level flight (easier said than done). This has been done for two postition of the wing, changing it's longitudinal static stability margin. Them the lift was recorded. The measurement was repeated at 4 second interval to assess the quality of the level flight. Wing position 1: Wing Position 2: Measurement: Wing position 1: Higher longitudinal static stability margin; Dry mass: 3.34t; Total mass: 3.98t; Mass: 3.78t; Weight: 37.069kN; avg Lift: 59.91kN; Ground speed: 179 m/s; Load factor: 1.62. Wing position 2: Lower longitudinal static stability margin; Dry mass: 3.35t; Total mass: 3.99t; Mass: 3.80t; Weight: 37.265kN; avg Lift: 50.93kN; Ground speed: 185 m/s; Load factor: 1.36. It is important to note that the load factor in level flight is supposed to be 1.0. It is also interresting to note that the thrust is higher than the drag. And if we look at Wing Position 2 the mach number slightly drop while the drag is lower than the thrust. It is also part of the problem. I'm unable to assess if this is an aeroGUI bug or an aerodynamic model issue. But issue there is. Thanks to @Buzz313th , who helped me understand that the issue might be linked to longitudinal stability. (Maybe) Linked issue:

I flew the design used in my post of the February 28th and re-flew it. Same issue as before. Then I remade the same (as much as possible) design, and there problem disappeared. No idea what is going on. But the problem seems to be solved for new design. Good enough for me will mark the issue as solved.

@Buzz313th Disregard that post. I forgot that my thrust was vector was below the CoG and therefore producing a pitch up moment which changed my trim setting and therefor my angle of attack. This lead to the reduction in Lift. I'm therefore unable to reproduce the bug observed in the first version of the Early access. Following your answer on an other post, I decided to do an other test. I was not able to reproduce the bug where the lift needed for level flight was completely off, as observed in my post of February 28th. It might have been a bug of the aero GUI that is not present in the new version of KSP2. Now the announced lift correspond to the actual flight condition. But I still have the bug where cutting the engine change dramatically the lift produce without the airspeed changing. The aircraft design is the following: Almost neutrally stable; No thrust vectoring; mass: 16.42T, Fg = 161.02kN The issue that can be observed in the pictures above is the following: The airplane is trimmed for level flight and produce the expected ~160kN of Lift at an airspeed of 258 m/s when the engines are running; The airplane still with the same trim setting does only produce ~66kN of Lift at an airspeed of 255 m/s when the engines are cut off. Expected behavior: Lift is linked to the airspeed, mach number, reynolds number, density, geometry, and angle of attack, but not to thrust. Observed behavior: Lift is linked to thrust!

It seems I did not explain the problem clearly. I'm not speaking about pitch authority of a specific design. I'm merely observing that for a given airplane with a given mass, it appear that the amount of lift needed to maintain level flight (load factor of 1) varies in function of the mach number. This is not something that has any logical explanation. Indeed in order to be in a maneuver with a load factor of 1, typically level flight, the lift force must be equal to the G-Force. In the measured case in order to maintain level flight the lift needed to be around twice the weight. I'm aware that an airplane can be too stable when CoP is too far aft of the CoM, and that in those case it is difficult to steer the airplane, but if the lift is higher than the weight it should still enter a maneuver corresponding to the load factor. Edit: typo corrected.

Nope see:

In order to investigate further the aerodynamic model of the game I designed a simple plane with detachable rectangular wings in order to investigate the effect of aspect ratio on the aerodynamic drag. Here's the design: I created the first design with a relatively high aspect ratio expecting a lower drag from this design. In trimmed level flight at around 130 m/s 550 m above sea level, I got the following results: Right after separation I got those results: Then I changed the aspect ratio for something ridiculously small expecting a steep increase in drag. For very similar speed and altitude I got: And after separation: As can be seen once the drag of the body is removed from the total drag, the drag of the wing can be read, and in both cases it is ~2.1 [kN], This proves that the aspect ratio does not have any effect on drag, or on L/D ratio. Which is quite sad in a game such as this one. It is such a fundamental of aerodynamic that I would classify that as a bug.

Interesting discovery. Note also that at lower Mach number, your planes appear to need more Lift in order to fly in level flight.

Computer Informations -` thomot512@amdBuild .o+` ------------------ `ooo/ OS: Arch Linux x86_64 `+oooo: Kernel: 6.2.1-arch1-1 `+oooooo: Uptime: 1 hour, 40 mins -+oooooo+: Packages: 987 (pacman) `/:-:++oooo+: Shell: zsh 5.9 `/++++/+++++++: Resolution: 5120x1440 `/++++++++++++++: DE: Plasma 5.27.2 `/+++ooooooooooooo/` WM: kwin ./ooosssso++osssssso+` Theme: [Plasma], Adwaita [GTK3] .oossssso-````/ossssss+` Icons: [Plasma], Adwaita [GTK3] -osssssso. :ssssssso. Terminal: konsole :osssssss/ osssso+++. CPU: AMD Ryzen 5 7600X (12) @ 4.700GHz /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT/7900 XTX `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 6c:00.0 Raphael `+sso+:-` `.-/+oso: Memory: 6631MiB / 31232MiB `++:. `-/+/ .` `/ Description of the bug. Expected Behavior The water and the atmosphere would be displayed. Observed Behavior The water and the atmosphere is not rendered. Steps to Replicate Unknown. Fixes / Workarounds (if known..) Controlling a craft in orbit of Duna and going back to the KSC seems to fix the issue. A list of ALL mods. If the list is long, please consider using a spoiler window. None Other Notes / Screenshots / Log Files (if possible..)

I ran a few other test. I wanted to trim an airplane into level flight and look at the its weight and lift. Here is the airplane used: It's total mass is 12720 [kg]. It's weight is therefore 9.80665 [m/s^2] * 12720 [kg] = 124746 [N]. If we assume that the angle of attack needed for a level flight in trim condition will be small, and therefore the component of the thrust adding to the lift is negligible, we can assume that the weight must be compensated by a lift force of equal intensity. Therefore the expected lift force in level flight must be 124746 [N]. During flight, the airplane was trimmed at three different altitude and speed. The three condition represent three different flight condition at different Mach number and air density: Air density [kg/m^3] Mach number [] Lift [N] 1.131 0.502 274582 0.615 2.852 113105 1.172 0.269 275441 What can be observed is that below the speed of sound the airplane needs roughly 2.2 times the expected lift in order to achieve level flight. Yet at supersonic speed this requirement drop below 0.9 times the expected lift. This behavior cannot be considered otherwise as a bug. If I had to guess I would say that the aerodynamic forces displayed in the AeroGUI represent roughly what should be expected for this airplane in those condition, including the huge increase of drag at supersonic speed. But those forces are not well linked with the mechanics of the airplane. It behave in a really weird fashion.

Today I wanted to try aerodynamics. I ran into a lots of issue. The first one is that the shape of the airplane does not seem to influence the ability of the airplane to break the sound barrier. As can be seen from the image below the airplane fly in low atmosphere at Mach 2.6, without any shape optimization. Either the aerodynamics does not simulate the shock wave drag and its relation with area rules or the thrust of this motor is way too high! Second issue I had is about trimming. As can be observed in the screenshot below, the airplane is gliding at around 250 m/s, with all control surface at 30° deflection to increase lift and pitching moment. It is generating around 170kN of lift force and weight about 40kN. Even with a lift that is enough to fly a 4G maneuver, the airplane can almost not pitch up. When the engine is running it is perfectly trimmed at those speed but without engine it is flying like a stone. All of the above is extremely counter intuitive and seem very unrealistic. I suppose some more work is urgently needed in the aerodynamic simulation section.

In my case changing the flight controls, in-game or in json file has no effect on the flight controls.

I notice during my first Mun orbit, and then noticed that it happens a bit all the time, even in the atmosphere and under Kerbol light. (Sorry for the low quality gif, I'm a noob at videos) System: -` thomot512@amdBuild .o+` ------------------ `ooo/ OS: Arch Linux x86_64 `+oooo: Kernel: 6.1.12-arch1-1 `+oooooo: Uptime: 3 hours, 8 mins -+oooooo+: Packages: 987 (pacman) `/:-:++oooo+: Shell: zsh 5.9 `/++++/+++++++: Resolution: 5120x1440 `/++++++++++++++: DE: Plasma 5.27.1 `/+++ooooooooooooo/` WM: kwin ./ooosssso++osssssso+` Theme: [Plasma], Adwaita [GTK3] .oossssso-````/ossssss+` Icons: [Plasma], Adwaita [GTK3] -osssssso. :ssssssso. Terminal: konsole :osssssss/ osssso+++. CPU: AMD Ryzen 5 7600X (12) @ 4.700GHz /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT/7900 XTX `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 6c:00.0 Raphael `+sso+:-` `.-/+oso: Memory: 7651MiB / 31234MiB `++:. `-/+/ .` `/

I also noticed the issue with the control in launch a test rocket. I think that experienced player tend to input too little control. I is expected that you completely over-steer the rocket. If you do that, the tutorial continues as expected. (took me a while to figure it out)

Similar issues also with AMD video card. I also had some weird light flickering when on the dark side of Mun. When I tried to take a screenshot it did not appear. Probably they are not present on every frame. I'm going to try again.

I only tried with proton-ge 7.49 and it worked. I'm always using the following commands though: mangohud RADV_PERFTEST=aco DXVK_ASYNC=1 gamemoderun %command% Later I changed the launched option for the following in order to remove the PD Launcher: eval $( echo "mangohud RADV_PERFTEST=aco DXVK_ASYNC=1 gamemoderun %command%" | sed "s/PDLauncher\/LauncherPatcher.exe'.*/KSP2_x64.exe'/" ) Worked as well. Specs.: -` thomot512@amdBuild .o+` ------------------ `ooo/ OS: Arch Linux x86_64 `+oooo: Kernel: 6.1.12-arch1-1 `+oooooo: Uptime: 9 hours, 9 mins -+oooooo+: Packages: 959 (pacman) `/:-:++oooo+: Shell: zsh 5.9 `/++++/+++++++: Resolution: 5120x1440 `/++++++++++++++: DE: Plasma 5.27.1 `/+++ooooooooooooo/` WM: kwin ./ooosssso++osssssso+` Theme: [Plasma], Adwaita [GTK3] .oossssso-````/ossssss+` Icons: [Plasma], Adwaita [GTK3] -osssssso. :ssssssso. Terminal: konsole :osssssss/ osssso+++. CPU: AMD Ryzen 5 7600X (12) @ 4.700GHz /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT/7900 XTX `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 6c:00.0 Raphael `+sso+:-` `.-/+oso: Memory: 8286MiB / 31234MiB `++:. `-/+/ .` `/ I'm using a Wayland session.

We can also add that the chutes are superposed, which is something I was hoping KSP 2 would not do.

In my case some bindings works, some don't. For example the key 'e' cannot be bound from the game settings but needs to be bound through the "InputBindings.json" file. When any key, including the 'e' key is rebound to action in the VAB, it works fine, but no change made to the flight control have any effect in game.

@FleshJeb & @OhioBob Thanks a lot. This will help a lot!

In order to have some fun I wanted to write a small script that would help me optimize both the launch vehicule and the gravity turn. To acheive that I need to have accurate data concerning the atmosphere. In the wiki we can find the equation describing the change in pressure in function of the altitude. But I was not able to find anything similar for the temperature. It is also mentionned that both variable change with time of day and latitude. But the equation describing those change are nowhere to be found. Can someone help me?

This is also what I'm hoping for.

What about Linux?

@Geonovast I tried it in a live environment of Mint and got the exact same issue that I could solve in the exact same way.

I just received a last mail from them advising me to use the following command: dos2unix -f *.sh This finally worked. I really had to insist in order to get them (three different person) to admit that the issue is probably not the fact that I'm using an Arch based install. To summarize, if you need to install an old KSP version from GoG, write to the support, and, if needed, use the command on top of this post. This is due to the fact that the file might be uploaded from a windows machine which can cause some incompatibility issue. (I'm no specialist so if someone is willing to explain it in more detail, he/she is more than welcome)