item ID re-organisation

[Alige]

This is part of the balance project is one of our top priority right now.

Here is an idea of a list for the item ID re-organisation that needs to be discussed.

• 1000 - 1999 -> Healph Items & Status Items
• 2000 - 2999 -> Weapons & Ammo & Shields
• 3000 - 3999 -> Feet Armor
• 4000 - 4999 -> Legs Armor
• 5000 - 5999 -> Chest Armor
• 6000 - 6999 -> Hands Armor
• 7000 - 7999 -> Head Armor
• 8000 - 8999 -> Dyed items (path = 20 -> leaves space for some new dyes)
• 9000 - 9999 -> Necklaces & Rings & Charms
• 10000 - ∞ -> Generic Items

Ali-G

[Crush]

Why not put dyed items into the armor category they belong to?

[Jenalya]

What about checking how many items of each type we actually have?
This could change with more new items coming into the game of course, but if we can see big differences (e.g. less than twenty of one type and hundreds of another), it might be a good idea to not have all the ranges the same size, but leave room in each for new items.
Also, isn't there a limit of the numbers server-sided?

Why not put dyed items into the armor category they belong to?

I like that idea.

[Alige]

Why not put dyed items into the armor category they belong to?

Well we could effectively do that, so the list would become somthing like that:

• 1000 - 1999 -> Healph Items & Status Items
• 2000 - 2999 -> Weapons & Ammo & Shields
• 3000 - 3999 -> Feet Armor
• 4000 - 4999 -> Legs Armor
• 5000 - 5999 -> Chest Armor
• 6000 - 6999 -> Hands Armor
• 7000 - 7999 -> Head Armor
• 8000 - 8999 -> Necklaces & Rings & Charms
• 9000 - 9999 -> Generic Items

As Jenalya just said, we could indeed see how much space is needed for each category. The space written here is only an example of course.

[o11c]

Also, isn't there a limit of the numbers server-sided?

Items are stored in a DB table (more commonly known in CS as a map), instead of an array, so there is no practical limit to the range.

Remember that the current server uses signed 32-bit integers and has a lower limit of 500 (but starting at 1000 would probably make things simpler).

---

I do recommend that you put dyed items (including the white/undyed version) separate from non-dyeable items (this could be still in the same thousand range, or add 10 thousand), to minimize headaches when converting to non-hard-coded colors. It might be better to have the IDs grouped by color rather than by base item.

