The packet structure in the PlayerProfile_Struct
already uses uint32 to represent exp, and the database
already supports values this large.
Code:
pp->exp is defined as a uint32 in eq_packet_structs.h:961
row[r] is the field returned from the database query, returned as a char* from the indexing operator of MySQLRequestRow, but the actual numeric value coming in here from the database can't ever exceed the unsigned in32 max, because that's how the column is defined in the database.
atoi() returns a SIGNED int32; returning INT_MAX = 2147483647, if the parsed argument is > INT_MAX
See
https://docs.microsoft.com/en-us/cpp...l?view=vs-2017 for example of atoi behavior in this case.
It's taking a value (albeit as a string) that is already an unsigned int32 (from the database), running it through a function (atoi) that returns a SIGNED int32, and then storing it in an unsigned int32.
The atoi() function is what looks to be truncating the value when loading character_data from the database when the client connects to a new zone.
This doesn't look like any structs or packets need to be changed, just use a function that returns an unsigned int32, or since there doesn't seem to be one of those, use one that returns a signed int64, the return value of which will easily fit into an unsigned int32, since the input value (from the database) is already an unsigned int32.
I don't usually like the easy fix myself, and would generally agree there's got to be something more in depth wrong, but in this case, I really think that it's something that wasn't an issue when it was implemented. Given that leveling beyond 85 wasn't a big concern at the time,and depending on the current state of what is considered "end-game" development for EQEmu, maybe it still is not a concern--I just was putting it up here since I perceived it to be a bug that maybe one day would need to be addressed.
Threaded Mode
