M2ke4U

> 怎么回事哥们 怎么把我DirtyFolia的屎山bug一起搬来了 https://github.com/LuminolMC/LightingLuminol/commit/bea112c6913b98dce83610ddac1e61abace64a1b https://github.com/Era4FunMC/DirtyMolia/

> > 怎么回事哥们 怎么把我DirtyFolia的屎山bug一起搬来了 > > [bea112c](https://github.com/LuminolMC/LightingLuminol/commit/bea112c6913b98dce83610ddac1e61abace64a1b) https://github.com/Era4FunMC/DirtyMolia/ 

哥们你这

> > 哥们你这 > > 怎么卡区块毛病一样有啊 跟我写的屎山的毛病一样  

> > 哥们你这 > > 怎么卡区块毛病一样有啊 跟我写的屎山的毛病一样 还有你getChunk直接就那样返回已经加载了的查询但是这个并不是

> > 哥们你这 > > 怎么卡区块毛病一样有啊 跟我写的屎山的毛病一样 worlddata分配的参考的df但是也不是照搬过来的

> > > 哥们你这 > > > > > > 怎么卡区块毛病一样有啊 跟我写的屎山的毛病一样 > > worlddata分配的参考的df但是也不是照搬过来的 还有计分板的锁那个是我早期项目搬过来的而且你这写的也不是会各种爆炸的吗

> > > > > 哥们你这 > > > > > > > > > > > > 怎么卡区块毛病一样有啊 跟我写的屎山的毛病一样 > > > > > > > > > worlddata分配的参考的df但是也不是照搬过来的...

> > 这个fork也是这样，我主要开发力并不在这上面，而且我还要中考没空管这么多，还有旧版本的机制和这个完全不一样而且比这个更稳定但是内存泄漏 > > 是的 其实过度的去兼容bukkit生态并不是一件好事 在我看来应该把空间留给原生的folia插件 > 毕竟我们做调度兼容没办法精确到对象 在对不同对象的操作上还是有很多存在的问题 例如跨区块操作 > 这样就很难去精确到调用的目标位置并匹配对应的调度器(如果强制在调度器里执行还要考虑线程切换造成的损耗) > 很多问题在这里需要去解决 有许多问题没办法但从修改来解决 > 可能要使用到字节码分析在插件的类被加载的时候通过分析从字节码层匹配对应的调度器 但这样需要极高的水平而且极难做成 分析就是很大的难题 要尽量精确的匹配到目标区块还是很困难的 > > 这也许是未来的方向 但是稳定性可能还不如现在的好 而且编写起来极为麻烦 我当时把getworlddata的全改成了我之前写的一个worlddatapool里获取的，然后那边调用的folia的不是自己存储的但是还是内存泄漏了

> > 我当时把getworlddata的全改成了我之前写的一个worlddatapool里获取的，然后那边调用的folia的不是自己存储的但是还是内存泄漏了 > > 其实我有兴趣在我刚刚说的那个方向上去研究 之前做DirtyFolia的时候跟老外讨论过这个问题 > 理论上来说通过字节码处理兼容folia是十分有可能的 > 类似与banner模组或者别的一些跨平台兼容的东西(插件平台应为典型) 对字节码重新映射来兼容mod平台所使用的映射 > 只不过更为复杂 需要考虑到上下文字节码 并添加调用调度器的代码 > > 如果你对这个也有兴趣的话 其实暑假可以一起研究这个 这样做可以避免很多魔改造成的问题 ``` ```这个fork只是考虑到我好友需求做的，刚开始也就加回来个craftscheduler后面我自己也要用了才开始大规模魔改的（），如果想聊聊的话QQ群里罢（）