“产线基础和铝产线的初步展示”的版本间的差异
[未复核版本] | [已复核版本] |
1600627624(讨论 | 贡献) |
1600627624(讨论 | 贡献) |
||
第56行: | 第56行: | ||
我相信你肯定知道抽屉管理器已经抽屉等等好东西,他们是储存的非常优秀的方案,但是这里,我们运用一个非常好的性质就是,抽屉管理器有它的管辖范围,在这个范围内,会按照一定规则选取一个位置把输入物品塞进去。于是一直新的,特大规模的物流方案就产生了,可以通过溜槽漏斗等高速输入物品输入抽屉管理器,然后通过桥接方块和上锁的抽屉进行高效物流(产线之间的距离?不就是一个抽屉管理器吗)。 | 我相信你肯定知道抽屉管理器已经抽屉等等好东西,他们是储存的非常优秀的方案,但是这里,我们运用一个非常好的性质就是,抽屉管理器有它的管辖范围,在这个范围内,会按照一定规则选取一个位置把输入物品塞进去。于是一直新的,特大规模的物流方案就产生了,可以通过溜槽漏斗等高速输入物品输入抽屉管理器,然后通过桥接方块和上锁的抽屉进行高效物流(产线之间的距离?不就是一个抽屉管理器吗)。 | ||
[[文件:抽屉物流.png|无|缩略图]] | [[文件:抽屉物流.png|无|缩略图]]那么接着就是生产速度的问题,由于搅拌机这个离谱的设定体系,直接上原代码了: | ||
processingTicks = MathHelper.clamp((MathHelper.log2((int) (512 / speed))) * MathHelper.ceil(recipeSpeed * 15) + 1, 1, 512); | |||
也就是说什么那,反应时间(单位tick)为k*[9-log2(x)]+1而由于有int函数的存在,导致了一些奇奇怪怪的设定,就比如34速和35速的效率是完全一样的,尽管应力花费不一样,所以记住,在搅拌方案中,2^n+1速是血赚的。而且我们知道,搅拌机的启动速度是32速,recipespeed在默认状态下是1,那么k就是15。 | |||
那么32速搅拌机效率是多少?61tick处理一个配方,处理一组铝土矿的效率大概是97.6s。与手计时101s大抵一致。 | |||
那33速那?33速会不会赚一些?46tick处理一个配方,只需要73.6s,而这仅仅只是加了4点应力影响而已。手计时77s。 | |||
也就是说该假说成立,那么就需要考虑的一个非常严肃的问题就是,在同等应力下,我是加速还是多做几个进行堆叠。 | |||
显然的如果我的速度来到了65,那么处理效率那?31ticks处理一个配方,与33+32方案25.5ticks处理一个比,效率完全弱爆了。所以在速度上,多堆叠远远比多加速更加的有意义。 |
2021年11月30日 (二) 20:03的版本
概览
铝作为进阶金属,在自动化中是非常重要的原材料,与钢相同,是买入电力时代的重要标志。鉴于此,为了使得玩家能更好的研究产线,进行更加有效的产线布置,以铝产线为例,给出有效的产线布置方案,为自动化提供有效的支撑。
准备
也许你已经有了一条铝产线,但是为了以后的产线着想,还是看一下产线的思路是如何构成的。
首先,要得考虑的是一个产线所需要的步骤处理,以铝产线为例,与铝产线有关的合成表大致如下:
1、最先能找到的肯定是铝烧结,可行的方案大致是由铝粉烧制而成:
2、接着对于铝粉进行下一步分析,可以得到制备方案为:
3、接下来对于冰晶石,氧化铝进行分别溯源处理大致得到当前版本(0.4.6stable2)有效的产线思路:
大概也许可能某些萌新看到这张流程表就头大,但实际上这张图就是一个一个合成表倒叙分析,向着总目标产出进行研究后产生的方案。
继续对于该合成表进行分析,可以显然的可以发现,铝的生产需要三个搅拌过程,两个电解过程,和两个烧制过程,如果能自动化的实现他们,那么产线就产生了。
但这只是最基础最基础的产线,大部分玩家的产线也是如此,分析流程,搞出过程,然后就开始布置了。这样我写wiki的意义也就没有了。
那么,画出流程图了以后要如何处理这也是我们今天需要考虑的一个问题。没有流程,产线无从谈起,有流程,不代表好的产线。
首先我们需要考虑的是产物和投入的交换比。
不妨设我们的投入是硫磺,盐,水,洗净铝土矿石和萤石。
显然的500mb水两个硫磺粉,两个萤石,一个氢氧化铝可以合成500mb冰晶石
500mb水,一份盐,2个洗净铝土矿石可以获得一个氢氧化铝
氢氧化铝和氧化铝的交换比是1:1
氧化铝加上100mb冰晶石可以获得1份铝粉
铝粉与铝的交换比也是1:1
好,接下来,对铝所需要的材料进行分析,每合成5个铝锭,需要消耗的成本为3500mb水,2硫磺粉,2个萤石,6个盐和12个洗净铝土矿石(非常的贵)。
接着需要考虑的就是物流问题,产线和物流是分不开的。
显然的液泵和路由器(是没有灵魂的)是在做铝产线前非常不现实的一种方案。液体的传输有且只有智能流体管道+动力泵的方案。
而物品的物流方案就多了,常见的物流方案是传送带,但是沉浸的传送带需要钢,而机械动力的传送带需要动力,但是考虑到你游动力的价格。。
所以在这里额外介绍两种物流方案
1、水道方案
mc原版玩家狂喜系列,由于无限水的存在,水流运输具有造价极端便宜,运输上限极高的优势可以说直接把沉浸的传送带打的找不着北(用毛线传送带,水流不香吗?),但是鉴于策划的意思,在0.5版本主世界将不再可以找到灵魂沙(虽然地狱会开放就是了),所以在纵向上具有较大的劣势,另外一个劣势就是分类非常的困难,一旦涉及分类,在原版看来,分类是低效的,多检测的,而缓慢的。但是,这里的模组提供了有效的解决方案,例如本产线需要的1:5分流。
用水道将物品塞入任意一个容器内,在容器两端补上黄铜漏斗,一边设置5,另外一边设置1便可以达到一个伪黄铜隧道而不需要任何传送带进行补正。
PS:水道的水源如果要露天,请在边上准备火把放结冰(我相信现在你的水道已经冻上了,别看,我装摄像头了)。
2、抽屉方案
我相信你肯定知道抽屉管理器已经抽屉等等好东西,他们是储存的非常优秀的方案,但是这里,我们运用一个非常好的性质就是,抽屉管理器有它的管辖范围,在这个范围内,会按照一定规则选取一个位置把输入物品塞进去。于是一直新的,特大规模的物流方案就产生了,可以通过溜槽漏斗等高速输入物品输入抽屉管理器,然后通过桥接方块和上锁的抽屉进行高效物流(产线之间的距离?不就是一个抽屉管理器吗)。
那么接着就是生产速度的问题,由于搅拌机这个离谱的设定体系,直接上原代码了:
processingTicks = MathHelper.clamp((MathHelper.log2((int) (512 / speed))) * MathHelper.ceil(recipeSpeed * 15) + 1, 1, 512);
也就是说什么那,反应时间(单位tick)为k*[9-log2(x)]+1而由于有int函数的存在,导致了一些奇奇怪怪的设定,就比如34速和35速的效率是完全一样的,尽管应力花费不一样,所以记住,在搅拌方案中,2^n+1速是血赚的。而且我们知道,搅拌机的启动速度是32速,recipespeed在默认状态下是1,那么k就是15。
那么32速搅拌机效率是多少?61tick处理一个配方,处理一组铝土矿的效率大概是97.6s。与手计时101s大抵一致。
那33速那?33速会不会赚一些?46tick处理一个配方,只需要73.6s,而这仅仅只是加了4点应力影响而已。手计时77s。
也就是说该假说成立,那么就需要考虑的一个非常严肃的问题就是,在同等应力下,我是加速还是多做几个进行堆叠。
显然的如果我的速度来到了65,那么处理效率那?31ticks处理一个配方,与33+32方案25.5ticks处理一个比,效率完全弱爆了。所以在速度上,多堆叠远远比多加速更加的有意义。