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

Fri Jun 9 10:33:20 PDT 2017

On Fri, Jun 9, 2017 at 10:25 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 10 June 2017 at 04:28, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> On Fri, Jun 9, 2017 at 9:12 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> Yeah, you have convinced me. I will use "stopnpc"
>>
>> I think I will implement the cancellation of "walk npc" in a way that
>> always allows it to finish already-started steps. If somebody actually
>> wants misalignment, they can use the npc pixel commands.
>>
>
> But! You convinced me that stopnpc might be a confusing name as people
> could expect it to stop movement-type movements too. If an NPC isn't in the
> middle of a walknpc command or pathfinding, then stopnpc would do nothing,
> even if the npc is pacing back and forth. (Also, "set NPC moves" sure is a
> strange and unintuitive command name). haltnpc, cancelnpc, cancelnpcwalk...
>
>

Good point. "cancel npc walk" sounds pretty good.

>
>>
>>
>>
>>>
>>>
>>>>
>>>> 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.
>>>
>>
>>
>> You know, I think you are right. I can't reproduce it anymore in
>> situations with only one npcs.
>>
>> I actually haven't implemented any npc scheme yet at all, right now it
>> treats them all as solid walls no matter if they are moving or not.
>>
>> distinguishing between moving and non-moving npcs is still on my to-do
>> list.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>> 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'll only decrement the retry count in the same situations that trigger
>> the cooldown timer
>>
>
> Ah, right. So the max-retries count would effectively be how long the NPC
> sits without going anywhere at all. If it keeps ditehring back and forth
> between two alternatives, due to the movements of other NPCs, it wouldn't
> count down.
>
>>
Yep. Dithering will probably ultimately happen less often than I feared

That is that case I hope to let people handle with the optional max step
count on "wait for npc"

>
>>
>>>
>>>>
>>>>
>>>>> 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?
>>>
>>
>>
>> Do I look like a man who dislikes crazy names? ;)
>>
>> But seriously, what if I make it a method of XYPair? Is there any
>> downside to doing that?
>>
>
> No downside... aside from being kind of novel.
>
>>
>> ---
>> James
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> 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/20170609/e5c09e06/attachment.htm>