KSP2 - Bug solutions from a game developer's view

[EverydayKerbonaut]

So there is bugs, yea we expected some.
but looking at the most common bugs raises concerns that they need to go "back to formula"
see what outers think is simply a annoyance bug points to much larger issues. and there are a few "gotcha's" 

First off is simply user interface, how key and button input is handled. but also how it is processed.
an example is when writing a ship's name, M key takes you to a map view.
 this shows inputs are global instead of mode specific and/or the mode swapping is not handled properly.

then there is the lack of response from interface when crafts of extreme loads are being launched, lets say you get time to pass once every 10 seconds, pressing esc you wait up to 10 seconds to see map.
this is first a ticking issue, shows the menu is not calculated independently and have to wait for the world render cycle to complete before it is acted upon. the menu us a slave function to rendering. this should not be so.

next there is time itself.
time should pass once every second, no lag or load should reduce that.
any function should be a slave of time and use "time passed since last action" as part of its calculations. instead of relying on each action's output to calculate the next, formula's should allow passing of any amount of time and be able to adapt to those.
an example is rotating to a position over time, instead of needing to take action at every passing unit of time, a simple formula can be used to see how far it would be towards its goal giving this amount of time passed.
so if a craft would need 8 seconds to rotate from prograde to retro, and you are on 10x speed, then simply assume that in the passing of 10 seconds it made the rotation and set it as such, and deduct the propellant it would have used for that. simple
this will fix rotation and acceleration not  functioning over time warp of any kind.

then as for physics, this should be simplified where you can pre-calculate it
take the assembled craft in its current state, then do a linetrace from it from every direction, get the relevant angle of the hit and assign a value to it. do an additive overlay for control surfaces and other moving parts.
now simplify it into center of drag, and center of mass
use this along with speed to calculate everything else needed, bit you now get to treat it as a single part and not 100's of parts, and only needs to recalculate if the assembly changes.
you can further pre-calculate each part and in the final calculation use those as an is visible basis.
 you're welcome.

the current setup looks to prioritize visual
priority of execution should be:
1 - time
2 - interface input and response
3 - control input and response
4 - vehicle movement
5 - actual rendering, here going LOD or even complete basic Low poly will be acceptable as long as time keeps passing, input responding and actions happening reliably. 

next assembly
again looks like rendering is prioritized. it looks like everything is as movable and lighting is dynamic, this is wrong and even bad for performance.
treat every placed object as static, use directional light and pre-bake light as much as possible, then calculate dynamic shadows for the single combined model.
also VAB should have better uniform lighting with less shadows, it's a rocket factory after all so can assume its getting at least 4x light from each side and from on top, this makes baking light easier.
as for placement sockets, sure snapping to anything is a function now, but how about if we mid-mouse-button select something to then prioritize snapping to the object that we are focusing our view on?
also you dont have to make an entire assembly as moveable to attach it, simply rendering a 2d version of it for the current view and using a depth offset, use that as a card for the moveable part, and hide the static once you render the card, then you dont even need movables.
there is also collision issues with many parts, the simple solution is to do a visual interrace and get tangent at location, use that instead of collision, so a surface mount item will mount to the visual outer surface.

these are just a few bug fixes and performance booster i would have looked at.
again this is speculative and only the opinion of a play test, and I have no actual knowledge of how the code actually functions

[Sea_Kerman]

So you're saying don't simulate the internal forces of a vehicle? I think yous hould have to design your craft to be structurally sufficient, it's a big concern in vehicle design, especially the big long interstellar craft built around a central truss.

[Nuke]

i can make a case for long patch cycle times. i have a harder time making a case for a weekly patch cycle. id have hoped a quick and dirty initial patch was in the cards, but that was only wishful thinking. 

Edited March 9, 2023 by Nuke

[Profugo Barbatus]

This reads like you've only ever made static environment, limited interaction games at best, and have no idea what your talking about at worse. What you've written reads to me as "Just abstract away every interacting element of the simulation in pursuit of a stable physics delta" which can be translated for the less development inclined as "Just use the KSP Physics model from 2013 and drop all the new simulation details". It defeats the purpose of a freeform sandbox simulation of rocket building and flight. Not to mention half the abstractions via assumption you propose break fundamentally under anything more complex than single resource sink perfect scenario operations. And if it were as simple as "if 15 seconds passed irl and lag means you only finished 8 seconds worth of processing, just simulate the other 7 but faster" is like telling someone to charge their phone by turning up the brightness - you can't fix an execution speed problem by enforcing that the execution happen on time without just abandoning a processing cycle halfway through every time it goes under load - which would ensure complete collapse of the physics simulation at that point as you just have to ignore impulses or time travel. Reducing the physics delta is what they already do, and its the only viable option.

Pretty much the only thing I nodded along to with a "Yea" was the rename/map issue where someone just forgot to set a flag somewhere in their UI toolkit or input mappings. 

[Fullmetal Analyst]

9 hours ago, EverydayKerbonaut said:

So there is bugs, yea we expected some.
but looking at the most common bugs raises concerns that they need to go "back to formula"
see what outers think is simply a annoyance bug points to much larger issues. and there are a few "gotcha's" 

First off is simply user interface, how key and button input is handled. but also how it is processed.
an example is when writing a ship's name, M key takes you to a map view.
 this shows inputs are global instead of mode specific and/or the mode swapping is not handled properly.

