Datenbank 'world'
access_requirement
achievement_criteria_data
achievement_dbc
achievement_reward
achievement_reward_locale
areatrigger_involvedrelation
areatrigger_scripts
areatrigger_tavern
areatrigger_teleport
battleground_template
battlemaster_entry
broadcast_text
broadcast_text_locale
command
conditions
creature
creature_addon
creature_classlevelstats
creature_equip_template
creature_formations
creature_loot_template
creature_model_info
creature_onkill_reputation
creature_questender
creature_questitem
creature_queststarter
creature_summon_groups
creature_template
creature_template_locale
creature_template_addon
creature_text
creature_text_locale
disables
disenchant_loot_template
event_scripts
exploration_basexp
fishing_loot_template
gameobject
gameobject_addon
gameobject_loot_template
gameobject_questender
gameobject_questitem
gameobject_queststarter
gameobject_template
gameobject_template_locale
game_event
game_event_arena_seasons
game_event_battleground_holiday
game_event_condition
game_event_creature
game_event_creature_quest
game_event_gameobject
game_event_gameobject_quest
game_event_model_equip
game_event_npcflag
game_event_npc_vendor
game_event_pool
game_event_prerequisite
game_event_quest_condition
game_event_seasonal_questrelation
game_tele
game_weather
gossip_menu
gossip_menu_option
graveyard_zone
instance_encounters
instance_template
item_enchantment_template
item_loot_template
item_set_names
item_template
lfg_dungeon_rewards
lfg_dungeon_template
linked_respawn
locales_gossip_menu_option
locales_item
locales_item_set_names
locales_npc_text
locales_page_text
locales_points_of_interest
locales_quest
mail_level_reward
mail_loot_template
milling_loot_template
npc_spellclick_spells
npc_text
npc_trainer
npc_vendor
outdoorpvp_template
page_text
pet_levelstats
pet_name_generation
pickpocketing_loot_template
playercreateinfo
playercreateinfo_action
playercreateinfo_item
playercreateinfo_skills
playercreateinfo_spell_custom
player_classlevelstats
player_factionchange_achievement
player_factionchange_items
player_factionchange_quests
player_factionchange_reputations
player_factionchange_spells
player_factionchange_titles
player_levelstats
player_xp_for_level
points_of_interest
pool_creature
pool_gameobject
pool_pool
pool_quest
pool_template
prospecting_loot_template
quest_poi
quest_offer_reward
quest_poi_points
quest_request_items
quest_template
quest_template_addon
reference_loot_template
reputation_reward_rate
reputation_spillover_template
script_waypoint
skill_discovery_template
skill_extra_item_template
skill_fishing_base_level
skill_perfect_item_template
skinning_loot_template
smart_scripts
spelldifficulty_dbc
spell_area
spell_bonus_data
spell_custom_attr
spell_dbc
spell_enchant_proc_data
spell_group
spell_group_stack_rules
spell_learn_spell
spell_linked_spell
spell_loot_template
spell_pet_auras
spell_proc
spell_proc_event
spell_ranks
spell_required
spell_scripts
spell_script_names
spell_target_position
spell_threat
transports
trinity_string
updates
updates_include
vehicle_accessory
vehicle_template_accessory
version
warden_checks
waypoints
waypoint_data
waypoint_scripts
Trinity DB, TrinityCore 2015-09-13, Tec's Ilaros WoW 3.3.5a, Datenbank 'world'

Tabelle: 'item_loot_template'

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.

This table format is used for 12 different tables to generate different loot items for different things. The 12 tables are creature_loot_template, disenchant_loot_template, fishing_loot_template, gameobject_loot_template, item_loot_template, pickpocketing_loot_template, prospecting_loot_template, skinning_loot_template, quest_mail_loot_template, reference_loot_template, milling_loot_template, spell_loot_template. The general description here is valid for all 12 because the loot system is the same for all eleven.

Loot templates define only items in the loot. See comments about money drop in corpse, pickpocketing and luggage loot in creature_templateand item_template.

Structure

FieldTypeNullKeyDefaultExtra

Entry

mediumint vorzeichenlosneinPRI0
Itemmediumint vorzeichenlosneinPRI0
Referencemediumint vorzeichenlosNO0
Chancefloat

nein100
QuestRequiredboolNO0
LootModesmallintnein1
GroupIdtinyintnein0

MinCountmediumintnein1
MaxCounttinyint vorzeichenlosnein1
Commentvarchar

Relations

The 11 tables have different relations with other DB tables.

Loot table

Field

Relation

Related table

Field

Comment

