03 Feb, 2008, David Haley wrote in the 1st comment:
Votes: 0
On Nick Gammon's forums, there has been considerable interest in adding Lua to SmaugFUSS. Nick has released a version of FUSS with Lua added, however, his approach – of including a Lua state per player – makes it complicated if not impossible in practice to use Lua for mudprogs. (Indeed, for his demo of scripting resets with Lua, he uses a global MUD Lua state.) I propose to add a single Lua state to the FUSS codebase and centralize everything in that state. The main goal of this endeavor would be to replace the obsolete and (IMHO) clumsy mudprog language with Lua.

Before embarking on this project, however, I would like to get a feel for how many people would find such a thing useful. I have been working on using Lua in my own MUD, and believe it would be a strong addition to the MUD community as a whole. Be that as it may, adding Lua to FUSS would not be directly beneficial to me as my game's codebase came into existence before FUSS even existed. Therefore, I would only even consider this project if enough people feel that it would be useful.

If, for instance, the only thing that people would feel is gained from the project is educational value, there are other ways of achieving that goal. I could perhaps release portions of my own codebase.

In any case, let's assume for now that people would like to see Lua replace mudprogs. Broadly speaking there are two extremes to aim for:

1. The "basic version". This would be adding Lua in as straight-forward a way as possible. Essentially, it would replicate what mudprogs can do, but in Lua. The main result here would I believe be educational: it would show how you would go about embedding Lua into a SMAUG codebase. The true power of embedding Lua would not really be evident from this version, although it would still be a significant step up from mudprogs.

2. The "right version". This would be adding Lua the right way, taking advantage of its power. For example, scripts could implement resumable coroutines; scripts would have data storage in the mob to persist across trigger executions; etc. In brief, this would be closer to what I actually do when I use Lua in my own codebase.



Naturally, the advantage to the basic version is that it can be completed fairly quickly with relatively little expense if the goal is educational. The "right version" should only be an option, I feel, if it is generally agreed upon that Lua should properly replace mudprogs as a long term option.

I am hesitant to go with the right version simply because I'm not sure how many people would really care, hence the point of this thread. I am not promising anything here, but I would like to seriously consider your opinions as to what would be worthwhile. If you would care about this work, please let me know; and if possible, please let me know why you would like to see it (as an example vs. actually using it).
03 Feb, 2008, Kayle wrote in the 2nd comment:
Votes: 0
Either one is fine with me. I'm partial to a "right way" implementation though, as long as it's not overbearingly hard to understand. Also, for simplicities sake, can Lua be masked to be syntactically similar to MudProgs just so that it's easier on Builders and Coders alike, so that the Coders don't have to give weekly classes on how to write in Lua? :P
03 Feb, 2008, Guest wrote in the 3rd comment:
Votes: 0
I think if the effort is going to be made, it should go all the way and replace the existing mudprog system. In doing so, any existing mudprogs already in the stock areas should be replaced with working Lua scripts so folks have some idea of what to do with it.
03 Feb, 2008, Tommi wrote in the 4th comment:
Votes: 0
If your going to do it David i think scrap the existing progs totally, i know that from discussions with my own staff that they would like to see the prog system replaced with something entirely better.

I have been keeping an eye on the lua discussions on nicks site with the thought of going down that path at some point. I just haven't worked out what i would like to achieve with it yet.
03 Feb, 2008, quixadhal wrote in the 5th comment:
Votes: 0
I also agree that replacing the mudprog mess with a real scripting language is the way to go. Lua seems to be a pretty easy and consistent language, and is used in several other large projects out there *cough*WorldofWarcraft*cough*.

The one thing I'm rather curious about is how much of the game state will be accessible to the lua scripting engine? In the Diku model, there really isn't much in the way of security because one tended to either write things as special procedures (in C) to do anything, or using mudprogs with narrowly defined windows.

With a true scripting language, it would be nice (from a coders point of view) to have more direct access to the variables out there in memory, but it would also perhaps cause some ugly security issues to come up – even if most access were read-only.
03 Feb, 2008, kiasyn wrote in the 6th comment:
Votes: 0
DavidHaley said:
2. The "right version". This would be adding Lua the right way, taking advantage of its power. For example, scripts could implement resumable coroutines; scripts would have data storage in the mob to persist across trigger executions; etc. In brief, this would be closer to what I actually do when I use Lua in my own codebase.


