diff --git a/src/diary/entries/210601 b/src/diary/entries/210601 index dbdefd6..efa931f 100644 --- a/src/diary/entries/210601 +++ b/src/diary/entries/210601 @@ -94,5 +94,15 @@ june 1, 2021
  • Today, I'll push out my CSS update to go along with tomorrow's article.

  • -Last Updated: June 6, 2021
    +

    saturday, may 29

    + +
    +

    monday, may 31 - Memorial Day

    +
    +Last Updated: June 9, 2021

    diff --git a/src/diary/entries/210610 b/src/diary/entries/210610 index d8716a2..9556db2 100644 --- a/src/diary/entries/210610 +++ b/src/diary/entries/210610 @@ -1,6 +1,34 @@ -

    how to get a character to follow a moving target

    +

    how my characters 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.
    +

    what must be done


    +Patrols was the last significant feature I wanted to add before making a playable HTML5 release. Now I want to clean up the movement system, add Tutorial Bingo back into the game, and iron out any bugs that prevent shipping.
    +
    +Autopathing to attack targets, skill targets, and item targets still 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.
    +
    +For now, I'm going to update the movement system so that the character can autopath after a moving floor item and pick it up once within reach.
    +
    +

    the current movement system


    +(diagram of movement)
    +
    +

    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 . It needs to .
    +
    +
    +

    flaws + fixes


    +

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

    +A target can either be a position (as with click-to-move) or an object (as with autopath-to-item). For consistency's sake, the single entry point for movement for the old system only accepted objects. When clicking-to-move, a waypoint Position2D object is generated at the global mouse position and fed to the character.
    +
    +For more consistency, I took it a step further and also generated waypoints at the position of object targets. However, the system doesn't require a waypoint, only an object with a global position. Providing the goal directly to the character instead of a waypoint not only resolved issues but also simplified my code.
    +
    +

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

    +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.
    +
    diff --git a/src/diary/entries/210701 b/src/diary/entries/210701 index 663987f..d9c73dc 100644 --- a/src/diary/entries/210701 +++ b/src/diary/entries/210701 @@ -20,6 +20,8 @@ july 1, 2021

    tuesday, june 8

    +
    +

    wednesday, june 9

    + diff --git a/src/views/diary-boxes.tpl b/src/views/diary-boxes.tpl index 4d15b2b..8d317ec 100644 --- a/src/views/diary-boxes.tpl +++ b/src/views/diary-boxes.tpl @@ -2,7 +2,7 @@