产线基础和铝产线的初步展示 - 版本历史

Khjxiaogu：拒绝由Mr xian作出的后次文字更改，并由1600627624恢复到版本1445

2022-11-21T13:53:24Z

拒绝由Mr xian作出的后次文字更改，并由1600627624恢复到版本1445

←上一版本		2022年11月21日 (一) 13:53的版本
第124行：		第124行：
	方案二		方案二

	涡轮发电，通入蒸汽，1:~~4发电，没啥好讲的，材料很贵（备注输液管在没有液泵的情况下，有效率限制）~~		涡轮发电，通入蒸汽，1:3发电，没啥好讲的，材料很贵（备注输液管在没有液泵的情况下，有效率限制）

	1.2传输基础		1.2传输基础

Mr xian：/* 辅正 */ 涡轮是1:4发电

2022-11-19T09:55:00Z

辅正：涡轮是1:4发电

←上一版本		2022年11月19日 (六) 09:55的版本
第124行：		第124行：
	方案二		方案二

	涡轮发电，通入蒸汽，1:~~3发电，没啥好讲的，材料很贵（备注输液管在没有液泵的情况下，有效率限制）~~		涡轮发电，通入蒸汽，1:4发电，没啥好讲的，材料很贵（备注输液管在没有液泵的情况下，有效率限制）

	1.2传输基础		1.2传输基础

1600627624：开始补正

2022-01-15T04:57:22Z

开始补正

←上一版本		2022年1月15日 (六) 04:57的版本
第94行：		第94行：

	也就是说青铜飞轮绰绰有余。		也就是说青铜飞轮绰绰有余。

			== 辅正 ==
			鉴于0.4.7更正了铝产线的制备方案，上述方案虽然依旧有效但是毕竟有更好的处理逻辑，可以看一下。

			在这之前，由于萌新实在太多，所以上述直接考虑效率的玩家专属方案不太适合萌新，那么我们接下来就萌新一点，先讲两个教程分别为电力基础和红石基础。

			1、电力基础

			1.1发电基础

			现在（0.4.7）拥有的发电方案有且只有两种，顾再此对于能量消耗与转化进行比较。

			方案一

			动力发电，很多玩家并不知道交流发电效率几何，这里给出计算，一个青铜锅炉产出蒸汽的效率为12mb/t，产生应力大小为1024su，而交流发电机应力消耗是每增加一个速度单位消耗16su（备注：手摇和飞轮的初始速度均为32rpm），那么在这种情况下，交流发电机的发电效率是66.66%rpm向下取整，那和蒸汽的交换比是多少？1664=1024也就是说12mb蒸汽能完全供给一个动力发电机64速旋转，产生42rf的电量，能打到近乎3.5的交换比，即1mb蒸汽能产生3.5rf电量。但是，问题又来了，刚才提到，一个青铜飞轮需要将速度提升两倍，但是加速的转速控制器和齿轮会消耗应力，达不到1024su了。

			那怎么办?

			有玩家指出，我一个给32不就好了，其他的用十字齿轮箱连接起来，然后多堆叠几个动力发电机不就好了？

			但是这样虽然解决了发电的交换比问题，但是他不够廉价，也就是说，不NB，那怎么加速不消耗应力那？

			机械动力的加速，还有一个东西可以做到，那就是可编程齿轮箱，可以进行二倍速运转，并且可以堆叠。

			那堆叠上3个二倍速齿轮箱，速度就可以来到256rpm而没有消耗掉任何一个应力。这时候256*16=4096，正好来到一个钢飞轮。

			但是这里又有问题了，由于红石器件的gt时钟问题，导致检测和运转都有延迟，所以检测结束再开始会损失时间导致交换比降低。故将各个可编程齿轮箱连接在0t时钟上即可解决问题（0t时钟自己去抄方案，原版的东西）。

			方案二

			涡轮发电，通入蒸汽，1:3发电，没啥好讲的，材料很贵（备注输液管在没有液泵的情况下，有效率限制）

			1.2传输基础

	== 制备 ==		== 制备 ==
	[[文件:伸手系列.png\|无\|缩略图]]		[[文件:伸手系列.png\|无\|缩略图]]

