Zugg Software :: View topic

Posted: Tue Jul 10, 2007 10:54 pm

I've started implementing Lua within CMUD now. I had to convert the Lua header files so that they dynamically linked the LUA.DLL file instead of the normal static linking files that were already available for Delphi. This allows you to remove the Lua support in CMUD by just removing the LUA.DLL file. CMUD first looks in the CMUD.EXE directory for the LUA.DLL, and if not found, then it loads the DLL via Windows.

So, I've got the basics going. Lua appears in the list of script languages. There seem to be a couple of issues with the default Scintilla syntax highlighting for Lua, but it might just be a color style that I haven't defined yet (the ; at the end of the line is black-on-black). I've got the "print" function overridden to display the result to the MUD window.

My question is, should the Lua State be "global"? In other words, should all windows and modules share the same Lua scripting environment, to allow sharing of variables, functions, etc, or should each window/module have it's own Lua environment?

My best guess is that the state should be global to allow windows/modules to communicate with each other. But this is different than how the Microsoft Scripting is currently implemented in zMUD/CMUD. The MSS has a separate script environment for each MUD window.

Anyway, let me know how you feel about this before I get too deep into the implementation. My main job now is to add the various functions to Lua that allow it to access all of the zScript stuff, like variables, commands, functions, etc.

Posted: Tue Jul 10, 2007 11:15 pm

Firstly, let me just say: ^________________^

Now.

Posted: Tue Jul 10, 2007 11:47 pm

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

The other thing I did was a mechanism for getting a userdata which was a reference to a different world (ie. a different game session). Then you could supply that userdata as the first argument for any function, which redirected that function to affect the other world. That way you could write something like "send to all worlds" or "bring world x to the front".

It was mildly fiddly to get that to work, but I think the result was worth it. You must already have the problem that, within the Lua state, if the user wants to display something on the screen, *which* screen it appears on (assuming multiple ones are open at once). If you have one state per connection, at least, then you can store in the Lua registry some kind of pointer or whatever Delphi uses, so that you can get back to the connection it is associated with.

Posted: Wed Jul 11, 2007 3:47 pm

Hmm, the more I thought about it, the more I think Nick is right about this. While the idea of each package being a module was interesting, it doesn't get around the fact that simple global variables would end up being shared, so doing something as simple as :

i=0

could effect some other script in some other windows. When you add threads to this, it gets even more complicated since you'd want each thread to treat "i" as a local variable, and not a global variable.

And yes, I was just starting to run into the problem where the Lua state needed to know what window it was within. For example, the "print" function needs to know what window to send it's text to. Storing the connection window as userdata within the Lua state sounds like a good idea.

This leads me to another complexity...how do people want to access CMUD variables from within Lua. Remember that I created the "zsvar" object for other scripting objects? Well, the problem with "zsvar" (or with making this into a table within Lua) is that it doesn't allow you to access variables by module/class name. In CMUD you can do this: @//modulename/class/subclass/varname . In other words, variables are stored in a tree hierarchy within CMUD, much like files within a directory structure.

So how do you access a variable like this in Lua? If "zs" refers to the current module/window associated with the Lua environment, then I can have "zs.varname" or "zs[varname]" using a simple table, but that doesn't give access to a variable in a specific class.

Seems like I might need to implement something like a "class" userdata that returns a table of settings within a given class. Something like:

MyClass = zs.class[classname]
Var = MyClass[varname]

Nick, does MUSHClient use a tree hierarchy for variables, or do you have a flat table structure? Any ideas how people would like this to be handled. There's a lot of power in Lua if we can set this up correctly.

Posted: Wed Jul 11, 2007 4:42 pm

OK, I think I need to take a day and think more about this design before I just jump into the coding. I need to come up with a clean, easy-to-understand design for doing Lua programming within CMUD. I'm going to read through the "Programming in Lua" book again and see if I can come up with something that fits well into the Lua-way of doing things, that would still make sense to CMUD users.

