- Status Closed
- Percent Complete
- Task Type Bug Report
- Category
-
Assigned To
Tristan Cragnolini - Operating System
- Severity Medium
- Priority
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: PlaneShift
Opened by Arerano Areramau - 07.12.2008
Last edited by aurelynt - 22.03.2009
Opened by Arerano Areramau - 07.12.2008
Last edited by aurelynt - 22.03.2009
FS#2579 - Items "vanish" when moved to an invalid slot
Using the old inventory (or one of the Modded inventories) makes items which are about to be equipped to the “Head slot” vanish.
More specifically: Moving an item to an invalid slot makes it “vanish” for the client.
Looking into the Database, the items gets “location_in_parent=-85”.
In my oppinion this is a BUG. The server should deny moving items to “invalid slots” rather than giving it some “inaccessible parent id”.
There’s no way for “clients” to reaccess those items.
To reproduce: use the old inventory.xml (which has <widget name=”head” factory=”pawsSlot” tooltip=”Head”> instead of <widget name=”helm” factory=”pawsSlot” tooltip=”Helm”>).
| ID | Project | Summary | Priority | Severity | Assigned To | Progress | |
|---|---|---|---|---|---|---|---|
| 2588 | PlaneShift | High |
Closed by aurelynt
22.03.2009 19:31
Reason for closing:
Additional comments about closing:
22.03.2009 19:31
Reason for closing:
Additional comments about closing:
Verified fix.
Working.
kougaro made the following patch http://pastebin.ca/1281015 this should fix this issue for the time being by not allowing clients with invalid slot names to connect to the server.
http://pastebin.ca/1283394 Updated the link, i forgot a bunch of semi-colons while writing this :)
Both links open an empty paste for me "general pastebin - no posts to display".
Verified, it works.
Kougaro, can you put the patch on codereview and find someone to commit it? :)
New Patch Fix both client side and server side.
Client side, ensure that the client won't load if the slots are not correct
Server side, the function in charge was assuming that by default you can put the item in the slot, resulting in aberrant behaviour for out of range values.
Setting ready to test, since this was commited (a slightly modified version) in r3057