Quote:
Originally Posted by Derision
It's up to KLS as to what goes into the code, however if it was me, I would think about adding a vector<int> KeyRing in the Client class and load all a client's keys into it in Client::FinishConnState2.
That way the only time you need to access the database again is when a new key is added to the keyring, so I would do a KeyRing.push_back(NewKeyID) and then INSERT into the keyring table at that point.
|
A std::list would be slightly more efficient, and just use the iterator because we don't need the vector's ID anyway. You can still push_back onto the list, although a clear() and select from DB may be safer, if itemID doesn't exist in list. The iterator is faster than accessing via an increment on the vector ID, but vector inherits from list anyway so I can use it if I can think of some need for ID..
Still stuck on testing zone flag, but I think if u can just #flagedit and give somebody the zone flag whether by item use or quest, then I don't need to worry about it. I'll probably spend this time to improve database usage with your recommendation.
Threaded Mode
