[Ohrrpgce] SVN: james/8551 Clean up perform_npc_move() refactoring the collision detection for wall

James Paige Bob at hamsterrepublic.com
Sun Mar 19 19:51:03 PDT 2017


On Fri, Mar 17, 2017 at 9:46 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

> There's no need for the npc_collision_check overload without the
> hero_collision_exception argument, because FB lets you make byref arguments
> optional, by giving them a default value. That results in a temporary
> variable getting initialised to the default value and passed to the
> function. I do this in several places. One of those little things I like
> about FB.
>

Cool! I'll fix that. I didn't realize (or had forgotten that) I could do
that :)


> I see you made a small back-compat breaking change here, by changing the
> determination of NPC tile X/Y position for the purpose of wall/zone
> checking, using the center rather than the top-left of the walkabout. Of
> course, this only happens when the NPC finishes a step, so there's only a
> difference if the NPC is mis-aligned, in which case collision checking is
> quite broken anyway. I wonder, does any game actually rely on that
> brokenness? It seems unlikely actually. I tested Siv: journey of an egg and
> didn't notice any problems.
>

I am slowly working my way up to fixing the getting-stuck-mid-tile bug.

Even though it is technically backcompat breaking, we have not yet
identified a single game that relies on the bug. If we ever find one, I'll
dust off the old code, wrap it in a backcompat bitset, and turn that bitset
on with some kind of IF gamename = "game_that_needs_to_be_broken.rpg" check

>
>
> Actually I don't think that change to using the tile center helps at all;
> it's still going to be broken. I suggest fixing misalignment by walking
> NPCs/heroes less than 20 pixels (whether by walknpc or builtin movement) so
> that it realigns at the next tile boundary, and doing collision checking
> like a pixel-base-moving NPC/hero until then.
>

Yeah, I know that doesn't fix anything, I still figured it was more correct
to determine which tile's walls to check based on the center rather than
the top left corner.

Yes, that does sound like a good plan for fixing misalignment.


> Script commands would be great. I think there are two approaches: high
> level "do NPC/hero obstacle checking exactly like the engine does" that
> might be useful for scripting eg pathfinding, and could be affected by a
> pixel-based-movement option, or low level "check for collisions with
> walkabouts" that would be a building block for scripting your own movement.
> So there could be commands for both, if they would actually get used. But
> maybe the latter would not get used enough to bother... I know recently
> I've said several times "use the wall checking commands and do your own
> collision checking with 'find colliding slice'", but have have to look into
> those specific use-cases actually were.
> Plus, unfortunately the wall checking commands I added recently don't
> support NPC zones or one-way walls.
>

The other thing I am doing (besides chipping away at the tile misalignment
bug) is to add a couple new NPC movement types.

Specifically I want a less random version of Chase and Avoid. I have one
that is *almost* working but I still need to clean up some edge cases and
test it better.

I also definitely want a movement type for follow-right-hand-walls and
follow left-hand-walls which will allow for some pretty fancy NPC movement
using just zones and no scripts.

I have also been thinking about full-on A-star pathfinding. but won't dare
touch that until I have the other stuff working.

---
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170319/0e398587/attachment.htm>


More information about the Ohrrpgce mailing list