我测试发现原版游戏中的管道连接器最大流量是1200，而管道均衡器最大流量是1800。即使用了管道5，在有管道连接器的管路中，最大流量也会受限在1200。满容量3级熔融通道经过熔融连接器会更加明显地观测到这一现象。不知道能不能mod中修改原版游戏的连接器的最大流量。既然高等级存储罐都可以有更高流量，更改这一点应该也可以做到吧。您的众多mod做的非常好，中文coi社区需要您这样的人才。我平时搜攻略都上google的。我设计的工厂恰好都要用满五级的最大流量，困扰了我非常久为什么管道5跑不出最大性能，测了半天才发现问题。我可以暂时用一格占地均衡器mod（最大流量1800）解决此问题，但我认为本mod还是要在这方面做出改进。如果我测试结论有误，请原谅

感谢你的回复,你说的这个问题,很多人都有反映,但是我并没有在意,因为我专注于管道和传送带本身是否实现功能,而认为这是用户的自己的事.

通过你的解释,我彻底明白,这是一个配套的工作,属于整体的流程,不能光考虑管道,而应该考虑他的应用场景,这是系统性的物流体系,每个环节都可能影响性能.我测试都是用单条传送带或者管道来测试,没考虑实际输出功率.

我已经公布了一个多口mod,我将会结合一下两方面,仔细研究这个链接器产生的效率阻隔的问题.

wtmxhyy wrote:

感谢你的回复,你说的这个问题,很多人都有反映,但是我并没有在意,因为我专注于管道和传送带本身是否实现功能,而认为这是用户的自己的事.

通过你的解释,我彻底明白,这是一个配套的工作,属于整体的流程,不能光考虑管道,而应该考虑他的应用场景,这是系统性的物流体系,每个环节都可能影响性能.我测试都是用单条传送带或者管道来测试,没考虑实际输出功率.

我已经公布了一个多口mod,我将会结合一下两方面,仔细研究这个链接器产生的效率阻隔的问题.

感谢您的付出与迅速回复。有管路必有连接器，而单输出口对单输入口还需要5级的流量更是罕见。我认为只有去替换原版连接器的吞吐量才算是无痛解决此问题。如果不能替换原版而是提供更大吞吐量的连接器，就意味着每个超限的连接器（mod1x1均衡器）都要手动另外放置，那还不如把现有的多口Mod集成进本mod来的方便。手动放置需要额外的计算规划量以及操作量，但我觉得问题不大

1. 关键一个节点问题是3/tick,这是一个不可变,只读参数!他严格锁死了所有上限.突破他太难,我废了很多时间绕过他实现了3600吞吐的传送带,然而也很难避免各种bug出现.

   一个根本缘故就是每次都要检测一个系统设定,每秒发送量和MAX_TRANSFER_PER_TICK = 3 的限制导致每次传输操作只能移动少量产品，对于高吞吐量的传送带，需要更多的传输操作，从而增加了延迟和吞吐量损失。

   用反射,劫持,等手段无法有效干涉,因为他不是存在一次,而是每次每帧调度都会用到.牵一发而动全身.

   传送带和管道是一个基础的微积分阶差算法,被简化为乘法倍率来作为升级参数.可不变的是受控条件.他们都被系统设定给锁定,因为只读属性.

   MAX_TRANSFER_PER_TICK = 3 的限制导致每次传输操作只能移动少量产品，对于高吞吐量的传送带，需要更多的传输操作，从而增加了延迟和吞吐量损失。
   如果动了他,那么整个需要这个参数的计算全都要推倒重来!这将会造成其他不可控因素爆发.
   如果不动他,根本无法修改任何相关的设定,
   
   MAX_TRANSFER_PER_TICK 是 readonly 字段，在静态构造函数中初始化。当代码被 JIT 编译时，CLR 可能会将这个 readonly 字段的值 内联到使用它的代码中 。这意味着即使通过反射修改了字段的值，已经编译的代码仍然会使用旧的值。

2. 算了不说技术问题了,我努力解决这个问题.看看还有什么办法能够平衡解决.

我已经更新了版本,你现在再次做测试,我需要一个详尽的测试,来综合评估补丁是否真实有效,从理论上看现在日志中显示应用补丁成功,而没有提示错误,剩下就是需要你通过实测数据肉眼观测,是否解决了问题.

我任何模拟都不能模拟出你的描述情况,毕竟你是实际用户,具体实际运行要大规模链接来查看.辛苦了.有消息告诉我.😝

