function test(ch)
props = {name, level}
for i, v in ipairs(props) do
ch:send(v .. ":" .. ch.v)
end
end
function test(ch)
props = {name, level}
for i, v in ipairs(props) do
ch:send(v .. ":" .. ch.v)
end
end
– 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
– 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
foreach my $i (sort keys %foo) {
print "$i = " . $foo[$i] . "\n";
}
you cannot call a Lua "mobscript" without setting up the userdata first.
Unless you store the userdatum somewhere, and access it later.
the mob somehow was killed, it would send in a pointer to a dead mob right?
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.
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.