Standing still for 35 minutes breaks animation system in Desktop mode

[jae1911]

Describe the bug?

When AFK in desktop mode, if the player stays still for more than 35 minutes, the animation system will completely break, needing a respawn to be fixed.

Time range: 35 minutes - 1 hour.

To Reproduce

1. Open Resonite
2. Load into world and avatar
3. Stay still for more than 35 minutes
4. Observe the animation system is broken

Expected behavior

The animation system should work as expected regardless of time spent immobile.

Screenshots

Footage sped up 6x times.

https://youtu.be/BR-dzuji2nc

As you can see at the end of the video (05:55), the locomotion system just stops working at all and locks the avatar in a static scrambled pose.

Resonite Version Number

Beta 2024.10.29.1229

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop

Log Files

TETHYS - 2024.10.29.1229 - 2024-11-04 16_58_31.log

Additional Context

It took me way too long to report this.

Only tested in world hosted locally with an avatar having a custom locomotion animation module.

Reporters

U-j4 | j4.lc (Discord)

[shiftyscales]

Only tested in world hosted locally with an avatar having a custom locomotion animation module.

Does this also occur on the unmodified defaults as well, @jae1911? If not, can you share what properties are modified from stock?

I'd also recommend enabling debug visuals during the entire run for subsequent tests / recordings. Relevant exception seems to be:

17:37:23.157 (170 FPS)  Exception when Updating object: Element: ID4F33700, Type: FrooxEngine.UserPoseController, World: Jae's Home, IsRemoved: False, IsDestroyed: False, IsDisposed: False, Enabled: True
Element: ID4F31300, Type: FrooxEngine.Slot, World: Jae's Home, IsRemoved: False, Slot name: User <noparse=2>J4 (ID2E00), T: [0.01090509; -0.0002065609; 1.385103], R: [0; 0; 0; 1], S: [0.75; 0.75; 0.75], ActiveSelf: True, IsDestroyed: False
Element: ID67100, Type: FrooxEngine.Slot, World: Jae's Home, IsRemoved: False, Slot name: <color=hero.orange>🐢</color> Users, T: [0; 0; 0], R: [0; 0; 0; 1], S: [1; 1; 1], ActiveSelf: True, IsDestroyed: False
Element: ID2300, Type: FrooxEngine.Slot, World: Jae's Home, IsRemoved: False, Slot name: Root, T: [0; 0; 0], R: [0; 0; 0; 1], S: [1; 1; 1], ActiveSelf: True, IsDestroyed: False
Element: ID0, Type: FrooxEngine.World, World: Jae's Home, IsRemoved: False

Exception:
System.ArithmeticException: Function does not accept floating point Not-a-Number values.
  at System.Math.Sign (System.Single value) [0x00028] in <9577ac7a62ef43179789031239ba8798>:0 
  at FrooxEngine.LocomotionSimulator.SimulateHead (FrooxEngine.LocomotionSimulator+MoveData& data) [0x001f8] in <1c37b8104a504ccf836b1c567f150291>:0 
  at FrooxEngine.LocomotionSimulator.Update (Elements.Core.float3 positionDelta, Elements.Core.floatQ rotationDelta, System.Single deltaTime, FrooxEngine.LocomotionState state, System.Single headCrouchOffset) [0x006de] in <1c37b8104a504ccf836b1c567f150291>:0 
  at FrooxEngine.UserPoseController.OnCommonUpdate () [0x01009] in <1c37b8104a504ccf836b1c567f150291>:0 
  at FrooxEngine.ComponentBase`1[C].InternalRunUpdate () [0x0001f] in <1c37b8104a504ccf836b1c567f150291>:0 
  at FrooxEngine.UpdateManager.RunUpdates () [0x0007c] in <1c37b8104a504ccf836b1c567f150291>:0

[jae1911]

Does this also occur on the unmodified defaults as well, @jae1911? If not, can you share what properties are modified from stock?

Given the time it takes to test this, I haven't tested with the default values (though I suspect this happens as well with those).

One configuration tested was June's: https://github.com/Yellow-Dog-Man/Resonite-Issues/discussions/2799#discussioncomment-10619650

[shiftyscales]

Given the time it takes to test this, I haven't tested with the default values

Yes, and given the time it takes to test, the more of that you're able to offload / figure out / narrow down, the more likely we will be to be able to resolve this issue as otherwise you force our developers to need to do so themselves. E.g. make a line change, compile Resonite, wait up to an hour is kind of brutal- knowing it is related to a specific variable(s) narrows the amount of testing required.

How many runs have you done so far to determine the range of 35-60 minutes? Does it consistently happen? With a large time range, it sounds like it could be a semi-random issue that inevitably will pop up given enough time.

[jae1911]

How many runs have you done so far to determine the range of 35-60 minutes?

At least 5-6 runs over the last week, basically leaving Resonite open while having to do something else and then coming back to see that.

The video also definitely helped with determining the exact amount of time, and seems to be consistent with the observations during the week.

Does it consistently happen?

From my experience, it is very consistent.

Yes, and given the time it takes to test, the more of that you're able to offload / figure out / narrow down, the more likely we will be to be able to resolve this issue as otherwise you force our developers to need to do so themselves.

I just launched a test with default values while starting to cook, I will post the results when it is done.

[shiftyscales]

Thank you- knowing it happens 100% of the time (as best we're able to determine) would be helpful, e.g. reasonable confidence in determining if the issue has been fixed if it doesn't occur in the expected time span. If there are runs it does not occur it would be useful to nail down why, e.g. if the range of time is larger than initially suspected.

Thank you for looking into it further.

[JackTheFoxOtter]

I know this was an issue with the new "standing still" values in case they are set to 0. Not sure if this is the same cause.

[jae1911]

I retract my previous statement for now, coming back after an hour, the animation system still works as expected when on default settings.

I also tried to artificially speed up Resonite to check further, but without success.

[jae1911]

Looking at the past week, it seems the bug is really inconsistent now.

Whereas it would trigger on every single occurrence, since 2024.11.12.1329 this bug seems to be somewhat irregular or on time scales that are too big to test, though in some cases the 30 minutes - 1 breaking point still appears.

I'm still trying to get a way to get this bug to consistently show up within a reasonable timeframe.