-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed paused actor physics resuming after switching to another actor #3146
Conversation
Almost perfect. Found one crash scenario:
Under Debug I get infinite asserts when trying to backspace with the crane: RoR_2024-04-22_19-22-25.mp4 |
258ec18
to
b02c774
Compare
I fixed the asserts on backspacing the Liebherr crane, and added many more asserts in the process, because those that triggered were completely legit, |
b02c774
to
340fbd3
Compare
340fbd3
to
13120c1
Compare
Attached loads now move faster than the crane when using live repair mode (soft reset enabled): 8mb.video-lNy-61XoPei1.mp4vs master: RoR_2024-05-30_16-16-36.mp4 |
13120c1
to
46c6bf0
Compare
@CuriousMike56 Ready for another test. Turns out there was another bug in forced unlinking of inter-actor beams (both when deleting actor and hard-resetting) which left the actor data in inconsistent state. It's actually a very old bug in code written by Ulteq in ~2016/17 to fix multithreading problems related to inter-linking. It passed unnoticed until I introduced the |
#3146 (comment) still happens |
46c6bf0
to
ebfb60d
Compare
@CuriousMike56 Mystery solved: why did this only manifest when using ties (your scenario) and not hook (my initial scenario)? The reason is - by accident, the movement sync between the crane and the load was done once for each interconnecting beam, instead of once per actor pair. And because there's always just one hook beam, it worked OK with a hooked load, but there may be multiple ties (in this case 4), the load moved faster (4x in this case). Fixed by adding a cache of unique actor pairs, and updating it each time linking changes. |
This reverts commit 9431e1b where I tried to tidy-up duplicate syncing code but oversimplified the logic to reset unlinked actors. As result, the physics paused state and skeletonview state could only be active on player's actor and connected actor, not on any free standing one.
ebfb60d
to
c017ad8
Compare
@CuriousMike56 I apologize for all the trouble - it's all because I tried to automagically sync all state toggles in one place. I'm rebooting this PR by reverting the offending commit. The paused physics problem is gone, as well as all the LiveRepair glitches, also the crash in #3146 (comment) is gone. However, now I'm observing these glitches:
|
@CuriousMike56 I've refurbrished the prior commits without all the parts that touch LiveRepair (aka interactive reset).
|
767cb32
to
2a6c7c6
Compare
@CuriousMike56 Ready for another test. I had to revert most of my new code, including the asserts. I re-tested all the above scenarios, including the crash scenario you found originally, including the truck/trailer/car combo. |
PROBLEMS: * when you release a load from a hook (be it by pressing L or Hard-resetting), the skeletonview and physics paused states don't get reset. In 2022.12 it's the same except physicspause does get reset when unhooking by L (not by hardreset tho.). * when you release a load from ties using O key, skeleton view gets reset, but physics-pause does not. Also when you hard reset, everything remains dirty. 2022.12 behaves the same. * When you Hard-reset or delete a vehicle with hooks/ties attached, they are not removed correctly, causing a crash if re-attached. The `DisjoinInterActorBeams()` helper (used by SyncReset() and Actor destructor) was leaving data in inconsistent state - specifically, it properly removed the inter-beams themselves and linkage records (both the per-actor and global lists), but it didn't update the `tie_t/hook_t/rope_t` objects itself - these kept pointing to the deleted/reset actor. SOLUTIONS: * Remake the actor-linking code to track when 2 actors become linked/unlinked - and sync the sekeletonview & physicspause there. * Instead of employing custom code to do Hard-reset, extend the existing (old!) `hookToggle()/tieToggle()/ropeToggle()` funcs (used for regular locking/unlocking of those elements) to also do forced unlocking upon removing/SyncReset-ing an actor, and then modify `DisjoinInterActorBeams()` to use them. DEV NOTE: This is quite a significant remake of actor-linking code; a direct follow-up to d36c4ec which introduced ✉✉ MSG_SIM_ACTOR_LINKING_REQUESTED. A remake was needed because there was no single spot to correctly reset the skeleton/physicspause on actor unlink - there was simply no concept of "actors were just linked/unlinked". While researching how to add it, I realized scripts may want to know when that happens, so I added a script event `SE_GENERIC_TRUCK_LINKING_CHANGED` for it. Keep in mind there can be multiple interlinking beams at the same time, so not every added/removed beam means linking changes. The new event also helps navigate the codebase and documents how stuff works. CODECHANGES: * SimData.h: the ActorLinkingRequestType enum was merged with HookAction enum and got new fields: HOOK_RESET, TIE_RESET, ROPE_RESET - the `DisjoinInterActorBeams()` function now uses these. * Actor.h: `hookToggle()/tieToggle()/ropeToggle()` funcs got new parameter `forceunlock_filter` and all now accept ActorLinkingRequestType param; * Actor.cpp: `SyncReset()` no longer manipulates beams/hooks/ties/ropes directly - that's all done by the extended `DisjoinInterActorBeams()`. * ScriptEvents.h - added SE_GENERIC_TRUCK_LINKING_CHANGED * All other files are just fallout from changes above.
2a6c7c6
to
58520dd
Compare
PROBLEM: typo (a copypaste derp) in GameContext.cpp ADDITIONAL FIX: an assert() when loading Penguinville-TrolleyLine terrain. The blendmap info was incomplete (understandable since the terrain is meshed-only) and the game ended up reading bad memory. Fixed by adding a check for valid data which reports "[RoR|Terrain] Page {}-{} has no blend layers defined, blendmap will not be set up." to RoR.log.
c047902
to
14017e1
Compare
Fixes #3105.
This was quite an endeavor - it turned out there's no single spot to correctly reset the physics pausd state (or skeletonview state - related). While researching how to add it, I realized scripts may want to know when (un)linking of actors happens, so I added a script event
SE_GENERIC_TRUCK_LINKING_CHANGED
for it.What changed: code changed signifficantly; all data remained the same - code handling hooks/ties/ropes/slidenodes got only cosmetic edits. There are many new sanity/integrity checks in the (un)linking logic which will trigger Asserts on Debug and just prevent damage on Release.
What to test: Operation of ties/hooks/ropes/slidenodes, including savegame and abrupt deleting of one of the actors.