这总是让我烦恼，所以我通常只是忽略它，但这次它促使我问这个问题......
我正在使用代表队列的路径为排队获取资源的代理设置动画。我有一个 moveTo 块，可以将我的代理移动到位于队列前面的节点。当队列为空并且有代理到达接受服务时，它看起来很棒，因为代理移动到队列路径的末端，并沿着路径平稳地前进到节点所在的队列的前面。
但是，如果队列中有多个代理，则新代理将移动到队列路径并一直移动到队列的前面（节点所在的位置），然后跳回到队列路径上的正确位置。
如果我将节点放在队列的后端，那么当代理到达时动画看起来很棒，因为他们在其他已经在那里的人后面加入队列，但是当队列前面的代理抓住他们正在等待的资源时它跳到队列的后面，然后沿着队列前进到资源节点。
关于如何让它正确动画的任何想法？
【问题讨论】：
您可以简单地使用 Conveyor 块来表示“移动”队列（具有一些特定配置），但值得考虑更广泛的情况（这也有助于理解为什么尝试将 MoveTo 块添加到服务它沿路径的队列无法实现您想要的）。
流程模型可以包括与模型相关的空间性，其中移动时间很重要。 （与 MoveTo 块一样，RackPick/Store 和 Service 块等带有“发送占用的资源”检查的块隐含地包括移动。）但是，通常您不会：队列沿路径的 Service 块正在使用path just 来提供队列的一些可视化表示。在底层模型中，代理从上游块立即到达队列，并在资源空闲时立即进入延迟——这就是模型的过程抽象。因此，尝试使用先前的 MoveTo 块或类似块来“修复动画”将不起作用，因为服务块不不应该代表其队列的这种概念（因此代理将“弹回”到您观察到的潜在行为的现实）。此外，“适当的动画队列”会掩盖模型的底层基础（看起来好像该运动正在被显式建模，但实际上并非如此）。
Conveyor 在概念上确实捕获了必须保持一定距离的代理，并且（对于累积的传送带）明确地模拟了在有空闲空间时移动的代理。因此，虽然这看起来有悖常理，但这实际上是对移动的人类队列的“正确”详细概念化（当然也与实际的传送带相匹配）。
要使其按您的意愿工作，您需要调整代理的大小（仅从传送带的角度来看），以便您的队列（现在是传送带）中只有所需数量的人员，并使用以下内容服务块只有容量为 1 的队列（因此仅代表“队列前面的人”）——服务块不能有容量为 0 的队列。您可以使用点节点作为此单入口队列的位置，该位置刚好超出传送带路径的末端（因此这有效地表示队列中的第一个位置）- 见下文。
然后您希望传送带上的代理长度代表您的“队列槽长度”，这需要指定队列容量（在我的示例中是一个变量），所以类似于
path.length(METER) / (queueCapacity - 1)
path 是您的传送带路径。 （传送带代表除第一个之外的所有队列“槽”，因此我们在上面减去 1。）
您还可以将所有这些封装为自定义 ServiceWithMovingQueue 块或类似的。
请注意，如果传送带没有空间容纳到达的代理（即“概念队列”已满），则需要传送带之前的队列。如果你想变得特别现实，你必须决定现实生活中发生的事情并明确建模（例如，溢出队列、代理离开等）。
附：另一种选择是使用 Pedestrian 库，其中带有线条空间标记的服务旨在对此进行建模：下面的部分示例流程。但是，这意味着将您的代理切换为行人（参与行人建模基础物理模型以进行运动）并再次返回，这是性能密集型的（并且由于物理原因，在某些情况下可能会导致一些奇怪的运动）。另外，由于行人图书馆没有明确的行人服务资源概念，因此您必须做一些事情，例如让资源池容量变化影响哪些服务点是否开放。 （带有 Lines 标记的 Service 中的服务点具有 setSuspended 之类的功能，因此您可以将它们动态设置为“打开”或“关闭”，在这种情况下，与资源是否在轮班工作有关。）
附言请注意，从建模精度的角度来看，捕捉人类队列中的“真实”运动通常是无关紧要的，因为
如果队列为空，则与服务时间相比，从末端移动到前端的时间通常可以忽略不计（即使不可忽略，通常存在队列的服务也意味着这种额外的移动只是相关的对于一小部分到达者——见下文）。
如果队列不是空的，人们会在为其他人服务的同时向上移动，这样就不会延迟服务（在与某人结束后总是可以“立即”接受下一个人，因为他们已经在前面队列）。
【讨论】：
这不能用流程建模库的现有块来解决。
不过，如果你使用行人库，就不会出现这个问题，如果动画那么重要，也许你可以考虑使用它，但代价是你的模型的处理速度
实际做到这一点的唯一其他方法是创建自己的基于代理的模型来处理队列中代理的行为，但这并不是很直接。
现在，如果您考虑操作时间，如果代理像它一样移动或移动到行尾，则流程统计没有区别，因此就结果而言，您不必担心关于它
【讨论】：