= 创作分享 =
技术讨论
我的Mod游玩心得 篇一:能源系统设计
craftkuro

我的Mod游玩心得 篇一:能源系统设计

craftkuro 于 2019-8-27 13:48 ( 5年前 ) 发表在 [教程] 分类。 [复制链接] [只看楼主] [打印]
16876 31
本帖最后由 craftkuro 于 2020-12-10 01:56 编辑

- 本文的大部分内容均为原创,部分来自借鉴的内容会特别标注。

- 本篇文章的面世,少不了群里各大佬的灵感和协助。笔者在此表示感谢。

- 关于转载:使用CC BY-NC-SA许可证。欢迎转载,但请遵守许可证。请不要滥用作者给予的宽容。若您受本文启发而有了新的划时代设计,也不妨将本文加入参考文献中。

- 为鼓励根据自己的情况灵活修改设计,笔者在方案讲解中只提供概念设计,但在后文会提供游戏截图作为参考设计,并证明其确实可行。(可能无限期鸽置)

- 致在遥远的未来阅读本帖的你:请注意本帖最初作于2019年8月,其中包含的内容可能在某个时候发生改变。在套用经验前请先验证概念。

- 本文内容可能较为混乱。我的思路本来就有点乱……大概没有办法解决。

- 本文内容可能高度硬核。看不懂?多毕业几个模组,大概就能明白个中玄机。
-----------------------

目录
1 常见,但存在大量缺点的方案
2 基于优先级的能源分配 (RF/FE阵营)
    2.1 决定输出的依据
    2.2 决定输出功率的方法
    2.3 总体思路:水位控制
    2.4 初级外围设计:保底和填谷
    2.5 进阶设计:自适应发电和耗电
    2.6 主动填谷
3 基于优先级的能源分配(IC2)
    3.1 若MFSU不支持比较器
    3.2 若MFSU支持比较器
4 高级设计
    4.1 冗余、模块化、可扩展、灵活配置和平滑升级
    4.2 降低能源网络的不确定性
    4.3 Reload-safe 和 restart-safe
5 图片样例

-------------------------

玩科技类模组,少不了的一类元素就是能源。但与此相伴而来的,还有停电。如何解决这一问题,成为了科技发展中的一大挑战。

1 常见,但存在大量缺点的方案
- 我不管了!停电就停电
╮(╯▽╰)╭

- 大缓存
其实这个方案本没有错,但是它并没有从设计层面阻止停电的发生。而且在缓存满后,会有些浪费。

- 手动开/关额外发电机,或者根据MFSU/能量单元的红石信号开关发电机
这个方案为这个目标做了一些努力,但它的效果并不理想。相信经验丰富的你一定有所体会。

是时候升级了!现推出“电网Plus“,愿你在挂机或者探险的时候,对自己基地的能源状况充满自信。

2 基于优先级的能源分配 (RF/FE阵营)
格雷?格雷是什么?

首先,让我们看看一个较为典型的RF阵营基地有什么:
- AE/RS/RFTools等需要能源的存储/物流/自动化系统(需要一直有电)
- 磨粉机 炉子 压缩机等等,在需要的时候启动并消耗能源的机器(需要尽量保证有电)
- 收割机 种植站 各种矿机 虚空矿物/资源/植物采掘机等长期运行,但停一会或者慢点也无所谓的机器
- DE聚合合成装置等需要巨量能源但不在意是否花多少时间的机器
- UU机 分子机等能源黑洞(没错,它们是EU阵营的,但在一些魔性的整合里有)

于是,我们很容易发现不同种类的机器之间有非常明显的能源优先级差距。此时,有一个同样基于优先级分配电力的装置,岂不美哉?

文中适用于RF阵营的设计,基于一个非常重要的假设:能源不足时机器仅降低速度而不改变执行结果。比如某虚空矿物采掘机,其标注需要8000 rf/t,那么我们以恒定2000 rf/t给它通电,此时机器内部缓存将会在每次缓存达到8000 rf(需要4tick)的时候工作1tick,刷出矿并消耗掉这8000 rf。宏观上就是速度变成了满速时的1/4。

那么问题来了,怎么实现这个优先级呢?
我目前的思路主要是,从某种依据出发,决定某一路的输出功率。
从外部来看,其架构是这样的:


