Database:CoreServerData

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

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

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 components:

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.

opcodes

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

zones

General Server Core Data

Back to Content:Introduction

Content:Introduction