[SRC]bag jumble Fix

[juggalo2]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
find
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wsprintf(G_cTxt, "RequestInitDataHandler error: Client(%s) Item(%d)", m_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scroll up a bit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
iTotalItemA = 0;
for (i = 0; i < DEF_MAXITEMS; i++)
if (m_pClientList[iClientH]->m_pItemList != NULL)
iTotalItemA++;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
add
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//fix for bag jumble
bFlag = FALSE;
while (bFlag == FALSE) {
bFlag = TRUE;
for (i = 0; i < DEF_MAXITEMS-1; i++)
if ((m_pClientList[iClientH]->m_pItemList == NULL) && (m_pClientList[iClientH]->m_pItemList[i+1] != NULL)) {
m_pClientList[iClientH]->m_pItemList = m_pClientList[iClientH]->m_pItemList[i+1];
m_pClientList[iClientH]->m_pItemList[i+1] = NULL;

m_pClientList[iClientH]->m_ItemPosList.x = m_pClientList[iClientH]->m_ItemPosList[i+1].x;
m_pClientList[iClientH]->m_ItemPosList.y = m_pClientList[iClientH]->m_ItemPosList[i+1].y;
bFlag = FALSE;
}
}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
make sure there 16 not 15
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if (memcmp(token, "item-position-x", 16) == 0) {
cReadModeA = 50;
cReadModeB = 1;
}
if (memcmp(token, "item-position-y", 16) == 0) {
cReadModeA = 51;
cReadModeB = 1;
}


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`



Have Fun Brought To You By Juggalo2

[1+12]

Have you tested this to make sure it actually works?

Then again its nice to see someone still contributing to the HB Community.

[bone-you]

This has already been suggested and proven not to work. Even at 15, it still matches because the first 15 bytes are still exact. It still processes a match. Though it does seem to fix an error of reading the y values into x, that doesn't explain why the items are just swapped back an index value putting them in the spot the next item up was at. That's an indexing issue not so much a reading issue.

[juggalo2]

This has already been suggested and proven not to work. Even at 15, it still matches because the first 15 bytes are still exact. It still processes a match. Though it does seem to fix an error of reading the y values into x, that doesn't explain why the items are just swapped back an index value putting them in the spot the next item up was at. That's an indexing issue not so much a reading issue.

dude there more than just the 15 to 16 change durr.


and yes i tested an it works i havent had a bag jumble yet

[Dax]

This has already been suggested and proven not to work. Even at 15, it still matches because the first 15 bytes are still exact. It still processes a match. Though it does seem to fix an error of reading the y values into x, that doesn't explain why the items are just swapped back an index value putting them in the spot the next item up was at. That's an indexing issue not so much a reading issue.

Turns out the 2.20 was almost there. That bFlag shit (although confusing) is the 2.20 fix. Thats why I never experienced the bug after performing hypno's proposed fix on my files. Juggalo found the final peice. So in both cases, Juggalo wins, you lose.

[1+12]

Lol, Anyways, good job

[Charles]

wouldnt it be better to add it to the part above instead of below it? i just added the x and y pos inside the itotalitema part. and edited the notify case for item postion with the 2.20 one. haven't experienced any scramble yet. if you look at other codes inside the source about how you get an item. you'll see you dont need to add another part. just have to edit an existing part