fix(engine): walktrigger env settings and moveClickRequest changes

[tannerdino]

• adds ~playerwalk3 proc
• adds NODE_... setting for where walktrigger is ran in the world cycle. 0 = processed in packet handler. 1 = processed in player setup (client input). 2 = processed in player movement. For setting 0, path is set in the packet handler. For settings 1 & 2, path is set in player setup.
• defaults both path to be set and walktrigger to be processed immediately in the packet handler. In the span of OSRS's lifetime, the location of where walktrigger was processed for yellowx was changed from: packet handler -> client input -> player movement. Videos: May 4, 2013 OSRS (before server pathing update), Oct 17, 2016 OSRS (after server pathing update)
• p_op and p_walk should not set moveClickRequest, and moveClickRequest is reset on login. If a queue is pending, you will not move when placing the cannon, unless moveClickRequest is false. In osrs on login, without moving, you will walk with the cannon just fine. But once you yellowx, your next cannon + queue will prevent movement for the length of the delay.

Cannon + pending queue (notice how I stop moving as soon as I turn on prayers):

2024-11-20.16-25-44.mp4

2024-11-20.16-26-21.mp4

Cannon + pending queue after logout:

2024-11-20.16-28-09.mp4

2024-11-20.16-28-37.mp4

• set moveClickRequest to false on opheld and opheldu null interactions, to match early osrs bug abuse videos such as: https://youtu.be/GPfN3Isl2rM (smuggles games room effect, which clears on engine queue). This could theoretically work with other items like books (as long as it doesnt clear movement) - todo: find proof of items that work other than dueling ring as shown in the linked video.

• only remove the flag on the map for op packet errors. Null obj example:

2024-11-20.17-35-08.mp4

[tannerdino]

Is NODE_WALKTRIGGER_SETTING in .env the right approach here? We'll probably never have it set to anything other than 0, since Lost City, the project, will probably not do OSRS revs. But it could be nice for server owners who want to match certain OSRS updates?

If the goal of this engine is to be very general with the ability to match different eras with env settings, then I guess a NODE_WALKTRIGGER_SETTING is good

[Pazaz]

Is NODE_WALKTRIGGER_SETTING in .env the right approach here?

I think it's a fine approach, basically the same as a config file and we can pre-make template .env files for future eras.

My only concern, if we have it as SETTING=version... what if we discover a "new version" change in-between? I'm thinking generally since we would want to keep the same convention for other feature flags.
Adding to the end could be confusing, and shifting everything might break people's setups. Keep it as-is for now but keep that in mind... maybe I should come up with a tryParseEnum for this case.

[ultraviolet-jordan]

if ur doing this then u can delete this:

    clearWaypoints(): void {
        super.clearWaypoints();
    }