登相：修改错别字

2021-12-02T08:49:54Z

修改错别字

←上一版本		2021年12月2日 (四) 08:49的版本
第1行：		第1行：
	== 概览 ==		== 概览 ==
	铝作为进阶金属，在自动化中是非常重要的原材料，与钢相同，是买入电力时代的重要标志。鉴于此，为了使得玩家能更好的研究产线，进行更加有效的产线布置，以铝产线为例，给出有效的产线布置方案，为自动化提供有效的支撑。		铝作为进阶金属，在自动化中是非常重要的原材料，与钢相同，是迈入电力时代的重要标志。鉴于此，为了使得玩家能更好的研究产线，进行更加有效的产线布置，以铝产线为例，给出有效的产线布置方案，为自动化提供有效的支撑。

	== 准备 ==		== 准备 ==

1600627624：/* 制备 */

2021-11-30T12:45:29Z

制备

←上一版本		2021年11月30日 (二) 12:45的版本
第96行：		第96行：

	== 制备 ==		== 制备 ==
			[[文件:伸手系列.png\|无\|缩略图]]

2021年11月30日 (二) 12:42 1600627624

2021-11-30T12:42:49Z

←上一版本		2021年11月30日 (二) 12:42的版本
第86行：		第86行：

	那搅拌速度是多少？		那搅拌速度是多少？

			10s要生产6个氢氧化铝，那么加热搅拌机的速度是多少？34tick处理一个物品65速的搅拌机就足够了。

			10s处理1次配方的流体搅拌。。。。32速吧，只能这么干了，毕竟要启动。

			那么最后，我们算一下应力，不考虑损失，那么运输流体花费90su，搅拌花费516。

			也就是说青铜飞轮绰绰有余。

			== 制备 ==

2021年11月30日 (二) 12:34 1600627624

2021-11-30T12:34:30Z

←上一版本		2021年11月30日 (二) 12:34的版本
第35行：		第35行：
	铝粉与铝的交换比也是1:1		铝粉与铝的交换比也是1:1

	~~好，接下来，对铝所需要的材料进行分析，每合成5个铝锭，需要消耗的成本为3500mb水，2硫磺粉，2个萤石，6个盐和12个洗净铝土矿石（非常的贵）。~~		好，接下来，对铝所需要的材料进行分析，'''每合成5个铝锭，需要消耗的成本为3500mb水，2硫磺粉，2个萤石，6个盐和12个洗净铝土矿石（非常的贵）'''。

	接着需要考虑的就是物流问题，产线和物流是分不开的。		接着需要考虑的就是物流问题，产线和物流是分不开的。
第60行：		第60行：
	processingTicks = MathHelper.clamp((MathHelper.log2((int) (512 / speed))) * MathHelper.ceil(recipeSpeed * 15) + 1, 1, 512);		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。~~		也就是说什么那，反应时间（单位tick）为k*[9-log2(x)]+1而由于有int函数的存在，导致了一些奇奇怪怪的设定，就比如34速和35速的效率是完全一样的，尽管应力花费不一样，所以记住，在搅拌方案中，'''2^n+1速是血赚的。'''而且我们知道，搅拌机的启动速度是32速，recipespeed在默认状态下是1，那么k就是15。

	那么32速搅拌机效率是多少？61tick处理一个配方，处理一组铝土矿的效率大概是97.6s。与手计时101s大抵一致。		那么32速搅拌机效率是多少？61tick处理一个配方，处理一组铝土矿的效率大概是97.6s。与手计时101s大抵一致。
