This page covers how party state is tracked via the SOCache, what generated methods exist for party operations, and the invite/ready-check flow.
Party objects (CSODOTAParty, CSODOTAPartyInvite) are shared objects pushed by the Dota 2 GC and synchronized through the SOCache. Party operations are mostly fire-and-forget writes to the GC; state changes are observed by subscribing to the relevant SOCache containers.
For lobby-specific functionality such as custom games and practice matches, see page 3.3. For general event handling and SOCache integration, see pages 2.1 and 2.2.
The party system revolves around two shared object (CSO) types synchronized through the SOCache. Their type IDs and proto constructors are registered in the internal CSO mapping logic.
CSO Type Registry (party-related entries)
| Constant | CSOType ID | Proto Message |
|---|---|---|
cso.Party | 2003 | CSODOTAParty |
cso.PartyInvite | 2006 | CSODOTAPartyInvite |
Sources: protocol/dota_gcmessages_common_match_management.proto
The CSODOTAParty message represents the main party state, including membership, configuration, and current activity status.
CSODOTAParty — field overview
Sources: protocol/dota_gcmessages_common_match_management.proto
Each party member is represented by a CSODOTAPartyMember structure containing role, networking, and matchmaking data.
| Field | Type | Description |
|---|---|---|
is_coach | bool | Whether the member is coaching |
region_ping_codes | repeated uint32 | Region codes for ping measurement |
region_ping_times | repeated uint32 | Ping times to various regions |
lane_selection_flags | uint32 | Preferred lane selections (see ELaneSelectionFlags) |
mm_data_valid | bool | Whether matchmaking data is valid |
high_priority_disabled | bool | High priority matchmaking status |
banned_hero_ids | repeated int32 | Heroes banned by this member |
Sources: protocol/dota_gcmessages_common_match_management.proto
Party objects transition through defined states that correspond to different phases of the matchmaking and game experience. The CSODOTAParty_State enum is defined in the generated protocol package.
CSODOTAParty state machine
Sources: protocol/dota_gcmessages_common_match_management.proto
Party operations are split between hand-written methods in client_party.go and generated methods in client_generated.go. All of them ultimately call d.write(...) to send a fire-and-forget GC message; state changes are observed asynchronously via the SOCache.
The client_party.go1-19 file provides two core party operations:
LeaveParty() — client_party.go8-10 Sends EGCBaseMsg_k_EMsgGCLeaveParty with an empty CMsgLeaveParty message body via d.write().
RespondPartyInvite(partyId uint64, accept bool) — client_party.go13-18 Sends EGCBaseMsg_k_EMsgGCPartyInviteResponse with CMsgPartyInviteResponse containing the party_id and accept boolean fields.
Both methods use the fire-and-forget d.write() pattern. State changes resulting from these operations are observed asynchronously through SOCache updates.
Party invite/join flow
Sources: client_party.go8-18
The following party-related methods are emitted by apigen into client_generated.go. All use the fire-and-forget d.write(...) pattern (no response).
| Method | GC Message ID | Request Proto |
|---|---|---|
AckPartyReadyCheck | k_EMsgPartyReadyCheckAcknowledge | CMsgPartyReadyCheckAcknowledge |
CancelPartyInvites | k_EMsgClientToGCCancelPartyInvites | CMsgDOTACancelGroupInvites |
SetPartyLeader | k_EMsgClientToGCSetPartyLeader | CMsgDOTASetGroupLeader |
SetPartyOpen | k_EMsgClientToGCSetPartyOpen | CMsgDOTASetGroupOpenStatus |
MergePartyInvite | k_EMsgClientToGCMergePartyInvite | CMsgDOTAGroupMergeInvite |
MergePartyResponse | k_EMsgClientToGCMergePartyResponse | CMsgDOTAGroupMergeResponse |
SendPartyReadyCheck | k_EMsgPartyReadyCheckRequest | CMsgPartyReadyCheckRequest |
The proto type mappings for several of these required manual overrides because the heuristic name matching in apigen could not resolve them automatically.
Party method code entity map
Sources: client_generated.go19-29 client_generated.go146-158 protocol/dota_gcmessages_common_match_management.proto
The invitation system manages sending, receiving, and responding to party invitations between players. Invitations are tracked through shared objects and discrete events.
CSODOTAPartyInvite is registered in the CSO type registry under type ID 2006.
CSODOTAPartyInvite — field overview
Sources: protocol/dota_gcmessages_common_match_management.proto
Incoming party invitations arrive as SOCache create events on the cso.PartyInvite container. Consumers subscribe with client.GetCache().SubscribeType(cso.PartyInvite).
Each received *socache.CacheEvent has EventType == EventTypeCreate and Object of type *protocol.CSODOTAPartyInvite.
To respond, call RespondPartyInvite(partyID, accept) (client_party.go13-18), which sends EGCBaseMsg_k_EMsgGCPartyInviteResponse.
When an invitation is successfully created, the GC emits an InvitationCreated event. This event implements the Event interface defined in events/event.go9-16
InvitationCreated event structure
| Field | Type | Source |
|---|---|---|
| Event wrapper | events.InvitationCreated | events/invite.go9-11 |
| Embedded message | CMsgInvitationCreated | events/invite.go10 |
| Message ID | EGCBaseMsg_k_EMsgGCInvitationCreated | events/invite.go15 |
| Event name | "InvitationCreated" | events/invite.go24 |
The event is emitted when the GC confirms an invitation has been dispatched to the target player. Applications can subscribe to this event to track outgoing invitation status.
Sources: events/invite.go8-26 events/event.go8-16 client_party.go13-18
Parties can initiate ready checks to confirm all members are prepared for matchmaking or other activities.
| Method / Message | Direction | Purpose | Key Fields |
|---|---|---|---|
SendPartyReadyCheck() | Client → GC | Initiate a ready check | (empty) |
CMsgPartyReadyCheckResponse | GC → Client | Server ack | result (EReadyCheckRequestResult) |
AckPartyReadyCheck(readyStatus) | Client → GC | Member responds | ready_status (EReadyCheckStatus) |
SendPartyReadyCheck and AckPartyReadyCheck are generated in client_generated.go.
Ready check flow
EReadyCheckStatus)| Value | Constant | Meaning |
|---|---|---|
| 0 | k_EReadyCheckStatus_Unknown | No response yet |
| 1 | k_EReadyCheckStatus_NotReady | Member declined |
| 2 | k_EReadyCheckStatus_Ready | Member accepted |
Sources: client_generated.go22-29 protocol/dota_gcmessages_common_match_management.proto
Party members can specify preferred roles and lanes for matchmaking via CSODOTAPartyMember.lane_selection_flags, a bitfield using the ELaneSelectionFlags enum.
| Flag | Value | Lane/Role |
|---|---|---|
k_ELaneSelectionFlags_SAFELANE | 1 | Safe lane carry |
k_ELaneSelectionFlags_OFFLANE | 2 | Off lane |
k_ELaneSelectionFlags_MIDLANE | 4 | Mid lane |
k_ELaneSelectionFlags_SUPPORT | 8 | Support |
k_ELaneSelectionFlags_HARDSUPPORT | 16 | Hard support |
Predefined combinations simplify role selection:
k_ELaneSelectionFlagGroup_CORE (7): Safelane + Offlane + Midlanek_ELaneSelectionFlagGroup_SUPPORT (24): Support + Hard Supportk_ELaneSelectionFlagGroup_ALL (31): All rolesSources: protocol/dota_gcmessages_common_match_management.proto
CSODOTAParty and CSODOTAPartyInvite are managed through the SOCache system. The GC pushes updates via CMsgSOCacheSubscribed and CMsgSOMultipleObjects.
SOCache subscription and update path for party objects
Sources: client_party.go13-18 protocol/dota_gcmessages_common_match_management.proto
Refresh this wiki