Finally had a chance to review this code a bit. I think it is a good idea, but not sure I follow the code enough to commit it myself.
I am not really sure why you check 10 slots in this function (and a few other spots):
Code:
bool ItemInst::WillAugmentCauseLoreCollision(ItemInst* newAugment)
Max aug slots on an item is currently 5 slots and if anything, should be coded to use the defined value for max aug slots, "MAX_AUGMENT_SLOTS". The only thing I can think of that would run through 10 slots would be bags. I don't really know the goal of this function. I would think you could just use CheckLoreConflict(), but maybe I am missing something here. Aug Lore checks should be done against the entire inventory, not just per item. I haven't looked too in-depth into it, though.
Also, I don't think the DB query you have is required. You should be able to pull that info directly from shared memory, I think.
There were a few other things I am not quite clear on yet, but I don't really want to go into each one.
As it is currently, I think this could probably be done in a different and maybe more user-friendly way. With the limitations of how this is coded (such as you can't select which aug slot to remove), I think it might be a bit too much of a hack to make it into the SVN. Even though it would be another hack, I think this could be done by tricking the client into thinking it is interacting with a real aug pool. It would probably take more work and innovation to make it work as I am thinking, but I think it may be possible to trick the client into using a bag as a real aug pool. I can imagine how to do part of it (may only work for SoF+ clients though), but the part I am not sure of offhand is how it would actually be saved in the inventory in the case of a crash.
Sorry, I don't mean to shoot down your submission, but if something like this was added, I just think it would have to be done a bit differently.
Threaded Mode
