add a module that will add a content tag for vanilla+roz and cop items

[Grahf0085]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my PR will be ignored.
• I understand I should leave resolving conversations to the LandSandBoat team so that reviewers won't miss what was said.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have tested my code and the things my code has changed since the last commit in the PR and will test after any later commits.

What does this pull request do?

It adds a module that will add a content_tag column to item_basic table. Items added to the game during COP will get a value of "COP". Items added before COP will get a value of VROZ. The list of items in the COP list were taken from the patch notes for each patch updated listed here: http://ffxi.somepage.com/news/highlights.php#Patch_Info

Items that received the VROZ content tag were all items that can be found discussed on various websites before the release of TOAU and NOT listed in the COP patch notes. Distinguishing between items that were added with ROZ and those that were in the game from the start was too challenging. So they are lumped together.

If people want to they can add a content tag for TOAU, WOTG, or whatever expansion.

With this information someone could remove items from the AH if they aern't in the era they are stuck in, remove items from mob droplists that aren't in the era they are stuck in, and remove synth recipes that aren't in the era they are stuck in.

Steps to test these changes

A couple example queries that can use the new content_tag in item_basic.

Find synth recipes out of target era:
SELECT item_basic.name from item_basic
INNER JOIN synth_recipes ON synth_recipes.Result = item_basic.itemid
WHERE item_basic.content_tag = 'UNKNOWN'

Remove items from the AH:
SET aH = 0 WHERE content_tag = 'UNKNOWN';

You can also use it to find items mobs drops that are out of target era.

[zach2good]

We don't use VROZ as a concept anywhere else in the codebase. In npc_list we have content_tag varchar(14) DEFAULT NULL,, which is NULL for the base edition of the game, which is Base + ROTZ. If we take on a change like this, that's the convention we're most likely to accept.

I think it would be reasonable to add content_tag to item_basic in the main codebase (no modules needed, and no migrations needed because this is static data), and then we can have settings similar to ENABLE_COP, RESTRICT_CONTENT etc. (or reusing them completely) that things like synth recipes can plug in to.

[zach2good]

See IsContentEnabled in the codebase for how we restrict NPC by content tag, etc.

[Grahf0085]

See IsContentEnabled in the codebase for how we restrict NPC by content tag, etc.

I would love to do this with items. I'll look into it.

I saw how NULL is used in table like spell_list for content tags. I don't know how you distinguish between something that isn't known yet and a Base + ROTZ item then. Because there's a lot of items. I cover around 7000 of the 22,561 I see in the database. Labeling the Base + ROTZ items as NULL makes them the same as everything past COP right now.

[zach2good]

I'm told that ASB has a module that adds content_tag instead to synth_recipes, which I think would be preferable. Catch up with them and see what they think

[Frankie-hz]

We were contemplating adding content_tags to ASB a while ago but the question we asked ourselves was: "Do we actually need this?" and we came to the conclusion: no. Instead we added content_tags to a lot of other sql like synth_recipes (to be ported soon) and mob_groups (also to be ported).

Adding content enabled to items may be a lot of work so before you go and do all of this can what you want be handled a better way? Do you have an outline of what exactly this will acomplish? There may be a better way to approach this instead of adding content tags to 22,089 items :)

If its just droplist items we can make a module to modify just those droplist instead? That is what we decided to do.

[Grahf0085]

We were contemplating adding content_tags to ASB a while ago but the question we asked ourselves was: "Do we actually need this?" and we came to the conclusion: no. Instead we added content_tags to a lot of other sql like synth_recipes (to be ported soon) and mob_groups (also to be ported).

Adding content enabled to items may be a lot of work so before you go and do all of this can what you want be handled a better way? Do you have an outline of what exactly this will acomplish? There may be a better way to approach this instead of adding content tags to 22,089 items :)

If its just droplist items we can make a module to modify just those droplist instead? That is what we decided to do.

It seemed like the easiest way to catch all items that I didn't want on a server. It can be used to filter items out of any other table by joining them. It's the "single source of truth" for items that are spread across multiple tables like droplists and synth recipes and the auction house. If a synth recipe or mob drop or auction house listing or NPC sell an item without a content_tag from item basic table then they're easy to remove by joining the tables. Otherwise you're looking at four different tables to make sure certain items aren't available. If an monster only drops items with a content_tag that you don't want then you can be certain the monster is OOE. If a synth recipe has one item OOE you can remove that recipe by joining that table to item_basic. It's what I prefer and I'm confident my list is the most accurate out there but to each there own.

[zach2good]

Does a catch-all tag work though, and is it really needed? An item would be entirely unobtainable if the content that produces it is properly marked with the relevant era and restricted (synth recipe eras, droplist eras, etc). Then they'll never even make it to the AH, etc.

If a server's AH is being stocked by a bot, then it's their responsibility to make sure only relevant items are being listed - nothing to do with us and we shouldn't be on the hook for restricting it.

Synth recipes aside, I'm fairly sure all of this information is loaded in on startup so there isn't a search across multiple tables.

Synth recipes should be loaded into memory on startup too, that's an important work item for someone.

[Grahf0085]

So I can port over the content tags from ASBs various tables to LSB?

[zach2good]

Do we need this PR anymore? We got ASB's content tags for synth_recipes sent in last week, and a couple of other synth recipe improvements: https://github.com/LandSandBoat/server/blob/base/src/map/utils/synthutils.cpp#L304-L314

If you know any important recipes that might need to be tagged as certain eras, it might be worth you going through synth_recipes to see if what we have matches your notes.

For content and droplist-related items, does this apply more to BCNMs/Instances/HNM-type monsters, or NMs, or regular monsters? There's different ways to alter/revert those droplists to remove OOE things. A catch-all on items would leave those lists potentially empty instead of swapping them to what they were previously.

[Grahf0085]

Do we need this PR anymore? We got ASB's content tags for synth_recipes sent in last week, and a couple of other synth recipe improvements: https://github.com/LandSandBoat/server/blob/base/src/map/utils/synthutils.cpp#L304-L314

If you know any important recipes that might need to be tagged as certain eras, it might be worth you going through synth_recipes to see if what we have matches your notes.

For content and droplist-related items, does this apply more to BCNMs/Instances/HNM-type monsters, or NMs, or regular monsters? There's different ways to alter/revert those droplists to remove OOE things. A catch-all on items would leave those lists potentially empty instead of swapping them to what they were previously.

I'll go through the synth recipes later on today. Thanks