Reply to Re: Dink with Lua scripting
If you don't have an account, just leave the password field blank.
Right, so I have not yet added these automated tests. While I agree with you in principle about the importance of them, I was more eager to have something working than I was with making sure everything worked right in a backwards-compatible manner. Obviously, this will most likely slow down adoption of my feature into the official FreeDink (if ever), but it doesn't mean it's entirely undoable. I am unfortunately not familiar enough with all the oddities of DinkC to feel entirely qualified to write these tests, as I don't know what strange edge cases need to be tested.
That being said, I tried making as minimal changes to the DinkC code as I could. In particular, the DinkC parsing code is entirely untouched, as is most of DinkC binding code. However, I have done some refactoring with the more complicated binding code, like playmidi, which basically amounts to avoiding repetition of the same code in the two language's bindings. The largest changes were made to the code that deals with loading, running, resuming and killing scripts, since how that is done differs in the different scripting engines. Again, however, I tried making the changes as minimal as possible.
I completely agree with the versioning support. It should definitely be possible for a dmod to know whether it can run on the current engine or not. However, since the current one doesn't really have any such mechanism, apart from get_version(), which will only work in DinkC (so a Lua dmod wouldn't even run at all on that engine, obviously) I'm not sure how useful it will be in protecting "new" type dmods from "old" type engines. In fact, I don't think this versioning should be a script at all, because if a newer version has a different scripting engine than previous versions, then their scripts won't even be possible to run. Perhaps a better choice is to use a declarative file (maybe even dmod.diz?) for this purpose.
The Lua scripting has been coded for 1.08 mode only. If you run it with the 1.07 compatibility mode, the Lua engine turns itself off. I did that mostly so I don't have to deal with stuff that is only in place to make existing dmods work in the first place.
Yeah, I get what you're saying about the conditional compilation. Mostly I wanted it to make sure that even when I completely disabled DinkC, Lua would still work, and the other way around, i.e. the two engines aren't interfering/interacting with each other. I also wanted it to be able to run a dmod that has mixed scripts, but only load one particular type of script... I do this when I'm re-writing Dink so that it doesn't load the existing scripts, letting me know which scripts I have to convert next.
I'm thinking instead of making them compile-time conditional, I'll make the engines run-time conditional. So you can run Dink with something like "--disable-dinkc" and "--disable-lua" to get the same effect, but not miss out on the feature itself in the application.
I'll keep updating the thread when new things are happening. Currently, as I said, I'm just re-implementing Dink in Lua for testing purposes (and to serve as a reference source for people who want to get into Dink Lua coding to look through).
That being said, I tried making as minimal changes to the DinkC code as I could. In particular, the DinkC parsing code is entirely untouched, as is most of DinkC binding code. However, I have done some refactoring with the more complicated binding code, like playmidi, which basically amounts to avoiding repetition of the same code in the two language's bindings. The largest changes were made to the code that deals with loading, running, resuming and killing scripts, since how that is done differs in the different scripting engines. Again, however, I tried making the changes as minimal as possible.
I completely agree with the versioning support. It should definitely be possible for a dmod to know whether it can run on the current engine or not. However, since the current one doesn't really have any such mechanism, apart from get_version(), which will only work in DinkC (so a Lua dmod wouldn't even run at all on that engine, obviously) I'm not sure how useful it will be in protecting "new" type dmods from "old" type engines. In fact, I don't think this versioning should be a script at all, because if a newer version has a different scripting engine than previous versions, then their scripts won't even be possible to run. Perhaps a better choice is to use a declarative file (maybe even dmod.diz?) for this purpose.
The Lua scripting has been coded for 1.08 mode only. If you run it with the 1.07 compatibility mode, the Lua engine turns itself off. I did that mostly so I don't have to deal with stuff that is only in place to make existing dmods work in the first place.
Yeah, I get what you're saying about the conditional compilation. Mostly I wanted it to make sure that even when I completely disabled DinkC, Lua would still work, and the other way around, i.e. the two engines aren't interfering/interacting with each other. I also wanted it to be able to run a dmod that has mixed scripts, but only load one particular type of script... I do this when I'm re-writing Dink so that it doesn't load the existing scripts, letting me know which scripts I have to convert next.
I'm thinking instead of making them compile-time conditional, I'll make the engines run-time conditional. So you can run Dink with something like "--disable-dinkc" and "--disable-lua" to get the same effect, but not miss out on the feature itself in the application.
I'll keep updating the thread when new things are happening. Currently, as I said, I'm just re-implementing Dink in Lua for testing purposes (and to serve as a reference source for people who want to get into Dink Lua coding to look through).
