Crafted flag DB change

[xinux]

Looking at the items in the DB i recommend the following changed for the crafted flag. When the crafted flag is set to 1 you get the text telling you "This looks as if it could be used fir crafting level x - x handcrafted items" . The problem is we have the crafted flag on profile, House containers, adornments, thrown, weapon, armor etc etc.

Using the following query's should limit the amount of items that this should not be set on.
1st Query changes all crafted 1 to crafted 0.
[code]
UPDATE items
SET crafted='0'
WHERE crafted ='1'
[/code]

2nd Query We need to set the correct items to crafted 1.

Code: Select all

UPDATE items
SET harvest='1'
WHERE item_type ='normal'
and (stack_count = '200' and novalue ='1' and notrade = '0' and flags2_64 = '0' and flags2_256 = '0' and flags_16384 = '0' and flags_32768 = '0' and heirloom = '0');

This now leaves us with 515 items flagged instead of the 42,286 items that were flagged.
There is still some items that i can't find a good way to not flag them cause we should only have around 246 items total.

[Jabantiz]

This is not a solution as the `crafted` field in the DB is for the Flags elements in the item struct, changing it will change the flags of the items, in this case it will show the wrong tier as the tier displayed relies on the crafted flag, I believe older clients even have a "Crafted" flag next to the tier.

EQ2EmuCrafted=1.png

EQ2EmuCrafted=0.png

Our problem is with the code we set the "Crafted" element in the struct based on if it has the Crafted flag, the element should be renamed to crafting component or something else as that is what it is for. It is possible that there is a flag for it in the Flags element the we haven't identified but we will probably have to add a new field in the DB to properly handle this element.

[xinux]

Well crap

[xinux]

This may be a stupid question but couldn't we just go off the creator_flag in the header instead? Since well if it is crafted it has a creator flag.

[xinux]

What do you think John?

[16:49] <Jabantiz> so add a `harvestable` field in the db, load it, and when the value is set...
[16:50] <Jabantiz> change the if
[16:50] <Jabantiz> if(CheckFlag(CRAFTED))
[16:50] <Jabantiz> packet->setSubstructDataByName("footer", "crafting_flag", 1);
[16:50] <Jabantiz> to if (Isharvestable())
[16:51] <Jabantiz> or whatever you want to name it
[16:52] <Jabantiz> then you can change the 2nd query you posted to set the newfield instead of crafted
[16:55] <@Xinux_Work> makes sense and probally the easist way
[16:58] <Jabantiz> less code changes
[17:08] <@Xinux_Work> Going to suggest that in the post for John.

[John Adams]

How are the items coming from SOE that differ from how we are sending them? I assume you looked into that as well. But yeah, if you need a column and it will make things easier, go for it.

Side note: I was staring at the many fields for Flags when was refactoring Parser, and considered turning them into bitwise values anyway... but that would have required a bunch of World changes I was not prepared to make at the time. Ie., 2 fields instead of 25.

[Jabantiz]

Implemented the code and put the table mod on the db patcher. For parser the only thing that would have to be done (as far as I am aware, never went to deep into the parser code) is to check the element "crafting_flag" in the footer and set the `harvest` field in the `items` table to the same value.

[John Adams]

check the element "crafting_flag" in the footer and set the `harvest` field in the `items` table to the same value.

I guess I am still a little confused. Why don't we just set the crafting_flag in the footer and get the same results, if that's how it comes from SOE? Obviously, I am missing something.

[Jabantiz]

"Crafted" flag that is set in the flags elements in the header is for items that are crafted

"crafting_flag" in the footer is for items used in crafting, it will cause the "This harvest looks as if it could be used for crafting levels xx - xx "

Either one can be set without the other being set.

A "tin cluster" for example will have the "crafting_flag" set in the footer but it will not have the value for "Crafted" set in the flags element in the header

[John Adams]

A "tin cluster" for example will have the "crafting_flag" set in the footer but it will not have the value for "Crafted" set in the flags element in the header

Okay, got all that. So, why do our "tin cluster" not just have the crafted set in the flags element in the header if we know those items can be used in crafting? Do you understand my confusion, or am I just making things worse?

Maybe someone who speaks "JA" should give it a go

[Jabantiz]

Crafted flag in the flag element in the header is for crafted products. Tin Cluster is not a crafted product, it is something you get from harvesting. This is how SoE set it up, if we set the crafted flag in the header it would change the tier and the item info would no longer match live.

[John Adams]

A "tin cluster" for example will have the "crafting_flag" set in the footer but it will not have the value for "Crafted" set in the flags element in the header

I think I see my confusion. This statement made me think "this is the problem", when in fact, it is the solution

I'm still not sure why the collected data from SOE would not have this info, but apparently I am not asking the right question. As long as it works, we can move on

[Jabantiz]

Collected logs will have the info. No clue if the parser pulled the data but it was never stored and used in the DB world uses. We set the "crafting_flag" wrong in the server core, so this was confusing back when this was all added as well. The element name itself seems to cause the most confusion.

[John Adams]

Indeed. Does this mean you need all Items re-parsed (with the parser fixed first) or do we just go manually change all the items flags settings as-needed? We can probably just add a simple in-game command to toggle that for items so it is easier to fix on-the-fly.

[xinux]

All the values in the new field should be 0 you can run this query and it will flag about 515ish items that is still about 200 more then what should be flagged but it is a good start the others we can just manually adjust as we come across them.

Code: Select all

UPDATE items
SET harvest='1'
WHERE item_type ='normal'
and (stack_count = '200' and novalue ='1' and notrade = '0' and flags2_64 = '0' and flags2_256 = '0' and flags_16384 = '0' and flags_32768 = '0' and heirloom = '0');

If you decide you want to reparse all the items you may want to fix this in the parser also.

OK i now have green stats like Ministration, Ordination, Parry etc etc showing up when you mouse over and or examine a item. This is not the correct way but since all the values in the DB are wrong it works.

For instance item# 85148 in the DB shows type 1 subtype 36 value 0 when it should be type 0 subtype 1 value 36 for ministration & Ordination.