Skip to content
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

feat!: Replace Pathfinding with FlexiblePathfinding (part 2) #89

Merged
merged 16 commits into from
Jan 21, 2022

Conversation

skaldarnar
Copy link
Contributor

@skaldarnar skaldarnar commented Jan 13, 2022

Follow-up to #88.

Integrates the state of Terasology-Archived/FlexibleMovement@e722d75 into this module.

  • restructure packages to match module guidelines
  • fixup! restructure packages to match module guidelines
  • feat!: integrate classes from FlexibleMovement
  • fixup! feat!: integrate classes from FlexibleMovement
  • chore!: remove left-over actions using Pathfinding
  • feat!: add assets from FlexibleMovement

Follow-ups

  • make use of @In (if possible) or initialization in construct() consistent
  • formatting of assets (JSON)
  • formatting of Java files
  • removing dead and commented code (or revive if necessary)
  • assess and iterate naming of actions and behaviors
  • slim down test assets (testcharacter.prefab itself, duplicates in children of parent character prefabs)
  • align behavior node prefabs for condition, jump, log, setTargetLocalPlayer, setTargetToNearbyBlock with the ones for findPathTo, moveAlongPath and moveTo

@jdrueckert
Copy link
Member

@DarkWeird I removed the following behavior node prefabs:

  • findPathTo.prefab
  • moveAlongPath.prefab
  • moveTo.prefab

For each of them you seem to have created a replacement in FlexibleMovement that's copied over here in this PR:

  • findpathtonode.prefab
  • movealongpathnode.prefab
  • movetonode.prefab

Can you tell me what these prefabs are used for?

Also, I noticed the following changes when comparing the originals and their replacements:

  • removal of action field - why is this not needed anymore?
  • removal of displayName field - why is this not needed anymore?
  • replacement of name field value with displayName field value - is this the new "displayName" field?
  • introduction of type field - where does this come from?

@DarkWeird
Copy link
Contributor

@DarkWeird I removed the following behavior node prefabs:

  • findPathTo.prefab
  • moveAlongPath.prefab
  • moveTo.prefab

For each of them you seem to have created a replacement in FlexibleMovement that's copied over here in this PR:

  • findpathtonode.prefab
  • movealongpathnode.prefab
  • movetonode.prefab

Can you tell me what these prefabs are used for?

Also, I noticed the following changes when comparing the originals and their replacements:

  • removal of action field - why is this not needed anymore?
  • removal of displayName field - why is this not needed anymore?
  • replacement of name field value with displayName field value - is this the new "displayName" field?
  • introduction of type field - where does this come from?

Seems this prefabs using for BehaviorsEditor only.
I don't feel any problem... When haven't thm

@skaldarnar skaldarnar marked this pull request as ready for review January 18, 2022 21:06
Comment on lines +1 to +11
{
"BehaviorNode": {
"type": "FindPathToNode",
"name": "Find Path",
"category": "movement",
"shape": "rect",
"description": "Finds a path to target using FlexiblePathfinding",
"color": [180, 180, 180, 255],
"textColor": [0, 0, 0, 255]
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we just remove all of these prefabs and link them in a central issue to bring them back with support for the behavior tree editor? Having half of them might be more confusing than helpful...

Or are they actually complete (or only a few missing)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There still is the ensureTargetPresent.prefab which can be removed as we remove the node.
Apart from that we still only have the "old ones" for:

  • condition
  • jump
  • log
  • setTargetLocalPlayer
  • setTargetToNearbyBlock

Would be nice if @DarkWeird could comment on my questions on the differences/changes between old originals and new replacements. Migrating the above-listed remaining ones in a similar fashion should be easy, but I'd like to understand the changes first before applying them to the rest.

Comment on lines +1 to +38
{
"MinionMove": {
"movementTypes": ["walking", "leaping"]
},
"NameTag": { "text": "testcharacter" },
"Behavior" : {
"tree" : "naiveMoveTo"
},
"persisted" : true,
"location" : {},
"Character": {},
"CharacterHeldItem" : { },
"Network" :{},
"Health" : {
"maxHealth": 1,
"currentHealth": 1,
"excessSpeedDamageMultiplier": 0,
"destroyEntityOnNoHealth" : true
},
"Trigger" : {
"detectGroups" : ["engine:debris", "engine:sensor"]
},
"CreatureNameGenerator" : {
"genderRatio" : 0.5,
"nobility" : 0.5,
"theme": "DWARF"
},
"AliveCharacter": {},
"CharacterMovement" : {
"groundFriction" : 16,
"speedMultiplier" : 0.3,
"distanceBetweenFootsteps" : 0.2,
"distanceBetweenSwimStrokes" : 2.5,
"height" : 0.9,
"radius" : 0.3,
"jumpSpeed" : 12
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This thing has so many properties - I hope we can slim it down a bit later

@@ -0,0 +1,4 @@
{
"type": "FlexibleMovementDebugLayout",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code of this class is commented out. Either one the first things to revive, or to throw out in a follow up and write down an issue for instead.

Comment on lines 61 to 65
MinionMoveComponent flexibleMovementComponent1 = actor.getComponent(MinionMoveComponent.class);
flexibleMovementComponent1.running = false;
if (path == null || path.size() == 0) {
actor.save(flexibleMovementComponent1);
return;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has the changes around MinionMoveComponent#running which were added in an attempt to understand what's happening and to fix potential issues. It was not there in the original code from FlexibleMovement, so maybe we should revert d136af9 (#89).

}

@Override
public BehaviorState modify(Actor actor, BehaviorState result) {
final MinionMoveComponent moveComponent = actor.getComponent(MinionMoveComponent.class);
if (moveComponent.path == null) {
// this an action node, so it will always be called with BehaviorState.UNDEFINED
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is true, though - I'd like to keep this comment as help for further work on this.

Comment on lines 78 to 81
if (result == BehaviorState.RUNNING) {
// this can never happen o.O
return result;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this code looks like this action should sometimes return RUNNING, but I'm not sure when exactly/how to check whether the pathfinding process is currently running or not....

@DarkWeird any clue on this?

// current index along path above
private int pathIndex = 0;

public boolean running = false;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not stay in like it is.

@skaldarnar skaldarnar added Status: Needs Testing Requires to be tested in-game Topic: AI Requests, Issues and Changes related to pathfinding, behaviors, etc. Topic: Stabilization Requests, Issues and Changes related to improving stablity and reducing flakyness labels Jan 18, 2022
@skaldarnar skaldarnar merged commit 317dd65 into develop Jan 21, 2022
@skaldarnar skaldarnar deleted the feat/merge-flexible-movement-2 branch January 21, 2022 17:03
skaldarnar added a commit to Terasology-Archived/GooKeeper that referenced this pull request Jan 21, 2022
skaldarnar added a commit to Terasology/WildAnimalsGenome that referenced this pull request Jan 21, 2022
@jdrueckert
Copy link
Member

skaldarnar added a commit that referenced this pull request Mar 13, 2022
- style: format `.behavior` files
- chore: add TODO ideas and questions in several places
- chore: add some debug logging
- feature/fix: small adjustments to Behaviors logic

Follow-up PR to #89.

Related PRs (extracted from this): #94, #96, #97, #99.

Contributes to MovingBlocks/Terasology#4981.

Depends on Terasology/FlexiblePathfinding#26 and Terasology/FlexiblePathfinding#27.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Needs Testing Requires to be tested in-game Topic: AI Requests, Issues and Changes related to pathfinding, behaviors, etc. Topic: Stabilization Requests, Issues and Changes related to improving stablity and reducing flakyness
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants