Das Teil ist hier als ein WorldCluster compiliert, was bedeutet ihr könnt per NPC 5 verschiedene Welten definieren, welche ihr nach Herzenslust umgestalten könnt.
Der WorldServer (Node) ist eine hybride TrinityCore, welche in diesem Paket als Node compiliert wurde und damit nicht für den Einzelbetrieb ausgelegt ist.
Nun was bringt einem der Spaß?
Zum einen könnt ihr hier 5 verschiedene Worlds basteln, welche sich komplett von der anderen unterscheiden kann.
Das einzige was man zu beachten hat, ist der Umstand das die Reihenfolge der Entry-IDs auf jeder WorldDB gleich bleiben muss, was durch den Cache im LogonServer bedingt ist.
Hätte man den Cache nicht, hat man bei knapp 600 Spielern Lags ohne Ende.
Ihr dürft also neue Creature-Templates bauen, müsst aber schauen das diese in der Reihenfolge bleiben.
Was uns zum nächsten Punkt bringt: Ihr könnt jeder Node eine andere World-DB zuweisen.
Das hat nun folgenden Vorteil:
Node 1 hat die normale 335a Welt ohne extras, jetzt habt ihr aber Lust eine custom Instanz zu schreiben, wollt aber die originale Inze behalten.
Kein Problem setzt euch einfach ne 2. Node mit neuer World-DB auf und baut dort alles um, die original Welt wird davon keinen Kratzer erleiden.
Die Nodes erreicht man hier auf 2 Wege, zum einen über den Befehl: .debug send test NODEID oder mittels dem NPC, den ich weiter unten als SQL poste.
Damit man aber überhaupt etwas mit der Core anfangen kann sollte man als erstes die Configs bearbeiten.
Die LogonServer.conf
RealmID = Ist die RealmID, wie auch in der AuthDB
LogonDatabaseInfo = Ist die Node/LogonDatabase, in der DB stehen alle Nodes für diesen LogonServer
WorldDatabaseInfo = sollte die Main-WorldDB sein, ist sie das nicht, dauerts zu lange um den Cache zu füttern
LogonServerPort = ist der Port, der auch in der AuthDB - Realmlist eingetragen wird
SessionThreadNumbers = Ist ganz wichtig, bei 20 Spielern reicht 0/1 (was für die Core das selbe ist). Ein Thread kann knapp 200 Leute verarzten, sollen es mehr sein, ist es erforderlich das ganze anzuheben.
OptimizeInterval = sollte auf 14 gestellt werden. Damit werden dann alle 14 Tage die Item-GUIDs der Char-DB neu organisiert.
Wer Replikationen für seinen DB-Server nutzt, sollte aufpassen, denn das ganze sorgt auf Slaves für nen freundlichen Delay wenn man Pech hat.
Network.Threads = Diese finden normalerweise kaum Beachtung, hier sollte es aber ein Augenmerk werden, denn auf 4 SessionThreads sollten 3 Network.Threads folgen.
Der Rest ist ähnlich wie die WorldServer.conf
Die WorldServer.conf
RealmID = 1 definirt hier nicht mehr den Realm, sondern die Node, D.h. ist es der Master kommt ne 1 rein, ist es Node 2 natürlich 2, etc...
(Es heißt RealmID, weil die Core wie beschrieben ein Hybrid ist)
CoreType = 0 unbedingt auf 1 setzen, niemals 2 oder 3...
LogonDatabaseInfo = NodeDB, muss die selbe sein, wie auch von jeweiligen LogonServer zu dem diese Node gehört.
WorldServerPort = Ist klar unser WorldServerPort
PoolServerPort = Der Port um mit dem logonServer zu syncen
Der Rest gleich wie auch mit der normalen TC.
Die Datenbank
Bis auf die LogonDB ist alles wie man es auch von der TC gewohnt ist.
Die LogonDB jedoch ist das wichtigste an dem ganzen System.
Ich werde mal im Schnelldurchlauf alle Tables etwas genauer erläutern.
command = hier sind die bisher wenigen Commands definiert, die der LogonServer kennt.
logonlist = Ein recht wichtiger Table.
Hier wird angegeben, welche ID, IP, Name und PW der LogonServer hat.
PW kann man sich bei der Version sparen, wichtig sind hier die ID, IP und Name.
ID = ID des LogonServers
IP = Von welcher IP der LogonServer auf die Nodes verbindet
Name = RealmName
Stimmen diese Daten beim Handshake zwischen LogonServer und Nodes nicht überein, gibts kein Handshake!
NodeList = Hier trägt man alle Nodes ein.
NodeID = ist die ID der Node (die wir in der WorldServer.conf als RealmID definiert haben)
Name = Name der Node... Is unwichtig, kann man aber zur besseren Identifizierung angeben
Address = Ist die IP auf die unser LogonServer verbinden soll um den WorldServer/Node zu erreichen
Port = ist der WorldServerPort von der Node
ControlPort = Ist der PoolServerPort in der WorldServer.conf der jeweiligen Node
NodeType = muss eine 1 sein, sonst wirds haarig
So wer alles bis hierhin verstanden hat, hat gute Karten mit dem System Spaß zu haben.
Aber: Fortsetzung folgt...
Der Tele-NPC
Code:
INSERT INTO `creature_template` (`entry`, `difficulty_entry_1`, `difficulty_entry_2`, `difficulty_entry_3`, `KillCredit1`, `KillCredit2`, `modelid1`, `modelid2`, `modelid3`, `modelid4`, `name`, `subname`, `IconName`, `gossip_menu_id`, `minlevel`, `maxlevel`, `exp`, `faction_A`, `faction_H`, `npcflag`, `speed_walk`, `speed_run`, `scale`, `rank`, `mindmg`, `maxdmg`, `dmgschool`, `attackpower`, `dmg_multiplier`, `baseattacktime`, `rangeattacktime`, `unit_class`, `unit_flags`, `dynamicflags`, `family`, `trainer_type`, `trainer_spell`, `trainer_class`, `trainer_race`, `minrangedmg`, `maxrangedmg`, `rangedattackpower`, `type`, `type_flags`, `lootid`, `pickpocketloot`, `skinloot`, `resistance1`, `resistance2`, `resistance3`, `resistance4`, `resistance5`, `resistance6`, `spell1`, `spell2`, `spell3`, `spell4`, `spell5`, `spell6`, `spell7`, `spell8`, `PetSpellDataId`, `VehicleId`, `mingold`, `maxgold`, `AIName`, `MovementType`, `InhabitType`, `HoverHeight`, `Health_mod`, `Mana_mod`, `Armor_mod`, `RacialLeader`, `questItem1`, `questItem2`, `questItem3`, `questItem4`, `questItem5`, `questItem6`, `movementId`, `RegenHealth`, `equipment_id`, `mechanic_immune_mask`, `flags_extra`, `ScriptName`, `WDBVerified`) VALUES (43430, 0, 0, 0, 0, 0, 2361, 0, 0, 0, 'TeleTyp', '', '', 21198, 80, 80, 0, 35, 35, 1, 1, 1.14286, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, '', 0, 3, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 'npc_node_changer', 1);
Die Files findet man hier:
Als DB kann man eine TDB nutzen, bis wann man die WorldDB updates von der TC Repo einspielen muss, steht in dem REV-File.
EDIT: Das ganze ist nen 3.3.5 Server.
