Anth

I wonder if such a big change to CBT might mean a change from Directx 11 to Directx 12 as well.

It might be that they wanted to get something they knew that worked from KSP1 so they could get development in all areas up and running. Verses waiting for CBT to be developed before any other development areas could be started.

So this is going to replace PQS+ before 1.0 of KSP2? I am glad that KSP2 is still at a point that this kind of thing can be considered.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: Lazy Orbits to get into Eve orbit then removed mod afterwards otherwise it wastes a lot of time travelling all the way to Eve to test again and again. There are two ways this happens. 1. A craft under stress because a rocket engine is firing and then time warp is used. 2. When a craft has the force of gravity being applied to it on a planetary body and then time warp is used. Below shows the accumulative effects of this happening to crafts in a short amount of time. 1. Firing Rocket Engines: Video Evidence (Orbit): https://youtu.be/BdnfoC2xoeU Save File for Orbital Test: https://www.dropbox.com/s/8jzafc5qbg4jiss/Orbital%20Test%20Save.zip?dl=0 How to Reproduce Using the Save File Supplied: 1. Activate the engines to full throttle 2. Turn on Time Warp and get it to as full Time Warp as the game will allow 3. Spam Time Warp keeping it engaged even though KSP2 will keep dropping it. 4. Get just the right timing and it will do as it did in the video. 2. Using Gravity: Video Evidence (On the Surface of Eve): https://youtu.be/eDZ27loKCe8 Save File for Planetary Test: https://www.dropbox.com/s/53euqrv2xsirzqg/Planetary%20Test%20Save.zip?dl=0 How to Reproduce Using the Save file Supplied: 1. Turn on Time Warp 2. Turn off time warp 3. Wait until the flexible parts have dropped down towards the ground 4. Turn on Time Warp (watch the timing for full time warp to be available not physics warp. It has to freeze the parts.) 5. Keep using Step 2 to Step 4 until it looks like the video or worse To Clarify: This bug report is about: Time warp saving stressed parts coordinates into memory. The other bug report (one below) is about: The game saving stressed parts coordinates into the save file. More Information: As I said in the other bug report, KSP1 (excluding robotics) saves the crafts original parts coordinates (VAB/SPH/Editor) into the save file so they can never change or be influenced. (well other than docking) That avoids these issues unless the developers want to record the original parts coordinates and their stressed ones so they can bend back to their original positions when the force is withdrawn, but that would make for huge game save files right?

The bug tracker for KSP1 was established by Squad before Take Two took over. It's a little different from starting all over again with a new company and a new game.

Done over 200 bug reports for KSP1, Involved myself in other peoples bug reports on the bug tracker to reproduce their bugs etc. Reported 18 Bug reports for KSP2 so far Contributed on the KSP forums from time to time. Helped quite a few people on the reddit ksp discord with their problems playing KSP1. Bought KSP1 twice, steam and GOG, bought both DLCs once on steam, Got KSP as a bundle. Gave that away to someone on one of the discords I belong to. Claimed a free copy of KSP via Epic recently. That's enough I would say.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None How KSP1 Works Without Robotics Which Keeps Parts Permanently In Their Original Positions: Whenever KSP1 saves: Only the original part positions from the VAB/SPH are saved Whenever a craft leaves physics/render range: KSP1 when leaving physics range will snap all parts to their original positions. Then when it moves out of render range those coordinates are held in memory for when the game saves. How KSP2 Works: Whenever KSP2 saves: The current real time part positions are saved which are different to the original parts positions due to the stress on the parts by gravity or by other means. Whenever a craft leaves physics/render range: I flew in a plane until the KSC disappeared and then flew back a few times. There is some form of drift but it's not exactly like the game saving and loading. Video Evidence of Drift Over Multiple Saves or Visits to a Craft: The following video shows the worse of this situation. Drift over multiple saves or visits to the craft. Its accumulative. (5 Quicksaves+ 5 Quickloads) I have timestamped it so the loading screens can be skipped to save time. End of video I undocked the weight and the craft stayed bent which doesn't happen if it's undocked on launching it for the first time. https://youtu.be/yYUN4lqQZsE Screenshots of Extreme Drift after 1 or 2 Quicksaves and Quickloads: What it's like in the VAB: And this is after 1 or 2 QuickSaves and QuickLoads. This is permanent. Obviously I used a heavy weight to force the issue: Craft Files from Video and Screenshot: https://www.dropbox.com/s/bdlg15vpdn5hg3r/KSP2%20Drift%20Testers.zip?dl=0 Conclusion: Drift via Gravity: If the player wants to reuse crafts again and again the parts will drift over time until they looked warped or are entirely useless Because the main drift is caused by gravity imagine what a craft on Eve will end up looking like. Drift via Wobbling Parts: If a rocket is wobbling or flexing while in space and the player or the game saves, the rocket will now stay permanently in a flexed state on reloading. Additional Information: For further information I recommend talking to @JPLRepo (Jamie Leighton) who is one of the developers for KSP2. KSP1's 1.12.3 which fixed docking port drift (introduced in 1.12.0) and added a way to counter drift to some degree when locking was his work.

I am using a mod called maneuver node controller. It does the same thing. Hope that helps narrow that down.

I would more describe it as the KSC menu screen maybe rather than menu screens. KSC causes high CPU usage. Not sure about GPU usage. This is my bug report relating to it:

Yeah true.

Ahh. I first saw it in the Balsa game. And the fairing system in KSP2 kind of points to the same idea but on a really small level. Hopefully they got the message because the gizmo system would make things way easier.

Yes .Alt Period would force Physwarp in KSP1. I would like that back. As for this bug report I want the craft to be able to follow the retrograde marker down to the ground from whenever KSP2 forces me to 4x timewarp which timewarp can't do. Physics warp works from the moment the player hits an atmosphere. Thats why I think it's a bug the way its behaving for a planet without an atmosphere.

@Vl3d Hey. Your picture is way better than my attempt. Someone just linked me your post.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None The Problem From My Perspective: The current system is functional but its a little hard to get the right shape with just a menu with sliders and numbers. A Possible Solution: Keep the current system for fine tuning but also have something similar to the fairing system (in KSP2) using a gizmo dedicated to the manipulation of the wings Screenshot of what I propose (loosely) using MS Paint to manipulate a wing in KSP2 with arrows: Important Additional Information: If you want to see how it's being done in a game already then look at the former lead developer for KSP1's Felipe Falanghe's game currently under development called Balsa Model Flight Sim. It shows exactly what I mean. (Spoiler Alert! It's not my idea!)

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Expected Behavior: Whenever KSP determines that x4 time warp is necessary it should be physics warp just like a planet with an atmosphere. Observed Behavior: First it's in standard unlocked timewarp When it gets closer to the ground but still a fair way up it will drop to 4x Timewarp (non responsive to controls) When it gets much closer to the ground it will change to physics warp (4x) From the ground: Its physics warp from the ground up to a certain altitude and then It changes to time warp but maintains a lock at 4x Until it gets high enough and locks to full timewarp Video Evidence: This shows what happens from the ground on the Mun. https://youtu.be/MVMaa7iuK2s First it starts with the 4x physics warp and becomes unresponsive (changes to timewarp) at 3300m (sealevel) maintaining 4x Conclusion: I definitely would have expected this to be physics warp all the way up to timewarp being fully unlocked but its not.

When in full orbit with no risk of crashing into the ground we should be able to go to full timewarp. I need to be able to go to full timewarp to get to a transfer window between planets. I cant do that with 100x Timewarp.

Reason why it happens is because KSP2 doesn't think the craft is landed. It can be seen via map mode that the craft thinks it's going to collide with the ground. Here's a save file to help out for testing lovely devs watching. In the case of this the Craft is on one of the globes of the same scene as the video. https://www.dropbox.com/s/h8b831ye0vit5ti/Save Files.zip?dl=0

Look to the following link but remember some parts are new or being renamed so Cubic Octagonal Strut is now called a Micro I think for example. So parts similar to that size will also most likely be physicless. https://wiki.kerbalspaceprogram.com/wiki/Physicsless_part

Once they go into that state they become non responsive with no ability to save themselves. I just find that frustrating.

Agreed.

I know. The only reason I made the video was for the bug report where I suggested some animations. It's obviously not normal. But the coding that took to do it so well is what is amazing. It tries to deceive my mind into thinking that's natural when it obviously isn't. My bug report suggests staggering, falling over, falling over and sliding, couch and slide like a super hero. I don't like the ragdolling in KSP1. So I think an in between situation would be better. A compromise if you will between realistic physics and avoiding what KSP1 did badly.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Video Evidence: Kerbal will contact the surface at 43.1m/s horizonal speed without momentum affecting it and ends up just standing. https://youtu.be/P756NwqFSCo First Compliments to the Developers: I love what has been done here. It's amazing. So smooth and it seems almost natural to be able to travel horizonally and hit the ground at 43.1m/s and just be standing at the end of it. (a bit below 60m/s is actually the top speed) Truly its surprising how well this works. Suggestions for Animations to make it "seem" a little more realistic: If slow enough the Kerbal just staggers. If a bit faster the Kerbal falls onto its face and then gets back up and then dusts themselves off. If a lot faster than that the Kerbal falls over onto its face and travels a small distance before stopping and then gets up and dusts themselves off. Also there could be on rare occasions that the Kerbal actually does a sort of crouch and do a slide to a heroic stop like the movies (or nearly makes it) Additional Information: The rag dolling in KSP1 wasn't really that enjoyable so let's not go back there please

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Video Evidence: First look to see that I activate the engines. Then I stop after 2 seconds into the burn and the timer still keeps counting down. https://youtu.be/3h5p-kF6N9c Possible Expected Behavior: This is more complicated because what if the player only drops the throttle to 50% or 80% because once that happens the timer is inaccurate. Alternative possibility: A way around it might be that the timer just stops and turns to another colour indicating an error on the part of the player? Additional Information: This wouldn't matter very much if it was the same as KSP1 where dV is a much more important indicator of how a maneuver is progressing which I made another bug report for:

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None The following explanation is to show why the required dV actually should be counting down on the Burn Timer. An experienced Kerbal player (well...me at least) does the following for executing a maneuver node burn typically (KSP1): They start the burn at 100% throttle at the appropriate time. They are watching the required dV reducing as the fuel gets used up. Towards the end of the burn they drop the throttle for finer control. They watch the dV display until it hits exactly zero but are also watching the actual maneuver to see if it matches the predicted one. Video Evidence using KSP1: This follows the above 4 steps. https://youtu.be/9DLHwIUxFP8 Video Evidence using KSP2: This is less precise than KSP1 primarily because the deltav isn't reducing like KSP1. https://youtu.be/aJxAZ9nnexc Additional Information: In the case of a maneuver node execution 1 second is a very long time. Recommended actions: Have the dV display reduce as the burn progresses as its being used up like how KSP1 does it. If dV passes below 0 show negative numbers to show how far to recover using RCS etc. Have the dV display on the burn timer a little bigger and reduce the size of the time remaining.

Im sure everyone does. Good thing is that it's not intended to be missing the trajectory. It's just missing due to a bug of some sort.