About Us
Products
Purchase
Downloads
Support
Forums
Contact Us
Site
 Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion Goto page 1, 2  Next

Are you interested in seeing Lua added to CMUD?
Yes
56%
 56%  [ 26 ]
No
8%
 8%  [ 4 ]
Maybe
8%
 8%  [ 4 ]
Indifferent
26%
 26%  [ 12 ]
Total Votes : 46

Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Mon May 14, 2007 11:03 am   

Lua in CMUD
 
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?


Last edited by Fang Xianfu on Mon May 14, 2007 1:19 pm; edited 1 time in total
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Mon May 14, 2007 12:10 pm   
 
I would absolutely love to see Lua integrated nicely into CMUD.
Reply with quote
Obyron
Novice


Joined: 29 Jan 2006
Posts: 40
Location: Aardwolf

PostPosted: Mon May 14, 2007 3:17 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: 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.
_________________
Asati di tempari!
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Tue May 15, 2007 12:14 am   
 
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.
_________________
CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;)
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Tue May 15, 2007 5:11 am   
 
Indifferent here. No real compelling reason to use even Javascript or VBscript for me, much less anything more recent.
_________________
EDIT: I didn't like my old signature
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue May 15, 2007 12:46 pm   
 
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!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue May 15, 2007 7:15 pm   
 
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
Reply with quote
alluran
Adept


Joined: 14 Sep 2005
Posts: 223
Location: Sydney, Australia

PostPosted: 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.
_________________
The Drake Forestseer
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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?
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Thu May 17, 2007 3:02 pm   
 
Fang Xianfu wrote:
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.

You could probably implement a proxy between cMUD and Lua that behaves like MUSHClient.

cMUD <-----> "MushClient" Proxy <-----> Lua

Another method is to write a Lua compiler that translates MushClient Lua scripts to zScript or to cMUD's Lua version. The proxy method is probably the easiest though.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Thu May 17, 2007 3:50 pm   
 
Fang Xianfu wrote:

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.

What you have to keep in mind also is that alot of functions might not be used by a lot of scripts. So when making a library you priotize on getting the most used functions to work early.

I think the biggest issue might be ethical concerns. For example say I write a full zScript interpreter for MushClient. While it would be nice to most players it could make Zugg upset. It is similar issue with making cMUD able to execute MushClient scripts.

Ethical issues aside the point here is that cMUD could very well support MushClient scripts.
Reply with quote
Obyron
Novice


Joined: 29 Jan 2006
Posts: 40
Location: Aardwolf

PostPosted: Mon May 21, 2007 3:02 pm   
 
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.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Mon Jun 18, 2007 5:53 am   
 
Zugg wrote:
So even if CMUD and MUSHclient both used Lua *syntax*, the library routines (COM objects, etc) will still be completely different.


Just to clarify a bit - all of MUSHclient's scripting, except Lua, uses the COM interface.

When I implemented Lua scripting I wanted to get away from using COM objects (eg. for running under Linux).

In order to do this, I had to write a "glue" routine for every existing script call, to give it a Lua interface. Lua is very very good at interfacing with C, so this was easy enough, if a bit tedious.

I am not aware of any COM interface that lets you use a Lua DLL with a program that supports COM, without interfacing it with C calls. Lua is specifically designed to interface with C programs (however C++ is easy enough to do).

Zugg is quite right though, even providing Lua would not particularly make script designed to run on MUSHclient run on CMUD, or vice-versa. You have the basic syntax there, but all the script functions would do different things.

As another poster said, you quite possibly could write interface routines, in Lua, that simulate the behaviour of MUSHclient functions for CMUD (and again, vice-versa if you implemented Lua in CMUD).

The extent to which that would be easy would rely a bit on the basic client design - if they had a similar sort of approach to doing things, it might be reasonably possible. You also have to find common ground for implementing some things. For example, MUSHclient has a function GetInfo that returns all sorts of things, like the current world's IP address. For this to be converted a similar function would need to be exposed by CMUD.

Other things being equal, I certainly recommend using Lua as a scripting language. It is easy to interface with, easy to code in, and very fast. Despite its compact design, you can do a lot of things with its basic library, and you can extend it by adding your own libraries.

For example, in the MUSHclient implementation, all of the normal "world" script events are effectively an extra library added into the Lua script space, by MUSHclient at program startup.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Mon Jun 18, 2007 5:58 am   
 
Rorso wrote:

I think the biggest issue might be ethical concerns. For example say I write a full zScript interpreter for MushClient. While it would be nice to most players it could make Zugg upset. It is similar issue with making cMUD able to execute MushClient scripts.



Personally I am not too concerned if you simulate or otherwise make it possible to execute MUSHclient scripts in CMUD. For one thing, MUSHclient is now Freeware, and I don't therefore consider that you would be reducing my income stream a huge amount.

Second, there is clearly some cross-pollination between client user bases. I get people on my forum asking how to convert zMUD scripts to MUSHclient, and you get people on this forum asking the reverse. Overall it no doubt balances out a bit.

It seems to me that if we want to encourage text-based MUDs as a genre, the more co-operation between clients the better, and if we encourage a shared script language (eg. Lua), then that is very likely for the good.
Reply with quote
chosig
Novice


Joined: 20 Apr 2008
Posts: 39
Location: Sweden

PostPosted: Thu Jul 17, 2008 8:10 pm   
 
Nick Gammon wrote:
It seems to me that if we want to encourage text-based MUDs as a genre, the more co-operation between clients the better, and if we encourage a shared script language (eg. Lua), then that is very likely for the good.


I have to second this, even go further and set up a standard for let's say mapper database backends etc. so a map can be used no matter which client the end user prefers.

As time passes clients get more and more monochrome when it comes to speed, looks etc. - it's all up to the users preference rather than which feature a client has (they all have pretty much the same), and when you count the amount of RAM in a computer by the gigabyte, who cares if a client uses 64K or 256MB? :P
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net