[Ohrrpgce] SVN: james/8834 Add preliminary scripting interface for NPC pathfinding. None of these a

[Ralph Versteegen]

On 10 June 2017 at 03:18, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Thu, Jun 8, 2017 at 9:06 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 9 June 2017 at 10:32, <subversion at hamsterrepublic.com> wrote:
>>
>>> james
>>> 2017-06-08 15:32:01 -0700 (Thu, 08 Jun 2017)
>>> 235
>>> Add preliminary scripting interface for NPC pathfinding. None of these
>>> are documented yet, because I gotta do testing first
>>>   pathfind npc to (n, x, y)
>>>   npc chases npc (n, dest n, stop when reached)
>>>   cancel npc movement override (n)
>>> ---
>>> U   wip/const.bi
>>> U   wip/game.bas
>>> U   wip/game.bi
>>> U   wip/plotscr.hsd
>>> U   wip/scriptcommands.bas
>>> U   wip/udts.bi
>>>
>>
>> Cool!
>> Instead of cancelnpcmovementoverride I think we should add a generic
>> stopnpc command to stop the current walk. Currently you have to script it
>> yourself by doing walknpc(npc, left, 0) , walknpc(npc, down, 0), but that's
>> non-obvious and can leave the npc misaligned (I guess we can add an arg
>> whether to finish the current tile's movement or stop immediately).
>>
>
> We definitely need a stopnpc command, but "cancel npc movement override"
> is doing something dramatically different.
>
> stopnpc would be canceling a step, either from a walk npc, or from a
> movement type.
>
> "cancel npc movement override" would allow the npc to revert to their
> normal movement type, which would only mean stopping if their previous
> movement type was non-walking, or if "suspend npcs" was active
>
> ...actually, if "suspend npcs" is not active, then "stop npcs" would also
> allow the NPC to resume their normal movement... so I guess the difference
> isn't that big.
>

Actually, I don't see any difference at all (assuming that the command
waits for the current step to end).
I guess I should have called it cancelnpcmovement instead of stopnpc, but
stopnpc is so, so much shorter. I meant a command to stop any current walk
command or pathfind, so that the npc returns to its normal movement type.


>
> Which reminds me, the way I implemented the pathfinding override is
> currently broken in regards to suspend npcs, so that is the next thing I
> need to fix.
>
>>
>> I think that the NPC/hero pathfinding commands should behave like other
>> NPC/hero walking commands; for example waitfornpc should work,
>>
>
> Yes, I definitely want to be able to use waitfornpc with the pathfinding
> commands,
>
> I was also thinking about adding an optional argument to wait for npc
> allow it to time-out on an endless path.
>
> Right now endless paths happen when an npc can't reach its destination,
> and waffles between two equally good consolation destinations. I think I
> can reduce the risk of that with better tie-breaking, but it is guaranteed
> to always be possible once other moving npcs are added to the equation.
>

Really? I haven't seen any NPCs pathing forever. However there's a lot of
bad back-and-forth behaviour due to other NPCs moving and changing the
available paths. It encourages me to argue for a more complicated cost
scheme for NPCs rather than just whether they're been stationary.


>
>
>> and using walknpc would cancel pathfinding and vice versa. (Is it useful
>> enough to have a way to move an npc without cancelling pathfinding to go to
>> the trouble of special commands? I guess they would be 'pause' and 'resume'
>> commands.)
>>
>
> I like having walknpc cancel pathfinding.
>
> I haven't tested yet, but I think that pathfinding will already wait for a
> walk npc command to finish before it begins pathing.
>
> I'm glad you reminded me to test how simultaneous pathfinding and walknpc
> will interact with each other.
>
>
>
>
>
>> Still, I guess npciswalking should probably return false for a
>> pathfinding npc that's currently stuck for consistency, with a separate way
>> to check whether an npc is pathfinding.
>>
>>
> I agree. "stuck" in the sense of unable to reach the desired target, but
> reached a consolation destination okay should definitely count as
> npciswalking == false
>
> I was thinking of having an optional maximum number of retries that
> autopathing will attempt before giving up and cancelling a movement entirely
>

That could be useful, but because the path is recalculated after every step
as the npc moves towards a consolation tile, the retry count would
effectively be the number of steps to take before halting.


>
>
>
>> I know we're not using script error levels for much currently, but I
>> expect they will be more important in future (in particular, I'd like to
>> add a script error log where you can see warning messages without them
>> causing annoying notifications). Don't use serrBound for new script
>> commands. Use serrBadOp. That's already the default for get_valid_npc_id.
>>
>
> Ah, thanks! I'll fix that. I copy-pasted those serrBound lines from some
> other command.
>
>
>
>>
>> pathfinder_stop_when_npc_reached won't work if the dest npc is just over
>> the map edge.
>>
>
> Oops! Good catch.
>
> I should write a xypair_wrapping_manhattan_distance() function that
> checks gmap(5)
>

xypair_manhattan_distance seems like a crazy name to me; why not
manhattan_distance?


>
>
>>
>> I'm rather amazed that it's possible to define constants with names npc
>> and pos, which are used elsewhere as variable names...
>>
>>
> I think it only works because they are in the scope of the ENUM, and I use
> the full enum name when I refer to them.
>

> ---
> James
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170610/82c5251a/attachment.htm>