Bug Status [7/28]

[schlosrat]

9 hours ago, Turbo Ben said:

I'm playing KSP 1 as I write this, and can confirm that KSP 1 moves all subsequent nodes keeping them at the same time. I'm not saying you can't do it that way, or even that it's a worse option, I'm just saying that there is an element of guess work going on and that may be a reason it's intentional with KSP 2. KSP 1 is probably a better way of doing it, as it works fine for minor corrections, which is normally the case. Either way, I usually check all nodes after a change.

In KSP2 if you create nodes in order from earliest to latest, then adjusting the earliest node moves the later nodes - just like in KSP1. In fact, the game tracks this with a couple of properties on the node. The first is the boolean IsOnManevuerTrajectory. This is set to false for the first node, and true for subsequent nodes which have been placed on patched conic maneuver trajectories. In addition to this, there is also the property ManeuverTrajectoryPatch. This is set to null for the first node (or any node which is not on a maneuver trajectory) and to the correct patched conic patch associated with the time of the node. Patches run from a start time to an end time, so if Patch 0 starts at x and ends at y, and Node 1 (the second node) is at a time between x and y, then any change to Node 0 (which has a burn time that ends at time x) will result in Node 1 moving so the node control gizmo is at the right place based on its node time and the shape of Patch 0.

What happens when you create nodes out of order is most definitely not intended, as what's going on is that you've created a node at some time y, and since there were no prior nodes at the time you made that one, its IsOnManevuerTrajectory = false and its ManeuverTrajectoryPatch = null. You then create another node at time x (which is < y), so that node also (correctly) has IsOnManevuerTrajectory = false and ManeuverTrajectoryPatch = null, but the previous node is not updated to have its IsOnManevuerTrajectory = true and its ManeuverTrajectoryPatch = the patch from the new earlier node.

This is a bug, as this could never be the intended behavior unless we assume devs are devious and want to confuse players (which is patently false). We can see what the intended behavior should be by creating nodes in order. There is no use case where the player would want the later node to *not* follow the patch of the earlier node as that just means there's a node for that vessel that can never be reached - so they would need to delete that one and recreate it. Thus, this a bug. It would be nice if the game were smart enough to handle nodes created out of order as players tend to be humans, humans do silly things like this, and the game will let you create nodes out of order, so why not handle it gracefully?

Edited August 3, 2023 by schlosrat

[schlosrat]

9 hours ago, cocoscacao said:

Never thought about this... What happens if you change it so much that your trajectory crashes somewhere, making subsequent nodes nonexistent?

That's a great question! it turns out that what it does is... nothing.

By that I mean it doesn't delete the node, and presumably doesn't change any of it's properties - it leaves the old node hanging in space, but not necessarily where you might think it should be.

Suppose you;'ve got a node that would take you from Kerbin to Mun and you've fiddled with it so that it's just grazing Mun on one side. As you go from a near miss to a collision, the post-Mun node jumps to an odd location that may be some distance from where it was pre-collision. Moreover, as you keep fiddling with the lithobreaking trajectory the "post-Mun" node keeps moving around! There's a discontinuous jump from where it was right before your trajectory intercepted the Mun to where it is (hanging in space), and then it moves smoothly while you keep adjusting, and then another discontinuous jump once you've adjusted the earlier node so much that you're just grazing the Mun on the other side and no longer on a collision course.

[Turbo Ben]

1 hour ago, schlosrat said:

In KSP2 if you create nodes in order from earliest to latest, then adjusting the earliest node moves the later nodes - just like in KSP1. In fact, the game tracks this with a couple of properties on the node. The first is the boolean IsOnManevuerTrajectory. This is set to false for the first node, and true for subsequent nodes which have been placed on patched conic maneuver trajectories. In addition to this, there is also the property ManeuverTrajectoryPatch. This is set to null for the first node (or any node which is not on a maneuver trajectory) and to the correct patched conic patch associated with the time of the node. Patches run from a start time to an end time, so if Patch 0 starts at x and ends at y, and Node 1 (the second node) is at a time between x and y, then any change to Node 0 (which has a burn time that ends at time x) will result in Node 1 moving so the node control gizmo is at the right place based on its node time and the shape of Patch 0.

I stand corrected. Thanks for the insight.

[herbal space program]

I think I mentioned this before, but I determined on my lengthy Jool 5 mission that bugs #2, 3, and 13 all appear to be related. That is, whenever a ship starts to show signs of orbital decay, you can count on it to also have problems when docking/undocking, and moreover to exhibit various phantom motions, sometimes violent, whenever you exit timewarp inside of the decay-inducing altitude for a particular body. For that reason, I suspect that definitively fixing any of these bugs will actually fix all of them.

Edited August 4, 2023 by herbal space program

[whatsEJstandfor]

On 8/3/2023 at 10:00 AM, Chilkoot said:

My biggest gripe since day one has been planet-side performance, and it's essentially still the same (i.e. really bad) as it was in the first EA release.

I don't want to sound pollyanna but this is just not true, at least according to the data gathered from the ksp2_technical Discord channel, and my own experience. It went from very bad in 0.1.0.0 to very acceptable by 0.1.3.0, even on midrange GPUs. What GPU are you using, out of curiosity?

[RickJM694]

@Intercept Games can we get another….well anything? It’s been radio silence for over a week now. And the current state of the game is….frustrating at best. 

Edited August 7, 2023 by RickJM694

[The Aziz]

Oh no  the week

How are people going to survive this

[kicka55]

On 8/2/2023 at 8:59 PM, Nicrose said:

Personally not a big fan of this idea, I feel like for a video game predictability is key and this seems to make it way more complex than it needs to be. I can’t imagine launching over and over and increasing the “thickness” by one every time for every node to find the optimal weight and strength for each tank, and then having to redo it with every other size every rocket. 

It could be an automated solution with the option to do it manually. The more mass you stack on top of a tank the more sturdy the lower ones get. Maybe also take TWR of the engines into account. And of course with too little sturdiness on the tanks they would not just wobble but rupture at some point. Give each tank a property of pressure and a property of sturdiness. Modders could then even add more realism by making sturdiness a function of temperature etc. And you could be min-maxing by reducing the stock sturdiness. 

And in order to not lose compareability to other player rockets it of course needed visual ques like visible structural supports on the outside. That would probably be the biggest challenge. How to implement it in a funny way that it fits into KSP while still being somewhat realistic. Just thicker tank walls are hard to visualize on screenshots.

Edited August 8, 2023 by kicka55

[Royalswissarmyknife]

On 8/7/2023 at 2:03 AM, The Aziz said:

Oh no  the week

How are people going to survive this

The Tragedy!

I think I might just die from consuming too much Aerozine 50 AND no Ksp-2 Dev Update!!!!

[Vanamonde]

Okay, please ease off on the sarcasm. 

[Vanamonde]

And stick to the subject, please. 

[gluckez]

I'm glad I found this somewhere in another thread. I had no idea what the current status was, or when an update would be available. I'm a software dev myself, so I understand that these things take time, but is it possible to make these bug status reports more visible? keep up the great work!