Add sync for stalkers

[dartasen]

• Stalker FindNest : [O] : leashPosition can be changed by FindNest
• Stalker DropTooth : [O] : RemotePlayer cause DropTooth to duplicate items
• AttackLastTarget (Done through current system)
• MoveTowardsTarget (Done through current system)
• FleeOnDamage : [O] StopPerform might change Creature.leashPosition
• SwimToHeroPeeper : [CAW]
• AggressiveWhenSeeTarget (Done through current system)
• MeleeAttack
• PrisonPredatorSwimToPlayer : [O] Add support for RemotePlayer target
• CreatureFlinch [X]
• CreatureFear [X]
• PrisonCreatureBehaviour [X]
• AvoidObstacles [X]
• StayAtLeashPosition [X]
• AvoidEscapePod [O] : StopPerform might change Creature.leashPosition

Will need work after this PR :

• MeleeAttack (Pickup held item from remote player)
• CreatureFriend System
• CollectShiny

Closes #2250
Closes #2243
Contributes to #2627

[Copilot]

Copilot reviewed 16 out of 16 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

NitroxClient/GameLogic/Spawning/Metadata/Extractor/StayAtLeashPositionMetadataExtractor.cs:7

• The class name 'StayAtLeastPositionMetadataExtractor' appears inconsistent with the metadata type 'StayAtLeashPositionMetadata'; renaming it to 'StayAtLeashPositionMetadataExtractor' would improve clarity.

public sealed class StayAtLeastPositionMetadataExtractor : EntityMetadataExtractor<Creature, StayAtLeashPositionMetadata>

[OhmV-IR]

• Cameras are super desynced with stalkers grabbing them, I don't see the camera in the position that the other client does and they can pick it up after the stalker drops it to dupe cameras
• yellow goo attack VFX is not shown on the other client and neither is the SFX
• cuddlefish can escape alien containment through animation with player(probably out of scope for the PR)
• Stalkers hatched in alien containment but we did not see any change in behavior when we entered the room or the tank

[github-actions]

Test Results

  1 files   -   1    1 suites   - 1   15s ⏱️ -11s
243 tests ±  0  242 ✅ ±  0  1 💤 ±0  0 ❌ ±0 
243 runs   - 243  242 ✅  - 242  1 💤  - 1  0 ❌ ±0 

Results for commit cfe27a8. ± Comparison against base commit f5ab747.

♻️ This comment has been updated with latest results.

[dartasen]

PrisonPredatorSwimToPlayer behavior is weird in singleplayer as well :

• Will swim towards the player for 1s
• Will cancel and move somewhere else

Which has a weird look & feel when looking at the creature.
Multiple CreatureAction are evaluating different target independently : MoveTowardsTarget, PrisonPredatorSwimToPlayer, SwimToHeroPeeper

MoveTowardsTarget is very likely to run after PrisonPredatorSwimToPlayer, which is pretty quick since there's no delay between creatureActions

[dartasen]

All systems online

[Coding-Hen]

LGTM CW just a few minor points

[Coding-Hen]

Maybe worth creating a issue for this so we don't forget and someone can pick it up later. Let's not delay this, just think worth tracking for something separate and specific in another ticket as another bit of work.

[tornac1234]

While you're at it, would you patch MeleeAttack.CanDealDamageTo with a prefix like to ensure remote players aren't attacked when they shouldn't be ?

public static bool Prefix(GameObject target, ref bool __result)
{
    if (target.TryGetComponent(out RemotePlayerIdentifier remotePlayerIdentifier) && !remotePlayerIdentifier.RemotePlayer.CanBeAttacked())
    {
        __result = false;
        return false;
    }
    return true;
}

[tornac1234]

if we wanted to keep that minDistance logic, we should probably move it to GetNearestTarget so it actually acts as a filter

[dartasen]

I'll remove it, the rings behavior already implies to have a maxDistance

[tornac1234]

same here, GetCanSeeObject should be moved to IsTargetValid to be an actual filter
The current implementation could lead to situations like this one:

              player2 (distance = 50 => not target, GetCanSeeObject=true)
                             

 
               

Stalker |||wall||| player1 (distance = 30 => target, GetCanSeeObject=false)

player1 is closer to Stalker so they're picked as target, but then they're forgotten because they can't be seen, while player 2 might be in range and in sight range too (which means they're the only valid target here)

[tornac1234]

Could you explain why this is important ? (this is not in the base game and it seems to me that this wouldn't have any feedback on the current behaviour which might end up in situations where a player is a locked target so the stalker tries to attack it, but then another player is closer so the stalker randomly starts swimming towards that other player) (also if we were too keep that, we'd probably have to adapt the whole behaviour to drop the player as locked target when they're no longer a valid target)

[dartasen]

Could you explain why this is important ? (this is not in the base game and it seems to me that this wouldn't have any feedback on the current behaviour

Initial issue is that PrisonPredatorSwimToPlayer is using Player.main exclusively to decide behaviors of this Action. Other behaviors almost always have a local state (or another behavior like LastTarget that stores this information) to share the "target" between Evaluate and Perform methods.

So I do need a state to persist this information in whatever form it can take (static states in patch, Custom component, LastTarget, ...). With that being said it's not excluded that other behaviors are also using LastTarget, in fact it's the case for Stalker. Which is why I used SetLockedTarget instead of usual SetTarget.
However it does not prevent other behaviors to have another target state which can be different from LastTarget. But that's up to SN devs that implemented behaviors that can conflict with each other, that's not really the result of my choices (see #2255 (comment))

As a side note PrisonPredatorSwim behavior guarantee that the creature is inside the prison, thereferore they're friendly and all the agressive behaviors are disabled. Which can limit the weird behaviors between conflicting behaviors

also if we were too keep that, we'd probably have to adapt the whole behaviour to drop the player as locked target when they're no longer a valid target

I can implement that in Perform if needed

    public static void Perform(PrisonPredatorSwimToPlayer instance, Creature creature, float time)
    {
        LastTarget lastTarget = creature.GetComponent<LastTarget>();
        if (!lastTarget)
        {
            Log.ErrorOnce($"[{nameof(PrisonPredatorSwimToPlayer_Perform_Patch)}]: Creature {creature} does not have a LastTarget component.");
            return;
        }

       if (!IsValidTarget(lastTarget.target))
       {
            lastTarget.UnlockTarget();
            return;
       }

        Transform targetTransform = lastTarget.target ? lastTarget.target.transform : null;
        if (targetTransform && time > instance.timeNextSwim)
        {
            instance.timeNextSwim = time + instance.swimInterval;
            instance.swimBehaviour.SwimTo(targetTransform.position, instance.swimVelocity);
        }

        lastTarget.UnlockTarget();
    }