pa/eqemu-server
2
0
Fork 0
mirror of https://github.com/EQEmu/Server.git synced 2026-09-09 19:36:36 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated Understanding the database tables (markdown)

Paul Coene
2018-11-08 13:18:13 -05:00
parent 5e50b78c31
commit 1e0fe5dcec
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Understanding-the-database-tables.md
+1 -1
@@ -24,6 +24,6 @@ But more than this, it serves as a key into the npc_faction_entries table.
## [npc_faction_entries](https://github.com/EQEmu/Server/wiki/npc_faction_entries) ## [npc_faction_entries](https://github.com/EQEmu/Server/wiki/npc_faction_entries)
The npc_faction_entries table has two 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 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.
This table collects too much data in one place, and really should be broken down. As it stands right now, if there are 10 different mobs that yield different faction hits when killed, there needs to be 10 different npc_factions and copies of their behavior records in new npc_faction_entries records. If we separated out the hits into a separate table, then we would only need one copy of the behavior records. We'll mark this as potential improvement. (In my work matching live faction data, it has required a ton of redundancy). This table collects too much data in one place, and really should be broken down. As it stands right now, if there are 10 different mobs that yield different faction hits when killed, there needs to be 10 different npc_factions and copies of their behavior records in new npc_faction_entries records. If we separated out the hits into a separate table, then we would only need one copy of the behavior records. We'll mark this as potential improvement. (In my work matching live faction data, it has required a ton of redundancy).