2.1 使用何种依据?
看发电功率和耗电功率?似乎没有办法可使用常规自动化方式获取。即使能,它们也需要使用数学和逻辑运算才能转换为可用于执行某种操作的结果(如红石)。
看电池(缓存)里的容量?似乎是个好办法。(此方法由TE机器功率随其内部缓存水平改变而启发)缓存水平高的时候,输出就高一些;缓存低的时候,输出就低一些。似乎可以应对不少状况。获得缓存能量水平也相对容易,一个比较器即可搞定,还有16级的精度呢。


2.2 如何决定某一路的输出功率?
除去opencomputers等上帝赐予的模组,MC里通用的信息传递手段是红石信号。
于是我们的思路也很明确——在合适的时候,给出合适等级的红石信号,操作某一路输出前面的那个开关。

小试牛刀!
游戏前期,你只做的起基础等级的机器,和第一个环境科技太阳能和矿机。你还有一个树场和一个蒸汽发电机组。
很明显,我们希望充分利用两者的发电能力。那么,如何以尽可能低的成本,既能让矿机获得尽可能充足的电力,还能让你的各个机器保持稳定运行呢?

如果想不出来或者希望跳过此问题,可点击展开详解。
但我强烈建议在提出自己的方案之后阅读这部分,因为这可能是全文唯一一处按步骤分解的详细说明。



刚才举出的例子,在游戏前期对成本敏感时可能较为有用。但很快,在这个系统上我们就会遇到瓶颈。因此,需要一个更加强力和正式的方案。

接下来将列举我(和大佬们)提出并经过实践证明的一些方案。不分优劣。因为适合当前情况的才是最好的。

重要提示:请避免在实际使用时配置过多的优先级,这会引入不必要的复杂性。个人建议前期供能不足时使用3-4个,后期使用2-3个优先级。

2.3 总体思路:水位控制
易于理解的模型是这样的:


实际实现可以有两种,一种是使用一个大缓存:

此方案的特性及缺点:
- 在“水位”达到一定高度之前,它上面的输出完全关闭。
- 理论上允许无限路输出,和15个优先级,但实际受具有实用价值的红石信号范围限制,最多可设置14个优先级。(eio电容库似乎只有在存满所有能量时才会输出15,因此这一级通常没有实用价值。)
- 若缓存装置允许无限扩展(如eio电容库,和rftools power{不是rftools!}能量单元),则扩容升级相对容易,并可实现平滑升级。
- 缓存装置的IO能力,和输出开关连接到缓存的导线,容易成为瓶颈。
- 若将DE能量阀门用作可多级控制的开关,则可实现更加精细和灵活的控制。
- 不必拘泥于只使用一个比较器,如果发现没有足够的空间摆下管道和开关,则可使用多组比较器。
- 此方案可能具有较强的改装潜力,因为一个比较器即可纵观全局。见后文的其他方案。


另一种是使用多级缓存串联的方案,此方案在一定程度上借鉴了其他人的设计:


此方案的特性及缺点:
- 在“水位”到达特定水平之前,此级别的输出完全关闭。但是如果移除比较器和开关装置,在程度上,也允许较低的优先级,在对应级别的缓存未满时,获得少许能量(此处获得的能量多少,不可预测。见后文“减少能源网络的不确定性”)。
- 若使用的缓存装置允许无限扩展,则可实现较为容易的扩容和平滑升级。
- 缓存间级联用导线,和缓存本身,容易在后期成为扩容瓶颈。
- 此方案我没有想出丰富的改装方案。目前已知较为实用的一种是将DE能量阀门作为开关,因其支持不同级别的红石信号,可使得输出功率变化平滑。


2.4 初级外围设计:保底和填谷

其实这里的两个内容,说简单可以做得简单,说复杂也可以做得很复杂。既然这里写着是初级,那么就举出简单实用的例子。

当其他所有能源都因为异变而变得无法使用的时候,我们也许需要保证诸如AE网络等基础设施仍能正常运作,使得我们有机会修复基地并恢复主要能源供应,并避免遇到先有鸡还是先有蛋的问题而导致ae里的东西拿不出来。于是,我们需要一个装置用于保证某个特定优先级(通常是最高)的供电在任何情况下都可用。

自然,这个优先级不能提供非常大的功率。


既然是保底,我们也可以不考虑什么动态功率调整,而将重点放在高可用和高可靠性上,让它在出现危机的时候可以果断介入。

