How the online functions work

A reference for everyone building on this server: every online function of eFootball PES 2021 (1.01.00, Steam), worked out from the game itself. It covers what each command is for, how the game uses the reply, and what a private server has to send. It continues the technical write-up, which covers the wire format, login and Quick Match. Static analysis of the game binary and our own test logs, 2026-11-05.

What changes for our server

The findings that change server behaviour, most important first. Each one links to its section.

1. No relay fallback exists today. The game only uses TURN when GET_TURN_SERVER_LIST returns servers; we return none. Run coturn (TURN over TLS), answer the list with credentials and certificate, and forward SEND_TURN_ADDRESS_DATA to the opponent as a WATCH_TURN_ADDRESS_DATA push. The UDP 7600 "game relay" isn't a fallback and can go. Connecting the players → DONE Built, on by default since 2026-11-06 (TURN=0 turns it off): a small TURN server inside our program (TLS 5349, UDP relay 49160–49179 opened with UPnP, RFC 8016 mobility, which the game asks for), a self-signed certificate naming the server's addresses, TURN REST credentials, and byte-exact address forwarding. Traffic between two players' relays is handed over inside the program, so no router loopback is needed. First live run (against coturn): the game accepts our list and certificate and allocates over TLS; it needs mobility, which coturn refused by default (mobility alone is not enough: see the next sentence). coturn's own test client works against our relay with no loss. Tested with the game (2026-11-05): allocation over TLS works, but the game also needs a SOFTWARE "dual route" directive HOST:PORT,<text>,0 (otherwise it restarts every second) and then a second relay leg over DTLS/UDP before it publishes its relay address. Live tests → OPEN
2. The host's own address is wrong for remote friends. When the server runs in a player's home, that player's reflexive address is their LAN IP, so a friend in another home is told to connect to an unreachable address. Rewrite it to the public IP when the opponent is remote. This alone may explain "Failed to connect with opponent". → DONE Confirmed in our logs (the host's game reported 192.168.1.100); the server now swaps in the address the remote friend uses to reach the server, port unchanged. Not yet tested between two homes.
3. Deliver peer notices exactly once, in order. pid_list grows by one copy per match; a duplicate START/END notice at the head of the queue blocks the P2P rendezvous for 30 s. Dedupe and exclude the sender. → DONE Confirmed in our logs: [1], [1, 1], [1, 1, 1]… was delivered that many times. The sender is never in its own list.
4. Push the verdict WATCH_GAMEADDPOINT. Without it, one player stalls 20 s after every match (Quick Match never shows the rating screen anyway, see results). Answer REQ_GAMEADDPOINT and push ratings, win streak and winner; gameend_reason must be NORMAL_END. → DONE Our logs show both games sending REQ, also after aborted matches. The server answers REQ with the verdict when the match reached END (Elo from 1000, K 32, win streak), and sends nothing after an abort, since any other end reason shows OLXH186. It also pushes the verdict to every player at the final whistle (default; PESSERVER_VERDICT_AT_END=0 turns it off). Live: this ends Quick Match, Divisions, Matchday, Tournament and co-op matches cleanly, with no DISCONN_P2P from the slower player.
5. Live scores never update: goals arrive as CMD_ADD_SCORE; CMD_ADD_GOAL doesn't exist. Dedupe by gtimer (both clients report). → DONE Both games sent the same goal with gtimer 2996; each (gtimer, side) now counts once.
6. Reconcile both SEND_GAME_RESULT reports (one says NOERR, the other DISCONN_P2P with the same score), and keep SET_PLAYDATA_MATCH (scorers, player ratings), STATS_DATA and the line-ups. →
7. Pair only players whose CHECK_CHEAT sums match, or they fail with "DATAPACK error" after connecting. JOIN_ONLINE_MODE → ERR_MODE_BLOCKED is a clean version gate. Record SEND_TAMPER_DATA as a cheat flag. → DONE Matchmaking pairs only games with the same param_check_sum, patch and DLC version, and the admin feed says once why two searching players aren't matched. Games that never send the sum pair with anyone. Tamper reports go to the admin feed. No version gate yet (pairing already keeps versions apart).
8. The game database is decoded (players, teams, rosters, shirt numbers), and the login checksums reproduce exactly from the files: both test clients ran the stock update pack. Delivering live data would change every player's checksum. →
9. The Live Update channel is mapped: the server can give every player the same data (rosters, form) through the game's own downloader: an HTTP GET of one CPK, checked only by a server-supplied SHA-256. Same data → same checksums → no DATAPACK errors. →
10. The server can tune the player-to-player link: all connect timeouts and direct/TURN switching thresholds come from JSON the server sends in GET_SERVER_ENV.proto_opt (we send none → defaults; direct connect gives up after 15 s, twice). →
11. Use the game's own texts: replies like ERR_INVALID_ACCOUNT (ban), ERR_FREE_TO_PLAY_FULL (server full) or ERR_COMMAND_BLOCKED show clear messages instead of a bare code. →
12. Live tests (2026-11-05/06): our own Live Update works end to end (checksums exactly as predicted, as long as the server keeps listing the update); the relay works end to end once it handles the game's ktc DTLS framing and port changes, and a match can be played over it alone (DONE in the server: turndtls.py, UDP 5350, relay on by default); reconnect survives a ~7 s outage; a whole lobby match and the return to the room work. →
13. Never push a RELOAD list into a game that already holds entries: it ends the game (uncaught C++ exception in the watch-list merger, confirmed live). RELOAD only as the reply to a new REQWATCHL_* request; pushes are ADD/UPDATE/DEL. →
14. Send each player's reflexive_addr exactly as that player reported it. The game picks the side that opens the match link by comparing two address strings: its own reported reflexive address and the peer's reflexive_addr the server sent. Only the "lower" side opens; if the server rewrites one side's address so both think they are higher, both wait and the match fails with MXNV_0013 after 10 s (seen live with test addresses). Our reflexive rewrite for the host's LAN (_visible_addr) can do this for friends whose public IP sorts between the host's public and LAN addresses. Put the public IP into host_addr instead, which is never compared (gncx_labels.md). STATIC →
15. Split large replies into 0x70 / 0x71 / 0x72 fragment frames; the client rejects any frame body over 0x410 bytes. → DONE Both ways, with the layout from the send path 0x1418537d0 (chunks 0x3f3, then 0x3fc; 0x2x for pushes). Tested on every size around the boundaries, not yet against the game, so the admin page still refuses a news message that needs more than one frame.
16. Never reply ERR_CHEAT to in-match commands, and keep key_size 16 (32 switches the whole game to AES until restart). GET_MATCHID upload:"YES" is safe: it is how match replays are recorded (see spectating). →
17. CMD_RECONNECT is unimplemented: after a gate drop it needs a session key like SET_CURRENTPLAYER. → DONE A new 16-byte key; the new connection takes over the player's place (unknown pid: ERR_LOGIN_FAILED). Live: after a 7-second server outage mid-match both games reconnected and played on; after 15 seconds they show APLR_0002, and in the menus VNBP_0002 with no reconnect attempt.
18. Rooms for "play a chosen friend" are specified: blocks, room list and player lists (replies, then UPDATE pushes; never a RELOAD push), ENTRY_GAME, owner start via SET_GAMEMEMBER, room states. → Live: creating a room works (own room in the room list first, player list sent only as the reply, nested psn_user_id blob); with the real game_env echoed into the room list (limitTime NOSET hides a room), a friend sees the room, joins, and both reach team selection (2026-11-06). DONE Built into the server (pesrooms.py) and tested live on the real server code: create, join, ready, start, team selection. →
19. Online Co-op works, one player per side (mod 0.5.0 + pescoop.py, live 2026-11-06): the game's own co-op never handed the opponent to its P2P layer; the mod adds that step and the server does force_alone matching, one WATCH_COOP_MATCHING push, real teams, game_sycom "P2P" and the SYNC_PROGRESS echo. The P2P layer takes exactly one peer, so 2v2/3v3 with more humans can't run. Spectating is switched on by upload:"YES" and served as AES chunks over HTTP. →
20. The server can put its own text on screen: an urgent announcement, a news list, and a "maintenance soon" warning. Done: all three tested in the game and on the admin page. →
21. Tooling: schemas.json misses 1,907 reply fields in 108 commands (extractor bug, fixed in the notes, not yet applied to the server). notes/re/errcode.py's default game path broke when the repo moved. →

↑ Back to contents

Connecting the two players: NAT traversal, TURN relay, game relay

How a match connection is set up

1. Network test at mode entry: the NTL library ("NTL 1.11.11-Windows64") tests the NAT against the STUN server (UDP 3478) and GateInfo.php, tries UPnP, then reports its addresses with CMD_SEND_IPANDPORT_NTL {host_addr, reflexive_addr, relayed_addr, ntl_nat_type}. LIVE
2. Pairing: CMD_WATCH_MATCHING member blobs carry each peer's NTL addresses. LIVE
3. Match session task (OnlineModeTaskMatchSession.cpp, fn 0x1411430b0, state in [task+0x70]): GET_SERVER_ENV → GET_TURN_SERVER_LIST (states 9/0xa) → SetConfig() (state 0xb) → CreateMultiplaySession (state 0x11; also starts ConnectTurnTask and the WATCH_TURN_ADDRESS_DATA watch) → wait for the link (state 0x15) → revision check → connected (0x1a). Errors go to state 0x17. STATIC
4. Connection strategy (factory 0x1411aa730) depends only on whether the TURN list is empty. The NAT type is not consulted: STATIC
   • empty list (our server today) → P2pFullMesh: NTL hole punching only, no relay;
   • non-empty list → P2pFullMeshWithTurn with P2pTurnIoFailover: direct path plus a TURN path, switching between them. (Debug tunables turn_mode / direct_online_turn_mode default to this.)
5. When the link doesn't come up in about 30 s, both games report CMD_SET_GAMERELAY_CHECK_RES {error_code ER_MATCHING_RETRY, failed_reason 2}. LIVE The match task retries once after 15 s (cmp rax,0x3a98 at 0x141143ccd). Link results: 1 ok, 2 "Revison check TIMEOUT", 3 "Revision error", 4 "DATAPACK error", 5 "Other user disconnected". STATIC

client A                 our server                          TURN server (coturn)          client B
GET_TURN_SERVER_LIST ──► {turn_server_list, id, pw, cert}
TLS over TCP to tls_port ──────────────────────────────────► Allocate (401 → auth) → relayed address A
SEND_TURN_ADDRESS_DATA{A} ──► push WATCH_TURN_ADDRESS_DATA{A} ────────────────────────────────────► B
WATCH_TURN_ADDRESS_DATA{B} ◄── ◄── SEND_TURN_ADDRESS_DATA{B} ◄──────────────────────────────────── B
CreatePermission / ChannelBind (B) ────────────────────────► relays A ⇄ B ◄────────────── B does the same

CMD_GET_TURN_SERVER_LIST: TURN servers and credentials

• Transport: HTTP (URL type GET_TURN_SERVER_LIST). Requested every match, twice per client, once by the match task and once by ConnectTurnTask. Not at login. LIVE
• Request: pid, turn_account_param (= the pid as text), turn_time_limit (always 60). The game never uses either value itself. They look like hints for time-limited TURN credentials. STATIC INFERRED
• Reply (parser 0x141e4e650, stored in onlinesystem::ParameterTurn): STATIC
  • turn_server_list: an array of inline maps (not nested blobs) {zone NUM, address STR, port NUM, tls_port NUM}. Entries with port or tls_port = 0 are dropped. Only tls_port is used to connect; port only has to be non-zero. Any zone works: servers are grouped by zone, and failed ones are skipped for a while.
  • id / pw (STR): TURN long-term username and password. If either is empty, TURN is silently skipped.
  • server_certificate (STR): base64 of a DER X.509 certificate (a PEM body without its BEGIN/END lines works), added to the TLS trust store. server_certificate_data_size (NUM) = number of DER bytes. Invalid DER aborts the TLS session.
  • origin (STR, optional): passed to the TURN client config (ORIGIN attribute, RFC 7635 style).
• Bare {result:NOERR} (today): empty list → no relay; nothing errors. LIVE

The TURN client: Konami "ktc-0.0.0"

• A standard RFC 5766/8656 client (namespaces ktc::session, ktc::socket, ktc::lib::TlsSession, OpenSSL 1.1.0i): Allocate / Refresh / CreatePermission / ChannelBind, 401+nonce long-term auth, 438 stale nonce, 437 allocation mismatch, 405 mobility forbidden. Defaults: lifetime 60, 10 retries. STATIC
• Transport: TURN over TLS on TCP (RFC 5766 §2.1) to address:tls_port. After allocating, the game requires the relay's SOFTWARE attribute to be a Konami "dual route" directive HOST:PORT,<text>,0; without it, the session restarts every second. With it, the game also opens a second leg over DTLS/UDP to that address and only publishes its relay address once that leg works. STATIC LIVE (live tests)
• The switch-over thresholds (ChangeoverToTurnReceiveIdleTimeMsThreshold, TurnNetworkIoConnectionTimeoutMs, TcpFallbackEnable, …) come from the game's local multiplay parameter data, not from the server. STATIC
• The NTL library has its own, separate TURN client (ntl::TurnClient), which would fill relayed_addr. That field is all zeros in every log, and no code path configures it, so treat it as unused. INFERRED
• m_TurnQuality* / TURN_QUALITY_* / TURN_CHANGEOVER_* / ROUTE_TCP_MS strings are keys of the post-match network statistics record. They are telemetry, not settings, but useful later to see whether a match used TURN. STATIC

CMD_SEND_TURN_ADDRESS_DATA → push CMD_WATCH_TURN_ADDRESS_DATA

• After its TURN allocation succeeds, each client sends {pid, address, address_data_size} (gate, svrtype MENU). The address blob is the serialized relayed address; its byte format isn't decoded, so treat it as opaque. A non-NOERR reply makes ConnectTurnTask fail. STATIC
• The server must push CMD_WATCH_TURN_ADDRESS_DATA {result:"NOERR", address, address_data_size} to the opponent with the bytes unchanged (msgpack str, like sa_data). The push has no pid field. The client then creates a permission and channel to that address. STATIC
• CMD_WATCH_PUNCHING_DATA {host_addr, reflexive_addr, ntl_nat_type} is used only by lobby/room flows, not Quick Match. STATIC

CMD_SEND_IPANDPORT_NTL and a likely cause of cross-home failures

• sa_data = 14 bytes: port (big-endian), 2 zero bytes, IPv4, 6 zero bytes. address_family 1 = IPv4, 0 = empty. ntl_nat_type is a packed descriptor (seen 1 before the test, 0x10307533 after a good test); its bits aren't decoded. LIVE
• reflexive_addr is whatever our STUN server sees. When the server runs in one player's home, that player's game reaches it over the LAN, so its "public" address is its LAN IP (logs: host == reflexive == 192.168.1.100). The friend in another home is then given an address it cannot reach. This alone can explain "Failed to connect with opponent" between homes, even when both routers would allow a direct path. LIVE INFERRED
• Cheap fix without TURN: when a LAN-side player is paired with an internet player, rewrite the LAN player's reflexive IP to the server's public IP and keep the port. This works on routers that preserve source ports. TURN is the robust fix.

CMD_GET_GAMERELAY and the "game relay"

• game_sycom selects the transport: "P2P" → mode 1, "SC" → mode 2 (server/client through Konami's game relay), anything else → 0. Only with "SC" are ip_addr/port kept; otherwise they're cleared. That is why the client's CHECK_RES shows an empty gamerelay. STATIC LIVE
• "SC" uses MultiplaySessionStrategyCsClient, a full client/server relay with Konami's own protocol (kps msp over dlcp, see transport layers). It is not a TURN-style fallback. Our UDP 7600 has never received a packet. LIVE
• GET_GAMERELAY_QUALITYCHECKLIST, SET_GAMERELAY_QUALITY, SET_GAMERELAY_MATCH_QUALITY and the LOCAL_GAMERELAY commands measure or select relays for SC mode and the lobby's "LocalGamerelayDialog". A bare NOERR is fine for all of them. STATIC
• CMD_SET_GAMERELAY_CHECK_RES {pid, game_sycom, error_code, gamerelay{…}, failed_reason, is_special_match_confirm} is each client's verdict on the connection. Push CMD_WATCH_GAMERELAY_CHECK_RES {error_code}: NOERR only if both sides reported NOERR, otherwise ER_MATCHING_RETRY, so both go back to searching. INFERRED

What our server should do

1. Superseded: our program now has its own relay (on by default), and live tests showed that a plain TURN server isn't enough. The relay must also send the SOFTWARE dual-route directive and serve a DTLS/UDP leg (live tests). The original advice was to run coturn on an internet-reachable address: tls-listening-port=5349; a non-zero but unused listening-port (3478 is our STUN); a self-signed cert whose IP SAN is the advertised address; lt-cred-mech; user=pes:<password>; realm=pes2021; external-ip; a UDP relay port range forwarded on the router. Behind a home router, coturn relaying between its own two allocations needs NAT hairpinning; a VPS avoids that. INFERRED
2. Reply only when TURN is configured: {result:"NOERR", turn_server_list:[{zone:1, address:"<public IP>", port:3479, tls_port:5349}], id:"pes", pw:"<password>", server_certificate:"<base64 DER>", server_certificate_data_size:<len>}. For time-limited credentials: id = "<expiry>:<pid>", pw = base64(HMAC-SHA1(secret, id)) with coturn use-auth-secret, and an expiry of hours (refreshes happen during a 90-minute match).
3. Forward SEND_TURN_ADDRESS_DATA to the opponent as a WATCH_TURN_ADDRESS_DATA push, and queue it if the room isn't ready.
4. Keep game_sycom:"P2P". The UDP 7600 placeholder can go.
5. Rewrite the host player's reflexive address when the opponent is remote (see above).

Tested live (2026-11-05): REQUESTED-TRANSPORT is UDP; the game asks for mobility; it needs a SOFTWARE directive HOST:PORT,<text>,0 and then a DTLS/UDP second leg before it publishes its address (details). 2026-11-06: with a DTLS leg that handles the ktc framing, the games publish their address (20-byte blob: 00, port big-endian, IPv4 little-endian) and relay ChannelData; the TLS leg is closed once the DTLS allocation exists; the whole session restarts every 21.4 s (open). Still unknown: whether the certificate is verified when none is sent, and whether a dead TURN server breaks the match. Our test showed the match running fine over P2P while TURN failed.

↑ Back to contents

Match flow: setup, in-match reports, end of match

The real sequence of a full match LIVE

WATCH_MATCHING (push) → GET_GAMERELAY (HTTP) → GET_MATCHID → SEND_SYNC_NOTICE "1,"/"2," → WATCH_SYNC_NOTICE
→ GET_SERVER_ENV → GET_TURN_SERVER_LIST (HTTP) → SEND_SYSTEM_NOTICE "START:pid=…;time=…;" (both) → push
→ SEND_SYSTEM_NOTICE "END:pid=…;time=…;" (both) → push → P2P link check (10–25 s)
→ SET_GAMERELAY_CHECK_RES → WATCH_GAMERELAY_CHECK_RES (push) → SEND_MATCHING_RESULT (both)
→ SET_GAMEMEMBER (owner) → CHANGE_GAMEPHASE DATASYNC → SET_GAMEMEMBERENV (owner) → GET_PLAYER_PARAMETERLIST
→ SET_GAMETEAM + GET_MATCHID → TEAMSELECT → MATCHMENU → GAMELOAD → SEND_MATCH_TEAM_INFO → ENTRY → 1ST …
  ADD_FOUL / ADD_SCORE … BREAK1 → 2ND … → SET_GAMEPLAYER_PLAYTIME → CHANGE_GAMEPHASE END
→ SET_PLAYDATA_MATCH (HTTP) → SEND_ABNORMALEND DISCONN_P2P (second to leave) → SEND_STATS_DATA
→ SEND_GAME_RESULT → REQ_GAMEADDPOINT → LEAVE_ROOM

The match session task (OnlineModeTaskMatchSession.cpp, on-screen MXNV_00NN)

Update fn 0x1411430b0, state at task+0x70, result at +0x74 (1 ok, 2 peer gone / revision timeout, 3 multiplay failure, 4 ping out of range, 5 server command error, 6 internal error). Every tick first checks the gate connection; if it's lost, the task fails with MXNV_0002 "DISCONNECT PES SERVER". STATIC

Peer notices relayed by the server

All three SEND commands carry {pid_list_num, pid_list[int], data STR}; the pushes carry {data}. The client never checks who sent a notice except through what's inside data. STATIC

• SYNC_NOTICE = match-session barrier. data = "<pid>," for each other member. The receiver pops one entry and ignores its contents. pid_list grows by one copy per match: the game never clears the vector it's built from ([2], [2,2] … [2,2,2,2,2,2] in our logs). If the server relays every copy, stale entries make the next match's barrier pass instantly. Harmless, but not real synchronisation. LIVE STATIC
• SYSTEM_NOTICE = P2P connect rendezvous (thread 0x1411d9620). data = "START:pid=<sender>;time=<unix s>;" or "END:…". Each handshake waits up to 30 s for a matching entry at the head of the queue, and the parser doesn't drop a non-matching head. One duplicate or stray notice therefore blocks the handshake and the P2P connect fails. Relay data byte for byte: each side builds the session tag "pid-pid-…-min(own time, peer time)" from time= and passes it to the NTL connect (0x1411d81d0), so altered times make the tags differ. STATIC
• NOTICE = JSON notices for rooms (not Quick Match): {"notice_key": …} with MOMROOM_START_COUNTDOWN {from_pid, reason, count_zero}, MOMROOM_RESULT_TIMEOUT, MOMROOM_REQ_RESULT_TIMEOUT {from_pid, roomid}, ROOM_SHARE_INFO {from_pid, has_team_data, team_power, chemistry, team_id, team_name}, SYNC_PROGRESS {pid_list}. Keys exist with no builder found: MOMROOM_CANCEL/REQUEST_COUNTDOWN, MOMROOM_SEND_XSESSION_INFO, MOMROOM_CONNECT_COMPLETE, QUICK_PING_RES. STATIC
• Server rule for all three: take set(pid_list) − {sender}, deliver each push exactly once per target, keep the order (START before END), never inject extra notices.

CMD_GET_MATCHID and CMD_GET_SERVER_ENV

• GET_MATCHID reply: match_id (any type, converted to a string) and upload. "YES" (what the server sends since 2026-11-07) makes the client stream its replay (CMD_SEND_GAME_SEQUENCE_DATA {pid, match_id, game_seq_data[{type, fromId, channelId, sequenceNumber, data, data_len}]}), which the server keeps as a replay (pesreplay.py). It's sent twice per match, so both times must return the same id for both players. LIVE
• GET_SERVER_ENV is copied into the game's environment every time; missing keys keep the client defaults. All timeouts are in seconds: STATIC

  Key	Default	Effect
  match_client_timeout_load_timeout	180	load-screen limit (× fps frames) → LOAD_TIMEOUT, QVHE1459
  match_client_timeout_long_outofplay	120	ball out of play too long → OUTPLAY_LONG
  match_client_timeout_init_not_end	240	match init not finished → LOAD_TIMEOUT (0 = instant abort, which we hit early on)
  match_client_timeout_cmd_lack	180	no peer commands → CMD_LACK
  trigger_keep_alive, matchrejectpid_max, quality_check_wait_sec (3600)		keep-alive switch, reject-list size, relay quality re-check
  is_revision_check "YES", is_check_myclub_level "YES", max_division "D12"		revision check switch; myClub; highest division
  teamlobby_game_rating_border_normal/hard (600/700), lobby_ping_good/normal, quick_ping_good/normal, log_update_level, konamiid_api_retry_sec, proto_opt		team lobby, ping bars, telemetry

  Our 180/120/240/180 are the client defaults. Raise long_outofplay / cmd_lack for more pause tolerance.

In-match reports (the "game queue")

• During the match, CHANGE_GAMEPHASE, ADD_FOUL, ADD_SCORE, SET_GAMEPLAYER_PLAYTIME, SEND_MATCH_TEAM_INFO, SEND_ABNORMALEND, SEND_ALIVE and others go through a queue (TaskGameQueueProcessor 0x141124df0). The only reply value it reacts to is result:"ERR_CHEAT", which makes the client end the match with reason CHEAT (FAMY242). Other errors just mark the entry failed. STATIC
• CHANGE_GAMEPHASE {phase, gtimer}: DATASYNC, TEAMSELECT, MATCHMENU, GAMELOAD, ENTRY, 1ST, 1ST_15MIN, 1ST_30MIN, BREAK1, 2ND, 2ND_15MIN, 2ND_30MIN, BREAK2, EX1ST, BREAK3, EX2ND, BREAK4, PK, END. Both clients report every phase. STATIC LIVE
• ADD_SCORE {goal_side, goal_gameplayer_id_info (blob), goal_player_side, goal_player_pid, assist_side, assist_gameplayer_id_info, assist_player_side, assist_player_pid, gtimer}. There is no CMD_ADD_GOAL in the game: our events.py waits for ADD_GOAL, so live scores never update. Both clients send each goal; dedupe by (room, gtimer). An own goal is probably goal_side ≠ goal_player_side. LIVE STATIC
• ADD_FOUL {card_pid, card_side, card_gameplayer_id_info, card_kind, injury_pid, injury_side, injury_gameplayer_id, injury_data {part, symptom, level, mcount_left}, injury_all, injury_one, gtimer}. LIVE
• SET_GAMEPLAYER_PLAYTIME: both teams' players with minutes played and final position, sent just before END. SET_GAMETEAM {home_team_id, away_team_id} at team select; 262143 = no team. LIVE
• SET_GAMEMEMBER / SET_GAMEMEMBERENV are sent only by the room owner: envlist[blob{pid, side HOME/AWAY, sideLeader YES/NO}], the authoritative sides. Unlike the queue, these replies are checked: an error aborts match setup. STATIC
• SEND_MATCHING_RESULT (both, after the session): member / vs_member blobs with each side's NTL addresses, and error_code ("" = connected, otherwise e.g. MXNV_0013). It's the best per-match record of whether connection setup worked. The reply isn't checked. LIVE
• LEAVE_ROOM {error_code}: "" after a normal match, otherwise the last on-screen code. LIVE

Abnormal ends and the match watchdog

CMD_SEND_ABNORMALEND {reason, error_code}. error_code = <last on-screen code>_0x<8 hex>. Reasons (enum 0x1437f3d20): STATIC

0 CHEAT · 1 INJURY · 2 GIVEUP · 3 EXIT · 4 SLOWDOWN · 5 NO_OPERATION · 6 COMPE_TIMELIMIT · 7 CMD_ERR · 8 MODE_ERR · 9 SYNC_FAILED · 10 CONFLICT · 11 LOAD_TIMEOUT · 12 GAMERELAY · 13 BUFFER_OVER · 14 DEGRADE_SC · 15 DISCONN_SC · 16 CMD_SENDFAILED · 17 OUTPLAY_LONG · 18 CMD_LACK · 19 TIME_ERR · 20 NOTRUN · 21 READY_TIMEOUT · 22 DISCONN_NTL · 23 DISCONN_P2P · 24 DEGRADE_P2P · 25 NOERR

• The per-match watchdog (MatchOnline.cpp 0x14213dab0) uses the GET_SERVER_ENV limits plus fixed ones: DISCONN_P2P (10 s / 300 s / 30 s depending on state), NOTRUN (60/90 s), SYNC_FAILED (180 s), BUFFER_OVER, NO_OPERATION (the AFK rule: (setting+30)×2 s or (setting+60)×1 s without input; about 70 s in our live test). STATIC
• Seen in our logs: DISCONN_P2P/GNCX_0003 (always the second player leaving after the match), NO_OPERATION/VIXT2253, LOAD_TIMEOUT/QVHE1459 and /MMGC_0002_0_262143, GAMERELAY/EYRH1530, DEGRADE_SC/EYRH1530. LIVE
• Server: store {room, pid, reason, error_code, phase}. Ignore DISCONN_P2P that arrives after both sent END. Mid-match, the reporter usually stayed and the other player left.

Liveness probe and reconnect

• CMD_WATCH_CHECK_ALIVE_PLAYER is a server push ("are you still there?"). The client answers with SEND_ALIVE {pid, reason} (NOERR, DISCONN_SC = P2P link down, DEGRADE_SC = server path degraded) and SEND_ALIVEPLAYER {pid, pid_list} listing the peers it still hears. We never push it. It could decide who disconnected. Optional. STATIC
• CMD_RECONNECT {pid, platform, patch_version, dlc_version, online_mode} is sent after a gate connection drop. It expects {key, key_size} like SET_CURRENTPLAYER. Today it gets a bare NOERR with no key, so a reconnect probably fails. It should be handled like SET_CURRENTPLAYER (new 16-byte key, rebind to the existing session and room). STATIC Needs a live test.

Server error table inside the client

The game carries a 765-row table (0x1428a1170) of (command, ERR_* code the server may return, message id). That's the list of error replies Konami's server could send per command, e.g. ERR_ROOMNOTFOUND, ERR_NOTROOMOWNER, ERR_PLAYERISNOTENOUGH, ERR_DATABASE. Every room or lobby handler should pick its errors from it. STATIC

↑ Back to contents

After the match: results, statistics, rating, divisions

CHANGE_GAMEPHASE END (both) → highlights / full-time screens
TaskWatchGame (OnlineModeTaskWatchGame.cpp, 0x141120730) runs through the match:
   watches push CMD_WATCH_GAMEADDPOINT + push CMD_WATCH_CHECK_ALIVE_PLAYER
   on a dropped peer link: wait for the verdict → REQ_GAMEADDPOINT at +10 s → give up at +20 s
OnlineMatchEnd (0x14137e390): SET_PLAYDATA_MATCH (HTTP) → SEND_STATS_DATA → SEND_GAME_RESULT → LEAVE_ROOM
OnlineMatchRatingPre (0x141379220): "normal" → rating screen (menu::RatingChange)   |  "skip"
Online Divisions only (gamemode 24): GET_DIVISION_INFO → division-points screen

The verdict: CMD_REQ_GAMEADDPOINT / push CMD_WATCH_GAMEADDPOINT

• Now (2026-11-07): the server pushes the verdict to both players when both reported CHANGE_GAMEPHASE END, in every one-on-one match. Both games then end cleanly (no "match abandoned" dialog) LIVE. A match left early has no verdict (anything but NORMAL_END shows OLXH186); the server instead counts it as a 3-0 loss for the one player who left early (own GIVEUP/EXIT/NO_OPERATION report or a dropped connection) and a win for the other, in ratings, Online Divisions and Matchday LIVE.
• Before: the client whose P2P link closed first waits for the push, sends REQ_GAMEADDPOINT after 10 s, and gives up after 20 s. Logs: ABNORMALEND 16:23:39 → REQ 16:23:49 → GAME_RESULT 16:24:01; also 20:06:53 → 20:07:04 → 20:07:14. Nothing breaks, but there's a 20 s stall and no rating screen. LIVE STATIC
• Push layout (parser 0x141d7f540, handler 0x141100010). Nested objects are msgpack blobs. STATIC

  { result:"NOERR", player_count: NUM,
    player_list: [ blob{ pid, pes_pname: blob{name, xuid_one, psn_user_id: blob{account_id, online_id,
                   is_valid_cache}, is_deleted},
        rating_type  RANKMATCH | LEAGUE_A | LEAGUE_A_COACH | LEAGUE_B | … | LEAGUE_PREMIERE(_COACH)
        rating (new), oldrating, rating_compe, rating_boost_type NONE | ROOKIE | CONTWIN, rating_boost_rate,
        team_id, side HOME|AWAY, contWin_num (win streak),
        skill_rank SKILL_RANK_12 … SKILL_RANK_1, is_rankup_skill_rank YES|NO, is_first_skillrank YES|NO } ],
    winner_side WINNER_HOME | WINNER_AWAY | WINNER_NONE,
    gameend_reason NORMAL_END | DISCONN | OWNGOAL | CHEAT | INJURY | GIVEUP | … | DISCONN_P2P | DEGRADE_P2P,
    is_pk YES|NO }

• The entry whose pid equals the player's own pid is "me". gameend_reason must be NORMAL_END (or INJURY). Anything else, or a missing value, shows OLXH186. The rating screen shows oldrating → rating (gain = rating − rating_compe when rating > rating_compe), the boost and the win streak. STATIC
• Server should: keep a rating per player (e.g. Elo from 1000) and a win streak. Answer REQ_GAMEADDPOINT with NOERR and push the verdict immediately. Also try pushing it to both players once both sent CHANGE_GAMEPHASE END. Quick Match never shows the rating screen: it only runs for mode groups 13, 19, 28 and 29 (bit mask 0x30082000 at 0x141379270, static table 0x1434fc9c0), and Quick Match (gamemode 25) is group 14. The push still matters: it ends the 20 s wait. Send rating_compe 0 (gain shown = rating − rating_compe). STATIC

What each game reports

• CMD_SEND_GAME_RESULT (one per client; reply never checked): pid, side, game_phase, home_score, away_score, home_team_id, away_team_id, is_cheat, error_code, abnormalend_reason, and gameend_reason, which is always "NotImplement": the client leaves the outcome to the server. Also network diagnostics: communication_time, link_type, rtt_*, transport_rtt_*, rx_packet_loss_rate_*, match_time, match_hz_*, per-controller cursor_data_list (input delay), network-quality flags, server ping samples. Unset values are all-ones (4294967295/65535/255) or "NotImplement". LIVE STATIC
  Both reports: without a verdict at full time, the second game reports END/DISCONN_P2P when the first leaves the result screens. Since the server pushes the verdict at END in every one-on-one match, both report END/NOERR with gameend_reason "NORMAL_END" LIVE (2026-11-07).
• CMD_SEND_STATS_DATA: pid, match_id, stats[2 blobs {side, inframe_shoot_num (shots on target), freekick_num, cornerkick_num, tackle_success_num, save_num, pass_success_num, cut_num (interceptions), possesion}]. LIVE
• CMD_SEND_MATCH_TEAM_INFO (about 20 s before kick-off): per team pid, team_spirit, cpu_level, chemistry[11], player_role_list, starting_order[23 × {gameplayer_id_info, level, condition (form arrow 0–4), stamina}]. LIVE
• CMD_SET_PLAYDATA_MATCH (HTTP PLAYDATA_MATCH, form field play_data = JSON). The best stats source. gamemode (25 = Quick Match, 24 = Online Divisions), stadium_id, weather, match_time (match-length setting), main_pad_side, opponent_pid, scorer [player ids], win_lose (2 = draw), and for both teams team_id, team_power, uniform, member[29 × {player_id, play_time, rating (5.0–7.0), player_overall, strength}]. LIVE
• CMD_SEND_DOWNLOAD_STATS_DATA is download telemetry (file, hash, time, bps), not a match result. STATIC

Divisions and rankings (Online Divisions mode)

• Divisions belong to Online Divisions (gamemode 24, matching type OC_RANK), not Quick Match (25). LIVE STATIC
• How a season works (modes2.md, live 2026-11-06): the game has no season calendar. other_match_num is the number of matches left (10 per season, the history holds ten), and the current points are the sum of match_history_list[].division_point, not a field. When other_match_num is 0 the game shows its season-end screens and sends CMD_FINISH_SEASON; the server then moves the player up or down. A bare reply therefore runs the season end on every visit. max_division in GET_SERVER_ENV sets the bottom division. The search is Quick Match with matching_type "OC_RANK" plus GET_OFTEN_USED_TEAM_LIST, and the found opponent is shown on a "View Opponent" screen (Find Another / Proceed). LIVE
• CMD_GET_DIVISION_INFO {pid, is_season_end} is called on entering the mode, at season end (with CMD_FINISH_SEASON) and after every division match, before the division-points screen. Reply: pname blob and division_info blob {division, promotion_point, demotion_point, doublerank_promotion_point, other_match_num, match_record {win_count, draw_count, lose_count, win_s_max, rating}, match_history_list [{division_point, enemy_team_id, home_score, away_score, enemy_side, enemy_name, is_finished_match, win_lose, enemy_cpu_level}]}. The server sets the thresholds; the client has no threshold table. Icons go from division_12 (lowest) to division_1. STATIC
• CMD_GET_DIVISION_POINT_INFO → server_num, division_list[{division_type, point, rank}] (division records screen).
• GET_DIVISION_RANKING(_BYID) and GET_RANKING(_BYID) are HTTP (DIVISION_RANK, RANK, …). Form: start_index, view_num, division or sort, order; BYID uses the requester's ids. Reply: date, total_rank_num, rank_list[{user {pid, pname, division, favoriteTeam, favoritePlayer, intro, manner, match_record}, rank, point}]. In these HTTP replies nested maps are inline, not blobs. STATIC
• CMD_GET_GAMERESULTS (match history): rlist[blob{date, ex_type, pk_flag, no_match, player[…], team, score[{score_1st, score_2nd, score_ex1st, score_ex2nd, score_pk}], match_category, gameend_reason}].
• GET_HEROSTATS (career totals) has no caller in 1.01. GET_MATCH_ANALYZE_ENV (play-style screen thresholds), GET_PLAYER_PARAMETERLIST (server-side player abilities for myClub cards) and GET_GP_ACHIEVEMENT (wallet and achievement bits) are login or pre-match queries; a bare NOERR works. STATIC LIVE

Built and checked in the game (2026-11-07) LIVE

• Season end: the game decides promotion / stay / relegation itself from the season's points and the thresholds of the reply before FINISH_SEASON (FINISH_SEASON comes before the is_season_end "YES" request). Rules: ≥ double-promotion points → up 2, ≥ promotion → up 1, < demotion → down 1; the server applies the same. match_record is this season's record (Season Results screen).
• A full Online Divisions match: SEND_MATCH_ANALYZE from both before END, the verdict at END, "Changes in rating" screen, then the season chart with the new result.
• Profile pages (GET_PLAYERINFO): favoriteTeam, favoritePlayer, intro at the top level; manner must be a blob {manner C..AAA, disconnect_rate LOW_RATE | SEMI_HIGH_RATE | HIGH_RATE} (a string crashes the game); rankmatch_stats a blob (division, rating, match/win/draw/lose numbers, streaks, goals); rankmatch_teamLog a plain list of team ids ("Teams Chosen in Last 5 Matches"); matchday_stats_single a blob.
• Play Analysis (GET_MATCH_ANALYZE): analyze_data_list must be a list of blobs (inline maps crashed the game); the server returns what the games uploaded.
• Rankings (HTTP, inline maps): overall (Online Stats → Overall Ranked Match Rankings) and per division. In rank_list[].user, manner is a plain string.
• Match history (GET_GAMERESULTS): Online Stats → Last 20 results; match_category from the game's 25-name enum (RANK_MATCH = "Online Divisions", MATCHDAY = "Matchday"; no name gives a Quick Match label). "Participating Users" → "Add to Match Block List" is the only way to block (needs matchrejectpid_max > 0 in GET_SERVER_ENV).
• Frequently Selected Teams (GET_OFTEN_USED_TEAM_LIST): a plain int list.
• Matchday: a full match adds points per side; the points screen breakdown (gameplay_quality, squad_rating) is in tenths; Side Ranking entries are blob{pname: blob{pid, pname: blob{…}}, team_id, rank, matchday_point}.
• Online Co-op (2026-11-08): co-op needs the full-time push WATCH_GAMEADDPOINT too (without it both games report the link lost ~36 s after full time); the server sends it without changing 1v1 ratings. "Changes in CO-OP Level" reads GET_COOP_LEVEL_RESULT: evalution = Points earned, reference = To level-up, point = Rating +N; the server gives 30/20/10 points for a win/draw/loss and a level every 100.
• Online Tournament (2026-11-08): PES League rankings are blobs {pid, entry_name, team_id, clan_owner_name: blob{name, …}, point, rank, win/draw/lose_count, match_num, get_score, lose_score, diff_score, continuous_win, is_mydata, …} plus a top-level update_date; "Current Match Results" is GET_GAMERESULTS game_res_type "PESLEAGUE" with pesleague_compe_id (category PESLEAGUE_MATCH = "eFootball League"); the end-of-competition notice is GET_PESLEAGUE_COMPE_RESULT_LIST is_unconfirm_list "YES", reached when MAINMENU_INFO says new_result "YES".

Suggested storage

Tables for: match (ids, teams, final score, winner, end reason, status final/disputed/aborted, play_data JSON); match_report (both clients' GAME_RESULT); match_team_stats (STATS_DATA); match_player (line-up, minutes, rating, goals); player_rating (rating, W/D/L, streak); rating_change (source for the verdict push); division_state, division_rule (promotion/demotion thresholds), division_history. Rankings are just ordered queries over these.

Value sets STATIC: division = "D1" (top) … "D12", or "NONE" (GET_SERVER_ENV max_division "D12"). Ranking sort = RATING, WIN_NUM, MATCH_NUM, WIN_STRAIGHT, WIN_RATE (or absent), order always "ASC", view_num 100. GET_GAMERESULTS request = pid, game_res_type (ALL/RANK/MYCLUB/COOP_ALL/PESLEAGUE/COOP_PESLEAGUE), pesleague_compe_id. gtimer ≈ 50 ticks per real second (950 at kick-off, ~94,000 for a full match); use it only for de-duplication.

Still unknown: whether a verdict push to the client that isn't waiting is used; the units of the STATS counters (all 0 in our 0–0 test matches).

↑ Back to contents

Lobbies and rooms: playing a chosen friend

Where it is: Kick Off → Friendly Match Lobby, the 8th item of a scrolling list just below "Cup" (then Team Play Lobby, then Training). The menu is a hard-coded table in the exe (built by 0x1401c7fb0) with no server or platform filter. Live, with test handlers following this spec, the game reached the Match Room List and created a room. It then quit about 2 s after the room player list, before ENTRY_GAME; the cause is being investigated (live tests).

Two lobby products STATIC

• Free lobby (menu freelobby, game mode LOBBY1VS1, task TaskLobbyRoomMainFree): 1 vs 1 rooms. max_players = 2 is hard-coded (0x1410e86bb). This is the one we need.
• Multi / MOM lobby (multilobby, MOMLOBBY): several humans per side, 11-a-side room screen, countdown notices, best player, position rating. It shares about 90 % of the protocol.
• Hierarchy: menu "Server" = lobby (GET_LOBBYLIST/JOIN_LOBBY) → menu "Lobby" = block (GET_BLOCKLIST/JOIN_BLOCK, a sub-area with its own room list and player cap) → room.

Three kinds of commands

1. Plain request/reply (CREATEJOIN_ROOM, ENTRY_GAME, …).
2. WATCH_* = pure server pushes. The client registers a local watch and never sends a request (no RX of any WATCH_* in our logs). Push with kind 0x60, rqid 0. LIVE STATIC
3. REQWATCHL_* = request + list subscription. The request carries arguments (room_id) and is answered; later pushes with the same msgid update the list. Safe behaviour: answer and also push. INFERRED (strong)

The list protocol for all REQWATCHL_* STATIC

Merger 0x1411c1340. Every list reply or push has list_key_name, list_type and list_data (an array of msgpack blobs):

• RELOAD clears the cached map and inserts every element, but only safely when the cache is empty: its clearing loop throws (uncaught, the game exits) once the cache holds entries, so a server may send RELOAD only as the reply to a new request (confirmed live 2026-11-06). ADD/UPDATE (re)insert; DEL removes. An empty or missing list_data changes nothing, even with RELOAD, so to clear a list you DEL each element.
• The key is the field named by list_key_name inside each element (room_id for room lists, pid for player lists). It must be a msgpack int; a string or double key becomes 0 and the elements collide.

Flow: owner A creates, friend B joins (confirmed live 2026-11-06)

both: JOIN_ONLINE_MODE FREE → GET_LOBBYLIST → JOIN_LOBBY → GET_LOBBYINFO → GET_BLOCKLIST → JOIN_BLOCK
      → REQWATCHL_ROOMLIST (request; reply RELOAD = the block's rooms, the only safe RELOAD)
A:    CHECK_STRING {room name} → CREATEJOIN_ROOM {name, match_type OC_FREE, lang, max_players 2, …} → {room_id}
      server → subscribers incl. A: room list ADD (A looks for its own pid in the room list)
A:    SET_GAMEENV {game_env: blob of the 9 settings} → server stores it, echoes it as the room's gameenv,
      pushes room list UPDATE (limitTime NOSET would hide the room from everyone)
A:    REQWATCHL_ROOMPLAYERLIST_NTL {room_id} → reply = the player list (no push before A's ENTRY_GAME)
      then ENTRY_GAME {entry FALSE, side HOME} → room screen
B:    (row selected) REQWATCHL_ROOMPLAYERLIST_NTL {room_id} → reply → "Match Room Details" screen
B:    JOIN_ROOM_NTL {room_id, is_invited NO, password} → {room_owner blob (pid, pname, NTL addresses), room_stat}
      ERR_PASSWDINCORRECT → password prompt · ERR_ROOMNOTFOUND → "no room" dialog
      server → room list UPDATE; player-list UPDATE to A
B:    REQWATCHL_ROOMPLAYERLIST_NTL {room_id} → reply, then ENTRY_GAME {entry FALSE, side AWAY}
A:    SEND_NOTICE ROOM_SHARE_INFO {team id/name/power, chemistry} to both; SET_GAMEMEMBER (nobody entered: ignore)
room: "Start Match" = ENTRY_GAME {entry TRUE, side}
      server → room: WATCH_ENTRY_GAME {entry_count, entrygame[blob{pid, entryNum, gameNum}]} + player-list UPDATE
      owner, when all entered → SET_GAMEMEMBER (empty body)
      server → room: WATCH_DECIDE_GAMEENV {game_env}, WATCH_ROOMSTATE {event StateChanged, state SETENV}
match: GET_MATCHID, SEND_SYNC_NOTICE, GET_SERVER_ENV, P2P START/END, DATASYNC, SET_GAMEMEMBERENV, TEAMSELECT …
after: SET_PLAYDATA_MATCH (HTTP), SEND_STATS_DATA, SEND_GAME_RESULT, REQWATCHL_ROOMLIST, LEAVE_GAME {pid}
      server, when all left → WATCH_ROOMSTATE StateChanged WAITING (both back in the room, rematch possible)
never: a RELOAD push into a game that already holds list entries (uncaught C++ exception, the game exits)

Command reference (Free lobby)

• Follow list (FOLLOW_USER, GET_FOLLOW_LIST → follow_list[blob{user_id{pid, pname}, is_locked, is_clan_member}], LOCK_FOLLOW_USER) lives with the co-op code: CO-OP Settings → Follow List, and after a co-op match the screen that offers to follow your human team-mates. No path leads from a followed player into a Free room. DONE The server stores each player's follow list; the co-op card's follow flag and follower count come from it (unit-tested, not tried in the game yet).
• Mode names STATIC: lobby_type = FREE, MULTI, MYCLUB, PESLEAGUE; JOIN_ONLINE_MODE online_mode = QUICK, RANKMATCH, FREE, MULTI, MYCLUB, PESLEAGUE, MATCHDAY, COOP, EDIT_DATA_LIVE_UPDATE. SET_GAMEENV game_env is a packed blob holding the 9-key settings map. Co-op room_phase uses the game-phase names (DATASYNC…END).
• SET_MATCHREJECTPID / GET_MATCHREJECTLIST (a player's block list for matchmaking): bare or empty is fine.

What our server can reuse

The NTL address store, _pname, _send_later, the notice relay, GET_GAMERELAY, SET_GAMERELAY_CHECK_RES, GET_MATCHID and the events code all work as they are, if at match start the server inserts the usual st["rooms"][id] = {owner, members, t}. Only the lobby / block / room-list layer is new (a pesrooms.py). The full per-handler spec is in notes/re/functions/rooms.md.

Still unknown (two-client test): whether REQWATCHL requests really go on the wire; the order of SET_GAMEENV vs CREATEJOIN_ROOM; the commands between SETENV and GAMELOAD (the menu flow is data-driven); whether a Free-lobby client also sends LEAVE_ROOM after a match; whether chat should echo to the sender.

↑ Back to contents

Co-op (2v2, 3v3) and spectating

Live (2026-11-06): what this section predicted from the code was only partly right. In 1.01.00 co-op never connects: it builds its peer list but never hands it to the P2P layer, and that layer takes exactly one peer. With mod 0.5.0 (two hooks that add the missing step) and pescoop.py, an Online Co-op Casual Match with one human per side (CPU teammates) connects and kicks off. Matches with two or three humans on a side can't run. The server must echo each player's own SYNC_PROGRESS notice, answer GET_GAMERELAY with "P2P" and give each side a real team. Details: coop2.md, livetests.md. LIVE

How co-op works STATIC

[menu]   GET_COOP_MAINMENU_INFO, GET/SET_COOP_QUICKMATCHOPTION, GET_COOP_PROFILE, GET_IS_JOIN_COOP_ROOM, reject lists
[party]  optional co-op room (CREATEJOIN/JOIN/LEAVE_COOP_ROOM, REQWATCHL_COOP_ROOM_MEMBER, …)
TaskCoopMatchingManager (0x141079280):
  1  every human: START_COOP_GROUP_MATCHING → push WATCH_COOP_GROUP_MATCHING FINISH   ("your side is formed")
  4  vs-COM: START_COOP_VSCOM_OPPONENT → push WATCH_COOP_VSCOM_OPPONENT (CPU squad)
  6  group owner only: START_COOP_MATCHING → push WATCH_COOP_MATCHING FINISH to all  ("opponent side found")
  9  TaskCoopSession: GET_GAMERELAY → the same 1v1 TaskMatchSession (match id, notices, TURN, P2P)
     → SET_GAMERELAY_CHECK_RES → WATCH_GAMERELAY_CHECK_RES → SEND_MATCHING_RESULT
 11  TaskCoopStartGame: SET_GAMEMEMBER → SET_GAMEMEMBERENV → team sync → SET_GAMETEAM → GET_MATCHID (must be non-empty)
     → GET_COOP_MATCH_DATA → match as in 1v1
after:   SEND_GAME_RESULT … + SET_COOP_MATCH_DATA, SET_COOP_PLAYER_GRADE, GET_COOP_LEVEL_RESULT, RETURN/LEAVE_COOP_ROOM

• The co-op session creates the 1v1 TaskMatchSession (0x141133d5d) with the members of both sides. The link is P2pFullMeshSession: 2v2 = 4 peers (6 links), 3v3 = 6 peers (15 links). A group (one side's humans) is capped at 3 (0x14111072f); nothing forbids a group of 1.
• matching_state enum: CHECKALIVE, SEARCHING, FOUND, FINISH, CANCEL, TIMEOUT, FAILED. Only FINISH moves the client on; CANCEL/TIMEOUT/FAILED fail the step and the manager retries.
• Pushes are sent exactly like WATCH_MATCHING (kind 0x60, rqid 0). Every WATCH/REQWATCH handler is slot 27 of its CommandObject vtable.

The matching commands

• START_COOP_GROUP_MATCHING (every human) {pid, matching_type, is_good_reputation, com_level_min, com_level_max, retry_num}. matching_type ∈ ONLINE_COOP, MYCLUB_COOP, ONLINE_VSCOM_COOP, MYCLUB_VSCOM_COOP, MATCHDAY; com levels VERYEASY…LEGEND. CANCEL_COOP_GROUP_MATCHING {pid} dequeues.
• Push WATCH_COOP_GROUP_MATCHING {matching_state:"FINISH", member_list:[blob{member: blob{the 1v1 WATCH_MATCHING member: pid, pname, is_owner, matching_order, host/reflexive/relayed_addr, ntl_nat_type, side, …}, guest_kind GUEST_NONE|GUEST|PLATFORM_GUEST, is_follow, coop_level, coop_manner C|B|A|AA|AAA}], member_list_num, com_level_min, com_level_max}. Exactly one member per group has is_owner:"YES"; that player becomes the group owner.
• START_COOP_MATCHING is sent only by the group owner (my pid == owner, 0x141133717): {matching_type, coop_player_info_list[{pid, is_good_reputation, guest_kind, user_id}], owner_pid, use_team_id, retry_num}. CANCEL_COOP_MATCHING {pid}.
• Push WATCH_COOP_MATCHING to all 4–6 players: {matching_state:"FINISH", group_list:[2 × blob{member_list[…], member_list_num, use_team_id, owner_pid, group_id}], group_list_num:2}. The client finds its own group and reads its member's side, so one group must be all HOME and the other all AWAY. Send a single is_owner:"YES" in the whole push, the HOME owner, which takes the 1v1 host role. INFERRED matching_state:"CHECKALIVE" makes the client answer SEND_COOP_ALIVE {pid, group_id} (optional).
• vs-COM co-op: push WATCH_COOP_VSCOM_OPPONENT {my_team{…team_data{squad member_list[{gameplayer_unique_id, gameplayer_id, uniform_number, player_level, parameters, default_rarity}], gameplan_data, …}}, com_team{side, com_level, …}, owner_pid}: a whole squad, the hard part.
• Server: after WATCH_COOP_MATCHING, register one room holding all pids. GET_MATCHID, the relay check and the notice relay then work unchanged, because they already key on the room members.

Menus, post-match and party rooms

Party rooms: CREATEJOIN_COOP_ROOM {basic_settings{room_name, password, is_com_match, coop_level, coop_manner, …}, match_settings{user_team_id, enemy_team_id, cpu_level}, kind}, GET_COOP_ROOMLIST, JOIN/LEAVE/RETURN_COOP_ROOM, GET/SET_COOP_ROOM_OPTION + push WATCH_COOP_ROOM_OPTION {…, room_phase, countdown…}, member list REQWATCHL_COOP_ROOM_MEMBER (same list protocol, key player_index), SET_COOP_MATCH_READY, SET_COOP_ROOM_GUEST, SET_COOP_ROOM_TO_MATCHING {to_match_pid_list} → push WATCH_COOP_ROOM_TO_MATCHING_MEMBER {player_index_list}, REQWATCH_ERROR_COOP_ROOM_TO_MATCHING {is_error, error_kind NOERR|NOT_ENOUGH_PLAYER|INCLUDES_RENTAL|RED_CARD|CONTRACT}, push WATCH_BREAKUP_COOP_ROOM when the owner leaves. The room's members then send START_COOP_GROUP_MATCHING, and the server must put them in one group. STATIC INFERRED

Effort

• Quick co-op (solo players, no rooms, no vs-COM): about 1.5–2 days. A first test can use 2 clients with each player in their own group ("1v1 co-op").
• Party rooms: about 2–3 more days. vs-COM, myClub and Matchday co-op: 3+ days (squad synthesis).
• Main risk: whether all 6–15 player-to-player links come up. TURN helps here.

Spectating

PLAYERS                                      SERVER                               VIEWER
GET_MATCHID → {match_id, upload:"YES"}       decides which matches are recorded
START_SEND_GAME_SEQUENCE_DATA {pid}          opens a recording for the match
every ≤5 s / 16 KB: SEND_GAME_SEQUENCE_DATA  stores the records
  {match_id, game_seq_data[blob{type, fromId,   re-encodes, chunks, [zlib], AES-256-CBC
   channelId, sequenceNumber, data, data_len}]}                       GET <WATCHING_GAME url>/<id>/1.enc, 2.enc …
                                                                   ◄── GET_WATCHING_MATCH_LIST
                                                                   ◄── SEND_WATCHING_RESULT (at the end)

• The server turns recording on with upload:"YES" in GET_MATCHID (0x140ff7cd0). Since 2026-11-07 the server sends "YES" and records every match (pesreplay.py). An error reply to START_SEND_GAME_SEQUENCE_DATA aborts the match (MXNV264). STATIC
• The recorder taps the session layer of P2pFullMeshSession / CsClientSession (hook 0x1412561c0). The first record is a header with the revision triple, build string and match id. data is probably base64. STATIC INFERRED
• The viewer only uses HTTP and never talks to the players. It fetches <WATCHING_GAME url>/<id>/<N>.enc (N = 1, 2, …). Each chunk is a 16-byte IV + AES-256-CBC with a key built into the game (0x142897bd0: 35a11067 5829e368 45dc7751 62cca1bb 69b786ed 1e73d82e a9fe7e61 76743881). Plaintext = [flag][body], flag 1 = zlib. The last chunk ends with END_OF_DATA. A chunk that isn't ready yet must return 404; the viewer retries for 30 s on chunk 1 and 330 s later (DZWO960). Stream items: 0 header (revision must match the viewer's), 1 member list, 2 [2][fromId][channelId][seq BE32][len BE16][data], 3 end. STATIC
• GET_WATCHING_MATCH_LIST {match_category, compe_id, index} → match_list[blob{match_id, game_phase, game_result{…}}]; SEND_WATCHING_RESULT {match_id, is_connect, phase, error_code, reason} → NOERR.
• Tested live (2026-11-06), it works with server replies only: both players upload once upload:"YES" is sent (keep one stream; each record's data is base64 of 256 bytes, keep data_len; each record is already a viewer item, no re-encoding). The viewer gets there through eFootball → Online Tournament → a competition → team → PES League lobby → X "Match List" → Spectate Match: GET_PESLEAGUE_COMPE_INFO must carry match_type "PES_LEAGUE_MATCH_1VS1_LOBBY" inside a compe_data blob, otherwise the 1v1 menu opens. In GET_WATCHING_MATCH_LIST, team and score sit at the game_result level, two each. The viewer then downloads /<match_id>/1.enc, 2.enc … every 0.2 s and replays the recorded match from storage, so two copies are enough (live watching needs a third). Test add-on: notes/re/functions/tools/testserver/spectest.py; recipe: spectate2.md. LIVE
• Built into the server (2026-11-07) LIVE: every online match is recorded; the newest 20 are listed in a "Match Replays" PES League competition (Online Tournament → Match Replays → any team → lobby → X Match List, the keyboard's a key) and served at /r/<match_id>/<N>.enc. A whole 90-minute replay played to the full-time result screen. A full unattended match is about 200 chunks / 800 KB; a played one about 450 chunks.
• Effort: about 1.5–2 days plus a 3-client test (2 players, 1 viewer). Error tags: DZWO (HttpStreamWatchingData), PWTV (ObserveSession), OBMB (PES League watching), NNAB (observer menu), JCND (MatchOnlineObserverForPesServer).

Still unknown: how Konami grouped solo players; which is_owner the session host needs when both groups have owners; whether 6-peer full mesh connects through our setup; the contents of match_data; room_phase values; the minimum vs-COM squad push. (The spectating URL id is the listed match_id, and data is base64: both settled live.)

↑ Back to contents

Fair play, news and the online menus

Order at online login LIVE

SEND_LOG, GET_GAME_TEAM_LIST, GET_MATCH_ANALYZE_ENV, GET_MANNER_WARN, GET_DMM_NOTIFICATION, GET_PRIVATEINFOTITLELIST, GET_DMM_PLAYERINFO, SEND_LOG, JOIN_ONLINE_MODE, CHECK_CHEAT, GET_URGENT_ANNOUNCEMENT (PRE_MAIN), GET_MANNER_WARN, GET_PRIVATEINFOTITLELIST, GET_QUICKMATCHOPTION, (GET_MAINTENANCE_INFO), START_MATCHING. Login errors here carry the tag CCWR (OnlineLoginTaskConnectMenu2.cpp).

CMD_CHECK_CHEAT: checksums of the player database

• Request: pid, dlc_version, dlc_type ("NotImplement"), param_check_sum, entry_check_sum. Sent after JOIN_ONLINE_MODE. LIVE
• param_check_sum (0x141128e90) is not MD5. For every player in the database: low 16 bits of the id + the 108 parameters + height + weight + the weekly condition (a constant 5 unless live data is applied), added into four u32 accumulators (by id & 3). Reproduced exactly from the game files, see the database. The accumulators are XOR'd with {29bda03d, 0593fbe2, 298015ab, 9fbead21} and printed as 32 uppercase hex characters. STATIC
• entry_check_sum (0x141129240): the same idea over the team rosters (team id + each player's id + shirt number), with no XOR. STATIC
• What changes them: stat edits, transfers, roster or number changes, live-update data. What doesn't: names, kits, faces, emblems, stadiums and other cosmetic option-file content. STATIC INFERRED All 48 logged requests (both players) had the same two values. LIVE
• Reply: only result is read. ERR_PARAMCHECK_FAILED aborts online login (CCWR_0014); any other error also aborts (CCWR_0015). There's no "warn and continue". STATIC
• Where the sums are really enforced: in the P2P revision check after connecting, the peers exchange revision, param_check_sum, entry_check_sum. A mismatch ends the match with "DATAPACK error" (MXNV533). Only param_check_sum, then entry_check_sum are compared, as exact strings; revision is never compared, and DLC/live-data/patch versions are not in the exchange. The switch is GET_SERVER_ENV.is_revision_check: exactly "YES" (or absent) compares, anything else skips the compare (the 60 s exchange still runs) (notes/re/functions/datacheck.md). STATIC
• Server should: store both sums (and the versions from JOIN_ONLINE_MODE) per session and only pair players whose sums match. Optional strict mode: whitelist the accepted sums and reply ERR_PARAMCHECK_FAILED to the rest.

CMD_JOIN_ONLINE_MODE: a natural version gate

Request online_mode (QUICK…), patch_version "1.01.00", dlc_version, livedata_version, extradata_version. Replying ERR_MODE_BLOCKED blocks entry with its own message (CCWR_0003), which is a clearer failure than a DATAPACK error after connecting. Other errors (including ERR_DIFFERENT_PATCHVERSION / LIVEDATA / DCVERSION) end in the generic login error CCWR216, possibly after the command's own text. STATIC LIVE

CMD_SEND_TAMPER_DATA: the game reports its own tampering

After a Quick Match or a vs-COM match start, the game recomputes param_check_sum. If it differs from the login value (stats changed in memory, e.g. by a trainer), or the squad has "Unregister:" / "Doping:" / "costover" entries, it sends {pid, match_category, data, error_code} (TaskWatchCheat 0x1411263a0). Never seen in our logs. Reply NOERR and record a cheat flag for the admin page. STATIC

Fair-play rating and word filter

• CMD_GET_MANNER_WARN → warn_kind opens one of four built-in courtesy-rating dialogs; the names don't match the texts: DOWN_B "The number of times you have failed to properly complete matches is increasing…", A_TO_B "Your courtesy rating has fallen to "B"…", DOWN_C "…failed to properly complete matches remains high…", STILL_C "Your courtesy rating has fallen to "C"…". Anything else shows nothing. Asked at the online login and on entering an online mode. LIVE (all four, 2026-11-07). The server rates players on their last 10 matches (pesmanner.py): an early exit is the player's own game reporting GIVEUP/EXIT/NO_OPERATION in SEND_ABNORMALEND, or their connection dropping mid-match; A ≤ 1, B 2–3, C ≥ 4; one warning per early exit.
• CMD_CHECK_STRING {str} is the bad-word filter for profile, clan, team, room and squad names. Any non-NOERR rejects the text (ERR_NGWORD and variants): "Includes unusable letters or phrases." LIVE. The server refuses whole words from the host's blocked_words.txt, and player names at CREATE_PLAYER (ERR_NGWORDINPNAME).

Showing our own text in the game

• Urgent announcement (simplest): CMD_GET_URGENT_ANNOUNCEMENT (request online_mode, announcement_type PRE_MAIN, lang, region). Reply {is_announcement:"YES", announcement_data: blob{online_mode, announcement_type, announcement_id, read_check, title, body}} to get a dialog before Quick Match. Echo the request's online_mode and announcement_type. LIVE It shows every time, so our server sends each message once per player.
• Maintenance warning: CMD_GET_MAINTENANCE_INFO → {maintenance_warn:"YES", maintenance_time: <unix seconds>} shows a Yes/No "maintenance soon" dialog (in local time) before matchmaking. No goes back to the menu. LIVE ("TRUE" shows nothing.)
• News list: CMD_GET_GLOBALINFOTITLELIST (gate, svrtype GATE or MENU) and CMD_GET_PRIVATEINFOTITLELIST → announce_info_list = list of blobs {announce_type NO_BANNER_INFO|BANNER_INFO|WEEKLY_INFO|COMPE_INFO|PERSONAL_INFO, title, announce_id, priority, popup_type ONCE|DAILY|EVERYTIME, weekly_info_type, event_id, date (u32), evoked_text, list_banner_file_info{filename, hash_str}, …}. The count key is spelled annnounce_info_list_num (three n's); the list drives the iteration. LIVE: the title is listed on "Online Information" at sign-in and, with popup_type EVERYTIME, opens as a pop-up at the main menu. The private list works the same way for one player (announce_type PERSONAL_INFO, body through CMD_GET_INFOBODY {is_private "YES"}): the game asks for it at login and on entering an online mode, pops up each new ONCE item, and remembers closed items across restarts LIVE. The server uses it for the host's messages to one player and the kick note.
  The body LIVE comes from CMD_GET_INFOBODY {pid, announce_id, is_private, lang, region} → announce_info: blob{announce_basic_info: blob{…}, body, link_url, direct_move, use_template, template_id, banner_file_info, compe_name, compe_start_time}. Use NO_BANNER_INFO, UTF-8 text, no link_url (it opens a browser). CMD_SET_WEEKLY_INFORMATION_ACTION acknowledges a weekly pop-up.
• Images (banners, ad boards, thumbnails) are plain GET <url>?fname=<name> downloads of raw bytes from the URL-list types TOPINFO, BANNER, WEEKLY_INFO_BANNER (key announce_id), ONLINE_AD, DMM_TOP (banners up to 409,600 B). CMD_GET_ONLINE_AD_FILE {ad_match_kind, compe_id} → ad_banner_file_name, ad_signage_file_name for stadium ad boards. The image format is UNKNOWN. No code path for ADFILE was found.
• "DMM" is not Japan-only. CMD_GET_DMM_NOTIFICATION is the top-menu Notifications feed (info_list of FEATURED_PLAYER, LEGEND_PLAYER, STORE_LINK, WEB_LINK, ICONIC_MOMENT items with title, body, thumbnails, players). CMD_GET_DMM_PLAYERINFO {is_present_inbox} is the gift-inbox badge. Both are sent every session on Steam. A bare NOERR is fine; avoid WEB_LINK/STORE_LINK. LIVE STATIC

Profile, account and store

Live (2026-11-06): different data → GNCX_0006 "Unable to connect." 2 s after the match start (the sums do block the match); is_revision_check:"NO" → team selection reached. GNCX_0006 is the same param/entry compare as MXNV_0017: the multiplay object reports it one tick before the match task would (gncx_labels.md). Live: with the check off, a match with different player stats stayed in sync past minute 15 (identical minimaps), so a mismatch is unfair rather than fatal. Still unknown: whether a no-banner news item shows and how priority sorts; the image format for banners, ads and avatars.

↑ Back to contents

Transport layers: large messages, the AES tier, dlcp, and the player-to-player link

(A) Server link (gate / ACCOUNT / MENU, TCP 10000)
    onlinesystem::Client → fox::ncl NclMio (Blowfish tier)  or  NclEnhancedMio (AES-256 tier) → msgpack
(B) Player ↔ player match link (UDP, direct or through TURN)
    onlinesystem::P2pFullMeshSession / CsClientSession / ObserveSession
      → kps::msp (multi-session protocol) → kps::domain::LlDomain + Clltcp (connections)
      → kps::lltcp FastTcp / ScalableTcp (reliability, pacing) → kps::dlcp (key exchange + RC4 records)
      → onlinesystem::NtlNetworkIo / P2pTurnIo* → ntl → UDP socket
(C) NAT traversal (ntl, cobra\NatTraversal\NTL): STUN-format messages with Konami methods/attributes

Frame kinds and fragmentation

• Receive peek 0x141854f10 accepts exactly these kinds. Bit 0x1000 of the raw kind selects the AES parser. STATIC
• Send path 0x1418537d0: a payload goes in one frame if it is ≤ 0x3f7 bytes (AES: 0x3d7). Otherwise the first chunk is 0x3f3 (0x3d3) and later chunks 0x3fc (0x3dc). The client rejects any frame body over 0x410 (0x141854a49). STATIC
• Server action: send replies over ~1015 bytes as 0x70 + 0x71… + 0x72 with this layout, never as one oversize 0x60 frame, and reassemble incoming fragments the same way. Our URL list was trimmed to fit one frame because of this limit.

The "enhanced" AES tier (NclEnhancedMio / NclCryptAes)

• Not tied to a server type. It's a global tier: every send uses AES once the client holds a 32-byte key (cmp [daemon+0x144],0 at 0x141216c75). STATIC
• Only two replies install that key, and only with key_size == 32: CMD_SET_CURRENTPLAYER (handler 0x1410f9ca0: cmp r8d,0x20 → 0x14184f8a0 AES, otherwise 0x14184f8d0 Blowfish) and CMD_RECONNECT (0x141233ee0). We send 16, which is why we've never seen AES. STATIC
• The key is cleared only when the game starts. Once AES is on, it stays on for every later connection until the game restarts. STATIC
• Crypto: AES-256-CBC via Windows BCrypt, manual PKCS#7 padding, SHA-256 integrity, no MD5, no XOR. Frame layout: STATIC

  off  len  field                                       encrypted?
  0    2    kind 0x1060/0x1070–72 (big-endian, no XOR)   no
  2    2    body_len (incl. padding) ≤ 0x410             no
  4    16   IV                                           no
  20   4    random nonce ("seq")                         AES-CBC ┐
  24   32   SHA-256(bytes[0:24] ‖ body)                  AES-CBC │ one CBC stream,
  56   n    body = data_len|orig|zlib|data + PKCS#7      AES-CBC ┘ (36+n) % 16 == 0

• The "COMPOUND" check in the send path is dead code left over from MGSV. Recommendation: keep 16-byte keys; AES gains us nothing.

kps::dlcp: security of the player-to-player link

• Every Clltcp connection in an LlDomain owns a dlcp link (vtable 0x142bc53a8 slots 13/19 → LinkController 0x14203c730). LlDomain is created by CreateMultiplaySession (0x1411aa730), which also picks the session type: 0 CsClient (game relay, "SC"), 1 P2P full mesh, 3 Observe. So dlcp protects the UDP match link between the players, and would also protect an SC relay or observer link. STATIC
• Key exchange (SimpleExchangeKeyExchanger): a ≤4-byte token and a 16-byte reply, both RC4 under the static key a977d392 db0e55b9 9d1641c2 d4f82739 (.rdata 0x142bcaf10). The 16 bytes become the session key. Direction is INFERRED.
• Record: [hdr u8][checksum u16 BE][payload], RC4 with the session key. hdr bit 7 = link flag, bit 6 = zlib (compress2 level 9), bits 0–5 random. The checksum covers the record with the checksum field zeroed. STATIC
• Sequence and ack live one layer up, in kps::lltcp (FastTcp/ScalableTcp congestion classes, pacing, loss/dup/reorder counters). UNKNOWN
• Our server never needs dlcp for P2P matches. A TURN relay carries it opaquely. Only an "SC" relay endpoint or an observer would have to speak it.

NAT traversal messages (ntl)

• Everything is RFC 5389 STUN framing (magic 0x2112A442), with Konami extensions. STATIC
  • Methods: 0x801 RT_ACK, 0x802–0x809 RP_HEARTBEAT / ENTRY / INFO / APPROVAL / EXIT / DATA_CAST / SYNC / P2P_SYNC, and the hole-punching set 0x80a UHP_FINALIZE, 0x80b UHP_CONNECT, 0x80c UHP_KEEPALIVE.
  • Attributes: 0x9090 RP_P2P_HEADER, 0x9091 RP_RELIABILITY, 0x9092 RP_AMF_DATA, 0x9093 RP_JSON_DATA, 0x9094–0x9096 RP_HOST / REFLEXIVE / RELAYED_ADDRESS, 0x9097 RP_NAT_TYPE, 0x9098 RP_SYNC_POINT, 0x9099 RP_ENTRY_IDX, 0x909a RP_PEER_STATUS, 0x909b RP_RAND_SEED, 0x909c RP_RELIABILITY_ECHO, 0x909d UHP_FINALIZE_RET, 0x9999 TERM, 0xf000 ATTR_EXTENSION.
• NAT tests: MappingTest IA…IV, FilteringTest I/II, Hairpin test. We answer the 0xF000 MappingTestIA. LIVE
• The 5-second keepalive to the STUN server is a Binding request carrying 0x9090 and 0x9091, with a counter that increases per answered keepalive. LIVE
• Hole punching (inferred from event names): UHP_CONNECT to the peer's host, reflexive and relayed addresses from WATCH_MATCHING, then UHP_KEEPALIVE, then UHP_FINALIZE / UHP_FINALIZE_RET. After that, dlcp/lltcp datagrams share the same UDP socket. Peers exchanged 48-byte and 256-byte packets in our captures. INFERRED

VDPCHAT and voice chat

VDPCHAT is one of four server types (with GATE, ACCOUNT, MENU). Entries of that type are stored in their own list (+0x4070 of the server list), but nothing reads that list. Voice chat (onlinesystem::VoiceChatImpl, ktVoice codec, TaskVoiceChat in the MOM lobby) appears to ride the match session. Don't advertise VDPCHAT. STATIC INFERRED

Still unknown: the lltcp header (sequence/ack/window), the contents of UHP_* messages, and the match-layer packet format (MatchOnline*.cpp messages inside msp). A hex dump of the first ~64 bytes of each UDP send during matchmaking and kick-off would settle all three.

↑ Back to contents

The big modes: myClub, clans, PES League, Matchday, events

Survey level: request and reply fields are extracted for every command (see the catalogue), but the flows below haven't been traced state by state. STATIC fields, INFERRED meaning.

myClub (125 commands)

• Everything is server-owned: the club (CREATE_MYCLUB_TEAM {team_name, base_team_id, coach_id, rental_gameplayer_id}), squads (CREATE/COPY/SET_MYCLUB_SQUAD_* with gameplan_data blobs), owned players (GET_MYCLUB_GAMEPLAYERLIST: gameplayer_id = the game's own player id, gameplayer_unique_id = the owned card, plus level, exp, contract_term, rating, tiredness and parameters), coaches, items, trainers and staff.
• Signing players: agents with draw rates (GET_MYCLUB_MARKET_AGENTLIST, GET_MYCLUB_AGENT_DRAW_RATE {rate_table}, USE_MYCLUB_AGENT), scouts and about 18 auction commands with live bidding (push WATCH_MYCLUB_AUCTION_SCOUT_DETAIL).
• Economy: GP and myClub coins (pes_point), contract renewals (EXTEND_MYCLUB_GAMEPLAYER), selling, presents, login bonus, achievements, weekly rankings (HTTP).
• Matches: VS COM (GET_MYCLUB_VSCOM_OPPONENT returns a whole team_data; SET_MYCLUB_VSCOM_GAMERESULT returns a rating), Sim, co-op squads, SEND_MYCLUB_MATCH_RATING.
• What's missing: Konami's card data. Featured and Iconic players have boosted stats sent by the server (parameters, enhanced_parameters), plus agent pools, prices and the event calendar. None of it is in the client.
• Feasible subset ("myClub lite"): cards from the local player database at base stats, a fixed coach list, our own agent pools, VS COM and PvP with our own rating. Large effort; a project of its own.

Clans (17)

Create, search, request to join, accept or reject, expel, settings, members' current online mode, and an HTTP clan ranking with divisions (GET_CLAN_RANKING {division}). Mostly records and lists of player blobs (pid, pname, online ids). Moderate effort; useful as a "friends group" feature.

PES League (17) and events / competitions (12)

DONE Online Tournament is in the server (pestourney.py, live 2026-11-08): friends' 1v1 competitions in the game's own eFootball League screens. A monthly "Friends Cup" runs by itself; hosts can add their own through /admin/api/tourneys (name, dates, team list, match length, outline text). The player enters with a team, presses Start Match (it uses Quick Match matchmaking with matching_type "PES_LEAGUE", and only players of the same competition are paired), and gets 3 points for a win, 1 for a draw. The after-match "Changes in rating" screen shows the points; the 1v1 menu, Rankings (5 pages), Current Match Results, Competition Outline and, after the end, the "Competition Results" notice with the final position all show real data.

• Match length and rules LIVE: a top-level compe_regulation blob in GET_PESLEAGUE_COMPE_INFO (match_time NUM in real minutes, condition STR, ranking_match_num, trade_num, extra_time STR, guest STR, is_equalization / is_3member_coop / is_ex_substitution YES/NO). Without it the game plays a match of about 2 minutes. is_equalization "YES" promises evened-out ratings and makes the game ask the server for them (GET_PLAYER_PARAMETERLIST); the server sends "NO", so teams play at their real strength.
• The path: list → "Enter this Competition. Proceed?" → COMPE_INFO (fields also inside a compe_data blob; match_type there picks 1v1 menu, co-op or lobby) → TEAM_LIST → JOIN_PESLEAGUE_COMPE {team_id} → 1VS1_MAINMENU_INFO (the matchmaking window ends at matching_first_date + matching_time). Layouts: tourney.md.
• PES League (eSports): competitions with entry windows and matching times (GET_PESLEAGUE_COMPE_LIST {entry_limit_date, entry_user_limit, match_end_date…}, …_1VS1_MAINMENU_INFO {matching_first_date, matching_interval, matching_time, point, rank…}), rankings, result lists and rewards. Needs a scheduler and standings.
• Events (COMPEV): event categories with banners (GET_EVENT_CATEGORY_LIST), VS COM or online competitions with progress counters (GET_COMPEV_MAINMENU_INFO {clear_count, progress_game_count, win_point}), join, leave and re-entry.

Matchday (20)

DONE Matchday is in the server (pesmatchday.py, live 2026-11-06): one standing event, Home and Away sides with four teams each, ordinary 1v1 matches (win 3, draw 1), points per player and per side. Needed: the event map inside compe_info.info_overview, a future end_group_match_date, and the player's own squad (sent with JOIN_MATCHDAY) returned by GET_MATCHDAY_SP_GAMEPLAN, or the match crashes while loading. Only the group stage: the pick-up stage and the watched final are not built (matchday2.md).

2026-11-06 (modes2.md, static): the group stage looks possible with one fake Matchday: JOIN_MATCHDAY_MODE → GET_MATCHDAY_LIST → GET_MATCHDAY_INFO → pick a side and a team → JOIN_MATCHDAY → GET_MATCHDAY_MAINMENU_INFO (progress "GROUP_MATCH") → START_MATCHING matching_type "MATCHDAY". The final (watched by others) needs spectating. Events (COMPEV) have no menu entry of their own: they are reached only from myClub and co-op event rooms.

Two-sided group events: join a side, play "pickup" matches (START_MATCHDAY_PICKUP_MATCHING → push WATCH_MATCHDAY_PICKUP_MATCHING with member host_addr, like Quick Match), collect Matchday points, and a final match between the sides' representatives that others watch (SET_MATCHDAY_START_WATCH_MATCH, GET_MATCHDAY_FINAL_RESULT_INFO {is_exist_watch_match_data}). Needs spectating (see co-op and spectating).

Random Selection, social, fair play

• Random Selection Match: GET_RANDOMSELECTION_LOTTERY_LIST {gameplayer_list, trade_num}, RESULT_RANDOMSELECTION_LOTTERY/TRADE, SYNC_RANDOMSELECTION_TRADE (ProcessOnlineRsLottery.cpp, MenuOnlineRsTrade.cpp). Random squads with trades. The player pool could come from the local database.
• Social: follow list, text chat and blocks (see rooms); GET_KONAMIID_FUNCTIONAL_BLOCKADE {is_blocked}.
• Fair play: CHECK_CHEAT, GET_MANNER_WARN {warn_kind}, SEND_KICK_REQUEST, and SEND_TAMPER_DATA {pid, match_category, data, error_code}, an anti-tamper report the game can send (never seen in our logs). See fair play and menus.

In-match sync messages (14)

TEAM_DATA_SYNC, USER_DATA_SYNC, BL_DATA_SYNC, SYNC_COMMENTARY, SELECT_SIDE, COMPLETE/UPDATE_TEAM_SELECT, CMD_ERR, CMD_LACK, CMD_SENDFAILED, LOST_GUEST, SET_GUEST, REVISION_CHECK have no reply parser. They look like player-to-player multiplay commands carried inside the match session (MultiplayCmdTeamDataSync.cpp), not server commands. INFERRED CMD_RECONNECT is a real server command (see match flow).

↑ Back to contents

Inside the game binary

• Size (PES2021.exe 1.01.00): 37 MB of code in the .trace section, about 118,500 functions (158,720 .pdata entries incl. chained chunks), 10,179 C++ classes with RTTI, 9,188 with recorded base classes. A further 380 MB section, .impdata, looks packed or obfuscated and was not examined. Only 68 source-file paths survive, 33 of them online code, so the rest of the game has few debug strings. STATIC
• Main areas by class namespace:

  Area	Classes	What it is
  fox::gr, fox::ph, fox::geo, fox::anim, fox::fx, fox::ncl …	~2,100	Fox Engine: graphics, physics, geometry, animation, effects, the server-link codec
  menu, menusystem, menuutility, flash	~1,400	menus and UI (416 classes derive from menusystem::Window)
  commandautomake, command, onlinesystem, onlinemode, onlinelogin	~1,750	server commands and the online system (this page)
  cobra::*	~840	Konami middleware: render, config, job graph, file I/O, NAT traversal
  mode::offline	737	offline modes; about 205 Scenario judge/post-process pairs, likely Master League / Become a Legend story events
  process, process::mail	~720	screen-flow steps (156 online ones) and an in-game mail/messages system
  match, match::player, match::ai, match::anime, match::pad, match::camera, matchPlan	~600	the match engine: player control, AI, animation, controller input, camera, tactics
  kps::*, ntl	~250	player-to-player network stack and NAT traversal (see transport layers)
  draw, sound, fixdemo, edit, savesystem, tmpdb, livedata	~300	rendering helpers, sound, cutscenes, Edit mode, saves, the in-memory database, live data

• Every server command also has a JSON form: 401 classes derive from fox::ncl::NclJsonMessageBase / NclJsonMessageResult, next to the MessagePack parsers we use. That's the second parser on each reply class. The game accepts MessagePack, so it isn't needed. STATIC
• Finding code: notes/re/functions/tools/classmap.py rebuilds the full class list with base classes and vtables from the game exe. The kb.py commands find users of a string, address or struct offset (str, refs, callers, disp), summarise a command (cmd) and dump functions (fn).

↑ Back to contents

The game database: players, teams, rosters

Where it is STATIC

• Files common/etc/pesdb/*.bin inside the CPK archives: the update pack download/dt80_100E_x64.cpk overrides Data/dt10_x64.cpk, which overrides dt00. The game reads 28 tables, including Player, Team, PlayerAssignment, Coach, Competition, CompetitionEntry, Country, Stadium, Tactics, TacticsFormation, PlayerWeekly and TeamWeekly (file table 0x1434d6630, record sizes 0x1428bb100).
• Wrapper: ff 10 81 "WESYS" + u32 compressed size + u32 size + zlib (flag 0x00 = stored). No encryption.
• In memory: up to 30,001 players (0x17c bytes each) and 750 teams (0x690 each). Player loader 0x1414f4500 → converter 0x1414f8420 → bit unpacker 0x1414c78e0 (108 setters) → clamp to MIN/MAX 0x1414f79d0. Teams and rosters: 0x1414f5120.

Player.bin: 312 bytes per player (18,452 in the update pack) STATIC

The 108 parameters (in the order the checksum uses): registered position; 13 position ratings (none / B / A); the 29 abilities (Offensive Awareness, Ball Control, Dribbling, Tight Possession, Low Pass, Lofted Pass, Finishing, Heading, Place Kicking, Curl, Speed, Acceleration, Kicking Power, Jump, Physical Contact, Balance, Stamina, Defensive Awareness, Ball Winning, Aggression, GK Awareness/Catching/Parrying/Reflexes/Reach, weak-foot usage and accuracy, form, injury resistance); height and weight; foot; age; playing style (22 values); 7 COM playing styles; 41 skills; and motion and appearance values. Names come from the game's own UI-order tables (0x142978fd0 abilities, 0x142978f90 positions, 0x142979100 skills, 0x1429790d8 COM styles). The bit map was checked against the game's real unpack code for 150 random players with zero differences. A few names are still uncertain (p43, p48–p50, the motion order). Skill names follow the game's own English labels: 74 = Long Range Drive (PES 2020's "Long Range Curler"), 106 = Long Range Shooting, 99 = Step On Ball Control, 105 = Cross Over Turn, 101 = Rising Shots. STATIC INFERRED

Team.bin and PlayerAssignment.bin STATIC

• Team.bin: 0x5fc bytes per team, 669 teams. Team id at +8, coach id at +0, rivals, stadium id (u16 at +0x3c), country (+0x44 bits 18–26), 20 language name slots (English at 0x170), short name at 0x372.
• PlayerAssignment.bin: 16 bytes per row, 18,582 rows: entry id, player id, team id, then flags with shirt number − 1 (bits 0–9), line-up order, set-piece roles and captain (bit 21). This is where current club, national team and shirt numbers come from.
• Coach, Country, Stadium, Competition, CompetitionEntry, Derby, Tactics, PlayerWeekly and TeamWeekly are described in notes/re/functions/db.md.

What the login checksums really are LIVE STATIC

• param_check_sum = for each player, (id & 0xffff) + the 108 parameters + (height & 0xff) + (weight & 0xff) + condition, summed into 4 accumulators and XOR'd with a fixed key. entry_check_sum = for each team, team id + Σ(player id + shirt number).
• Recomputed from the stock update-pack files: 25D6DFBB091E75D525E090F993DBAE73 / 1E21A82F1DFF00C9DBE591735FF8746A, exactly what both test clients sent. So both ran the unmodified update-pack database, with no edits and no live data. A game without the update pack (dt10 only) sends 25BC6828… / 1E8FB88B… and would fail the revision check against an updated player.
• The "condition" term is the player's weekly form from PlayerWeekly.bin, but only after a live update has been applied (DB live-data mode 1, set by LiveDataSetFlow). Otherwise it's the constant 5. So delivering live data changes every player's checksum: all players must get the same live data.

Saves and the option file

Saves live in Documents\KONAMI\eFootball PES 2021 SEASON UPDATE\save\ (types EDIT, SYSTEM, …), except the downloaded Live Update, which is C:\ProgramData\KONAMI\eFootball PES 2021 SEASON UPDATE\save\LIVE00000000 (live test). They're encrypted with an MT19937-based XOR stream (0x14140e0f0), keyed from 64 header bytes at +0x100. Where the master key comes from wasn't traced, and no save files were read. Edit data overrides the database, so an edited option file changes the checksums. STATIC

Using it

notes/re/functions/tools/pesdb.py reads the CPKs directly (update pack first): checksum (both sums, also the live-data variant), player <id>, team <id>, dump out.json. For the server, it gives names for the ids in SET_PLAYDATA_MATCH and line-ups, squads for vs-CPU co-op and a myClub-lite, and a way to name the cause when two players' checksums differ (missing update pack vs edited data).

↑ Back to contents

Live Update: how the game downloads new data

Three kinds of downloadable data STATIC

All three are ordinary CRI CPK archives, loaded on top of the base data (driver livedata::LiveDataSetFlow, LiveDataSetFlow.cpp, error prefix SGJC, update fn 0x1420ac3f0):

The sequence

1. Data pack gate: the game's update-pack version (version_dp.bin in dt80 = "1.00" | "1.01.00" | "2396" → 100) must not be lower than the server's DLC version, which is GET_SVRVERSION dlc_version (copied to [netmgr+0x68] by 0x1410f08c0). Otherwise ERROR_CODE_DP_VERSION_OLD (SGJC392). Our "1.00" passes. GET_SVRVERSION livedata_version has no reader. STATIC
2. Ask: CMD_GET_DLC_FILELIST over HTTP to the FLOW URL: file_type=LIVEDATA&region=REGION_ALL&pid=0. Sent at every login and again on entering an online mode, before JOIN_ONLINE_MODE and CHECK_CHEAT. LIVE
3. Decide: Live Update is new if atoi(dlcfile_list[0].dlc_version) > the version of the Live Update already saved (0 if none). Version strings in the files parse as "a.bb" → a·100+bb, so "1.01" ↔ "101". STATIC
4. Download: plain WinHTTP GET of the entry's url (https only if the URL says so). It needs status 200, and the body must be exactly size bytes: longer fails, shorter is zero-filled and fails the hash. The limit is 120 s for the whole transfer. STATIC
5. Check: SHA-256 of the downloaded bytes as 64 lowercase hex characters, compared exactly with hash (mismatch → "wrong hash", SGJC1006). That's the only check: no signature or key. STATIC
6. Save and load: the raw bytes go into the save slot (save failure → SGJC1102), then get loaded as a CPK at priority 5 (load failure → SGJC1306). Afterwards the edit data (option file) is re-applied on top, so players' own edits stay. A "LiveDataSetDialog" confirms it. STATIC

CMD_GET_DLC_FILELIST reply STATIC

• Fields: dlcfile_list_count, dlcfile_list, variation_file_list_count, variation_file_list, extra_file_list_count, extra_file_list (parser 0x141d34a90). There is no top-level dlc_version; the one we send is ignored.
• Each element is a real inline msgpack map (not a nested blob): {name STR, size NUM, url STR, hash STR, dlc_version STR (integer string), required_program_version NUM (ignored)}. Only dlcfile_list[0] is used. extra_file_list_count is trusted as the count, so keep it consistent with the list.
• Today we send empty lists: no live data → ERROR_CODE_NOT_DELIVERED → one "No new Live Update" dialog per session and CMD_SEND_LOG {title:"LiveUpdate"}, then login continues. Harmless. LIVE

What a Live Update file contains

• common/etc/version/version_wu.bin: 30 bytes, three NUL-padded 10-byte ASCII fields (content version, required program version, build string; the same layout as version_dp.bin; only the first field is read). Required: without it the client stays at version 0 and downloads again at every login. STATIC INFERRED
• The database tables the live-data module handles (0x142bd0ec0): PlayerWeekly, Tactics, TacticsFormation, PlayerAssignment, Player, PlayerAppearance, BootsList, PlayerDeleteList, Coach, CoachDeleteList, TeamWeekly, under common/etc/pesdb/ in the usual WESYS format. A full roster update is about 1.5 MB. Team.bin is not in the list.
• Persistence: the saved file stays across restarts until a higher version replaces it. The Live Update is applied per session by this flow; Variation and Extra files are loaded from boot.

Effect on matchmaking

CHECK_CHEAT is sent after the Live Update is applied, and with live data active the checksum also includes each player's weekly form. So players with the same Live Update get the same checksums (live: only while the server keeps listing the update; an empty list at mode entry makes the game fall back to its base data), and a player without it (or with an older one) would hit "DATAPACK error" against them. Players report their live-data version in JOIN_ONLINE_MODE livedata_version ("0" today), which the server can compare. There's also an ERR_DIFFERENT_LIVEDATA_VERSION error code, whose on-screen handling is unverified. STATIC LIVE

Publishing our own update (what the game expects)

1. Build a CPK with common/etc/version/version_wu.bin (e.g. "1.01" | "1.01.00" | a build string) and the changed common/etc/pesdb/*.bin tables. Our tools/pesmod CPK writer produces CPKs the game accepts.
2. Serve it with HTTP GET at a fixed URL on the server's HTTP port: status 200, exact Content-Length, raw bytes. httpgate.py needs a new route for this.
3. Reply: {"result":"NOERR", "dlcfile_list_count":1, "dlcfile_list":[{"name":"livedata_101.cpk", "size":<bytes>, "url":"http://<server>:8080/livedata/101.cpk", "hash":"<sha256, lowercase>", "dlc_version":"101"}], "variation_file_list_count":0, "variation_file_list":[], "extra_file_list_count":0, "extra_file_list":[]}. To publish again, raise the version in both the file and the reply.
4. Compare livedata_version at JOIN_ONLINE_MODE and pair players only when their checksums match.

Tested live: the Live Update slot is saved as C:\ProgramData\KONAMI\eFootball PES 2021 SEASON UPDATE\save\LIVE00000000 (encrypted), and the predicted checksum matched exactly (details). Still unknown: the folder for ExtraUpdate.bin; which tables are re-read after loading; how the client shows ERR_DIFFERENT_LIVEDATA_VERSION; what Variation and Extra files were used for (probably myClub card art and stadium assets).

↑ Back to contents

Tuning the connection: proto_opt, failover, NAT type, NAT test

GET_SERVER_ENV.proto_opt: the tuning tree STATIC

• Chain: GET_SERVER_ENV handler 0x141210dd0 → ParameterMultiplay::SetJson 0x141174b20 → JSON parse. It's read again every time a match session is created (CreateMultiplaySession 0x1411aa730). Invalid or missing JSON (our "NotImplement") is harmless: all defaults stay. A hash of the text is reported back in the post-match stats (PROTO_OPT_HASH).
• Shape: { "<profile>": { "<group>": { "<key>": value } } }. The profile is "P2P" for normal matches ("CS" for the game relay, "P2P_ADHOC" for direct online). A level profile "P2P_HIGH_LEVEL" / "_LOW_LEVEL" / "_GIVE_UP_QUICKLY_LEVEL" overrides it key by key. Which level Quick Match uses is unknown, so put values in "P2P". Integers must be JSON integers.
• Groups: Network, NatTraversal, Session, Domain, ProtocolTransmission, ProtocolChannel, MatchCommandBufferingControl (input-delay buffering), Match (load/out-of-play/command-lack timeouts), MultiplayStatistics, OnlineSystem (voice chat, network testers, observe).

The other two 15 s timeouts are ProtocolTransmission.ConnectionTimeoutUs and Domain.LinkTimeoutUs (key exchange: Domain.KeyExchangeTimeoutUs 20 s). Lever to test for hard-to-connect pairs: {"P2P":{"Network":{"NetworkIoConnectionTimeoutUs":30000000}}}. Keep proto_opt small so GET_SERVER_ENV stays within one frame. The full key list is in notes/re/functions/nettune.md.

When the game switches between direct and TURN STATIC

P2pTurnIoFailover (only when a TURN list is sent) starts on the direct path. It moves to TURN, while the TURN route is up, when: the direct link isn't connected (reason 1); the direct link has been congested for over 10 s (reason 3); or TURN is receiving but the direct link never received (reason 4) or has been silent for 7.5 s (reason 5). It goes back when the direct link receives within 7.5 s again (reason 6). After a congestion switch it waits 0 s, 10 s, 20 s… (at most 60 s) before going back. The reasons are reported in the post-match stats (TURN_CHANGEOVER_REASON/TIME). The TURN server must keep allocations alive for the whole match.

Possible limit: TURN setup checks that one config list has exactly one entry (0x14122eab1). If that list is the peers, TURN mode would only work 1v1 and co-op with a TURN list would fail with "Error CreateMultiplaySession". Test co-op with TURN before relying on it. UNKNOWN

The NAT type value (ntl_nat_type) STATIC

• 1 = no result yet; 2 or 3 = the NAT test failed. Otherwise a bit set: 0x10 UDP reachable, 0x20+low bits = filtering class (3 = worst/unknown), 0x100–0x2000 UPnP found / mapping / external IP, 0x4000 STUN address ≠ UPnP address, 0x10000 hairpin works, 0x20000 mapping varies (symmetric NAT), 0x100000 port preserved, 0x200000 port parity preserved, high bits = NTL config flags.
• Our clients' 0x10307533 = UDP reachable, port and parity preserved, UPnP working, STUN ≠ UPnP address (our STUN sees the LAN IP), filtering class 3. The hairpin and mapping tests never ran.
• The game never branches on it: no strategy change, no refusal, and no "NAT Type" text shown to the player. It's only reported to the server for matchmaking. Our matchmaker can ignore it, or use the symmetric-NAT bit as a hint to prefer TURN.

The NAT test and GateInfo.php

• 14 tests in phases (MappingTest IA…IV, FilteringTest I/II, hairpin). The extra tests only run if the first reply (IA) carries an OTHER-ADDRESS (0x802C) and a Konami 0xF000 "O573_CR_XADDR" address. Our STUN answers IA only, so the rest are marked skipped, and our logs show only the 32-byte IA probe. Nothing depends on the rest; leave stun.py as it is until the 0xF000 reply layout is proven. STATIC LIVE
• GateInfo.php: STATUS 200 and API_STATUS 0 (what we send) are fine. API_STATUS 1 + LOG_ACTIVE 1 + PUT_LOG_URL would make clients upload their NTL logs, an optional debug channel.
• The "SC" game relay (Konami's own full relay) isn't worth building: it needs the undecoded link layer and session logic, with no traffic to learn from. TURN is strictly better.

↑ Back to contents

Live test results (2026-11-05 and 11-06)

TURN relay LIVE

• The game accepts our list and certificate and connects over TLS to tls_port. It sends Allocate {LIFETIME 60, REQUESTED-TRANSPORT UDP, MOBILITY-TICKET (empty), SOFTWARE "ktc-0.0.0", FINGERPRINT}, receives a 401, retries with long-term credentials, and gets the allocation.
• It then needs the relay's SOFTWARE attribute to be a "dual route" directive HOST:PORT,<text>,0, which Turn::Impl reads after allocating. With no SOFTWARE, or any other value, the game closes the connection about 30 ms after the allocation and starts over every second, forever. With the directive, the TLS session stays up through a whole match, refreshed every 30 s. A port of 0 counts as invalid.
• With the directive, the game tries a second leg over DTLS/UDP to that host:port (three 189-byte UDP packets at 0, 1 and 3 s). With nothing answering, it never publishes SEND_TURN_ADDRESS_DATA (watched for over 3 minutes), so the relay isn't used.
• Second leg against a stock DTLS server: the game completes a DTLS 1.2 handshake (cookie exchange included) with our relay's TURN certificate, cipher ECDHE-ECDSA-AES256-GCM-SHA384 (the same as the TLS leg). It then sends application-data records over and over that the stock server can't read. Later (2026-11-06): they are TURN Allocates in the ktc framing (64-byte STUN + type byte, plus a 2-byte trailer counted in the record length); with that handled, the DTLS leg works, see the second round below. LIVE

Live Update LIVE

• Our reply offered one CPK (common/etc/version/version_wu.bin "1.01" + an edited common/etc/pesdb/Player.bin with Messi's Speed 81 → 82). The game fetched it with one HTTP GET, checked the SHA-256, saved it and applied it. It then showed "No Live Update changes to Condition Rating. All players' conditions will change each match…", its notice for an update without a PlayerWeekly table.
• JOIN_ONLINE_MODE livedata_version became "1.01". CHECK_CHEAT param_check_sum was exactly the value pesdb.py predicted (25D6E9E6…6094); the roster checksum was unchanged.
• Saved as C:\ProgramData\KONAMI\eFootball PES 2021 SEASON UPDATE\save\LIVE00000000: the CPK plus 990 bytes, encrypted by the save system. Deleting that file removes the update.

Reconnect, outages, AFK LIVE

• Server down about 7 s during a match: both games sent CMD_RECONNECT {pid, platform, patch_version, dlc_version, online_mode}, got a new key and carried on. About 15 s: "Connection to server lost. CODE:APLR_0002". Outage while in the menus: "Connection to server lost. CODE:VNBP_0002", with no reconnect attempt.
• AFK: 72 s without input after kick-off ends the match. The idle player gets NO_OPERATION / VIXT2253_0x1a000000 ("This match will be called off, as you stopped playing for some time."); the other gets DISCONN_SC / GNCX_0003_0x20000000 ("Connection quality with … has significantly worsened. Canceling match."). Both still wait out REQ_GAMEADDPOINT (+10 s) before reporting results (+22 s).

Menus LIVE

The eFootball menu lists Quick Match, Online Divisions, Online Co-op, Matchday and Online Tournament. Kick Off lists Local Match, Local Match [UEFA EURO], Co-op, Random Selection Match, Versus, League and Cup. The list scrolls: after Cup come Friendly Match Lobby (the Free 1v1 room lobby), Team Play Lobby (MOM) and Training. (An earlier version of this page wrongly called the lobbies hidden; the first test stopped scrolling at Cup.)

Friendly Match Lobby, live: JOIN_ONLINE_MODE {online_mode "FREE"} → SEND_IPANDPORT_NTL, GET_SERVER_ENV, CHECK_CHEAT, GET_URGENT_ANNOUNCEMENT, GET_MANNER_WARN, GET_PRIVATEINFOTITLELIST → GET_LOBBYLIST {lobby_type "FREE"} → JOIN_LOBBY → GET_LOBBYINFO → GET_BLOCKLIST. A bare "OK" here gives "Unable to send or receive data."; with one block it continues: JOIN_BLOCK {block_id} → REQWATCHL_ROOMLIST is a real request → the "Match Room List" screen ("Set up Match Room", "Number of rooms"). Creating a room: Room Settings (name, security, password) → General Match Settings (time, injuries, ball, time limit, overtime, PK, substitutions) → CHECK_STRING {room name} → CREATEJOIN_ROOM first, then SET_GAMEENV (game_env = a blob of the 9 settings) → REQWATCHL_ROOMPLAYERLIST_NTL {room_id}. Room creation works when the server follows three rules found by code reading and a live bisection: (1) after CREATEJOIN_ROOM, push the owner's room into the room list (ADD) before the player list, because the game looks for its own pid in the room list; (2) in the player list, pname.psn_user_id is a nested blob {account_id, online_id, is_valid_cache} (an object, as in WATCH_MATCHING, exits the game; an empty list is read as garbage memory); (3) answer REQWATCHL_ROOMPLAYERLIST_NTL only with the reply and push no list before the owner's ENTRY_GAME: our test server also pushed the same list 50 ms later, and that second copy ended the game about 0.2 s later every time (an UPDATE after ENTRY_GAME was harmless). With the reply only, the owner sends ENTRY_GAME {entry FALSE, side HOME} and shows the room screen "[001]Room <name>". A bare NOERR reply without a list gives LEAVE_ROOM {error_code "VZLN_0002"} (creation failed). A second player's Match Room List showed "Number of rooms 0" although our reply listed the room. Code reading found the cause: the list builder (0x14104c730) hides every room whose gameenv.limitTime is NOSET or unknown, and also rooms with is_invite_limit YES or an empty gamer list. Our test server sent NOSET because it never unpacked the game_env blob of SET_GAMEENV (the game had sent MIDDLE). The fix: store that blob, echo it as gameenv, and push a room-list UPDATE after SET_GAMEENV (notes/re/functions/roomlist.md). An empty list as owner_pname.psn_user_id in the room list ends both games (notes/re/functions/livetests.md, roomcrash.md). LIVE

Friendly Match Lobby, whole flow (2026-11-06): with those rules, a friend picks the room and both players reach team selection.

1. Room list: the second player sees "Number of rooms 1" and the row "[001]Room <owner>" with Owner, Capacity 1/2 (gamer_num/max_players) and an EN tag (owner_lang).
2. Room details: selecting the row sends REQWATCHL_ROOMPLAYERLIST_NTL {room_id} from a non-member. Our reply gives the details screen: the owner's settings from gameenv (limitTime MIDDLE shows as "Time limit Normal"), Home = owner, Away = "Accepting Participants", Enter.
3. Join: JOIN_ROOM_NTL {room_id, is_invited "NO", password} → reply {room_owner blob, room_stat} + room-list UPDATE. The joiner then asks for the player list (reply) and sends ENTRY_GAME {entry FALSE, side AWAY}. A player-list UPDATE goes to the owner, who sends SEND_NOTICE ROOM_SHARE_INFO (team id/name/power, chemistry) to both and an empty SET_GAMEMEMBER. Both screens show Home and Away names.
4. Ready: "Start Match" sends ENTRY_GAME {entry TRUE, side}; after our WATCH_ENTRY_GAME push that side's OK turns green.
5. Start: when both have entered, the owner sends SET_GAMEMEMBER again. The server pushes WATCH_DECIDE_GAMEENV {game_env} and WATCH_ROOMSTATE {StateChanged, SETENV} to both. The games then run the usual match start: GET_MATCHID, SEND_SYNC_NOTICE, GET_SERVER_ENV, P2P START/END, DATASYNC. The owner sends SET_GAMEMEMBERENV {envlist [blob{pid, side, sideLeader}]} (default reply is enough), then TEAMSELECT. Both games showed team selection. Stopped there; from here it is the same match session as Quick Match.

Player-list UPDATE pushes after a player's ENTRY_GAME, and to the owner when someone joins, were harmless. The test handlers live outside the repo; the production server does not have the lobby yet. LIVE

Second round (2026-11-06 afternoon)

• A whole Friendly Match Lobby match, and back to the room. A 10-minute match ran through 1ST … BREAK1 … 2ND … END (about 29 real minutes with autoplay). After the "Full Time" screen each game sends HTTP SET_PLAYDATA_MATCH (gamemode 26), SEND_STATS_DATA, SEND_GAME_RESULT, a new REQWATCHL_ROOMLIST and LEAVE_GAME. Whoever confirms first leaves the match session; the other, still on the stats screen, then reports DISCONN_P2P / GNCX_0003 and sees "This match will be abandoned. There has been a connection problem…" (same pair as in Quick Match). When both have left, our WATCH_ROOMSTATE WAITING push brings both back to "You can now start the match by selecting Start Match", so a rematch is possible. A room in a match stays in the list (2/2); selecting it gives "Could not enter because a match is currently being played." from the client itself. LIVE
• The duplicate-list crash is confirmed: a player-list RELOAD pushed to a game whose list cache already holds entries ended it within 0.25 s, with e06d7363 (C++ exception) in its Wine log; an UPDATE was harmless. Rule: RELOAD only as the reply to a new REQWATCHL_* request, every push ADD/UPDATE/DEL. LIVE
• Live Update: keep listing it. The game asks for the file list again when it enters an online mode (always pid=0). If the update is no longer listed, it computes CHECK_CHEAT from the base data, while still reporting livedata_version. Listed every time, the sums were exactly as pesdb.py predicts. A reboot does not download it again. LIVE
• TURN relay, second leg working. The game's TURN client is stock OpenSSL 1.1.0i wrapped by Konami's ktc layer, which adds 2 bytes after the last record of every application-data datagram it sends (and counts them in the record length) and ends every plaintext with a type byte (0x00). A relay that strips the 2 bytes, strips the 0x00 and replies with SSL_write(message + 0x00) gets the whole flow: Allocate → 401 → Allocate → Refresh, the TLS connection closed (it only bootstraps), CMD_SEND_TURN_ADDRESS_DATA published, ChannelBind to the opponent's relayed address and ChannelData both ways. The address blob is 20 bytes: 00, port big-endian, IPv4 little-endian, zeros. The 21.4 s restart cycle came from the game re-creating its DTLS socket every 10 s (DSCP on by default), which changes its UDP port; a relay that moves the session to the new port when a record decrypts with that session's keys keeps TURN up (fixed, turncycle.md). A match runs entirely over the relay (both direct paths made unreachable): kick-off and play over TURN, 10,000+ relayed packets. The key: the game sorts the two peer address labels and only the side with the lower one opens the link, so the server must hand out labels where exactly one side is "lower" (our first try had both waiting and failed with MXNV_0013). proto_opt is honoured too (DscpEnable false stops the port changes; Session.ConnectionTimeoutUs moved a timeout from 10 to 30 s) (ktcdtls.md, turncycle.md, turnlinkup.md). LIVE
• Data mismatch (one copy on a Live Update, one stock): with is_revision_check on (default) both sessions end 2 s after START with GNCX_0006 and "Unable to connect." (not the predicted MXNV_0017); with is_revision_check:"NO" both reach team selection. LIVE
• Online Co-op 1 vs 1: the menu opens; matchmaking needs the server to echo each player's own SYNC_PROGRESS notice back, then START_COOP_MATCHING arrives; the session needs GET_GAMERELAY game_sycom "P2P" (with "" it fails with MXNV_0010). It then stopped (START notice to nobody, MXNV_0013): co-op never hands its peer list to the P2P layer, which Quick Match and the lobby do. Fixed in mod 0.5.0, which hooks the two co-op functions to add that step and to keep the peers' addresses, and the server's pescoop.py: with both, an Online Co-op Casual Match connects and kicks off (one human per side, the other four players CPU). The server must give each side a real team (use_team_id); "no team" on both sides crashes the match load. 2v2/3v3 with more humans can't run: the game's P2P layer takes one peer (coop2.md). LIVE
• Dialogs photographed: ERR_DIFFERENT_PATCHVERSION ("Your version of PES 2021 is out of date…"), ERR_PARAMCHECK_FAILED ("Invalid player data found." then CCWR_0014), ERR_MODE_BLOCKED, ERR_LOBBYUSERMAX ("Cannot participate due to full quota."), GET_BLOCKLIST ERR_DATABASE, ERR_ROOMCREATELIMIT, the courtesy-rating "B" warning (GET_MANNER_WARN A_TO_B) SET_GAMEMEMBER ERR_DATABASE (C_DYUN_0013; it came from a crash in our test handler, which the gate answers with ERR_DATABASE) and LOGIN ERR_INVALID_ACCOUNT (the account-suspended text; the game then stays offline). Exact texts in livetests.md. LIVE

Third round (2026-11-06 evening)

• Spectating works: a lobby match was recorded through our server and replayed on one copy from storage, through the PES League lobby, with server replies only (details). LIVE
• Live Update team data is applied: a Team.bin edit (FC Barcelona "BAR" → "BRX") showed on the scoreboard, and the PlayerAssignment edit moved entry_check_sum to exactly the pesdb.py prediction; a Speed edit of 11 players gave the predicted param_check_sum. LIVE
• Different player data, check off: the match stayed in sync past minute 15 (identical minimaps on both copies); no SYNC_FAILED. LIVE
• "Server full" login (LOGIN → ERR_FREE_TO_PLAY_FULL): "Due to excessive traffic on the PES 2021 server, login is currently restricted. Please try reconnecting again later." LIVE

Online Divisions, Team Play Lobby, room counters (2026-11-06 evening)

• DONE Online Divisions is in the server (pesdivisions.py): ten divisions, ten-match seasons, win 3 / draw 1, promotion and relegation at season end, its own matchmaking queue; a full division match was played live and both games showed the rating change and the new result on the Divisions chart.
• Online Divisions is Quick Match plus a division screen. The season is just a count of matches left (other_match_num, 10 per season); with today's bare GET_DIVISION_INFO it is 0, so every visit runs the season-end screens and then hangs. With a division_info blob (division, thresholds, matches left, a match_history_list whose division_point values add up to the points) the Divisions screen shows the badge, the chart and each result; the search then sends START_MATCHING {matching_type "OC_RANK"} and reached "View Opponent" on both copies. A spec for a 10-division server is in modes2.md. LIVE
• Team Play Lobby: two humans can start a room, but this lobby only connects through Konami's own game relay ("SC"), which we don't have; the direct path used by the Friendly Match Lobby is switched off for it in the game (lobby2.md). STATIC
• Room counters ("N Match(es)", Wins) only count the end-of-match verdict push; the server now sends it at the final whistle of every lobby match. Room chat: the game prints only lines it receives, so our echo to the sender shows once. STATIC
• Events / Matchday: events have no menu of their own (they come from myClub and co-op); Matchday's group stage looks possible with one fake event (modes2.md). STATIC

Full details: notes/re/functions/livetests.md.

↑ Back to contents

What the player sees: error texts and server replies

How a text is found STATIC

• Message id = (group number << 16) | entry id, where the group number is the u32 at +4 of each group header in the .str string tables (lookup 0x141497dd0 → 0x1414996f0). Example: 0x0398002f = "Press Any Button". "Failed to connect with opponent." is 0x045b0010, shown by the lobby room screen (0x1410438a0).
• Server error replies: every command shows an error dialog automatically (on by default, flag at +0x74; about 40 commands switch it off). The text comes from the game's table at 0x1428a1170 (command, ERR code, message id):
  • message id 0xffffffff: no dialog; the screen that sent the command decides (109 rows);
  • message id 0 or 0x01fb00d2: the generic "An unexpected problem has occurred while communicating with the server." plus CODE: = a hash of the command name + "_" + the ERR number, e.g. ZVMY_0079 (163 rows);
  • any other id: that specific text, with no code (492 rows).
• On-screen codes from the error reporter: TAG_%04d when the site has a sub-code, otherwise TAG + line, optionally followed by an extra value (GNCX_0003_0x20000000). Most codes players see are therefore in the sub-code form (MXNV_0013, CCWR_0014); the error table shows both forms.

Replies that give players a clear message STATIC

• Version replies: the three JOIN_ONLINE_MODE → ERR_DIFFERENT_* rows show their text from the command layer, but the login flow then also aborts with the generic login error (line 216 of OnlineLoginTaskConnectMenu2.cpp). For a clean refusal use ERR_MODE_BLOCKED (sweep.md). STATIC
• Avoid: CMD_LOGIN's live-data error row, which points to a Condition Rating help text; and ERR_JOINKICKEDROOM, which only gives the generic text plus a code.
• Live-update errors (0x1420ac100): 1 "Unable to login.", 2/6 "Communication error", 3 "The downloaded file is broken.", 4/5 "Install failed.", 7 "No new Live Update available.", 8 "Data Pack Incompatible…".
• {rf} / {re} in texts are macros the game fills in (probably the game title) INFERRED. The full table, with every command and ERR code and its text, is notes/re/functions/data/server_errors.tsv.

↑ Back to contents

Error codes: every place the online code reports one

• The reporter is 0x1411546b0(mgr, function-name, source path, line, sub-code). The four letters are a hash of the .cpp file name (notes/re/errcode.py). STATIC
• The code players see is letters + "_" + 4-digit sub-code when the site has one (most do), otherwise letters + line. Two formats share those letters: letters + line (EYRH763 = OnlineModeTaskQuickMatching.cpp line 763), and letters + "_" + 4-digit sub-code (GNCX_0003_0x20000000 = OnlineModeMultiplay.cpp sub-code 3, reported at line 505; the hex tail is an extra error value). STATIC LIVE
• Codes reported through other paths and seen in our logs: EYRH763 Quick Match search timed out; EYRH1530 Quick Match abnormal end GAMERELAY / DEGRADE_SC; QVHE1459 GameModeMatchListenerMatch.cpp, loading took longer than load_timeout (LOAD_TIMEOUT); VIXT2253 MatchOnline.cpp, no input for about a minute (NO_OPERATION, the AFK rule); OLXH152 error on the CHECK_ALIVE_PLAYER watcher; FAMY242 the server replied ERR_CHEAT to an in-match command; LZFP101 SEND_ALIVE. LIVE STATIC
• Meanings come from the message string the code stores next to the report, or from the area sections above. Rows without a meaning have no nearby text.

↑ Back to contents

Catalogue of all 433 server commands

Request fields come from each command's request builder (HTTP form or gate MessagePack), with the common msgid, rqid, svrtype, client, urltype left out. Reply fields come from the reply parser, with nested objects' fields flattened into the same list (see the encoding rules for blobs vs inline maps). STATIC