Client-Server Item Desyncronization Bugs
Hello All!
I am creating this thread so that a thorough bug description repository and feedback forum will be available for me and others to use to troubleshoot and trace the source of client-server item desyncronizations. I have already researched posted issues both here and at www.peqtgc.com and have accumulated a small library. Most of what I have seen are the results of desyncronization and not the actual bugs themselves. I have been able to find, and reproduce with 100% accuracy, at least six desyncronization bugs. Some minor fixes have led to even more bugs revealing themselves. None of the bugs, that I have discovered, are exploits. However, certain conditions can lead to exploits or permanent loss of items. I will not give detailed information on what bugs lead to exploits and ask that anyone posting information not to give explainations of how to do so as well. We know that certain bugs can be exploited..we just need information about what led to the occurrence of the bug. If you choose to find a way to exploit these bugs, you will most likely be treated as a hacker by the GM's and Admin's of your host server and suffer any consequences thereof. As this is the EQEmulator forum, we cannot promise any bug submission rewards for posted information. You will need to apply on the forums of your host server, should they offer them. They will determine feasability based on their set of rules and criteria. So far, all of the bugs that I have discovered are initiated by some function that deals with sorting stackable items. I have added immense debug code to inventory.cpp so that I may see in real-time what is occurring. This includes standard item swapping, bandolier swapping and the possibility of corpse looting. I have not tested the corpse looting myself, but looking over the code responsible for handling stackable items, I see a major difference in the way that it's handled versus the way the client and other server methods do. Without this debug code added to the zone server, you will not be able to see the actual bug conditions as they happen. Only the results of a desyncronization will be apparent. ANY desyncronization will lead to problems at some point and it is not recommended to replicate these bugs on anything but test or private servers. Here are some of the conditions that I have found that will lead to desync: - Holding a weapon (especially one used in a bandolier swap) in-hand while performing a swap that contains arrows. - Clicking a stack of arrows that doesn't respond, then clicking on another item or empty slot. - Holding a partial stack of ammo that is used during a bandolier swap. - Certain swap conditions will lead to an arrow with zero charges. - Certain swap conditions will lead to having a backpack (or other non-ammo item) placed in the ammo slot. You should zone or camp as soon as possible if you discover that you have a stackable item that is not clickable! (If you manage to get a backpack in your ammo slot, zone and then click on the ammo slot with the backpack that appears.) The following patch is not guaranteed to be bug free nor provide 100% reliable results. The code is intended to aid in resolving current issues and may or may not be upgraded or refined in the future. Some portions are untested and could cause a server crash with item loss. Use it at your own risk. (It was reverted and patched with no apparent issues.) <inventory.cpp.patch> Code:
Index: inventory.cpp Uleat of Bertoxxulous |
You can probably also check the item swap / item cursor with cast or click as well. Especially with the speed of the MQ2 macros.
|
Do you happen to know if the problem occurs all the time or just when a summoned item is created per chance?
I saw a few postings about that before I found one of the major bugs and did not include it in my search criteria. The most noticeable cursor issue is has to do with how the server is coded to handle a swap action of partial stacks. If you are holding a partial stack on the cursor, the server will jump to placing any additional partial stacks in either an empty personal slot or bag slot, while the client will check for a partial stack on the cursor first. This creates the client-server de-sync and the player becomes bugged to future trades/swaps resulting in obvious item deletions - some permanent. (Yes, the fix for that is really easy, but DO NOT TRY TO COMMIT A FIX before speaking with me privately. There are MAJOR issues that arise when you make that change.) I have a small list of these bugs that I will post soon, but am welcome to more input in the mean time. I need to sort my notes between de-sync issues and actual bug triggering. Again, item loss is not the bug, but the result of one. Like a damaged car is a result of an accident, we want the events leading up to and including the accident, not an in-depth description of the damaged car :) |
Here are some known bugs and behaviors that I have observed.
Some of the behaviors I have seen are omitted since they are duplicate scenarios of the same issue. There are also some other non-revelent issues here since I'm looking at the entire inventory.cpp module. [Cursoring a partial arrow stack involved in bandolier swap, with no other partials in inventory, results in de-sync (Bug)] - This is caused by MoveItemToInventory(). It does not check the cursor for a partial stack before trying to find an empty slot. Client behavior checks the cursor before moving on to empty slots. {TESTED AND VERIFIED - Partial fix appears to work} [Cursoring one of the weapons involved in bandolier swap that has arrows results in de-sync (Bug)] - Known issue, but still researching the exact cause. Could be related to the above bug. {TESTED} [Clicking an item stack and it is non-responsive (Behavior)] - At this point, you are bugged. You need to camp or zone to fix this problem asap before item loss becomes permanent. Any items that you click, trade, buy or receive after invoking this behavior become subject to item loss. I guess this could be applied to any item, but if not, that would narrow down the cause list. {TESTED} [Placing an arrow stack in the ammo slot results in an 'Insufficient Quantity' error message and item deletion (Behavior)] - The part of the code that triggers this message is working correctly. Again, you have become bugged by this point. Other stackables are probably affected the same way. {ARROWS - TESTED AND VERFIED} [Moving an item results in an 'Item Not Found On Server' error message and item deletion (Behavior)] - Bugged..you know what to do. {TESTED AND VERFIED} [Zero-charge stackable item (Bug or Behavior - still in-work)] - It's possible to have an arrow (or possibly any stackable item) with zero charges. This can turn into an exploit, so I will not elaborate on it's cause. (I have triggered this, but do not have an exact procedure as yet. I was already suspecting this as a problem, but I have found a way to provide evidence of it.) {TESTED} [Backpack - the new ammo! (Behavior)] - Overloading the inventory and then calling a swap will result in some REALLY odd behavior (And major item loss.) I managed to get a backpack into my ammo slot..I did not try to use my bow, however... (I wonder if a bag would actually fly across the screen..hmmm...) {TESTED} [Probable issue with Client::PutItemInInventory 'CalcBonuses' call] - If you look at this particular function, you will notice there are two (slot_id == SLOT_CURSOR) checks. The first one is always processed on 'true,' but the second one is never processed on 'true,' however... The call to PushItemOnCursor in the first check duplicates the entire segment of code that is missed. This is not the problem... - Look at the second one again. The check ALWAYS handles a return and CalcBonuses() is never called. {NOT TESTED} [Possible issue with Client::TryStacking] - With stackable items, this method checks the eight personal slots first before going back through bags and misses the cursor altogether. This does not match the client and other server scheme for parsing stackable items. Corpse looting will likely become bugged due to the same de-sync issues described above. {NOT TESTED} [Possible issue with Inventory::SwapItem (item.cpp)] - One-way check... slot 'a' item is checked against slot 'b,' but not vica-versa. First attempt at a fix crashed zone.exe... This needs to be researched more thoroughly. {CONSEQUENCE OF LACK OF CHECK - NOT TESTED} [Not pertinent - possible message issue with summoning items with augmentations] - This is not tested, but I have seen where a possible lore conflict message will kick back when no other lore item is owned and also on non-lore flagged items. The lore checks are correct, but the reference to the lore item in the message is set to the base item and not the augmentation itself - meaning that you are trying to create an additional lore augmentation, but not lore item itself, and it is reporting the wrong lore conflict. Let me know if you have experienced this. {NOT TESTED} [Not pertinent - #peekinv is not showing slot #30 in the listing when its value is null, or supposed to be] - I haven't looked at the code to see if the 'GetItem()' command is just not reporting or is in a failed state. {OBSERVED} After working these issues, and anything new that crops up with fixes, I'll take a look at consumption issues. I just need to verify that they are not a part of these exisiting de-sync problems. If you are posting symptoms, please include server revision, system and client information as well. I don't believe these problems are unique to, or exclusive of, any particular setup, but we won't be able to determine that without the proper data. These issues are long-lived and I'm sure that everyone would love to see them fixed. Please support this request if you have pertinent information. And to remind anyone wanting to fix these issues one at a time - Please do not do so with the item swapping issues. You will introduce major exploits unless all of the issues are coordinated and fixed together. Thanks! |
Cursor stacking can also become messed up without actually becoming desync'd in such a manner that anything becomes unusable.
I do not have a way to make it happen off hand, but it most often happens when doing tradeskills. I was speeding through (manually not with MQ2) making something, drinks i think, and then went to give some to another player and they received instead one of the components I had been using. My inventory was seemingly normal, but upon camping and coming back some of the drinks i had turned into a component. Along these lines I've also ended up with a bag in a bag |
That almost sounds like the zero-charge bug..I'll see if I can do some ts'ing and replicate it.
I've also noticed something along the lines of the server finding an item in the cursor slot (with multiple items on it) but getting the first item regardless of if it's the correct one..almost like it doesn't iterate to find what it found... |
I also managed to #summonitem a stack of 100 water flasks... Should probably add code to check max stack size to help avoid problems.
I was trying to induce the arrow error and camp immediately to check the database for possible zero stacks. What I found was a stack of 100 water flasks... |
I'm trying to sort out some issues as I make changes. One of the things I need to know is this:
Do all clients operate in the same manner in regards to inventory placement order? I can account for any discrepancies in client versions, but I just need to know about them. I also know about the top-to-bottom fill order of the personal inventory slots, and the left-to-right of bag slots. Here is the actual placement order that I have observed with my SoF client: [Stackable Item Charge Movements Only] > Slot 22 >> Slot 22 : Bag Slots (0 -> 9) > Slot 23 >> Slot 23 : Bag Slots (0 -> 9) ..etc... etc... > Slot 29 >> Slot 29 : Bag Slots (0 -> 9) > Slot 30 >> Slot 30 : Bag Slots (0 -> 9) [Stackable Movement Reiteration/Regular Item Movement] > Slot 22 >> Slot 22 : Bag Slots (0 -> 9) > Slot 23 >> Slot 23 : Bag Slots (0 -> 9) ..etc... etc... > Slot 29 >> Slot 29 : Bag Slots (0 -> 9) > Slot 30 >> Slot 30 : Bag Slots (0 -> 9) >>> Slot 30 Array Push The functions/methods that I'm dealing with at the moment all start at 22 and end at 29. I am changing the max to 30 and will check in-game to see if worn slots are included when considering certain actions. (I have not tried 'looting' an arrow to see where it goes yet.) If the worn slots are auto-equipped by the client, but are pushed into the personal inventory by the server, this would account for the CSD (Client-Server Desyncronization..I got tired of spelling that everytime...) and massive item loss associated with it. [Theory:] (Player auto-loots a corpse with a partial stack in ammo -> auto-equips all weapons and armor -> finds stackable ammo for the range slot..client puts it in the ammo slot, but server puts it in slot 22 -> transfers the the bags..client puts all of the bags in the proper place, but server places last bag on the cursor -> player zones and finds a bag on his/her cursor... Speculative..but would like to know if anyone has experienced that exactly. I may have to test this.) I'm still learning the processes involved and may answer my own question about the auto-equip issue. Thanks to everyone that's provided feedback so far! |
Ok, disregard the [Theory] in the previous post. I tried to trigger a bug with that, but it always seemed to put the arrows in the correct places.
Is there an auto-loot button? I keep reading about how it is bugged, but can't seem to find a button or command... |
With SOD+ I believe (been awhile since I've used SoD, on HoT client now) there does exist an auto-loot button - right click corpse, check right by the loot button. Loot All is there, and I've been able to replicate a few of your mentioned bugs with it. They're actually pretty annoying on a single player LAN server, but I can very easilly see how they could be used for abuse. Kudos for bringing this to light.
|
Ahh, I'm using a SoF client..only button I have is 'Link All' :mad:
I believe I see the problem with it, so I may include that in an untested patch after I do this one. I think I've already described that above, but basically it's just not iterating to match the client and items are being placed in different slots on the client versus server in some cases. I'm still waiting for additional feedback on this, however..especially since I can't create a test for it. I found one source of the problems, but I'm still getting this error series: Error: Insufficent number in stack. SwapIt->Exit(SRCItem[Shadowspike Arrow]->SRCCharges[48]->MIStackCount[49]->SRCStackSize[100]->ERROR) The missing 3 charges were 2 on the cursor and 1 in the ammo slot. I just need to find this other source and test it out. My head is stuck in a recursive loop at the moment... :confused: Anyways, I'm hoping these fixes will be easy and won't require any major recoding. |
I'm starting to get some private feedback on these bugs as well and it seems there is proven evidence of their existence.
Give me some time to sort out this mess I call 'notes' and I'll see what I can do with them. I 'think' that currently bugged players will be fixable as well, but someone else will probably submit that..my sql is REALLY horrible! |
Testing with SoF is probably not the right thing to do. From what I've heard it is the least stable client and probably the least used.
|
Quote:
|
Unfortunately, my monthly income is about -$250 a month, so I have to use what I have atm http://www.eqemulator.net/forums/images/icons/icon9.gif
I missed the Steam download by one day..I found the thread here after I had starting researching the different perl versions. Anyways, I'll do what I can with this and post it as an alpha patch. There's no way that I can thoroughly test it the same as someone with internet access and multiple players though. The feedback is appreciated too! I spend most of my time inside VS trying to follow logic paths, so when I get verification of things that I see, it makes it soooo much easier to find a solution. (No eta on a patch atm..I want to understand 100% what I'm seeing before I make any actual submissions.) Edit: p.s. If anyone has any ideas about there being different client loot orders, I still need an answer to resolve that. Thanks! |
[Sidenote: Trevius]
This is speculation, especially since it is so deep in the kernel, but that issue with Inventory::SwapItem may also be playing a part in this. Inv:SI is coded to return a true or false in the case of a success or failure. However, the few instances that I've seen in <inventory.cpp> all call it blind... Even if the memory pointer swap fails, the calling method doesn't have code to process a failed swap, so it just assumes it was successful. (Added to list...) I could be WAY off on this, but it's another possible area to consider. |
(<Bump> on the item swap/casting issue... http://www.eqemulator.org/forums/sho...59&postcount=2)
Do you know if this happens with any spell? Or just with spells with stackable components, per chance? |
Here's a change to my posting about the Inventory::SwapItem function above...
It currently is a void function, but I was thinking that it was a bool instead. The same idea applies and maybe it needs to be changed to 'bool Inventory::SwapItem' to keep the calling method from processing a success when the swap actually failed. Sorry about that... Like I said, my head is a bit off atm. |
One last question (well, maybe two) for you guru's out there before I head off to bed...
I see that items stored on the cursor beyond slot #30 are in slots beginning at #8001 in the database. This appears to successfully reload since I had both the slot #30 and #8001 items when I logged back in. First, I'm not seeing where this extra range is defined anywhere in Item.h, Item.cpp, inventory.h or inventory.cpp. In addition, no checks are made to this range. These are probably not an issue since we don't want to be trading in this area anyways. Question 1: What is the maximum range for the additional cursor slots? Question 2: Where are the bag slots defined for these cursor extra slots??? (see where I'm going?) If a full bag is loaded to one of the #8001+ slots due to overloading your inventory, when it gets bumped to slot #30, where does the information come from for the items that used to be in there? If there are bag slot id ranges for the additional cursor range, I'm still trying to find them somewhere. Otherwise, this is where the loss of items is coming from on the corpse looting when someone grabs extra stuff for a corpse run. If there are no extra slots, the only thing I can think to do would be to auto-loot everything but the bags, then calculate how many slots are left to hold bags and cancel the transaction if there aren't enough spaces to safely loot them. I would like to know the ranges for the extra cursor slots and their bag slots, if they exist. Thanks! |
This is what I have so far with the extended cursor slots:
- The server will allow creation of up to at least 250 additional items with the range being from #8001 to #8250 - These values can be verified by viewing the player inventory in the database. - The client (SoF in this case) only recongnizes 36 additional slots and any more than this the client seems to ignore - Unless you log or zone at this point, you will be CSD bugged if you had any additional items beyond 36. - Since the server 'bumps' the item positions down, the client is 'reloaded' in the case of logging or zoning. - I have not found any extended cursor bag slots as of yet..will continue testing. I'm really not sure if the client is ignoring the extra slots or not. I want to either crash the client or server in an attempt to find the ceiling or to find those extended bag slots. I don't believe they exist, personally... |
From what I can tell, the server is coded to allow 101 items the be stored on the extended cursor at any given time.
It has a total range of 8001 to 8999 and will reiterate any items found here down to the active range of 8001 to 8101. I'm having issues verifying whether or not there are extended bag slots on the client due to the server renumbering my entries to the 8001 ~ 8101 range and not sending my original slot numbers to the client. I've noticed some system packet commands. Is there one in particular that will allow me to send 'item->to_slot' type commands? Or should I look at writing a custom script that will do this? Thanks! |
Can anyone give me pointers on this? I want to send a 'Fake Item' to the client at a specific slot number, but the best I've suceeded in doing is
crashing zone... (I've already updated command.h and the command_init portions.) Code:
void command_zitemtest(Client *c, const Seperator *sep) I just basically want to send the client an item packet for the specified slot, without the server being updated, so I can watch client behavior. Thanks! |
Look at how
Code:
Client::DoTributeUpdate You might also look at the #peekinv command which might help you narrow down when the server and client disagree on something. |
Thanks Lerxst! I'll play around with that later this evening and see what becomes of it.
I was trying to use existing functions, but that's probably part of the problem. Since I can't 'force' my client to pickup a loaded bag and put it on the extended cursor and watch behavior from that, I'm having issues understanding where the item info for those bag slots is coming from. I think this may be a whole other issue and, if I can put my finger on it, I'll start another thread specifically for that. If you have a private/test server and want to see the client cursor limitation, try this: > create a macro to summon an arrow (#summonitem 8005 1) > use this macro, say, like 51 times. This will put 1 arrow on your cursor and 50 on the extended. > Now, find an empty slot and start placing your arrows. In my case, I end up with a stack of 37 arrows (slot #30 plus the 36 extended ones.) > If your cursor still has items on it, you may be using a different client..will need input from people if they do this with different results. > Now, zone or relog and voila! You should have 1 arrow on your cursor and 13 on the extended. > Check this by finding another empty slot and start stacking..the results should be 14 arrows. |
I now have a working #ztestitem command and will do some testing with it. If I find a range that holds extended cursor bag items, I'll start another thread
to elaborate on that. (I found out that I was not initializing the item instance correctly..thanks again Lerxst for pointing me in a good direction!) p.s. This test command is not meant for committed server use. It will cause CSDs and is meant for testing only. If anyone would like a copy of it, please post here and I will diff it. Only one request is needed..no need to fill up the thread with requests. |
Ok, I think that I've finally resolved my understanding of what's going here... (correct me if I'm wrong.)
[Client-Side:] - Slot 30 is assigned as the cursor and has a built-in buffer array of x (37 total in the case of my SoF client [0..36].) - Slots 331 to 340 are assigned to slot 30 [0], but there is no buffer array on these. - Cursor buffer slots were never meant to hold actual occupied bags..only single items that may have been received in quantities greater than one. - There are no slot assignments in the range of 8001 to 8999 registered in the client. [Server-Side:] - Cursor slot 30 is assigned normally, as well as slots 331 to 340 for bag contents. - Cursor slot is buffered, and is assigned to the range of 8000 + x [1..101]. Reiteration of the cursor re-enumerates exisiting buffer items. - Cursor array will reiterate any items between 8001 to 8999 to keep the buffer filled. - Cursor bags slots are not arrayed, as indicated by the log posted below. - Any occupied bags forced into the cursor array will override the contents of the cursor bag stored in the server player profile..but not update the client. That last one is nasty if you loot a corpse with a full inventory. You will lose all items up to the last bag. But since this also created a CSD, you stand a chance of losing those as well as any other items you interact with afterwards. Fix? Possible... Depends on what the desired behavior is. We could just not allow occupied bags to be placed in the cursor buffer... Or, a cursor bag array could be created, but some sort of keeping the array sync'd to the actual bag it belongs in would need to be implemented..as well as a client update for the cursor bag slots... This is a postulate, but much comes from the observed behavior of my client interactions. Here's the log..notice the item in slot 30, depth 37 will not show up on my client until I relog or zone: Code:
[Sun Jul 15 06:21:44 2012] Logging to 'eqlog.txt' is now *ON*. Back to working the original CSD issues..again, let me know if I am off-base with this. I need to understand how this works before I can decide what method needs to be used in a fix for these other issues. |
I think I found a bug with '#equipitem,' but not sure atm if it's an actual issue..might be exploitable, so no description will be provided.
(Added to list of things to check.) (Does MQ use #equipitem? If this is how that exploit is being performed, those users aren't gonna be happy...) |
As with all # commands, it is only usable by an account with a status of whatever is set in the commands table. I know of very few servers where it is available to all players. If you had the status to use the command you could certainly use it in a MQ2 macro, but otherwise, no.
|
kk, thanks! I did add some code to it (and another function) to help alleviate anything from this particular possibility.
I'm nowhere near done and will have to test all of this before I post an alpha patch..but it is coming along. EDIT: I need a favor from the community... If someone positively knows this, please post it, otherwise: I need to know what the cursor limits are for each client. For my SoF client, holds 1 visible cursor item and an additional 36 behind it. Anything after that is ignored. Use the instructions here to determine the limit: http://www.eqemulator.org/forums/sho...8&postcount=24 Also, does anyone know if any clients actually hold bag data for those hidden cursor slots? SoF doesn't appear to because I can't force items beyond the visible bag. Thanks! |
Regardless of the problems and issues that I've already described, the more that I dig into this, the more I am finding wrong.
This is not going to be a quick fix and will probably require a rework of many functions. I've made some progress with what I have so far, like the server catching and deleting 'phantom' client items before they bug 'real' server items. Because of the differences in the way that some calling methods use certain functions, the 'swap' actions are being processed in the wrong portion of code... (i..e., weapons are being treated as stackable items and having their 'charge' removed to become 'zero-charge' items when they are moved.) I'd be willing to bet that any bugs dealing with the transfer of items can be traced back to what I've found (and am still finding.) I'm anything but an expert, but I am making some progress..so, any input from you guys will help and is greatly appreciated! |
I'm having an idiot moment...
Can someone point me to where the client packet stream is processed and a 'trade' or a 'swap' call is directed to Client::SwapItem? VC 'find' is not cooperating... (('swapitem' == ':swapitem') != '.swapitem' != '>swapitem') |
Client::Handle_OP_MoveItem
I just searched for "SwapItem" and looked at all 5 places where a function of that name is called. I have no idea what the search you posted is supposed to do. |
Lol! Sorry about that! I'm on my latop..very old laptop..that's boasting a 2.4 GHz, non-HT cpu, and a whopping 1-Gig of ram...
For some reason my 'searches' are not finding things they way it should when I search for specific criteria. That thing at the end is what my search results say is equal and not equal..not my actual criteria line. searching for 'swapitem' will find ':swapitem', but does not return '>swapitem' or '.swapitem' hits for some reason. Even with the above four criteria, 'Client::Handle_OP_MoveItem' never came up..even when searching 'Entire Solution...' Thanks for the info! EDIT: Yes, I searched up and down, but something just isn't right about my searching or my laptop..or both... |
I finally managed to bug an 'empty' corpse the other night so that it would not go away.
The strings of the corpses in the backup appeared different than the one that was still active. I think this CSD issue is creeping into this area too. Could someone with knowledge of corspe inventory strings and access to an active database check to see if there are corpses that players can't loot anything else off of, but that the corspe will not decay after looting? I'm looking for it having items stored on it that have zero charges, resulting in the client not seeing them, but the server saying they are there..hence the reason a corpse will not decay properly when bugged... Thanks! |
You can duplicate this by having an item on the cursor when you die.
Make a rogue. fill up the inventory. use pickpocket to get an item on the cursor. use pickpocket again and you should get the message that it won't work with an item on your cursor. die. get rez. loot corpse. corpse will not rot. this of course also is easy to do with foragers, but it should be repeatable with any character and a full inventory and an item on the cursor. I am semi confident it does not happen if the inventory is not 100% full. as for look at corpse items.. those are in a blob, so need to parse it out of there. I vaguely recall seeing a script to check blobs once but do not recall if it was on corpses or players. i'll poke at it later if no one gets back to you sooner. |
(Sorvani, that almost sounds like when a player dies with an item in the cursor queue, past [0], the server knows
that it's there, but the loot routine is only grabbing [0] and sending it to the client and not sending queue slots... I'll add it to the list... It might be fixable by doing a cursor iteration when sending the loot window packets, if that's what is happening.) Anyways, I've been distracted by r/l and am starting to get back into this. I'm posting an ALPHA patch here for some minor issues. I didn't want to start a new thread in another forum with a portion of this not tested. (#summonitem was modified to report lore conflict failures with augments properly (imo) and I haven't looked up any augment item id's just yet to test it out.) The rest of the code is tested and should work as intended. [CSD Patch 1] Code:
Index: command.cpp If this isn't committed, that's fine. I'll include it in a later patch. I think I have a pretty good idea of what's happening now, but if anyone still has any suggestions... (constructive... I know how to do THAT already!) |
Here's another 'in-work' mod...
(Remember, I'm trying to find ALL occurences of CSDs/bugged inventories.) Code:
Index: client_packet.cpp Tested with legal trades, but untested for illegal... This is still in a crude state, but any input is appreciated! |
I missed removing that second 'hackflag' definition..they were originally internal.
|
I always forget to check for 'null' values on new stuff..usually that is already done...
I also changed the pointer reference when I was trying to figure this out..it currently works, but it could have the other way as well... (didn't check it.) This is an ALPHA patch as well since it more proof of concept than a finished product. [CSD Patch 2] Code:
Index: client_packet.cpp Still looking for feedback :D |
(I know you guys get tired of reading my rantings..but I have to keep it out here in case something happens to me or my notes...)
Back in this post - http://www.eqemulator.org/forums/sho...2&postcount=19 - I mentioned how the cursor is slot 30 and the queue begins at 8001, per database observation. Slot 8000 is apparently not used for the active cursor. It is, however, referenced several times in the code..here's one instance: [PlayerCorpse.cpp] Code:
Corpse::Corpse(Client* client, sint32 in_rezexp) of the second loop? And, what would happen if both slot 30 and slot 8000 were occupied? We should lose one of them, right? Muse it over and let me know if you think this is an issue. It's on my list, so I'll eventually find a way to test what is happening. |
All times are GMT -4. The time now is 07:48 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.