第68行：		第68行：
	也就是说该假说成立，那么就需要考虑的一个非常严肃的问题就是，在同等应力下，我是加速还是多做几个进行堆叠。		也就是说该假说成立，那么就需要考虑的一个非常严肃的问题就是，在同等应力下，我是加速还是多做几个进行堆叠。

	显然的如果我的速度来到了65，那么处理效率那？31ticks处理一个配方，与33+32方案25.~~5ticks处理一个比，效率完全弱爆了。所以在速度上，多堆叠远远比多加速更加的有意义。~~		显然的如果我的速度来到了65，那么处理效率那？31ticks处理一个配方，与33+32方案25.5ticks处理一个比，效率完全弱爆了。所以在速度上，'''多堆叠远远比多加速更加的有意义。'''

	那么电解机的速度？		那么电解机的速度？
第76行：		第76行：
	电解机在供电充足的情况下，12s（手计时）处理一个物品（裂开不），也就是说，合成5个铝在只用两个电解机的情况下，需要消费72s，这是一个非常长的时间，导致很多时候，产线一直在空转处理，就非常的脑瘫。这里不妨用11个电解机，6:5处理，这样处理一个铝锭只需要2s非常的舒服。		电解机在供电充足的情况下，12s（手计时）处理一个物品（裂开不），也就是说，合成5个铝在只用两个电解机的情况下，需要消费72s，这是一个非常长的时间，导致很多时候，产线一直在空转处理，就非常的脑瘫。这里不妨用11个电解机，6:5处理，这样处理一个铝锭只需要2s非常的舒服。

	~~你说熔炼？那个东西效率极高，前往不要想如何传送带处理，可以魔法一下大概这样：~~		你说熔炼？那个东西效率极高，前往不要想如何传送带处理，可以魔法一下大概这样（正下方智能溜槽过滤产物）：
	[[文件:魔法熔炼.png\|无\|缩略图]]		[[文件:魔法熔炼.png\|无\|缩略图]]你说啥，着火？会烧掉活板门？在活板门正上方放溜槽不就好了（没有氧气烧不掉，气不气，气不气）。

			最后就是各种速度。

			2s产生一个铝，10s产生5个铝，那抽水速度是多少？

			水3500，硫酸500，冰晶石500，那分摊到每一tick是多少？17.5mb/t水，2.5mb/t硫酸，2.5mb/t冰晶石所以需要35速动力泵一个，5速动力泵2个。

			那搅拌速度是多少？

2021年11月30日 (二) 12:21 1600627624

2021-11-30T12:21:58Z

←上一版本		2021年11月30日 (二) 12:21的版本
第56行：		第56行：

	我相信你肯定知道抽屉管理器已经抽屉等等好东西，他们是储存的非常优秀的方案，但是这里，我们运用一个非常好的性质就是，抽屉管理器有它的管辖范围，在这个范围内，会按照一定规则选取一个位置把输入物品塞进去。于是一直新的，特大规模的物流方案就产生了，可以通过溜槽漏斗等高速输入物品输入抽屉管理器，然后通过桥接方块和上锁的抽屉进行高效物流（产线之间的距离？不就是一个抽屉管理器吗）。		我相信你肯定知道抽屉管理器已经抽屉等等好东西，他们是储存的非常优秀的方案，但是这里，我们运用一个非常好的性质就是，抽屉管理器有它的管辖范围，在这个范围内，会按照一定规则选取一个位置把输入物品塞进去。于是一直新的，特大规模的物流方案就产生了，可以通过溜槽漏斗等高速输入物品输入抽屉管理器，然后通过桥接方块和上锁的抽屉进行高效物流（产线之间的距离？不就是一个抽屉管理器吗）。
	[[文件:抽屉物流.png\|无\|缩略图]]那么接着就是生产速度的问题,~~由于搅拌机这个离谱的设定体系，直接上原代码了：~~		[[文件:抽屉物流.png\|无\|缩略图]]那么接着就是生产速度的问题,由于搅拌机这个离谱的设定体系，直接上原代码了（从策划嘴里问点东西真难）：

	processingTicks = MathHelper.clamp((MathHelper.log2((int) (512 / speed))) * MathHelper.ceil(recipeSpeed * 15) + 1, 1, 512);		processingTicks = MathHelper.clamp((MathHelper.log2((int) (512 / speed))) * MathHelper.ceil(recipeSpeed * 15) + 1, 1, 512);
