Unless you store the userdatum somewhere, and access it later.


This is a good example of a potential problem, yes. Some codebases don't actually extract mobs until the end of the whole round, even if the mob died, to simplify this problem.


It's extremely plausible, and it's a problem that affects the C side as well! It is made even more complicated when you start having to manage things in two places at once…

The ID system is like a safety net. I find it very useful in helping find cases where you left dangling references, and not blowing up the MUD because of it.

You can make it very convenient; you can make the getter return an actor, but if the actor id exists and refers to an invalid actor you transparently return nil instead. Callers are therefore completely unaware of the difference between not having an id, vs. having an invalid id.

actor2 = actor:getOpponent()
if actor2 then
  actor2:poke()
end

This code doesn't care at all about invalid IDs etc., as long as getOpponent is careful to return nil when the ID refers to something that doesn't exist anymore.

I'm trying to figure out a way to access an objects members dynamically.
What if you wanted to make a table full of properties, and then access them during runtime?

function test(ch)
    props = {name, level}

    for i, v in ipairs(props) do
        ch:send(v .. ":" .. ch.v)
    end
end

This obviously does not work, instead it just prints the letter "v" as the value.
In Ruby this is easy with symbols.

Johnny, instead of using ch.v, I believe you'd want to use ch[v]. The .member syntax is just shorthand for ["member"], so ch.v is actually ch["v"], which isn't what you wwanted.

Well, actually, the above code won't really do anything useful, because 'name' and 'level' aren't defined :wink: (I assume you meant them as strings.) It won't print the letter 'v'; it will print ch["v"] (as Twisol said) which is likely to be nil, meaning that what is printed is actually "v:".

Actually, if you try to use the .. operator on a nil value (such as ch.v), you'll get an "attempt to concatenate a nil value" error, so I don't know where he's getting his output.

Oops, sorry! You are correct about that. 2am over here after a long day… :redface:
(This is why it's useful to post actual code you're running :wink:)

Thanks for the tips guys.
Here is the actual code now

– test olc file for now

mobProps = {name  = " Name: ",
                        title = "Title:",
                        gold  = " Gold: ",
                        level = "Level: "}


– wrap things up with the olc session
local function quit(ch, olcObject)
        ch:quitOlc()
        olcObject = nil
end

function olcMedit(ch, argument)

        if argument == " " then
                ch:send("#B—- M-EDIT —-{w\r\n")
                for k,v in pairs(mobProps) do
                        ch:send(v .. ch[k])
                end
                return
        end

        if argument == "done" then
                ch:send("{gQuitting R-EDIT{w")
                quit(ch, argument)
        else
                ch:send("What? You are in #BM-EDIT MODE{w")
        end

end

OUTPUT:
—- M-EDIT —-

Title: Lord of Gondor
Level: 60
Name: Aragorn
Gold: 0

The funny thing, is that it's not in order. Anyone know why exactly?

Lua table iteration is in arbitrary order (this is the case for many languages' maps, incidentally). If you wanted to print the keys in some specific order, you'd have to sort a list of keys in that order and then iterate over that list, indexing into the table appropriately.

For example, this would work in order:

– test olc file for now

mobProps = {
  {name = " Name: "},
  {title = "Title: "},
  {gold  = " Gold: "},
  {level = "Level: "},
}


– wrap things up with the olc session
local function quit(ch, olcObject)
        ch:quitOlc()
        olcObject = nil
end

function olcMedit(ch, argument)

        if argument == " " then
                ch:send("#B—- M-EDIT —-{w\r\n")
                for k,v in pairs(mobProps) do
                        ch:send(v .. ch[k])
                end
                return
        end

        if argument == "done" then
                ch:send("{gQuitting R-EDIT{w")
                quit(ch, argument)
        else
                ch:send("What? You are in #BM-EDIT MODE{w")
        end

end

…Wow, for some really weird reason, the @@-at-start-of-line-to-highlight thing won't work when you have it on a bunch of lines that are right next to eachother. >_>

Cool, thanks.
With this power, it's going to be very easy to create an OLC that is truly extensible.

Tables (AKA associative arrays) will usually use some algorithm under the hood to maintain the key -> value mapping with some efficiency. Some languages (perl) call them "hashes", because the engine uses a hash table to do that. Because of this, the order keys are returned is not easily predictable. I believe perl only says that the order won't change if the mapping itself hasn't changed, and I don't know if Lua would even give you that much.

In perl, it's common to see things like:

foreach my $i (sort keys %foo) {
  print "$i = " . $foo[$i] . "\n";
}

Perl looks pretty nifty.
This is totally off topic, but why arent there any perl muds out there?
Does the language lack a socket lib?

Oh my. It's not that Perl lacks a socket lib: it's that you haven't seen enough of Perl. :wink:
Perl's philosophy is that there should be many ways of doing anything. This results in a language with all kinds of syntax for doing all kinds of things that look the same but aren't, look different but are the same, etc. It has a lot of quirks, and a lot of "features" that make life easy in some cases but miserable in others. For instance, hash table keys must be strings, and if you pass in anything else, it is stringified first…
For the record, I actually quite a lot about Perl and have used it for a while and still use it, it's just that as a language I find it to be relatively unpleasant for anything non-trivial. It's very good at what it was designed for: writing short scripts to manipulate text. In fact, it's extremely good at that. But for large programs… "just say no"! :wink:

Just say no to perl. No matter how many people tell you that you'll look cool doing it.

lol, ok then. And yes, I have seen very little Perl.

Actually, there IS a perl mud out there.
I believe it's called "Northlands". It made my eyes hurt…. as does most perl that I didn't write myself. :)

Not saying I write really good perl, but perl is often described as a "write-only" language.

Akoya
Anarres (Perl LPC Mud driver)
Northlands
PerlMUD
PoeMud
PerlMOO
And MOOiX and XpertMud which incorporate Perl as a programming language

It takes a lot of discipline to write "world-readable" perl. It's possible to write quite clean perl, you just have to pretend that you're not allowed to use a lot of language constructs (such as funny one-character variables).

Lua question: :biggrin:
I've added a command for reseting the Lua state. This allows me to keep the mud running while making
changes to my scripts that are run in a given state. Is this because after a file is loaded, it is then ran
as bytecode? Is there a more practical way to refresh files than destroying the state, and creating a new one?

You can re-load and execute a Lua file by using the dofile() function in Lua or luaL_dofile() in the C API. You'll want to make sure that there's no cruft left over from the previous time the file executed that could cause things to go bonkers.