很明显烧煤/石油等的常规能源阵列,或者一个经过检验的马克1反应堆,是较好的选择。我们可以很方便地储存大量燃料。如果你的方案经测试确实能保证存储网络的稳定运行,也可以充分利用其提供的存储空间。

有关使能信号,若使用诸如ME标准发信器等需要能源才能发射红石信号的装置,请注意将整个装置设计为,在没有能源供应时也能触发应急发电机工作的模式。非门可能是一个有用的工具。
---------

后期常用的大功率发电,包括太阳能和风电等,都具有一定程度的周期性,因此,在应用基于优先级的能源分配时,部分大功率机器的速度在夜间等时候可能显著变慢。
当然,充满创意的玩家们总是能提出一些饱含创意的方案——没有夜晚的话,就没有这些问题了!使用DE的苍穹变换器,或者制造一个时间固定的RF工具维度都可以很好地解决这个问题。
但这并不符合本文的主题。符合主题的方式是,再加一个填谷装置,用来在缓存水平不够高的时候,主动开始供应能源。

最简单的实现方法,是再做一个“保底”装置,让它在缓存剩余较多(比如2/3)的时候介入,这样就可以实现填谷了。(不建议将原先的保底装置用作他用)(因概念相同,图略)
事实上这是一个相当不错的方案。

另一个稍显复杂的方案,是根据主缓存的能量水平动态调整填谷装置的发电功率。



图中蓝线的两端可以在虚线框内自由移动,但很明显,只有设置为和图中类似的下降趋势才能按照我们期望的方式起到作用。
按照这种设计,若填谷装置的发电容量足够,在大多数情况下主缓存的能量水平会趋向于稳定在某两个比较器输出之间。我个人比较推崇这种设计。

这种设计的实现,在细节上也可以分为两类:
一种是直接从主缓存上的比较器传输信号,但如果缺少具有相关特性的模组,在MC里传输模拟(analog)水平的红石并不容易。扩容可能也相对麻烦。这个方案不需要设计自适应发电功率。可能适用于填谷装置距离主缓存很近的情况。
另一种方案是使用主缓存上的比较器,操作DE能量阀门等装置,控制从填谷装置获取能量的速率。在这种设计下,为避免浪费燃料,应当设计自适应发电功率,让发电机组输出主动与整个装置的输出同步。这个方案模块间耦合度低,可不管主缓存的任何内容,直接进行扩容等升级操作,也没有红石传输带来的距离限制——信息从能量管道间接完成传输,甚至可以跨维度操作。

但是这种被动填谷的方案也存在其固有缺点:在大多数情况下不能充分利用发电机容量(因为主缓存大多数情况下不会放空),而且因为最终稳定水平较低,机器速度也会受到影响。这个问题可以通过设置填谷装置的工作范围和增加容量来缓解。

这两个方案总的来说都可以很好地达成目的。但是仍然有一个问题未能得到解决——如何使夜晚的机器速率和白天一模一样呢?请看后文:“主动填谷”。

2.5 进阶设计:自适应发电和耗电
面对不确定且不可预测的发电和供电情况,我们自然不能坐视不管。我们希望将这方面的波动尽可能平滑,使得各种发电机的发电速率、机器的工作速率接近于一段时间的平均能源供给/消耗。在某种程度上,它们是缩小版的水位控制方案一。

2.5.1 自适应发电装置


相信你一看就懂。逻辑上,整个装置可以被认为是一个大功率的,红石控制的发电机。
发电机也不必拘泥于能源炉,NC的反应堆等可由红石控制和随时启停的产能装置都可以。
缓存的大小完全无所谓,甚至IO能力也无所谓,不过太小的话可能效果并不合算。
发电机也可以任意并联,只需将红石信号传输处理好。
于是负载从0直到缓存允许的最大IO能力,这个装置都可以轻松应对,并且没有燃料浪费。
整个装置可以作为一个模块来大量堆叠,以提供更大的功率。

2.5.2 自适应耗电控制装置

对于能源黑洞等装置,使用大功率短脉冲似乎也没什么问题,但如果希望在某些情况下使用稳定大小的电流,这个装置就可能派上用场。
于是继续按照原先的设计,我们在缓存后面加上了一个根据红石水平控制的能量阀门。


波动且不确定的输入经过了这个缓存的滤波,变成了较小但相对稳定的输出。
等等,有哪儿不对。虽然缓存可以轻松扩容,但能量阀门的容量是线性的,如果配置的数字太小,带不动大功率装置;配置的数字太大,则输出又是大幅波动的,和没加这套装置没啥区别。
怎么办?这里又有一个新的设计:多段线性能量输出。


