Hi Rosko,
Quote: 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.
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.
Quote: What do you all think of an open source multi threaded mud engine written entirely in lua?
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...
Quote: 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 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++...
Quote: The portion of the project I am most concerned with now is writing a file editor,
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. |