Even if you didn't do this version, I would be interested in how you would handle data storage.
04 Feb, 2008, David Haley wrote in the 7th comment:
Votes: 0
Alright. It looks like more people are leaning towards option 2 than option 1. I guess that's good because even though it means more work for me, it's the option I prefer as well. :wink:

Kayle said:
can Lua be masked to be syntactically similar to MudProgs just so that it's easier on Builders and Coders alike, so that the Coders don't have to give weekly classes on how to write in Lua? :P

To a large extent, yes. Lua is already quite similar syntactically to mudprogs, in particular for how if-checks work. The main difference will be the dollar sign business: in mudprog you have things like $n $N etc. but in Lua you can't use dollars in variables. Personally, I'm of the opinion that the dollar-letter notation is a little confusing anyhow, and it'd be much easier to have actual variables like "actor", "victim", etc. But that might not be desirable for other people.

One issue is that of string concatenation. In mudprog, you can write things like:
say Hello, $n

Lua would probably make you create the string dynamically one way or another; for instance you might have:
do(me, "say Hello, " .. actor)

The "me" could be implicit with some more or less tricky magic, so you could also have just:
do("say Hello, " .. actor)

This would work whether or not the 'actor' variable is just a string with the name, or a "pointer" to the character (userdata for those familiar).

Another option would be to look at a script and preprocess strings to replace $n occurrences with the proper text, but to be frank I think that's a fair bit of rather inelegant work just to keep an old syntax.

quixadhal said:
The one thing I'm rather curious about is how much of the game state will be accessible to the lua scripting engine? In the Diku model, there really isn't much in the way of security because one tended to either write things as special procedures (in C) to do anything, or using mudprogs with narrowly defined windows.

This is an interesting question. In an ideal world, security and safety issues aside, the entire game state would be exposed to Lua pretty much directly. Of course, it would be an awful lot of work to bind all those variables, especially since really you probably don't care about that many of them directly. It might be more worthwhile to provide templates and examples, and let codebases expose more of the C variables to Lua if they care to do so. The "obvious" choice for me would be things like being able to iterate over characters at the least in the current room; being able to look up characters and objects by name; etc. As for binding members of structures, such as character fields, it would probably be best to not give direct write access to anything regarding pointers and to force using helper functions instead.

Security is an interesting question. I'm not really sure how to best approach that problem. The cop-out would be to simply do nothing, which is pretty much what mudprogs do now. The presumption would be that the only people with access to making scripts would be those who have the competence to verify the script – basically how mudprogs work.

A more interesting approach might be to layer Lua functions into authorization levels much like how commands are layered by minimum level. The script would be given an access level, determined by the person who last edited the script (you can only edit scripts of your level) and whenever a call is made it would be checked against the script's level. The problem is that I'm not sure I like the idea of a linear scale of authorization; you might want some people to have access to some things but not necessarily others of the same "level".

I suspect that, for now, I will err on the side of a less interesting solution and not really do much. I'm not aiming to revolutionize the mudprog system; I'm aiming to have a saner and more powerful language there instead. You can already shoot yourself in the foot with mudprog; as long as Lua doesn't give you write access to important information like the character linked lists without going through protection like helper functions, I think it is acceptable for now to adopt the same policy.

Of course, I would include things like preventing scripts from running too long; since Lua has interesting control flow you could end up with infinite loops or recursion. You wouldn't want that to bring down your MUD…

kiasyn said:
Even if you didn't do this version, I would be interested in how you would handle data storage.

I would expose struct fields to Lua via standard metatable __index/__newindex binding. But I would also attach a Lua table to every entity that would represent its Lua data. This table would exist as long as the entity does, and would be used to add Lua-specific information to the entity. For instance, a Lua script could have state by setting flags in a character's Lua field. This would be very flexible, I think, as it would not force you to change C for every little thing. Of course, data stored in Lua like this will be harder to see from C than data stored in C…
05 Feb, 2008, Darwin wrote in the 8th comment:
Votes: 0
Working with Nick's code, I've found that it would be much better if there was a total of one global state for the entire mud. I've not quite figured out how to change his code to apply the character states to the mud state instead.