我们可以多摆几个能量阀门,比如第一个位置摆上系数为1K(系数是什么?这里指的是红石水平每增加1,能量输出增加的数量,系数为1K即配置为红石信号高=15K=15000,红石信号低=0)的能量阀门,在第3个位置摆上系数为10K,第5个100K,第7个1M,第10个10M等等。这样就可以大幅提升整个装置的输出能力——当比较器输出7(缓存约一半)的时候,输出就为1K*7+10K*5+100K*3+1M*1=1,357,000 rf/t。

几乎完美。
然而,当输入能量不足以凑足一段输出时(尤其是在大功率下),其实际输出功率很明显会在两个水平之间波动。这个现象在本装置里无法避免,并且尚未找到解决方案。不过即使如此,宏观上机器的速度仍然是平稳的。

咱们再看看前面提到的,用能量管道间接传输信息的具体实现方式。



就像这样,把发电接到一个受控的输入端。
能源调度系统根据其内部缓存容量控制这个阀门,决定从这个发电装置获取能量的速率。
然后自适应发电装置自行进行内部调节,使发电速率和能量流出速率在宏观上相等。
并不是什么黑科技。

2.6 主动填谷
警告:这一节是实验性内容,未经充分测试和验证。虽然看起来能用,但也许会出现令人意外的结果。
前文提到的被动填谷方案,不可避免地会在夜间降低缓存水平,并降低机器的速度。是否能设计一个控制器,使得在任意的输入和输出情况下,都能够保持输出水平呢?

简单的回答是我没想出一个完美的方案。

结合在下文提到的平滑升级需求,我们假设在之前的优先级分配方案一上来进行升级——方案二没法弄;那么问题就变成了,如何在任何情况下都维持一个固定的缓存水平?

方案一:定期检查缓存水平,并决定从发电机取多少电。
这玩意用红石逻辑可能太麻烦了,但咱也不会写lua,只能折中,选用rftools control。
I know talk is cheap, so here's the code.


写的有点乱,但在实验时基本能达到设计目标。
简单来说,这里有一个可配置的目标缓存水平(80),当算出来缓存水平低于这个的时候,每1秒提升一级从反应堆等可自由调节的能源抽取的能量(实验时发电机端已启用自适应发电,上限10M rf/t),当缓存水平高于目标水平时,每1秒降低一级从可调节能源抽取的能量。
我的实验装置如下:


理论上说,只要这个装置的最大输出功率不超过可控能源供应的最大输出功率,这个控制器就能将缓存水平大致维持在预定水平上。但是这里有个问题,在实验过程中,控制发电机能源输入的红石信号不断从在0和15之间震荡,而不能随负载大小稳定在某个数值上。这意味着这个装置并非能够主动趋向于一个稳态——这在之前所有的设计里都没有发生。
对于某个特定大小的负载,修改两次执行程序的间隔,能够在一定程度上缓解问题;但我的设计目标是对任意大小的,不可预测的输入和输出都能够良好处理。因此这个方案不符合我的要求。
但是它能用。你想用就用吧。代码都给了。大概需要一点小改。


方案二:高级版的填谷方案二
警告:此方案完全未经实验,但我相信这个方案足够稳……应该不会翻车。
既然我们解锁了可编程控制器,那么我们就可以弄出更加复杂的曲线。


于是我们弄出了一个以预定水平(80)两端对称的陡峭斜线——每1%都对应着原先的一个红石水平。和刚才那个体现宇宙真谛(运动是永恒的)的方案类似,只要可控能源足够强力,我们就可以稳住缓存水平,而这次机器速度下降的程度比之前的填谷方案二小多了。

3 基于优先级的能源分配(IC2)
格雷是什么?哦我听过,但不会玩。


由于我实在是没深入地玩过格雷,同时因为GT和IC2对能源的供应要求完全不同,故本节中的内容只适合IC2。想要GT的方案?自己原创一个,或者看看其他人的经验和技巧。也许我未来会在这里再加一章吧。

警告:本节中的几乎所有内容均未经过实验验证。

1.12的IC2储能方块似乎有支持比较器,但玩1.7的时候似乎没有。那么我把两种情况分开讨论吧。

3.1 若MFSU不支持比较器
MFE这个弟弟,就不提了。
方案一:串联


