feat: RvcManager and reference (part 1)

[zly2006]

Description/描述

RVC: Reference

For many fields such as storage tech, people will make some slices that,
for example, each slice can filter a single type of item.

However, when you want to test them, you have to stack them together, which is very inconvenient.
RVC Reference can help you to place a "reference" of a slice, once you finished your slice,
you can press a hotkey, and the reference will be updated to the latest version of the slice.
Happy debugging!

Related Issues/相关的 issue

#83

Checklist/清单

• Create reference
• Reference serialization to save to disk and send to network
• Use git submodule as reference
• Sync referrers with when referenced part changed
• Renderers
• Remove reference and delete referrers
• Remove reference and keep referrers (Convert them to RVC subregions)
• Replace reference

Screenshots

[zly2006]

@lovexyn0827 @wafarm @Cubik65536 有空review一下吗？主要看看设计，命名，以及需求计划等等，这个还在初步阶段还好改，如果有可能的问题尽快处理

[lovexyn0827]

非常好的想法！

不过，根据实践，还是感觉需求当中有几处是可以补充一下的：

• 不同位置的reference实际对应的具体内容可能略有不同，比如全物品仓库当中不同的单片可能对应不同的物品，需要对这一点进行特殊处理（暂时想得到解决方法有在reference当中放置不替换原有方块的空位，自定义各种细节相应的规则（依赖reference当中预先放置、功能类似方法参数的留空），或者借助scarpet处理）
• 在设计进行到一半时有可能会突然地发现设想的装置无法用单片来实现，而需改用多层单元的堆叠，对这种变更可以添加一种更便捷或自动化的操作方法（可能还需考虑对两端的结构与相关的附属结构的附带变更）
• 横向大小变更后，有可能需要对整个装置中的reference与其他结构进行再次对齐，会需要一个批量调整位置的功能（范围选择的话个人倾向于用指令实现，不过按照模组现有的风格应该还是基于GUI的多选+区间选择更合适（两者也各有各的优势））（周围附属结构（如水道收集）的移动也有自动化的可能，但一般没有太多的需求，毕竟投影和WorldEdit也有一套解决方案）
• 可以考虑加入类似于WorldEdit中//stack（等？）指令的功能以便大量放置reference

（不知道最近有没有时间来写一些qwq)【手动狗头】

[zly2006]

• 不同位置的reference实际对应的具体内容可能略有不同，比如全物品仓库当中不同的单片可能对应不同的物品，需要对这一点进行特殊处理（暂时想得到解决方法有在reference当中放置不替换原有方块的空位，自定义各种细节相应的规则（依赖reference当中预先放置、功能类似方法参数的留空），或者借助scarpet处理）

// com.github.zly2006.reden.rvc.tracking.reference.StructureReference.SyncMode
// 同步的内容逐渐增多
    enum class SyncMode {
        ChangedBlocks,
        AllBlocks,
        ChangedBlockEntities,
        AllBlockEntities,
        Entities,
    }

• 在设计进行到一半时有可能会突然地发现设想的装置无法用单片来实现，而需改用多层单元的堆叠，对这种变更可以添加一种更便捷或自动化的操作方法（可能还需考虑对两端的结构与相关的附属结构的附带变更）

不会考虑

• 横向大小变更后，有可能需要对整个装置中的reference与其他结构进行再次对齐，会需要一个批量调整位置的功能（范围选择的话个人倾向于用指令实现，不过按照模组现有的风格应该还是基于GUI的多选+区间选择更合适（两者也各有各的优势））（周围附属结构（如水道收集）的移动也有自动化的可能，但一般没有太多的需求，毕竟投影和WorldEdit也有一套解决方案）

（类似PR中波纹剪辑啥的？）
暂时还没考虑这个，而且以目前来说实现会很麻烦，如果你有更多的想法请随时补充以便调整设计，我倾向于可以做

• 可以考虑加入类似于WorldEdit中//stack（等？）指令的功能以便大量放置reference

有计划做，会使用gui实现。可以说是x/z上赛上两个for循环，TODO

[lovexyn0827]

• 不同位置的reference实际对应的具体内容可能略有不同……

// com.github.zly2006.reden.rvc.tracking.reference.StructureReference.SyncMode
// 同步的内容逐渐增多
    enum class SyncMode {
        ChangedBlocks,
        AllBlocks,
        ChangedBlockEntities,
        AllBlockEntities,
        Entities,
    }

也是一种办法，不过还是有几个问题，一方面，如果默认设置为同步内容最多的选项的话就有可能会因为误操作而替换掉本不该被替换的部分；再一方面就是，这种方法没有处理到某个方块实体的NBT只有一部分分属每个instance而另一部分可能随reference整体的变更而改变这样的corner case（可以添加MergeChangedBlockEntities这样的选项来解决，但这又涉及一个冲突处理的问题）；还有，如果全物品单片中的漏斗改变了位置，直接同步的话原来漏斗当中的内容就会丢失。

