diff options
| author | Kitzunu <24550914+Kitzunu@users.noreply.github.com> | 2021-11-18 02:33:42 +0100 |
|---|---|---|
| committer | Kitzunu <24550914+Kitzunu@users.noreply.github.com> | 2021-11-18 02:33:42 +0100 |
| commit | d58078a4d1e6e0732f8d80f1baec53d498e12592 (patch) | |
| tree | 6cae120904e26663de5720147e2d76b4912f5a97 /docs | |
| parent | 5e244c5e6dcb05d6d8c52e4a0a727d52999c73a6 (diff) | |
| download | wiki-d58078a4d1e6e0732f8d80f1baec53d498e12592.tar.gz wiki-d58078a4d1e6e0732f8d80f1baec53d498e12592.tar.bz2 wiki-d58078a4d1e6e0732f8d80f1baec53d498e12592.zip | |
chore: update loot_template
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/loot_template.md | 115 |
1 files changed, 58 insertions, 57 deletions
diff --git a/docs/loot_template.md b/docs/loot_template.md index 3241cd5..8c7f27b 100644 --- a/docs/loot_template.md +++ b/docs/loot_template.md @@ -15,12 +15,12 @@ Loot templates define only items in the loot. See comments about money drop in c ## Structure | Field | Type | Null | Key | Default | Extra | Comment | -|---------------------|--------------------|------|-----|---------|-------|---------| +| ------------------- | ------------------ | ---- | --- | ------- | ----- | ------- | | [Entry][1] | MEDIUMINT UNSIGNED | NO | PRI | 0 | | | | [Item][2] | MEDIUMINT UNSIGNED | NO | PRI | 0 | | | | [Reference][3] | MEDIUMINT UNSIGNED | NO | | 0 | | | | [Chance][4] | FLOAT | NO | | 100 | | | -| [QuestRequired]][5] | bool | NO | | 0 | | | +| [QuestRequired][5] | bool | NO | | 0 | | | | [LootMode][6] | SMALLINT | NO | | 1 | | | | [GroupId][7] | TINYINT | NO | | 0 | | | | [MinCount][8] | MEDIUMINT | NO | | 1 | | | @@ -42,20 +42,21 @@ Loot templates define only items in the loot. See comments about money drop in c The 11 tables have different relations with other DB tables. -| Loot table | Field | Relation | Related table | Field | Comment | -|-------------------------------|-------------------------------|-----------------------------------------------------------------------------|-------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------| -| fishing\_loot\_template | no relation | [entry](#loot_template-entry) is linked with ID of the fishing zone or area | | | | -| creature\_loot\_template | [entry](#loot_template-entry) | many <- many | [creature\_template](creature_template) | [lootid](creature_template#creature_template-lootid) | | -| gameobject\_loot\_template | [entry](#loot_template-entry) | many <- many | [gameobject\_template](gameobject_template) | [data1](gameobject_template#gameobject_template-data0-23) | Only gameobject type 3 (GAMEOBJECT\_TYPE\_CHEST) or 25 (GAMEOBJECT\_TYPE\_FISHINGHOLE) use data1 as loot ID, for other types data1 is used in other ways | -| item\_loot\_template | [entry](#loot_template-entry) | many <- one | [item\_template](item_template) | [entry](item_template#item_template-entry) | | -| disenchant\_loot\_template | [entry](#loot_template-entry) | many <- many | [item\_template](item_template) | [DisenchantID](item_template#item_template-DisenchantID) | | -| prospecting\_loot\_template | [entry](#loot_template-entry) | many <- one | [item\_template](item_template) | [entry](item_template#item_template-entry) | | -| milling\_loot\_template | [entry](#loot_template-entry) | many <- one | [item\_template](item_template) | [entry](item_template#item_template-entry) | | -| pickpocketing\_loot\_template | [entry](#loot_template-entry) | many <- many | [creature\_template](creature_template) | [pickpocketloot](creature_template#creature_template-pickpocketloot) | | -| skinning\_loot\_template | [entry](#loot_template-entry) | many <- many | [creature\_template](creature_template) | [skinloot](creature_template#creature_template-skinloot) | Can also store minable/herbable items gathered from creatures | -| quest\_mail\_loot\_template | [entry](#loot_template-entry) | | [quest\_template](quest_template) | [RewardMailTemplateId](quest_template#quest_template-RewardMailTemplateId) | | -| reference\_loot\_template | [entry](#loot_template-entry) | many <- many | - \_loot\_template | [-mincountOrRef](#loot_template-mincountOrRef) | In case of negative mincountOrRef | -| spell\_loot\_template | [entry](#loot_template-entry) | many <- many | [Spell](Spell) (DBC) | SpellId | | +| Loot table | Field | Relation | Related table | Field | Comment | +| ----------------------------- | ----------------------------- | --------------------------------------------------------------------------- | ------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| fishing\_loot\_template | no relation | [entry](#entry) is linked with ID of the fishing zone or area | | | | +| creature\_loot\_template | [entry](#entry) | many <- many | [creature\_template](creature_template) | [lootid](creature_template#lootid) | | +| gameobject\_loot\_template | [entry](#entry) | many <- many | [gameobject\_template](gameobject_template) | [data1](gameobject_template#data0-23) | Only gameobject type 3 (GAMEOBJECT\_TYPE\_CHEST) or 25 (GAMEOBJECT\_TYPE\_FISHINGHOLE) use data1 as loot ID, for other types data1 is used in other ways | +| item\_loot\_template | [entry](#entry) | many <- one | [item\_template](item_template) | [entry](item_template#entry) | | +| disenchant\_loot\_template | [entry](#entry) | many <- many | [item\_template](item_template) | [DisenchantID](item_template#disenchantid) | | +| prospecting\_loot\_template | [entry](#entry) | many <- one | [item\_template](item_template) | [entry](item_template#entry) | | +| milling\_loot\_template | [entry](#entry) | many <- one | [item\_template](item_template) | [entry](item_template#entry) | | +| pickpocketing\_loot\_template | [entry](#entry) | many <- many | [creature\_template](creature_template) | [pickpocketloot](creature_template#pickpocketloot) | | +| player\_loot\_template | no relation | [entry](#entry) is linked with player | | | TeamID. 0 = Horde, 1 = Alliance | +| skinning\_loot\_template | [entry](#entry) | many <- many | [creature\_template](creature_template) | [skinloot](creature_template#skinloot) | Can also store minable/herbable items gathered from creatures | +| quest\_mail\_loot\_template | [entry](#entry) | | [quest\_template](quest_template) | [RewardMailTemplateId](quest_template#rewardmailtemplateid) | | +| reference\_loot\_template | [entry](#entry) | many <- many | - \_loot\_template | [-mincountOrRef](#mincountorref) | In case of negative mincountOrRef | +| spell\_loot\_template | [entry](#entry) | many <- many | [Spell](spell) (DBC) | SpellId | | ## Description of the fields @@ -63,27 +64,27 @@ The 11 tables have different relations with other DB tables. 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](#loot_template-Relations) 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 often the same ID as the loot source (item, creature, etc) but when the [link](#relations) 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](#loot_template-Template_reference) from "normal" loot templates. +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](#reference) 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](#loot_template-Agreements). +Agreements on **Entry** field values are described [there](#agreements). ### Item Template ID of the item which can be included into the loot. -NOTE: For [reference entries](#loot_template-mincountOrRef) this field has no meaning and 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. +NOTE: For [reference entries](#mincountorref) this field has no meaning and 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. ### Reference 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 M[axCount](#loot_template-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](#loot_template-Group_reference) sometimes. +Value of [MaxCount](#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](#group_reference) 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](#loot_template-Group_reference). If you make a self-reference like +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](#group_reference). If you make a self-reference like ```sql INSERT INTO `reference_loot_template` (`Entry`, `Item`, `Reference`) VALUES (21215, 0, 21215); @@ -107,23 +108,23 @@ Absolute value of **Chance** signifies the percent chance that the item has to Absolute value of **Chance** signifies the percent chance that the item has to drop. Any floating point number is allowed but indeed any value larger that 100 will make the same result as 100. -Just as for [plain entries](#loot_template-Plain_entry) absolute value of **Chance **signifies the percent chance that the item has to drop. But in addition negative **Chance** +Just as for [plain entries](#plain_entry) absolute value of **Chance **signifies the percent chance that the item has to drop. But in addition negative **Chance** ### Chanced references -For **Reference** **entries** **Chance** signifies the percent chance that the reference has to be used. So it is very similar to [plain entries](#loot_template-Plain_entry) meaning, just note that entire reference is skipped if the chance is missed. +For **Reference** **entries** **Chance** signifies the percent chance that the reference has to be used. So it is very similar to [plain entries](#plain_entry) meaning, just note that entire reference is skipped if the chance is missed. Negative and zero values of **Chance** make no sense for that case and should not be used. ### Common remarks -Zero value of **Chance** is allowed for [grouped entries](#loot_template-groupid) only. +Zero value of **Chance** is allowed for [grouped entries](#groupid) only. (Non-zero) values of **Chance** in loot definition are multiplied by Rate.Drop.Item.XXX (worldserver.conf settings) during loot generation for references and non-reference entries, **but not for grouped entries.** It only works when `groupid` is equal to 0. ### QuestRequired - 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](quest_template) that has the [item ID](#loot_template-item) in its [RequiredItemId](quest_template#quest_template-RequiredItemId) fields or in its [RequiredSourceItemId](quest_template#quest_template-RequiredSourceItemId) fields. The player must also have less copies of the item than [RequiredItemCount](quest_template#quest_template-RequiredItemCount) or [RequiredSourceItemCount](quest_template#quest_template-RequiredSourceItemCount). + 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](quest_template) that has the [item ID](#item) in its [RequiredItemId](quest_template#requireditemid) fields or in its [RequiredSourceItemId](quest_template#requiredsourceitemid) fields. The player must also have less copies of the item than [RequiredItemCount](quest_template#requireditemcount) or [RequiredSourceItemCount](quest_template#requiredsourceitemcount). ### LootMode @@ -132,7 +133,7 @@ A special parameter used for separating conditional loot, such as Hard Mode loot Loot mode examples from the Flame Leviathan fight in Ulduar: | LootMode | Use | -|----------|------------------------| +| -------- | ---------------------- | | 1 | Normal mode (0 towers) | | 2 | Hard mode A (1 tower) | | 4 | Hard mode B (2 towers) | @@ -141,9 +142,9 @@ Loot mode examples from the Flame Leviathan fight in Ulduar: ### GroupId -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](#loot_template-item) from the items declared in the loot definitions of the group. Groups are formed by loot definitions having the same values of [entry](#loot_template-entry) and **GroupId** fields. +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](#item) from the items declared in the loot definitions of the group. Groups are formed by loot definitions having the same values of [entry](#entry) and **GroupId** fields. -A group may consists of **explicitly-chanced** (having non-zero [Chance](#loot_template-ChanceOrQuestChance)) and **equal-chanced** ([Chance](#loot_template-ChanceOrQuestChance) = 0) entries. Every *equal-chanced* entry of a group is considered having such a chance that: +A group may consists of **explicitly-chanced** (having non-zero [Chance](#chance)) and **equal-chanced** ([Chance](#chance) = 0) entries. Every *equal-chanced* entry of a group is considered having such a chance that: - all equal-chanced entries have the same chance @@ -166,13 +167,13 @@ During loot generation: - core rolls for explicitly-chanced entries (if any): - **a random number\*R **is rolled in range 0 to 100 (floating point value). - chance to drop is checked for every (explicitly-chanced) entry in the group: -- **if\*R** is less than absolute value of [Chance](#loot_template-ChanceOrQuestChance) of the entry then the entry 'wins': the [Item](#loot_template-item) is included in the loot. Group processing stops, the rest of group entries are just skipped. -- **otherwise the entry 'looses': the [Item](#loot_template-item) misses its chance to get into the loot.\*R** is decreased by the absolute value of [Chance](#loot_template-ChanceOrQuestChance) and next explicitly-chanced entry is checked. +- **if\*R** is less than absolute value of [Chance](#chance) of the entry then the entry 'wins': the [Item](#item) is included in the loot. Group processing stops, the rest of group entries are just skipped. +- **otherwise the entry 'looses': the [Item](#item) misses its chance to get into the loot.\*R** is decreased by the absolute value of [Chance](#chance) and next explicitly-chanced entry is checked. - if none of explicitly-chanced entries got its chance then equal-chanced part (if any) is processed: -- a random entry is selected from the set of equal-chanced entries and corresponding [Item](#loot_template-item) is included in the loot. +- a random entry is selected from the set of equal-chanced entries and corresponding [Item](#item) is included in the loot. - If nothing selected yet (this never happens if the group has some equal-chanced entries) - no item from the group is included into the loot. -Let us use term **group chance** as the sum of [Chance](#loot_template-ChanceOrQuestChance) (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%). +Let us use term **group chance** as the sum of [Chance](#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: @@ -180,7 +181,7 @@ If you understand the process you can understand the results: **If\*group chance** is at least 100 then one item will be dropped for sure. -- If *group chance* does not exceed 100 then every item defined in group entries has *exactly* that chance to drop as set in [Chance](#loot_template-ChanceOrQuestChance). +- If *group chance* does not exceed 100 then every item defined in group entries has *exactly* that chance to drop as set in [Chance](#chance). **If *group chance* is greater than 100 then some entries will lost a part of their chance (or even not be checked at all - that will be the case for all equal-chanced entries) whatever value takes the roll\*R**. So for some items chance to drop will be less than their [Chance](#loot_template-ChanceOrQuestChance). That is *very* bad and that is why having *group chance* > 100 is strictly prohibited. @@ -188,12 +189,12 @@ If you understand the process you can understand the results: So now basic applications of the groups are clear: -**Groups with *group chance* of 100% generate\*exactly one** [item](#loot_template-item) every time. This is needed quite often, for example such behavior is needed to define a loot template for tier item drop from a boss. -**Groups with *group chance* < 100 generate\*one or zero** [items](#loot_template-item) every time keeping [chances](#loot_template-ChanceOrRef) of every item unchanged. Such behavior is useful to limit maximum number of items in the loot. +**Groups with *group chance* of 100% generate\*exactly one** [item](#item) every time. This is needed quite often, for example such behavior is needed to define a loot template for tier item drop from a boss. +**Groups with *group chance* < 100 generate\*one or zero** [items](#item) every time keeping [chances](#chance) of every item unchanged. Such behavior is useful to limit maximum number of items in the loot. -- 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](#loot_template-Group_reference) for more details. +- 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](#reference) for more details. -There is no way to have a [reference](#loot_template-mincountOrRef) as a part of a group. +There is no way to have a [reference](#mincountOrRef) 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. @@ -222,15 +223,15 @@ The minimum number of copies of the item that can drop in a single loot For non-reference entries - the maximum number of copies of the item that can drop in a single loot. -For [references](#loot_template-Template_reference) value of **MaxCount** field is used as a repetition factor for references - the reference will be processed not just once but exactly **MaxCount** times. This is designed to serve a single purpose: to make definition of tier token drops a bit simplier (tokens of a tier are defined as a 100%-chance group of an artificial template and bosses' loot templates include 100%-chanced reference to that group with repetition factor of 2 or 3 depending on the case). Using non-1 repetition factor for other things (references to a group with *group chance* less than 100% or [chanced references](#loot_template-Chanced_references) with chance less than 100%) must be agreed with TDB devs first (and described here). +For [references](#reference) value of **MaxCount** field is used as a repetition factor for references - the reference will be processed not just once but exactly **MaxCount** times. This is designed to serve a single purpose: to make definition of tier token drops a bit simplier (tokens of a tier are defined as a 100%-chance group of an artificial template and bosses' loot templates include 100%-chanced reference to that group with repetition factor of 2 or 3 depending on the case). Using non-1 repetition factor for other things (references to a group with *group chance* less than 100% or [chanced references](#reference) with chance less than 100%) must be agreed with TDB devs first (and described here). Note: core rolls chance for any loot definition entry just one time - so if a references looses its chance it is skipped for the current loot completely whatever is **MaxCount** value. ## Agreements -These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs ([entry](#loot_template-entry)) and groups +These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs ([entry](#entry)) and groups -## Fishing haul +### Fishing haul For fishing\_loot\_template, ID is the zone or area ID from AreaTable.dbc (Note: Area IDs are not included in the link) @@ -239,7 +240,7 @@ Also an extra note on fishing\_loot\_template: if just one area ID is defined fo When several zones uses the same loot definition then - the loot template of the zone with minimal ID (minID) should be defined without references -- the other zone with the same loot should have loot definition as a single [reference](#loot_template-mincountOrRef) to the minID loot definition +- the other zone with the same loot should have loot definition as a single [reference](#mincountorref) to the minID loot definition Note: To be confirmed by TDB developers @@ -247,68 +248,68 @@ As successful fishing should give exactly 1 fish (with an exception for quest fi - or single [plain entry](#loot_template-Plain_entry) with 100% drop chance - or a single group with [*group chance*](#loot_template-groupid) equal to 100% -- or a reference to a template made according to previous two variants. It is recommended to use [group references](#loot_template-Group_reference). +- or a reference to a template made according to previous two variants. It is recommended to use [group references](#groupid). When a fish is catched for a quest it becoms the *second* fish on the hook. Many people rolled on floor laughing but this is blizzlike and fortunately easy to implement. Just add necessary [quest drop](#loot_template-Quest_drop) definition(s). -## Corpse loot +### Corpse loot 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 - many creatures use the same loot definition (well, stats on sites are *similar* due to the nature of random roll) - even more creatures use same parts of loot definition - That is why it is recommended to use [grouping](#loot_template-groupid), [group references](#loot_template-Group_reference) and [template references](#loot_template-Template_reference). + That is why it is recommended to use [grouping](#groupid), [group references](#groupid) and [template references](#reference). -## Disenchant outcome +### Disenchant outcome 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 -- or single [plain entry](#loot_template-Plain_entry) with 100% drop chance -- or a single group with [*group chance*](#loot_template-groupid) equal to 100% +- or single [plain entry](#entry) with 100% drop chance +- or a single group with [*group chance*](#groupid) equal to 100% There is no use for references here as the reference is done with the relation field. No quest drop at all. -## Gameobject harvest +### Gameobject harvest ***TBD*** -## Luggage contents +### Luggage contents ***TBD*** -## Pocket pick-ups +### Pocket pick-ups Agreements for pickpocketing loot templates numbering is not known. ***TBD*** -## Prospecting outcome +### Prospecting outcome Agreements for prospecting loot templates numbering is not known. ***TBD*** -## Skinning pulls +### Skinning pulls 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 -- or single [plain entry](#loot_template-Plain_entry) with 100% drop chance -- or single group with [*group chance*](#loot_template-groupid) equal to 100% +- or single [plain entry](#entry) with 100% drop chance +- or single group with [*group chance*](#groupid) equal to 100% 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. Yes, funny. This is blizzlike and fortunately easy to implement. Just add necessary [quest drop](#loot_template-Quest_drop) definition(s). +When a skin is pulled for a quest it becoms the *second* skin from the mob. Yes, funny. This is blizzlike and fortunately easy to implement. Just add necessary [quest drop](#questrequired) definition(s). ## Reference Template Numbering 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 | |