Back to 'creature_loot_template' Return to world Go to 'gameobject_loot_template'
Well, according to vocabulary the meaning of the word "loot" is good for corpse loot and may be for some gameobjects like chests but quite unfit for fishing "loot". Nevermind. We will use term "loot" here as "a set of items generated on an event for a player" and "loot definition" as "a set of rules for loot generation". And forget about vocabulary for a while.
This table format is used for 12 different tables to generate different loot items for different things. The 12 tables are:
The general description here is valid for all 12 because the loot system is the same across all tables.
Loot templates define only items in the loot. See comments about money drop in corpse, pickpocketing and luggage loot in creature_template and item_template.
| Field | Type | Attributes | Key | Null | Default | Extra | Comment |
|---|---|---|---|---|---|---|---|
| Entry | mediumint | unsigned | PRI | NO | 0 | ||
| Item | mediumint | unsigned | PRI | NO | 0 | ||
| Reference | mediumint | unsigned | NO | 0 | |||
| Chance | float | NO | 100 | ||||
| QuestRequired | tinyint(1) | signed | NO | 0 | |||
| LootMode | smallint | unsigned | NO | 1 | |||
| GroupId | tinyint | unsigned | NO | 0 | |||
| MinCount | tinyint | unsigned | NO | 1 | |||
| MaxCount | tinyint | unsigned | NO | 1 | |||
| Comment | varchar(255) | YES | NULL |
The 12 tables have different relations with other DB tables.
| table | field | relation | related table | related field | comment | |
|---|---|---|---|---|---|---|
| fishing_loot_template | no db relation | AreaTable | id | Entry is linked with ID of the fishing zone or area | ||
| creature_loot_template | Entry | many <- many | creature_template | lootid | ||
| gameobject_loot_template | Entry | many <- many | gameobject_template | data1 | Only GAMEOBJECT_TYPE_CHEST (3) or GAMEOBJECT_TYPE_FISHINGHOLE (25) | |
| item_loot_template | Entry | many <- one | item_template | entry | ||
| disenchant_loot_template | Entry | many <- many | item_template | DisenchantID | ||
| prospecting_loot_template | Entry | many <- one | item_template | entry | ||
| milling_loot_template | Entry | many <- one | item_template | entry | ||
| pickpocketing_loot_template | Entry | many <- many | creature_template | pickpocketloot | ||
| skinning_loot_template | Entry | many <- many | creature_template | skinloot | Can also store minable/herbable items gathered from creatures | |
| mail_loot_template | Entry | many <- one | quest_template_addon | RewardMailTemplateID | ||
| spell_loot_template | Entry | no db relation | Spell | id | Only spells with SPELL_EFFECT_CREATE_RANDOM_ITEM (59) or SPELL_EFFECT_CREATE_ITEM_2 (157) | |
| reference_loot_template | Entry | many <- many | *_loot_template | Reference |
The ID of the loot definition (loot template). The rows with the same ID defines a single loot.
It is often the same ID as the loot source (item, creature, etc) but when the link is made not on Entry field of the Related table then ID can be different. For example, when several loot sources should provide the same loot, single loot definition can be used. In this case the loot sources have the same value in the link field.
It is possible also to set up artificial loot templates which are not used directly at all as they have ID which are not referenced from the related source. Such "support templates" can be referenced from "normal" loot templates.
When a common or artificial loot template is used a problem arises: what ID to use for that template? Depending on the loot table, different rules can be agreed on to simplify maintenance for the table. Moreover, such rules would be very handy but it seems at the moment there are very few rules explicitly defined.
Agreements on Entry field values are described there.
Template ID of the item which is included into the loot.
Note: For reference entries this field has no meaning and is not used by the core in any way. Yet because of the PRIMARY KEY on the entry + item combination, this field will nonetheless need to be a unique number for each reference entry so that no indexing conflicts arise.
Template reference asks core to process another loot template and to include all items dropped for that template into current loot. Simple idea.
Value of MaxCount field is used as a repetition factor for references - the reference will be processed not just once but exactly MaxCount times. So if the referenced template can produce 3 to 10 items (depending on luck) and value of MaxCount is '5' then after processing of that reference 15 to 50 items will be added to the loot. An awful example, isn't it? Actually no good example for whole template reference repetition is known, but it is quite useful for group references sometimes.
Be careful. Self references (loot template includes reference to itself) and loop references (loot template A includes reference to entire template B, loot template B includes reference to entire template A) are completely different from internal references. If you make a self-reference like
INSERT INTO `reference_loot_template` (`Entry`,`Item`,`Reference`) VALUES (21215, 0, 21215);
then the core will crash due to stack overflow at first attempt of loot 21215 processing. That is why self references and loop references are strictly forbidden.
Item drop chance (plain entry or quest entry).
Chance > 0
Chance > 0
Zero value of Chance is allowed for grouped entries only.
(Non-zero) values of Chance in loot definition are multiplied by RATE_DROP_ITEMS (config setting) during loot generation for references and non-reference entries, but not for grouped entries.
Informs the core that the item should be shown only to characters having appropriate quest. This means that even if item is dropped, in order to see it in the loot the player must have at least one quest that has the item ID in its RequiredItemId fields or in its StartItem fields. The player must also have less copies of the item than RequiredItemCount or ProvidedItemCount.
A special parameter used for separating conditional loot, such as Hard Mode loot. A lootmode of 0 will effectively disable a loot entry (its roll will always fail). This column is a bitmask, so you shouldn't duplicate loot across lootmodes. The active lootmode(s) can be changed at any time by the core. This column should only be used if required, in most cases it should be left as 1. Valid lootmodes include: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 16384, 32768.
A group is a set of loot definitions processed in such a way that at any given looting event the loot generated can receive only 1 (or none) item from the items declared in the loot definitions of the group. Groups are formed by loot definitions having the same values of entry and GroupId fields.
A group may consists of explicitly-chanced (having non-zero Chance) and equal-chanced (Chance = 0) entries. Every equal-chanced entry of a group is considered having such a chance that:
Of course group may consist of
The easiest way to understand what are groups is to understand how core processes grouped entries:
At loading time:
groups are formed - all grouped entries with the same values of GroupId and Entry fields are gathered into two sets - one for explicitly-chanced entries and one for equal-chanced. Note that order of entries in the sets can not be defined by DB - you should assume that the entries are in an unknown order. But indeed every time core processes a group the entries are in some order, constant during processing.
During loot generation:
core rolls for explicitly-chanced entries (if any):
Let us use term group chance as the sum of Chance (absolute) values for the group. Please note that even one equal-chanced entry makes group chance to be 100% (provided that sum of explicit chances does not exceed 100%).
If you understand the process you can understand the results:
Processing of equal-chanced part takes much less time then of explicitly-chanced one. So usage of equal-chanced groups is recommended when possible.
So now basic applications of the groups are clear:
A single group may be defined for a set of items common for several loot sources. This could be very useful for decreasing DB size without any loss of data. See References for more details.
There is no way to have a reference as a part of a group.
Note: A group may contain definitions of non-quest drop, quest drop or both, but mixing non-quest and quest drop in a single group is not recommended.
Note: Due to client constraints only 16 non-quest items (money and items added into the loot for quests are not counted for this "16") may come into the loot. As most of loots have much more than 16 possible items (sometimes several hundreds) so without groups there is a (little) chance that more than 16 items will be rolled for a given loot but player will be able to see (and take) only first 16 of them. With groups you can ensure that more than 16 items will never drop. If DB pretends to be a quality software it must have loot template definitions which ensure that not more than 16 plain entries and groups are defined for any loot template. This is just a note - such declaration is not issued by TDB developers yet.
Note: The core has no limitation for number of groups (except 255 by DB field size), but according to the previous note there is no need to use values greater than 16.
Groupid for dummies as people have a hard time understanding it:
Lets say you have 10 different items in groupid 1 with the same chance, everytime the creature dies, it will randomly pick one of those items to drop.
If you have 10 different items in groupid 1 and 10 different items in groupid 2 with the same chance, then everytime the creature dies, it will randomly pick one of those 10 items in groupid 1 to drop, and one of the 10 items in groupid 2 to drop, meaning two items will drop. This is how boss loot works, this is how you make two random gear items drop everytime the boss dies.
For reference entries: If GroupId > 0 only the referenced items with said GroupId will drop.
The minimum number of copies of the item that can drop in a single loot
For non-reference entries:
For reference entries:
Note: core rolls chance for any loot definition entry just one time - so if a references loses its roll it is skipped for the current loot completely, whatever it's MaxCount value.
This field is for any comment you want to make. It is arbitrary text.
These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs (entry) and groups.
For fishing_loot_template, ID is the AreaTable ID
Also an extra note on fishing_loot_template: if just one area ID is defined for a zone, then that whole zone ID is skipped and therefore all areas in that zone need to have entries in the table. Only when there doesn't exist any area entries for a zone does the core use the zone ID directly. Zone = Wetlands, Elwynn, etc; Area = Northshire, Lakeshire, etc.
When several zones uses the same loot definition then:
Note: To be confirmed by TDB developers
As successful fishing should give exactly 1 fish (with an exception for quest fishes) so non-quest part of every loot template should be:
When a fish is caught for a quest it becoms the second fish on the hook. This is blizzlike and fortunately easy to implement. Just add the necessary quest drop definition(s).
For creature_loot_template basic approach is to use creature_template.lootid equal to creature_template.entry. But this results in great overhead in the loot table as:
That is why it is recommended to use grouping, group references and template references.
Agreements for disenchant loot templates numbering is item.ItemLevel * 100 + item.quality where Item is disenchanting target.
As disenchanting should give exactly 1 type of shard/essence/dust/etc so every loot template should be:
There is no use for references here as the reference is done with the relation field. No quest drop at all.
TBD
TBD
Agreements for pickpocketing loot templates numbering is not known.
TBD
Agreements for prospecting loot templates numbering is not known.
TBD
Agreements for skinning loot templates numbering is not known.
It's a real pity as many creatures should use the same templates. In most cases mobs with the same family and level have very similar skinning statistics.
As skinning should give exactly 1 type of skin/hide/etc so every loot template should be:
There is no use for references here as the reference is done with the relation field.
When a skin is pulled for a quest it becoms the second skin from the mob. This is blizzlike and fortunately easy to implement. Just add necessary quest drop definition(s).
Agreements for Reference Templates are as followed:
| Range | Used for |
|---|---|
| 00000-00999 | Skinning Reference Templates |
| 01000-09999 | KEEP FREE: TDB-DEV-References |
| 10000-10999 | Item Reference Templates |
| 11000-11799 | Fishing Reference Templates |
| 11800-11999 | Milling Reference Templates |
| 12000-12899 | Raid: Gameobject Reference Templates |
| 12900-12999 | Mining Reference Templates |
| 13000-13999 | Prospecting Reference Templates |
| 14000-29000 | World Reference Templates |
| 34000-34999 | Raid: Creature Reference Templates |
| 35000-35999 | Dungeon Reference Templates |
Gameobject dropping a single non-quest item
-- Add a single non-quest item to an object
DELETE `gameobject_loot_template` WHERE `Entry`=1419;
INSERT INTO `gameobject_loot_template`
(`Entry`,`Item`,`Chance`,`LootMode`,`GroupId`,`MinCount`,`MaxCount`)
VALUES
(1419,2453,100,0,0,1,3); -- 100% chance to drop a 1 to 3 Bruiseweed
Creature having in the pocket single quest item
-- creature_template: entry=6846, name='Defias Dockmaster', pickpocketloot=6846
-- Note: link with pickpocketing_loot_template is on `pickpocketloot` field (which is equal to `entry` field in this case)
DELETE `pickpocketing_loot_template` WHERE `Entry`=6846;
INSERT INTO `pickpocketing_loot_template`
(`Entry`,`Item`,`Chance`,`LootMode`,`GroupId`,`MinCount`,`MaxCount`)
VALUES
(6846,7675,100,0,0,1,1);
Back to 'creature_loot_template' Return to world Go to 'gameobject_loot_template'