昨天没开游戏，感谢您的光速更新，我刚刚测试发现您已经把游戏自带管道连接器的最大流量修到了3600以上，完全解决了问题。我认为我的描述情况非常之简单。游戏里没有月生产1800的机器一对一供应给月消耗1800的机器，所以用的到1800流量的管道的管路必然包含连接器，那就必然被连接器限速1200。这个问题一定会存在，与工厂设计无关。我认为只要能准确测量一定时间的转运量，就可以随意复现。实际中我一个生产1800废气的冶炼厂一直有三分之一的机器废气输出已满停工，我才探究此问题的。在老版本中，四级存储罐-五级管道-四级存储罐这一结构月转运量1800（观察到每tick转运量3）；但四级存储罐-五级管道-管道连接器-五级管道-四级存储罐这一结构月转运量仅有1200（每tick转运量3）。在新版本中，四级存储罐-五级管道-管道连接器-五级管道-四级存储罐这一结构能实现月1800的转运量；四级存储罐-两条五级管道-管道连接器-两条五级管道-四级存储罐这一结构能实现月3600的转运量（观察到每tick转运量6）；四级存储罐-管道连接器-三条五级管道-四级存储罐这一结构的月转运量仍然保持在月3600（观察到每tick转运量9）。每tick转运量上升了但月转运量没有上升是因为四级存储罐的最大流量就是3600。而四级存储罐-管道连接器-四级存储罐这一结构每tick转运量达到了24，所以我推测您修改mod后，管道连接器的最大流量来到了14400。用cheat的“保持空”功能即可观察到每tick转运量（结合您给出的数据我推测的）。我目前用storage无法把存储罐流量修改到3600以上，只能减不能超过，所以没有更好的测试。但是减少存储罐的流量则每tick转运量也会等比例减少。所以我认为14400是可信的。即使没到这么大的数字，我也认为本次补丁非常之完善。（除了熔融连接器这个重量级，我观测到熔融连接器的吞吐量只有120，和熔融管道相同，可以说二三级熔融管道没有任何用处。新版本仍是如此。）

1,对你的测试反馈表示感谢.
2,我有一个mod叫做机器超频mod,你可以试试,通过超频一个机器可以达到1600.在以前版本曾经达到几千几万的产能,但是我做了更新,确保数字不爆炸做了限定.如果以铁熔融来计算最高级别他可以做到686
这设定是为了安全,以前都是好几千产量的.但是为了符合游戏设定规则而进行了重构,降低产能了.
通过他,我测试出熔融管道的确没有提升吞吐.管道的吞吐确实没有被修改. 我将会检查这一部分.

熔融的速度现在还处于瓶颈.

IoPort.GetMaxThroughputPerTick 对于非Transport实体返回 MAX_TRANSFER_PER_TICK = 3。

对于熔融通道：

• ThroughputPerTick = 2/sec / 60 ticks/sec = 1/30 tick ≈ 0.033/tick
  这个值远小于3，所以 MAX_TRANSFER_PER_TICK = 3 不会限制熔融通道。

但"熔融连接器的吞吐量只有120"。120/min = 2/sec。这正是熔融通道的吞吐量。
但对于连接到熔融通道的端口，GetMaxThroughputPerTick 返回的是熔融通道的ThroughputPerTick ，不是 3。

T1: 1/30 ≈ 0.033
T2: 2/30 ≈ 0.067
T3: 3/30 = 0.1

这些值都不等于 3，所以我的 patch 不会修改它们

也就是平板和u型用了一个代码控制,而熔融用了一个代码控制,水管用了另一个代码控制.

😝真是混乱的一塌糊涂啊.

我架设了测试场景,一条熔融,链接3个连接器,分别观测,时间变动,流量变动,动画变动,数值变动.
然后,加入了每一帧调试代码,运行几十秒,日志爆了90m.🥵

我看到了控制代码,这是Transport.cs:1218里面的一句,实际接收数量 = Min(产品限制, 传送带限制) = Min(1, 2) = 1

Mafi.Core.Prototypes.InvalidProtoException: Transport 'MoltenMetalChannelT2' speed '0.1992188' must divide products spacing '0.5' exactly (2.509766 vs 3 has delta 0.4902344).
你看修改后,系统报错,通过报错提示,运输设备 MoltenMetalChannelT2 速度 0.1992188 必须能被产品间距 0.5 整除 计算商值：2.509766，理论要求整数3，差值 0.4902344 不匹配

系统要求能够整除算法.

这就是fix32的精度问题,在数学中,fix32最容易出现无法整除\(v = \frac{65536},\quad k\in\mathbb\)

所以,我的质因子2有问题.我们是十进制算法,那么就会产生斐波那契数,底层3.5.7这种的额外的质因子.

这是第一次玩游戏要自带计算器,手边一边打代码,一边按计算器,太美观了!🤧这个游戏会逼疯我的数学老师.

太变态了😵您真是疯狂的程序员啊

786216376 wrote:

太变态了😵您真是疯狂的程序员啊

至少你的建议解决了.熔融的问题已经更新,你测试一下.