fix(Core/Threading) Refactored Map class - changed i_scriptLock to mutex and some code optimization

[nl-saw]

Changed i_scriptLock to mutex and some general code refactoring

Changes Proposed:

• Changed i_scriptLock from bool to mutex
• Removed unnecessary iteration
• Some code cleaning

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Scripts (bosses, spell scripts, creature scripts).
• Database (SAI, creatures, etc).

Issues Addressed:

• Closes

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

No functional changes have been made. The changes primarily involve code refactoring aimed at potential performance improvements, with enhanced code structure and more stability.
There should be no issues or deficiencies resulting from these changes.

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

Known Issues and TODO List:

• [ ]
• [ ]

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[Takenbacon]

I do have a couple possible concerns but it's super hard to review off my phone, will try once I'm back in town.

Main one being with merging the two loops, sessions and player objects are destroyed in the session update, which means adding the player update after might be pointing to invalid memory. I see it retains that odd "optimization" with checking for t_diff so it may not be consistent

[nl-saw]

Take your time, no rush. All logic should be exactly the same apart from _creatureRespawnScheduler.Update(t_diff); now being called after the player update, which seems harmless to me.

[Takenbacon]

Ok I had time to glance at it.

You can ignore my first comment, I forgot session/player deletions are handled in "unsafe" context (world update) so there shouldn't be any issue with player being deleted during the map session update.

As for i_scriptLock, I suspect (but I am not 100% sure) the original intention looks to be to prevent recursive calls rather than actually a threading/mutex protection. With a standard mutex a recursive call will deadlock.

[nl-saw]

I checked the files making use of i_scriptlock. The only recursive call I found is

bool Map::HasEnoughWater(WorldObject const* searcher, float x, float y, float z) const
{
    LiquidData const& liquidData = const_cast<Map*>(this)->GetLiquidData(searcher->GetPhaseMask(), x, y, z, searcher->GetCollisionHeight(), MAP_ALL_LIQUIDS);
    return (liquidData.Status & MAP_LIQUID_STATUS_SWIMMING) != 0 && HasEnoughWater(searcher, liquidData);
}

Could this be problematic in your experience?

[nl-saw]

My last comment was a mistake, it was an unnecessary overload instead.