level 9
qweytr_123
楼主
事情的起因是这样子的：
在第N次开游戏启用Mod然后重启之后，我给茄子问了一句，能不能在开游戏的那个启动器里面修改Mod配置![[怒]](/static/emoticons/u6012.png)
茄子表示好像的确应该这么做![[黑线]](/static/emoticons/u9ed1u7ebf.png)
---
目前来说，茄子的人力并不充裕，于是程序员们没时间玩游戏。
所以，或许，除了汇报BUG之外，我们应该帮茄子画一下饼，告诉茄子应该修改什么，以及修改顺序是什么。
---
短期目标（这些是可以立刻完成的，几乎不会引入任何BUG）：
升级HarmonyX到最新版，好处是可以比较方便地修改迭代器
给启动器增加Mod管理器功能
在商店买东西时候，如果交易不为空，右键退出时应当做提示
（误触导致退出商店是一件很痛苦的事情）
中期目标（这里是一些新内容，比较容易做，而且做完的好处显而易见）：
1. 排序：
送礼时按好感而不是价值排序
祠堂按资质排序
物品排序加入“按种类”，这样可以把相似的物品归类到一起。目前的按名称，重量，品阶，价值排序时，我们没办法把相似物品归类到一起。
2. “蓝图”系统：
蓝图的主要好处是，可以预览，可以在确认之前撤销修改
这样，只需要在提交时进行确认，不必确认每一次更改
2a) 允许先规划后支付资源
比如可以允许在建筑未解锁时预先规划建筑，在人力不足时预先规划拆除
自然资源不应该扩张到规划建筑之上
在规划之后，程序应当自动分配有空闲的村民来完成任务。
由程序分配的好处是，玩家不必担心自己分配的那个厨艺为0的家伙，其杂学是否高于100
某种程度上这样可以节省一定的玩家脑力和太吾村劳力。
2b) 允许存储默认功法模板
每次突破功法都需要选择6个词条，而玩家往往只会从两个模板中进行选择（正练一个，逆练一个）
这里希望允许游戏在突破的时候，先按模板选择词条，再自动选择没有歧义的词条（比如字诀只有一个的话，自动锁定这个字诀，字诀有多个就看模板怎么选）
这样的好处是可以让突破变得简单，而不必让玩家每次突破都选一圈词条（特别是你只读完了一本书的时候，选一圈词条真的不怎么好看）
2c) 祠堂灌顶的默认模板
默认模板包含全部技艺的模板，和几个自定义功法模板。如果不选定模板，灌顶时按普通流程灌顶
选定模板时，进入批量灌顶模式，每次点击人物都应当生成一个“给这个人物灌顶这个模板中最靠前的可以灌顶的功法”的任务。可以选择是否生成暂时无法完成的任务（比如20岁的太吾给一个人灌顶4次，或者太吾灌顶一个自己还没有学会的功法）
由于这里是灌顶任务，所以可以自由地修改（而不必每次灌顶都预先确认）
在安排完任务之后，可以点击“完成灌顶”按钮按顺序批量执行任务，不成功的灌顶任务保留到下一次灌顶执行。
更远一些的目标（放在这里的目标是应当完成，但是因为存在BUG等原因，完成这些工作并不容易）：
1. 批量买卖商品
目前想买卖商品只能挨个确认取消
但，比如说玩家想卖掉所有8品以下的资源，那么玩家就只能筛选完了一个一个确认
如果可能的话，应该配合排序系统，做一个批量选中。玩家只需要选择开始物品和结束物品，之后程序会自动将选中范围内的全部物品进行购买/出售
2. 前端优化
目前太吾非常卡，前端甚至跑不满48帧（不要吐槽，我习惯性地锁48）
如果能找到是什么导致了卡顿，最好解决这个问题。
3. Mod系统升级
目前的Mod系统跟...没有任何区别
经过实践，我发现一个mod的新写法，格式大致为
[Desc("描述",默认值)]
class Patch : TaiwuSlider {
public static int val; // 你可以把变量定义在class内部，而不必把变量统一定义在初始化mod的class里面
// 这里填int是因为太吾绘卷的Slider只接受int，简单扩展一下，比如如果我们希望增加一个文本格式的entry，这里也可以用string
public void Init() {base.Init(ref val);} // 多数情况下每一个patch只会拥有一个变量，所以固定使用这样的Init已经足够
// 以下开始patch
}
实践中，大于等于0的值默认为Mod生效，小于0的值默认为Mod失效，不会导致任何问题
这样写BepInEx mod会比先写config.Bind<int>(...)方便很多
具体实现可以看https://gitee.com/Neutron3529/MiChangSheng_Mod/blob/master/utils.cs，这些内容虽然是针对BepInEx的，但改到太吾并不会有太大问题
——或者说太吾早就该改一改了。
BepInEx是支持在C#代码里面创建ConfigEntry的，如果是太吾，你必须先写lua，再到C#里面读取参数，最后使用参数完成patch，这三步错一步都会导致patch读不到正确数据
虽然说现在的确可以写Mod，但Mod写起来非常痛苦。
或许Mod应该把config和settings分开，config里面不涉及Mod的各个配置项，Mod的配置项应当由类似Config.Slider("键值","描述",默认值,最小值,最大值,步长)这样的代码生成（和读写）
（就像bepinex mod做的那样）
4. 后端函数拆分
目前来说，后端的部分函数实在过于复杂
比如战斗部分，如果想做战斗系统的Mod（比如做一个更智能的战斗AI），我们必须阅读整个战斗系统的Update逻辑
类似的大函数完全有拆分的可能，如果把类似函数拆分成多个小函数，可以在一定程度上方便modder进行修改。
（这是当年玩茶马帮时候发现的，茶马帮逻辑小几百行根本不是正常人应该看的东西……）
我暂时只能想到这么多饼了
大家可以一起来画饼，也可以做一下排序和补充。
或许这里写的东西，太吾一个都不会做
但万一呢？
2023年03月22日 05点03分
1
在第N次开游戏启用Mod然后重启之后，我给茄子问了一句，能不能在开游戏的那个启动器里面修改Mod配置
茄子表示好像的确应该这么做
---
目前来说，茄子的人力并不充裕，于是程序员们没时间玩游戏。
所以，或许，除了汇报BUG之外，我们应该帮茄子画一下饼，告诉茄子应该修改什么，以及修改顺序是什么。
---
短期目标（这些是可以立刻完成的，几乎不会引入任何BUG）：
升级HarmonyX到最新版，好处是可以比较方便地修改迭代器
给启动器增加Mod管理器功能
在商店买东西时候，如果交易不为空，右键退出时应当做提示
（误触导致退出商店是一件很痛苦的事情）
中期目标（这里是一些新内容，比较容易做，而且做完的好处显而易见）：
1. 排序：
送礼时按好感而不是价值排序
祠堂按资质排序
物品排序加入“按种类”，这样可以把相似的物品归类到一起。目前的按名称，重量，品阶，价值排序时，我们没办法把相似物品归类到一起。
2. “蓝图”系统：
蓝图的主要好处是，可以预览，可以在确认之前撤销修改
这样，只需要在提交时进行确认，不必确认每一次更改
2a) 允许先规划后支付资源
比如可以允许在建筑未解锁时预先规划建筑，在人力不足时预先规划拆除
自然资源不应该扩张到规划建筑之上
在规划之后，程序应当自动分配有空闲的村民来完成任务。
由程序分配的好处是，玩家不必担心自己分配的那个厨艺为0的家伙，其杂学是否高于100
某种程度上这样可以节省一定的玩家脑力和太吾村劳力。
2b) 允许存储默认功法模板
每次突破功法都需要选择6个词条，而玩家往往只会从两个模板中进行选择（正练一个，逆练一个）
这里希望允许游戏在突破的时候，先按模板选择词条，再自动选择没有歧义的词条（比如字诀只有一个的话，自动锁定这个字诀，字诀有多个就看模板怎么选）
这样的好处是可以让突破变得简单，而不必让玩家每次突破都选一圈词条（特别是你只读完了一本书的时候，选一圈词条真的不怎么好看）
2c) 祠堂灌顶的默认模板
默认模板包含全部技艺的模板，和几个自定义功法模板。如果不选定模板，灌顶时按普通流程灌顶
选定模板时，进入批量灌顶模式，每次点击人物都应当生成一个“给这个人物灌顶这个模板中最靠前的可以灌顶的功法”的任务。可以选择是否生成暂时无法完成的任务（比如20岁的太吾给一个人灌顶4次，或者太吾灌顶一个自己还没有学会的功法）
由于这里是灌顶任务，所以可以自由地修改（而不必每次灌顶都预先确认）
在安排完任务之后，可以点击“完成灌顶”按钮按顺序批量执行任务，不成功的灌顶任务保留到下一次灌顶执行。
更远一些的目标（放在这里的目标是应当完成，但是因为存在BUG等原因，完成这些工作并不容易）：
1. 批量买卖商品
目前想买卖商品只能挨个确认取消
但，比如说玩家想卖掉所有8品以下的资源，那么玩家就只能筛选完了一个一个确认
如果可能的话，应该配合排序系统，做一个批量选中。玩家只需要选择开始物品和结束物品，之后程序会自动将选中范围内的全部物品进行购买/出售
2. 前端优化
目前太吾非常卡，前端甚至跑不满48帧（不要吐槽，我习惯性地锁48）
如果能找到是什么导致了卡顿，最好解决这个问题。
3. Mod系统升级
目前的Mod系统跟...没有任何区别
经过实践，我发现一个mod的新写法，格式大致为
[Desc("描述",默认值)]
class Patch : TaiwuSlider {
public static int val; // 你可以把变量定义在class内部，而不必把变量统一定义在初始化mod的class里面
// 这里填int是因为太吾绘卷的Slider只接受int，简单扩展一下，比如如果我们希望增加一个文本格式的entry，这里也可以用string
public void Init() {base.Init(ref val);} // 多数情况下每一个patch只会拥有一个变量，所以固定使用这样的Init已经足够
// 以下开始patch
}
实践中，大于等于0的值默认为Mod生效，小于0的值默认为Mod失效，不会导致任何问题
这样写BepInEx mod会比先写config.Bind<int>(...)方便很多
具体实现可以看https://gitee.com/Neutron3529/MiChangSheng_Mod/blob/master/utils.cs，这些内容虽然是针对BepInEx的，但改到太吾并不会有太大问题
——或者说太吾早就该改一改了。
BepInEx是支持在C#代码里面创建ConfigEntry的，如果是太吾，你必须先写lua，再到C#里面读取参数，最后使用参数完成patch，这三步错一步都会导致patch读不到正确数据
虽然说现在的确可以写Mod，但Mod写起来非常痛苦。
或许Mod应该把config和settings分开，config里面不涉及Mod的各个配置项，Mod的配置项应当由类似Config.Slider("键值","描述",默认值,最小值,最大值,步长)这样的代码生成（和读写）
（就像bepinex mod做的那样）
4. 后端函数拆分
目前来说，后端的部分函数实在过于复杂
比如战斗部分，如果想做战斗系统的Mod（比如做一个更智能的战斗AI），我们必须阅读整个战斗系统的Update逻辑
类似的大函数完全有拆分的可能，如果把类似函数拆分成多个小函数，可以在一定程度上方便modder进行修改。
（这是当年玩茶马帮时候发现的，茶马帮逻辑小几百行根本不是正常人应该看的东西……）
我暂时只能想到这么多饼了
大家可以一起来画饼，也可以做一下排序和补充。
或许这里写的东西，太吾一个都不会做
但万一呢？
![[阴险]](/static/emoticons/u9634u9669.png)
