和ReplayTheSpire模组的不兼容：
完全是它全责，查阅报错信息可以得知：
com.megacrit.cardcrawl.orbs.AbstractOrb.renderText
replayTheSpire.patches.ReplayOrbRenderTextPatch.Prefix
java.lang.ArrayIndexOutOfBoundsException: -1
==========
它为了给自己的GlassOrb充能球添加特殊的显示数字效果（就是充能球图片上的那些受集中影响数字），居然没有@Override，而是直接PrefixPath了杀戮尖塔充能球最底层的renderText函数。然后导致了错误。
它出错的代码为：AbstractDungeon.player.orbs.get(AbstractDungeon.player.orbs.size() - 1)==_instance，这一看就是个很容易导致数组溢出的代码，正确的写法应该在之前加上AbstractDungeon.player.orbs != null 和 AbstractDungeon.player.orbs.size() > 0，我觉得这是最基本的安全意识，除非你操作的所有东西都是你自己模组的东西，你知道某些情况不可能会发生。
==========
经过猜测，ReplayTheSpire认为，如果一个模组在某个地方绘制一个充能球，那个模组的角色的“所有充能球中”就会有充能球。所以它认为没必要检测这部分。但是实际上我的模组在角色本体没有充能球（注意，不是充能球位而是充能球）的情况下在另一个位置绘制了一个充能球，于是导致了它的数组溢出。但是这是我的错吗？我不认为。
很显然，在进行这一高危险操作时，它完全没有意识到什么值可能为空，什么地方可能溢出，只考虑了自己模组的情况。
任何模组作者都有权力在任何地方绘制一个充能球，甚至有理由把充能球作为模组的攻击特效，或者把充能球绘制在卡牌上、遗物里、药水中，把充能球悬挂在怪物身上作为一个攻击怪物的机制，作为浮游炮特效，等等，而不是只在角色本体有充能球的情况下才绘制一个充能球。那样的话我们的生活该有多么无趣？
==========
关键问题是，它的这个目的应该是不需要patch renderText就能写出来的，如果它只是想要为自己的GlassOrb充能球添加特殊的文字处理，完全可以重写整个renderText函数，因为这个函数的权限是protected，是完全可以覆盖的。
甚至它本身就是在检测是否为GlassOrb后莫名其妙的又去获取了别的东西导致的错误。为什么要这么做？为什么不在之前加上检测？为什么不直接@Override？
==========
虽然我可以通过path它的path去修复这个bug，但是我不是他妈，我没有义务为别人糟糕透顶的代码做任何事情。
同时，这个模组多半还会和一大堆其他的模组冲突，而且它21年以后就没有更新了，很显然它并不是自己声称的所谓“有史以来最好的杀戮尖塔模组”。
==========
LoadOut模组对我自己写的buff体系也不起效，但是我修复了这个bug，这是因为它的代码很好，模组很实用，适用性很强，而且持续更新。而且，就算它对我的模组不起效，它也没有导致我的模组崩溃。