Reply to Re: Dink with Lua scripting
If you don't have an account, just leave the password field blank.
I'm glad to have somebody fully on board!
Count me on board as well! I think this is a great project.
But don't worry Kyle, I won't abandon my editor.
Instead, when this starts working, I will probably add support for it. I'd just need to write a lua syntax parser (so I can replace sprite names with their editor_num, for example), which should be easy; lua is a very simple language. Actually, I might also cheat and just generate a table at the start of each script, which can then be used by the script. Oh, the joy of having a real language.
Oh, no, it's not a sprite graphic, it's a sprite object.
I think the confusion stems from this website, which inserted html code for a smiley in place of the : followed by s. It should be (space added to avoid the problem):
The : is lua's way of calling a member function, similar to what would be sprite.say in C++ (more precisely: lua does not automatically pass the "this" argument to a member function; object:function (args) is just syntactic sugar for object.function (object, args)).
As for the variables: please encourage good programming. That means as little global variables as possible. So I would definitely go for one sandbox per script. This is also pretty much requried, as you mention, for garbage collection to work.
On the other hand, object globals will be very useful as well. So if you can create an interface for those (for example a table named "volatile" (or perhaps better "v", because using it should be easy), which is shared between all sandboxes) that would be awesome. It can be used for loading functions which you don't want to include explicitly, for tables of strings, that sort of thing. The reason I'm thinking of it is that my editor uses names instead of numbers for sequences (and many other things), and it currently does the translation between them in the preprocessor. However, it would be nice if this could be done without parsing the lua code. Generating a table for them is easy, but it's a large table, and I wouldn't want to define it at the start of every script. It cannot be hardcoded, because it depends on which graphics are loaded through dink.ini.
My engine will be backwards compatible in that it will still be able to play all the old dmods, (at least to the extent that FreeDink already is able to) but not the other way around.
So I have a feature request: please add an interface to create new brain functions. They will need to be registered with a number, or they cannot be saved. My idea is to have an array of brains, which is initially filled with the default brains, but which can be altered by the DMod. So you can say brains[25] = function ... end. This interface needs some documentation, because nobody knows what a brain function should do.
Heh, well, I assume that if I don't provide Windows binaries for my project, then effectively nobody will be using it.
That's what I thought, too, but I have several times tried to compile things on or for Windows and I don't think it ever worked. I'm done with it; it makes me frustrated and I don't want that. If Windows users want good software, let them use a different OS. It's their problem, let them solve it. This is one reason I'm writing my editor in Python; Windows users can run it without me compiling it for them.
Count me on board as well! I think this is a great project.
But don't worry Kyle, I won't abandon my editor.
Instead, when this starts working, I will probably add support for it. I'd just need to write a lua syntax parser (so I can replace sprite names with their editor_num, for example), which should be easy; lua is a very simple language. Actually, I might also cheat and just generate a table at the start of each script, which can then be used by the script. Oh, the joy of having a real language. Oh, no, it's not a sprite graphic, it's a sprite object.
I think the confusion stems from this website, which inserted html code for a smiley in place of the : followed by s. It should be (space added to avoid the problem):
sprite: say (...)
The : is lua's way of calling a member function, similar to what would be sprite.say in C++ (more precisely: lua does not automatically pass the "this" argument to a member function; object:function (args) is just syntactic sugar for object.function (object, args)).
As for the variables: please encourage good programming. That means as little global variables as possible. So I would definitely go for one sandbox per script. This is also pretty much requried, as you mention, for garbage collection to work.
On the other hand, object globals will be very useful as well. So if you can create an interface for those (for example a table named "volatile" (or perhaps better "v", because using it should be easy), which is shared between all sandboxes) that would be awesome. It can be used for loading functions which you don't want to include explicitly, for tables of strings, that sort of thing. The reason I'm thinking of it is that my editor uses names instead of numbers for sequences (and many other things), and it currently does the translation between them in the preprocessor. However, it would be nice if this could be done without parsing the lua code. Generating a table for them is easy, but it's a large table, and I wouldn't want to define it at the start of every script. It cannot be hardcoded, because it depends on which graphics are loaded through dink.ini.
My engine will be backwards compatible in that it will still be able to play all the old dmods, (at least to the extent that FreeDink already is able to) but not the other way around.
So I have a feature request: please add an interface to create new brain functions. They will need to be registered with a number, or they cannot be saved. My idea is to have an array of brains, which is initially filled with the default brains, but which can be altered by the DMod. So you can say brains[25] = function ... end. This interface needs some documentation, because nobody knows what a brain function should do.
Heh, well, I assume that if I don't provide Windows binaries for my project, then effectively nobody will be using it.
That's what I thought, too, but I have several times tried to compile things on or for Windows and I don't think it ever worked. I'm done with it; it makes me frustrated and I don't want that. If Windows users want good software, let them use a different OS. It's their problem, let them solve it. This is one reason I'm writing my editor in Python; Windows users can run it without me compiling it for them.
