ccc3.4(111601)的bug和一些吐槽!!!!!!

3d 的框,下个版本会提供绘制能力,2d 碰撞体我们确认下

@liqiao 大佬
这个bug会在3.4修复吗???

大佬~复现了吗??? :cry:
@EndEvil


目前看下来是脚本修改父节点 然后子节点位置被物理计算改了回去,父节点在往前 子节点在往后,所以相对位置不动

啊。。。。
这是引擎的bug么??? :cry:

大佬
确认的怎么样了????
@EndEvil

目前看下来不能在脚本里面修改父节点的位置,只能修改物理节点本身

???
怎么会有这样的设计。。。???
一点都不灵活。。。
那我给移动的精灵添加一个碰撞框
还得分开设置坐标???
还得把碰撞框和精灵各自对应起来
are you kidding me ???

跟我们同学确认了下,你好像刚体上选择的是 static,可以换成 dynamic

大佬不行的啊
我现在就是需要这样属性的刚体啊
在2.x好像都可以这么搞的
3.x居然不行了。。
又开倒车?

为啥你们老是在这里又是rust又是go的推荐个不停啊。。。rust难道现在很适合游戏吗。。。

何止是适合游戏。。。。。几乎可以碾压所有的任何的历史语言,您是否还在为cocos的内存泄漏一直没解决而疑惑痛苦不堪?您是否还在为window的蓝屏而痛楚?那就赶紧用rust吧,他能帮你解决这些10多年都解决不了的问题,当然目前主要是生态不行,不然用的人估计遍布全球!只是时间问题而已,生态这种东西很虚的,很多东西你们不大懂,砸门就给你们科普,等你们反应过来的时候,可能都已经是大伙大热了。。。。吃不到第一个螃蟹。。。可以参考这个 我们玩游戏了吗? (arewegameyet.rs)

作为过来人还是奉劝兄弟一句,开源精神固然好,但是不要被部分开源社区的宗教分子给洗脑了,当初我何尝不是向你这么追go的,又说go能做android应用,又要go加泛型,用go做游戏的声音也不少,结果go现在不是也就那样了,rust别的不说,目前就没有一个在android和ios上可以稳定构建游戏的方案,这些需要额外的时间,go和rust都是目前为止只能活跃在应用服务器这个类型的项目上,即使rust做好了基础设施,那么编辑器各种其他工具呢?rust的所有类型指针C++都可以有,而且如果是针对游戏项目的话,一般都是贴图这类大内存对象的利用决定内存效率,需要看住的内存泄露的目标很少,那些逻辑对象直接用对象池一次分配完毕然后通过池来重复利用才是最佳方案,即使你用rust也是重复一样的事情

物理的问题验证过了,是个bug,更新场景树的时候node位置没有同步到子节点所属的物理component上,多谢反馈

:cry:
哪个版本可以修复这个bug???
下一个3.4的社区版?
还是不知道啥时候的3.5???

update里修改节点位置以后调用 PhysicsSystem2D.instance.physicsWorld.syncSceneToPhysics() 就行了

好的~~~~~~~

任何东西都是从无到有,现在也许没这个生态,但是也不是没人在这方面的努力,不是被开源社区洗脑,而是我比你更加清楚内存泄漏的痛楚,“即使你用rust也是重复一样的事情”,做的事情是一样的,但是rust几乎很难写出内存泄漏的代码,这就决定了做的事情一样,但是效果不一样,一个是怎么做都有内存泄漏,cocos就是一个典型的例子,试问哪个版本的编辑器没内存泄漏,但是如果用rust可以大大避免这种情况,何乐而不为,如果什么东西都是写好给你的,那谁来做第一个开始写生态的东西?对吧?目前rust做游戏引擎的开源产品并不少,也许还不够完备,但是它在这个领域是其他语言所毕不了的,奉劝你少过于依赖开源产品,从语言层面来解决内存并发安全bug才是最好的选择,而不是修来修去,最后发现10年了都修不好的内存bug竟然是编辑语言导致的

:sweat_smile:

不可否认rust的优点,但没必要在cc论坛里这么为rust引流,这是在败坏rust的路人缘。
而且rust我只能保持观望状态,真厉害就不会还是现在这样在游戏圈不温不火。