eqemu / eqemu-docs-v2 Goto Github PK

  docs\changelog\server\2019.md (3 hits)
	Line 227: * Now has an embedded **Web API** on port 6000 by default, details can be found at [Loginserver API](https://eqemu.gitbook.io/eqemulator-loginserver/loginserver/configuration/loginserver-api)
	Line 228: * Now has a rich embedded **CLI interface**, details found at [Login CLI Interface](https://eqemu.gitbook.io/eqemulator-loginserver/loginserver/command-line-management-interface)
	Line 242:       To migrate your Legacy login server, follow this guide [Migrating your Legacy Loginserver](https://eqemu.gitbook.io/eqemulator-loginserver/loginserver/migrating-from-a-legacy-loginserver-database)
  docs\changelog\server\2020.md (1 hit)
	Line 874: * Both event types have new or updated entries on the [Events](https://eqemu.gitbook.io/quest-api/methods/events/) page
  docs\schema\admin\perl_event_export_settings.md (1 hit)
	Line 10: | event_id | int | [Unique Perl Event Identifier](https://eqemu.gitbook.io/quest-api/events) |
  docs\server\aas\customizing-aas.md (2 hits)
	Line  17: AAs often have "ranks" available that allow you to progress the ability, making the effects more powerful at each rank level purchased.  These values are stored in the [aa_rank](https://eqemu.gitbook.io/database-schema/server/aas/aa_ranks) table. For example, _Innate Run Speed_ has many ranks to represent the levels it can be trained. 
	Line  39: The effects of each rank of an AA is stored in the aptly named [aa_rank_effects](https://eqemu.gitbook.io/database-schema/server/aas/aa_rank_effects) database table.  
  docs\server\factions\customizing-factions.md (4 hits)
	Line  7: Every faction that exists on a server is listed in the [`faction_list`](https://eqemu.gitbook.io/database-schema/server/factions/faction_list) table. This table includes a unique id, a name, and a starting (base) faction. This starting value is combined with any race/class/deity adjustments that apply (see [`faction_list_mod`](https://eqemu.gitbook.io/database-schema/server/factions/faction_list_mod) table) to create the starting faction for characters when they are born. As characters interact with the world, they can gain/lose faction through their actions, be that killing or questing. These values are continuously updated in the [`faction_values`](https://eqemu.gitbook.io/database-schema/server/factions/faction_values) table.
	Line 14:       As of [06 March 2019](https://eqemu.gitbook.io/changelog/years/2019#3-1-2019) we have imported the client faction list and we now use these renumbered factions. The client does not have a base for any of the factions, all of the offsets are realized in faction_list_mod instead. This does not mean that the base cannot be altered for custom results.
  docs\server\factions\README.md (6 hits)
	Line 19: The [faction_list ](https://eqemu.gitbook.io/database-schema/server/factions/faction_list)table contains one entry for each unique faction on the server. This list was previous our own values, but now uses values directly from the client for any non-custom factions. The ID field identifies an in-game faction, but IS NOT directly associated with an NPC. This list simply lists the in game factions and the starting value that all characters start at with this faction before they begin earning or losing faction. DO NOT use these values in npc_types. See npc_faction below for details.
	Line 23: The [faction_base_data](https://eqemu.gitbook.io/database-schema/server/factions/faction_base_data) was imported directly from the client. In includes the lowest a character can go in "earned" faction and the highest amount of "earned" faction they can obtain. The modifiers for race, class and deity are still applied on top of the personal faction to determine the final standing.
	Line 27: The [faction_list_mod](https://eqemu.gitbook.io/database-schema/server/factions/faction_list_mod) table stores the static data that indicates what bonuses or penalties race, class and deity have on various factions. For example, a character's standing may be worse with some factions due to that faction hating your deity. Or like in the case of the Kerran race, they dislike Erudites. These adjustments, combined with the starting value for everyone taken from faction_list, make up where you start in relation to all of the factions on Norrath.
	Line 31: The [faction_values](https://eqemu.gitbook.io/database-schema/server/factions/faction_values) table stores the ever-changing data in regards to each characters actions in the game. A running sum of all of the hit and gains in faction for characters is stored here, one line per char/faction pair. Lines only exist if a character has at least one hit or credit based on in game actions.
	Line 37: The ID from the [npc_faction](https://eqemu.gitbook.io/database-schema/server/npcs/npc_faction) table is where an NPC gets its entire faction behavior. The ID assigned here, ties an NPC to their primary faction (from faction_list) as well as determines whether not not they will assist their primary faction comrades in battle.
	Line 43: The [npc_faction_entries](https://eqemu.gitbook.io/database-schema/server/npcs/npc_faction_entries) table has three major roles. First, entries are placed here that indicate how much faction is gained/lost with various factions if any NPC has this npc_faction_id is killed. The second, is that you can list how these NPCS react to other NPCS of various other factions. The third, these entries can also indicate faction gain/loss via the task system. The npc_faction_id is specified in the faction_reward field in the tasks table.
  docs\server\items\ornament-types.md (1 hit)
	Line  23: * To create a Hero's Forge Ornamentation you have to set the [Hero's Forge Model](https://eqemu.gitbook.io/database-schema/server/items/items) column in the items table to a value greater than 0.
  docs\server\logging-system\logging-categories.md (1 hit)
	Line 10: Logging categories have their settings stored in the [logsys_categories](https://eqemu.gitbook.io/database-schema/server/admin/logsys_categories) table, but the categories are defined in [common/eqemu_logsys.h](https://github.com/EQEmu/Server/blob/master/common/eqemu_logsys.h)
  docs\server\npc\customizing-npcs\using-the-peq-database-editing-interface.md (5 hits)
	Line  37: Explanations for each of these fields can be found on the [npc_types](https://eqemu.gitbook.io/database-schema/server/npcs/npc_types) page (opens new window) in the Database Schema documentation.  
	Line  59: A _Spawngroup_ is a grouping of one or more NPCs.  A Spawngroup can have one member, which will be the case for our Greeter Bot, or it can have many members; a Spawngroup with many members can create a more random feel for your world, since the same NPC may not always appear.  You can review the fields in database table on the [spawngroup](https://eqemu.gitbook.io/database-schema/server/spawns/spawngroup) page (opens new window) in the Database Schema documentation.
	Line  75: A Spawnpoint is the database entry that determines the location and behavior when the NPC spawns in the world.  These values are stored in the spawn2 table in your database.  You can review the fields of this table on the [spawn2](https://eqemu.gitbook.io/database-schema/server/spawns/spawn2) page (opens new window) of the Database Schema documentation.
	Line  99: The Pathing Grid has Wander types, Pause types, and a listing of Waypoints that your NPC will follow.  To review the Grid fields in your database, reference the [grid](https://eqemu.gitbook.io/database-schema/server/grids/grid) page (opens new window) in the Database Schema documentation.  For information regarding the Waypoint entry fields in your database, reference the [grid_entries](https://eqemu.gitbook.io/database-schema/server/grids/grid_entries) page (opens new window).
  docs\server\npc\spawns\wander-types.md (1 hit)
	Line  8:       These Wander Types are assigned to a [Grid](https://eqemu.gitbook.io/database-schema/server/grids) to cause the behavior listed below as the NPC wanders through Grid Waypoint Entries.
  docs\server\operation\exporting-client-files.md (4 hits)
	Line 21: | BaseData.txt | An ASCII export of your [base_data](https://eqemu.gitbook.io/database-schema/server/client-files/base_data) table, which contains information regarding class "base" stats, such as HP, Mana and Endurance by level. |
	Line 22: | dbstr_us.txt | An ASCII export of your [db_str](https://eqemu.gitbook.io/database-schema/server/client-files/db_str) table, which contains the text that is displayed to a player character from various sources, such as spells or trades. |
	Line 23: | SkillCaps.txt | An ASCII export of your [skill_caps](https://eqemu.gitbook.io/database-schema/server/client-files/skill_caps) table, which contains information about skills (1HS, 1HB, Abjuration, etc.) by class and level. |
	Line 24: | spells_us.txt | An ASCII export of your [spells_new](https://eqemu.gitbook.io/database-schema/server/client-files/spells_new) table, which contains information about all of the [spells](../spells/) in use in your world. |
  docs\server\scripting\entity-lists.md (1 hit)
	Line 213: * The same exact thing applies for clients, you can use any $client object listed in the [Quest API](https://eqemu.gitbook.io/quest-api/) manipulate the entity list and trigger any action in any event that you want. It is a less frequent thing to want to use a full list of clients to do something, but you can use it for a variety of things depending on the cool ideas that you come up with. But for examples sake I want to use an example where maybe I want to freeze all of the clients in a zone in a boss fight with **Emperor Crushbone **for many a few seconds at a time
  docs\server\scripting\entity-variables.md (1 hit)
	Line 24:   * See [Plugins Reference](https://eqemu.gitbook.io/quest-api/perl/plugins)
  docs\server\scripting\README.md (8 hits)
	Line  7: Please note that there is extensive documentation of the [EQEmu Quest Api](https://eqemu.gitbook.io/quest-api/) available on this site.  This documentation includes sample scripts describing functions, variables, sub routines and the like.  
	Line 15: **If you are new to both Lua and Perl**, a good place to get started is the [Beginner's Guide to Perl and Lua.](https://eqemu.gitbook.io/quest-api/methods/beginners-guide)
	Line 17: **If you are adept at either Lua or Perl**, it is best to familiarize yourself with how EQEmu [loads quests scripts](https://eqemu.gitbook.io/quest-api/methods/quest-loading), followed by reviewing the various [Events](https://eqemu.gitbook.io/quest-api/methods/events) that can be triggered in either Perl or Lua, along with  exports of those events (as well as the [global exports](https://eqemu.gitbook.io/quest-api/perl/exports)), and then beginning to review the many methods and functions exposed in the API.
	Line 21: The decision to utilize either Perl or Lua for your quest scripts is entirely up to you.  Both offer nearly all the same functions and methods--where discrepancies exist, they are noted (for instance the [Spell Methods (Lua)](https://eqemu.gitbook.io/quest-api/methods/spell-methods-lua) page describes methods only available in Lua.  Beginners often find Perl easier to understand. Adept Lua programmers might enjoy the ability to load [encounters](encounters-lua.md).  Advanced Perl programmers may find the ability to create or utilize [plugins](https://eqemu.gitbook.io/quest-api/perl/plugins) very desirable.
	Line 33: These scripts range from fairly straightforward to relatively complex--be sure to reference [Event Subroutines](https://eqemu.gitbook.io/quest-api/events) to learn why these scripts fire, [Quest API Functions](https://docs.eqemu.io/quest-api/introduction/) to learn what each function does and how to properly call the function, and finally, [Customizing NPCs](../../../../server/npc/customizing-npcs) if you would like to learn how to create your own NPC who will utilize any of these quest scripts.
  docs\server\spells\README.md (2 hits)
	Line   7: There are tens of thousands of records in your [spells_new](https://eqemu.gitbook.io/database-schema/tables/spells_new) table, and making sense of them all can be a little daunting (at least at first).
	Line 211: A dizzying array of fields exists that have not been covered above. Many of these fields are quite self-explanatory, such as the level at which each class can use the spell, the deities allowed to use the spell, cast-on messages, etc. This section is meant to cover the remaining fields as questions arise about their functionality. Remember to reference the information on [spells_new](https://eqemu.gitbook.io/database-schema/tables/spells_new) found on this wiki, and the information contained in the [spdat.h](https://github.com/EQEmu/Server/blob/master/common/spdat.h) source file, as well as the other helpful wiki pages for [Base Value Formulas](../../../../server/spells/base-value-formulas), [Spell Target Restrictions](../../../../server/spells/spell-target-restrictions), [Spell Resist Types](spell-resist-types.md), and [Damage Shield Types](../../../../server/spells/damage-shield-types).
  docs\server\task-system-guide\README.md (6 hits)
	Line  12:       While every attempt will be made to keep this page updated, please reference the additional supporting documentation found in the [Database Schema](https://eqemu.gitbook.io/database-schema/), [Quest API](https://eqemu.gitbook.io/quest-api/), and [Changelog](https://eqemu.gitbook.io/changelog/).
	Line  25: The most up to date information regarding the database schema can be found in the Database Schema Space for [Tasks](https://eqemu.gitbook.io/database-schema/server/tasks).  The information presented here is current as of this writing.
	Line 221:       These options are present in the Logging System through [logsys_categories](https://eqemu.gitbook.io/database-schema/server/admin/logsys_categories) or in-game via command #logs set [output] [type] [level]
	Line 241:       Be sure to reference the [Quest API](https://eqemu.gitbook.io/quest-api/) in the event that functionality is expanded.