lua programming and lua mud server specifications

Good day all,
I have recently started learning lua using the ebook Lua for absolute beginners - published by Wrox.
I am in the middle of chapter 4 which covers tables.
It does seem tables and function calls in assignments are written moderately different in lua 5.0 in comparison to 5.1.
Most bits of third party documentation do not seem to indicate the applicable lua versions used by each author.
The book I am reading is great over all, the one problem I have had however is with the tendency to use massive statements.
These statements usually combined three or more function calls on a single line.
Reviewing such lines line by line is all but impractical using a screen reader.
Reading such lines one character at a time is the only way I have found,
of keeping track of the characters in the line and the meaning behind each expression.
I eagerly await responses to this thread, I believe this thread will be a great resource to lua beginners and enthusiasts.
What reference material do you all use when looking up information on lua 5.1?
I imagine many lua programmers could use some more documentation on the lua language.



On another note, I would also love to discuss this mud engine idea.
What do you all think of an open source multi threaded mud engine written entirely in lua?
Maybe we should have a driver thread, mudlib thread, and a character thread.
The driver would also be written in lua,
but could be limited to providing socket management and security.
Sorry to digress, but one feature that could be extremely helpful is instance support allowing for different instances of a lua file to run at the same time.
I imagine nothing would be sent to a socket by the driver,
aside from error messages and a new users guide for mudlib writers.
The mudlib thread would handle all the static game content and most dynamically generated game content.
I think driver separation from the mudlib would be great for a server written in lua as well.
Its possibly even more important than in your average mud running a pre-compiled binary.
I would like for all mudlib coding to be done in game.
I can imagine a setup where the stock driver configuration without an available mudlib would accept connections on the main port and display the mudlib developers guide I mentioned.
The next step would then be to edit a configuration file and enable the administrative port by changing the port number from 0.
The administrative port would drop the user directly into a file manager where new files can be created,
and any file inside or under the mudlib root directory could be edited.
The idea behind such a setup being that the administrative port is not made to be used on drivers with any sort of mudlib to speak of,
the expectation would be that mudlib writers would write an in game interface to the modules used by the admin port.

Now, moving on to imbedding vs extending...
I would love to see discussion of the pros and cons of writing parts of the mud server in a systems programming language or at least a compiled platform independent language.
I imagine I will eventually start a thread specifically for that topic.
The portion of the project I am most concerned with now is writing a file editor, I would not even know where to begin if asked to write one myself.
At least I would be sure to learn a lot because there are a lot of important concepts I must understand before writing the most basic of editors.
I want to read docs and implement what I learn in example programs before I start a real project.
So, hopefully I can get started in a month.

I would like to thank Nick and David for there work bringing lua to the mudding community.
It was there work on adding lua to smaug that got me interested in lua.
So, maybe some people will have fun adding lua to there established diku derivatives,
and then eventually begin working on a custom mud written in lua.
I believe lua has the capability to draw many pragmatic creators away from dikus and lpc based muds.

Thank you all for your time and thanks in advance for your responses.

Hi Rosko,


I started using the Programming in Lua book (http://www.lua.org/pil). I've since bought both the first version (for Lua 5.0) and second (for Lua 5.1). When I need to look things up, I almost exclusively use the Lua manual (http://www.lua.org/manual/) although to be truly intelligible it requires you to be fairly proficient already. Those two resources are pretty much all I use -- well, that and following the Lua mailing list, seeing the tricks used by truly expert Lua programmers.


I'm not sure I like the idea of multi-threading in Lua. My understanding is that to get concurrent multi-threading, you need to do some messing around in the Lua core implementation, and it's considered an "at-your-own-risk" type of thing. That, and I believe that Lua provides no built-in synchronization primitives, so you would have no way to enforce thread safety.

If I were to have multi-threading, it would be with C++ providing it. The networking would most likely be written in C++, and would be in its own thread, and pretty much everything else would be in thread containing just a Lua interpreter.

Still, I'm not entirely sure multi-threading is appropriate for all tasks. I think that it makes a lot of conceptual sense to think of the networking doing its own thing over in that corner, and the game world evolving on its own over there, but I'm not convinced it would be the easiest to implement.

If you look at the BabbleMUD page (http://www.babblemud.com) under the section 'engine specs', I explain a little more what I intend by the distinction between those two threads. Of course, that was written several years ago by now (heh...) and doesn't take into account Lua at all, but many of the concepts are the same...


I agree that this might be better served by its own thread. The short version from my end is:

- there tends to be better support for low-level systems stuff like networking and threads in non-scripting languages like C, C++, and Java for that matter (thread support is built-in for Java)
- the scripting language gives you flexibility of data structures and programming in general; it is a fair bit easier to whip things up in an interpreted language that doesn't require you to specify all data structures in advance.

I'm not sure that Lua is inherently better for writing MUD servers in all respects, once you have the end result in hand. The main feature that is a big strength of Lua's is coroutines, which can be implemented using threads but you'd have to do a fair bit of work yourself to make them behave the same way. Lua's main strength in my view is the ease and rapidity of the development process. But, there is something to be said for the type rigidity of languages like C++...



I'm assuming you mean something like a shell environment, given your previous discussion of the admin port that lets people create, edit, delete etc. files. I'm not really sure, either; a lot of that support isn't provided in stock Lua and you would need a module like LuaFileSystem.

That said, implementing a shell is something that's been done over and over and over again. I wonder if it would be possible if there are libraries for shell environments that you can just stick right into your server application... that would make this task a lot easier. Especially if from within that shell you could invoke normal OS commands, esp. text editors like vi.



p.s. It occurs to me that it might not be that easy to read the quotes with a screen reader because it's just HTML 'hr' tags... please let me know if it makes life harder for you.

I describe the differences between Lua 5.0 and 5.1 in this thread:

http://www.gammon.com.au/forum/?id=7322

Really, things are pretty similar, although people writing for Lua 5.1 tend to use some of the new features, like #x to find the "length" of x.

For documentation, I have the Programming in Lua 5.1 book, because I like hard copy, but for quick reference I just type in the word I want into MUSHclient's editor and hit Ctrl+Shift+Alt+L to bring up MUSHclient's Lua help (which I wrote, *cough* *cough*). This has one help page per Lua function, and I find it pretty helpful as a quick reference.

However this is really a function reference, not a syntax reference.

Like David, I personally wouldn't multi-thread. The problems with synchronizing threads, to me, throw away the advantages of them. However I *would* use co-routines, and perhaps that is what you meant.

I already have a rudimentary Lua MUD server which I seem to recall releasing a copy of recently. However it really just shows the general idea, it is hardly complete.

David and I, along with various other people discussing things on this forum, have been toying with the idea of another MUD server for a while.

There is a lot to be said for an all-Lua server, as PCs these days are fast enough they can probably cope with the speed slowdown of running a server in a scripting language. Bear in mind that Lua is one of the fastest script languages around.

One advantage, as you note, is that you could program behaviours in-game (since they would be scripts).

I am not sure why you would want to write an editor, there are already some very nice ones, in particular Crimson Editor which I use these days for editing Lua files, amongst other things (like C).

I am glad my Lua additions to SMAUG got you excited by it - there have been comparatively few reactions to the work I did. However, the sheer fun of it was quite a lot of reward. ;)