Database:CoreServerData
- Last edited 10 years ago by Vlash Nytefall
Content - Core Server Data
Return to: Content | Tutorials | Portal | Forum | Project Manager | Bug Tracker
EQ2Emulator: Core Server Data The tables listed here are ones that the server cannot function without. These are considered Core Data, and are maintained by the EQ2Emulator Database Project team. You can always get the latest Core Data by connecting your world to our public LoginServer and pulling down updates for the data shown below.
Appearances are the "pointers" to the graphical representations of every spawn, item, or object in the game. Appearances consist of an appearance_id and an internal path within the client's assetlib.vpl file where that appearances graphical information can be found.
Appearances come in many categories, such as Static Objects, Armor, Creatures, etc. Below are some examples:
id appearance (path)
5 staticobjects/chandalier_iron -- The graphic for an iron chandalier
53 ec/pc/ratonga/ratonga_male -- The graphic representation of a ratonga male
184 accessories/wearable_items/_exp07/royal_velium_armor/royal_velium_armor_chain/forearms
This is a pointer to a piece of armor
The usage of the appearance_id's are simple. If an NPC has a particular appearance (model), whatever it's model_type value is will refer to the appearance_id for that model. Similarly, items must have an appearance_id associated with it if it is to appear in-game on a player. The Forearms example above, in order to "see" that on a player, you would look in the item_appearances table, the equip_type column is the pointer to the proper appearance_id. If an item does not have an appearances record, it is not visible in-game, such as a loaf of bread.
Note: Only the appearance_id is useful to EQ2Emulator. The appearance name (or path) is only there as a reference for developers.
Commands are any slash (/) commands that might be entered by the player or the User Interface (UI) itself. For example, /who is a slash command, and must be in the Commands table in order for it to be executed and/or return results.
Commands are made up of a number of elements:
type : either 0 or 1 (needs further definition) command : the command itself (eg., spawn) subcommand : the sub-command (eg., create) handler : the internal command handler definition to execute the command in World required_status: the minimum admin_status required to execute the command (or sub-commands)
Example:
type command subcommand handler required_status 1 spawn 1 0 1 spawn create 44 100
In this example, the type 1 command spawn can be executed by any player, while the sub-command create can only be executed by players with an admin_status of 100 or higher.
The handler option is how the server code determines what command it is to process. In the above example, handler ID 1 is processed as COMMAND_SPAWN, which is set to a value of 1 in Commands/Commands.h --
#define COMMAND_SPAWN 1
The code that executes that command is in Commands/Commands.cpp, in the very large switch() statement that processes all commands --
case COMMAND_SPAWN:{
int32 id = 0;
Spawn* spawn = 0;
if(sep && sep->arg[0] && sep->IsNumber(0)){
id = atol(sep->arg[0]);
spawn = world.GetSpawn(id);
}
etc...
Within this "case" statement, many things get checked including a players access to the command itself. If they lack the proper status to execute the command, they are told they have insufficient status for that command. If they do have access, and the command takes parameters (like /spawn create does), the parameters list is then checked for validity -- and if all things check out, the command is executed.
See "In-Game Commands" for more details on how Commands work.
For this article, we'll just discuss the Core Server Data related to Opcodes. For a detailed overview of Opcodes and what they are used for, see this article on Understanding Opcodes.
EQ2Emulator's opcodes table consists of 4 mandatory elements:
name : The Opcode Name (eg., OP_ZoneInfoMsg) opcode : The Opcode Value (eg., 33 = OP_ZoneInfoMsg) version_range1: The lowest client data version this opcode supports version_range2: The highest client data version this opcode supports
In brief, any client EQ2Emulator supports must understand the data stream being passed between the Server->Client. To do this, and to support multiple client versions at the same time, opcode "ranges" were developed to ensure each individual client gets the data it expects from the server, and vice versa.
Additional details can be found in these articles:
Understanding Opcodes Understanding Data Structure Understanding Data Packets
The Skills table is a list of all known player skills used in the game. It is used mostly for display purposes in placing the proper data in the client UI where appropriate (skill up messages, Persona data, etc)
Skills data consists of these elements:
skill_id : The skill's ID (this value matches SOE's skill_id value) short_name : An internal tag identifying the skill name : The friendly name of the skill description: The text that shows up in the UI describing the skill skill_type : What type of skill is this? Spell, Art, Crafting, Mastery display : Whether or not this skill is displayed somewhere in the UI
In general, Skills are what tell the world whether or not a player can or cannot use a certain item or spell. For example, a Paladin cannot cast spells or use abilities that require him/her to know determined faith if said Paladin does not possess that skill (the skill_id is not in their character_skills table)
skill_id short_name name description type display 90523872 determinedfaith Paladin This allows you to use paladin spells. 0 0
The above example shows that determined faith is a default skill of a Paladin class, and because it is a passive skill (does not rise or fall in value) it is NOT displayed in the client anywhere.
This is specific to the EQ2Emulator PatchServer service, and only pertains to Servers that connect to EQ2Emulator.net's Public LoginServer Service. The data in the `table_versions` table tracks the current schema (data structure) and it's table data for your Server, and allows your Server to ask for table or data updates provided by the EQ2Emulator Project.
This table has the following elements:
name : The name of the table in the database version : The current Server version supported by this table download_version: The current version of the data within the tables (optional)
For example, we recently developed a new function in the Server known as spawn templates, which required a new MySQL table be added to the database. The internal server version this happened in was 71000 (the 1st schema change in EQ2Emulator v0.7.1) so a new table was added as follows:
name version download_version spawn_templates 71000 0
When you checked out the newest SVN code from our repository, compiled your world and ran it the first time, your world tells the PatchServer "Give me the new updates as of version 71000". PathServer knows that this new table should be sent, so it sends the query to your world, who executes the CREATE TABLE, and when it's finished, sets a new record in table_versions as above.
See Public PatchServer Service for further details on how this service works.
The `variables` table holds various data elements unique to your EQ2Emulator Server, like your server MOTD, current in-game date/time, and current lotto #'s and jackpot.
Many of the values previously held in the variables table are being replaced by the new server Rules System.
An example of a `variables` entry:
variable_name variable_value description gambling_current_jackpot 1000 Current Gigglegibber Gambling Game Jackpot
Visual States are similar to Appearances in the fact that they cause specific effects to occur within the world, such as fog, Mender's banging forges, players emotes, or other visual effects.
The table consists of these elements:
visual_state_id: The visual_state value needed to cause the spawn/object to display the given effect name : The friendly name of the visual state (reference only)
An example of a visual state in action would be a player (or NPC, or any object) being set to visual_state_id 148 (cast_lightning) and that spawn would shoot lightning bolts from itself for a short duration.
Note: These are not spell effects, but usually the result of something being interacted with. For spell effects, see Spell Effect Reference.
To try out Visual States, you can either use the in-game command /animtest {visual_state_id}, or to see it in action on an NPC, target an NPC and type /spawn set visual_state {id} <-- any ID from the list. Note that not all visual_state_id's produce effects, so try a few. Can be fun 
The `zones` table is the gateway to all things in EQ2Emulator! Without Zones, we have nothing. Every zone that an EQ2 Client supports must be in the zones table. Some data is mandatory, while others are recommended/fun stuff. Still other values are merely for reference, or systems not yet developed.
MANDATORY VALUES:
id : The zone's ID - used with /zone {id} to move around the world
name : The zone's "short name" - used with /zone {name} to move around the world
file : The name of the zone graphics file ("vpk", in client's /paks/ folder)
description : This appears in the client UI while the player is changing zones
safe_x : The zone-in "X" coordinate (long.)
safe_y : The zone-in "Y" coordinate (height)
safe_z : The zone-in "Z" coordinate (lat.)
: Note, without a safe x,y,z you will zone into 0,0,0 and likely blackness!
shutdown_timer: How long to wait after last player leaves before shutting zone down
OPTIONAL INTERESTING STUFF:
xp_modifier : Boost or Nerf xp granted in the zone
always_loaded: Zone starts up with the server, and never shuts down even if empty
min_status : Required admin_status a player must have before access is granted
min/max_level: Min/Max player level checks before access is granted
start_zone : The zone that relates to a player-selected starting city in Character Create screens
: Example, player selects Kelethin as their starting city, so the zone record for
: Greater Faydark should be set to 4 (the value for Kelethin)
lua_script : Attach a LUA script to a zone for fun events and interactions
zone_motd : Each Zone can have it's own personalized welcome message!
ruleset_id : Each Zone can have a unique ruleset applied - now that's awesome!