惊现：moveTo的bug--100%完美复现，有测试脚本@官方大大

Creator 2.x
#1

  • Creator 版本： V2.13

  • 重现方式：有测试脚本
    Test.rar (832 字节)

  • 重现概率： 100%

image.png930×957 365 KB

测试脚本截图如上，对一个节点做两次 moveTo ，如果按moveTo的理解，最终移动的坐标应该为设置的目标节点。
当设置 moveTime为 0.2s时，移动位置正常
当moveTime为0.5s时，移动位置超过。

追了一下moveTo的逻辑，看它实际上还是继承 moveBy，而moveBy继承 ActionInterval，
ActionInterval判断动作是否结束，用的时间，从而导致 有上述问题。

但是 为什么时间 分别为 moveTime分别为 0.2 和 0.5s时 ，执行的结果不一致，这个暂时还不明白，
希望官方帮我看看

#2

就不该对同一个节点同时调用两个moveTo，假设一个moveTo让他朝左，另一个让他朝右，他们时序上有重叠，你说他该朝左还是朝右？
脚本得先看逻辑上通不通，再来看引擎做的对不对

#3

惊现：发现了一条2010年的老旧BUG:slightly_smiling:

#4

move就是 update， 一帧的时间多少会不一样，建议move后加cc.place就好了

#5

谁都知道的就没必要回了，我知道不应该给同一个节点两次moveTo，但我好奇的是为什么 第二个动作延时0.2s和0.5s的时候，结果为什么不同，虽然大概也知道为什么。另外一个是moveTo的实现总觉得有点怪怪的

#7

嗯好的 ，我先试试哈

#8

这写得这叫啥玩意儿

#9

node.x 都值都变化了 结果怎么可能一样

#10

你每次只能看到一帧，渲染机制会合并计算位置，所以问题出在你自己身上。代码就不能这么写，写得这叫神马玩意儿。

#11

你没发现正常的0.2这个值跟你scheduleOnce的延迟时间一样吗？你看了源码就没发现moveBy和moveTo的起始点都是在startWithTarget设置的吗？给你理一下执行顺序：

  1. node.y = 50 y为50
  2. 第二个action先启动，delayTime 0.5之后，调用moveTo的startWithTarget, 动作效果为y值从50到0
  3. 第一个action后启动，延迟0.2+0.5后，调用moveTo的startWithTarget，假如moveTime为0.5，这时第一个动作的效果生效0.2秒了，当前y值应该是30，会增加一个0.5秒y从30到0的效果；如果是moveTime是0.2，y已经是0了，这个action为0.2秒从0到0，所以你看到移动位置正常。

问问题没关系，再简单也没人说你，大家反感的是你标题，神马惊现，神马@官方，新闻看多中毒了吧，想搞技术就踏踏实实的少整这些花里胡哨的

#12

嗯 谢谢啦，我想的跟你差不多。

标题惊悚是为了吸引大神关注，目的达到了。我就是觉得moveTo现在的实现有点问题，因为按api最直观的理解，moveTo就是移动到一个目标位置，不管moveTo的方向是啥，谁移动的最慢，就移动到谁的位置，现在的表现，不符合这种直接的理解。

其次，我写这种乱七八糟的测试，就是为了不按照“理应如此” 来做的，来看下是否能够达到最初的预期，顺便学习下官方的实现。

所以上面瞄一眼就来喷的，我也懒的去回复了。认真回复的我都会说声谢谢

#13

你说的对，但其实 我就是觉得官方的实现有问题