Anth

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.

Maybe. Its a shame that I couldn't have it via my PD account. I didn't specify steam at all. It's fine. I will just zip each update but steam definitely wasn't my intention.

KSP2 Version: 0.1.0.0.20892 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods used: None Note this Happens if it's Via a Maneuver Node of if There is no Maneuver Node. When a SOI is inside another (Bugged): Mun inside Kerbin (Craft is anywhere within Kerbin SOI) Minmus inside Kerbin (Craft is anywhere within Kerbin SOI) Tylo inside Jool (craft is anywhere within Jool SOI) Screenshot 1 Showing the Lack of Trajectory (Kerbin Orbit to Mun): When a SOI isn't inside another (Works Correctly): Mun and Minmus (Craft is within Mun SOI heading towards Minmus) Tylo and Jool (Craft is within Jools SOI heading towards Tylo) Screenshot 2 Showing Correct Trajectory (Mun Orbit to Minmus): Save Files From the Screenshots: https://www.dropbox.com/s/jawws84aovxokb4/Saves.zip?dl=0

[snip] You do know that some bugs take longer to fix/hunt down compared to other's right? Sometimes they can fix a bug easily. Sometimes they can make a temporary work around for a bug until they do a more involved fix. Some issues need a feature completely overhauled. I dont think it's not as simple as you think.

Back up non modded saves first is my recommendation. I am not 100% certain but I am pretty sure the amount of issues increased after I installing mods for KSP2.

Thanks for the update on what's happening Nate. I look forward to the first patch.