cocos 2dx 3.16的bug，就没pr的必要了吧

也可以把修改片段发到这里，主要我感觉可能 creator 搞不好也有

这样问就很尴尬了… 至少CCC 2.2.1吧，我需要碰撞时遍历玩家的顺序要严格按照“加入顺序”来保证确定性，那自带的碰撞系统如果本来就是这么做的或者有钩子改成这样就最好，但实际上是没有，起码我就可以下这个判断：这事要自己来并且不算浪费时间 – 虽然这好像不怎么值得说… 其他的也包括看了你们update怎么写的，决定在过快过慢的判断上自己能最少只新增多少代码这样的小点，确保每一个要确定性的地方我都知道来龙去脉。

“卡点”既有阻碍点也有真的卡顿，单说结果就是我曾经怀疑是因为CCC渲染性能问题的地方最后都证实是我自己的问题，导致多看了不少动画渲染那部分的代码 （实际上并不开心也并不高效，氧化钙） – 这种就属于我不看你源码能不能做出来吧，不好说，但看了能确信问题不在那里是很重要的，假如是Unity可能这种情况下就会陷入赖引擎的惰性思维了，或者找不到怀疑自己的有力依据

明白了，网络同步的确定性问题，确实在引擎中考虑的不多

这个没所谓的，我考虑过其他引擎，并不会更好做，我更看重的是“能快速准确地判断怎么做是最低成本的”这个好处，复杂的核心算法写多反而容易错

引擎开源能提供更多的可能性，遇到问题的时候可以追本溯源，找到问题的出错点，闭源的话就只能瞎猜了，运气好能猜到，运气不好就变成无头公案了，然后开源后扩展也比较方便，你可以很方便的扩展你想要的功能，比方你可以修改节点渲染顺序，扩展动态合图，修改文字渲染，增加视频音频播放器，增加wasm等等功能来解决特点游戏特点方向的性能优化问题，能检测的手段也更多，优化的方向提供了更多的可能性
扩展引擎现有功能，不用等引擎下个版本发布就自己合pr或者自己改修复线上bug，或者想要新的功能又不想升级版本的时候可以在现有版本基础上合入新的pr，出了问题也可以自己查，不需要等官方遥遥无期的排期而一筹莫展，实在不行crash了搞点骚操作直接绕过，对代码和研发周期的掌控性更强，引擎开源情况下也不用担心给你植入有些意想不到的代码，植入了也可以删。
然后针对某些特点平台的优化就更明显了，引擎为了跨平台的兼容性，有些方案的选择会倾向于兼容性，性能比较中庸，但是对于特定开发者来说，可能需要某个平台的性能最大化，如果闭源的情况下就很抓瞎了

ScrollView、InputEditor
在友商（U）上基本难以在原基础上定制非常“高级”的功能
不仅仅是成员、函数私有，甚至还有Cpp / jni之类的更底层代码完全无法查看
只能直接重新写一个类似的出来

开源的话，就不用说了，js hack code结合继承能解决不少问题，
如果还不行直接看代码->修改
对于其他协作开发来说，只要不是破坏接口的修改，基本完全无感，不需要额外的学习成本

PR最近两天提交了两个
主要是对tiled map的问题进行修复
主要考虑到能将这些问题的修复推给你们，减少项目组其他成员定制引擎的步骤也是好的

开源肯定是引擎选择考量之一
不说别的，
升级引擎对于我们来说特别是国内需要“热更”快速解决问题的环境来说，成本巨大，也等不起

以前在微信使用websocket 掉帧很厉害，不知有没有修复

1.引擎本身的问题我们能直接修改，提高了工作时候的效率
2.很多时候，是通过学习引擎代码来提高自己的。
3.以前做RMXP这些小玩意的时候，很多效果不好实现，无从下手，到cocos这里后，没有不行的，不行就是你不行。反正就改，各种魔改
4.知道你们是不是在偷懒，后面的版本会改写啥

太真实了！

1. 开源的好处就是可以看源码，引擎的逻辑能够一览无余，当你在遇到问题的时候不仅仅有一味地求爷爷告奶奶这种选择，可以选择自己阅读引擎源码、修改源码解决自己的问题。
2. 以下我的实际经历：
   项目需求需要实现子游戏大厅功能，通过bundle方式确实能实现部分，并且很好实现，但是有个问题资源可以热更，但是脚本不行。于是去翻引擎源码，找到js加载注册的地方，并进行了修改，重复加载脚本的问题就解决了。但是加载bundle并不会重复加载同样的index，看了引擎源码，加载bundle的地方，发现是可以手动传入版本的方式进行重新加载，于是我通过修改热更工具在生成的逻辑，在config、index打上热更版本的标签，这样一个完整的子游戏大厅的工具就产生了，目前已用在公司多款商业项目中。
3. 首先感谢引擎组吧，虽然引擎有bug，但是开源啊，而且引擎组也有很积极的解决
   感谢论坛大佬测试出的脚本不能热更的bug，第一次做插件确实有些草率了。
   也感谢各位对插件的支持，以及信任

欢迎来到cocos大型黑粉炸帖

我说说我碰到的问题吧。都是通过魔改引擎去实现的。

2.4.0没有支持astc，引擎后续版本也没支持，一直到3.x才支持的。我自己按照3.x实现了astc。质的飞跃。但是2.4.0的编辑器不支持直接打包出astc纹理，后面只能写脚本，自动化处理。

在做2.4.0支持bundle压缩包热更/普通对比文件下载热更2种方法的时候，第一个问题就碰到了用cocos的下载接口在安卓那边处理不合理，用的是 callTimeout 意味着整个函数调用超过10秒就会导致下载失败。但是大文件，10秒钟下不完的，后面改成了 connectTimeout writeTimeout readTimeout 3种方式去判断是否超时。cocos在这里就没有做好处理。

后面有碰到了2.4.0不支持紧挨在安卓可写路径下的文件，按照2.4.3的模板又魔改了一次。

分包之后，因为需要支持压缩热更，最开始解压逻辑是放在安卓处理的。后面因为游戏文件大了，差不多有100M以上了，这个时候，在一些比较垃圾的安卓手机解压很慢，差不多需要将近20s。后面把安卓解压改成了c++解压，效率飙升，只需3-5s。不过这个时候产生了几个问题，c++解压会阻塞UI线程，安卓解压放到了UI线程，虽然慢，但是能刷新UI。 还有个就是引擎的 ZipUtils 这个类，明确的引用zlib。为啥不加个压缩方法暴露出来呢。还得用户自己处理。

说回来，开源最大的好处就是方便大家自己动手，有啥问题自己能解决的就提前解决了。
cocos能发展到这么大，开源功不可没。但凡是闭源的，BUG这么多，用户早跑了。实话实说

不管是开源还是闭源， 首先要把基本的功能做好，然后再加其它功能，不要一些基础问题，很多版本都不管。 做的好，哪怕收费都愿意用。

感觉 Cocos 2.x 的那个 cc.d.ts 的方式挺好的, 请问 Cocos 3.x 后续会弄类似这个的功能吗 ?

Cocos 的引擎开源很赞

因为可以按照自己的想法添加一些功能, 提高效率

另外, 确定性物理引擎(2D就行) , 请问有计划做吗 ?

如果是闭源引擎，只能依赖引擎足够完善，自身没有问题，使用者也不会遇到问题，不然遇到问题网上又没有解决方案的时候，真的就无力了。事实上没有问题的软件是不可能存在！
但是开源引擎就好多了，遇到问题可以随时去翻代码，浅层的代码写的很好，我这种小菜鸡阅读起来也没什么障碍

例子1

最近遇到的两个问题，都是网上找不到解决办法，最后去翻引擎代码搞定的

例子2

平时写代码的时候，遇到疑惑的地方，也可以去翻引擎来吃定心丸
比如自己写了个load函数，里面是getComponent(Sprite).spriteFrame = xx 。就会担心性能问题，要不要考虑判断一下是相同图片就不重新赋值，结果去翻代码发现引擎已经做好了

image698×182 15.4 KB

例子3

引擎的代码编写还是比较规范的，对于我这种小菜鸡来说，有样学样就可以把事情做好了
比如最开始接触ccc的时候，想获取坐标的时候都是node.getPosition()，也没有注意到引擎建议复用vec3。
后来在引擎代码里看到很多 这样子复用的

再比如之前需要在不能复用的tween里先设置节点坐标为0，那就会.set({position:new Vec3(0,0,0)}) ， 那其实写Vec3.ZERO就可以了，同样的还有类似Color.GREEN

例子4

可以编写更符合需求的自定义引擎
比如小游戏环境在裁剪包的同时，还会用到包内的一小块功能，那就自己去阉割
比如瓦片地图渲染裁剪可以优化为不同layer可以共享裁剪范围计算结果（论坛也已经有大神优雅的实现了）

之前做物理帧同步的时候遇到不同步的问题

一开始打印位置是完全相同 然后 玩了一会发现不同步 (因为这件事找了好久问题 甚至怀疑能不能这样做)
然后发现是因为 同一个场景 运行次数不一样结果也是不一样 之后定位到 重置场景时候物理系统其实不是初始状态 也就是 每个设备的物理系统的状态是不一样的

后面阅读源码 添加了一个清除物理的方法 每一次重置场景初始化新的物理系统 就没问题

只要你做帧同步 遇到重连 回来追帧 或者 关卡类 都会遇到

目前上线半年 并没有遇到不同步现象

官方可以加个重置物理的方法 (说不定很多人遇到这种现象以为是 浮点数什么的 我认为只要计算结果一致都是可以帧同步的 比如 1 + 1 = 1.9 所有设备算 1 + 1 = 1.9 那就没问题 只要有一个 = 2 那这个设备就不能帧同步 反正结果要确定性 就行 目前没有发现设备计算结果是有不一致的)

这是我自己的理解.

ios退出app导致的崩溃，有官方大佬带带嘛https://forum.cocos.org/t/topic/143275

大佬, 请问方便讲下您这个清除物理是怎么做的吗 ? 是要改引擎还是什么 ?