于是很明显,你应该能看出来它实现了类似于RF系比较器的功能。IC2的开关就是EU分流导线了。参考RF阵营的设计概念,建造合适的红石电路就能达到目的。

但是,IC2和EU本身带来了一些蛋疼的问题:
1) 什么才算满?究竟是40,000,000还是(40,000,000-2048)~40,000,000,又或者是什么别的值?
测试结果表明判断为“满”的值大约在39,959,000左右。两个猜想都错了。
2) 整个装置的输入/输出能力被限制在了单个MFSU的2048 eu/t。扩容的方法似乎只有建造多个相同的装置来并列
如果在MFSU串联间的导线上进行输出,由于其串联的本质,下游的MFSU会得到较少能量,因此会造成红石输出并不连续(比如只有第1,2,4个MFSU有信号,但3应当也有)的诡异情况。如果你想出了完美解决这种情况的方法,那么从中间引出也不错。

方案二:并联
上一个方案的缺点如此明显,我们自然不能坐视不管。
IC2没有很方便的扩容方式,为了达成一秒一个铱的速度,唯一的方法就是堆上更多的MFSU。

如果不用红石控制,它就是个非常非常普通的方案。但是和之前各个方案一样,若要实现控制,我们需要使用某种方式获取其中能量水平。
将所有的MFSU都配置为“满电时发出红石信号”,然后将这些信号分别进行“或”和“与”逻辑预算,我们可以得出以下3种情况:
或=0,与=0,=>所有的MFSU都没满
或=1,与=0,=>有部分MFSU满了
或=1,与=1,=>所有的MFSU都满了
虽然没法像比较器和rftools control一样实现精确的控制,但至少能给我们一些线索来了解其中情况。那么我们就可以借用其他方案中出现过的经验,来实现较为粗放的电力调度。也许这就是大功率的代价吧。
——如果使用更复杂的逻辑,也许会有更精细的结果,但我未能想出较好的方案。
这里还有个问题,当能量输入时,每个EU Packet会往哪去?我不知道。因此输入端的接线建议不要对称,以尽量拉开“有一个满”和“全满”的容量差距。


3.2 若MFSU支持比较器
那还等什么?照抄RF系方案啊。然后做一大堆相同的装置来实现扩容。注意电压问题。


4 高级设计
4.1 冗余、模块化、可扩展、灵活配置和平滑升级
还记得前文的这个方案吗?


我们做两个这样的装置,将每一个外部的输入和输出并联起来——BOOM!我们的电网扩容了一倍!
其实本文中RF/EU阵营的其他几个方案也可以这样做。

对于本节标题中提到的相关术语,具体的意思我们不再赘述,但我们评价一下这个并联多个个此类装置的方案:
冗余:一个装置因为异变坏掉了!但是另一个还能完美正常使用。基地照常运行,就是慢点。
模块化、扩展性和平滑升级:两个装置不够用?再做两个相同的装置并联一下,还能用!电网容量变成四倍了! 从前期中期的1000 rf/t,到后期的10M甚至100M rf/t,升级仅需替换组件。无论是并联操作还是新建、拆除装置,都不会造成基地完全停电,简单的加能量单元/电容库等操作,连1tick的停机都不会出现。
灵活配置:对于“水位”阈值和每个阀门的容量,仅需移动少量方块,或编辑数字/程序来完成配置,无需进行大规模重构。

要是其他系统的设计也像这样,该多好。

4.2 降低能源网络的不确定性
当大家任性接线的时候,通常不会考虑到这样一个问题:若你有多个发电机,它们的实际负载分别是多少?当上游能源不足时,下游的机器的能量又是如何分配的?

设想以下情境(如图):
对于这样一个装置,有一个450 rf/t和一个700 rf/t的输入,有一个1000 rf/t的输出。
很明显输入总功率是大于输出总功率的。
所有的输入和输出都以最大速度工作时,能量单元的缓存会逐渐被填满。那么问题来了,当这个缓存满了之后,这两个输入端的能量功率分别是多少?

当然,你可以选择不管这个问题,因为装置仍然可以正常工作。

不过,假设700 rf/t的是免费的太阳能,而450的是你辛辛苦苦砍下来的树烧出来的。很明显,你不希望这些燃料烧得太快。

