[Request] newSlot when looting

[TacoBell]

What is the "byte position" for adding an item to a next slot? I want to avoid "CASH" items stacking up on one another, IE: 2x DROP cards. If a player were to receive one from an NPC or from drops, I would like to appear in a whole new slot, instead of being piled up on one another in one slot. I'm assuming this is in MapleInventoryManipulator.java, but I don't know the byte to put the item in the nextFreeSlot. Thanks.

[MentaL]

[Eric]

This is actually just a bug in OdinMS. After I re-wrote InventoryManipulator to Nexon's, and Smega's and other NX things like Chocolate Heart Boxes refused to stack, I was curious why (so used to them stacking in Odin!). Apparently, no cash items stack.. I however wrote a workaround which gives all Cash items a fixed slotMax of 10 (defined as a constant), so I can customize it. However, this does not to apply to Pets or Hearts.

Anyway, your problem is the implementation of slots in Odin. For any item who's XML does not have "slotMax", it is automatically 100. This is wrong, idk why they did that. I bolded it so you can see where this is, feel free to make it 1 or define it as a constant somewhere. This function is stored in src/server/MapleItemInformationProvider.

public short getSlotMax(MapleClient c, int itemId) {
        if (slotMaxCache.containsKey(itemId)) {
            return slotMaxCache.get(itemId);
        }
        short ret = 0;
        MapleData item = getItemData(itemId);
        if (item != null) {
            MapleData smEntry = item.getChildByPath("info/slotMax");
            if (smEntry == null) {
                if (getInventoryType(itemId).getType() == MapleInventoryType.EQUIP.getType()) {
                    ret = 1;
                } else {
                    ret = 100;
                }
            } else {
                ret = (short) MapleDataTool.getInt(smEntry);
                if (ItemConstants.isThrowingStar(itemId)) {
                    ret += c.getPlayer().getSkillLevel(SkillFactory.getSkill(4100000)) * 10;
                } else {
                    ret += c.getPlayer().getSkillLevel(SkillFactory.getSkill(5200000)) * 10;
                }
            }
        }
        if (!ItemConstants.isRechargable(itemId)) {
            slotMaxCache.put(itemId, ret);
        }
        return ret;
    }

EDIT: To explain, the manipulator continuously adds into a slot until the maximum has been reached or (according to Odin standards*), the Item Name differences (e.g tagged by GM). If you make the max 1, then every item will go to a new slot like you're asking. If you make it 1000 for everything, all items will have 1000 per slot before moving to a new slot.

[TacoBell]

This is actually just a bug in OdinMS. After I re-wrote InventoryManipulator to Nexon's, and Smega's and other NX things like Chocolate Heart Boxes refused to stack, I was curious why (so used to them stacking in Odin!). Apparently, no cash items stack.. I however wrote a workaround which gives all Cash items a fixed slotMax of 10 (defined as a constant), so I can customize it. However, this does not to apply to Pets or Hearts.

Anyway, your problem is the implementation of slots in Odin. For any item who's XML does not have "slotMax", it is automatically 100. This is wrong, idk why they did that. I bolded it so you can see where this is, feel free to make it 1 or define it as a constant somewhere. This function is stored in src/server/MapleItemInformationProvider.

public short getSlotMax(MapleClient c, int itemId) {
        if (slotMaxCache.containsKey(itemId)) {
            return slotMaxCache.get(itemId);
        }
        short ret = 0;
        MapleData item = getItemData(itemId);
        if (item != null) {
            MapleData smEntry = item.getChildByPath("info/slotMax");
            if (smEntry == null) {
                if (getInventoryType(itemId).getType() == MapleInventoryType.EQUIP.getType()) {
                    ret = 1;
                } else {
                    ret = 100;
                }
            } else {
                ret = (short) MapleDataTool.getInt(smEntry);
                if (ItemConstants.isThrowingStar(itemId)) {
                    ret += c.getPlayer().getSkillLevel(SkillFactory.getSkill(4100000)) * 10;
                } else {
                    ret += c.getPlayer().getSkillLevel(SkillFactory.getSkill(5200000)) * 10;
                }
            }
        }
        if (!ItemConstants.isRechargable(itemId)) {
            slotMaxCache.put(itemId, ret);
        }
        return ret;
    }

EDIT: To explain, the manipulator continuously adds into a slot until the maximum has been reached or (according to Odin standards*), the Item Name differences (e.g tagged by GM). If you make the max 1, then every item will go to a new slot like you're asking. If you make it 1000 for everything, all items will have 1000 per slot before moving to a new slot.

Gah, thank you very much. I learned something new today, but it seems your method wasn't able to work. It gave me an idea, though, to try another method and it ended up working flawlessly. Didn't realize the stacking thing was a bug O.O

[Twdtwd]

To expand on this a bit more, most odin based sources have a bug relating to stacking items where it doesn't compare the timestamp on the items to see if they are the same before allowing them to stack. This can be used to extend duration of items that expire. When fixed, it also makes any cash shop items purchased (If your source makes them expire) have their own slot.

[TacoBell]

To expand on this a bit more, most odin based sources have a bug relating to stacking items where it doesn't compare the timestamp on the items to see if they are the same before allowing them to stack. This can be used to extend duration of items that expire. When fixed, it also makes any cash shop items purchased (If your source makes them expire) have their own slot.

I was thinking the exact same thing when I added the method. The one I added, though, only allows 1 item to be allowed in a slot (I only plan on making two items expire in cash) so they won't ever stack and the timestamp remains when dropped and retrieved again. Down the line I may give it a crack and try to fix it. Thanks for pointing it out.