Zugg Software :: View topic - Why LUA scripting is better than normal zScripting

Posted: Thu May 31, 2007 5:12 pm

This is a continuation of the discussion we were having over in the thread about LUA. There were several posts about why some people find it easier to just create scripts in plain text files (using their favorite editor) and then load them into CMUD.

Part of this I can understand...I understand wanting to see your entire script at one glance in an editor without clicking on various aliases, triggers, etc.

But here are some of the problems that I face with trying to allow this kind of scripting:

Some objects just don't lend themselves nicely to regular text scripting. My favorite example is Buttons. Take a look at the #BUTTON command. How many people know how to create a working multistate button using the #BUTTON command? It's a complete mess. A script that contains a lot of complex buttons is impossible to read and debug unless you have all of the arguments memorized.

How do you add a "comment" field to an alias, trigger, etc? This is the text field at the bottom of the advanced properties for every scripting object. There is no way to set this field from a command line script.

How about options like the Alias Auto-append option? Or how about the options for macros? The #TRIGGER command has it's own option field, but again, this is a poor way to implement options in the general case.

The fundamental problem is that zScript is based upon the original TinTin scripting language, and does not lend itself to advanced concepts such as properties. If I were designing the scripting language from scratch, then I'd probably implement a more modern language where you could do stuff like:

Magician Joined: 23 Nov 2004 Posts: 364

Being able to click on the class folder and edit the script for the entire class, and being able to view it/copy it is something I would like to see implemented in cMUD. I used it frequently to give out scripts and for editting. Another issue is just the routine. Some people like to edit their scripts in their favorite program simply because they are so in tune with the workings of that program.

Posted: Thu May 31, 2007 6:07 pm

I would very much like to be able to see the class script again.
Useful for sharing your scripts (in part) with folks who still used zMUD.

Enchanter Joined: 10 Oct 2000 Posts: 698

My insignificant thoughts:
It seems to me that ease of use is paramount. If I were in the middle of an intense MUD session and someone suggested I d/l their package, I'd probably put it off and then forget about it.
Maybe it can be done now but it certainly should be possible once the Chat module is loaded to initiate a transfer on the fly...

Player complains about X.
Author says I have a nifty package to handle X.
Player asks for the particular package.
Author right-clicks on package and selects the 'offer package to ...' MenuItem, then selects Player.
Player gets a dialog that a Package has been made available. Accept Y/N? Selects Yes.
Player's registration status is verified and if current, Package download/installation occurs from the Package Library seamlessly.

This would require a backward link from the Package Library to the Author's Package. It should also be possible for the author to share a link to private/pay Packages as well.

If this isn't possible now, a work-around would be to have the parser recognize a link to the Package Library and display the dialog to start the d/l and installation.

Posted: Thu May 31, 2007 6:28 pm

Let me try and summarise why I like Lua scripting from what I said in the other thread:

1) More and more varied options for storing data. Tables within tables that can also contain arrays, strings, functions, userdata, or whatever as elements, and metatables to provide even more flexibility.
2) (Specific to MudBot) - the ability to support custom protocols like ATCP. Mud servers are reluctant to change their protocols to accommodate clients (which is stupid, I know, but that's the way it is) and so we have to change to accommodate them.
3) Real functions are also very much a plus. I do hate having all those settings around that I'm never going to call from the command line. But Lua also supports anonymous functions, something that I think would be very hard to reproduce in zScript.

In response to the questions you ask about zScript itself, I definitely agree that CMUD's editor is superior than an external editor now, there's no doubt about that.

