Old Wiki:Eve-server

From EVEmu Wiki
Jump to navigation Jump to search

Contents

EVEmu eve-server project

The eve-server is the primary executable. This project contains the actual program loop during which all server functions are performed. It also contains the code to create those services, that handle everything from docking, to warping, to the market. Probably the most integral part of the evemu source code, the eve-server is where those of you who decide to add to the source code will spend the majority of your time.

First off, this is the only one of the projects that actually compiles into anything that we actually use. Some may say that makes it the most important, but all I'll say about it is that it makes it the easiest to work with, because all of the framework necessary to write code for it is already in place in the other projects.



eve-server.cpp

This project contains the single most important file in the entire solution: eve-server.cpp. (it's named "eve-server" for a reason :) ). eve-server.cpp contains the primary loop of the server, which, while the server is running, performs the following tasks:

  1. Initialize logging, read configuration, connect to database
  2. Start API and Image servers
  3. Create various system-wide resource objects
  4. Register all services
  5. Create game memory objects: Item Factory, Module Manager effects & info tables
  6. LOOP:
    1. Check for incoming packets on the TCP connection
    2. If there is an incoming packet, decode it
    3. Make the appropriate response
    4. Send the response to the client that sent the request
    5. Scan through entire Entity List for any items that need actions taken (modules changed, timers expired, etc)
    6. Scan through entire list of services to process any actions pending
    7. Monitor for Ctrl+C server shutdown command
  7. END LOOP
  8. shut down logging, API server, Image server, TCP server
  9. close logfile
  10. Entity List destructor invokes save-off to database of all modified objects

That is folks. That's all it does. In fact that's all the entire project does...ever. All of your coding that you will more than likely be doing will be focused solely on number 3. 1, 2, and 4 are pretty much done, and unless you're doing some serious revision of the entire server structure, or just like breaking things, you'll probably never touch them. Fortunately for you, 3 covers an immense amount of code. In fact, it is almost all of the server code. Basically, number 3 is broken into various service managers. Service Managers are discussed later in this article.

So that is basically how the eve server in its entirety functions. A call is received from the client, processed by the appropriate service manager/service, and a response is sent. During that time, all manner of things can happen. The general structure of the code is as follow:

Service Managers and their associated services are found in code files called SomethingService.cpp or SomethingServiceMgr.cpp. Anything that requests information from the evemu database is found in code files named SomethingDB.cpp. Things just named Something.cpp contain data structures and the actual code behind a service call. What you will usually see is that the service call, like Handle_Add, will have statements to make sure that it can decode the arguments passed to it by the client. Once that is affirmed, the Handle_Something function will usually call a (usually protected) function that actually executes whatever the service is supposed to do. The rest of the stuff are helper functions, such as packet decodes, query formatters and so on. Here is pseudocode of what eve-server.cpp does and what happens inside:

At start-up, print splash info on Copyright, licensing, EvE client version
Set current time
Load server configuration from local eve-server.xml
via eve-server > EVEServerConfig
Load server log settings from local log.ini
via common? > LogNew
Connect to evemu mysql database using info from local eve-server.xml
via common? > DBcore
Create the DGM Type Attribute Manager
via eve-server > dgmtypeattributemgr
Start the TCP server
via eve-common > EVETCPServer -and- common? > TCPServer
Make the Item Factory
via eve-server > ItemFactory
Create the main Service Manager
via eve-server > PyServiceMgr
Create the Command Dispatcher object
via eve-server > CommandDispatcher
Register all commands
via eve-server > AllCommands.h
Register all services (see the List of Service Managers below for a complete list)
via eve-server > PyServiceMgr
Cache Database Tables using Object Cache Service
via eve-server > ObjCacheService
Set Server to ONLINE
via eve-server > PyServiceMgr
ENTER MAIN LOOP:
----Set current time and Get tick count
----Check TCP Server's TCP connection stack for the presence of any new TCP connections from EvE clients
----Add new TCP connection from the TCP Server's TCP connection stack onto the Entity list (list of clients connected to evemu server)
----via eve-server > EntityList > Add()
----Process Entity List - run through list of all Clients connected to evemu server
----via eve-server > EntityList > Process()
----Process Service List - run through list of all services registered with PyServiceMgr?
----via eve-server > PyServiceMgr
----Get tick count again, calculate remaining time for thread sleep and SLEEP that time using Sleep()
----IF Server receives SHUTDOWN signal (Ctrl-C, I think), EXIT MAIN LOOP 
END LOOP
Close TCP Server
Set Server to OFFLINE
Close Log file
EXIT MAIN - ends program execution

System-Wide Resources

eve-server contains many "singleton" objects that have exactly one and only one instance throughout the entire server. These objects are singular resources for system-wide access and functions that anything anywhere in the server code base may need access to for various reasons, such as posting a log message to the main server log, accessing the server's database connection to the EVEmu Database, or any number of in-memory database objects for the Module Manager or other critical services in the code base.

Here is a list of the current system-wide singleton objects available anywhere in the codebase using the shown mnemonic:

Service Object Mnemonic Description
sMarshalStringTable
sDatabase
sLog
sAPIServer
sImageServer
sDGM_Effects_Table
sDGM_Skill_Bonus_Modifiers_Table
sDGM_Ship_Bonus_Modifiers_Table
sDGM_Implant_Bonus_Modifiers_Table
(other ModuleManager related sDGM_XXXXX_Table objects go here)
sEntityList
sConfig
sLiveUpdateDB

Service Managers

When the client sends a request to the server, it first sends the service manager name, and then the name of the service, along with a additional arguments like itemID's clientID's...you get the picture. The server decodes the service manager name, then calls upon the appropriate service manager, and passes along the service name and the arguments that go along with it. The service manager takes this and looks through all of the services that it is capable of performing.

Once the service has been found, it invokes a new instance of that service, and passes along the arguments, which are processed by the service, and the appropriate response is sent back to the service manager, which sends that to the overall PyServiceManager?, which sends the response to be encoded and send to the TCP connection, where it is the received by the client. If everything went well, you wont see a nice little message called "BeanCount?" pop up in your server window ( unlikely ). If you do, you screwed up somewhere( very likely :D ).

Now, there are service managers for just about everything you can think of. There's a Character service manager, Ship service manager, Certificates service manager, Module service manager, NPC service manager... basically any element in the game that actually DOES anything has a service manager associated with it, because besides service calls, the only thing the client ever sends to the server is errors...which, wait for it...call a service called BeanCount?. There's even a service manager for service managers, called PyServiceMgr?, which handles dispatching service calls from the client to the right service manager. So basically, if you want to figure out why something in the game doesn't work, you need to know 2 things: the service manager name and the service name itself.

Working with Service Managers

Tip: if your implementing a service, to register it with a service manager, you need to use a function called PyCallable_REG_CALL( service manager name, serivce name) otherwise the service manager won't know about your shiny new service :)

Tip: you usually don't need the service manager name though, as you can just search the solution for Handle_[service name] since no two service calls have the same name, or if they do, it will become very apparent that one of them is not what your looking for. For instance, if the client calls Add, and you look for Handle_Add, you may run into a Handle_Add, and realize its under the character creation service manager. Obviously, as it was called when you moved an item into your inventory, this is not what your looking for. Instead you should be looking for something in the InventoryItem? manager or something similar.

List of Service Managers

NOTE: This list shows all Service Managers registered with the EVEmu Server as of revision 952 of the experimental branch

TODO: Add one-line descriptions for all service managers

ClientStatsMgr AgentMgrService MissionMgrService - manages player interaction with player missions / giving players missions, accepting, declining, etc AccountService UserService AlertService AuthService BillMgrService BookmarkService - manages player interaction with Bookmarks in all ways, creation, deletion, usage, conversion to cargo item, etc. CertificateMgrService - manages player interaction with the Certificates Manager interface, including browsing and awarding of certificates CharacterService CharMgrService ConfigService LanguageService CorpMgrService CorpStationMgrService CorporationService - manages player interaction Corporation - make corp, dissolve, manage roles of corp members, EVERYTHING in Corp Management window, etc... CorpRegistryService - manages player interaction players registration of the corporation LPService - manages player interaction with loyalty points, which he has for certaion faction ingame DogmaIMService InvBrokerService LSCService - Large Scale Chat service ObjCacheService LookupService - handles requests to lookup various in-game items, solar systems, characters, corporations and provide an orange auto-link to those resources in the client chat window VoiceMgrService - manages player interaction EVE in-game voice ShipService InsuranceService - manages player interaction with the Eve Ship Insurance and stored insurance contracts in the database BeyonceService MapService OnlineStatusService Standing2Service WarRegistryService FactionWarMgrService StationService - manages player interaction with bounty, insurance, clone, agents, owerall everthing what can be found in the station StationSvcService JumpCloneService - manages player interaction with Jump Clones KeeperService DungeonService SkillMgrService - manages player interaction with the Eve Skills browser and training queue TutorialService - manages player interaction with the Eve Tutorials PetitionerService - manages player interaction with petition service from the game master to the player SlashService MarketProxyService - this manages the entire Market experience in Eve, anything to do with the Market is done in here (buy orders, sell orders, history, etc) ContractMgrService - this manages the entire Contracts market in Eve, including Want-to-Sell contracts, Want-to-Buy contracts. Auction contracts, Corporation contracts, and player to player contracts ReprocessingService - this manages everything to do with using Reprocessing services inside stations FactoryService - this manages everything to do with Manufacturing items and ships using Industry services inside stations or at POS's with appropriate modules RamProxyService PosMgrService - this manages everything to do with Player Owned Stations (POS), shields, automatic defenses, fuel consumption, etc. NetService TradeService charUnboundMgr Missing Services ????
This is a list of service managers that have not even been created to handle parts of the game:

ScanMgrService - handles the use of the system scanner and scan probes deployed within a solar system
Asteroid Belt spawn service ??
Rat spawn service (could this be the DungeonService? ??) - this would include wormhole rats (Sleepers) as well
Wormhole spawn service
GangMgrService - handles the interaction and collaboration of multiple players through Fleets
Sovereignty service
Planetary Management service

Major Game Features and their Sections in eve-server

Major Game Feature Description Account? Handles account services Character? Handles services and functions related to EVE characters Chat? Handles services and functions related to Chat and EVEmail Corporation? Handles services and functions related to Corporations Inventory? Handles services and functions related to Items, Attributes, Inventory, etc Manufacturing? Handles services and functions related to Manufacturing Map? Handles services and functions related to the EVE universe map Market? Handles services and functions related to the in-game Market Mining? Handles services and functions related to Mining Missions Handles services and functions related to Agents and Missions NPC Handles services and functions related to NPCs POSMgr Handles services and functions related to POS stations Scanning Handles services and functions related to System and Scan Probe Scanning of solar systems Ship Handles services and functions related to Ships, Destiny, Insurance, Modules, Combat, Targeting Spawn? Handles services and functions related to Spawning NPC rats, Asteroid belts, Wormholes, etc Standing? Handles services and functions related to Standings of all kinds, Faction War, Player War Station Handles services and functions related to Station Services System Handles services and functions related to Systems, Dungeons, Celestial objects, Bubble manager, Bookmarks, Scenarios, Solar systems, etc Trade? Handles services and functions related to Inter-player Trading inside stations Tutorial? Handles services and functions related to Tutorials Client? Handles services and functions related to user Clients ClientSession? Handles services and functions related to user Client sessions EVEmu Coding Aids

Global Constants Structures

The constants structures listed below are manually created from queries on the mysql database tables, so when changes are made to the database in these areas, these constants structures would need to be updated. Some of these structures are incomplete and need to be completed.

/eve-common/tables/invCategories.h - EVEDB::invCategories:: - type this in a source file in Visual Studio to get an Intellisense drop-down box listing all entries in the 'invCategories' database table as constants that can be used for whatever you need /eve-common/tables/invGroups.h - EVEDB::invGroups:: - type this in a source file in Visual Studio to get an Intellisense drop-down box listing all entries in the 'invGroups' database table as constants that can be used for whatever you need /eve-common/network/packet_types.h - EVEItemFlags:: - type this in a source file in Visual Studio to get an Intellisense drop-down box listing all possible values that can be used in the flag field of an inventory item listed in the 'entity' table /eve-common/tables/invCategories.h - other constants structures listed in this file include MACHONETMSG_TYPE, MACHONETERR_TYPE, EVEItemType (this is incomplete), EVEItemChangeType, EVEContainerTypes, EVERookieShipTypes, EVESkillID (this is incomplete), EVEItemTypeID (this is incomplete), EVERace, EVEStandingEventTypeID, an enum containing account roles with ROLE_ prefixes, a group of Corporation Role flags as static const types and some combinations that are useful such as corpRoleAll that grants all roles, or corpRoleAllContainer that grants access to all corporation containers, EVEEffectID, JournalRefType?, EVEAccountKeys, fmtMappingType, EffectCategories? There are also a number of itemID value range checking functions to determine if an itemID found in the entity table is an Agent, or a Stargate, or other specific things. IsAgent?(), IsStaticMapItem?(), IsRegion?(), IsConstellation?(), IsSolarSystem?(), IsUniverseCelestial?(), IsStargate?(), IsStation?(), IsTrading?(), IsOfficeFolder?(), IsFactoryFolder?(), IsUniverseAsteroid?(), IsScenarioItem?() Object Oriented Design of the EVEmu Server

The entire EVEmu server is designed with an object-oriented method. Whether the current implementation is good enough is not the subject of this section, but rather to simply document what that design is.

The EVE universe is a single galaxy comprised of Solar Systems, all linked by stargates. Each Solar System contains a Star, planets, moons, stations, and other celestial objects. They also contain ships flown by pilots and ships spawned by the Server, NPC ships belonging to the many legit NPC Corporations or Pirate organizations.

CLASS: EntityList - The TOP Object

EVEmu's top object is the EntityList?, found in include/eve-server/EntityList.h. This class is a Singleton and so only ONE instance exists. It contains a protected member variable system_list m_systems. This list contains ALL Solar System objects that exist in the universe. It is a std::map<> construct with a uint32 key value and a SystemManager? secondary value. The EntityList? object also contains a list of all clients connected to the EVEmu server via a protected member variable client_list m_clients, which is a std::list<> containing the Client * reference pointers for all clients connected to the server.

Important Methods

Add(Client client) - call this passing in a pointer to a pointer of a Client object to add clients to the EntityList? FindOrBootSystem?(uint32 systemID) - call this passing in a uint32 value equal to the solarSystemID from the mapDenormalize table in order to either Find or Boot that solar system. If the referenced solar system has not had its own SystemManager? object created yet since server start, this function will do that, otherwise, the pointer to the referenced solar system SystemManager? object that already exists will be returned. Broadcast(), Multicast(), Unicast() - These broadcast functions are ways to call Client::SendNotification?() on one or more Client objects referenced in the m_clients list. FindCharacter?(), FindByShip?(), FindAccount?(), FindByStation?(), FindByRegion?() - These functions serve to find Client reference pointers using characterID, characterName, shipID, accountID, stationID, or regionID, the last two return a std::vector<> list of Client reference pointers. Warning: Each of these Find functions make use of simple for() loop search methods, so with very largely populated EVE universes, these functions could potentially take a long time to execute, so make very sparse use of them. Consider strongly a more efficient way of finding the Client object of some character or ship piloted by a character BEFORE resorting to using these functions. CLASS: SystemManager?

The SystemManager? class, found in eve-server/system/SystemManager, is the next class object down in the hierarchy, which manages each Solar System. So, as characters log into the server, they enter the game world in specific Solar Systems and if those systems have not been created yet, a SystemManager? object for each of them is created and stored in a list inside the EntityList? as mentioned above. This class object contains a number of things localized to a Solar System and they include a SystemEntity? list in the form of a std::map<> that holds pointers to SystemEntity? objects, each of which are references to objects that exist in that Solar System, a systemID value, a systemName value, a systemSecurity value, its own SpawnManager? object, and its own SystemDB object providing access to the database.

NOTES: Much work is needed to manage Asteroid Belt, NPC ship/fleet, Cosmic Anomaly, and Cosmic Signature spawning in each Solar System. It may be that the SpawnManager? object owned by each SystemManager? object will take care of these spawnings, but the SpawnManager? objects need entries in the 'spawns' and 'spawnGroups' tables in the Database. NPC ships/fleets need targets when they spawn, especially when a ship warping to a location within a solar system triggers a spawn, as would happen when entering the grid of a Cosmic Signature marking a complex, or an Asteroid Belt spawning rats. So, the SystemManager? should be expanded to hold a list of ships in space, perhaps, and not just a list of SystemEntities?, however, more research into the SystemEntities? classes are necessary to see if scouring the list of those in a solar system, held by the m_entities protected variable will work as a means for a particular NPC ship/fleet to gather a list of targets in its immediate vicinity. CHANGES It has been proposed that we make several std::map protected member variables along with Add(), Get(), Find(), and Remove() support functions to separate out different kinds of SystemEntity? objects, such as ships in space, cargo containers, POS modules, drones, NPC ships, asteroids, cosmic signatures and anomalies, and other dynamic objects Use simple array objects for static objects like NPC stations, stars, planets, moons, stargates This will make it easier to get lists of targets for NPC ship engagements Important Methods

BootSystem?() - This loads the solar system celestials via the _LoadSystemCelestials() call and loads the system dynamics via the _LoadSystemDynamics() call. There is also code here that loads all spawns and fires up the initial spawn via the SpawnManager?, however, this code is commented out with a note that it makes the "client angry". More research is needed to find out what's going wrong, if anything. ProcessDestiny?() - This is called once for each Destiny second. More research is needed to determine exactly what this does. AddClient?() - Add a client to the list of SystemEntity? objects. This would be done if a pilot's ship jumps into this solar system either with a jump capable ship or a stargate. RemoveClient?() - Removes a client from the list of SystemEntity? objects. This would be done if a pilot's ship jumps out of this solar system either with a jump capable ship or a stargate. AddNPC() - Adds an NPC SystemEntity? to the SystemEntity? list. This would be done when an NPC ship/fleets spawns or is triggered due to a incoming warp to a location where the spawn is located. RemoveNPC() - Removes an NPC SystemEntity? from the SystemEntity? list. This would be done when an NPC ship/fleets is destroyed or de-spawns from a location. AddEntity?() - Adds a generic SystemEntity? object to the list of SystemEntity? objects. RemoveEntity?() - Removes a generic SystemEntity? object from the list of SystemEntity? objects. CLASS: SystemEntity?

Found in eve-server/system/SystemEntity.h ABSTRACT CLASS : NO INSTANCES ALLOWED TBD

Important Methods

TBD

CLASS: ItemSystemEntity? derived from SystemEntity?

ABSTRACT CLASS : NO INSTANCES ALLOWED Found in eve-server/system/SystemEntity.h

CLASS: DynamicSystemEntity? derived from ItemSystemEntity?

ABSTRACT CLASS : NO INSTANCES ALLOWED Found in eve-server/system/SystemEntity.h

CLASS: InanimateSystemEntity? derived from SystemEntity?

ABSTRACT CLASS : NO INSTANCES ALLOWED Found in eve-server/system/SystemEntities.h

CLASS: SimpleSystemEntity? derived from InanimateSystemEntity?

Found in eve-server/system/SystemEntities.h

CLASS: SystemPlanetEntity? derived from SimpleSystemEntity?

Found in eve-server/system/SystemEntities.h

CLASS: SystemStationEntity? derived from SimpleSystemEntity?

Found in eve-server/system/SystemEntities.h

CLASS: SystemStargateEntity? derived from SystemStationEntity?

Found in eve-server/system/SystemEntities.h

CLASS: SystemSimpleEntity? derived from SystemPlanetEntity?

Found in eve-server/system/SystemEntities.h

CLASS: SystemDungeonEntranceEntity? derived from ItemSystemEntity?

Found in eve-server/system/SystemEntities.h

CLASS: tbd

Found in ???

Conversations with Luck on eve-server

[14:41] <@AknorJaden_> well, i've been trying to look at different sections of the eve-server to fix little problems like undocking, chats, etc. but i haven't been able to make sense of the API between the service managers and the eve-common stuff that receives, decodes packets, then encodes and sends packets back to the clients [14:42] <@Luck> okay [14:42] <@Luck> everything is organized into different types of calls [14:42] <@AknorJaden_> i guess it's just that there is SO much stuff [14:42] <@AknorJaden_> yeah saw that [14:42] <@Luck> lol [14:42] <@Luck> each call is expecting a different way to decode the packets [14:43] <@Luck> so you declare the object from eve-common [14:43] *** DanTheBanjoman has joined #evemu [14:43] *** ChanServ sets mode +o DanTheBanjoman [14:43] <@AknorJaden_> ok, but i bet there isn't some kind of class diagram for all the object classes in the code base, is there? [14:43] <@Luck> call decode on the packet [14:43] <@Luck> sure there is [14:43] <@AknorJaden_> really? [14:43] <@Luck> all of those packet decoding is generated from xml files by the xmlpacketgen project [14:43] <@AknorJaden_> yeah, i figured that out at the highest level [14:44] <@AknorJaden_> those xmlp files get run through xmlpktgen to create the .h files [14:44] <@Luck> yea [14:45] <@Luck> so you look at those xml files [14:45] <@AknorJaden_> do understand the packet structure, eh? [14:45] <@Luck> and you get an idea of what each call does [14:45] <@Luck> ? [14:45] <@Luck> do i? [14:45] <@AknorJaden_> no, lol [14:45] <@AknorJaden_> i meant "to", not "do" [14:45] <@Luck> oh [14:46] <@Luck> yes [14:46] <@AknorJaden_> ok [14:46] <@Luck> they were all determined by packet sniffing [14:48] <@AknorJaden_> ok [14:48] <@Luck> so what else do you want to know? [14:48] <@AknorJaden_> lol....everything ;) [14:49] <@AknorJaden_> maybe i should start from the top: packets come in from the client and are received where? [14:50] <@Luck> the TCP connection [14:50] <@AknorJaden_> oh right [14:50] <@Luck> :) [14:50] <@Luck> they are passed to the PyDispatcher [14:51] <@AknorJaden_> ah [14:51] <@Luck> which looks at the information contained in the packet that says which service the client is calling [14:51] <@AknorJaden_> ok, starting to make sense [14:52] <@AknorJaden_> so then it calls that appropriate service, right, such as LSCService for chats/mails? [14:52] <@Luck> the dispatcher passes the packet to the required service, and the service dispatcher reads the particular call to it, and if it has a function registered to handle that call, it calls that function [14:52] <@Luck> yes [14:52] <@Luck> and LSCService looks to see if it has a function to handle the particular call [14:52] <@Luck> like Handle_SendMessage [14:53] <@Luck> time to commit [14:53] <@AknorJaden_> ok [14:55] <@AknorJaden_> got it [14:59] <@AknorJaden_> so now that the packet has called the right function in the right service, how does the packet info get used (is it the "args" object) and then there's the use of that info to do whatever the function called is supposed to do [14:59] <@Luck> you notice that every function called Handle_Something [15:00] <@AknorJaden_> yeah, lot's of those, but not all [15:00] <@Luck> i mean [15:00] <@AknorJaden_> nevermind, pretty much all of em [15:00] <@Luck> every function that has a name like that has the same argument [15:00] <@Luck> PyCallArgs &args [15:00] <@AknorJaden_> yeah, i was just about to type that [15:01] <@Luck> not all of them ( there are a few exceptions) but almost all [15:01] <@Luck> the first part of the function will declare a call object [15:01] <@AknorJaden_> and the value "call" is polymorphic, right? where PyCallArgs is some kind of base class for all packets? [15:01] <@Luck> Call_SendMessage args; [15:02] <@Luck> then you use that Call object to decode the PyCallArgs& call [15:02] <@Luck> args.Decode( call.tuple ) [15:02] <@Luck> once you do that, the args object will have the appropirate information in it [15:02] <@AknorJaden_> now, what is the call.tuple? [15:02] <@AknorJaden_> or don't i care at this point? [15:02] <@Luck> call is the PyCallArgs object argument passed to the function [15:03] <@Luck> and call.tuple means to decode the tuple inside the PyCallArgs object [15:03] <@AknorJaden_> oh, right, duh. why the tuple attribute? how come that's not private. aren't most data members of a class supposed to be private? [15:03] <@AknorJaden_> ok [15:03] <@Luck> not ones that we want to acces [15:03] <@Luck> :) [15:04] <@AknorJaden_> call->getTuple() wouldn't be better? [15:04] <@AknorJaden_> not so encapsulated [15:04] <@Luck> in some respects yes [15:04] <@AknorJaden_> ok [15:10] <@AknorJaden_> so, then i guess the rest of the story is to go some place in the code to understand *what* is in the args object once it's been decoded, and then start using that info? [15:11] <@Luck> it goes to figure out what is in the call object [15:11] <@Luck> PyCallArgs &call [15:11] <@AknorJaden_> what does, the .Decode() method? [15:11] <@Luck> args is the result of the decoded call [15:11] <@AknorJaden_> ok [15:12] <@Luck> args can then be used normally [15:13] <@Captnoord> re [15:14] <@AknorJaden_> ok, so args is an object that has data structures inside that contains info for the function called? [15:14] <@Captnoord> AknorJaden: the reason for the objects not to have them protected is because of the packet code generator [15:14] <@AknorJaden_> you mean xmlpktgen? [15:14] <@Captnoord> yup [15:14] <@AknorJaden_> ok [15:14] <@Captnoord> which is a piece of shit [15:15] <@AknorJaden_> LOL [15:15] <@Luck> hahaha [15:15] <@Luck> he's right [15:15] * @Luck waves a Captnoord [15:15] <@AknorJaden_> it's ok. i'm no OOD expert, but i do undedrstand encapsulation [15:16] * @Captnoord waves back..... [15:17] <@Captnoord> hmmm my girl offers me something I can't ignore..... [15:17] <@Captnoord> crap... [15:17] <@Captnoord> :P [15:17] <@AknorJaden_> dude, what are you waiting for ....GO [15:19] <@Luck> lol [15:19] <@Luck> gtfo of here man [15:19] <@AknorJaden_> so, luck, when i am in the LSCService, i need to go look at the xmlp files (or more appropriately, the .h files) to find out what stuff is in the decoded args object? [15:19] <@Luck> that's one way yes [15:20] <@AknorJaden_> ok, is there an easier way? [15:20] <@Luck> start typing args. [15:20] <@Luck> and see what intellisense tells you is available [15:20] <@Luck> :) [15:20] <@Luck> not always accurate though [15:20] <@AknorJaden_> where, in the function i'm in? [15:20] <@Luck> yea [15:21] <@Luck> your better off looking at the Decode() function for that particular call though [15:21] <@Luck> oh [15:21] <@Luck> if anyone is interested, new commit to the exp branch [15:21] <@AknorJaden_> ok, thanks for the tip. but am i right about going to the .h files under eve-common\include\packets for the source? [15:21] <@Luck> no.. [15:21] <@Luck> go to the .cpp files [15:22] <@Luck> well i guess you could go to the .h files [15:22] <@AknorJaden_> so, eve-common\src\packets ? [15:22] <@Luck> i guess [15:22] <@Luck> i look at it in VS [15:22] <@Luck> structure is slightly different [15:22] <@Luck> wait [15:23] <@AknorJaden_> yeah, that's what i meant. i look at the .h and .cpp files in VS [15:23] <@Luck> nvm [15:23] <@Luck> kk [15:23] <@Luck> yea [15:23] <@Luck> eve-common/src/packets [15:23] <@Luck> the ability to ban accounts from the server has been added [15:23] <@Luck> exp branch rev 975 [15:23] <@Luck> *974 [15:25] <@AknorJaden_> cool, i can ban myself from my own solo server LOL [15:25] <@Luck> lol [15:25] <@Luck> careful [15:25] <@Luck> it will kick you [15:25] <@AknorJaden_> well duh! [15:25] <@Luck> and you won't be able to log back into unban yourself [15:25] <@Luck> so you'll have to edit your db [15:25] <@AknorJaden_> ah, but i can use phpmyadmin! [15:25] <@Luck> fair enough [15:25] <@AknorJaden_> hehe [15:26] <@Luck> you should read the announcement on the forums about it [15:26] <@AknorJaden_> oh, hey that reminds me...eve-server isn't coded to take advantage of multi-core processors is it? [15:27] <@AknorJaden_> brb [15:29] <@Luck> umm not really [15:33] <@Luck> k guys, i g2g deal with some rl shit [15:33] <@Luck> i'll ttyl [15:33] *** Luck has quit IRC: [MF] Quit: Leaving [15:34] <@AknorJaden_> or for that matter, eve-server definitely doesn't run on a server farm either, eh?


  1. client sends packet to server
  2. packet received by TCP section
  3. received packets are sent to PyDispatcher
  4. PyDispatcher looks at packet info to figure out what service to call
    1. the dispatcher passes the packet to the required service, and the service dispatcher reads the particular call to it, and if it has a function registered to handle that call, it calls that function