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