这个方法的最大弊端其实是所有凡是牵扯到场景物碰撞或dynamic效果的飞行做法都会遇到的一个bug，如果你不仔细处理细节是不可避免的。你们应该见过有人用编辑模式把工程车撤掉，站在上面的人掉不下来的情况吧。人在空中停滞和缓缓移动时，这时候终止飞行产生自由落体的状态瞬间，脚下会生成一种编辑模式看不见的空气墙，像一种虚拟的地面，是你甚至不能通过高度检测判断你是否悬空，只能通过检测强制ai挪开，但这样系统才仅仅概率性清除这个虚拟地面碰撞，并且对ai的agent高概率容易出现，一旦出现这个，就会影响你对飞行终止执行下落的判断，人直接锁死高空点，哪怕你用的是dynamic法。而attach法出这种bug的概率最高，所以ai无论用哪种办法，都要加滞空bug的检测修复代码。然后玩家比较特殊，出现这种情况比较少，因为玩家的行为比较复杂多变，特高的高空偶尔卡住时，自己来回身体旋转蹭蹭就摆脱这个锁人的空气碰撞bug了，所以玩家可以随便使用各种飞行做法没有顾虑。
然后这种bug还有一个升级版，就是如果你在一个带斜面的建筑物碰撞上终止飞行下落时触发此bug，有概率形成的不是滞空bug了，而是无限升空bug，人一直垂直上天，这时候你哪怕检测到这人有bug你都动不了他去修正。
所以超越战团本身机制的功能，不会尽善尽美，一步到位，常常需要修补各种暴露的弊端，所以诸君注意取舍和不滥用。


最后是关于碰撞是否会跳出以及对性能的影响问题。
首先对于简单的物体就像我这种单纯的六面体形状的prop animate比attach性能影响大(但是attach人的碰撞如果奇形怪状过于复杂，以至于会让agent骨骼动作产生肢体晃动的过程中和这个碰撞频繁乱七八糟的挤压，这种情况就反过来了)。其次hitbox和collision只要不频繁反复摩擦，产生与人相对位置的频繁改变，是不容易跳出的，attach控好频率一定时间间隔保持一定相对位置即可。最后不用飞时取消碰撞也可以缓解对性能影响，已在百人战场应用多场战斗了，稳定性可以。不过呢代码不是分割的东西，还是要看你其他代码的配合，有的时候两块代码本身没有问题，你合在一起可能就有些奇怪的问题，这个就要你们自己判断了。

来自: iPhone客户端