02 May, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
Ok, i know there has been several threads about embedding Lua in C, but i was wondering if someone could expound a bit on what that might avail the programmer specifically. Let's say in a ROM or SMAUG project, what might some code look like? I know Aardwolf uses Lua as mobprog scripting for builders. Also, would it be suited to develop commands?
02 May, 2009, Kline wrote in the 2nd comment:
Votes: 0

An entire forum devoted to (one) implementation of Lua in SMAUG. Nick uses a single global state, though, but I don't know enough to state the pros/cons of that versus something like a state per player (or object).
02 May, 2009, David Haley wrote in the 3rd comment:
Votes: 0
Actually he uses a state per player for a lot of the interesting things, and a global state for other things. The embedding he has is not a full embedding where you can treat characters as first-class objects. If you read those forums you'll note that we talk about this for quite a bit. :smile: That said, it's a very good example for getting started.

As for what Lua gives you, well, it gives you a sane and far more powerful "mudprog" environment; it gives you a language that you can implement actual game logic in, including commands; and of course all the advantages of dynamic languages when working in a C/C++ environment.
02 May, 2009, quixadhal wrote in the 4th comment:
Votes: 0
Out of curiosity, has anyone attempted embedding Lua in Lua? Lua seems quite mature enough to use for a driver, and I always consider it a plus if the driver itself uses the same language (and utility code) as the game objects. However, for security reasons, you don't really want a program attached to an sword to be able to call arbitrary functions (such as I/O, threading, etc).

Since it seems to be fairly easy to pass things around from C to Lua, how easy is it to sandbox a Lua interpreter from another Lua interpreter?
02 May, 2009, David Haley wrote in the 5th comment:
Votes: 0
Well, the thing is that you can already create restricted execution environments for functions to run in, so you wouldn't need to create a sandboxed interpreter from inside another interpreter. But sure, plenty of people working with Lua have done this sort of thing. I haven't done it personally to implement a driver/scripting separation, however I have used restricted environments for other reasons and down the line restricting scripts will be one application.
03 May, 2009, Pedlar wrote in the 6th comment:
Votes: 0
I have done this sort of thing, in my Lua project I've been working on, all the game logic is in Lua, and I wanted builders to be able to make scripts for things such as mob progs, all the way to commands to enhance areas in some special way, so I built a sandbox inside of Lua to run Lua scripts built by builders, with its own _G array as to not write over the cores.
04 May, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
Thanks for the post to Gammon's site about SMAUG and Lua, awesome stuff!

I was wondering though, how different is ROM from SMAUG, my original project is a QuickMud base and would like to use Lua in it.

Mainly, i dont mind MobProgs, but i want to add a ton of stuff, like Quests, a Lottery, Auction-House. I also want to add commands that can be dynamically loaded.
05 May, 2009, David Haley wrote in the 8th comment:
Votes: 0
You will probably have trouble implementing interesting commands without a deeper embedding (one where character handles can be passed around as values). To answer your question, though, ROM isn't different enough that it would be terribly complex to adapt the Lua embedding.
05 May, 2009, Asylumius wrote in the 9th comment:
Votes: 0
yo dawg, I heard you like Lua, so I embedded an Lua in your Lua so you can Lua while you Lua!

… Sorry.