Thanks elanthis. I was already 90% sold on Lua (as opposed to Ruby), but that just made it 100%. I've actually been reading the Lua tutorials, syntax guide and info on the C API - it all seems pretty straightforward. Wish me luck! And wish luck to my minions that I force this upon… :devil:

Reread original post. It's an invitation for anyone to evangelize their favorite embedded language.
Since that bores me…
I'd advance the idea that a much better general approach is to encourage the poster to identify what they want to accomplish and what features they require.

Tyche wins. I lose. :)

hah yes thanks for making that point for me.

fyi Java is the language that "runs" GroovyMud. Groovy is the scripting language the engine uses for the game implementation.

Integrating Jython, JRuby or a Java based Lua scriptengine will be added to my list of "things to do" :) With my architecture I could probably integrate any kind of Language Engine with my code, as long as I keep the game and the engine separate enough.

The idea of putting something like an interpreted script language on top of a compiled-interpreted language is largely alll about safety and sandboxing. I do not believe that Java has any significant sandboxing support at all, for example (you can lock the Java process down from the rest of the machine, yes, but you cannot lock one .class down from accessing interfaces defined in other .class files, iirc).

Java is supposed to have this whole security manager stuff that defines which methods can be called in which contexts and stuff like that. I have no idea how it works though and have never played with it.

yep groovymud uses all that good stuff..

The actual engine's basic security can be globally changed by editing the policy file. There are obviously some basic package security requirements, it needs access to its own jars and the like, but anything else is restricted.

I then use JAAS for user security. Users run commands wrapped in a PrivilegedAction check that throws exceptions for operations they are not given permission to do.

for example, when a user is running a script I do the following:

…
// run through a privileged action so we don't access stuff we
// shouldn't
Subject subject = player.getSubject();
Subject.doAsPrivileged(subject, new PrivilegedAction<Object>() {

  public Object run() {
        boolean error = false;
	try {
		Class<?> clz = getGroovyScriptEngine().loadScriptByName(argHolder.command); // loads the command using the engine

		MudPermission permission = new MudPermission(clz.getName());
		AccessController.checkPermission(permission);
		return doCommand(argHolder.command, argHolder.args, player);
	} catch (ResourceException e) {
		logger.error(e, e);
		error = true;
	} catch (ScriptException e) {
		logger.error(e, e);
		error = true;
	} finally {
		if (error) {
			try {
				player.getTerminalOutput().writeln("You cannot do that.");
			} catch (IOException e) {
				logger.error(e, e);
			}
		}
	}
	return null;
        }
   }, null);
}
…

each user has a user level that gets assigned to its subject a number of mudpermissions, one for each "level" of access (god being the most access, although I am thinking of making the levels of permission more flexible).

Ah, didn't know Java had that. I definitely need to pay more attention to the Java world, I guess. :)

I would highly suggest avoiding using numeric levels for access control. One of my friends running an RO server on eAthena just bitched to high heaven last night about that very issue, because he can't mix-and-match permissions. It's fairly easy to just define a set of permission and either assign those to users individually or assign them to permission groups and attach a user to a group. e.g. the GM group might have the KICK, TELEPORT, SPAWN, SUMMON, and INSPECT rights; the Support Staff group though might just have KICK, INSPECT, and TELEPORT; and the Builder group might have TELEPORT, SPAWN, and INSPECT.

Yes, you make it quite clear that you're God's gift to Muddom and that you are 'teh superior coder'. It's really unfortunate that you're not making an april fools joke, though it's quite funny regardless.



At least you get the name right now, and yes, it does tokenize its input. I guess you have issues reading C code, somehow I'm not completely surprised given how clueless you are at times, especially when it comes to the more practical side of things and seeing how things are connected and their relative importance.


mrmud has very strong variable support (better than anything lua would give you) which is the main thing lacking in classic mobprogs to get stuff done. Matter of fact is that you don't need c like power to create good mobile programs, just a bunch of basic if checks, variables, and some good utility commands to interact with the world. The complexity of Lua is actually a disadvantage to newbie builders.


