Zugg Software :: View topic

Posted: Mon May 14, 2007 11:03 am

I remember a couple of weeks ago in my WSH thread, Zugg posting that since Lua is so lightweight (and because there's buggerall in the way of Lua-for-WSH ;) he was considering adding it to CMUD itself as a scripting language. I have a couple of questions:

- Did anything ever come of this maybe-possibly, or is looking at it as a possibility still on the todo list?
- If it's more than maybe, where does it fit on the roughish CMUD feature order plan? There seems to already be quite a bit on the plate...
- Finally, and most importantly: Is anyone else actually interested in this?

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

I would absolutely love to see Lua integrated nicely into CMUD.

Novice Joined: 29 Jan 2006 Posts: 40 Location: Aardwolf

I've heard a lot of very interesting things about Lua, and would definitely be interested in this. I also know a lot of scripts for MUSHclient get written in Lua, and this might help to get people to switch, knowing that any rewrites to their existing scripts could be relatively minor, and can happen in a language they're already familiar with.

Posted: Mon May 14, 2007 6:18 pm

I'd also be interested in hearing from other users on this so that I can better prioritize it. If it's easy to add, then it will get added sooner rather than later. But if it's difficult, then it might get lost in the huge list of things I'm working on.

Putting Lua into CMUD would not necessarily give any compatibility with MUSHclient. Yes, the scripting syntax would be the same, but the method in which you access aliases, triggers, variables, etc would all be different.

Any MUD client that relies on COM-based scripting (such as MUSHclient) sets up their own COM objects and functions which then integrate with their scripting language. It's sort of like using COM-based scripting in the existing CMUD system with other languages (such as the zvar.varname syntax to access CMUD variables from VBScript or other languages).

It would be like comparing PHP with C. Both PHP and C use "C-like" syntax (using {} for code blocks, etc). But the main power of PHP comes from it's library routines, which are completely different than the library routines in C. So even if CMUD and MUSHclient both used Lua *syntax*, the library routines (COM objects, etc) will still be completely different.

Posted: Mon May 14, 2007 7:01 pm

I'd be interested in seeing Lua in CMUD, but I don't have any pressing need for it. Maybe I'm just a simple mudder but I'm constantly amazed at how complex some other folks have their scripts. With that said I like the idea of having new tools at hand and the flexibility they can offer. Plus I'd like to offer Lua.

I think it boils to down the the 3 types of users, that we talked about in the Beta forums and it's hard to get a feel for their numbers and breakdown. You have your advance scripters like Larkin, edb, Matt and others. Then you have your tinkerers and those for whom CMUD/zMud is the primary programming they do. Then you have group three that only know what groups 1 and 2 tell them. The ones that will likely want Lua are group 1 and mostly if it allows to solve complex or unique problems CMUD doesn't quite handle yet. I don't know Lua so I don't know how many of those there are.

Another thing to consider is the small possibility of drawing more of WoW crowd that also MUD. Leveraging in Lua CMUD would be another selling point. But once again it's hard to estimate the size of this audience.

Posted: Mon May 14, 2007 7:13 pm

Lua's definitely got a lot of press from WoW, that's true, but it's also had attention in the communities of other games, and in mod development communities too. I was amazed how easy Lua was to pick up, too - I learnt enough to get by during an idle weekend and can now edit WoW Addons to my heart's content.

I hope Lua will be easy to get in, since I'm positively slavering at the thought of getting my MUDing hands on it. But I'm wondering - is there some easy way to specify a script language from the dropdown menu without using the dropdown menu? It wouldn't be a problem for scripts in packages but it'd be nice to be able to quickly and easily define a Lua-based script from the command line without involving the Package Editor GUI.

But yes, I'd love to see Lua. To people reading this, as well - if you're indifferent to Lua or really don't want it, please post as well.

This topic is now a poll.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Voted maybe only because I've never used it. I'm interested because others I'd consider power users are though, and if I get back into mudding more then I'd probably be tempted.
random note, I want to make a CMUD widget for Vista that'll let you display info in the sidebar using XML while you're playing if CMUD is minimized. could be cool.

Posted: Tue May 15, 2007 12:23 am

Voted maybe too for pretty much the same reasons as Guinn.

Guinn: CMUD is exposed via COM so I see no reason why you couldn't make a Vista widget to do that.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Indifferent here. No real compelling reason to use even Javascript or VBscript for me, much less anything more recent.

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

Lua is able to be more smoothly (tightly) integrated with the program you're scripting with it. Instead of needing special COM access objects, like zvar or world, you can just call functions directly. The only difficulty that I can see with integrating Lua scripting with CMUD is going through the existing code to expose the functions to the Lua engine.

I like Lua because it's simple to learn, nothing extra to install (as with Python, Perl, etc), and packages that use Lua are more likely to run well on someone else's system.

Really looking forward to playing with Lua in CMUD!

Posted: Tue May 15, 2007 6:38 pm

Larkin: I'm not sure if I'll be able to use that kind of integration with Delphi though. Right now I was just thinking of getting the Lua DLL and trying to integrate it with the same COM-based system that is used by all the other scripting languages. I haven't really looked at how you expose functions to Lua, but it seems like I should use a consistent naming scheme for all languages, rather than doing something different for Lua. But like I said, I haven't looked at it very much yet...my initial searching for Delphi integration of Lua didn't come up with very much.

If you locate some resources for how to integrate Lua with Delphi, let me know. But since I can't compile Lua directly within Delphi, there is always going to be some sort of Lua DLL file to distribute with CMUD I think.

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

I'm no expert on Delphi programming, but I've taken a look at Lua for .NET and the principles seem to be the same. You load the functions from the DLL on any system, so a Lua DLL is always required. Your functions are exposed through registering them with the Lua engine (LuaRegister or whatever it's called), and you can use a different name for the Lua version from the internal version (i.e., your function might be DB_LoadStuff and the one called from a Lua script is LoadDatabase). The process actually looks fairly straightforward from the samples I saw.

My source:
http://sourceforge.net/projects/lua4delphi

Posted: Wed May 16, 2007 5:10 am

If you incorporated the functions that you use to access the mapper and/or sql DBs into LUA, then I'd just have to go learn LUA.
If not, then it would all come down to speed. The greatest attraction of CMUD to me at the moment is speed boosts. I mean, a friend and myself optimise our scripts down to the millisecond, finding things like #addkey faster than #var etc (though it makes little to no sense to me, i would have thought #addkey slower) and migrating them throughout all our scripts. Generating sorting routines for DB variables that use a single %sort and no loops, etc. If LUA is faster than CMUD compiled scripts (or more stable, because last i checked, the stuff i want to do in CMUD just isn't stable enough yet) then i'd be using LUA all over the place.

Posted: Wed May 16, 2007 7:59 am

I know that it would not mean compatibility with mushclient, but all the people I know that use mushclient and do not come from a programming background use lua with mushclient. Supposedly its simple or something. Cmud offers a lot of things mushclient does not, but for they just cant be bothered learning a new language, so they stick with what they know.

So while I'd probably never use it, I think its a good idea to add it to CMUD since it would be making it more accessible to some people who really are the sort of people who appreciate user-friendliness. It might only be a small group, but every bit helps, right?

Posted: Wed May 16, 2007 7:16 pm

I was thinking about that the other day actually Caled, mainly wondering if converting to Lua really would provide a speed benefit when you consider the overheads of calling a method or value through COM. I came to the realisation that most simple scripts and some intermediate ones aren't really reliant on many zcmds or zfuncs at all. Most of them don't even need zvar unless they explicitly need their values saving across sessions when those values aren't static (like maxhp or a database of notes you're keeping on enemies). That should mean that for people that want to switch clients, or to convert scripts from another client, the principles should be exactly the same. Probably the only thing you'd need to change for some scripts, especially if you're using regexes for triggers, would be the function that actually sends the command to the server.

Posted: Thu May 17, 2007 7:45 am

I'm not sure I fully understand you, but I think I disagree. At least with the muds I play (Imperian, Aetolia, Achaea etc) anyone that wishes to be involved in PVP with reasonable success needs a fairly complex system, involving at the very least variables and if statements, and at the higher end, math functions, stringlists, database variables, loops structures and some lengthy elsif structures (or some other way of achieving the same).

While thats simple stuff to anyone with a programmers training, most of the non-coders I play with (we have a close forum community in the IRE games) don't learn much coding at all. If they are using zscript, they learn the basics and do some pretty complex (and inefficient) stuff with it. The same goes for those that use mushclient instead of zmud/cmud - they pick the easiest language (lua) and learn enough to do what they need. They aren't using lua for some speed benefit - they are using it because some friend recommended they use it. They actually would have been better off from the beginning if their friend had told them to use zMud. They don't understand the basics of programming, so while to you it may seem simple to do the same stuff in zscript, for them its starting again from the beginning.

I've mentioned some of the cooler new stuff cmud does (such as #SWITCH and the package sharing feature) and everyone says it sounds great, including the non-coder mushclient users, so my point is really that offering those people the familiarity of LUA might be enough to lure them over to CMUD.

Posted: Thu May 17, 2007 2:47 pm

After reading about MUSHClient's implementation of Lua it actually seems that I was quite wrong. Oh well.

MUSHClient's implementation of Lua is quite different to what I assume Zugg's will be. That means that the actual structure of scripts, compiling tables and constructing iterators and so on, will follow the same principles but any interaction with CMUD at all will be very different. An alias is useless if it doesn't parse its parameters, for example, and MUSHClient's method for doing this is very, very different to the zparam table that Zugg was suggesting.

So while there'll definitely be some benefit in terms of moving between clients, it might not be as large as you'd think at first.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Thu May 17, 2007 3:29 pm

There are two models for storing scripts in MUSHClient, it seems. One is to have a script snippet associated with each setting, like in zMUD, but the other is just to have a script file and then point each alias at whatever function you want it to use (and aliases can thus share functions, or call other alias' functions and so on).

But it wouldn't be too hard to just create an OnConnect event that require()s whatever script file you want to run and to then have the alias' script set to run that function with the parameters that MUSHClient would give it. The alias script would be something like

test_alias_func(name of alias,zfunc.cmd,zparam)

The harder part (but still not as hard as writing a proxy or compiler) would be writing a MUSHClient library for zMUD to simulate the functions that can be simulated, for example

function ColourNote (fore, back, str)
zcmd.say(str)
zcmd.color(fore .. "," .. back)
end

or something similar. But of course once that's done, it's done.

All in all, though, I don't think it's changed. It'll be possible to come from MUSHClient with more ease if CMUD supports Lua, but it might still be harder than you think.

Wizard Joined: 14 Oct 2000 Posts: 1368

Novice Joined: 29 Jan 2006 Posts: 40 Location: Aardwolf

I didn't mean to imply that MUSHclient scripts would be directly portable. I know they wouldn't be. What I'm saying is that you'd already be used to the core language, you'd just have to learn the differences between the way MUSHclient and ZMUD handle things internally. It'd beat the hell out of telling MUSHclient users that they have to learn Zscript or Cscript or whatever we're calling it now.

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

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

Novice Joined: 20 Apr 2008 Posts: 39 Location: Sweden

Posted: Thu Jul 17, 2008 8:37 pm

Wow, this is an old thread!

Chosig: I actually disagree with you. If all clients were the same, then why would anyone pay for CMUD? I have a family to support and bills to pay. I'm the only one who does this (MUD client) full time as a job. If nobody buys CMUD, then I go out of business and stop working on it.

What would that mean? Take a look at all of the MUD clients out there. Take a look at how many of them try to emulate zMUD and implement it's features (some of which all come from the original TinTin in the first place). Look at how all of the other mappers look so much like the mapper in zMUD. This isn't a coincidence. Many (but not all) MUD clients get their ideas from zMUD and add them later. In many cases, zMUD was the first client to have a specific feature. Without zMUD to drive the market, most MUD clients would be nowhere near the feature-set that they are today. It's very important to have an "innovator" pushing the market ahead. Otherwise it stagnates and dies.

So while zMUD/CMUD has always been one of the leading clients to develop and support *standards* (Telnet,ANSI,VT100,MXP,MSP,MCCP,MCP,etc) I personally think it's very important for each client to have it's own unique features too. I don't want a common mapper database backend. A common mapper backend wouldn't allow me to implement the features that I want to provide for my customers. I don't want a common scripting language. People who want to use Lua or VBScript or JScript or Perl or whatever can do that in CMUD. But I'm always going to push zScript to be an alternative as a scripting language specifically designed for MUD playing and programming. And zScript is always going to be very specific to zMUD/CMUD.