In any case, your option 2 seems a worth-while endeavor. I look forward to any work/progress you make with that project.
05 Feb, 2008, David Haley wrote in the 9th comment:
Votes: 0
Darwin said:
I've not quite figured out how to change his code to apply the character states to the mud state instead.

It would be possible by running all functions on a character in a special environment table. Basically, you would move the char-states' globals into a global-state environment table. This would be the straightforward so-called "naive" transition. But really, I'm not convinced that model is the best anyhow; for starters, it doesn't make a lot of sense to duplicate the quest data across all players. Also, making all the scripting player-centric makes it all but impossible to have stuff happen without a player somehow triggering it. (For instance, the resets-in-Lua code had to be done in a global Lua state.)
05 Feb, 2008, Darwin wrote in the 10th comment:
Votes: 0
Quote
I'm not convinced that model is the best anyhow; for starters, it doesn't make a lot of sense to duplicate the quest data across all players. Also, making all the scripting player-centric makes it all but impossible to have stuff happen without a player somehow triggering it. (For instance, the resets-in-Lua code had to be done in a global Lua state.)
I didn't mean to actually 'copy' the character Lua states into the global mud one, but rather have the one global state contain all the characters, so that there is only one instance of all the questing, resets, etc, functions within the state available to the characters. (If that made any sense.)

It just seems redundant to load all the same data for every character that logs in. It would be better to just load it once and share it with characters.
06 Feb, 2008, David Haley wrote in the 11th comment:
Votes: 0
Oh, sorry. What I meant is that the quickest way to move Nick's stuff to a single-Lua state would be to replicate it as I described; the better way would be to do what you describe (and what I had planned), namely to only have one instance of stuff for which you only should have one instance. You're quite right that it's redundant to have n copies of the quest data where n is the number of online players.
06 Feb, 2008, syn wrote in the 12th comment:
Votes: 0
Im very interested to hear if you start this as well, option 2 sounds great.

-Syn
28 Jun, 2008, Vladaar wrote in the 13th comment:
Votes: 0
DavidHaley said:
On Nick Gammon's forums, there has been considerable interest in adding Lua to SmaugFUSS. Nick has released a version of FUSS with Lua added, however, his approach – of including a Lua state per player – makes it complicated if not impossible in practice to use Lua for mudprogs. (Indeed, for his demo of scripting resets with Lua, he uses a global MUD Lua state.) I propose to add a single Lua state to the FUSS codebase and centralize everything in that state. The main goal of this endeavor would be to replace the obsolete and (IMHO) clumsy mudprog language with Lua.


David, we recently added Nick's latest Lua version. Can you elaborate more on how we will have a hard time with the global approach, and what it would take to make it a single lua state like you propose?

Thanks,

Vladaar
28 Jun, 2008, David Haley wrote in the 14th comment:
Votes: 0
I think I covered the problems with the per-character states enough on Nick's site; in brief, it makes it hard to do anything not centered on a character. It's why he had to use a single global state for the resets. A simple example is mob scripts running when a player is not there to trigger them. Making a single state requires treating actors (characters) as first-class Lua objects one way or the other. One way to do so is using userdata. It's something I'm experimenting with in my MUD, and I'll be using that to add it to FUSS. My first priority for now though is getting rid of the const stuff. (Well, actually, the first priority is finishing my move across the country and buying furniture for my empty apartment… :tongue:)
28 Jun, 2008, Vladaar wrote in the 15th comment:
Votes: 0
Heh, sorry I was playing catch up. I did not really follow the lua project much until someone finally talked me into
adding it. I was contemplating adding oasis olc, then got to thinking the prog system needs lots of help for
smaug. Lua seemed like the way to go.

So we added it, then having seen your post on it being not a good choice to try to use for mobprogs and such,
because of the global state it has made me a little frustrated.
28 Jun, 2008, David Haley wrote in the 16th comment:
Votes: 0
The global state is a good thing – it is necessary for progs to work the way you want them to. The per-character state solution is the one that limits you – it's why Nick had to use a global state for the resets.
0.0/16