creature_loot_template

NOTE: This page is auto-generated from the MAGNET DBDocs module,
Any changes made directly to this page will be lost when it is regenerated.

Description of the 'creature_loot_template' table for MaNGOSTwo

This table format is used to generate different loot items. 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.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Field Name	Field Type	Nullable	Key	Default Value	Notes
entry	mediumint(8) unsigned	NO	PRI	'0'	The ID of the loot definition (loot template).
item	mediumint(8) unsigned	NO	PRI	'0'	Template ID of the item which can be included into the loot.
ChanceOrQuestChance	float	NO		'100'	Meaning of that field is a bit different depending on its sign.
groupid	tinyint(3) unsigned	NO		'0'	A group is a set of loot definitions.
mincountOrRef	mediumint(9)	NO		'1'	This field defines when positive the minimum number of copies of the item.
maxcount	tinyint(3) unsigned	NO		'1'	For non-reference entries - the maximum number of copies of the item.
condition_id	mediumint(8) unsigned	NO		'0'	Value that represents a loot condition that must be filled.

Description of the fields

entry mediumint(8) unsigned

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 mediumint(8) unsigned

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.

ChanceOrQuestChance float

Meaning of that field is a bit different depending on its sign and the sign of mincountOrRef: Plain entry ChanceOrQuestChance > 0, mincountOrRef > 0 Absolute value of ChanceOrQuestChance (actuallu just the value as it's positive in this case) 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. Quest drop ChanceOrQuestChance 0 Just as for plain entries absolute value of ChanceOrQuestChance signifies the percent chance that the item has to drop. But in addition negative ChanceOrQuestChance 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 ReqItemIdN fields or in its ReqSourceIdN fields. The player must also have less copies of the item than ReqItemCountN or ReqSourceCountN. Chanced references mincountOrRef

groupid tinyint(3) unsigned

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 ChanceOrQuestChance) and equal-chanced (ChanceOrQuestChance = 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 easies 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 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 ChanceOrQuestChance 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 ChanceOrQuestChance 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 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%). 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 ChanceOrQuestChance. ¦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 ChanceOrQuestChance. 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

mincountOrRef mediumint(9)

This field defines

¦when positive: the minimum number of copies of the item that can drop in a single loot
¦when negative: a reference to another template.
Zero value makes no sense and should not be used.

Meaning of positive values is quite clear and requires no additional comments. References can point to either a whole template or to single group of a template and decribed below.

Template reference
mincountOrRef
Template reference asks core to process another loot template (having entry equal to "-mincountOrRef") 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 `creature_loot_template` (`entry`,`item`,`mincountOrRef`) 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.

Group reference
mincountOrRef 0

Group reference asks core to process another loot template (having entry equal to "-mincountOrRef") only in the part of one group - with id equal to value of `groupid` field of the reference entry. So this reference may add only none or 1 item into the loot (provided maxcount is equal to 1).

Meaning of maxcount field value is the same as described in Template reference.

Note that there is no way to have a reference as a part of a group as such grouped reference would have the same format as reference to group described here.

There are two types of group references:

¦external reference when group reference row has entry different from entry of the referenced group
¦internal reference when group reference row has the same entry as the referenced group.
Basic usage of group references is to avoid repetition of group definitions when several loot sources have common parts of the loot. In this case it is possible:

¦to define groups with the same contents (items/drop chances) again and again. The simpliest way, but very RAM consumable.
¦to define the group once as a part of one of loot source loot definition and to include group references in loot definitions of the other loot sources instead of repeating group definition.
¦to define the group once as a part of an artificial loot definition (having entry not corresponding to any source) and to include group references in loot definitions for every related loot source.
The first way is deprecated, both second and third use external references. UDB recommends to use the third way.

As references have chance to be processed it is possible to use them effiently for zone or world drop definitions. Those drops often have different chances for different loot sources (low/high skill gameobjects, non-elite/elite creatures etc) while having the same contents of the loot. The recommended way to define such drops is as following:

¦to set up a group with 100% group chance in an artificial loot template (using equal-chanced entries when possible)
¦to include references to that group into loot definition of every related loot source setting the drop chance for the reference.
Some bosses drop more than one tier item (two or three). Loot statistics looks like the same group is rolled 2 or 3 times and every time an item (possible the same) is chosen. It is simple to define a group for single item, but how to define drop for the second and the third? We can:

¦repeat group definition 2 (or 3) times with change of group id
¦define the group once and include 1 (or 2) internal references.
¦define the group once as a part of an artificial loot definition and include 2 (or 3) external group references.
¦define the group once as a part of an artificial loot definition and include an external group reference with repetition factor of 2 (or 3).
The in-game results will be the same. But again - the first way is very inefficient and then deprecated. We recommends to use the forth way.

maxcount tinyint(3) unsigned

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

