关于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

在最后的最后，感谢您阅读本人的提案，这份提案可能不完整且充满漏洞，但这正是正式讨论这一问题的绝佳时机，在此本人欢迎各位对此进行讨论、反驳与补充。

墨语流年恰似水

不明觉厉

ValeryMoskaunia

我说alex懂个p远星，早晚有一天会有人受不了这些代码自己做一个ss2出来

AIYHBVDCX

等等, 这是啥意思, 意思是远神某些模组指派java..执行非游戏工作动作?
如..前置模组luna那个联网更新检查, 防火墙拦截ping不通硬控满加载条, 让游戏白屏等待?

突然觉得..这像是某种特别的预警嘛? 告知用户远神mod可跨越如此程度?
毕竟通常只发生在错误出现时嘛, mod并不需要总是更新. 感觉这样解读也蛮合理的吼

议长不死于锉刀

仅代表个人非论坛发言：
个人觉得确实没毛病，Alex在事实上是默许这些的存在的
实际上Alex已经和我透露过下版本要给java agent官方入口了（会不会做另说，反正意思是至少让javaagent不需要modder修改/覆盖vmparams就能加载）

雪夜晴岚

议长不死于锉刀 发表于 2026-8-13 14:48
仅代表个人非论坛发言：
个人觉得确实没毛病，Alex在事实上是默许这些的存在的
实际上Alex已经和我透露过下 ...

这是好事啊.JPG

星域杂工jn_xyp

经管理组讨论，决定修改 Mod区管理规定 中的相关条目，修改记录如下：

2026年8月13日 2.5.0
- 删除了 原创Mod发布->规定 -> 2.不得对游戏本体（非配置文件数据）进行修改
- 添加了 通用规定 -> 2. **禁止发布**符合以下任意情况的Mod： -> 6. 在未告知或未经用户允许的情况下，对游戏本体（配置文件除外）进行修改、连接网络或读写游戏目录以外的文件的

Ir1s

我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊
不过看前面所说的担忧，好像这里指的“改原版”不止是改数据，还涉及到一些安全问题？有大佬解释一下吗？

wither-pt

Ir1s 发表于 2026-8-13 14:57
我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊 ...

安全性问题这种都差不多，例如恶意修改游戏文件导致游戏不能正确运行，或者获取用户信息并上传等等。
倒不如说alex在这一块比较滞后，毕竟你远还有类名字是Oo00o00Oo0这样的作为混淆防护，然而用处和棍木差不多

Alphard

让我们加速基建吧

唐晓白

这是好事啊，支持支持！

灵能实体

很显然新时代需要新方法

742799201

时代不一样了，AI都能编程+翻译了。把Modder限制在A圣的神秘代码里没必要。

xippxioo

我觉得侵入式模组（点名最近的miko+java28+FR多线程+VO图像组合），在可以做到通过替换启动器、实现多线程、优化多mod图片索引加载方式的逻辑，完全应该成为一种新的独立的MOD标准，他对于游戏使用者的帮助是实打实的，切实可见的

xippxioo

Ir1s 发表于 2026-8-13 14:57
我这才意识到，原来此前竟然很少见修改原版内容的Mod
要知道在别的游戏里改原版可是像喝水一样常见的情况啊 ...

安全性合规这块还是要审查的，恶意代码事后有问题支持追责，但是确实应当在当前的情况下，应当要求并建议侵入性模组必须明确说明，并基于下载者自行判定风险
不过要是大肥鱼写的工具性质侵入性模组一般也不会被恶意攻击，再来就是混淆防护对AI开发没意义了其实，都能读出来

ykk488

评价是，时间不在mixinlib这边。可用的lib需要用心维护或者详尽的文档，或者一个确实使用它的好mod做证明。不是一时兴起，研究了点东西扔进去，留下一些可疑又无说明的程序。

FR或者Patchlib这种小步快跑反而能做成甚至成为事实标准。

GerBeria

ykk488 发表于 2026-10-30 18:26
评价是，时间不在mixinlib这边。可用的lib需要用心维护或者详尽的文档，或者一个确实使用它的好mod做证明。 ...

额，我想说是mixinlib本质上只是用双jvm架构成功的把mc的SpongePowered Mixin搬了过来，所以它在某种意义上说还真不用自己出文档，长期维护也用不到，顶多游戏本体版本更新后重新适配或者更新一下内置mixin框架？
另外，我之所以为mixinlib说这么多纯粹因为我发现nanoforge和patchlib好像更受欢迎，而我已经在mixinlib上投入了太多。毕竟这三个是天生的竞争关系，社区好像也供不起三生态并存

ykk488

GerBeria 发表于 2026-10-30 22:22
额，我想说是mixinlib本质上只是用双jvm架构成功的把mc的SpongePowered Mixin搬了过来，所以它在某种意义 ...

或者说比起SpongePowered Mixin的可信度，更需要证明“搬过来”这个行为的可信度和稳定性，实际上也看到已经需要修改原mixinlib做分支来尝试同时兼容A/B/C。这步必须得快，因为别人也在做，甚至可能比你做的更好。
而且假设我是没有Minecraft Modding先验知识的人，并不能从发布页面得到任何有关上游SpongePowered Mixin的信息做帮助，很显然是把外部隐式内容作为公共知识的一点傲慢。

3l psi

凑个热闹

全自动电棍

ykk488 发表于 2026-10-30 22:59
或者说比起SpongePowered Mixin的可信度，更需要证明“搬过来”这个行为的可信度和稳定性，实际上也看到已 ...

我不认为PatchLib是一个好的CoreMod框架因为它甚至打不过ClassTransform这个对Mixin的拙略模仿，并且显而易见地ClassTransform库它同样可以直接使用Agent引导甚至是attach agent，而我理论上可以构筑一个能够通过在JRE自附加来引导ClassTransform库的“传统”模组，而这个东西的易用性（无论是dx还是ux上）无疑是薄纱PatchLib的，最搞的是CT还部分兼容Mixin语法。
然后就是这个PatchLib疑似一个AI SLOP，并且是最糟的那种因为作者并没有调查竞品。
但我觉得PatchLib作者应该是C#写昏头了搞了一个Harmony类似物，因为PatchLib的目标选择器远远落后于Mixin和CT，比如说它似乎无法做到基于序号去精确地修改方法中的某个调用，这导致它用起来和Harmony差不多。


至于FR它则是回归了基本功，对于FR的作者我有一些同情他因为他必须编写一个JVM规范的映射转换器来处理一切狗屎混淆，并且他的Remapping手法则是非常、非常的复古的（以至于我不愿意想象由我本人来处理这些东西会发生什么）。

MixinLib是一个AI Slop这是毋庸置疑的，但你并不能怀疑Mixin确实是注解驱动类转换框架中最高的山。
“把外部隐式内容作为公共知识”这一点我认为这应该不至于称之为“傲慢”，如果你仔细观察远神的开发者背景你会发现几乎所有存在CoreMod需求(且倾向使用Mixin)的用户基本上都是某方块人游戏的开发者，因为没有这一背景的开发者通常会通过询问LLM然后得到一个使用JavaAgent的回答，然后他们就去用转换器了，换句话说懂的人自然都懂。我们并不能忽视这种双向的选择关系。


其实这些问题出现的主要原因是因为MixinLib它其实是一个纯粹的MVP，一个Prototype，it work但是只是works，所以不要过多奢求什么。
并且它的SLOP程度让我都懒得去维护。

另外目前有一个更加工程化，更加可用的Mixin Bootstrap正在开发中，应该是不会再出现这些问题了。
所以请关注NanoForged谢谢喵。