Description of the 'game_event' table for MaNGOSTwo

This table contains definitions for all game events that are activated or deactivated automatically by the Game Event System in the core.
NOTE: an object (creature, GO etc.) cannot be related to a more than 1 game event. For example, if you wish something to happen only at March nights, you cannot combine events "March" and "Nights", but have to define a new event like "Nights" starting March 1 and ending April 1 of the same year.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

entry mediumint(8) unsigned

ID of the event. May be any, should be as low as possible.

start_time timestamp

Starting date for the event. Defines the first event occurence only, see occurence and length for the next ones.
NOTE: due to occurence/length event definition, the seasonal events require an editing in leap-years. The simplest solution is to change start_time to the event start at such year.

end_time timestamp

Ending date of the event. After this date, the event will never happen.

occurence bigint(20) unsigned

The interval (minutes) between consequent starts of the event.

length bigint(20) unsigned

The interval (in minutes) between start and end of single event occurence

Note:
If length is > occurence, an event would never stop.

holiday mediumint(8) unsigned

Holiday ID is a number, associated with the seasonal events and strictly defined since 3.x (WotLK) client version. Ignore this if you do not know one.

description varchar(255)

Textual comment about the event.

Table Contents

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_event_creature' table for MaNGOSTwo

Contains all creature instances that have to be spawned/unspawned during defined game events.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

guid int(10) unsigned

GUID of an existing creature.

event smallint(6)

ID of game event [See game_event.entry].
If positive, the creature will be spawned at event start and despawned at event end.
If negative, the creature will be despawned at event start and spawned again at event end.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_event_creature_data' table for MaNGOSTwo

Contains all creature instances that need to change display id and/or equipment during defined game events.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

guid int(10) unsigned

GUID of the creature [See creature.guid] which should change their appearance during the event.

entry_id mediumint(8) unsigned

New ID of the creature [See creature_template.entry] applied during the event.

modelid mediumint(8) unsigned

New modelID of the creature (creature_template.ModelId1 or ModelId2) applied during the event

Note:
Set to 0 if only the equipment should be changed.

equipment_id mediumint(8) unsigned

New equipment ID [See creature_equip_template.entry] applied during the event.

Note:
Set to 0 if only the model should be changed.

spell_start mediumint(8) unsigned

ID of the spell [See Spell.dbc] which the creature will cast on self at event start. Usually this is an aura of unlimited duration. The aura will be removed at event end.

spell_end mediumint(8) unsigned

ID of the aura spell [See Spell.dbc] to be removed from the creature at event start. Usually this is an aura of unlimited duration, added to the creature via creature_template_addon/creature_addon table. The aura will be applied again at event end.

event smallint(5) unsigned

Event ID [See game_event.entry].

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_event_gameobject' table for MaNGOSTwo

Contains all gameobjects instances that participate to any game event.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

guid int(10) unsigned

GUID of an existing gameobject.

event smallint(6)

ID of the event [See game_event.entry].
If positive, the gameobject is spawned at event start and despawned at event end.
If negative, the gameobject is despawned at event start and spawned again at event end.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_event_mail' table for MaNGOSTwo

This table holds definitions for mails sent out during game events and conditions for when to send the mail.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

event smallint(6)

Event ID [See game_events.entry].

raceMask mediumint(8) unsigned

Races of affected players based on enum Races [See ChrRaces.dbc] in the bitmask form. Values from the table may be combined by simple adding.

quest mediumint(8) unsigned

The quest [See quest_template.entry] which the player should have REWARDED (handed off) for receiving the mail.

mailTemplateId mediumint(8) unsigned

Mail template ID [See MailTemplate.dbc] of the mail which will be sent to the player when all conditions are satisfied.

senderEntry mediumint(8) unsigned

Entry [See creature_template.entry] of the NPC which will sign the mail.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_event_quest' table for MaNGOSTwo

This table controls availability of the quests during the events. When out of the event a questgiver may not be despawned, you can disable quests which he proposes. Quests listed here will be available only during respective events.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

quest mediumint(8) unsigned

