本帖最后由 名为123的貘 于 2021-3-31 20:33 编辑
简介
众所周知，血魔法有个祭坛（
物品放进去，吸收LP可以转换为另一个物品。
一般不会选择自动化改合成设备。即使要自动化，也会选择多个祭坛配合白名单。
本挑战难点很多：
简介
众所周知，血魔法有个祭坛（
物品放进去，吸收LP可以转换为另一个物品。
一般不会选择自动化改合成设备。即使要自动化，也会选择多个祭坛配合白名单。
本挑战难点很多：
1、红石方面：不接受红石控制，不提供红石比较信号，不会发生方块更新和比较器更新。
2、物流方面：难以知晓什么时候完成合成，必须在完成合成之后的极短时间内取出成品，否则成品可能会再度发生变化。
2、物流方面：难以知晓什么时候完成合成，必须在完成合成之后的极短时间内取出成品，否则成品可能会再度发生变化。
那么先简介一下我们的成品和之间取消的方案都有哪些限制吧：
通用：无限LP制
废案：成品+n材料=>成品*(n+1)，需要网络中有成品才行。
废案：成品（重命名）+n材料=>成品（重命名）+n成品，需要去命名器才能让发配出来的样品和做出来的成品一致。而且样品的伪合成控制也不简单。
最终方案：n材料=>n成品，不稳定，尽量保证n>16，除非是合成悬幽石板之类的不会再变化，或消耗LP量大的。成品是直接由材料合成的，而不能是中间隔了一个材料。推荐n>16。
逻辑
物品发配至箱子A（材料+合成占位符 ）
尝试维护箱子B有32+个材料（材料来自于A）
箱子B的剩余26个格子被种类占位符 占据：
通用：无限LP制
废案：成品+n材料=>成品*(n+1)，需要网络中有成品才行。
废案：成品（重命名）+n材料=>成品（重命名）+n成品，需要去命名器才能让发配出来的样品和做出来的成品一致。而且样品的伪合成控制也不简单。
最终方案：n材料=>n成品，不稳定，尽量保证n>16，除非是合成悬幽石板之类的不会再变化，或消耗LP量大的。成品是直接由材料合成的，而不能是中间隔了一个材料。推荐n>16。
逻辑
物品发配至箱子A（材料+合成占位符 ）
尝试维护箱子B有32+个材料（材料来自于A）
箱子B的剩余26个格子被种类占位符 占据：
一阶段：制作样品
首先将8个材料放入祭坛。
然后循环执行以下两件事
1：当祭坛中物品不足8时，从箱子B中抽取材料到祭坛。
2：从祭坛中抽取一个物品。如果能放到箱子B中则继续。如果不能放到箱子B中，则放到箱子C中，进入下一阶段。
二阶段：合成剩余部分
箱子C中应当是：一些成品，剩下26个格子都是种类占位符（同上图）
执行：不断从箱子B中补充材料到祭坛，不断从祭坛中抽取物品到箱子C，当箱子C中物品数量>=33时返还32个物品给主网络
三阶段：返还成品复原系统
当箱子A、B中没有材料，且祭坛中无物品时执行开始阶段：
抽走箱子C中的所有成品，抽走合成占位符。
图片解析
图中三个箱子从左到右（从上到下）依次为ABC。
蓝色网络为主网络
青色网络从箱子C中收集物品给蓝色网络
紫色网络执行二阶段从祭坛中抽取物品的操作
黑色网络负责一阶段从祭坛中抽取物品的操作
绿色网络负责从箱子A中供给物品给箱子B
白色网络负责从箱子B中供给物品给祭坛
*三个红色网络：负责三阶段的启动
首先将8个材料放入祭坛。
然后循环执行以下两件事
1：当祭坛中物品不足8时，从箱子B中抽取材料到祭坛。
2：从祭坛中抽取一个物品。如果能放到箱子B中则继续。如果不能放到箱子B中，则放到箱子C中，进入下一阶段。
二阶段：合成剩余部分
箱子C中应当是：一些成品，剩下26个格子都是种类占位符（同上图）
执行：不断从箱子B中补充材料到祭坛，不断从祭坛中抽取物品到箱子C，当箱子C中物品数量>=33时返还32个物品给主网络
三阶段：返还成品复原系统
当箱子A、B中没有材料，且祭坛中无物品时执行开始阶段：
抽走箱子C中的所有成品，抽走合成占位符。
图片解析
图中三个箱子从左到右（从上到下）依次为ABC。
蓝色网络为主网络
青色网络从箱子C中收集物品给蓝色网络
紫色网络执行二阶段从祭坛中抽取物品的操作
黑色网络负责一阶段从祭坛中抽取物品的操作
绿色网络负责从箱子A中供给物品给箱子B
白色网络负责从箱子B中供给物品给祭坛
*三个红色网络：负责三阶段的启动
黑色网络
不断从祭坛中抽取物品给B和C，不过我们想要压缩一下网络数量，因此……黑色网络也负责提供箱子C的信息。
对B的存储总线为【只写】，以此能够只看C中是否以存在样品。
当C中存在样品时，就可以停止抽取了吧！
不断从祭坛中抽取物品给B和C，不过我们想要压缩一下网络数量，因此……黑色网络也负责提供箱子C的信息。
对B的存储总线为【只写】，以此能够只看C中是否以存在样品。
当C中存在样品时，就可以停止抽取了吧！
紫色网络
当C中有物品的数量>=27（即有成品时）开始抽取
为了让抽取间隔更短，我们用了另一个操作：不断抽取至原处，以保持高频抽取。当然箱子C的优先级更高。
当C中有物品的数量>=27（即有成品时）开始抽取
为了让抽取间隔更短，我们用了另一个操作：不断抽取至原处，以保持高频抽取。当然箱子C的优先级更高。
白色网络
一直尝试维护祭坛物品数量>=8
当C中有样品时，把所有材料都尝试提供给祭坛。
资源下载
地图使用模组：appliedenergistics2-rv3-beta-6、BloodMagic-1.7.10-1.3.3-17
血魔祭坛AE2自动化-release-1.0.1.zip
(345.57 KB, 下载次数: 55)
来自群组: MC百科一直尝试维护祭坛物品数量>=8
当C中有样品时，把所有材料都尝试提供给祭坛。
资源下载
地图使用模组：appliedenergistics2-rv3-beta-6、BloodMagic-1.7.10-1.3.3-17
血魔祭坛AE2自动化-release-1.0.1.zip
(345.57 KB, 下载次数: 55)
（完了看不懂了
思考着应该可以使用打包法来简化并且让自动化的合成可以更通用一些，但一直卡在如何判断已完成合成这步。
刚开始思考着是否可以利用你提到过的“占位符处理系统”中，存取空间只给“合成CPU”的暂存的方法。
但这样的设计并不实际：会需要有一套独立的系统，里面能够「存入物品」的只有合成CPU，并且还要在从那个呼叫合成。
这对于使用者来说是极度不友善的。
后来想想，你也有提到可以利用硬碟来打包。
然后就想到解法了：可以利用硬碟来当做动态的过滤器
因此简单设计了一下打包法的自动合成版本：
这边的打包法利用血魔法的Teleposer将箱子传送到祭坛旁拆包合成。
指向箱子的interface需要设置为阻拦模式。
在合成途中，透过祭坛边的控制系统，决定箱子什么时候传回来可以有很好的阻拦模式效果。
控制系统分为两部分：红色的是拆包用的系统
只要将做为过滤器的硬碟放在最后一格，就可以简单的设定分流物品的storage bus的优先级来确保硬碟不会被送入祭坛内。
橘色系统是尝试抽出产物的系统：通过仅有的一颗带有白名单设定的硬碟来确定是否已合成出目标物品。
当橘色系统中的level emitter检测到系统（硬碟）中存有物品，则将硬碟送回主系统的io port拆包，并且将箱子传送回去，告知可以进行下一次合成。
这种设计可以处理通用的祭坛合成情况：无论是直接从石头合成为玄幽石板，同时呼叫多份合成，或者任意数量的材料合成，都能通过一个祭坛完美解决。
刚开始思考着是否可以利用你提到过的“占位符处理系统”中，存取空间只给“合成CPU”的暂存的方法。
但这样的设计并不实际：会需要有一套独立的系统，里面能够「存入物品」的只有合成CPU，并且还要在从那个呼叫合成。
这对于使用者来说是极度不友善的。
后来想想，你也有提到可以利用硬碟来打包。
然后就想到解法了：可以利用硬碟来当做动态的过滤器
因此简单设计了一下打包法的自动合成版本：
这边的打包法利用血魔法的Teleposer将箱子传送到祭坛旁拆包合成。
指向箱子的interface需要设置为阻拦模式。
在合成途中，透过祭坛边的控制系统，决定箱子什么时候传回来可以有很好的阻拦模式效果。
控制系统分为两部分：红色的是拆包用的系统
只要将做为过滤器的硬碟放在最后一格，就可以简单的设定分流物品的storage bus的优先级来确保硬碟不会被送入祭坛内。
橘色系统是尝试抽出产物的系统：通过仅有的一颗带有白名单设定的硬碟来确定是否已合成出目标物品。
当橘色系统中的level emitter检测到系统（硬碟）中存有物品，则将硬碟送回主系统的io port拆包，并且将箱子传送回去，告知可以进行下一次合成。
这种设计可以处理通用的祭坛合成情况：无论是直接从石头合成为玄幽石板，同时呼叫多份合成，或者任意数量的材料合成，都能通过一个祭坛完美解决。
平凡的行者 发表于 2021-4-19 04:39
思考着应该可以使用打包法来简化并且让自动化的合成可以更通用一些，但一直卡在如何判断已完成合成这步。
...
打包草
确实，包是物品另一种存在的形式，除去重命名不可用，那么它便是一个优解
不过或许应该再压一压（？
而且硬盘有个问题那就是可能主网络不太方便存储有物品的硬盘，而且还有时会有相关的骚操作如SSD（见百科教程）
不过如过纯粹从实用性考虑，换成是便携元件是可以接受的，但是谁实用性做这玩意啊（
那么可以在此分化出两个版本
附：你是否看过这个内容（滑稽）
https://www.wenjuan.in/s/UZBZJvzf3m/
平凡的行者 发表于 2021-4-19 04:39
思考着应该可以使用打包法来简化并且让自动化的合成可以更通用一些，但一直卡在如何判断已完成合成这步。
...
话说你应该有兴趣继续优化这个内容吧
那么我就逃了）
我先去干我的活了
这有点难啊 完全搞不懂
感谢作者
贴心！！谢谢啦