This design needs to deal with modules/windows, class folders, and the various settings, such as variables, aliases, triggers, etc. But I want it in a way that isn't syntactically cumbersome.

I want something simple like: zs.modulename.classname.subclass.varname to mimic our @//modulename/classname/subclass/varname syntax. But I'd want zs.varname to work like @varname (using the current class, etc). Feel free to discuss any ideas that might help with this design.

Posted: Wed Jul 11, 2007 6:24 pm

Hmm, here's another idea...since tables in Lua can have any string value as a key, maybe a syntax like this would be better:

zs.var[name]
zs.var["//module/class/subclass/varname"]

That would be a bit easier to implement I think. What do people think?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Sounds like a good Idea to me!

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Posted: Thu Jul 12, 2007 5:34 pm

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Posted: Thu Jul 12, 2007 9:37 pm

I definitely agree with Nick on this one. It's pointless trying to make CMUD variables into a "Lua-like" syntax, because they're not "Lua-like" variables. There needs to be a clear distinction.

Posted: Fri Jul 13, 2007 1:06 am

No, I still disagree. These are "userdata" values in Lua. Look at the example in chapter 28 of the "Programming in Lua" book where they show creating a bit array as a userdata type. They define very specific methods for the userdata type: set, get, size. In their example on page 267, they show this:

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Posted: Fri Jul 13, 2007 3:15 am

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Posted: Fri Jul 13, 2007 5:33 am

OK, I'll eventually edit this and add it to the Knowledge Base, but here is the design that I'm using for Lua in CMUD:

Overridden Lua commands

The "print" command in Lua calls the CMUD #ECHO command. The text is sent to the window that currently has keyboard focus

New global Lua commands

These are for convenience only. Normally you should probably use the "zs.command" form shown below, which allows you to specify the exact window or connection that is being used.

echo: Same as the Lua "print" command. Calls CMUD #ECHO in the current MUD window
send: Sends the arguments to the MUD as if they were entered into the command line (which means the command is echoed to the MUD window)
sendraw: Send the arguments to the MUD as raw data. No other echoing or processing is done. It simply writes to the network socket.
windows: A Lua table containing references to all defined CMUD windows. Each value in this table is a zsMudWindow userdata object (see below). The table can be indexed by window name (case sensitive) or by window ID value.

New "zs" global object

A new datatype is introduced to Lua called a "zsMudWindow". This represents a CMUD window (or module) object. The global "zs" object references the MUD window that currently has keyboard focus, or, when used within a trigger, it is the window that received the text which caused the trigger. Here are the properties and methods of a zsMudWindow object:

