Jare Guo
非常抱歉给您带来不好的体验，我下面的回复，可能会让你觉得是在辩解。但是我个人认为还是对我们立场的澄清挺重要的，不论如何我们都希望积极沟通。 ### 先解答一下文档质量问题 目前的文档，传承自早期的 Creator 3D，Creator 3D 又有大量文档是参考 Creator 2.x 写出来的，在 3.0 发布时，我们对 2.x 新版本的文档和 Creator 3D 的文档进行了一次人工合并。由于来源、版本的混乱，确实质量比较差，有些地方都有疏漏。 我们之前专职维护文档的妹子（薰衣），长时间不堪重负，收到研发初稿后，需要自己跑一遍、发现 bug 后要反馈给开发者修复，然后重新截图，（你也知道开发版 bug 肯定很多），还要调整文章逻辑，美化排版，最后翻译成英文…… 所以文档质量一直比较糟糕。 从今年开始，我们将文档工作移交给了成都团队，目前由更加擅长技术的麒麟子领头，不断在进行重写，用更加偏向教程而非参考书的逻辑去优化，力求降低入门门槛的同时修复文档中的错误。 ### 你反馈的文档问题 前面那句话到是强调了深度检测目的是和 3D 物体遮挡，没提到能够修改...
还是要有，没有说要去掉喔
一直以来，用户构建时可以勾选是否要带上 AnySDK。
之前是凯乐做的，你们沟通下吧
引擎内部没有用到
那不然需要用什么方式来获得唯一标识呢？如果用了标识，如何不被谷歌降权呢？
The solution you proposed increases the project package size (runtime solution rather than editor solution) and introduces additional runtime overhead. So I'm a little concerned about the potential for abuse....
# 需求汇总 ## 进制转换：国标单位下的十进制、千进制、千分之一进制转换，便于输入（km/m/cm/mm...） > 想想用户在调一个魔性手指的位置，你喜欢在输入框输入0.0079m呢，还是 0.79cm呢 这里要解决的是好不好输入的问题，而不是能不能输入的问题。但是容易导致滥用，会带来两个潜在风险 1. 精度问题 小数点后面的精确有可能不够。一个 desiredUnit 是 km 的值，如果接收到一个 cm 的输入，精度在 32 位上很可能丢失。 例如 speed = 0.79(cm); this.x = 1(km); this.x += this.speed（此时精度出现丢失）。 当不支持进制转换时，用户只能输入...