Augments Deleted?

[KingMort]

Happening to weapons and armor btw... anything augged with more than 2 augs the 3rd gets deleted..

Could you tell me where in the code augments are being handled like this ??

Perhaps I can see if we are missing something or something looks off..

[KingMort]

Can anyone shed some light onto this or point me in the right direction in the code??

My server is DOWN until this is figured out and my players are going crazy...

King

[Shendare]

In case this turns out to be an elusive problem to track down, would it be preferable to have the server up but inform players about the issue?

"Third augment slots are currently broken. Do not try to use them, or your aug may be lost. The problem is being looked into, and as soon as third slots are working again, every effort will be made to restore augments that have already disappeared."

It sounds like the server knows the augment is still supposed to be there, since it's giving the LORE message.

- Shendare

[dune157]

I support you mort! We want our server back someone help!!!!!!

[gaeorn]

If you look closely, the lore message was when he tried to summon the second augment. When he summoned the missing third augment, it did not give the lore message. So it appears the augment is truly being lost.

[KingMort]

Yeah can't take the server up even with a warning there are TONS of people who have 3rd and 4th aug slots filled and as soon as they log on then they are deleted....

This may end up with a small rollback :(

[ndnet]

Believe we got this fixed.

In common/shareddb.cpp: SaveInventory -

The query builder sprintf format references %lu, long unsigned integers. Above this code the array of augments is init'd as uint32. On a 32-bit system this is correct, but on a 64-bit system it appears to be giving overflows, resulting in the database getting filled with the max value for the column (default is 0 so it's not just spewing nulls).

Casting the augment item IDs to (unsigned long) in the MakeAnyLenString query build results in correct behavior. We may need to look further into our defined basic datatypes and more closely at the compiler warnings (this was one of them) to ensure the trunk operates on both architectures equally.