WoW:Events/System

Reference e
AddOns WoW API Widget API XML UI Event API WoW Lua Macro API CVars Battle.net HOWTOs Snippets UI tech Categories

→ API events

← Event API

Note that this page is automatically generated; editing it is pointless. To edit event descriptions, edit the entries in the alphabetical pages, e.g. Events/A, Events/B, etc. Changes there will be copied over to here within a few hours. System related events

"ADDON_ACTION_BLOCKED"	Category: System

(this event doesn't seem to be used anymore, use ADDON_ACTION_FORBIDDEN instead)

"ADDON_ACTION_FORBIDDEN"	Category: System

Fires when an AddOn tries use actions that are always forbidden (movement, targeting, etc.). If called from an AddOn arg1 Name of the AddOn that was last involved in the execution path. arg2 The protected function that was called. Notes It's very possible that arg1 will not be the name of the addon that tried to call the protected function. If called from the chat prompt (/script CastSpellByName("Attack")) arg1 The protected function that was called.

"ADDON_LOADED"	Category: System

This event fires whenever an AddOn is loaded (fires once for each AddOn loaded if multiple AddOns are being loaded), whether that is during the inital Loading Phase or when an AddOn is loaded using the LoadAddOn("addonname") or UIParentLoadAddon("addonname") function. This event always fires after SavedVariables of the AddOn have been loaded from disk and its OnLoad function has been executed. arg1 name of the AddOn that was just loaded

"CVAR_UPDATE"	Category: System

Fired when a CVar is changed arg1 cvarname arg2 value

"DISPLAY_SIZE_CHANGED"	Category: System

"DISABLE_TAXI_BENCHMARK"	Category: System

?

"ENABLE_TAXI_BENCHMARK"	Category: System

?

"LOGOUT_CANCEL"	Category: System

"MACRO_ACTION_BLOCKED"	Category: System

(this event doesn't seem to be used anymore, use MACRO_ACTION_FORBIDDEN)

"MACRO_ACTION_FORBIDDEN"	Category: System

Sent when a macro tries use actions that are always forbidden (movement, targeting, etc.). arg1 As of 3.0.2 (possibly sooner) this argument appears to always be "UNKNOWN()"

"PLAYER_ENTERING_WORLD"	Category: System,Player,Instance

Fired when the player enters the world, enters/leaves an instance, or respawns at a graveyard. Also fires any other time the player sees a loading screen. To check if the player is entering an instance, check GetPlayerMapPosition to see if both X and Y are zero. Correction on the above comment: When PLAYER_ENTERING_WORLD fires, you'll notice that WORLD_MAP_UPDATE fires just before it. My instincts tell that leaving an instance puts the player in void space momentarily. So for the case that you are entering AND leaving an instance, GetPlayerMapPosition always returns the coordinates [0,0] and hence there is no way to determine using the event PLAYER_ENTERING_WORLD if the player is entering an instance or not. When leaving an instance the following events fire (ignoring party/raid events). WORLD_MAP_UPDATE PLAYER_ENTERING_WORLD WORLD_MAP_UPDATE <--- Player coordinates are non-zero here Instances do have coordinates for units once the second WORLD_MAP_UPDATE event has fired. For the case of entering a battleground such as WSG, WORLD_MAP_UPDATE won't fire until you leave Silverwing Hold or Warsong Lumber Mill and you are outside. --Salanex

"PLAYER_LEAVING_WORLD"	Category: System

Fired when a player logs out and possibly at other situations as well

"PLAYER_LOGIN"	Category: System

Triggered immediately before PLAYER_ENTERING_WORLD on login and UI Reload, but NOT when entering/leaving instances. Note: Player skills such as those available through GetNumSkillLines() and relatives does not appear to be available when this event or PLAYER_ENTERING_WORLD fires during an actual player login from character-selection, as all the GetNumSkillLines()-function returns is 0 in those cases. When these events trigger from other reasons, such as zoning, the skill-related functions appear to work normally.

"PLAYER_LOGOUT"	Category: System

Sent when the player logs out or the UI is reloaded, just before SavedVariables are saved. The event fires after PLAYER_LEAVING_WORLD.

"PLAYER_QUITING"	Category: System

Fired when the player tries to quit, as opposed to logout, while outside an inn. This event does not indicate that the "player has quit", but instead that the "player has the quitting option". The dialog which appears after this event, has choices of "Exit Now" or "Cancel". The dialog which appears when you try to logout outside an inn, only has a "Cancel" choice, and the event is not fired.

"SCREENSHOT_FAILED"	Category: System

Fired when a screenshot fails.

"SCREENSHOT_SUCCEEDED"	Category: System

Fired when a screenshot is successfully taken.

"SOUND_DEVICE_UPDATE"	Category: System

?

"STREAMING_ICON"	Category: System

Added in 4.0 for the Streaming Launcher arg1 ? (number in 0-2 range)

"SYNCHRONIZE_SETTINGS"	Category: System

?

"TIME_PLAYED_MSG"	Category: Player,System,Communication

Fired when the client received a time played message. arg1 Total time arg2 Current time at this level

"UI_ERROR_MESSAGE"	Category: System

Fired when the interface creates an error message. These are the red messages that show in the top middle of the screen. "Your inventory is full." is one example. arg1 message

"UI_INFO_MESSAGE"	Category: System,Communication

Fired when the interface generates a message. These are the yellow messages in the top middle of the window. "No fish are hooked." is one example. arg1 message

"UPDATE_BINDINGS"	Category: System

Fired when the keybindings are changed. Fired after completion of LoadBindings(), SaveBindings(), and SetBinding() (and its derivatives).

"UPDATE_MACROS"	Category: System

"VARIABLES_LOADED"	Category: System

Fired in response to the CVars, Keybindings and other associated "Blizzard" variables being loaded. Since key bindings and macros in particular may be stored on the server they event may be delayed a bit beyond the original loading sequence. Previously (prior to 3.0.1) the VARIABLES_LOADED event was part of the loading sequence. Although it still occurs within the same general timeframe as the other events, it no longer has a guaranteed order that can be relied on. This may be problematic to addons that relied on the order of VARIABLES_LOADED, specifically that it would fire before PLAYER_ENTERING_WORLD. Addons should not use this event to check if their addon's saved variables have loaded. They can use ADDON_LOADED (testing for arg1 being the name of the addon) or another appropriate event to initialize, ensuring that the addon works when loaded on demand.