ID of the quest [See quest_template.entry] which will be accessible only during the event.

event smallint(5) unsigned

Event ID [See game_event.entry].

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_graveyard_zone' table for MaNGOSTwo

This table contains information about which zones are connected to the world's graveyards.

This table set if character die in zone ghost_zone and graveyard with id accept his team (HORDE or ALIANCE or both) and this is nearest graveyard then character's ghost will be teleported to graveyard id.

For a list of all existing graveyards and their respective IDs, check out WorldSafeLocs.dbc.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

id mediumint(8) unsigned

ID of the graveyard, see WorldSafeLocs.dbc. This DBC also defines coordinates where the ghost will pop up.

ghost_zone mediumint(8) unsigned

AreaID of the zone the graveyard is tied to, see AreaTable.dbc. The graveyard is considered to pop-up ghosts originated in this zone.

faction smallint(5) unsigned

Faction: ALLIANCE = 469, HORDE = 67, both = 0.
Some graveyards accept ghosts of players only from one faction.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_tele' table for MaNGOSTwo

This table contains a list of teleport locations that can be used with the .tele command in-game. Entries in this table can be added/deleted manually or with the .addtele/.deltele commands.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

id mediumint(8) unsigned

The id of the teleport location.

position_x float

The x location of the teleport location.

position_y float

The y location of the teleport location.

position_z float

The z location of the teleport location.

orientation float

The orientation of the player when teleported to the teleport location.

map smallint(5) unsigned

The map id of the teleport location [See map.dbc].

name varchar(100)

The name of the teleport location

Note:
Using spaces and special characters for locations is prohibited.

Table Contents

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'game_weather' table for MaNGOSTwo

This table holds the percentages for weather changes in various zones. Not all zones can have their weather changed. For any given zone the percentage of all weather types for each season should total, and not exceed 100%.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

zone mediumint(8) unsigned

A zone identifier. The value has to match with a zone identifier defined in AreaTable.dbc.

spring_rain_chance tinyint(3) unsigned

Percentage chance for rain in the Spring.

spring_snow_chance tinyint(3) unsigned

Percentage chance for snow in the Spring.

spring_storm_chance tinyint(3) unsigned

Percentage chance for a sand storm in the Spring.

summer_rain_chance tinyint(3) unsigned

Percentage chance for rain in the Summer.

summer_snow_chance tinyint(3) unsigned

Percentage chance for snow in the Summer.

summer_storm_chance tinyint(3) unsigned

Percentage chance for a sand storm in the Summer.

fall_rain_chance tinyint(3) unsigned

Percentage chance for rain in the Fall.

fall_snow_chance tinyint(3) unsigned

Percentage chance for snow in the Fall.

fall_storm_chance tinyint(3) unsigned

Percentage chance for storm in the Fall.

winter_rain_chance tinyint(3) unsigned

Percentage chance for rain in the Winter.

winter_snow_chance tinyint(3) unsigned

Percentage chance for snow in the Winter.

winter_storm_chance tinyint(3) unsigned

Percentage chance for storm in the Winter.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gameobject' table for MaNGOSTwo

This table holds the individual object data on each spawned game object in the world. This data along with the object's template data is read and used to instantiate the objects in the world.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

guid int(10) unsigned

The global unique identifier (GUID, low 32-bit) of the GameObject spawn.

id mediumint(8) unsigned

This defines what GameObject will be spawned [See gameobject_template.entry].

map smallint(5) unsigned

The map id that the game object is located on [See map.dbc].

spawnMask tinyint(3) unsigned

phaseMask smallint(5) unsigned

position_x float

The x location of the game object.

position_y float

The y location of the game object.

position_z float

The z location of the game object.

orientation float

The object's orientation in the game world, where north is 0 and south is 3.14159.

rotation0 float

The amount of rotation of an object along one of the axis in the game world.

rotation1 float

The amount of rotation of an object along one of the axis in the game world.

rotation2 float

The amount of rotation of an object along one of the axis in the game world.

rotation3 float

The amount of rotation of an object along one of the axis in the game world.

