关于CoreMod合规化的初步提案
## 提案
### 破冰
将 "Mod 区管理规定与细则"中"原创Mod发布"中的第二项规定
`不得对游戏本体（非配置文件数据）进行修改`
更改为：
`不得在用户不知情或未经用户允许的情况下，对游戏本体（非配置文件数据）进行修改`
### 规范
在当下，CoreMod以及包含CoreMod的模组应当与完全转换模组同样被视为一种独立的类别，并使用特定于此的标准、规范以及合规性要求。
具体标准、规范有待商讨
## 理由
### Context
在Mikohime Java升级套件开创性地将`侵入式修改`这一概念正式引入Starsector Modding社区后，越来越多的modder意识到自己可以类似的方式做到更多的东西。
~~（至于以前为什么没有你别问，抱怨的全被踩头了）~~
`侵入式修改`技术使得我们能够轻易做到原版游戏所不能够做到的事情，并且在当下已经有了许多使用这一技术的模组：
FastRander 通过滥用类路径机制与桥接方法修改原版类
PatchLib 通过使用自附加Agent动态转换原版类
MixinLib & PEI 通过使用PreMain Agent转换原版类
而这无不说明`侵入式修改`技术正在进入更多modder的视野中
并且，是的，我们总有一天是会需要它的。
但现在有一个小小的问题
### 不可能三角
> 无文件修改、持久化、正确的早期入口点
目前我们已知的所有`侵入式修改`技术都不可能在不修改游戏文件的同时持久化并能够获取正确的（足够早的）初始化时机。
他们不可兼得。
或许有些观众并不清楚这是一种什么样的情况，就是说，如果我解决了这个不可能三角，我基本上可以直接写一份CVE报告。
持久化的最佳方法是修改启动文件，但那样不合规（并且其他的思路比这个更加的不合规）。
无文件修改要求在原版模组框架内启动，这导致无法获取正确的入口点。
无文件修改且正确的入口点？这个是滚木，根本不可能做到。
所以是的，我们没招了。
### 一个足够合理的例子
作为国内黑魔法潮流的响应者，MixinLib采取了一种处在规则边缘的安装方式——
模组Jar同时作为Agent Jar存在，在目录中附带安装脚本的同时明确指引用户正确安装。
MixinLib（自动地、不受用户意志干涉地）修改了游戏本体的文件吗？并没有。
MixinLib修改了游戏吗？从结果上看，是的。
那谁修改了文件？用户。
用户将在这一过程中逐渐理解自己这么做的风险，而模组也能够完美的运转，双赢。
### 风险
我们清楚的知道，每一条规定都不是无来由的，每一条规定背后必然存在一些我们所不知晓的事情。
显然，禁止对游戏修改这一规定暗示着潜在的恶意行为者群体，但我们有必要意识到一件事——
恶意行为者并不会因为规定存在而停止行动，但有合规意愿的开发者会因此受限。
另外目前已经有无数种方法绕过游戏的原生限制，并且A圣脑子抽了没禁止Runtime.Exec。
~~（所以在这种情况下我并不认为安全性是什么有足够说服力的东西，en那边有人上传用户数据好几个月才被人发现，我已经打算不指望什么了。）~~
我们本质上只是希望能够在一个更宽松的技术指标下编写`侵入式修改`模组(CoreMod)，并在一个更加明确且更具指导性的标准下发布它。
## END
在最后的最后，感谢您阅读本人的提案，这份提案可能不完整且充满漏洞，但这正是正式讨论这一问题的绝佳时机，在此本人欢迎各位对此进行讨论、反驳与补充。
不明觉厉{:5_118:} 我说alex懂个p远星，早晚有一天会有人受不了这些代码自己做一个ss2出来 等等, 这是啥意思, 意思是远神某些模组指派java..执行非游戏工作动作? {:tieba_20:}
如..前置模组luna那个联网更新检查, 防火墙拦截ping不通硬控满加载条, 让游戏白屏等待?
突然觉得..这像是某种特别的预警嘛? 告知用户远神mod可跨越如此程度?
毕竟通常只发生在错误出现时嘛, mod并不需要总是更新. 感觉这样解读也蛮合理的吼{:tieba_30:} 仅代表个人非论坛发言：
个人觉得确实没毛病，Alex在事实上是默许这些的存在的
实际上Alex已经和我透露过下版本要给java agent官方入口了（会不会做另说，反正意思是至少让javaagent不需要modder修改/覆盖vmparams就能加载） 议长不死于锉刀 发表于 2026-8-13 14:48
仅代表个人非论坛发言：
个人觉得确实没毛病，Alex在事实上是默许这些的存在的
实际上Alex已经和我透露过下 ...
这是好事啊.JPG 经管理组讨论，决定修改 Mod区管理规定 中的相关条目，修改记录如下：
2026年8月13日 2.5.0
- 删除了 原创Mod发布->规定 -> 2.不得对游戏本体（非配置文件数据）进行修改
- 添加了 通用规定 -> 2. **禁止发布**符合以下任意情况的Mod： -> 6. 在未告知或未经用户允许的情况下，对游戏本体（配置文件除外）进行修改、连接网络或读写游戏目录以外的文件的 我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊
不过看前面所说的担忧，好像这里指的“改原版”不止是改数据，还涉及到一些安全问题？有大佬解释一下吗？ Ir1s 发表于 2026-8-13 14:57
我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊 ...
安全性问题这种都差不多，例如恶意修改游戏文件导致游戏不能正确运行，或者获取用户信息并上传等等。
倒不如说alex在这一块比较滞后，毕竟你远还有类名字是Oo00o00Oo0这样的作为混淆防护，然而用处和棍木差不多 让我们加速基建吧{:tieba_12:} 这是好事啊，支持支持！ 很显然新时代需要新方法 时代不一样了，AI都能编程+翻译了。把Modder限制在A圣的神秘代码里没必要。 我觉得侵入式模组（点名最近的miko+java28+FR多线程+VO图像组合），在可以做到通过替换启动器、实现多线程、优化多mod图片索引加载方式的逻辑，完全应该成为一种新的独立的MOD标准，他对于游戏使用者的帮助是实打实的，切实可见的 Ir1s 发表于 2026-8-13 14:57
我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊 ...
安全性合规这块还是要审查的，恶意代码事后有问题支持追责{:5_118:}，但是确实应当在当前的情况下，应当要求并建议侵入性模组必须明确说明，并基于下载者自行判定风险
不过要是大肥鱼写的工具性质侵入性模组一般也不会被恶意攻击，再来就是混淆防护对AI开发没意义了其实，都能读出来 评价是，时间不在mixinlib这边。可用的lib需要用心维护或者详尽的文档，或者一个确实使用它的好mod做证明。不是一时兴起，研究了点东西扔进去，留下一些可疑又无说明的程序。
FR或者Patchlib这种小步快跑反而能做成甚至成为事实标准。 本帖最后由 GerBeria 于 2026-10-30 22:27 编辑
ykk488 发表于 2026-10-30 18:26
评价是，时间不在mixinlib这边。可用的lib需要用心维护或者详尽的文档，或者一个确实使用它的好mod做证明。 ...
额，我想说是mixinlib本质上只是用双jvm架构成功的把mc的SpongePowered Mixin搬了过来，所以它在某种意义上说还真不用自己出文档，长期维护也用不到，顶多游戏本体版本更新后重新适配或者更新一下内置mixin框架？
另外，我之所以为mixinlib说这么多纯粹因为我发现nanoforge和patchlib好像更受欢迎，而我已经在mixinlib上投入了太多。毕竟这三个是天生的竞争关系，社区好像也供不起三生态并存
本帖最后由 ykk488 于 2026-10-30 23:08 编辑
GerBeria 发表于 2026-10-30 22:22
额，我想说是mixinlib本质上只是用双jvm架构成功的把mc的SpongePowered Mixin搬了过来，所以它在某种意义 ...
或者说比起SpongePowered Mixin的可信度，更需要证明“搬过来”这个行为的可信度和稳定性，实际上也看到已经需要修改原mixinlib做分支来尝试同时兼容A/B/C。这步必须得快，因为别人也在做，甚至可能比你做的更好。
而且假设我是没有Minecraft Modding先验知识的人，并不能从发布页面得到任何有关上游SpongePowered Mixin的信息做帮助，很显然是把外部隐式内容作为公共知识的一点傲慢。 凑个热闹{:5_117:}
页:
[1]