现在再看还是倾向于支持在结构中添加类似与方法参数的“待定内容”这种方案（尽管再添加这一的功能能提高设计的自由度，但是这样又会导致工作量&用户学习难度++）。

• 在设计进行到一半时有可能会突然地发现设想的装置无法用单片来实现，而需改用多层单元的堆叠，对这种变更可以添加一种更便捷或自动化的操作方法（可能还需考虑对两端的结构与相关的附属结构的附带变更）

不会考虑

不处理附带的非reference结构这一特性可以考虑和下面一项合并一下，也就是在批量移动reference位置时支持2x+406（将放置原点的x坐标移动到原x坐标的2倍加上406[整个堆叠的起点坐标]）这样的位置选定语法，这样也就实现了在更改了reference的厚度后半自动地相应地移动相关reference的需求。

• 横向大小变更后，有可能需要对整个装置中的reference与其他结构进行再次对齐，会需要一个批量调整位置的功能（范围选择的话个人倾向于用指令实现，不过按照模组现有的风格应该还是基于GUI的多选+区间选择更合适（两者也各有各的优势））（周围附属结构（如水道收集）的移动也有自动化的可能，但一般没有太多的需求，毕竟投影和WorldEdit也有一套解决方案）

（类似PR中波纹剪辑啥的？） 暂时还没考虑这个，而且以目前来说实现会很麻烦，如果你有更多的想法请随时补充以便调整设计，我倾向于可以做

有相似之处。但有个问题是，增大reference的大小后新同步过来的方块可能会覆盖掉reference以外的一些结构，需要让用户先行预览确认一下。

还有一条刚想起来可以补充一下，有时候同一个reference可能会被用在多个机器当中，可能有必要对reference进行分组。（可以考虑借助既有的机器范围自动完成）

[zly2006]

• 不同位置的reference实际对应的具体内容可能略有不同……

// com.github.zly2006.reden.rvc.tracking.reference.StructureReference.SyncMode
// 同步的内容逐渐增多
    enum class SyncMode {
        ChangedBlocks,
        AllBlocks,
        ChangedBlockEntities,
        AllBlockEntities,
        Entities,
    }

也是一种办法，不过还是有几个问题，一方面，如果默认设置为同步内容最多的选项的话就有可能会因为误操作而替换掉本不该被替换的部分；再一方面就是，这种方法没有处理到某个方块实体的NBT只有一部分分属每个instance而另一部分可能随reference整体的变更而改变这样的corner case（可以添加MergeChangedBlockEntities这样的选项来解决，但这又涉及一个冲突处理的问题）；还有，如果全物品单片中的漏斗改变了位置，直接同步的话原来漏斗当中的内容就会丢失。

现在再看还是倾向于支持在结构中添加类似与方法参数的“待定内容”这种方案（尽管再添加这一的功能能提高设计的自由度，但是这样又会导致工作量&用户学习难度++）。

使用结构空位那个方块？可以用来替换方块或者物品

• 横向大小变更后，有可能需要对整个装置中的reference与其他结构进行再次对齐，会需要一个批量调整位置的功能（范围选择的话个人倾向于用指令实现，不过按照模组现有的风格应该还是基于GUI的多选+区间选择更合适（两者也各有各的优势））（周围附属结构（如水道收集）的移动也有自动化的可能，但一般没有太多的需求，毕竟投影和WorldEdit也有一套解决方案）

（类似PR中波纹剪辑啥的？） 暂时还没考虑这个，而且以目前来说实现会很麻烦，如果你有更多的想法请随时补充以便调整设计，我倾向于可以做

有相似之处。但有个问题是，增大reference的大小后新同步过来的方块可能会覆盖掉reference以外的一些结构，需要让用户先行预览确认一下。

of course

还有一条刚想起来可以补充一下，有时候同一个reference可能会被用在多个机器当中，可能有必要对reference进行分组。（可以考虑借助既有的机器范围自动完成）

可以，但是比较麻烦，我没空弄所以欢迎contribute

[zly2006]

我在考虑reference是不是应该算作一种tracker？

/**
 * track a structure's part, listen to block changes and update the positions of the tracked blocks.
 * provide a way to iterate through the tracked blocks.
 */
@Serializable
sealed class StructureTracker

但是reference看起来不像是可以Serializable的样子，给加载保存部分开个洞还是单独保存？
强调并再次请求关于命名和类结构设计以及其他相关内容提出建议，否则难以推进此特性 @Cubik65536 @Zaiyuyou

[zly2006]

考虑先merge此PR以引入RvcManager。