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
This issue catalogues some non-blocking oddities in the fix to #2400:
When an intrinsic force is first applied, a stretch of trajectory of up to one fixed step integrated with an adaptive step method without any intrinsic force (the psychohistory which is made authoritative) is added to the checkpoint, even though it is not affected by the intrinsic force.
This has no visible consequence, though it may get in the way of potential future niceties such as highlighting accelerated trajectory segments, analysing past free-falling trajectories, etc.
When the set of parts of a vessel changes without the application of forces:
There may not be a point in the history of the parts (and thus of the vessel) where this change occurs.
Since that point would be needed as the initial state of a checkpoint, a checkpoint is not taken, even though such a change leads to a discontinuity in its trajectory.
Ramification: This may lead to visibly incorrect reanimation.
When a vessel collides with another:
There may not be a point in the history of the parts (and thus of the vessels) where the multi-vessel pile-up ends.
That point would be needed as the initial state of a checkpoint; however, a checkpoint is taken regardless, at the last point of the history prior to the end of the multi-vessel pile-up.
Ramification: This may lead to visibly incorrect reanimation.
Ramification: This leads to multiple checkpoints being created at the same time (Crash in TEST3274 #3277).
The dense points at the end of a collapsible segment are not downsampled once that segment is finished (by following it up with a non-collapsible segment).
Issues 1., 2., and 3. would need support in the PileUp to be properly fixed.
For 2. and 3., a newly created PileUp should append its initial state to the histories of the parts, much like it appends the psychohistory to the history when intrinsic acceleration starts.
For 2., the PileUp should signal (probably via a transient flag set by DeformAndAdvanceTime) that it has created a new fixed-step instance, so that the vessel is aware that a new checkpoint must be created; it might be necessary to convey the time at which that checkpoint should be placed as well.
For 1., the PileUp should communicate (perhaps by a similar mechanism) the time at which intrinsic acceleration starts, so that the stretch of free falling psychohistory isn’t part of the checkpoint.
However, none of this invalidates the basic principle of the solution to #2400, and in particular the serialized format need not change; it may be best to move forward with Entwurf as is, and fix these issues at a later date.
In the meantime, 3.iv. may be addressed by not creating the duplicate checkpoints (#3282).
Issue 4. is separate.
The text was updated successfully, but these errors were encountered:
This issue catalogues some non-blocking oddities in the fix to #2400:
This has no visible consequence, though it may get in the way of potential future niceties such as highlighting accelerated trajectory segments, analysing past free-falling trajectories, etc.
Issues 1., 2., and 3. would need support in the PileUp to be properly fixed.
For 2. and 3., a newly created PileUp should append its initial state to the histories of the parts, much like it appends the psychohistory to the history when intrinsic acceleration starts.
For 2., the PileUp should signal (probably via a transient flag set by DeformAndAdvanceTime) that it has created a new fixed-step instance, so that the vessel is aware that a new checkpoint must be created; it might be necessary to convey the time at which that checkpoint should be placed as well.
For 1., the PileUp should communicate (perhaps by a similar mechanism) the time at which intrinsic acceleration starts, so that the stretch of free falling psychohistory isn’t part of the checkpoint.
However, none of this invalidates the basic principle of the solution to #2400, and in particular the serialized format need not change; it may be best to move forward with Entwurf as is, and fix these issues at a later date.
In the meantime, 3.iv. may be addressed by not creating the duplicate checkpoints (#3282).
Issue 4. is separate.
The text was updated successfully, but these errors were encountered: