Mangos loot templates

Z WoWResource Wiki
Přejít na: navigace, hledání

Zpět na seznam tabulek world databáze.


(POZOR! Toto je anglický originál z UDB wiki, na jehož překladu se zatím ještě pracuje.)


Tabulky `*_loot_template`

Podle slovníku, je význam slova "loot" (česky: kořist) vhodný jako označení pro kořsit získanou z mrtvoly creatury, nebo kořist získanou z některých gameobjectů (chests - truhly), ale pro "fishing skill" (rybolov) není zas až tak vhodným označením. Nevadí. Budeme používat termín "loot", v našem případě jako "seznam itemů, které se pro hráče budou generovat"; termín "loot definice", jako "seznam pravidel pro generování kořisti". '(Loot se generuje v závislosti na jistých podmínkách.)

Formát této tabulky je používán pro 12 různých tabulek ke generování kořisti itemů pro různé události. Obecný popis zde platí pro všechny tabulky `*_loot_template`, protože loot systém je stejný pro všech dvanáct tabulek. Jedná se o tyto tabulky:

  • creature_loot_template
  • disenchant_loot_template
  • fishing_loot_template
  • gameobject_loot_template
  • item_loot_template
  • pickpocketing_loot_template
  • prospecting_loot_template
  • skinning_loot_template
  • spell_loot_template
  • quest_mail_loot_template
  • reference_loot_template
  • milling_loot_template

Tabulky lootu definují pouze itemy v kořisti. Viz. komentáře o "money dropu" mrtvol, "pickpocketing" a "luggage" loot v creature_template a item_template.


Struktura

Pole Typ Null Key Výchozí hodnota Extra
entry mediumint unsigned NE PRI 0
item mediumint unsigned NE PRI 0
ChanceOrQuestChance float NE 100
groupid tinyint NE 0
mincountOrRef mediumint NE 1
maxcount tinyint unsigned NE 1
lootcondition tinyint unsigned NE 0
condition_value1 mediumint unsigned NE 0
condition_value2 mediumint unsigned NE 0


Vztahy

Všech 12 tabulek má různé vztahy s ostatními tabulkami databáze. Viz.:

Loot tabulka Pole Vztah Vztahující se tabulka Pole Komentář / popis
fishing_loot_template žádný vztah entry je spojeno s ID rybolovné zóny nebo oblasti (zone/area)
spell_loot_template žádný vztah entry je spojeno s ID spellu
creature_loot_template entry mnoho <- mnoho creature_template lootid
gameobject_loot_template entry mnoho <- mnoho gameobject_template data1 Pouze gameobjecty typu '3' (GAMEOBJECT_TYPE_CHEST), nebo '25' (GAMEOBJECT_TYPE_FISHINGHOLE) používají `data1` jako loot ID. Pro ostatní typy je pole `data1` využito k jiným účelům.
item_loot_template entry mnoho <- jeden item_template entry
disenchant_loot_template entry mnoho <- mnoho item_template DisenchantID
prospecting_loot_template entry mnoho <- jeden item_template entry
milling_loot_template entry mnoho <- jeden item_template entry
pickpocketing_loot_template entry mnoho <- mnoho creature_template pickpocketloot
skinning_loot_template entry mnoho <- mnoho creature_template skinloot Může také uchovávat minable/herbable itemy získávané od creatur
quest_mail_loot_template entry quest_template RewMailTemplateId
reference_loot_template entry mnoho <- mnoho *_loot_template -mincountOrRef V případě negativní hodnoty mincountOrRef


Popis polí tabulky

entry

ID loot definice (loot šablony). Řádky se stejným ID definují jednu kořist.
ID lootu bývají často shodná se zdrojem odkud pocházejí (item, creatura, atd.), ale pokud se neodkazuje na pole entry související tabulky, pak ID může být různé.
Například když několik zdrojů lootu poskytuje stejnou kořist, může být použita jen jedna loot definice. V tomto případě zdroje lootu mají stejnou hodnotu v odkazovaném poli.

Je možné také nastavit "artificial loot templates" (umělé šablony kořisti), které nejsou používány přímo, protože mají ID, které nejsou referovány ze souvisejících zdrojů. Takové "podpůrné šablony" se pak mohou odkazovat z "normálních" šablon kořisti.

Je-li použita běžná nebo umělá šablona kořisti, vznikne problém: "Co za ID použít pro tuto šablonu?" V závislosti na tabulce lootu, mohou být ve vašem týmu domluvena různá pravidla na zjednodušení údržby a orientace v tabulce.

item

Template ID itemu, který bude začleněn do lootu.

POZNÁMKA: Referenční záznamy v tomto poli nemají žádný smysl, jádro je v nepoužívá. Přesto kvůli PRIMARY KEY v polích entry a item, bude toto pole muset obsahovat jedinečnou hodnotu pro každý referenční vstup tak, aby nevznikali konflikty při indexování.

ChanceOrQuestChance

Význam tohoto pole se trochu liší v závislosti na jeho znamínku (hodnota kladná/záporná) a znamínku pole mincountOrRef.

Prostý zápis

ChanceOrQuestChance > '0', mincountOrRef > '0'

Kladná hodnota pole ChanceOrQuestChance (v tomto případě se zadávají jen o kladné hodnoty) znamená procentuelní šanci, že item bude v lootu. Může to být jakékoliv číslo s desetinou čárkou. Zadávání vyšších hodnot než '100' nemá žádný smysl - loot systém se bude chovat stejně jako při hodnotě '100'.

Quest drop

ChanceOrQuestChance < '0', mincountOrRef > '0'

Stejně jako u prostého zápisu, kladná hodnota ChanceOrQuestChance znamená procentuelní šanci, že item bude v lootu. Záporná hodnota ChanceOrQuestChance odkazující se na quest_template.entry informuje jádro, které itemy z lootu budou dostupné jen hráčům, kteří mají odpovídající quest. To znamená, že hráč musí mít quest, který má ID itemu v poli ReqItemIdN nebo ReqSourceIdN. Hráč dále nesmí mít těchto itemů u sebe více, než je uvedeno v poli ReqItemCountN nebo v poli ReqSourceCountN.

Chanced references

mincountOrRef < 0

Záporná hodnota mincountOrRef (referenční údaje) ChanceOrQuestChance znamená procentuelní pravděpodobnost, že reference bude použita. Má to velmi podobný význam jako prostý zápis, jen na berte vědomí, že celá reference je přeskočena, pokud je šance ztracena (pokud se jí nedosáhne).

Záporné a nulové hodnoty pole ChanceOrQuestChance nemají v tomto případě žádný význam a neměly by být používány.

Obecné poznámky

Nulová hodnota pole ChanceOrQuestChance je povolena pouze pro seskupené záznamy (groipid).

Nenulové hodnoty pole ChanceOrQuestChance v loot definicích jsou násobeny RATE_DROP_ITEMS (nastaveno v souboru mangosd.conf) během generování referenčních a nereferenčních položek (entry) lootu, ale né pro seskupené záznamy.


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

mincountOrRef

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 < 0, group = 0

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 > 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. UDB recommends to use the forth way.

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

lootcondition

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.

Value Condition Comments
0 CONDITION_NONE Regular drop
1 CONDITION_AURA Player looting must have an aura active
2 CONDITION_ITEM Player must have a number of items in his/her inventory
3 CONDITION_ITEM_EQUIPPED Player must have an item equipped
4 CONDITION_ZONEID Player must be in a certain zone
5 CONDITION_REPUTATION_RANK Player must have a certain reputation rank with a certain faction
6 CONDITION_TEAM Player must be part of the specified team (Alliance or Horde)
7 CONDITION_SKILL Player must have a certain skill value
8 CONDITION_QUESTREWARDED Player must have completed a quest first
9 CONDITION_QUESTTAKEN Players must have the quest in the quest log and not completed yet
10 CONDITION_AD_COMMISSION_AURA
11 CONDITION_NO_AURA Miss some aura.
12 CONDITION_ACTIVE_EVENT While some event is active.
13 CONDITION_AREA_FLAG
14 CONDITION_RACE_CLASS Has special race or class.
15 CONDITION_LEVEL Has special level.
16 CONDITION_NOITEM Has not enouth items yet.
17 CONDITION_SPELL Knows some spell.
18 CONDITION_INSTANCE_SCRIPT SD2-Based condition
19 CONDITION_QUESTAVAILABLE Some quest is availible.
20 CONDITION_ACHIEVEMENT Has or has no special achievement.
21 CONDITION_ACHIEVEMENT_REALM Realm-wideversion of 20.
22 CONDITION_QUEST_NONE Has not taken a quest yet.

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.

condition_value

The values in the condition_value1 and condition_value2 fields depend on what condition was put in lootcondition.

  • CONDITION_AURA
    • condition_value1: The spell ID from where the aura came from.
    • condition_value2: The effect index of the spell that applied the aura (0, 1, or 2)
  • CONDITION_ITEM
    • condition_value1: Item ID
    • condition_value2: Count
  • CONDITION_ITEM_EQUIPPED
    • condition_value1: Item ID
    • condition_value2: Always 0
  • CONDITION_ZONEID
    • condition_value1: Zone ID
    • condition_value2: Always 0
  • CONDITION_REPUTATION_RANK
    • condition_value1: Faction ID
    • condition_value2: Minimum rank
  • CONDITION_TEAM
    • condition_value1: Player team (469 - Alliance, 67 - Horde)
    • condition_value2: Always 0
  • CONDITION_SKILL
    • condition_value1: Skill ID (SkillLine.dbc)
    • condition_value2: Skill value needed
  • CONDITION_QUESTREWARDED
    • condition_value1: Quest ID
    • condition_value2: Always 0
  • CONDITION_QUESTTAKEN
    • condition_value1: Quest ID
    • condition_value2: Always 0
  • CONDITION_AD_COMMISSION_AURA
    • condition_value1: Always 0
    • condition_value2: Always 0
  • CONDITION_NO_AURA
    • condition_value1: spellid
    • condition_value2: EffectIndex
  • CONDITION_ACTIVE_EVENT
    • condition_value1: event
    • condition_value2: Always 0
  • CONDITION_AREA_FLAG
    • condition_value1: area_flag
    • condition_value2: not_have_flag
  • CONDITION_RACE_CLASS
    • condition_value1: race_mask
    • condition_value2: class_mask
  • CONDITION_LEVEL
    • condition_value1: level
    • condition_value2: 0: equal to, 1: equal or higher than, 2: equal or less than
  • CONDITION_NOITEM
    • condition_value1: itemid
    • condition_value2: count
  • CONDITION_SPELL
    • condition_value1: spellid
    • condition_value2: 0: has spell, 1: has no spell
  • CONDITION_QUESTAVAILABLE
    • condition_value1: questid
    • condition_value2: 0
  • CONDITION_ACHIEVEMENT
    • condition_value1: achievementid
    • condition_value2: 0: has achievement, 1: has no achievement
  • CONDITION_ACHIEVEMENT_REALM
    • condition_value1: achievementid
    • condition_value2: 0: has achievement, 1: has no achievement
  • CONDITION_QUEST_NONE
    • condition_value1: questid
    • condition_value2: Always 0

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

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 DBC file 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 UDB 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.level*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).

Examples

The example here mainly taken from current UDB (339) or from UDB forum. Often examples have several authors and it is uneasy to credit right people so: many thanks to ALL UDB devs and conributors.

But please note that some (or even all) example may contain incorrect data and are shown just for demostration of different loot data organisation.

Simple examples

Gameobject dropping a single non-quest item

# gameobject_template: entry=1622 name='Bruiseweed' type=3 data1=1419

DELETE gameobject_loot_template WHERE entry=1419;
INSERT INTO gameobject_loot_template
  (entry, item, ChanceOrRef, QuestChanceOrGroup, mincount, maxcount, freeforall, lootcondition, condition_value1, condition_value2)
VALUES
  (1419, 2453, 100, 0, 1, 3, 0, 0, 0, 0);  # 100% drop a pile of 1 to 3 items [2453] 'Bruiseweed'

Taking into account default values of the table the second query could be simplified with no change of data (`mincount` is left on cosmetic reasons as `maxcount` has a non-default value):

gameobject_template: entry=1622 name='Bruiseweed' type=3 data1=1419

INSERT INTO gameobject_loot_template
  (entry, item, ChanceOrRef, mincount, maxcount)
VALUES
  (1419, 2453, 100, 1, 3);  # 100% drop a pile of 1 to 3 items [2453] 'Bruiseweed'

Creature having in the pocket single quest item

# creature_template: entry=6846, name='Defias Dockmaster', pickpocketloot=6846
# Note: link with pickpocketing_loot_template is on `pickpocketloot` field (which is equal to `entry` field in this case)

DELETE pickpocketing_loot_template WHERE entry=6846;

INSERT INTO pickpocketing_loot_template
  (entry, item, ChanceOrRef, QuestChanceOrGroup, mincount, maxcount, freeforall, lootcondition, condition_value1, condition_value2)
VALUES
  (6846, 7675, 0, 100, 1, 1, 0, 0, 0, 0);

Again, taking into account default values of the table the second query could be simplified with no change of data:

INSERT INTO pickpocketing_loot_template
  (entry, item, ChanceOrRef, QuestChanceOrGroup)
VALUES
  (6846, 7675, 0, 100);

Note that ChanceOrRef can not be skipped as it has default value of 100.

Wrong definition: combined quest and non-quest chances

SELECT * FROM `pickpocketing_loot_template` WHERE `entry` = '20424';
entry item ChanceOrRef QuestChanceOrGroup mincount maxcount freeforall lootcondition condition_value1 condition_value2
20424 422 0.1 100 1 1 0 0 0 0
20424 929 0.1 100 1 1 0 0 0 0
20424 4538 0.1 100 1 1 0 0 0 0
20424 4542 0.1 100 1 1 0 0 0 0
20424 5374 0.1 100 1 1 0 0 0 0
20424 16882 22.2222 0 1 1 0 0 0 0

First 5 rows in the result are incorrect, ChanceOrRef and QuestChanceOrGroup should not be positive simultanously. See allowed combinations. The core does not crash encounering that, but non-quest chances are ignored.

Groups

Simple skinning group

SELECT * FROM `skinning_loot_template` WHERE `entry` = '100003';

gives

entry item ChanceOrRef QuestChanceOrGroup mincount maxcount freeforall lootcondition condition_value1 condition_value2
100003 8170 80 -1 1 1 0 0 0 0
100003 8171 20 -1 1 1 0 0 0 0

Quite correct. Used quite widely:

SELECT entry FROM `creature_template` WHERE `skinloot` = '100003';

gives

659 2707 4242 4243 5347 5440 6582 6583 6648 7376 8024 8025 8204 8302 8303 8925 8932 9032 9297
9521 9526 9527 10177 10204 10376 10596 10619 10717 10942 10979 10988 11181 11374 11671 11672
11710 11740 11741 11885 11896 11897 11956 12124 12125 12803 13160 13178 13221 13618 13676 13916
14283 14344 14476 14477 14566 14568 14732 14884 14943 14944 14945 14946 14947 14948 14965 14986
14988 15041 15114 15172 15204 15220 15316 15338 15718

Almost correct skinning loot

SELECT * FROM `skinning_loot_template` WHERE `entry` = '5292';

gives

entry item ChanceOrRef QuestChanceOrGroup mincount maxcount freeforall lootcondition condition_value1 condition_value2
5292 4304 49.655 -1 1 1 0 0 0 0
5292 4234 43.1624 -1 1 1 0 0 0 0
5292 8169 4.0984 -1 1 1 0 0 0 0
5292 4235 3.0676 -1 1 1 0 0 0 0
5292 8973 0 80 1 1 0 0 0 0

Quest entry and a group. Would be good if group chance was 100, but it is only 99.9834. So on average at 166 skinning attempts over 1000 000 player will get an empty loot window (withuot considering quest skins which are very rare).

Used for creadure with entry=5292 only.

Damnly wrong skinning loot

SELECT * FROM `skinning_loot_template` WHERE `entry` = '10151';

gives

entry item ChanceOrRef QuestChanceOrGroup mincount maxcount freeforall lootcondition condition_value1 condition_value2
10151 8154 60 -1 1 1 0 0 0 0
10151 8170 48 -1 1 2 0 0 0 0
10151 4304 40 -1 1 2 0 0 0 0
10151 8368 5 -1 1 1 0 0 0 0
10151 8171 4 -1 1 1 0 0 0 0
10151 8169 3 -1 1 1 0 0 0 0
SELECT entry, name FROM `creature_template` WHERE `skinloot` = '10151';

gives

entry name
11614 Bloodshot

First problem the group chance is 160 that is much higher than 100. If by a case order of records in core (actually it is unknown) is such that chances of 60 and 40 are in the beginning then the rest of the group will never be processed. The result will be exacly the same is if the loot template was

entry item ChanceOrRef QuestChanceOrGroup mincount maxcount freeforall lootcondition condition_value1 condition_value2
10151 8154 60 -1 1 1 0 0 0 0
10151 4304 40 -1 1 2 0 0 0 0

Moreover, skinloot in not equal to creature_template.entry and this is NOT a reference to the same loot - 10151 is used ONLY by creature 11614. And the last problem - wowhead has no data about this skinning loot of this pet at all...