Core/Quests: Make sure itemcount doesn't get to be negative.

Since this is an old issue and probably there are various entries with huge values as itemcounts already, a cleanup must be done before changing structure of character_queststatus which was done in r9be097c482, thus I'll include the SQL cleanup in that revision's .sql file or MySQL will thrown an error regarding out of bounds values

--HG--
branch : trunk
This commit is contained in:
Shocker
2010-09-27 02:57:01 +03:00
parent a9e9a2c884
commit ede2a1c5ed
2 changed files with 6 additions and 1 deletions
@@ -1,3 +1,8 @@
UPDATE `character_queststatus` SET `itemcount1` = 0 WHERE `itemcount1` > 65535;
UPDATE `character_queststatus` SET `itemcount2` = 0 WHERE `itemcount2` > 65535;
UPDATE `character_queststatus` SET `itemcount3` = 0 WHERE `itemcount3` > 65535;
UPDATE `character_queststatus` SET `itemcount4` = 0 WHERE `itemcount4` > 65535;
ALTER TABLE `character_queststatus` CHANGE `status` `status` TINYINT( 1 ) UNSIGNED NOT NULL DEFAULT 0,
CHANGE `mobcount1` `mobcount1` SMALLINT( 3 ) UNSIGNED NOT NULL DEFAULT 0,
CHANGE `mobcount2` `mobcount2` SMALLINT( 3 ) UNSIGNED NOT NULL DEFAULT 0,
+1 -1
View File
@@ -15240,7 +15240,7 @@ void Player::ItemRemovedQuestCheck(uint32 entry, uint32 count)
if (curitemcount < reqitemcount + count)
{
uint16 remitemcount = curitemcount <= reqitemcount ? count : count + reqitemcount - curitemcount;
q_status.m_itemcount[j] = curitemcount - remitemcount;
q_status.m_itemcount[j] = (curitemcount <= remitemcount) ? 0 : curitemcount - remitemcount;
if (q_status.uState != QUEST_NEW)
q_status.uState = QUEST_CHANGED;