第69行：		第69行：

	显然的如果我的速度来到了65，那么处理效率那？31ticks处理一个配方，与33+32方案25.5ticks处理一个比，效率完全弱爆了。所以在速度上，多堆叠远远比多加速更加的有意义。		显然的如果我的速度来到了65，那么处理效率那？31ticks处理一个配方，与33+32方案25.5ticks处理一个比，效率完全弱爆了。所以在速度上，多堆叠远远比多加速更加的有意义。

			那么电解机的速度？

			这个又咋算那？

			电解机在供电充足的情况下，12s（手计时）处理一个物品（裂开不），也就是说，合成5个铝在只用两个电解机的情况下，需要消费72s，这是一个非常长的时间，导致很多时候，产线一直在空转处理，就非常的脑瘫。这里不妨用11个电解机，6:5处理，这样处理一个铝锭只需要2s非常的舒服。

			你说熔炼？那个东西效率极高，前往不要想如何传送带处理，可以魔法一下大概这样：
			[[文件:魔法熔炼.png\|无\|缩略图]]

2021年11月30日 (二) 12:03 1600627624

2021-11-30T12:03:47Z

←上一版本		2021年11月30日 (二) 12:03的版本
第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日 (二) 11:11 1600627624

2021-11-30T11:11:33Z

←上一版本		2021年11月30日 (二) 11:11的版本
第47行：		第47行：
	1、水道方案		1、水道方案

	mc原版玩家狂喜系列，由于无限水的存在，水流运输具有造价极端便宜，运输上限极高的优势可以说直接把沉浸的传送带打的找不着北（用毛线传送带，水流不香吗？），但是鉴于策划的意思，在0.5版本主世界将不再可以找到灵魂沙（虽然地狱会开放就是了），所以在纵向上具有较大的劣势，另外一个劣势就是分类非常的困难，一旦涉及分类，在原版来看，分类是低效的，多检测的，而缓慢的。但是，这里的模组提供了有效的解决方案，例如本产线需要的1:5分流。		mc原版玩家狂喜系列，由于无限水的存在，水流运输具有造价极端便宜，运输上限极高的优势可以说直接把沉浸的传送带打的找不着北（用毛线传送带，水流不香吗？），但是鉴于策划的意思，在0.5版本主世界将不再可以找到灵魂沙（虽然地狱会开放就是了），所以在纵向上具有较大的劣势，另外一个劣势就是分类非常的困难，一旦涉及分类，在原版看来，分类是低效的，多检测的，而缓慢的。但是，这里的模组提供了有效的解决方案，例如本产线需要的1:5分流。
			[[文件:分类方案.png\|无\|缩略图]]
			用水道将物品塞入任意一个容器内，在容器两端补上黄铜漏斗，一边设置5，另外一边设置1便可以达到一个伪黄铜隧道而不需要任何传送带进行补正。

			PS：水道的水源如果要露天，请在边上准备火把放结冰（我相信现在你的水道已经冻上了，别看，我装摄像头了）。

			2、抽屉方案

			我相信你肯定知道抽屉管理器已经抽屉等等好东西，他们是储存的非常优秀的方案，但是这里，我们运用一个非常好的性质就是，抽屉管理器有它的管辖范围，在这个范围内，会按照一定规则选取一个位置把输入物品塞进去。于是一直新的，特大规模的物流方案就产生了，可以通过溜槽漏斗等高速输入物品输入抽屉管理器，然后通过桥接方块和上锁的抽屉进行高效物流（产线之间的距离？不就是一个抽屉管理器吗）。
			[[文件:抽屉物流.png\|无\|缩略图]]