差别

这里会显示出您选择的修订版和当前版本之间的差别。

--- 数据库:world数据库:loot_template [2023/09/24 15:59] – [字段说明] admin
+++ 数据库:world数据库:loot_template [2023/09/24 16:10] (当前版本) – [常规] admin
@@ 行 10: / 行 10: @@
 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|Entry]]|MEDIUMINT UNSIGNED|NO|PRI|0| | | |
@@ 行 65: / 行 66: @@
 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
+<code>
 INSERT INTO `reference_loot_template` (`Entry`, `Item`, `Reference`) VALUES (21215, 0, 21215);
+</code>
 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.
 ==== ChanceOrQuestChance ====
@@ 行 109: / 行 112: @@
 Loot mode examples from the Flame Leviathan fight in Ulduar:
-LootMode	Use
+^LootMode^Use^
-	Normal mode (0 towers)
+|1|Normal mode (0 towers)|
-	Hard mode A (1 tower)
+|2|Hard mode A (1 tower)|
-	Hard mode B (2 towers)
+|4|Hard mode B (2 towers)|
-	Hard mode C (3 towers)
+|8|Hard mode C (3 towers)|
-	Hard mode D (4 towers)
+|16|Hard mode D (4 towers)|
 ==== GroupId ====
@@ 行 121: / 行 125: @@
 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
+  * all equal-chanced entries have the same chance
 *group chance (sum of chances of all entries) is 100%
@@ 行 127: / 行 131: @@
 Of course group may consist of
-only explicitly-chanced entries or
+  * only explicitly-chanced entries or
-only equal-chanced entries or
+  * only equal-chanced entries or
-entries of both type.
+  * entries of both type.
 The easiest way to understand what are groups is to understand how core processes grouped entries:
@@ 行 138: / 行 142: @@
 During loot generation:
-core rolls for explicitly-chanced entries (if any):
+  * core rolls for explicitly-chanced entries (if any):
-**a random number*R **is rolled in range 0 to 100 (floating point value).
+  * **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:
+  * 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.
+  * 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.
+  * 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:
+  * 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.
+  * 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.
+  * 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.
+  * 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.\\ \\
-If*group chance is at least 100 then one item will be dropped for sure.
+  * Processing of equal-chanced part takes much less time then of explicitly-chanced one. So usage of equal-chanced groups is recommended when possible.
-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:
@@ 行 164: / 行 162: @@
 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.
+  * 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.
@@ 行 171: / 行 169: @@
 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.
+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.
+  * 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.
+  * 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.
@@ 行 196: / 行 191: @@
 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 ====
+===== Agreements =====
+----
 These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs (entry) and groups
@@ 行 208: / 行 203: @@
 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 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
+  * 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 single plain entry with 100% drop chance
-or a single group with group chance equal to 100%
+  * 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.
+  * 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).
@@ 行 223: / 行 218: @@
 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)
+  * 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.
+  * 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 ====
@@ 行 231: / 行 226: @@
 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 single plain entry with 100% drop chance
-or a single group with group chance equal to 100%
+  * 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.
@@ 行 260: / 行 255: @@
 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 plain entry with 100% drop chance
-or single group with group chance equal to 100%
+  * 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 ====
+===== Reference Template Numbering =====
+----
 Agreements for Reference Templates are as followed:
-Range	Used for
+^Range^Used for^
--00999	Skinning Reference Templates
+|00000-00999|Skinning Reference Templates|
--09999	KEEP FREE: TDB-DEV-References
+|01000-09999|KEEP FREE: TDB-DEV-References|
--10999	Item Reference Templates
+|10000-10999|Item Reference Templates|
--11799	Fishing Reference Templates
+|11000-11799|Fishing Reference Templates|
--11999	Milling Reference Templates
+|11800-11999|Milling Reference Templates|
--12899	Raid: Gameobject Reference Templates
+|12000-12899|Raid: Gameobject Reference Templates|
--12999	Mining Reference Templates
+|12900-12999|Mining Reference Templates|
--13999	Prospecting Reference Templates
+|13000-13999|Prospecting Reference Templates|
--29000	World Reference Templates
+|14000-29000|World Reference Templates|
--34999	Raid: Creature Reference Templates
+|34000-34999|Raid: Creature Reference Templates|
--35999	Dungeon Reference Templates
+|35000-35999|Dungeon Reference Templates|
-===== Examples =====
+===== Examples =====
+----
 ==== Gameobject dropping a single non-quest item ====
 <code>