测试留言没有显示玩家昵称

05/042 浏览
我:测试留言没有显示玩家昵称(没有昵称就显示玩家ID)
嗒:
现在我明白了。日志中的 [Lobby] Identity updated from server: nick_name=耳内有灰 说明 Lobby 系统在连接后异步收到了昵称。但 getPlayerNickname() 在 userId=0 时跳过了 _GetUserNickname 调用。
问题根源:预览环境 _lobby:GetMyUserId() 返回 0,而后面服务端通过 allData.yourUserId 告知了真实 ID。但 getPlayerNickname() 只在第一次调用时尝试拉取。
让我看看服务端告知 userId 后是否有机会重新拉取昵称
lobby 对象没有类型定义。那么换个思路——既然日志显示引擎在连接后确实拿到了 nick_name,而且 _GetUserNickname API 需要 userId,我可以从另一个角度解决:
当服务端通过 Client.myUserId 告知真实 userId 后,再次尝试拉取昵称
同时也尝试直接从 _lobby 读取 identity 中的 nick_name
让我看看 main.lua 中收到服务端同步后的处理逻辑
我看到了!当服务端同步完成后(WallClient.serverReady),main.lua 的 HandleUpdate 会用 Client.myUserId 来重建菜单。我可以在这个时机也重新触发昵称拉取。
现在重写 getPlayerNickname(),让它:
优先使用已缓存的昵称
尝试从 _lobby 读取(userId 可能不是 0)
使用 Client.myUserId 作为备选 userId
异步拉取成功后更新缓存
构建成功。修改总结:
问题根源:预览环境 _lobby:GetMyUserId() 返回 0,导致 getPlayerNickname() 跳过昵称拉取,直接用 "玩家" 兜底。
修复内容:
getPlayerNickname() 改用双源 userId — 先试 _lobby:GetMyUserId(),如果返回 0 则用 WallClient.myUserId(服务端告知的真实 ID)
提取 tryFetchNickname() 辅助函数 — 可在任何时机用有效 userId 发起异步昵称拉取,且自动去重不重复请求
HandleUpdate 中服务端同步后重新拉取 — 当 WallClient.serverReady 且拿到真实 myUserId > 0 时,如果当前昵称还是 "玩家" 或纯数字 ID,立即用真实 ID 重新拉取昵称
这样即使 userId 一开始是 0,等服务端同步后也能正确显示昵称。留言的 author 字段会存储拉取到的昵称(或 ID 作为兜底),并持久化到云端。
1