condition_id mediumint(8) unsigned

Value that represents a loot condition that must be filled in order for the item to drop. This field combined with condition_value1-2 fields can provide conditions on when an item can be dropped.

ID	Type	Description
-3	CONDITION_NOT	Used to evaluate if another condition is NOT true. See Note 1
-2	CONDITION_OR	Used to evaluate if condition OR condition is true. See Note 1
-1	CONDITION_AND	Used to evaluate if condition AND condition is true. See Note 1
0	CONDITION_NONE	This condition is not used at all. Always returns true.
1	CONDITION_AURA	Checks target currently has the specified aura on him/her.
2	CONDITION_ITEM	Checks if the player has the required amount (value2) of items in his/hers inventory.
3	CONDITION_ITEM_EQUIPPED	Checks if the player has the specified item equipped.
4	CONDITION_AREAID	Checks if the player is within the specified area/zone.
5	CONDITION_REPUTATION_RANK_MIN	Checks if the player has the minimum required reputation rank with a specific faction.
6	CONDITION_TEAM	Checks what team the target is a member of (Alliance or Horde).
7	CONDITION_SKILL	Checks if the player has the required minimum skill value of the specified skill.
8	CONDITION_QUESTREWARDED	Checks if the player has complete the specified quest.
9	CONDITION_QUESTTAKEN	Checks if the player has taken the quest (as in has it in his/hers quest log.) and not completed it yet.
10	CONDITION_AD_COMMISSION_AURA	TODO
11	CONDITION_NO_AURA	Checks if the target DOES NOT currently have the specified aura on him/her.
12	CONDITION_ACTIVE_GAME_EVENT	Checks if a game event is currently active.
13	CONDITION_AREA_FLAG	Checks if area_flag is present in current area (if area_flag set != 0) AND if not_have_flag is not present in current area (if not_have_flag != 0)
14	CONDITION_RACE_CLASS	Checks if the target is a certain race AND/OR class.
15	CONDITION_LEVEL	Checks the targets level.
16	CONDITION_NOITEM	Checks if the player DOES NOT have the required amount (value2) of items in his/hers inventory.
17	CONDITION_SPELL	Checks if the target has or hasn't (value2) the specified spell.
18	CONDITION_INSTANCE_SCRIPT	SD3 based condition
19	CONDITION_QUESTAVAILABLE	Checks if the specified quest is available (can start it) for the player.
20	CONDITION_ACHIEVEMENT	Has or has no special achievement.
21	CONDITION_ACHIEVEMENT_REALM	Realm wide achievement (like 20 above but realm wide).
22	CONDITION_QUEST_NONE	Checks if the player has NOT taken the quest AND has NOT been rewarded for the quest.
23	CONDITION_ITEM_WITH_BANK	Checks if the player has the required amount (value2) of items in his/hers inventory OR bank.
24	CONDITION_NOITEM_WITH_BANK	Checks if the player DOES NOT have count (value2) of items in his/hers inventory OR bank.
25	CONDITION_NOT_ACTIVE_GAME_EVENT	Checks if a game event is currently NOT active.
26	CONDITION_ACTIVE_HOLIDAY	Checks if a holiday is active
27	CONDITION_NOT_ACTIVE_HOLIDAY	Checks if a holiday is not active
28	CONDITION_LEARNABLE_ABILITY	Checks if the player can learn ability - using minimum skill value from [See SkillLineAbility.dbc] If the player has spell or has item (when defined) the condition will evaluate to false.
29	CONDITION_SKILL_BELOW	TODO
30	CONDITION_REPUTATION_RANK_MAX	Checks if the player has a higher reputation rank than specified a faction.
31	CONDITION_COMPLETED_ENCOUNTER	Checks if an encounter has been completed.
32	CONDITION_SOURCE_AURA	Checks if the source of the condition (like looted npc) has an aura.
33	CONDITION_LAST_WAYPOINT	Checks the waypoint-state of the source of the condition.
34	CONDITION_XP_USER	Checks if a player has turned XP earning on/off
35	CONDITION_GENDER	Checks the gender of a player.
36	CONDITION_DEAD_OR_AWAY	TODO
37	CONDITION_CREATURE_IN_RANGE	TODO
38	CONDITION_PVP_SCRIPT	TODO
39	CONDITION_SPAWN_COUNT	Returns if specified count of creature entry exists on map.
36	CONDITION_DEAD_OR_AWAY	Checks if a player, a player's group, all players in an instance, or a creature is dead or left the map.

NOTE: For reference entries this field has no meaning, not used by the core in any way and should have the default value of 0.

Sign In

Categories

creature_loot_template

Description of the 'creature_loot_template' table for MaNGOSTwo

User Feedback

Recommended Comments

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Contact Us

Repositories

Support

Wiki

Browse

Activity

My Activity Streams

Important Information