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

[James Paige]

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.

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.


> 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



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


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170609/487d37fc/attachment-0001.htm>