Kin Wang
Kin Wang
1. 毫无疑问，操作序列以 “服务端收到的” 为准（权威输入）。至于是服务端算结果，还是客户端算结果，都可以。因为操作序列一致，显然无论在哪边算结果都应当一致。 2. 对于 JavaScript 项目而言，如果网络有做加密并非抓包破解，而是基于源码层面的破解；那么程序化的外挂式提交输入，也不是什么复杂困难的事情吧。
目前可以通过 preRecvDataFlow 和 preSendDataFlow 来修改。 但目前这种方式有缺陷，就是会需要 JSON.parse 修改后再 JSON.stringify。 后续版本会增加相关的配置选项，可以先临时使用 Flow 过渡。
TSRPC 使用浏览器的 HTTP 和 WebSocket API，只要您的原生 JavaScript 环境，兼容这些 API，就可以正常使用。 目前，React Native、UniApp、Cocos Creator，都是兼容的。
Cocos 吗？`new WsClient` 时关注 `caUrl` 这个配置项。
Cocos Android 端需要传入证书
目前没有 C# LIbrary 的计划，有以下原因： 1. 工作量太大。相当于用 C# 再实现一个 RPC Client。 2. 跨语言场景下失去了 TypeScript 前后端一体化的优势，在此情况下，gRPC 已经是跨语言 RPC 的足够好的选择。 但是，如果你打算用 TypeScript 开发 Unity 游戏，例如 puerts 的方案，目前已经有开发者验证，可以完美兼容 TSRPC。
`pendingInputMsgs` 代表要向服务器提交的用户输入，而 `TimePast` 是服务器的输入，而非用户侧的输入，所以用户不需要提交 `TimePast` 给服务器，只是在本地预测服务器即将到来的 `TimePast`。
取决于 “浮点数的不确定性” 是否会累加放大。 对于物理引擎而言，绝对需要考虑。
当然，参考： https://tsrpc.cn/docs/flow/session-and-cookie.html Flow 本身是个 **异步** 函数，所以你当然可以从数据库里去恢复 Session 信息。