RFBAngelicaRedirector

基本信息

属性 值
类 com.gtnewhorizons.angelica.loading.rfb.transformers.RFBAngelicaRedirector
路径 src/main/java/com/gtnewhorizons/angelica/loading/rfb/transformers/RFBAngelicaRedirector.java
行数 11
类型 public class ... extends RfbModRedirector（:7）
内部实现 shared/AngelicaRedirector

它是什么

3 个 RFB transformer 中最小的。全部逻辑一行：

// :9-11
public RFBAngelicaRedirector() {
    super("redirector", AngelicaRedirector.create());
}

RfbModRedirector 基类在 glsm 子项目，与 LaunchWrapper 侧的 ModRedirector 同源。

挂在哪个阶段

RFB（RetroFuturaBootstrap）类加载阶段。由 AngelicaRfbPlugin.makeTransformers :29-35 返回的 3 元数组中排第一位：

return new RfbClassTransformer[] {
    new RFBAngelicaRedirector(),
    new RFBCeleritasBlockTransformer(isObf),
    new RFBIsbrhTessellatorAbuseTransformer(isObf)
};

无条件构造（isServer 判定在 plugin 层完成，:24-27）。

与 FML 侧的不对称

FML 侧 RFB 侧
类 AngelicaRedirectorTransformer（15 行） 本类（11 行）
注册 AngelicaClientTweaker 反射改 tweak 列表 META-INF/rfb-plugin SPI 声明
排序 靠 AngelicaLateTweaker 手工放到 mixin 之后 RFB 原生排序机制
构造参数 无 无

FML 侧比 RFB 侧多 4 行——多出的是 transform 方法体。RFB 侧的 transform 由基类 RfbModRedirector 提供，本类无需覆写。

这正是 RFB 路径存在的价值：FML 侧因为 AngelicaTweaker :15-21 自陈的排序索引缺陷，被迫用反射 workaround 手工控制 transformer 位置；RFB 路径有原生排序，不需要这套 hack。

已知问题

  1. 无 id() 覆写：另两个 RFB transformer（RFBCeleritasBlockTransformer :30-32 返回 "sodiumblocktransform"、RFBIsbrhTessellatorAbuseTransformer :28-30 返回 "isbrh-tessellator-abuse"）都实现了 RfbClassTransformer.id()，本类依赖基类 RfbModRedirector 的 id 实现（构造参数 "redirector" 可能就是 id）。若 RFB 要求 id 唯一且本类的 id 与另两个冲突或缺失，会在加载期报错。
  2. 无排序声明：另两个都实现了 sortAfter/sortBefore（{"*", "mixin:mixin"} / {"lwjgl3ify:redirect"}），本类两个都没实现，依赖基类默认值。对比 RFBCeleritasBlockTransformer :34-42 明确要求排在 mixin:mixin 之后、lwjgl3ify:redirect 之前——本类缺少同等约束，排序位置不确定。
  3. 11 行无任何注释。

相关条目