Odd all-npc hostile happened once when user had a follower and entered dragonsreach fireplace table area

[absol89]

Skyrim together 1.8.1

Not sure why this happened with a follower, but it was likely due to triggering because follower had weapon drawn

This code was changed afterwards for 1.8.1h (hostiles) and perhaps that makes sheathing detection less error prone

so the rejected PR treated the symptom (forcing hostility/draw) and its detection misfires caused issue #6's all-hostile event. The real defect is upstream of that: when AI ownership hands over to the remaining client, the actor's animation/behavior-graph state isn't reset, so the behavior tree resumes in a stale sheathed state and never transitions to combat even though StartCombat was called.

[absol89]

What actually goes wrong at handover
While the NPC is remote on client B, its animation graph is driven purely by LoadAnimationVariables() replays from the old owner's action stream (AnimationSystem.cpp:54). The graph's variables (weapon-drawn booleans, bAnimationDriven, iCombatStance, iState_*) reflect whatever the leaving owner last broadcast.
On localization, SetRemote(false) flips the flag, but nothing reconciles the behavior-graph variables with the actor's actual engine state. The graph resumes its state machine believing e.g. "sheathed + not in combat" while actorState says otherwise — or vice versa after our forced SetWeaponDrawnEx(true).
StartCombat sets the combat engine target but the behavior tree only leaves the sheathed branch if the graph variables/anim-events agree. Since they're stale, the tree stays parked in the sheathed state machine → NPC runs at you unarmed (your playtest), or worse, misdetected hostility fires (the rejected PR → issue #6).
The LocalizedActorState grace window currently only de-dupes broadcasts during localization — it never writes corrected state into the graph.

Proposed approach (root-cause, no forced-hostility detection)
On localization (TakeOwnership + assign-owner path), after SetRemote(false):

Re-sync the graph from engine truth: write the weapon-state animation variables to match actorState.IsWeaponDrawn(), and clear stale drive flags (bAnimationDriven = false, reset iCombatStance) via the same descriptor lookup table LoadAnimationVariables already uses — a new Actor::ResetAnimationVariablesToEngineState(). This hands the behavior tree a consistent starting state instead of the departed client's leftovers.
Then issue the wake (StartCombat + draw) so the transition happens with a clean slate — the existing ShouldWakeAtLocalization gating (aggression ≥2 / ini factions) stays exactly as-is, since that part wasn't the rejection reason.
Keep it idempotent: run once per localization tick, guarded by the existing LocalizedTick mechanism.
No new hostility heuristics anywhere — issue #6's trigger (detecting unsheathed NPCs and forcing them hostile) is simply gone because we never infer hostility; we only repair the state machine.

Before I build it: does this match your understanding of "anim states not handed over to the new AI package", and do you want me to implement step 1 as described (descriptor-based variable rewrite on localization)? If you have logs from a repro where you can see which variables are stale (e.g. from MoreInformativeConsole poking the graph), that'd let me verify the exact variable names rather than trusting the descriptor tables blindly.

[absol89]

Test plan for when you run build https://github.com/absol89/TiltedEvolutionScriptFixes/actions/runs/32590792572

Leader + party member near hostiles (bandits outside a mine work well)
Leader travels away → remaining player takes over AI
Check the local log on the remaining client for [AnimReset] cleared ... (idx N) lines right before Localization wake issued
Watch whether the bandit now sheathes→draws and attacks properly
The [AnimReset] output tells us exactly what happened:

Cleared flags present → mechanism works; if behavior is still wrong we add missing flags to the list
"cleared 0" → the graph wasn't stale as assumed, and I'll pivot to inspecting which variables differ between a working fresh-spawn NPC and a handed-over one