[l0stmancd]

Hi Trevius,

Thanks for taking the time to review this.

The lore conflict may simply be confusion on my part. I was under the impression that a lore augment was simply an augment that could not be in an item twice. The client itself and other server checks have already determined if a user can hold two of an augment (in hand, etc) by the time the user has them. This check was simply to guarantee there would not be another of the same lore item (or lore group) in the item they are augmenting. If the game should not allow two of the same lore augment -anywhere, in any augmentation slot, on any item - then we should definitely remove the check lore augment code and move to the CheckLoreConflict code. Mind you - this may be unnecessary since by the time the user has two of these same lore augments, the CheckLoreConflict should already have been called (which is why it does not exist in the augmentation procedures as they are in trunk).

Regarding the database query? You are absolutely correct. Can remove this function and switch to the following code snippet.

				for(uint8 ctr = 0; ctr < MAX_AUGMENT_SLOTS; ctr++) {
					ItemInst* augToRemove = toBeAuged->GetAugment(ctr);
					
					if (augToRemove) {
						if (idOfAssumedSolvent == augToRemove->AugDistiller) {
							slotToRemove = ctr;	
							break;
						}
					}
				}

Holding off on fixing those and resubmitting until I understand your last note.

If it is possible to change this to work as a hand held augmentation pool (with item select, etc) this would be a good fix as long as it would handle zone server crashing. I am afraid, though, I am not familiar with how you would do that. If you do not have time to look into this, would you mind giving a two sentence explanation that I can take and dig into?

I agree that this fix is not perfect in so far as you could not select which augment to remove (just the first one it finds of a given type that has been inserted) but it would fix an issue that is causing problems now. That said, given that this would be an optional rule and does not seem to pollute the code surrounding tradeskills / augmentation I do not believe this would be hard to revert out if there was a better solution in the future. I will gladly spend the time to fix any issues you see / think can be improved here if you would still consider the concept for submission. If it would be easier, I can create a set of much smaller diffs that show the code progression more obviously.

Let me know - Took off work until Tuesday of next week and will gladly spend that time working on this.