When all I want to do is eat spaghetti I'll certainly take the spork over the swiss army knife - which generally doesn't come with a fork. Your argument shows the exact weakness of Lua, loop support is a security concern cause it can hang the mud, and with the additional power there's a lot more that can go wrong (no idea how strong its error messages are), and even then, you still need to interface it in such a way that it interact smoothly with a mud, which can be a massive pain in the ass.

Another strength of mrmud's mobprogs is that it can be easily extended, as done in emud which adds switch behavior, and it also has the basics for a generic logical expression interpreter.

:stare: :thinking: :stare:
:lol:

Sorry, I think that expresses my reaction better than words could.

Moving right along.


100% agreed. Permissions should be role-based, not linear-hierarchy-based. It's unclear who of the "head enforcer" and "head builder" would have more permissions: it's just different stuff. (Of course, to be fair, on many MUDs the staff all take on many roles due to being few in number, so it does kind of make sense to speak of some people being strictly more privileged than others.)

If you mean it splits on whitespace, it tokenizes, sure. If you mean it generates token data like any real parser, it doesn't. Difference in terminology, I guess, not a big deal.



Hahahahahahahaha. Ha.



Lua has that solved, actually. Try again.



Error handling is quite good in Lua.



Sure, it's harder than putting in mrmud mobprogs. Doing things right does generally take a little more effort though. And it'll bloat your line count OMGzors!

edit: removed unquoted bit of Scandum's text, oops.

I've found that mudprogs are actually quite difficult to extend, because the internals of the parsing are all icky. I've often thought it would be easier to rewrite it from scratch, although at that point it's even easier to put in a sane language like Lua. The only nice thing about mudprogs is syntax, but even that can be solved using token filters to some extent.

I almost started to write that exact response… The very notion is amusing, indeed - and I don't even know that much about Lua.

It's funny that we all three had the same reaction. You don't have to know much of anything about Lua to know that any decent programming language is very likely to have far better variable support than mudprogs.

To be fair to Scandum, we are probably misinterpreting slightly. I'm fairly sure he means that mrmud makes it easy to have global variables in the macro/mobprog language that don't pollute scope and don't require constant updates from the C code, because the variables can be just callbacks to functions (or it would be nice if they were callbacks, instead they're just a big if/else if/else if mess with strcasecmps… sloooooow). He's probably just not aware of what you can do with separate function environments and the __index metatable method, which he'd obviously not know about if he hasn't really dug into Lua before – those features are one of the unique "omg Lua rocks" things that most other languages lack. Just like he wouldn't know about Lua's loop hook support and its ability to easily solve infinite loops if he hasn't actually studied the C API.

I'll be frank, I don't really care for Lua's syntax. I'd much rather have JavaScript, or Cint, or some other variant. What makes Lua rock to me isn't the language itself, it's the runtime engine, its features, its performance, and its incredibly easy to use C API.

I've got a 10% done project somewhere with conversion of Lua syntax to JavaScript-like syntax, but it's slow going. The Lua parser is rather hard to hack on, unfortunately. They made a trade-off (the correct one for their target use cases) of having the parser directly generate the executable bytecode instead of parsing to an AST, so the parser is hard to extend but is blindingly fast and doesn't require a large amount of temporary working space to parse large programs. Given that it's used to process data files hundreds of megabytes in size, I don't blame them for making that decision – it's just making my little project a fair bit more difficult than I'd like. ;)

I guess it's your turn to be friendly and charitable. If somebody says A is better than B because they're ignorant about B, there's not a lot of misinterpretation to have other than on the part of the person making the claim…

Is there reason to think it might be easier to just write your own parser that generates Lua bytecode, and give that to the interpreter?

Why are mobprogs/mushcode more popular among non-programmers and easier for them to "get in to"? It's certain they both either fail or become unwieldy at hypertrivial tasks. My answer is that they both implement a significant subset of comparable mud/mush commands. I think that's key to providing an environment for user programming, particularly mud/mush programming. Capturing the domain with languages that make sense to the target audience is one reason to roll your own tiny language.

I fully agree. The nice thing about Lua in this respect is that the syntax is fairly bare (no funny symbols) and you can make things be function calls that don't actually look like them (no parentheses). 'course there are some gotchas etc. But yes, I think that syntax is very important to non-programmers. Fortunately, some languages (like Lua) allow relatively easy syntactic layer translation (in Lua's case, using token filters).

(FWIW I find mudprogs to at least be comprehensible, whereas mushcode blows my mind every time I see it.)

Probably. I haven't touched it in months, it's not particularly a high priority thing for me. Especially since there are things like DaoVM that are pretty much what I was aiming for. (I'm told the runtime is Lua inspired, and the syntax looks C# inspired, albeit with a few oddities.)

Truth be told, I've been getting a little interested in visual programming toolkits lately. At work we're doing more and more customized modules for clients that are really just very simplistic data abstraction and straight forward business logic kind of stuff, and I'm sick of working on trivial little crap like that. I know visual programming tools have been around for decades, but they've always kinda sucked – I'm wondering if maybe today's tools and techniques could make them more worthy of real-world use. Especially as I've been noticing that when I teach the high school kids on Tuesdays basic programming, the best way to express ideas is with visual aids like flow charts and traces.

It might be interesting to see what could done with a simple AI/mobprog visual development tool. I know a lot of professional games use similar tools, but they're very rarely ever released to the public, unfortunately. Especially with goal-oriented planning AIs and the like, it's pretty easy to express behavior has a set of distinct datums easily and understandably represented by a graph. Could still just reuse Lua backend (or Ruby or whatever) or code a slow-ass simplistic one from scratch as a prototype.



Very true. I'm a huge fan of domain languages. I only argue that implementing the entire stack from scratch is pointless when there is reusable code out there far better written than anything a single hobbyist could possibly cobble together in a few months and that the hobbyist could use as a building block. As David mentioned, Lua makes it pretty easy to develop a domain language with token filters, but it can easily be done on almost any other language as well. Look at the string handling / description macro thread for what i mean. In many cases a few simple regexes can transform a good domain language into just about any other script language, be it Lua, Ruby, Perl, Python, JavaScript, LISP, or whatever else you happen to be using.

If you're particularly thoughtful with the design, nothing stops you from devising a language that clearly and concisely covers the target domain while also retaining the full power of any other high-level general-purpose language.

As an example, look at the Smarty template language for PHP. It's a domain language designed so that HTML designers can stick basic backend display logic into their templates. For the most part, the syntax is fine. However, the implementation of Smarty is 100% pure and absolute shit, and as a result, those rare instances where a designer needs to do something a little more complicated end up being impossible. Then there's PHP-Sugar (personal project), which has a nearly identical syntax to Smarty, but has a recursive-descent parser and a real runtime stack (instead of just compiling to PHP code) which means that more complicated scenarios – rare as they are – can actually be handled, and the error handling is significantly better because broken code won't generate broken PHP output which results in useless errors referencing line numbers in generated files.

Point is, you don't need to sacrifice usability, power, speed, or anything else in order to get a simple, easy to learn, intuitive interface for designers. You just have to put in the effort to Do It RIght™. A little more work on your end once saves everyone else a little work many times.

I share the same curiosity mixed with skepticism due to past results. I think that for this to work, you would have to do a pretty good job at capturing the "core behaviors" that can be reused, in addition to relations between those core behaviors. Really, that is the problem with visual programming. If the blocks you have to build with are inexpressive, or if they're great but the relations to piece them together aren't appropriate, you have a poor result in the end of the day. Designing a good tool like this for non-programmers (or even for programmers really) requires extensive knowledge of what people actually do, not what we think they should do – not something that many of us programmers tend to think about quite enough. :rolleyes:

Amen to that. In fact, you don't just save time for other people: you save it for yourself as well.