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

Fri Jun 9 10:25:09 PDT 2017

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...

>
>
>
>
>>
>>
>>>
>>> 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.

>
>
>>
>>>
>>>
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170610/0a03c56e/attachment.htm>