Yea you are on the same page as me, this is all stuff i've looked through over the last two days.
The thing about zone switching isn't so much how much we have in, its the logic required to know you have switched zones and require a new pull of data, therefore we could end up with stale irrelevant data from the last zone we were in (i'm think a few versions down the line with full 1-80 leveling and question), while there isn't a requirement to load all the data, its more making sure the data we have is useful.
The concept about sqlite -> php -> mysql was a server side check to filter out and leave the calculations to the webserver rather than put the strain on the CC/plugin/HB, means the PHP does the work and not the C#, i'm being very cautious about putting extra strain on the application itself as it could go horribly wrong.
Also as its a local copy we can cache only what we need to on moment of pull as its literially a 1ms lookup or something stupid rather than a potential lag on the webserver which causes a 5 sec pull time.
I could go about this four ways and leave the option in the config for user choice
1. Option to use local and share data out
2. Option to use local compiled data, dont share and dont update
3. Option to use local copy of complied web data
4. Read striaght from live data (which is riskier), this really depends on how much bandwidth it starts eatting up, webserver speed etc. etc. (using outlinged methods suggested for cached zone data)
That way it takes in all four, all of which run around the same code anyway so just a matter of an extra few functions and flexiable coding.
To avoid data pollution I was thinking of what you said, a userid that would be held in two databases, the first database would be the raw data split over userids (i.e. unique key over userid/npcid), meaning you have access to your own info, and as you said if someone is polluting you just need to remove everything across their userid, then an hourly cron would merge all that into a seperate DB meaning when we find corruption we wipe the data of that user then force the merge, this however would all require a user login to be setup which isn't going to be as easy as it sounds without hosting it locally on the HB website and linking it to your HB account (or if they create a script which is basically an "echo $sql[userid]" and I could rip out and cache on startup (as you can't start HB without a session open first).
I reckon I'm going to have something up and running in a few days, then i'll push out the code for suggestions, switching between local SQLite and MySQL isnt as hard as you think, its just a new namespace called and one or two function changes, so once the core is done if i decide one is better than the other then not much of a overhaul, seems most have been coded around the same ODBC syntax.
Appreciate the feedback as you've cleared up a few things in my head about switching between the two, the more thrown at me the more I can see advancements (feature creeping) in this, I'm just wondering now if there is any other DB that could be held internally besides mobs, like players, items, quests etc. etc. not sure if they would be any use, but the mob one is useful for additional AI.
As for MobInfo any other suggestions, thought of a few more like FrostResistant/FireResistant etc. would be handy for Mages so you know you need to alter your Rotation based on whether the attacks would work.
Very nice work. Whats the speed like when reading / writing to the database?
