Swap Item: Invalid slot move from slot 2.9 billion to slot 2.9 billion

[l0stmancd]

See image http://imgur.com/8GqoP.

Trevius added code a while back to (revision 1272 March 01, 2010 to /trunk/eqemuserver/zone/inventory.cpp) to fix an issue where SoF+ clients would spam a slot move 3billion to slot 3billion every 10 minutes like clockwork. Appears to be happening at slot 2.9 billion now. Observed by myself and another user while playing. Both of us were using SoD. We had not seen this defect before but it started happening in the last ~3-4 days. I reviewed the recent checkins and I do not see any reason for this to happen so I assume its just a client quirk.

Not posting this in the code submissions forum since I do not know enough about this area to know if there is a problem with this fix but it -seems- quick and easy to fix. Just moving it from a > 3billion check to > 1 billion check. Honestly, even a billion is pretty far out there and should never be hit in normal circumstances but want to keep in the same order of magnitude as prior submission.

Index: inventory.cpp
================================================== =================
--- inventory.cpp (revision 1806)
+++ inventory.cpp (working copy)
@@ -798,7 +798,7 @@

if(!IsValidSlot(src_slot_check)){
// SoF+ sends a 3 billion+ to/from slot every 10 minutes. Don't warn for those.
- if(src_slot_check < 3000000000)
+ if(src_slot_check < 1000000000)
Message(13, "Warning: Invalid slot move from slot %u to slot %u with %u charges!", src_slot_check, dst_slot_check, stack_count_check);
mlog(INVENTORY__SLOTS, "Invalid slot move from slot %u to slot %u with %u charges!", src_slot_check, dst_slot_check, stack_count_check);
return false;
@@ -806,7 +806,7 @@

if(!IsValidSlot(dst_slot_check)) {
// SoF+ sends a 3 billion+ to/from slot every 10 minutes. Don't warn for those.
- if(src_slot_check < 3000000000)
+ if(src_slot_check < 1000000000)
Message(13, "Warning: Invalid slot move from slot %u to slot %u with %u charges!", src_slot_check, dst_slot_check, stack_count_check);
mlog(INVENTORY__SLOTS, "Invalid slot move from slot %u to slot %u with %u charges!", src_slot_check, dst_slot_check, stack_count_check);
return false;

[trevius]

Yeah, I could never figure out exactly why it sends that move item packet like that. From what I recall, it counts down by 960 (IIRC) every time it comes in. I thought it started at the same value every time a client logged in, so they would had to be logged in for months for it to get below 3 billion. Since that was extremely unlikely, I just set it to that. Apparently it doesn't start at the same value each time and instead it sounds more like it is related to something like a unix timestamp.

I would prefer to figure out why it is being sent and handle it correctly, but since it doesn't break anything to ignore it, that should be ok for now.

Some of my thoughts on what it might be:

1. Maybe something related to food/drink consumption. Though, I kinda doubt this since food/drink is already handled in other packets just fine.

2. Could be some type of inventory check, that forces the server to make sure the client and server are in sync somehow.

I would like to see what Live sends when they get this packet. Maybe I have one in one of my packet collects somewhere. It would be interesting to see what a reply (if any) would be like.

Either way, that patch should work for now. We can get it on the SVN ASAP.

[trevius]

Heh, I think I figured out something in relation to this packet.

I took the current unix timestamp from here:

http://www.unixtimestamp.com/index.php

Then, I subtracted that from the max unsigned int value of 4294967295.

This gives (for the time I ran this at anyway):

4294967295 - 1294998975 = 2999968320

My thought is that when you log in, it starts sending this reverse timestamp value. I don't know why it sends it, as that info is already handled in the player profile for /played time, and I also don't know why it would need to keep sending it. Maybe they want to make sure people aren't changing their system clocks while EQ is running to prevent some weird hack? It doesn't make much sense to send these in a Move Item packet, unless they want to prevent a hack, since you wouldn't want to block that type of packet.

Another example of this is that my lead GM, Kayen, reported seeing the value 2999989548 sent to him tonight. I checked that using this same simple math and here is the result:

4294967295 - 2999989548 = 1294977747

And using the conversion tool I linked above, that converts to this:

DATE: 01 / 13 / 11 @ 10:02:27pm

Which I think is the time that he logged in.

I can't think of any use we would make of this currently, but I will note it in the source and then apply the patch to prevent the error from happening.

If anyone can think of a reason why they might send these reversed timestamps, maybe we can handle them appropriately (if needed).

[lerxst2112]

Well, the struct has the fields as unsigned ints. If they were signed then the normal slot numbers would be positive and these timestamp values negative right? It seems like it'd be an easier check to say if(slot < 0) ignore it.

[trevius]

Oh yeah, duh. Dunno why I didn't realize that lol. I will get this in as l0stmancd posted for now and we can do struct change stuff later sometime if needed. (as it may require more work).