Reply to Re: Dink with Lua scripting
If you don't have an account, just leave the password field blank.
The memoriez! indeed! I have pretty much nothing but great memories from this place. It's what keeps me coming back. 
I'm glad to have somebody fully on board!
It's great to have someone else than myself psyched for this project. 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. In any case, yeah, we can't always let ourselves be held back by past limitations. Dink was never intended to run on Linux, and yet, today, we can.
Lua is incredibly simple and elegant. I will be writing some documentation along with my changes, like a small "Introduction to Lua for DinkC users" or whatever, just to get people started, as well as do my best to document all the differences between the two, so that if you know how to do something in DinkC, and accomplishing it is different in Lua, you should be able to go look that difference up somewhere.
I'm not really rebuilding variables, I'm just letting Lua deal with local variables instead of letting Dink deal with them. What that means is that, yes, there is no longer a variable limit on local variables. Have as many as you want in as many concurrent scripts as you want (limited, of course, by the memory limits of your computer). Global variables will be limited the same way they are today, and they will only be able to store integer values, as per today's limitations.
This actually lets me gracefully segue into a topic that I think requires a lot of discussion/thought.
Accessing the Dink globals will probably be done through an object aptly named "global" so that accessing the Dink variable &life from Lua will be done through doing "global.life". However, Lua also supports the idea of global variables, i.e. variables that can be accessed from multiple scripts... but just letting that happen isn't automatically the best idea. I'll explain why.
In my proof-of-concept implementation, each script is entirely separated (sandboxed) from every other script, in such a way that one script's globals cannot be seen from another script. The reason I did it this way is because DinkC users will be used to just creating a file and putting in some functions, and doing so places these functions in the global namespace in Lua, meaning that if they shared their environment, you couldn't have two scripts that both have a "main" function, because there would be a scope naming conflict.
So then, the question is, should I aim for DinkC-likeness, and just have the functions be global and the scripts be completely separated, or should I start a new scripting convention with Lua, that runs all the scripts in the same sandbox environment, rather than in separate sandbox environments, so they can share variables? Doing the latter will require scriptwriters to think to think a little differently about how to implement script functions like main, hit, talk, etc., because as I mentioned, they would interfere with each other if they were all global functions.
But wait, there are many more potential problems! If people aren't careful about using local variables rather than global, you'll quickly end up with a rather polluted (and eventually possibly memory consuming) pool of global variables from scripts that were long since killed off. Also, these variables would not be saved between saving and loading a game, so they cannot be used as reliably as the Dink variables, which do get saved to disk. All in all, I'm not sure it's worth the hassle to support this.
A different option would be to offer a mechanism similar to the global object of accessing Dink variables for Lua variables, and thus letting scripts be DinkC-like, and safely create global variables at will, without risking name conflicts or undesirable memory consumption.
Oh, no, it's not a sprite graphic, it's a sprite object. Probably a bad name choice; in Dink the word "sprite" is often used about the game objects as well, such as in "¤t_sprite;" or attaching something to "sprite 1000". Yeah, no, you load sprite graphics as before. I just used it as an example game object, presumably defined previously in the script somewhere.
Heh, well, I assume that if I don't provide Windows binaries for my project, then effectively nobody will be using it. After all, compiling software isn't very commonplace in Windows.
I'm glad to have somebody fully on board!
It's great to have someone else than myself psyched for this project. 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. In any case, yeah, we can't always let ourselves be held back by past limitations. Dink was never intended to run on Linux, and yet, today, we can.Lua is incredibly simple and elegant. I will be writing some documentation along with my changes, like a small "Introduction to Lua for DinkC users" or whatever, just to get people started, as well as do my best to document all the differences between the two, so that if you know how to do something in DinkC, and accomplishing it is different in Lua, you should be able to go look that difference up somewhere.
I'm not really rebuilding variables, I'm just letting Lua deal with local variables instead of letting Dink deal with them. What that means is that, yes, there is no longer a variable limit on local variables. Have as many as you want in as many concurrent scripts as you want (limited, of course, by the memory limits of your computer). Global variables will be limited the same way they are today, and they will only be able to store integer values, as per today's limitations.
This actually lets me gracefully segue into a topic that I think requires a lot of discussion/thought.
Accessing the Dink globals will probably be done through an object aptly named "global" so that accessing the Dink variable &life from Lua will be done through doing "global.life". However, Lua also supports the idea of global variables, i.e. variables that can be accessed from multiple scripts... but just letting that happen isn't automatically the best idea. I'll explain why.
In my proof-of-concept implementation, each script is entirely separated (sandboxed) from every other script, in such a way that one script's globals cannot be seen from another script. The reason I did it this way is because DinkC users will be used to just creating a file and putting in some functions, and doing so places these functions in the global namespace in Lua, meaning that if they shared their environment, you couldn't have two scripts that both have a "main" function, because there would be a scope naming conflict.
So then, the question is, should I aim for DinkC-likeness, and just have the functions be global and the scripts be completely separated, or should I start a new scripting convention with Lua, that runs all the scripts in the same sandbox environment, rather than in separate sandbox environments, so they can share variables? Doing the latter will require scriptwriters to think to think a little differently about how to implement script functions like main, hit, talk, etc., because as I mentioned, they would interfere with each other if they were all global functions.
But wait, there are many more potential problems! If people aren't careful about using local variables rather than global, you'll quickly end up with a rather polluted (and eventually possibly memory consuming) pool of global variables from scripts that were long since killed off. Also, these variables would not be saved between saving and loading a game, so they cannot be used as reliably as the Dink variables, which do get saved to disk. All in all, I'm not sure it's worth the hassle to support this.
A different option would be to offer a mechanism similar to the global object of accessing Dink variables for Lua variables, and thus letting scripts be DinkC-like, and safely create global variables at will, without risking name conflicts or undesirable memory consumption.
Oh, no, it's not a sprite graphic, it's a sprite object. Probably a bad name choice; in Dink the word "sprite" is often used about the game objects as well, such as in "¤t_sprite;" or attaching something to "sprite 1000". Yeah, no, you load sprite graphics as before. I just used it as an example game object, presumably defined previously in the script somewhere.
Heh, well, I assume that if I don't provide Windows binaries for my project, then effectively nobody will be using it. After all, compiling software isn't very commonplace in Windows.
