Open edo9300 opened 4 years ago
But I can't get who will benefit from this change, the users still need to update the binary files to update the AI.
perhaps publishers of the bots
This has the advantage that if someone wants to share a deck they made, they only have to give a DLL+ydk (and update the bot list), and that deck will be immediately playable without having to replace the windbot binary with a different one, also, due the nature of c#, those DLL executors should be able to work even if baseexecutor is changed (unless functions are changed or variables removed)
It won't be very useful until the basic part of windbot won't be changed often.
It could be useful for independent AI deck developers who don't distribute a YGOPro simulator. They don't have a version of windbot they control to add the bot to, but they can distribute the DLL and players on multiple different simulators could hypothetically install the deck.
Them can distribute windbot or send pull request.
A DLL is a significantly lighter distributable than the entirety of windbot, and sending a pull request assumes both that they want to contribute to upstream, and that upstream wants their contribution. For example, they could be new, and the maintainer could decide that the AI script isn't good enough reject it, but distributing it through a DLL would allow them to get some feedback from others while they practice and improve.
A DLL is a significantly lighter distributable than the entirety of windbot
You won't think so if you are a normal user.
I think if AIs were distributed in this way, some script language engines, such as Lua in YGOPro, or other scripting languages like Python or Javascript, as well as Ruby, could be a better choice other than a DLL. Sometimes DLLs works badly in cross-platform, as Windbot is usually deployed on Windows for end users or Windows servers, or Linux for servers. If needed to distribute Windbot like that, The whole project is needed to be rewritten in those scripting languages. Otherwise a whole script engine should be included in this project, as if YGOPro is made up of.
If the executor work with mono while integrated in the exe, then it will work the same way as DLL loaded by the exe while being runned via mono on non windows platforms. This isn't a thing to "replace" windbot things, it's just something to make those executors (while still dependant on the main exe) easily accessible without having to replace the binary, if another scripting/programming language has to be used, then better just rewrite the bot with those in mind. This is just a simple "hack" to make something that will work only on windbot more accessible, it's not a thing meant to replace the behaviour of the program.
The executors logic has been separated from the main application, and put in a library that will be loaded by windbot, this will allow executors to be compiled as a c# dll, consisting of only the executor class, this will then loaded by windbot in the same way as the internal executors are loaded, and they'll load the Executor implementation from ExecutorBase loaded by windbot. There's also a "SampleExecutor" project that is configured to build a valid dll already likned against ExecutorBase dll. The executors will be loaded from the "Executors" folder. The only difference between an integrated executor and an external one is that for the external one, rather than having the possibility to directly access to the Logger class, the chat function, and
Program.Random
, the first 2 are set via callbacks, with Log having a different syntax, whileRandom
has been made part of the executors themselves.