If he's talking about the tags meta names so: I think that the Iku.... is the longer tag but we can just name the tag as Iku is it's good for everyone, we can akso short some of the shops names and others like MC, CS, CrystalS, GOO, BLoot, Baking, FGift, BHH, TS and so on.

The notes of the tags are longer and it's really depends on the tag and the item.. battle loots for example is long and if the challenger is also long it can be 2.5 rows of a note..

I hope I didn't make it more confusing "^_^

As I understand it, basically the note will be broken up into two parts, one standard (Kathy's post at Posted on: 09/25/16 at 8:37pm, shows a good sampling - just the word part though, not what's in parenthesis).

So longer ones would be: Blackheart Hollow Achievement Prize Ikumoradeekanox Tree

We can shorten them, but I don't think we should. Or if we do shorten them, they could be tags we use to type in, but the item info would use the full name. Like we type in "bhh" but it shows the full "Blackheart Hollow" in the new notes.

Then the second part of the note contains info that changes - so for example: Part 1 = Morostide, Part 2 = 2016, Trick or Treat Item Part 1 = Morostide, Part 2 = 2016, Pumpkin Patch Item Part 1 = Tranformable, Part 2 = link to what it transforms from and into. Part 1 = Ikumoradeekanox Tree, Part 2 = nothing

, please correct me if I have this wrong.

Everything that Lypsyl said! I think you said exactly what was happening in my brain. <3

Hm, I feel like with a two part tagging of tag and then related notes, another table on the item page would be unavoidable as osterizer laid out. Sure it could be reorganized to look like normal notes... but then is that any different than the current notes? I was thinking more along the lines of how youtube does tags.

Morostide, 2016, 2015, Trick-or-Treak, Pumpkin Patch, Transformable, would all be individual tags. Then in the item notes, you can say "Transforms into: "

The idea is that for recurring categories/tags, you have "less" to type in the notes, instead you would select a bunch of different "somewhat standardized" tags. For administration of items, you would have a field for attaching tags, as you type, it would suggest tags which you can click and attach to an item or create your own new tag.

This is more of a organizational upgrade that is less reliant on having the item notes containing some keyword and instead can group things by tags. You will still have to add notes for things that require special mention...

But maybe that does not solve anything... let me know what you guys think from a user/admin perspective. This is great feedback!

- I hadn't thought about how YouTube tags work! :o I'm assuming the tags would be clickable and it would bring up a list of all of the other items that have that specific tag attached. So, let's say that I want to see all of the items from Morostide 2015, but specifically from the Pumpkin Patch. How would I go about doing that with the new tag system as a user? Right now, it's easy to search notes for "Morostide 2015 - Pumpkin Patch" and it would bring up all of those items. With the tags how you're suggesting them though, would I have to click three different tags ("Morostide", "2015", and "Pumpkin Patch") and then cross-reference? That seems like too much work for a user to do. If that is the way the tags are going to work, it would seem to me that we need the tags to be more specific.

LOL we are thinking very alike on this topic.

The point of this tag system is to make the notes more consistent. Can't speak for what intended, but the way I see it there are a few goals here:

1. ease of use for our users.

If a user wants to be able to see a list of all the fruit that can be picked from the Ikumoradeekanox Tree, they should be able to get a list without extraneous items that have Ikumoradeekanox in the notes for a reason that does not include it being a fruit that grows on the tree.

They should be able to create a user generated checklist that includes several tag options: All Morostide items for all years. All new Morostide items for the current year. Morostide for the current year, but limited to the pumpkin patch. Morostide for all years but limited to what was/is available through ToT. New Morostide food items.

2. easy for us to enter

Yes, to make our work easier, but more than that to keep it consistent so user generated lists and checklist actually contain all the info they need. If we all spell Ikumoradeekanox Tree differently, then a generated list isn't going to have all the fruit on it.

3. More ways to limit checklist info.

Currently we can only limit checklists by restock location and name. For most needs this works well, but when you get to the "does not restock" category its a hot mess trying to figure out where the items come from - are they genetech, token shop, morostide? You don't want to spend hours on one item trying to track it down, you want to group a bunch of items together and get those taken care of and move on to the next.

I guess what we're looking at here is what is possible from a programming perspective. Making it both user friendly and easy for staff to enter.

I'm quoting these out of order:

Custom checklists can be based on a substring of the item notes, but it was my experience while creating the Genetech Combo page that the Legendary weapons (which are Genetech 'ingredientes', not combos) still mentioned Genetech in their item notes, so they were showing up in my searches. I see tags as a way of getting these custom searches to be 'exact', without false positive results (like the unrelated Ikumoradeekanox items you mentioned).

I don't want to be too presumptuous about how what's possible with the programming, because I don't know what's already out there, but here's how I'd attempt doing this.

Create a table TagLibrary that describes what the tags are with three fields:

tag_id (e.g. "") tag_short_description (e.g. "Secluded Shrine Scroll") this would show up on the admin side in dropdown lists, etc. tag_syntax (e.g. "To create this scroll, bring the following items to the Secluded Shrine: %1") this would be the user-facing item note corresponding to the tag, with a placeholder for replaceable elements in the note.

Create a second table ItemTags containing all of the tags which are used:

item_id (e.g. 191021) tag_id (e.g. "") replaceable_content (e.g. "April 3, 2015")

No tag content appears in the primary item table -- the advantage of this is backward compatibility; we shouldn't have to adjust any pages that aren't "aware" of item tags until we're ready to do so.

When we're ready to display an item's tags, we'd run a query like:

SELECT item_id, tag_syntax, replaceable_content FROM ItemTags INNER JOIN TagLibrary On ItemTags.tag_id = TagLibrary.tag_id WHERE item_id = current_item;

That would get us all the tags for the item (we could avoid the join by storing the tag syntax with every tag, but this increases our storage requirements). Then for each tag_syntax that has a placeholder in it, do a substr_replace to insert the replaceable content where it belongs.

It's not quite as straightforward as I described -- the interface design will be harder than the database design will -- but I think this is something that could be done.

So if I am understanding this correctly, it would be a way to make checklists that essentially exclude some of the results that show up in many checklists now. So if I want to make a checklist that has all the items using the word "doll" but I don't want custom wearables in my list, this would do it.

While I agree this is really important I think having all the items done is going to be a necessity before we release it publicly. Otherwise we are going to have a barrage of complaints concerning "undone" items.

OK, I think I get it. You want to preserve people's custom checklist that use the notes... so we'll have the tags associated with appropriate text which will display in the notes... Then the tags will also be listed somehow, which users can click on to view all tagged/categorized items.

Yeah it is some more work. I'm never much of a fan of string parsing and formatting as it leaves more room for error (I'm scarred by massadd!) But doable. I'll see when I have some more time to work on it.

That list can already be created as a custom checklist!

I'd imagine that "all the items done" will be a moving target since new items will continue to be released while we're working on this. May I suggest instead having a few common tags ready before releasing it publicly and soliciting feedback while we continue to work on other tags?

Duplicating the tag_syntax field would cause a small boost in speed because the needed information would be contained in a single table without the need to perform a join. On the other hand: if we ever had to update a tag, we'd have to update it in every record where it appeared instead of just once. (Can you imagine how much work we'd have to do with the item notes the way they currently are if, say, Subeta decided to rename the "Millionaire Center" to the "Billionaire Center"? I'd like to avoid having to do that with tags.)

Data-scraping is the worst, though, because you're designing the parser but have no control over the input being parsed (everytime they make a change you have to make one, too.) I hope this wouldn't be as bad!

Yikes!