packet_struct_notation.txt 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485
  1. //===== Athena Doc ========================================
  2. //= Packet Structure Notation
  3. //===== By ================================================
  4. //= Ai4rei
  5. //===== Version ===========================================
  6. //= 1.0
  7. //=========================================================
  8. //= 1.0 - Initial version.
  9. //===== Description =======================================
  10. //= Explanation how packets are and should be documented.
  11. //=========================================================
  12. This document specifies how packets are and should be documented, to
  13. keep packet structure comments consistent in the entire codebase. It
  14. also serves as a guide to those, who are unfamiliar with the general
  15. packet layout.
  16. All mentioned data types are assumed to be little-endian (least-
  17. significant byte first, least significant bit last) and of same size
  18. regardless of architecture.
  19. = Typical description of a packet =
  20. /// Notifies the client about entering a chatroom (ZC_ENTER_ROOM).
  21. /// 00db <packet len>.W <chat id>.L { <role>.L <name>.24B }*
  22. /// role:
  23. /// 0 = owner (menu)
  24. /// 1 = normal
  25. The first line contain a brief description of what the packet does,
  26. or what it is good for, followed by it's AEGIS name in parentheses;
  27. first two letters of the AEGIS name specify origin (first letter)
  28. and destination (second letter) of the packet. If the packet's name
  29. is not known or is not applicable (rAthena server-server packets),
  30. specify at least these two letters to indicate the direction of the
  31. packet. Do not use S(end)/R(ecv) for this, as it is inaccurate and
  32. location dependent (if the description is copied to different server
  33. or other RO-related projects, it might change it's meaning).
  34. If there are multiple versions of the packet, the AEGIS name is
  35. appended to the end of the packet's structure instead. If the name
  36. did not change between versions, a PACKETVER expression is appended,
  37. such as (PACKETVER >= 20111111).
  38. Second line describes the packet's field structure, beginning with a
  39. %04x formatted packet type, followed by the individual fields and
  40. their types. Each field begins with it's name enclosed in angle
  41. brackets ( <field name> ) followed by a dot and the data size type.
  42. Field names should be lower-case and without underscores. If other
  43. packets already have a field in common, use that name, rather than
  44. inventing your own (ex. "packet len" and "account id"). Repeated and
  45. optional fields are designated with curly and square brackets
  46. respectively, padded with a single space at each side.
  47. Further lines are optional and either include details about the
  48. the packet's mechanics or further explanation on the packet fields'
  49. values.
  50. = Packet field data size type =
  51. B = 1 byte (byte)
  52. W = 2 bytes (word)
  53. L = 4 bytes (dword)
  54. Q = 8 bytes (quad)
  55. nB = n bytes
  56. ?B = variable/unknown amount of bytes
  57. nS = n bytes, zero-terminated
  58. ?S = variable/unknown amount of bytes, zero-terminated
  59. = Repetition of packet fields =
  60. {} = repeated block
  61. {}* = variable/unknown amount of consecutive blocks
  62. {}*n = n times repeated block
  63. [] = optional fields
  64. = Packet origin and destination letters =
  65. A = Account (Login)
  66. C = Client
  67. H = Character
  68. I = Inter
  69. S = Server (any type of server)
  70. Z = Zone (Map)