project/Network: Difference between revisions
Jump to navigation
Jump to search
Technology (talk | contribs) m (initial draft) |
Technology (talk | contribs) m (→Network tables) |
||
Line 15: | Line 15: | ||
==Network tables== | ==Network tables== | ||
===From tables to serverType object=== | ===From tables to serverType object=== | ||
Beyond this i will use kRO | Beyond this i will use kRO as the serverType name. | ||
:{|border="1" cellpadding="2" cellspacing="1" | :{|border="1" cellpadding="2" cellspacing="1" | ||
|- style=background-color:#F9F9F9; | |- style=background-color:#F9F9F9; |
Revision as of 20:25, 22 July 2010
Introduction
The following document is the (still incomplete) specification for the design and future implementation of Network in OpenKore.
Note: actual implementation may change and names may vary.
Problems in current Network design
- The serverType specific code is bad.
- Querying for packetID in the code to determine how to unpack is bad.
- The xkore's are hacked in.
- The send part's subs all have their own pack strings and similar code.
- The (un)packing of nested structure type packets is not supported. (handlers need to preform additional unpacking)
- The packet structures are not shared between different serverTypes. (serverTypes must define packets from scratch)
- ...
Network tables
From tables to serverType object
Beyond this i will use kRO as the serverType name.
# Action Description Example 0 read from: PACKET LIBRARY (tables) tables/PACKET_HANDLE_STRUCT.txt 1 store all (un)pack obj to: PACKET LIBRARY (kore) 2 read from: SERVERTYPE[_COMPILEDATE] (user selected) kRO_2010-05-11aRagexeRE 3 read from: PACKET ID HANDLE tables/kRO/PACKET_ID_HANDLE.txt from top till [2010-05-11aRagexeRE] 4 read from: PACKET IMPLEMENTATION tables/kRO/PACKET_IMPLEMENTATION.txt from top till [2010-05-11aRagexeRE] 5 pick (un)pack obj from: PACKET LIBRARY (kore) using PACKET IMPLEMENTATION 6 create a serverType obj: (see 5)
tables/PACKET_HANDLE_STRUCT.txt
description:
- contains all existing packet STRUCT's identified by their respective HANDLE's
notes:
- shared with all ST
- packet lengths can be derived from STRUCT's (can be used in combination with PACKET_ID_LENGTH.txt to do checking or to find serverType)
caveats:
- needs preprocessor directives (see PACKET_IMPLEMENTATION.txt caveat 2.2)
example:
struct EQUIPSLOTINFO { /* this+0x0 */ unsigned short info[4]; } #ifndef EQUIPMENTITEM_EXTRAINFO3 // older (default to this, if EQUIPMENTITEM_EXTRAINFO3 was not defined) struct EQUIPMENTITEM_EXTRAINFO3 { /* this+0x0 */ short index; /* this+0x2 */ unsigned short ITID; /* this+0x4 */ unsigned char type; /* this+0x5 */ bool IsIdentified; /* this+0x6 */ unsigned short location; /* this+0x8 */ unsigned short WearState; /* this+0xa */ bool IsDamaged; /* this+0xb */ unsigned char RefiningLevel; /* this+0xc */ struct EQUIPSLOTINFO slot; /* this+0x14 */ long HireExpireDate; /* this+0x18 */ unsigned short bindOnEquipType; } #elif EQUIPMENTITEM_EXTRAINFO3 == 1 // newer (pick if condition is fulfilled) struct EQUIPMENTITEM_EXTRAINFO3 { /* this+0x0 */ short index; /* this+0x2 */ unsigned short ITID; /* this+0x4 */ unsigned char type; /* this+0x5 */ bool IsIdentified; /* this+0x6 */ unsigned short location; /* this+0x8 */ unsigned short WearState; /* this+0xa */ bool IsDamaged; /* this+0xb */ unsigned char RefiningLevel; /* this+0xc */ struct EQUIPSLOTINFO slot; /* this+0x14 */ long HireExpireDate; /* this+0x18 */ unsigned short bindOnEquipType; /* this+0x20 */ unsigned short addedField; } #endif
tables/kRO/PACKET_IMPLEMENTATION.txt
description:
- dictates kore which packets to use from the (PACKET_HANDLE_STRUCT.txt) packet library
notes:
- ST specific
- is (if wanted) sectioned up in compile|distribution-dates so it is possible to support ST's like eA
- packetFUNCTION is what will be used in kore's code
caveats:
- new packets (new HANDLE, FUNCTION) can get added over time
- STRUCT ????, HANDLE ???? => solved by: adding the packetHANDLE and packetFUNCTION (need last one too?)
- old packets when we look at FUNCTION can change in (STRUCT and HANDLE) are 2 situations:
- STRUCT diff, HANDLE same => solved by: encapsulation the different packet's versions in (#if packetHANDLE == X) in the (PACKET_HANDLE_STRUCT.txt) packet library and #define's in ~
- STRUCT ????, HANDLE diff => solved by: linking packetHANDLE and packetFUNCTION
- a combination of 1) and 2) => solved by: first 1) (filter out by defines) then 2) (assign FUNCTION)
structure:
[RGZ_NAME] #define PACKET_HANDLE 1 // solves 1 packetHANDLE packetFUNCTION // solves 2 [END]
example:
[2010-05-11aRagexeRE] // from 2010-05-11aRagexeRE.rgz #define EQUIPMENTITEM_EXTRAINFO3 1 EQUIPMENTITEM_EXTRAINFO3 EQUIPMENTITEM_EXTRAINFO [END] // after this follows kRO (non eA) specific stuff
tables/kRO/PACKET_ID_HANDLE.txt
description:
- links packetID's to packetHANDLE's
notes:
- ST specific
- is (if wanted) sectioned up in compile|distribution-dates so it is possible to support ST's like eA
structure:
typedef enum <unnamed-tag> { ... packetHANDLE = packetID, ... } <unnamed-tag>;
example:
typedef enum <unnamed-tag> { ... HEADER_CZ_PARTY_BOOKING_REQ_SEARCH = 0x804, ... } <unnamed-tag>;
tables/kRO/PACKET_ID_LENGTH.txt
description:
- contains all existing packet lengths identified by their respective ID's
notes:
- ST specific
- replaces recvpackets.txt (the name makes no sense, the file contains the length of sent packets as well)
- is redundant, the packetlength can be derived from the structs in (PACKET_HANDLE_STRUCT.txt)