fix(Core/Map): remove hackfix that blocked update of GOs beeing set active

[sudlud]

• this just broke the whole purpose of setActive(true) if the gameobjects is still not really beeing set active afterwards
• GetGridActivationRange() returns 0.0f for gameobjects anyways
• so CalculateCellArea() will result in the minimal cell area around the gameobject's position
• if the cell around the gameobject should not be updated, the gameobject should not have been set active in the first place

Changes Proposed:

This PR proposes changes to:

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

Issues Addressed:

• Closes

fun fact:
Battlefield::SpawnGameObject() sets all objects active after spawning them

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:

• 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.

[PkllonG]

What needs to be tested.

[sudlud]

What needs to be tested.

Well this should actually not have any negative impact at all.

It might increase cpu load slightly (maybe?) as all gameobjects beeing set active now actually are beeing handled accordingly in the map update.

So if there's no cpu load issues in a high population server for example, then this should be fine.

[sudlud]

Testing could also be done by assigning a custom gameobject script to a gameobject, do setActive(true) inside and e.g. print a log / error message in a loop.
When leaving the map where the gameobject is in, it should still update the script and print the messages.

Before PR, the script execution would stop until the player comes back.

[pangolp]

Can this cause additional load understand? Or did the translator misinterpret your words?

[sudlud]

Can this cause additional load understand? Or did the translator misinterpret your words?

It depends.

I didn't check the whole core to see which gameobjects are set active.
So any setActive gameobject will be handled as "active" correctly after this PR.
So on each map update, anything in the same cell as the gameobject will also be updated. It should be just one cell because the "activision range" of gameobjects is 0.0f.

So this might have a slight increase in load, but most likely right now it should not make any difference.

Also the "increased load argument" is irrelevant in this case, as the hackfix has to be removed in my opinion and if any gameobjects should not be set active, that's the topic of another PR.

[pangolp]

Can this cause additional load understand? Or did the translator misinterpret your words?

It depends.

I didn't check the whole core to see which gameobjects are set active. So any setActive gameobject will be handled as "active" correctly after this PR. So on each map update, anything in the same cell as the gameobject will also be updated. It should be just one cell because the "activision range" of gameobjects is 0.0f.

So this might have a slight increase in load, but most likely right now it should not make any difference.

Also the "increased load argument" is irrelevant in this case, as the hackfix has to be removed in my opinion and if any gameobjects should not be set active, that's the topic of another PR.

Thanks for the reply. Honestly, I don't have enough knowledge to make a decision on a topic like this. I prefer that another colleague look at it. I trust his judgment to make the decision, but I would be calmer if someone else reviewed it for me.

[PkllonG]

CPU usage is doubled

[Nyeriah]

Objects shouldn’t be set active indiscriminately and should also be set inactive once they’re no longer in use. Higher resource usage is likely due to indiscriminate/arbitrary use of the active flag. I still see no issue with this PR in particular, the faulty cases/bad scripting needs to be addressed instead