John Adams wrote:Guys, correct me if I'm wrong here...

Currently, LoginServer has tables for character equipment `appearances` - that is, it stores 1 record for each equip_type, it's RGB+HighlighRGB, and what slot it's in. Once I get the update working, it would push 1 record for every "visible" slot on a character so they can see what they're wearing at character select... that's the mission.

But here's what just dawned on me. If I have an `item_appearances` table on Login, shouldn't I just need the equip_type value and what slot it's in? And not store (redundantly) all that appearance data? Meaning, my equipment table could merely have character_id, equip_type, and slot. Then let Login go fetch the RGBs from it's own local appearances table.

-- This would be the easiest approach and less of a load on mysql. This will also allow an easier time of color changes from dye and such. So pretty much upon login, mysql would fetch the data, read it, then fetch the corresponding data from the table appearances with the id given. Much easier then reading the data from point a, to reread from point b to jump back to point a to display point a.


Then of course, it just now occurred to me while writing this post - how would we handle Admins who make their own items, own appearances, without storing (locally) every item_appearance for each given world, like we do with custom zone names...

-- There isn't really an honest way around this I do believe, I'm not 100% sure you could do it without storing the data. Then again I may have read the question wrong.

Sigh. Where are the big brains when I need them? I'll stick with tackling a normal-case scenario first, then we can expand to custom world items should the need arise.

Gilraak wrote:This will also allow an easier time of color changes from dye and such.