then there is the lack of response from interface when crafts of extreme loads are being launched, lets say you get time to pass once every 10 seconds, pressing esc you wait up to 10 seconds to see map.
this is first a ticking issue, shows the menu is not calculated independently and have to wait for the world render cycle to complete before it is acted upon. the menu us a slave function to rendering. this should not be so.

next there is time itself.
time should pass once every second, no lag or load should reduce that.
any function should be a slave of time and use "time passed since last action" as part of its calculations. instead of relying on each action's output to calculate the next, formula's should allow passing of any amount of time and be able to adapt to those.
an example is rotating to a position over time, instead of needing to take action at every passing unit of time, a simple formula can be used to see how far it would be towards its goal giving this amount of time passed.
so if a craft would need 8 seconds to rotate from prograde to retro, and you are on 10x speed, then simply assume that in the passing of 10 seconds it made the rotation and set it as such, and deduct the propellant it would have used for that. simple
this will fix rotation and acceleration not  functioning over time warp of any kind.

then as for physics, this should be simplified where you can pre-calculate it
take the assembled craft in its current state, then do a linetrace from it from every direction, get the relevant angle of the hit and assign a value to it. do an additive overlay for control surfaces and other moving parts.
now simplify it into center of drag, and center of mass
use this along with speed to calculate everything else needed, bit you now get to treat it as a single part and not 100's of parts, and only needs to recalculate if the assembly changes.
you can further pre-calculate each part and in the final calculation use those as an is visible basis.
 you're welcome.

the current setup looks to prioritize visual
priority of execution should be:
1 - time
2 - interface input and response
3 - control input and response
4 - vehicle movement
5 - actual rendering, here going LOD or even complete basic Low poly will be acceptable as long as time keeps passing, input responding and actions happening reliably. 

next assembly
again looks like rendering is prioritized. it looks like everything is as movable and lighting is dynamic, this is wrong and even bad for performance.
treat every placed object as static, use directional light and pre-bake light as much as possible, then calculate dynamic shadows for the single combined model.
also VAB should have better uniform lighting with less shadows, it's a rocket factory after all so can assume its getting at least 4x light from each side and from on top, this makes baking light easier.
as for placement sockets, sure snapping to anything is a function now, but how about if we mid-mouse-button select something to then prioritize snapping to the object that we are focusing our view on?
also you dont have to make an entire assembly as moveable to attach it, simply rendering a 2d version of it for the current view and using a depth offset, use that as a card for the moveable part, and hide the static once you render the card, then you dont even need movables.
there is also collision issues with many parts, the simple solution is to do a visual interrace and get tangent at location, use that instead of collision, so a surface mount item will mount to the visual outer surface.

these are just a few bug fixes and performance booster i would have looked at.
again this is speculative and only the opinion of a play test, and I have no actual knowledge of how the code actually functions

bruh they are making this in unity engine 

[EverydayKerbonaut]

9 hours ago, Profugo Barbatus said:

This reads like you've only ever made static environment, limited interaction games at best, and have no idea what your talking about at worse. What you've written reads to me as "Just abstract away every interacting element of the simulation in pursuit of a stable physics delta" which can be translated for the less development inclined as "Just use the KSP Physics model from 2013 and drop all the new simulation details". It defeats the purpose of a freeform sandbox simulation of rocket building and flight. Not to mention half the abstractions via assumption you propose break fundamentally under anything more complex than single resource sink perfect scenario operations. And if it were as simple as "if 15 seconds passed irl and lag means you only finished 8 seconds worth of processing, just simulate the other 7 but faster" is like telling someone to charge their phone by turning up the brightness - you can't fix an execution speed problem by enforcing that the execution happen on time without just abandoning a processing cycle halfway through every time it goes under load - which would ensure complete collapse of the physics simulation at that point as you just have to ignore impulses or time travel. Reducing the physics delta is what they already do, and its the only viable option.

Pretty much the only thing I nodded along to with a "Yea" was the rename/map issue where someone just forgot to set a flag somewhere in their UI toolkit or input mappings. 

no i think you are missing the point.
this needs to improve the formula's used for calculations and have time passed as a factor.
this needs to be simplified so a ship can be calculated moving at 10x, 50x, or 1000x
you should not need to watch it do calculations for every frame, since time warp is a thing, and inactive vessels is a thing, 
the formula used for time warp simply needs to see if the craft can obtain a stable rotation in the time that passed, or calculate movement change in the time passed and current heading, velocity and all that.

now as for physics, it needs to simulate larger chunks of time as a single calculation so if it takes 5 seconds to simulate 1 second worth of action then instead it is smart enough to group every 5 actions into a single simulation and achieve a steady 1 second to simulate 1 second worth of action.
the physics formula needs to adjust to allow the steady passing of time, 

now if physics formula allows for larger chunks of time to be calculated, then it will also work with warping.
one formula that fix lag and allow time to move at the correct speed, and also allow for it to function under time warp as well.

oh and for multiplayer they will need to reduce the amount of info sent over the network and most likely its simply the vessel layout, and initial orbit, then only changes to orbit and configuration

[dvrabel]

Analytical solutions for coupled, multi-body systems do not exist, so it is impossible to "improve the formula's used for calculations and have time passed as a factor". Take a look at "double pendulums" for an illustrative example.

The differential equations for such systems need to be solved using numerical methods and thus require small time deltas to get a sufficiently well-behaved approximation of reality.

[Periple]

2 hours ago, EverydayKerbonaut said:

now if physics formula allows for larger chunks of time to be calculated

Big if

[lemon cup]

“simply” “only” “just” “should work” 

Reduction fallacy