You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FastLoader patch cause drag cubes to be semi-randomly wrongly generated.
Specifically, this seems to happen on all parts having multiple drag cubes defined, this include parachutes, but also animated parts such as the inflatable heatshield, deployable antennas, landing gears, etc.
The FastLoader patch alter the part compilation to decouple it from framerate, but it seems some part of the drag cube computations actually require a frame to skipped.
The required frame skip could be either setting the part animation at the desired position for each drag cube, or the aero texture not being updated immediately, this require further investigation. In any case, it seems to be necessary to reimplement at least some of the frame skips (yield return null) defined in DragCubeSystem.RenderDragCubes().
The reason it's semi-random is likely because the FastLoader patch still skip a frame occasionally to maintain ~30 FPS while loading, so depending on CPU/GPU speed as well as "data alignment", this doesn't reproduce on the same drag cubes every time, and sometimes not at all.
For reference, the needed frame skip was after calls to IMultipleDragCube.AssumeDragCubePosition(), which is logical in hindsight as this usually calls Animation.Play(), a deferred unity call. Actual animation processing occurs in the animation update in between frames.
This was fixed by adding a static flag flip in a DragCubeSystem.RenderDragCubes() transpiler, after the call to IMultipleDragCube.AssumeDragCubePosition(), then skipping an additional frame from the FastLoader coroutine wrapper if the flag is set.
Initially reported on the forums
The FastLoader patch cause drag cubes to be semi-randomly wrongly generated.
Specifically, this seems to happen on all parts having multiple drag cubes defined, this include parachutes, but also animated parts such as the inflatable heatshield, deployable antennas, landing gears, etc.
The FastLoader patch alter the part compilation to decouple it from framerate, but it seems some part of the drag cube computations actually require a frame to skipped.
The required frame skip could be either setting the part animation at the desired position for each drag cube, or the aero texture not being updated immediately, this require further investigation. In any case, it seems to be necessary to reimplement at least some of the frame skips (
yield return null
) defined inDragCubeSystem.RenderDragCubes()
.The reason it's semi-random is likely because the FastLoader patch still skip a frame occasionally to maintain ~30 FPS while loading, so depending on CPU/GPU speed as well as "data alignment", this doesn't reproduce on the same drag cubes every time, and sometimes not at all.
A few examples :
The text was updated successfully, but these errors were encountered: