From dba79f113cea22c44c16a2d6aa521cab222d66d5 Mon Sep 17 00:00:00 2001 From: chimchooree Date: Tue, 15 Jun 2021 10:13:12 -0500 Subject: [PATCH] updated diary entries --- src/diary/entries/210610 | 87 ++++++++++++++++++++++++++++++---- src/diary/entries/210701 | 20 +++++--- src/static/img/ent/follow.gif | Bin 0 -> 1550060 bytes src/static/xml/blessfrey.xml | 38 +++++++-------- src/views/contact.tpl | 4 +- 5 files changed, 112 insertions(+), 37 deletions(-) create mode 100644 src/static/img/ent/follow.gif diff --git a/src/diary/entries/210610 b/src/diary/entries/210610 index c2d1045..a4d3b65 100644 --- a/src/diary/entries/210610 +++ b/src/diary/entries/210610 @@ -1,19 +1,34 @@ -

how my characters follow a moving target

+

follow a moving target

june 10, 2021
#ai #character #movement

-After redesigning movement to support patrols, I realized the path remains static even if the target moves. Time to tweak the design and debug.
+After redesigning the movement system to support patrols, I realized the path remains static even if the target moves. Time to tweak the design again.

what must be done


-Autopathing to attack targets, skill targets, and item targets still partially rely on an old version of the movement system. Also, characters never update their pathfinding, so they cannot pursue moving targets. With some changes, the movement system can officially support following any of these targets, no matter where they go.
+Autopathing to attack targets, skill targets, and item targets still partially relies on an old version of the movement system. Also, characters never update their pathfinding, so they cannot pursue moving targets. With some changes, the movement system can officially support following any of these targets, no matter where they go.

-For now, I'll update the movement system so that the character can autopath after a moving item then pick it up once within reach. Since autopathing to items works identically to the others, the fix for them will be the same, too.
+For now, I'll update the movement system so the character can autopath after a moving item then pick it up once within reach. Since autopathing to items works identically to the others, the fix will be the same, too.

upgrading the movement system


I can keep the same system more or less, but one function is going to have to be rewritten: the character's path_to_object method.

-Before, it only set the next waypoint and built a path between the character and the waypoint. In order to follow moving targets, it needs to use the goal object itself. Also, it needs to be know when to only rebuild part of the path.
+Before, it only set the next waypoint and built a path between the character and the waypoint.
+
+

old path_to_object


+# Set Dots Between Character + Given Object
+func path_to_object(goal):
+     if goal.is_in_group("waypoint"):
+          set_next(goal)
+     else:
+          room.add_waypoint(goal.get_gpos())
+     path_to_position(goal.get_gpos())
+
+# Set Dots Between Character + Given Position
+func path_to_position(goal_pos):
+     set_dots(find_dots_pos(goal_pos))
+
+In order to follow moving targets, it needs to use the goal object itself. Also, it needs to be know when to only rebuild part of the path.

the character receives a waypoint instead of the target, so he is unaware of his target's movement


It took waypoints instead of the goal in the first place for consistency's sake. Since a target can either be a position (as with click-to-move) or an object (as with autopath-to-item) and the movement system only has one entry point, the old system only accepted objects. So when clicking-to-move, a Position2D waypoint is generated at the global mouse position.
@@ -29,23 +44,77 @@ For two, it's bad for performance. Generally, the efficiency of a lightweight Go
The next playable release after the bingo version will have a teleporting boss, so I'll probably need to be more thoughtful about pathfinding then. For now, though, these two fixes should do it...

+

new path_to_object


+# Set Dots Between Character + Given Object
+func path_to_object(goal):
+     # Next Waypoint
+     set_next(goal)
+     var goal_pos = goal.get_gpos()
+     var dots = get_dots()
+     var cd = get_current_dot()
+     # If no current dot, set dots between user and goal
+     if cd == null:
+          set_dots(find_dots_pos(get_gpos(), goal_pos))
+          MessageBus.publish("moved", self)
+          return
+     var last_dot = cd if len(dots) == 0 else dots.back()
+     # Make sure goal has moved significantly
+     if goal_pos.distance_to(last_dot) <= get_intimate_space():
+          return
+     # If goal moved further away
+     if get_gpos().distance_to(last_dot) > find_distance(goal):
+          # If no dots, generate new ones
+          if len(dots) == 0:
+               set_dots(find_dots_pos(get_gpos(), goal_pos))
+               MessageBus.publish("moved", self)
+               return
+     # If dots, only recalculate part of the path
+     var near = get_dots()[0]
+          for dot in get_dots():
+               if dot.distance_to(goal_pos) < near.distance_to(goal_pos):
+                    near = dot
+          var i = get_dots().find(near)
+          set_dots(get_dots().slice(0, i - 1) +
find_dots_pos(get_dots()[i-1], goal_pos))
+     # If goal moved closer
+     else:
+          set_dots(find_dots_pos(last_dot, goal_pos))
+     MessageBus.publish("moved", self)
+

testing


Now let's test it. I don't have any items that move around, so I'll quickly throw that in. I'll add some movement based on a sine wave into the _process method.

var time = 0 func _process(delta): - time += delta - var mod = Vector2(delta, cos(time) * 2) - set_gpos(get_gpos() + mod)
+     time += delta +     var mod = Vector2(delta, cos(time) * 2) +     set_gpos(get_gpos() + mod)


the character never stops autopathing, even after picking up the item


Okay, one more fix, then I'll have it.

-Previously, the movement AI relied on conditional statements in its process to detemine arrival at the goal. Instead, the achievement system handles arrival for the new movement system. Since the process is called faster than the event handlers can function, the old AI system picked up and queue_free'd the floor item before the new system could recognize it had arrived at the goal. This meant the character never truly arrived and never knew to halt the movement process or clear movement variables.
+Previously, the movement AI relied on conditional statements in its process to detemine arrival at the goal. Instead, the achievement system handles arrival for the new movement system. Since the process is called faster than the event handlers can function, the old AI system picked up and queue_free'd the floor item before the new system could recognize it had arrived at the goal. This meant the character never truly arrived and never knew to halt the movement process or clear movement variables.

Moving the conditional statements from _process to the function that handles the outcome of movement events.

+

new result code


+#enum MOVED {ARRIVED, NOT_MOVING, TOO_SLOW, WRONG_DIRECTION}
+func handle_moved_result(result, new_user):
+     if result == 0:
+          new_user.think("UserMove/Arrived")
+          if get_user().get_target() != null:
+          if track:
+               if get_user().find_distance_to_target() <= get_user().get_intimate_space():
+                    emit_signal('item_arrived')
+          get_waypoints().pop_front()
+          new_user.clear_movement()
+          return
+

just a few changes makes a big difference


+
+(image: Angel adjusts her pathfinding to follow a moving item.)

+
+Last Updated June 12, 2021 +
diff --git a/src/diary/entries/210701 b/src/diary/entries/210701 index a951eff..515d73c 100644 --- a/src/diary/entries/210701 +++ b/src/diary/entries/210701 @@ -20,15 +20,15 @@ july 1, 2021

tuesday, june 8