spawntimesecs int(11)

The respawn time for the game object, defined in seconds till respawn

Note:
Using a negative spawn time will lead to the object being despawned until spawned by a script. It will then despawn after the time specified here.

animprogress tinyint(3) unsigned

Not really known what this is used for at this time

Note:
Set to 100 for game objects of type chest.

state tinyint(3) unsigned

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gameobject_battleground' table for MaNGOSTwo

This table contains the events of gameobjects which are spawned on battlegrounds.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

guid int(10) unsigned

This references the "gameobject" table's unique ID for which the entry is valid.

event1 tinyint(3) unsigned

The identifier for the event node in the battleground. Event nodes usually are defined in the battleground's script.

Nodes are locations in a battleground where characters of each faction can perform actions, such as capturing a tower in Alterac Valley, or taking control over the stables in Arathi Basin.

event2 tinyint(3) unsigned

The state of the event node. Node status is defined differently in every battleground script.

Node events can occur for every node and usually describe changes due to character interaction. E.g. if stables in Arathi Basin are taken over by Alliance, the stables note state would become Alliance controlled. Similar node states exist for every battleground note

Note:
If you update battleground scripts and make changes to node status values ensure that you provide database update scripts which update the battleground events accordingly.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gameobject_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:

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)

Depending on the value of the field it may either define the minimum number of copies for the item to be dropped, or it may reference another loot template.

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. 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 Player looting must have no aura active mentioned in condition_value1 12 CONDITION_ACTIVE_EVENT The loot with that condition can be looted only while the Event (condition_value1) is active 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.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gameobject_template' table for MaNGOSTwo

This table contains templates of all the world's objects

Table Notes

This table uses the 'MyISAM' DB Engine

The Field definitions follow:

Description of the fields

entry mediumint(8) unsigned

Id of the gameobject template

type tinyint(3) unsigned

displayId mediumint(8) unsigned

A display model identifier for the Item. This references an DisplayInfo entry [See itemDisplayInfo.dbc].

name varchar(100)

Object's Name

IconName varchar(100)

castBarCaption varchar(100)

unk1 varchar(100)

faction smallint(5) unsigned

Object's faction, if any. [See FactionTemplate.dbc]

flags int(10) unsigned

size float

Object's size must be set because graphic models can be resample.

questItem1 int(11) unsigned

questItem2 int(11) unsigned

questItem3 int(11) unsigned

questItem4 int(11) unsigned

questItem5 int(11) unsigned

questItem6 int(11) unsigned

data0 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data1 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data2 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data3 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data4 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data5 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data6 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data7 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data8 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data9 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data10 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data11 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data12 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data13 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data14 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data15 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data16 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data17 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data18 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data19 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data20 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data21 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data22 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

data23 int(10) unsigned

The content of the data fields depends on the gameobject type. Please refer to the table below:

mingold mediumint(8) unsigned

DEPRECATED: Defines money looted from the game object.

maxgold mediumint(8) unsigned

DEPRECATED: Defines money looted from the game object.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gossip_menu' table for MaNGOSTwo

This table is used for displaying gossip when a player talks to an NPC.

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow:

Description of the fields

entry smallint(6) unsigned

Gossip menu ID [See creature_template.GossipMenuId]. These values are predefined, but a lot of them is unknown.

text_id mediumint(8) unsigned

ID of the text (npc_text.ID), shown at the top of the gossip windows, above any variants of answer.

script_id mediumint(8) unsigned

ID of the DB script [See db_scripts.id] with a type of 2, tied to the action of requesting the gossip.

condition_id mediumint(8) unsigned

ID of the condition (conditions.condition_entry), allowing the gossip to appear. If the condition is not fulfilled by the player, he may not get the gossip.

auto-generated by the getMaNGOS.eu MAGNET dbdocs module

Description of the 'gossip_menu_option' table for MaNGOSTwo

This table holds infos about menu options a gossip NPC can have. Examples of options: "Train me!" or "I want to unlearn my talents".

Table Notes

This table uses the 'InnoDB' DB Engine

The Field definitions follow: