洱海月 v0-07-0300 封包解析：ID 1228 GCRaidAskInvite（发给被邀请者的团队邀请提示）

GCRaidAskInvite 是团队系统里发给被邀请者的邀请提示包。当前世界服在 CGRaidInvite 校验通过后，会把团长资料封进这条包发给目标玩家；客户端收到后不会直接入团，而是先把邀请写入本地邀请列表，再触发团队邀请提示与后续确认流程。

包信息

项目	内容
封包 ID	1228
包名	GCRaidAskInvite
方向	GC 服务端 -> 客户端
对应请求	CGRaidInvite
后续回复	CGRaidRetInvite
固定包长	46
当前 Lua 状态	现役协议；世界服校验成功后只发送给被邀请目标
主要作用	向目标玩家投递团队邀请，并在客户端生成本地待确认邀请项

包体结构

当前 Game.exe 的 GetPacketSize() 可直接确认，这条包固定长度为：

46

按当前 Game.exe 读写顺序，以及现役 Lua 发送链的命名，包体结构如下：

偏移	长度	字段	类型	含义
0x00	0x04	leader_guid	uint32	团长 GUID；客户端缓存邀请项并在 CGRaidRetInvite 中回传
0x04	0x1E	leader_name	char[30]	团长名字；客户端邀请列表与提示文案直接使用
0x22	0x02	m_ZoneWorldID	int16	现役 Lua 发送端按区服 / World ID 写入；当前客户端 Execute() 未直接消费
0x24	0x04	leader_level	uint32	团长等级；当前客户端邀请列表按低 16 位读取并显示
0x28	0x02	invite_group_key	int16	客户端加入本地邀请缓存时使用的辅助分组键；现役 Lua 固定写 0
0x2A	0x04	operate_key	int32	邀请操作 Key；客户端缓存后会在 CGRaidRetInvite 同意/拒绝时回传，现役 Lua 固定写 0

需要单独说明两点：

• leader_level 在网络包里按 4 字节序列化，但客户端邀请列表脚本实际按低 16 位使用。
• m_ZoneWorldID 是当前现役 Lua 发送链明确填写的字段名；但当前客户端执行函数没有直接消费它。

当前实际行为

• 当前 Game.exe 中，GCRaidAskInvite::GetPacketID() 返回 1228，GetPacketSize() 返回固定 46。
• 当前 Read() / Write() 顺序固定为：
  • leader_guid
  • leader_name[30]
  • m_ZoneWorldID
  • leader_level
  • invite_group_key
  • operate_key
• 当前客户端 Execute() 的核心行为已经可以明确确认：
  • 先把邀请项写入本地团队邀请缓存
  • 写入缓存成功后，弹出 TDGZ_100809_44 对应的团队邀请提示文案，并带入 leader_name
  • 继续触发一次本地团队邀请后续流程与界面刷新
• 当前客户端 Lua 接口 LUA:Raid::GetInvitationByIdx 会直接从本地邀请缓存里返回：
  • 团长名字
  • 团长等级
• 当前客户端 Lua 接口 SendAgreeRaidInvitation / SendRejectRaidInvitation 会从缓存邀请项中取出：
  • leader_guid
  • operate_key
    并组包发送 CGRaidRetInvite
• 这说明当前 operate_key 虽然在现役 Lua 世界服发送时固定写 0，但在客户端本地协议链里确实被当作“回复邀请时需要原样回传的操作键”处理。
• 现役 /home/ubuntu/Game2 世界服发送链当前只显式填写：
  • leader_guid
  • leader_name
  • m_ZoneWorldID
  • leader_level
• 现役 Lua packet.lua 中尾部两个字段当前固定写为：
  • invite_group_key = 0
  • operate_key = 0
• 现役 Lua 服务端处理 CGRaidRetInvite 时，实际只使用：
  • m_Return
  • m_GUID
    对第三个 uint32 仅做占位读取，当前没有参与业务判断。

服务端落点

• 协议定义与序列化：/home/ubuntu/Game2/services/game/packet.lua
• 邀请请求入口：/home/ubuntu/Game2/services/msgagent.lua
• 世界服邀请处理：/home/ubuntu/Game2/services/world/worldcore.lua

当前活跃发送链是：

• 客户端发送 CGRaidInvite
• msgagent.lua 转发到 .world
• worldcore:char_invite_raid() 做团队资格校验
• 校验通过后构造 GCRaidAskInvite，只发给被邀请目标

关键代码

当前 Lua 的活跃发送点

local msg = packet_def.GCRaidAskInvite.new()
msg.m_ZoneWorldID = invite.m_ZoneWorldID
local leader_member = raid:leader(define.RAID_POISTION.RAID_POISTION_LEADER)
if leader_member then
    msg.m_uLeaderLevel = leader_member.level
    msg.guid = leader_member.guid
    msg.nickname = leader_member.name
    self:send2client(tar, msg)
end

当前 Lua 协议序列化

stream:writeint(self.guid)
stream:write(gbk.fromutf8(self.nickname), 0x1E)
stream:writeshort(self.m_ZoneWorldID)
stream:writeint(self.m_uLeaderLevel)
stream:writeshort(0)
stream:writeint(0)

当前 Game.exe 的读写结论

GetPacketID()   = 1228;
GetPacketSize() = 46;

Read(stream) {
    read_u32(leader_guid);
    read_char_30(leader_name);
    read_i16(m_ZoneWorldID);
    read_u32(leader_level);
    read_i16(invite_group_key);
    read_i32(operate_key);
}

Write(stream) {
    write_u32(leader_guid);
    write_char_30(leader_name);
    write_i16(m_ZoneWorldID);
    write_u32(leader_level);
    write_i16(invite_group_key);
    write_i32(operate_key);
}

当前客户端的本地消费链

Execute() {
    cache_raid_invitation(
        leader_guid,
        leader_name,
        (uint16)leader_level,
        operate_key,
        invite_group_key
    );
    show_text("TDGZ_100809_44", leader_name);
    trigger_local_followup(2);
    notify_ui_refresh_if_needed();
    return 2;
}

Lua:Raid::GetInvitationByIdx(idx) -> return leader_name, leader_level
Lua:SendAgreeRaidInvitation(idx)  -> send CGRaidRetInvite(1, leader_guid, operate_key)
Lua:SendRejectRaidInvitation(idx) -> send CGRaidRetInvite(0, leader_guid, operate_key)

结论

1. GCRaidAskInvite(1228) 是一条固定 46 字节的团队邀请提示包，不是直接入团结果包。
2. 当前 Game.exe 与现役 Lua 都能确认它至少稳定携带团长 GUID、团长名字、区服字段、团长等级以及一组邀请回复尾字段。
3. 当前客户端收到后，会先把邀请写入本地缓存，再弹出团队邀请提示，并等待后续 CGRaidRetInvite 回复。
4. leader_level 与 operate_key 的客户端用途已经可以坐实：前者用于邀请列表展示，后者会在同意/拒绝时原样回传。
5. 现役 Lua 世界服当前只实际填写前四个字段，尾部 invite_group_key 与 operate_key 固定为 0；现役服务端对 CGRaidRetInvite 的第三个字段也未使用。