🐛 Overlapping TriggerAreas defeat debounce mechanism

[StabbyCutyou]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

OS / platform the server is running (if known)

Server: Ubuntu 24.04
Client: Windows 10

Branch affected by issue

base
Running on 9b0a788, but have reproduced it as further back as e6e34bb

Steps to reproduce

Accept the quest "Flyers For Regine" in Port Sandoria
Exit to Northern Sandoria
Approach Villion (V) from below (F3, up on a balcony)
Enter his TriggerArea
Move slightly, notice it only writes 1 log line and does not loop
Slowly move towards Guilberdrier (G) (F3, on the lower level)
Trigger Gs TriggerArea, while still being within Vs
Log is immediately spammed with Gs phrase once, then Vs trigger phrase on loop

The spam stops once you are out of range

Expected behavior

You can be in multiple trigger areas at the same time with the debounce mechanism (not firing if you're already within the Trigger Area) working correctly for each.

Notes

The design of this seems to be shared across Zone and Zone Instance fwiw. I notice that some of this code changed very recently, could be related, or could be a red herring given it was a large refactor and a lot of things got touched.

What looks like is happening is that when the trigger area check fires, and you are both:

• In an existing Trigger Area from the prior call
• Have just entered a new Trigger Area in this call

The second TriggerArea in the list (not necessarily the 2nd one you entered, afaik) is stored on PChar each loop while you're in both, resulting in the first one always firing the action for OnTriggerAreaEnter, because it will always fail this check. Since m_InsideTriggerAreaID is only ever set outside the loop, it only ever stores the last one it encounters, meaning earlier triggerAreas in the list will always fire.

The logs from the server reveal that the char suffers a massive packet backlog as well. Those should show a clean zone into Northern Sandy, approaching V, seeing the trigger, my putting something to into say to demarcate, then entering Gs trigger area and getting the flood.

The logic inside of that function is not what I would have expected, as I would have assumed you would want to record the zone as you enter it, and not as you finish the loop checking for all entries, among other things. That said, if the idea is that you can only be in one zone at a time, any choice is fine so long as it is consistent.

If this is the intended behavior, and it's just this quest that needs it's own internal debounce, that could be a quick solve that feels similar to the Castle Z teleport fix that went in recently. But I wanted to raise it as a possible bug before trying to put a fix in for it, as it does seem like the code that uses m_InsideTriggerAreaID is designed to expect a single area only.

It could also be that what is actually needed are events for both entering an area, as well as existing inside of one on a tick, since both have valid applications.