这个时候就遇到了这样的不确定性问题。
对于本装置,我观察到的行为是,当两个输入的一个被关断后(比如晚上太阳能不再发电),当这个输出再次启用时,若缓存已满,它仅会输入为了保持缓存满时所缺的能量(在本装置中,是1000-450=550 rf/t)。这意味着,如果什么都不做,你的燃料就得不断被消耗以产生450 rf/t的能源。
解决方法是什么?一是根据缓存水平选择输入优先级,和本文主题相符,至于具体实现方式,当然和输出的优先级概念类似。另一种就是在合适的时候关断来自燃料的输出,来将太阳能变成所谓的主要输入,这样你的燃料发电机只需要输出1000-700=300 rf/t了。

另一个情境是,一个输出有限(比如1M rf/t)的供能设备下面接两个(或若干个)能量黑洞(可以抽象为垃圾桶),试求每个黑洞接收到的能量。
我求不出来。

本节中提到的不确定性问题,没有相关定式,我也没有能够以不变应万变的解决方案。但是在设计这样的系统时,有必要考虑它带来的潜在问题,以尽量避免系统处于意料之外的状况。

4.3 Reload-safe 和 restart-safe
服务器重启/区块加载和卸载时,会执行一些任务——具体我也不知道是啥。但部分不那么普通的接线方式,在这种情况下无法正常工作。
典型例子之一就是不同模组的导线直接相连。它们有相当的概率不能正确工作,或者发挥最大效能。造成这个现象的原理较为复杂,难以说明清楚。但由此得出的教训是,避免直接将不同种/不同等级的能量管道直接相连。若需要进行不同类管道的互联,建议在中间加上一个方块(比如能量单元/电容库/锂离子电池)的缓冲,其目的是保证它连接稳定,并且通过配置这个方块,实现能量流动方向的控制(降低不确定性),从而充分使用管道容量。


目前在能源网络中,似乎没有发现其他的特殊接法,会在服务器重启时造成问题。
不过AE2 stuff的无线接入器(配合AE 1.12.2 rv5或rv6时),在区块卸载时可能会发生故障。当然这是后话。

5 图片样例

事实证明我只鸽了两天。画图辣鸡!图切小了体积反而变大了

下图为前面小试牛刀的示例答案——最简单的调度系统实现。
似乎并没有什么需要解释的。
当然,这里的树场和矿机是假装的,理解概念即可。



下图为水位控制方案一:单一大缓存的示例方案。
一样,非常容易明白
略去了输入部分——有啥电都往里怼就行了。
橡木下面的对应位置(连有管道的部分)埋藏有能量阀门。当然,你也可以替换为其他的开关。


下图为水位控制方案二:多级缓存串联的示例方案。
太阳能作为示例的电力输入。橡木下面有能量阀门。


下图为自适应发电装置的示例方案。
前文已提到过,它的设计可以非常灵活,不必拘泥于能源炉。
至于自适应耗电装置,我发现它和刚才的水位控制方案一完全一样(除了配置的数字),照抄概念即可。



下图为IC2 MFSU串联的方案。
MFSU配置为“满电时发出红石信号”。非门起到一定程度的滤波作用。如果你选择“没有满电时发出红石信号”,也许可以省下一个非门。这样做是否合适,请根据实际情况决定。



下图为IC2 MFSU并联的方案。
MFSU和前面的一样,配置为“满电时发出红石信号”。当然你也可以根据实际情况选择不同的红石配置——但是后面的逻辑部分也要进行相应修改。与门和非门的具体实现略,用无线红石假装一下。



下图为前文提到的使用rftools control的并不完美的方案。图中的装置可以正常工作。
出自某夭折的周目。这是计划内扩建的新基地,设计供电容量为n*10M rf/t。很不幸,其他的外围设施未能建设起来。

咱们换个角度



篇一 能源系统设计 到此结束

本系列的更多内容
由于内容过多,鸽着是不可避免的了。写完后我会更新帖子里链接。
篇二 性能调优
篇三 基地设计
篇四 模块仓库












rftools_control_power_control.json.txt

21.09 KB, 下载次数: 8

文中提到的代码

点评

祖国需要你  发表于 2022-7-12 11:10

评分

参与人数 9RF +90 Vis +16 收起 理由
3424 + 2 触我一脸血
Aphex_Slayer + 5 + 2 触我一脸血
youyihj + 5 + 2 祖国需要你
梨木 + 20 + 4 喵喵喵喵喵?
CannonFotter + 8 + 4 给大佬递分
重生是希望 + 20 + 2 优秀作品!
星落辰 + 5 + 2 第一遍看没找到评分键,枯了。
封兽·鵺 + 20 不管了 停电就停电(放弃思考)
Lucky_H_ling + 5 详细