fishing_loot_templateno relationentry is linked with ID of the fishing zone or area
creature_loot_templateentrymany <- manycreature_templatelootid
gameobject_loot_templateentrymany <- manygameobject_templatedata1Only 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_templateentrymany <- oneitem_templateentry
disenchant_loot_templateentrymany <- manyitem_templateDisenchantID
prospecting_loot_templateentry

many <- one

item_templateentry
milling_loot_templateentrymany <- oneitem_templateentry
pickpocketing_loot_templateentry

many <- manycreature_templatepickpocketloot
skinning_loot_templateentrymany <- manycreature_templateskinlootCan also store minable/herbable items gathered from creatures

quest_mail_loot_template

entryquest_templateRewardMailTemplateId
reference_loot_templateentrymany <- many
  • _loot_template
-mincountOrRefIn case of negative mincountOrRef
spell_loot_templateentrymany <- manySpell (DBC)SpellId

Description of the fields

Entry

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.

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.

Reference

Template reference asks core to process another loot templateand to include all items dropped for that template into current loot. Simple idea.

Value of MaxCountfield is used as a repetition factor for references - the reference will be processed not just once but exactly MaxCounttimes. So if the referenced template can produce 3 to 10 items (depending on luck) and value ofMaxCountis '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 forgroup referencessometimes.

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) arecompletelydifferent frominternal references. If you make a self-reference like

then the core will crash due to stack overflow at first attempt of loot 21215 processing. That is whyself references and loop references are strictly forbidden.

Chance

Item drop chance (plain entry or quest entry). Not sure how this functions for loot reference items.

Plain entry

Chance

> 0

Absolute value of Chancesignifies 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.

Quest drop

Chance

> 0

Absolute value ofChancesignifies 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 Chancesignifies the percent chance that the item has to drop. But in addition negative Chance

Chanced references

For ReferenceentriesChancesignifies 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.

Negative and zero values of Chancemake no sense for that case and should not be used.

Common remarks

Zero value of Chanceis allowed for grouped entries only.

(Non-zero) values of Chancein 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.

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 onequestthat has theitem IDin itsRequiredItemIdfields or in itsRequiredSourceItemIdfields. The player must also have less copies of the item thanRequiredItemCount orRequiredSourceItemCount.

LootMode

A special parameter used for separating conditional loot, such as Hard Mode loot. A lootmode of 0 will effectively disable a loot entry (it's 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.

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

  • all equal-chanced entries have the same chance

    *group chance (sum of chances of all entries) is 100%

Of course group may consist of

  • only explicitly-chanced entries or
  • only equal-chanced entries or
  • entries of both type.

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):
  • a random number*Ris 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%).

If you understand the process you can understand the results:

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

    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.

    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.

So now basic applications of the groups are clear:

Groups with group chance of 100% generate*exactly one

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 every time keeping chances 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 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 a limitation - 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. And this is not a caprice of core devs - the client has some constraints. 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.

MinCount

The minimum number of copies of the item that can drop in a single loot

  • Zero value makes no sense and should not be used.

MaxCount

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 devorzeichenbehaftet 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).

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) 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)

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

  • 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

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

  • 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

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, 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

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

Gameobject harvest

TBD

Luggage contents

TBD

Pocket pick-ups

Agreements for pickpocketing loot templates numbering is not known.

TBD

Prospecting outcome

Agreements for prospecting loot templates numbering is not known.

TBD

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

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

Agreements for Reference Templates are as followed:

RangeUsed for
00000-00999Skinning Reference Templates
01000-09999

KEEP FREE: TDB-DEV-References

10000-10999Item Reference Templates
11000-11799Fishing Reference Templates
11800-11999Milling Reference Templates
12000-12899Raid: Gameobject Reference Templates
12900-12999Mining Reference Templates
13000-13999Prospecting Reference Templates
14000-29000World Reference Templates
34000-34999Raid: Creature Reference Templates
35000-35999Dungeon Reference Templates

Examples

All examples are maintained by ZxBiohazardZx if you have any questions or if you want to see a particular example then ask in the IRC.

ZxBiohazardZx is on IRC?

Simple examples

Gameobject dropping a single non-quest item

Creature having in the pocket single quest item

Wrong definition: combined quest and non-quest chances

OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!!

Groups

Simple skinning group

gives

OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!!

Almost correct skinning loot

gives
OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!!

Damnly wrong skinning loot

gives

OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!!


Votet bitte für uns und bringt uns so neue Spieler!
Stimme zählen für Account:
WoW Portal MPOG TOP WoW Servers NET Private Server
Gametoor Top 100 Arena Top G Top of Games Oxigen Top 100 List
Facebook YouTube
Impressum