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

[James Paige]

On Sun, Mar 19, 2017 at 9:07 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 20 March 2017 at 15:51, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>> 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
>>
>
> OK, I guess we can worry about it later. Enabling backcompat bits for
> specific games would be a whole new thing. In some cases that would be the
> best way to handle back-compat problems. I think we can come up with better
> ways than predicating on the file name though.
>
>

Thats how I *wish* I had handled the FUABMX cumulative level-up bonus bug :)


>
>>>
>>>
>>> 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.
>>
>
> Looking forward to it :)
>
> I guess you'll recompute the A* path each step rather than hanging onto
> it? For exposing to scripting, this is something that wants arrays and
> garbage collection.
>

Yeah, hanging onto it doesn't seem worth the complexity. I am hoping I can
get it to be efficient for quick calculation of a single step.

I'll probably also have an option to choose the maximum distance that it
will search. For many games, I think just 2 or 3 screen-widths will turn
out to be enough for what people want to do, without needing to search
across a max-size map every time by default.

I would not expose it to scripting until after arrays are available in
scripting, but I will be keeping that in mind when I work on it.

(And even before then, people would still be able to script it a little bit
just by changing NPC movement types)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170321/d4ee86be/attachment.htm>