You also ask why people choose to distribute their scripts in text form. The answer is partly that it's a carryover from zMUD, when that was the most reliable way to import scripts (provided that you do it yourself and don't just export them). But part is also because of the bugs (or at least the perceived bugs, because I don't remember if and when they were fixed) in the alternatives, both the package editor and especially the XML exporter. The XML exporter especially was broken for a long time. Both systems also lack the human-readable quality that people like. Most people don't want to import scripts that they can't look over first to make sure they don't contain malicious code. It doesn't happen often, but it does happen, especially since zScript has access to just about everything you could want.

You ask why people would choose not to use the package editor if it didn't have any bugs. The basic answer is that they would choose to use the package editor if it were bug-free. But it's not, and finding and adapting to an alternative is faster than waiting for those bugs to be fixed, since users have no way of knowing how long it's going to take. There's not a lot really to be done about that since you're fixing bugs as fast as you can.

The slightly more complex answer applies quite specifically to players of MUDs that can require very complex scripting, like IRE games. People don't want to distribute their scripts via the package library because they're publicly available; due to the very high amount of work that goes into those scripts, people often charge for them, either using in-game currency or credits. These people would probably use the XML export if it were working, and especially if it were human-readable. Without an XML exporter/importer, they look for alternatives, and once they've found one that works, they stick with it.

EDIT: That'd be a sweet feature to add to the CMUD chat protocol, mr_kent. But really I think the whole thing could be done quite simply if there were some sort of cmud:// link type that would open the package editor and show whatever package you'd linked to. That way you could paste them a link in a tell, over IRC, MSN, whatever.

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

I don't need to be able to distribute scripts in text form. I've had some troubles with the Package Library, mostly sync issues, but I haven't used it a lot recently. I agree with mr_kent that there should be a good way for us to distribute packages privately. I assume this can just be done by sending someone the .pkg and telling them where to put it and how to install it.

I find the CMUD text editor much improved over the zMUD editor, but the editor window (outside the settings editor) still needs the Scintilla update and a few other fixes (silly untitled window behavior, for example).

I'm really looking forward to seeing what a true "function" can do in CMUD. Lua in CMUD is still what I look forward to the most right now. I want complex table structures, function delegates, importing other libraries, and other really cool stuff.

Posted: Thu May 31, 2007 6:51 pm

I like Mr. Kent's suggestion for distributing packages in game, that would be a big plus (although I don't think I'd do it myself). Imagine getting one that affects layout etc, in the middle of the session. Perhaps you should have the option to download and apply immediately or at the start of the next session.

I actually find I'm fairly happy with the current editor, especially with the Scintilla enhancements. Now if I can just learn the shortcuts.

Over all though, I do believe packages are the superior way of distributing scripts we just need to spray the package library with some pesticide.

It's too cumbersome and error prone to do graphical/interface items (BUTTONs, MENUs and Macros) via text and certainly not the preferred way. Frankly I think most folks just like having the all in on view of their code (sometimes the big picture helps) and text export would serve this need just fine.

Functions are high on my wish list.

As for the comment fields... I'm not sure about others but I don't use them that often. I don't know if it's my coding style or just habit. I like to use them to keep track of work I'm doing on triggers and idea for enhancements, but I'd need to remember the exact trigger to see it. A comment field on a module/window would be more useful, or an easy way to see all the fields with comments. But as I mentioned earlier thats just how I like to work.

Posted: Thu May 31, 2007 7:35 pm

Good stuff! Here is an idea that I thought about when reading...let's talk more about the human-readable XML import/export.

As we have agreed, the current zScript syntax for some stuff (like #BUTTONs) is cumbersome, and zScript doesn't handle some object properties/options. So what if the "Class Script" tab showed the human-readable XML format instead of the zScript format? This would let you edit scripts in text format, but it would handle all of the options and fields. For example, you would have something like this:

Posted: Thu May 31, 2007 7:50 pm

Speaking from a specifically, Lua-based standpoint, I think having a zs.var object containing all values from variables is a good idea, but why not expand that to the other options as well - zs.func for functions and zs.cmd for commands and so on. That way people can configure, through metatables, whether they want to have calls to zs.echo() available at all, and if they do, they can configure whether functions or commands have priority. It's similar to the way MUSHClient applies a metatable to the _G table to allow you call its functions without prefixing them all the time (which is also an option you might want to consider). I definitely think it's neater having three tables instead of just having commands and functions together and having to prefix SOME functions with f_.

And in addition, I don't think global changes (perhaps changing echo to always prefix the text with something, for example) should affect other packages, similar to MudBot's modules. I think it's possible for there to be an argument about some environment settings and _G metatable settings to apply to all packages, but I'd say that the code for that could be copied into other packages easily enough, and that way they'd stand alone as well. I just hope it's easy to implement that kind of differentiation.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

I'm a bit slow today, so bear with me...

If all the zScript functionality was available to any scripting language via this zs object, and the Scintilla editor already recognizes the syntax of said scripting languages... is the XML output format necessary (beyond as a means of export)? It sounds like this gives us largely what "we" are after. Those that wanted to use the GUI for everything would be unaffected, and those that wanted to code in a "flat file" format would be able to do so.

I could have a ruby routine that uses zs.func.room() and other mapper functions to manipulate map data (maybe to a Rails application) in myMapOutputter.rb. I could have a python routine that parses my prompt via zs.cmd.trigger() and builds a graphical widget in wxPython in promptParser.py. The overly contrived examples could go on and on.

Is that doable with what is being discussed here, or am I way off base?

Posted: Thu May 31, 2007 9:10 pm

I'm not sure if Zugg means that the zs interface be available purely in Lua or if it be available to all the WSH-based languages. I'd assume the former. But the intention always was that all zscript functions and commands be available to all the extra scripting langauges.

I'm not sure what you mean by XML output other than as a means of export. That's the context we're talking about it in, since human-readable XML output seems important. The class editing thing is incidental, but also a nice way of doing it.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

Ah.. I'm not personally picky if it is all WSH languages or just Lua because of the tighter embedding, I was just using it as means of example.

As for the XML output, Zugg was using the XML format in this thread as not only a means of export/sharing but also as a means of flat-file editing. Which is fine and a good compromise if what I was saying above _isn't_ feasible with what is being discussed. But I'm thinking I could have my flat files in .lua format, because I have full access to the zScript API via the 'zs' object. I just pull them up in the CMUD scintilla editor, modify at will, save, and then "import" in CMUD (whatever "import" entails - it being a menu option right from the editor, or cut&paste into the command line, or something else entirely). Not sure I'm making sense because I'm not sure if what I'm envisioning is possible or even on the same page :)

Posted: Thu May 31, 2007 9:44 pm

I don't know if .lua files will feature directly in CMUD's implementation of Lua. It'd be nice if you could still use an OnConnect event with require() to load function libraries you've created (and third-party libraries), but the sensible course would be to have the script work like any other script and have each trigger contain its own functions and whatnot. The intention always was, it seems to me, to have the .pkg format be the single format needed for CMUD files so that it's easily distributed. You could still write all your scripts in .lua files (but you'd have to use an external editor to write them) and then have CMUD require() them, but it doesn't seem like the way it's set out to work.

Since .pkg files are the only "real" format for CMUD scripts, it makes sense that there by a way to open them in a text editor, mostly to check for malicious code before you blindly open the package. On reflection, I'm not sure how important that is for most users - it will provide a very nice way of editing your scripts in a text editor that'll include things that're hard to reproduce with the normal API. Mutliple script languages and buttons are the classic examples.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

Thanks for the clarification. I'd still like a way of working the way I described in my happy fantasy land, but Fang's explanation identifies why I may have been slightly off-track.

With that being the case, the "need" to work in the flat-file format is lessened. While it would still be handy at times (maybe simply the return of zMud's class-edit ability as Zugg suggested intially?), I'd hate to see a ton of effort go into it as I was thinking about it wrong. I'd be more interested in the Lua and/or COM integration that is already being discussed, and all the future automapper plans.

Posted: Fri Jun 01, 2007 5:52 pm

The zs object would be available to *any* scripting language, not just to LUA.

I've thought about having zs.cmd, zs.func, zs.var but I wanted to make it easier for people to call common commands, such as zs.echo without needing to fully specify zs.cmd.echo, and to call functions like zs.match without using zs.func.match. Your description of a "meta table" goes over my head...I'm not familiar with that terminology. Is that a LUA thing? In COM you can tell it to publish the methods without needing to qualify them, but I wasn't sure what would happen if I loaded both the "cmd" and "func" objects since there are name conflicts. I'll need to actually test this and play with it. But I wouldn't worry too much about the syntax until I've had more time to look into this. At least you can see the direction I want to go with it.

The reason for the XML is for editing "Class scripts". Some people want a text format for their entire script. The only way to accommodate that in CMUD is with XML. As I mentioned before, there is no way to set certain options via zScript. As a trivial example, what if you wanted to create an Alias with the AutoAppend option set? There isn't any way to do that with the #ALIAS command. There isn't any easy way to create multistate buttons using the #BUTTON command (unless you are an expert on the full set of arguments for #BUTTON). XML is already used in CMUD for import/export and copy/paste, so allowing it to be directly edited isn't hard. And people have been asking for a more human-readable XML format for a long time now, so this isn't really anything new.

I don't really like the idea of "including" *.lua files since that defeats the whole purpose of putting everything into a shareable package. You'd need to share your *.lua files, which just makes it harder to use the package library. What CMUD needs instead is a way of "including" some other script that is already stored within the package. Seems like there just needs to be a "scripts" setting type that is just a raw script text that can be "required" or "included" within other settings (such as aliases, etc).

Installing a package from the package library doesn't actually "run" anything. So there shouldn't be any danger from malicious code. You can always install a package and then immediately do an XML Export and look at the result for anything malicious (assuming the XML becomes more human readable). This is one of the exact reasons why I've been resistant to allow you to add other files to the package.

Anyway, Daagar I think you *will* be able to accomplish your fantasy of mixing multiple languages if that's what you really want to do.

Posted: Fri Jun 01, 2007 6:37 pm

Simply, metatables give you a way of redefining operations on tables. One of the options you can set is what happens when an index is called that doesn't already exist - Lua lets you redirect the call to a different table. So a call to zs.echo() (which doesn't actually exist) could be redirected to zs.cmd.echo(), and then if that doesn't exist, to zs.func.echo(). So calling zs.echo() would work while keeping the table neatly organised.

MUSHClient does this by giving the global table, _G, a metatable that redirects calls towards MUSHClient's table, which I think is "world". That way, when you call, say, the global function send(), which doesn't really exist, the call gets redirected to MUSHClient's table and still works.

Posted: Sat Jun 02, 2007 5:01 pm

Hmm, interesting. That's pretty similar to how COM objects work. The client asks the server for an "ID" number for the property/method of an object. So when it requests the "echo" method of the "zs" object, CMUD dynamically returns an ID value for this command or function, which the client then uses to execute the method.

I couldn't tell from the quick look I took at the DelphiLua stuff whether I will get to interface directly into Lua tables, or whether it's all COM based. I'm going to start with COM-based since that allows me to support all other scripting languages too. The COM overhead for what I'm doing is very minimal since I'm generating the ID values directly and not using any type library.