已正式发布 -【Cocos Creator 3.8.2 社区公测帖】

3.8.2了,原生Android还是无法得到可读的unhandledrejection信息。
image

Android打印的日志如下:
image
其中有一句:

  • [0]method@assets/main/index.js:308

我兴高采烈地打开index.js,找到308行,开心的准备修复我的错误:
image

(???)老板,你听我狡辩,真不是我不想修复,实在是没找到哪里错啊!

============================================================================
这个功能没有的话,一个引擎如何能用于大项目的生产,总不能要求团队内每个程序员都不能写bug吧,我们招不到这样的人啊,求介绍 :sob:

3赞

大家新年好,我再来催一催引擎组的bug修复。
https://forum.cocos.org/t/topic/153206/9
https://forum.cocos.org/t/topic/153656/9
https://forum.cocos.org/t/topic/154597

有开sourcemaps吗?
另外,script-backup里面,慢慢找,也能找到一定的提示

3.8.2版本,bug满天飞啊,赶紧又换回3.8.1,到底改了那些bug :crazy_face:

有的,而且sourcemap在这里也用不上。我打的debug包,也没选压缩脚本。
427e670f0e907d65421cceb2d533d8b

原回复中的第三张图,其实就是script-backup里面的index.js,如果不是debug版本,这里面还会压缩成一行,那种情况下,cocos 日志中只有行号,就更不可读。我修改C++代码,强制返回列号,但是也没用,因为其获取的是unhandled rejection 当前promise的上下文,所以列号指向的是该函数的结尾,而不是错误的具体地方。

====================================================================
不过我相信官方是不会管这个问题,从使用cocos开始,2.x 到现在的 3.x。5年了,都没任何变更,我已经打算在我每一个promise后面加上catch了 :sob:

promise 看起来美好,用起来问题还是有的比如在回调里面还得小心节点是不是已经被销毁了,要动态销毁跳出某个promise也不好弄,反正我是自己封装一个组件来处理异步需求

这个确实。
只是引擎应该提供好这种捕捉错误的基础设施,例如,
浏览器中的:
windows.onunhandledrejection
微信中的:
wx.onUnhandledRejection
NodeJs中的:
process.on(“unhandledRejection”, callbackfunction)

  • 升级 ASTC 工具到 4.6.0
    这一段。arm的astc工具,每次升级之后,输出的文件都是不同的(改进了压缩算法)。但是对于热更包来说,重新压缩的同样文件内容改变后,会导致热更比对失效。
    这块咱们这边是有什么机制来解决吗?

目前这块确实没有特别好的方式,因为对需要升级的用户来说,他们需要的就是新的输出的这份改进后算法的 astc ,这种情况重新下载本来就是符合预期的,何况文件确实变化了,这不正是 md5 hash 添加的意义所在吗?有人要升级有人不要,本身就没办法两全,只要不会造成 bug 新版本的编辑器会优先选择更新的方式。当然尽量减少不必要的升级,这次的升级也是有用户反馈确认后才升级的。

所以如果你不想升级 astc 但又希望使用最新版本的编辑器,目前最简单的就是自己替换编辑器安装包内 astc 压缩工具(在{Editor}/resources/tools/astc-encoder 内)或者说通过项目设置的自定义格式去配置使用一个项目自用稳定的 astc 工具,保障编辑器的任何升级都不影响你使用旧的 astc 。

当然如果您有其他的想法建议也可以告知我们。

1赞

还有新版本吗,还是要发正式版了?

:thinking:后续版本节奏会改成一年一个主版本,n个bug修复版本吗,感觉这样可以平衡功能和质量&性能?

请问一下我3.7.4项目升级3.81,为啥那些spine都失效了~·重新拖入都没用,就是显示不出来?

Unity 之前不就是这样吗?后来自己也扛不住了,本来一年 4 个小版本,变成 3 个,到最后过完年上一年的稳定版都出不来。最近干脆摆烂了,大版本不用 20xx 命名了

确实很难平衡。。。是个需要综合考虑的难题

3.8.2版本打包web手机端,构建出来的代码没有进行es5的转换和对globalThis的支持,导致在低版本的浏览器内核中不兼容。之前使用3.8.0是没有这个问题的

啥时候发布啊

咱们还是别用年份命名,现在unity的版本感觉怪怪的

建议把缓存清掉,如library, temp等,然后用381或382重新打开验证。380后统一用了wasm的方案

这个主要是因为 node 升级到 18 后,web 机型覆盖的数据库 module ( caniuse-lite )被升级了导致。
目前构建脚本的时候,web 平台上是写死 >= 0.5% 这个覆盖率,因为 caniuse-lite 数据库升级了,之前在这个范围内的设备,变成不在这个范围了。

我们把这个覆盖率(target)选项开放出来吧。默认 undefined,表示强制生成 polyfill,用户可以自己定义这个覆盖率。

另外,这个覆盖率其实是解决生成的 polyfill 大小的问题。如果不指定覆盖率,会导致生成的 polyfill 比较大。

感谢反馈,请问是否使用了自定义字体?是否可以提供可复现demo?