Perhaps there should be consideration for the fact that, theoretically, there are 16 equipment slots (even in the current server/protocol can't use them all)

The downside to separating out the IDs, is that sets of armor have unrelated IDs. Unless you reserve subranges for that. (There is practically no cost to having gaps, after all)

---

I'm not too fond of weapons, ammo, shields, being the same category.

---

'p' is nowhere near 't' ...

[enchilado]

The balance project will introduce equipment tiers, so each piece of equipment will need a number of entries (probably five).

My main concern with this idea is that if there any dyeable items with tiers, way too many entries will be needed. Should we leave room for equipment that will require 50 (or more, if we introduce new dyes) entries, or just avoid tiered and dyeable items?

Also, if there is no limit to the IDs, what if dyeable items had the same ID as the base item followed by a number? That is... 1234 would be the base item, and the dyed variants would be 12340, 12341, 12342, etc.

How easy is it to change the IDs of existing items?

[nmaligec]

Should we leave room for equipment that will require 50 (or more, if we introduce new dyes) entries, or just avoid tiered and dyeable items?

Wow, making tier and dye mutually exclusive is the simplest but best suggestion I remember reading about for this subject (sorry if others have already suggested this before). When you think about it makes sense to only allowing players to customize simple clothing. Armours are pretty much stuck the way you find them, and weapons wouldn't have much dye-able surface. You can use the dye system to make each of the 5 tiers look different, but don't allow for custom player colouring.

The alternative of allowing a tiered and dyable item would just needless bloat the item database. I would rather have 3 different dyeable clothes and 4 tiered items for the cost of just one dyable tiered item!

How easy is it to change the IDs of existing items?

Don't forget that you will have to update mob_db.txt to use the new IDs for the item drops. Also some npc scripts refer to the item by ID instead of by name (ex: 001-1_Tulimshar/bleacher.txt Line 9).

[Wombat]

We will make equipment tiers exclusive from dyeable equipment. This will save effort. If an armor is recolorable, a different color of it would have unique behaviors or purposes for existing from the other.

[Wombat]

Here is how it is to be done. We are using one more 0, so 99999 is our top number.
The 1 in 10000 decides if the item is: an item, non-tiered equipment, dyeable equipment or tiered equipment
The 2 in 02000 decides where the equipment is located: weapon, head, chest, leg, hand, feet, shield, ring, charm
If an Item, the 2 in 02000 will be marked 0 until we have more than 1000 items.
the 4 in 00444 is the number for the specific equipment.

[o11c]

Sorry I didn't notice this before, but despite being an int internally, when sent to the client it is cast to uint16_t
so the maximum is 65535.

And due to bugs in the client (which I told them about but they didn't think it was important), it will (sometimes?) mis-interpret those as signed, limiting to 32767.

[enchilado]

With five tiers and twenty dyes, there are 287 'types' of item (generic, head etc. equipment, dyed versions of head etc. equipment, tiers of head etc. equipment). If each type has an equal amount of space, 32,676 gives us about 113 items of each type.

What if we gave 50 slots to each type except generic, which would have the rest?

[o11c]

I just noticed this:

Code: Select all

    if (nameid > 500 && nameid < 600)
        id->type = 0;           //heal item
    else if (nameid > 600 && nameid < 700)
        id->type = 2;           //use item
    else if ((nameid > 700 && nameid < 1100) ||
             (nameid > 7000 && nameid < 8000))
        id->type = 3;           //correction
    else if (nameid >= 1750 && nameid < 1771)
        id->type = 10;          //arrow
    else if (nameid > 1100 && nameid < 2000)
        id->type = 4;           //weapon
    else if ((nameid > 2100 && nameid < 3000) ||
             (nameid > 5000 && nameid < 6000))
        id->type = 5;           //armor
    else if (nameid > 4000 && nameid < 5000)
        id->type = 6;           //card

I'm not sure how much it affects, however: I think this code is only reached when the item isn't in item_db.txt (deleted, or from a different map server)

[Wombat]

Amended

30000 is top

The 0 in 09999 is an Item or non-tiered equipment. The 1 in 19999 is dyeable equipment, the 2 in 29999 is for tiered equipment.
The 0 in 90999 decides where the equipment is located: weapon, head, chest, leg, hand, feet, shield, ring, charm. If an item, mark as "0". This gives 999 items and 1000 for each equipment location.

This should work?

[enchilado]

Well, we could only have 200 different tiered items (not that we'll ever reach that) and 50 different dyeable items (which we might reach).

[Wombat]

29999 is top.

0X000 is equipment location.
1 = item (regular) or weapon/arrow (tiered), 2 = head, 3 = chest, 4 = leg, 5 = hand, 6 = feet, 7 = shield or armgear, 8 = ring or charm

01000-08999 is for regular items and equipment.
11000-18999 is for tiered equipment.
22000-28999 is for dyeable equipment.

Equipment tier levels are 0-4 (5 levels) per specific item.

200 unique tiered items per location slot (0-999).

Dyeable equipment includes 20 possible dyes (including bleached white).

50 unique dyeable items per location slot (0-999).

With current system, overflow can be managed to double or triple locations which have a lot of unique creations for, like if more hats were created than the location slot would allow. Such amendments should be noted when done within the db. Presently, we don't have this problem nor does it seem like a problem for the very near future, but it is possible.