查看全部评分

发表于 2019-8-27 13:48:29 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式

回复 | 举报

该帖共收到 32 条回复!
GingleMeow
删图片的话,在编辑器附件里面就能找到了~
发表于 2019-8-27 17:58:27 | 只看该作者

回复 | 举报

craftkuro
Gingerbread 发表于 2019-8-27 17:58
删图片的话,在编辑器附件里面就能找到了~

原来如此,成功解决问题

评分

参与人数 1RF +5 Vis +2 收起 理由
星落辰 + 5 + 2 祖国需要你

查看全部评分

发表于 2019-8-27 18:15:26 | 只看该作者

回复 | 举报

LRual
表示一直遵循这大缓存,缓存满了以后关闭发电设备的套路
看了一部分楼主分享的心得,
感觉打开了新世界的大门

我得要至少半个月好好消化一下这些内容(趴趴)

辛苦了,受益匪浅的感觉
2333333
发表于 2019-8-28 00:30:54 | 只看该作者

回复 | 举报

craftkuro
light000 发表于 2019-8-28 00:30
表示一直遵循这大缓存,缓存满了以后关闭发电设备的套路
看了一部分楼主分享的心得,
感觉打开了新世界的大 ...

加油!期待你的全新设计:)
发表于 2019-8-28 19:56:09 | 只看该作者

回复 | 举报

星落辰
@重生是希望  老板,给他个高亮精华xxxxx吧~太强了(跪)
发表于 2019-8-28 23:05:35 | 只看该作者

回复 | 举报

smilesadness
建议添加大纲,添加更多栗子。
发表于 2019-8-29 12:44:40 | 只看该作者

回复 | 举报

uu-matter
热力的红石信号发生器能实现比较器功能和阈值控制,能很方便地读取大量(一个管道网有16个频道能读16个机器)能量单元或MFSU,然后交给一个多输入的与门处理
而且IC2的稳定性简直难以相信,重新加载区块时会有一定概率出现导线断成一节一节的现象。
对于安装了末影接口的情况,能量阀门可以用能量管道轻易做到。而纯热力基本也就只有靠能量单元的红石控制了。不过如果加入wirelessutils等能自动破坏/放置方块的mod,破坏管道(切断电线)实现关断是最直接的方法。

不过话说大家的ME网络应该都是稳定独立供电的吧。
要不要看看我做的资源包,数据包和模组?Modrinth Curseforge
发表于 2019-8-29 17:16:29 | 只看该作者

回复 | 举报

craftkuro
smilesadness 发表于 2019-8-29 12:44
建议添加大纲,添加更多栗子。

我加了目录,也加了图——你感觉如何?
发表于 2019-8-29 21:05:57 | 只看该作者

回复 | 举报

craftkuro
本帖最后由 craftkuro 于 2019-8-29 21:23 编辑
uu-matter 发表于 2019-8-29 17:16
热力的红石信号发生器能实现比较器功能和阈值控制,能很方便地读取大量(一个管道网有16个频道能读16个机器 ...

哇,我全程都没想起来热力的 红石信号中继器 (好像现在是这么翻译的)这玩意

导线断的情况近一两年没遇到过,再早玩1.7的时候偶尔有看到,可头疼了

开关的实现方式很明显不唯一,个人更偏好不发生方块摆放/破坏的,因为会减少区块更新的性能开销。

ME网络独立供电与否,也是见仁见智的问题。我近期玩/组装的整合,中后期发电主力多是太阳能,因此接在一起相对省事;以及ME网络的总耗电,从前期到后期会攀升不少倍,单独整个的话需要扩容两个系统,这样麻烦就会多些。
发表于 2019-8-29 21:18:17 | 只看该作者

回复 | 举报

1234下一页
百科目前不允许匿名发帖哦~ 请先 [ 登陆 ][ 注册 ] 吧~

本版积分规则

发新帖
  • 回复
  • 点评
  • 评分

[ MC百科(mcmod.cn) 除另有声明,所有开放公共编辑的内容均使用 BY-NC-SA 3.0 协议 ]

Minecraft百科CC协议
快速回复 返回顶部 返回列表