Fixed neighbor finding loop and added probabilistic movement

[casals]

Contains

• Partial fix for Stuttering motion with multiple characters with 'stray' behavior #15
• Implements optional probabilistic movement for the movement action associated with the stray behavior

Objective

Mitigate the synchronized stray behavior observed in the associated issue. Implementing a probabilistic movement action creates a visually smoother behavior for entities possessing the stray behavior and grouped in the same region.

Changes

• Removed fixed variable for neighbor iteration in SetTargetToNearbyBlockNode and replaced it with a random number generator
• Added the optional parameter moveProbability for the action set_target_nearby_block in doRandomMove.behavior
• Changed how the reachedTarget flag is raised in MoveTo minion action
• Added a yaw reset when the minion reaches the target

Usage

The examples below show the usage of the set_target_nearby_block in conjunction with doRandomMove.behavior:

• Using the default settings (movement probability = 100%):

{
  sequence : [
    set_target_nearby_block,  
    move_to
  ]
}

• Settings the movement probability to a specific value (integer):

{
  sequence : [
  {
    set_target_nearby_block : { moveProbability: 65 }
  },
    move_to
  ]
}

[dkambersky]

AFAIK the loop / synchro stuff was already fixed by 83986dc?

So hopefully this wouldn't need any additional mitigation. Nevertheless, the moveProbability stuff could potentially be useful (even though IMO it'd probably make more sense as a general Decorator to decide whether a particular Action runs or not - it's not really Move specific). Thoughts from anyone else?

Any particular reason why the RANDOM_BLOCK_ITERATIONS stuff was removed? Seems like it was there to make the blocks picked more varied / potentially far from one another.

[casals]

Adding a few more details:

• The loop with RANDOM_BLOCK_ITERATIONS was affecting the stuttering and not really helping with the neighbor variation (the value was fixed and the selection was re-randomized within the interaction - it looks like something inherited from a past implementation).

• moveProbability mitigates the synchronization effect observed when two animals move to a neighbor in the same direction at the same time (parallel movement vectors). It can be implemented as a general Decorator later for overall Action execution probability, of course - ultimately different Actions can have different probability rolls.

[casals]

Amended the commit to reflect the original RANDOM_BLOCK_ITERATIONS loop on neighbor finding, but randomized.

[Cervator]

Tested out, merging 👍

Am having a hard time tracking what is an outstanding issue and what may be newly introduced bugs. I noticed the "sliding" effect mentioned at #20 (comment) and also saw that all deer seemed to reset to point in a specific direction after they're done moving. Will continue on merging and hope to straighten it all out when we have fewer parallel PRs.

[casals]

I can confirm the "sliding"movement as well. (Context: all behaviors that ultimately use the MoveTo action) I think it's more noticeable after the target checking was amended (because now the deers are actually stopping at the target), but it might be the case that only fixing the yaw when the target was reached is not enough. I think it's worth testing it with PR#21 since there's no specific stop action in the target checking method - just a behavior status update. If the lack of a stop instruction is the only problem, the new behavior should solve it. However, since there are other minor glitches observed (like the unnecessarily high jump when sometimes climbing up/down), there might be still other things out there. If we consider everything up to this point from the first "stutter" issue, I think it's safe to say the stuttering was actually a cluster of different minor bugs, and we're still bound to find additional bugs previously unobservable/masked while fixing the others. Perhaps this is something that we can link to the current FlexibleMovement issue on using the old behavior structure: by removing the current pathfinding structure we'll be able to better observe what's behavior-related, what's pathfinding-related, and (perhaps) what's completely unrelated to either. Or - at this point - we could just raise a post-mortem issue, which is trying to identify what was actually solved by the recent related PRs, what was possibly introduced, and what's left.