It's here, the first project of the blog! All update entries concerning a project will have the following header format so if I ever start posting useless crap about my daily life, you can scan through pages for what you want. Anything concerning a project will have the title tagged with the project name in square brackets and in all capital letters. eg. [PROJECT NAME]
The entry number concerning the project's update status will be put after the project tag, and before the title of the post. That should be easy enough huh?
Now, the goal for this project is to code a LSL(Linden Scripting Language) runtime interpreter that functions nearly identical to the LSL virtual machine environment within Second Life. There will be a few limitations concerning states and function calling but I hope to work with it. A small amount of memory will be given to the user for variable declaration and storage (yeah it would have to store the name and data). I'm not even sure it's possible to create a fully functional LSL runtime written in LSL alone... If anyone knows how, leave me a message. :P
Since this is the beginning stage, I'm only at the phase of bouncing ideas around and how to go about predictable problems. At this point, I'm thinking one state for the user, and one state for clearing the instruction sets. "Instruction sets?" you might be wondering. Yep, now this is another idea of mine that might make or break the interpreter's overall usefulness (wasn't very useful in the first place). Basically whenever the user inputs an event name into chat, the compiler goes into a 'write mode', where it will store the function calls into a list dedicated to that event (list instruct_touch_start = []; for an example). It will continue to do so until the user inputs that he/she wants to exit the event, maybe by saying "exit event name" or something. Once the interpreter receives the call to exit the 'write mode' and go back to normal operations. The effect would be immediately put in place, so if that state is ever entered again, a procedure will check for any existing instruction sets and play through them like a recording.
Of course that idea is only going to complicate things two-fold but I really want to push the limits with LSL.
Two things already worry me. Script memory and speed. The amount of processing power that will be needed to perform so much parsing and conditional tasks to run a fairly complex block of code will make the waiting period for results so much more. Now the biggest problem is script runtime memory, which Linden Lab has limited to approximate 16kB. Not bad for a little server side script, eh? Yeah well that memory does not just account for variables... states and events also accommodate memory. Linden Lab really busted our balls with data types too. There are no such things as boolean, unsigned, doubles, shorts, longs, char... Efficiency wasn't on the list for the scripting department. Oh well.
Summary: Goal is to create a LSL runtime interpreter that accepts code from in world chat. Features include global variable declaration, event instruction set storage, functions called within functions, and state access (cannot create new states though). I'm going to try to code this all into maybe 2 or 3 large modules which use linked messages to communicate data to one another.
Well that's all for now!
No comments:
Post a Comment