zs.var: The table of variables stored within the window. You can access variables using the syntax zs.var[name] or zs.var.name (In Lua, both of these syntaxes are equivalent). To specify a variable in an arbitrary module and class, use zs.var["//module/class/subclass/varname"]
zs.name: calls the CMUD command or function of the given name. For example: zs.echo("hello world") is the same as calling the normal CMUD command: #ECHO "hello world". In the case where a CMUD command and function have the same name, this calls the function, and returns the value of the function. To force it to use the command, see the zs.cmd syntax below.
zs.cmd.name: calls the CMUD command of the given name. This is used in cases where CMUD has a command and function of the same name, and you want to call the command, not the function.
zs.func.name: calls the CMUD function of the given name and returns the result. This is used in cases where CMUD has a command and function of the same name, and you want to call the function, not the command.
zs.name: returns the name of the window (same as the CMUD #NAME command, but returns a value as a function)
zs.windowid: returns the unique ID number for the window (to deal with multiple windows that have the same name)
zs.host: the current host name for the window
zs.port: the current port number for the window
zs.char: returns the current username for the window (same as the CMUD %char predefined variable). In fact, many of the Predefined CMUD variables are available via this kind of syntax. A full list will be documented when implemented (and after I deal with name collisions between predefined variables and functions with the same name). In most cases, it's easy to handle since predefined variables do not have any arguments, and functions do. So "zs.char" can return the character name for the window, but "zs.char(65)" can still return the character with the ascii value of 65.

Using multiple windows

You can retrieve the window object for another CMUD window using the global "windows" table. This will return the zsMudWindow object for the specified CMUD window name or windowid. The object result can then be used the same as "zs" in these examples. For example:

Posted: Fri Jul 13, 2007 5:59 am

About the zs.var vs the CMUD #VAR command

As described above, most cases of "zs.name" calls the CMUD command or function with the given name. So, why doesn't "zs.var" called the CMUD #VAR command, just like zs.alias calls the #ALIAS command? Well, the most common use of variables is to set and retrieve their *values*. It is rare that you need to define the properties of the CMUD Variable Object itself. Whereas accessing an Alias (or Trigger, or Button) usually means that you need access to the full object so that you can set it's properties. Once an Alias is created, for example, the *value* of the Alias (the script) rarely changes.

You can still use the zs.cmd.var("name") syntax to access the CMUD #VAR command if absolutely needed. Also, the "zs.getvar" and "zs.makevar" routines still exist to manipulate the Variable objects, just like for Aliases and Triggers.

Hopefully this helps understand why you use zs.var[varname] or zs.var.varname for variables, but use zs.alias("aliasname") for aliases.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

Wow, Zugg... I'd never really looked into Lua before, but reading through your last couple entries I can see where the interface and alternate language support could really open up the scripting possibilities for those enlightened enough to learn the language.

I'm willing to bet a lot of people are getting excited for 2.0 :)

Posted: Fri Jul 13, 2007 10:23 am

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Okay, I wasn't saying that you *should* set a function as the value of a[10], just that it's possible in Lua and the behavior should be defined when something like that happens in CMUD. Also, I wasn't really against the zs.var.varname syntax for getting/setting CMUD variables. I think it'll be great. I'm just wondering what will happen when we assign things to them that you wouldn't normally put into a CMUD variable, whether it's a function, another table, or what have you. So, to ally our fears and doubts, could you please test this and/or let us know what to expect? :)

The documentation you posted looks great! I really can't wait to dive into 2.0 and start re-writing portions of my scripts to take full advantage of all the new features.

Posted: Fri Jul 13, 2007 4:47 pm

If you try to assign a function to a CMUD variable, you will get an error message (using the normal Lua assert system, which will generate proper error messages in CMUD, just like having a zScript syntax error). If it happens in a background script, then the error message is displayed in the MUD output screen, just like if you have an error in an alias that is called by a background trigger in zScript. In other words, the Lua and zScript error mechanisms are the same, and you will get error messages if you try to do something wrong in Lua (whether it's a syntax error, or a runtime error).

Assigning Lua tables to a CMUD variable should work fine. I'm using a serializer similar to what Nick did in MUSHclient. This is built into CMUD and handles full conversion of nested Lua tables to/from CMUD variables. And since CMUD variables are always stored in the database in the background, you don't need to worry about specifically telling CMUD to save the variables, like you do in MUSHclient.

CMUD *should* be able to handle the difference between the Lua "nil" value, and other values, so that shouldn't be any problem. But I'll know more when I get further into the implementation.

So, the data types that you *won't* be able to store in a CMUD variable are: function, lightuserdata, userdata, thread. These will give error messages.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Sounds good to me! Thank you for answering that so clearly. Very Happy

Posted: Fri Jul 13, 2007 7:15 pm

Updated the documentation above to reflect the new way of handling multiple windows. Instead of using a "getwindow" function, CMUD now creates a true Lua table called "windows". Each window is stored in this table (as userdata) twice: once for the window name, and once for the window id.

If you have multiple windows with the same name, the last defined window will occupy the spot in the table with the name as the index. So if you want a true list of all tables, iterate through the "windows" table by numeric index. For example: