feat(Core/Characters): Cleanup character item_instance and character_…

[Kitzunu]

…inventory guid gaps

• closes No odd acore_characters/item_instance guid in mysql #14605

This is defaulted to off with config.

It will reorder item_instance guid and update the responding in character_inventory at startup

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

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.

• Enable the config

• create characters and see guid gaps in item_instance

• restart server

• see that gaps are gone

• see that you still have your items

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.

[walkline]

I have concerns about large databases. I assume this will attempt to update every record. Imagine a database with 10+ million items - updating all of them at once would be extremely slow, especially with primary keys and indexes affecting the update process.

To me, this approach could work if performed occasionally, like once a year during scheduled maintenance, with downtime depending on the database size. However, I think it would be too slow to run on startup.

For startup, we could use a different approach, such as:

1. Identifying the gaps.
2. Taking the newest items (with the highest GUIDs) and using them to fill the gaps without modifying the others.

[walkline]

We need to do the same for mail_items, guild_bank_item, recovery_item, auctionhouse and probably some more tables (use a collective brain?).

[Kitzunu]

ah true they would all hava record in item_instance

[Kitzunu]

@Winfidonarleyan do you have any suggestions on how to improve it?

[Kitzunu]

We dont necessarily need to have it in the core. We could make a Python script for it.

The upside to having it on load is that it probably isnt safe to run it during runtime

[Winfidonarleyan]

@Winfidonarleyan do you have any suggestions on how to improve it?

This is db. I do not know how to make it better.

[Nyeriah]

Probably worth a disclaimer that this can slow down start up considerably.

[Nyeriah]

What we should probably do instead is implement proper guid recycle, not just for items but everything else, similar to how instances recycle IDs.

I think adding the procedure to start up like this is a bit self defeating. It would require a largely populated server for it to make any difference, but then again going through 1mil+ item entries probably slows it down to the point it’s unpractical on restarts

[Kitzunu]

The way guid is set today for objectguid is a variable on startup gets MAX() + 1 from DB and then the count is remembered coreside during runtime. And the cause of the gaps is due to temporary items are created when checking if it can be equipped which upps the guid count coreside.