
但是并不是所有人都是cpp be good at,而且Runner的意义在于编写插件更esay,毕竟某些时候脚本语言比宿主语言在某些事件的处理上更便捷。如果是你这么说的话,如果所有的Runner都消失了,编写插件的门槛大大提高,不会出多少插件的。而且基于Runner的插件可以一次编写全版本运行,除非Runner停更。纯cpp插件即使是BDXC也要大版本重新适配,Runner有他的好处,也有不足比如效率问题,但是毕竟利大于弊。我不是很看好runner,?也有实力开发更好的插件却现在一昧的开发runner,runner平台运行效率暂且不谈,就是资源占用也有很多(yysy,JavaRunner是真的没啥必要)cs也顶多就多几个cs的api,我相信用cs的大部分也都会cpp,少几个api也不会怎么样(yysy,cs的窗口的确很棒)。我觉得目前真正有用的只有jsr bdxlua pyr,其他的维护成本一样高(虽然还是没有cpp插件成本高)且依赖于runner,如果runner跑路/停更,成熟一点的插件基本就废了。总而言之,我不推荐使用runner
C++不香嘛,我认为它是众多语言(汇编除外)中最方便管理内存的了,虽说少一些官方库,但是第三方库总有可以满足你的
Runner的功劳确实不能忽视,毕竟是jsr把我带入坑的,上手容易,确实适合新手编写插件,但是我并不希望过于累赘的runner进入bds圈,太多的runner也并没有多少意义,有开发runner的时间都可以开发老多实用的插件/软件了。但是并不是所有人都是cpp be good at,而且Runner的意义在于编写插件更esay,毕竟某些时候脚本语言比宿主语言在某些事件的处理上更便捷。如果是你这么说的话,如果所有的Runner都消失了,编写插件的门槛大大提高,不会出多少插件的。而且基于Runner的插件可以一次编写全版本运行,除非Runner停更。纯cpp插件即使是BDXC也要大版本重新适配,Runner有他的好处,也有不足比如效率问题,但是毕竟利大于弊。
我的东西全都是保密不开源,但是兼容性异常的好,就这样。此话怎讲 原理是怎样![]()
【Lv:3】
谢谢支持,bds一定会变得更好感谢有你,更加美好
补充一下,我认为我提出的加载器配置文件的方案第一种虽然对加载器作者不是很友好,但是可以更有效的分清架构体系,让插件的配置文件夹和本体能与加载器进行更好的区分,同时我认为加载器本体不应该直接放在.\plugins文件夹中,这样也容易与插件混淆。对于腐竹们来说能方便一点所有插件可以直接丢plugins是再好不过了我的想法就是根据插件所属的加载器类型进行后缀名配置,比如说LiteXLoader的*.lxl.js/lua(*.js有时候不能直接看出来可不可以用于LXL,不过这个需要LXL的js插件开发者注意),BDSNetRunner的*.csr.dll,然后插件本身不需要再分文件夹放置(事实上大多数插件除了CSR都是直接放plugins的)
还有加载器的配置文件建议统一放在.\plugins\lib\加载器或.\plugins\加载器\lib(推荐后一种,这样方便加载器作者)