Back-to:World

Tables: *_

...

loot_template

General

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.

...

Relations

The 11 tables have different relations with other DB tables.

Description of the fields

...

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.

...

Agreements on Entry field values are described there.

Item

Template ID of the item which can be included into the loot.

NOTE: For reference entries 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.

...

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

...

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 absolute value of Chance signifies the percent chance that the item has to drop. But in addition negative Chance

...

For Reference entries Chance signifies the percent chance that the reference has to be used. So it is very similar to plain entries meaning, just note that entire reference is skipped if the chance is missed.

...

Zero value of Chance is allowed for grouped entries only.

(Non-zero) values of Chance in loot definition are multiplied by RATE_DROP_ITEMS (mangos 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 RequiredSourceItemId fields. The player must also have less copies of the item than RequiredItemCount or RequiredSourceItemCount.

...

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) 74219462 gameobject_loot_template from the items declared in the loot definitions of the group. Groups are formed by loot definitions having the same values of 74219462 gameobject_loot_template 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:

...

• 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 of the entry then the entry 'wins': the Item is included in the loot. Group processing stops, the rest of group entries are just skipped.
  • otherwise the entry 'looses': the Item misses its chance to get into the loot.*R is decreased by the absolute value of 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 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 (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%).

...

• Not more than one item from a group may drop at any given time.

  Panel
  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.

  Panel
  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. That is very bad and that is why having group chance > 100 is strictly prohibited.

• Processing of equal-chanced part takes much less time then of explicitly-chanced one. So usage of equal-chanced groups is recommended when possible.

...

• 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: 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.

...

For non-reference entries - the maximum number of copies of the item that can drop in a single loot.

For references 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 with chance less than 100%) must be agreed with TDB devs first (and described here).

...

These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs (74219462gameobject_loot_template) and groups

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)

...

• 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 to the minID loot definition

...

As successful fishing should give exactly 1 fish (with an exception for quest fishes) so non-quest part of every loot template should be

• or single plain entry with 100% drop chance
• or a single group with group chance equal to 100%
• or a reference to a template made according to previous two variants. It is recommended to use group references.

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 definition(s).

Corpse loot

...

• 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, group references and template references.

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 with 100% drop chance
• or a single group with group chance equal to 100%

There is no use for references here as the reference is done with the relation field. No quest drop at all.

...

As skinning should give exactly 1 type of skin/hide/etc so every loot template should be

• or single plain entry with 100% drop chance
• or single group with group chance 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 definition(s).

Reference Template Numbering

...