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_templateGeneralWell, 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
RelationsThe 11 tables have different relations with other DB tables.
Description of the fieldsEntryThe 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. ItemTemplate 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. ReferenceTemplate 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. ChanceItem drop chance (plain entry or quest entry). Not sure how this functions for loot reference items. Plain entryChance> 0Absolute 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 dropChance> 0Absolute 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 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. 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. 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. 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. 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 The easiest way to understand what are groups is to understand how core processes grouped entries: At loading time: During loot generation: 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 does not exceed 100 then every item defined in group entries has exactly that chance to drop as set in Chance. So now basic applications of the groups are clear: 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; The minimum number of copies of the item that can drop in a single loot 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. These agreements are different for different loot tables. Mainly agreements defines rules for loot template IDs (entry) and groups 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 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 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). 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 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. Agreements for pickpocketing loot templates numbering is not known. Agreements for prospecting loot templates numbering is not known. 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). Agreements for Reference Templates are as followed: KEEP FREE: TDB-DEV-References 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? OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! gives OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! gives gives OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! OUTDATED!!! |
Datenbank 'world'
Votet bitte für uns und bringt uns so neue Spieler!
Stimme zählen für Account:
Stimme zählen für Account: