我们先构建一个简单场景:
问题1:怎么让source只产生一个Cube,而不用连续产生?
如果我们选择Source的Active为Never,即不激活这个组件。
你会发现播放后, Cube直接落下穿透了地板。
如果你把Mu的Active置为Never,发现一切正常,难道Mu是多余的?
在game4automation的组件中,Active属性用于控制组件的行为或状态,特别是在自动化测试或游戏自动化脚本中。 这个属性决定了组件何时应该被激活或参与自动化流程。下面是每个选项的解释: Always: 这个选项意味着组件将始终被激活,无论上下文或条件如何。 在自动化流程中,无论其他条件如何变化,该组件都会持续运行或参与。 Connected: 当选择这个选项时,组件的激活状态依赖于它与另一个组件或系统的连接状态。 如果组件成功连接到指定的目标(如另一个设备、服务或模块),则它会被激活。这通常用于需要确保连接建立后才执行操作的场景。 Disconnected: 与Connected相反,这个选项表示当组件与另一个组件或系统的连接断开时,它会被激活。 这可以用于处理断开连接时的特定逻辑,比如重试连接、发送警报或执行清理操作。 Never: 选择这个选项时,组件将永远不会被激活。无论自动化流程的其他部分如何运行, 这个组件都不会参与或执行任何操作。这可以用于禁用某些不再需要的组件。 Dont Change: 这个选项意味着保持组件当前的激活状态不变。如果组件当前是激活的,它将保持激活状态; 如果当前是未激活的,它将保持未激活状态。 这个选项通常用于避免在自动化脚本的某个部分意外更改组件的激活状态。
我们试下把Mu组件删除掉,再次运行,发现真的一切正常。但是你会发现在模拟状态下(即播放状态)Mu脚本会自动产生一个。
原来Source会自动产生MU,如果你没有MU的话。
如果是自己定义了MU,那就以你的MU参数为准。
如果你没有定义MU,在播放后,Source会产生默认参数的MU,这个时候如果想设置MU的参数就只能使用代码来进行了。
现在终于明白这啥MU的图标为啥是个淡色的星了,原来是指它是后台动作的组件,你可以选择不关注它。
因此解决这个问题,只用看Source的属性即可。
经过研究,发现关闭Automatic Generation即可。
这个勾选后,后面的Generate if Distance:300 指的是按300距离后自动产生第二个MU对象。
因此关闭Automatic Generation后就不会再自动产生MU对象了。
问题2:用来做MU的那个Cube2一定要加Rigidbody吗?
我们删除掉Rigidbody后,发现一切正常。
如果没有Rigidbody,那就无法应用物理效果。但是实验证明有了Source后,就不用加Rigidbody。
我们在Source中发现有一个属性,Mass质量,这个本是Rigidbody的一个属性,现在包含在了Source中了。
所以我们可以认为Source自动生成的那些MU对象,会自动包含Rigidbody组件。
我们实验一下,以印证上面的想法。
我们播放后,选择Source自动生成的一个MU对象,如下图的Cube2-1。
看到它的属性面板中,果然自动添加了一个MU和一个Rigidbody组件。
可见,我们的猜想是正确的。
问题3:做为拉带的那个Cube非要添加Rigidbody吗?
是的。经过实验,如果没有Rigidbody,将运行异常。
这是因为播放后game4automation会修改Rigidbody的一些属性,以迎合Transport surface组件的需要。
这是播放前的Rigidbody属性
这是播放后,可以看到game4automation修改了User Gravity和Is Kinematic。
取消了Use Gravity,就是不受重力影响,因此做为拉带的Cube就不会落到地板上去。
勾选了Is Kinematci,就是取消了牛顿力学的计算,只使用运动学。
下面是详细解释:
可以这么说,在Unity的物理引擎中,对于Rigidbody组件, Is Kinematic属性确实是在牛顿物理定理(即完全由物理引擎控制的物理行为) 和一种更简化的、由开发者控制的运动学模式之间进行选择的开关。 当Is Kinematic未勾选(false)时,Rigidbody将遵循牛顿物理定理, 受到重力、碰撞力、摩擦力等物理力的影响,并根据这些力进行自然的物理运动。 当Is Kinematic勾选(true)时,Rigidbody将不再遵循牛顿物理定理的严格约束。 它不会因物理力而产生自然的运动,但开发者仍然可以通过代码来控制其移动和旋转。 此外,虽然物体本身不会因碰撞力产生物理上的位移或旋转,但它仍然可以检测碰撞事件,并根据需要做出响应。 因此,在Unity中,对于Rigidbody组件,开发者需要在牛顿物理定理的运动模式和运动学模式之间做出选择, 以根据游戏需求实现合适的物理行为。 需要注意的是,这两种模式并不是完全互斥的,因为即使物体被设置为运动学模式, 它仍然可以受到一些物理效果的影响(例如,可以通过代码应用力或扭矩来模拟物理行为), 但这些效果将不会通过物理引擎的自然计算来产生。

