Roadmap for replace Pathfinding with FlexiblePathfinding

Motivation

• High memory usage of Pathfinding(especially in java)
• Unnecessary PF’s NavGraph usage (e.g. CoreGameplay don’t needs it, but NavGraph is creates)
• We have alternative already (FPF)

Concerns

• Is there specific expertise that will be needed for this effort?
• Does this effort have dependencies on other efforts?
• Do you expect this effort to conflict with any other efforts?
• What are potential drawbacks of the effort?
• What are maintenance or continuous efforts that will persist beyond the completion of this effort?

Task Breakdown

• Extract pathfinding behaviours from behaviours (this was done in https://github.com/Terasology/FlexibleMovement and https://github.com/Terasology/PathfindingBehaviors )
• Rewrite dependency from behaviours to PF’s behaviours for depending modules (most specified dependencies were unused)
• Write PF’s behavours alternatives for FlexableMovement.
• Replaces PF behavours with FPF behaviours in depending modules (we actually did a near in-place migration in Terasology/Behaviors#88 and Terasology/Behaviors#89. therefore, we did not need to change much in modules. all relevant PRs are linked in those two PRs)
• Replace PF with FPF in omega lineup (https://github.com/Terasology/Index/commit/9e0b097850d9f0490fff0c55ea894a11d375d097 and https://github.com/Terasology/Index/commit/3ceb298733bfee39d843a6d8eca14492ba059a9d)
• Follow-ups from Terasology/Behaviors#89
  • check if use of @In possible

    @In
    private WorldProvider world;
    

    • it’s not possible in behavior actions
  • use initialization in construct() consistently throughout behavior actions - https://github.com/Terasology/Behaviors/pull/102

    @Override
    public void construct(Actor actor) {
        if (world == null) {
            world = CoreRegistry.get(WorldProvider.class);
        }
    }
    

    • this will work if @In has no effect, i.e., the field is initialized to null
    • this will work if @In is fixed and initializes the field correctly, making the code in construct a no-op
    • we preserve the information that we want to use @In in actions
  • formatting of assets (JSON)
    • behaviors cannot be properly JSON-formatted without changing the behavior parser
  • formatting of Java files
  • removing dead and commented code (or revive if necessary) - https://github.com/Terasology/Behaviors/pull/103
    • no dead / commented code in assets
    • FlexibleMovementDebugLayout almost entirely commented out
    • ValidatePath action has some out-commented code
  • assess and iterate naming of actions and behaviors
    • this is a potential rabbit-hole and more or less endless task… should be tracked separately and specified in more detail
  • slim down test assets (testcharacter.prefab itself, duplicates in children of parent character prefabs) Terasology/Behaviors#90
  • revert replacement of behavior node prefabs for findPathTo, moveAlongPath and moveTo https://github.com/Terasology/Behaviors/pull/91

Optional tasks and improvements

• Move code and features from Gooyes Defence to FlexableMoving.
• Provide documentation for FPF.

[jdrueckert]

All documented follow-ups done, closing this issue.

[jdrueckert]

Regarding the lacking support for dependency injection in behavior actions, I noticed, that we do have something in that direction in BehaviorTreeBuilder::addAction. However, I don’t know whether - and if not why - this is sufficient.

I wonder whether this might be related to the respective fields not being registered, yet, rather than the dependency injection not working as expected…?

If we are sure that the fields are registered and the dependency injection is implemented incorrectly, https://github.com/MovingBlocks/Terasology/issues/5003 might be related.