If you use Lua modules, a useful trick is to set package.loaded[<module name>] to nil, and then re-require the module.

To expand a bit on what Twisol said, though, reloading things at runtime can be very tricky. Let's say you have some objects: recall that an "object" in Lua is nothing more than a table with an associated metatable. This means in particular that the "methods" on the object are references to entries in that metatable. So, what happens if you reload the module file? Well, Lua recreates the table, it creates a metatable, and all future objects will have that metatable. What of the old objects? Well, they still have their metatables – but to the old metatables, meaning in particular the old functions!

If you access Lua from C++ by traversing the globals table with string keys (i.e., you get the function by its name, not its value) then reloading is fine. But you still have other fun things to deal with, like any potential closures etc.

Yep, you are venturing into the world of persistence here. Even if your game itself is not persistent, it sounds like your sandbox is. You might want to poke a little at one of the mudlibs (gurba, phantasmal, etc) for DGD and try to work out what their object managers are doing.

For context, the idea of a persistent MUD is one where there are no resets, and a shutdown/reboot cycle means saving the entire state of the game world and restoring it. Very nice stuff to have, but one of the costs associated with it is that everything has to be accounted for in some manner. If you have an orc that inherits code from aggressive, living, npc, and object; making a change to the orc and updating him isn't too bad. It's when you want to make a change to living or aggressive and have those changes be propogated through everything that inherits them that it gets ugly.

Interesting.
I have thought about using persistence with my game. Not to start another serialization thread, but I
am considering using YAML or JSON to do this. The hard part is whether it's easier to dump from C,
or from the Lua side of things. BTW, @quix, is your avatar from EVE online? It looks familiar.

I've updated Cygwin to VM Ware hosting SLAX. So far it's pretty sweet.
However, I am having issues with linking Lua to my project.
Here's the output:

root@slax:~/mud/src# make
make: Warning: File `act_comm.c' has modification time 2.1e+07 s in the future
gcc -O -g -Wall  -c -o o/act_comm.o act_comm.c
gcc -O -g -Wall  -c -o o/act_info.o act_info.c
gcc -O -g -Wall  -c -o o/act_move.o act_move.c
gcc -O -g -Wall  -c -o o/act_obj.o act_obj.c
gcc -O -g -Wall  -c -o o/act_wiz.o act_wiz.c
gcc -O -g -Wall  -c -o o/alt_menu.o alt_menu.c
gcc -O -g -Wall  -c -o o/comm.o comm.c
gcc -O -g -Wall  -c -o o/const.o const.c
gcc -O -g -Wall  -c -o o/db.o db.c
gcc -O -g -Wall  -c -o o/fight.o fight.c
gcc -O -g -Wall  -c -o o/handler.o handler.c
gcc -O -g -Wall  -c -o o/interp.o interp.c
gcc -O -g -Wall  -c -o o/lua_charlib.o lua_charlib.c
gcc -O -g -Wall  -c -o o/lua_interface.o lua_interface.c
gcc -O -g -Wall  -c -o o/lua_mudlib.o lua_mudlib.c
gcc -O -g -Wall  -c -o o/lua_objlib.o lua_objlib.c
gcc -O -g -Wall  -c -o o/lua_roomlib.o lua_roomlib.c
gcc -O -g -Wall  -c -o o/magic.o magic.c
gcc -O -g -Wall  -c -o o/maps.o maps.c
gcc -O -g -Wall  -c -o o/save.o save.c
gcc -O -g -Wall  -c -o o/sha256.o sha256.c
gcc -O -g -Wall  -c -o o/special.o special.c
gcc -O -g -Wall  -c -o o/update.o update.c
rm -f merc
gcc -o merc o/act_comm.o o/act_info.o o/act_move.o o/act_obj.o o/act_wiz.o o/alt_menu.o o/comm.o o/const.o o/db.o o/fight.o 
o/handler.o o/interp.o o/lua_charlib.o o/lua_interface.o o/lua_mudlib.o 
o/lua_objlib.o o/lua_roomlib.o o/magic.o o/maps.o o/save.o o/sha256.o o/special.o o/update.o -O  -lcrypt -llua
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lvm.o): In function `Arith':
lvm.c:(.text+0xbf9): undefined reference to `pow'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lvm.o): In function `luaV_execute':
lvm.c:(.text+0x2009): undefined reference to `pow'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lcode.o): In function `codearith':
lcode.c:(.text+0x11ea): undefined reference to `pow'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_tan':
lmathlib.c:(.text+0x1ee): undefined reference to `tan'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_tanh':
lmathlib.c:(.text+0x22e): undefined reference to `tanh'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_sqrt':
lmathlib.c:(.text+0x27d): undefined reference to `sqrt'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_sin':
lmathlib.c:(.text+0x2be): undefined reference to `sin'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_sinh':
lmathlib.c:(.text+0x2fe): undefined reference to `sinh'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_pow':
lmathlib.c:(.text+0x488): undefined reference to `pow'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_log':
lmathlib.c:(.text+0x52e): undefined reference to `log'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_log10':
lmathlib.c:(.text+0x56e): undefined reference to `log10'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_fmod':
lmathlib.c:(.text+0x678): undefined reference to `fmod'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_exp':
lmathlib.c:(.text+0x6be): undefined reference to `exp'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_cos':
lmathlib.c:(.text+0x6fe): undefined reference to `cos'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_cosh':
lmathlib.c:(.text+0x73e): undefined reference to `cosh'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_atan':
lmathlib.c:(.text+0x77e): undefined reference to `atan'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_atan2':
lmathlib.c:(.text+0x7d8): undefined reference to `atan2'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_asin':
lmathlib.c:(.text+0x81e): undefined reference to `asin'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(lmathlib.o): In function `math_acos':
lmathlib.c:(.text+0x85e): undefined reference to `acos'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(loadlib.o): In function `ll_loadfunc':
loadlib.c:(.text+0x947): undefined reference to `dlsym'
loadlib.c:(.text+0x954): undefined reference to `dlerror'
loadlib.c:(.text+0xa2c): undefined reference to `dlopen'
loadlib.c:(.text+0xa41): undefined reference to `dlerror'
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../liblua.a(loadlib.o): In function `gctm':
loadlib.c:(.text+0x104e): undefined reference to `dlclose'
collect2: ld returned 1 exit status
make: *** [merc] Error 1
root@slax:~/mud/src#

Now, I can assume there's something up with the makefile, so here it is just in case you need to see it:

CC      = gcc
PROF    =
C_FLAGS = -O -g -Wall $(PROF)
L_FLAGS = -O $(PROF) -lcrypt -llua

SRC_FILES := $(wildcard *.c)
O_DIR = o
O_FILES := $(patsubst %.c,$(O_DIR)/%.o,$(SRC_FILES))

merc: $(O_FILES)
        rm -f merc
        $(CC) -o merc $(O_FILES) $(L_FLAGS)
        cp merc ../area
        ctags –c++-kinds=+cdefgmnpstuv –fields=+iaS –extra=+q *.h *.c
clean:
        $(RM) -f $(O_FILES) merc  *~ *.bak *.orig *.rej

$(O_DIR)/%.o: %.c
        $(CC) $(C_FLAGS) -c -o $@ $<

You need to link the math library, libm. Add -lm to the linker command line.

Oh, and also libdl, with -ldl.

They should both be added to the linker command line before -llua.

Thanks man! Helps a ton.

Not a problem.

You might consider making use of pkg-config, which helps in situations like these.

You can add something like this to your Makefiles (or use the autoconf support):

LUA_CFLAGS := $(shell pkg-config –cflags lua)
LUA_LIBS := $(shell pkg-config –libs lua)

CFLAGS := whatever $(LUA_CFLAGS) …

And then use those variables in your rules. pkg-config is a neat little tool that lets software specify the various options to compile/link it, and lets your Makefile or build systems query those options. Makes your code more portable (since the -lm -ldl are only needed on some systems).

Most good libraries come with pkg-config support these days so I'd suggest trying it.

Do note that for unfortunate reasons, the Lua pkg-config file is sometimes renamed on certain Linux distros. I would complain (loudly) to any distro you run into that does that. They think they're doing you a service by allowing multiple versions of Lua to be installed, but that's bullshit since the whole point of pkg-config is portable build systems and renaming the file totally freaking breaks that. Debian/Ubuntu in particular are guilty of this. (You have to pass lua5.1 instead of just lua to pkg-config.) Still, if you're forced to modify Makefiles or add complex build rules, it's a lot easier to add a check for which name to pass to pkg-config than it is to switch out the specific build rules. You can even do the pkg-config automatically with a small bit of effort…

Hell, here you go:

LUA_CFLAGS := $(shell pkg-config lua5.1 && pkg-config –cflags lua5.1 || pkg-config –cflags lua)
LUA_LIBS := $(shell pkg-config lua5.1 && pkg-config –libs lua5.1 || pkg-config –libs lua)

Very helpful elan!
I'll have to add that to the old "utility belt" :cool:

Ok, so I've switched to Ubuntu for support reasons. SLAX was not good enough to have as a long term server, so I made the switch.
I installed Lua with: apt-get install lua5.1 and it was a piece of cake. But now I'm having issues again, and I'm afraid I'm a total Noob with linux.
It's giving me this:

gcc -O -g -Wall  -c -o o/act_comm.o act_comm.c
In file included from act_comm.c:28:
merc.h:18:17: error: lua.h: No such file or directory
merc.h:19:20: error: lualib.h: No such file or directory
merc.h:20:21: error: lauxlib.h: No such file or directory
In file included from act_comm.c:28:
merc.h:790: error: expected specifier-qualifier-list before lua_State
merc.h:1011: error: expected =, ,, ;, asm or __attribute__ before * token
merc.h:1618: error: expected ) before * token
make: *** [o/act_comm.o] Error 1
johnny@ubuntu:~/mud/src$

I think thought liblua wasn't installed, but I found out that it was. Any ideas?

It can't find the lua headers files. Make sure they're where the code expects them to be. I think your second set of three errors also stems from that issue, because lua_State isn't defined.

EDIT: I'm a Windows user through and through, but those errors seem fairly OS-independant. >_>

EDIT 2: Okay, so David (below) saw the other possible issue: the lua files might be where they should be, but the code isn't looking in the right place. Nice catch :P

You need to add something like this to your makefile's compiler settings: -I/usr/include/lua5.1

Debian did a lot of work to support several concurrent versions of Lua; this is both a very nice thing and very annoying thing. In any case, you just need to tell it where to find the include files.

To confirm that that is where the files are, ls /usr/include/lua*

Also make sure you actually install the header files. Linux packages most libraries into two parts: the runtime files and the development files. If you just installed the lua5.1 package, you have only installed the runtime. I believe you need the package called lua5.1-dev to get the headers.

Thanks guys!

CC      = gcc
PROF    =
C_FLAGS = -O -g -Wall -lm -I/usr/include/lua5.1 -L/usr/include -llualib5.1 -llua5.1 $(PROF)
L_FLAGS = -O $(PROF) -lcrypt -llua

SRC_FILES := $(wildcard *.c)
O_DIR = o
O_FILES := $(patsubst %.c,$(O_DIR)/%.o,$(SRC_FILES))

merc: $(O_FILES)
        rm -f merc
        $(CC) -o merc $(O_FILES) $(L_FLAGS)
        cp merc ../area
        ctags –c++-kinds=+cdefgmnpstuv –fields=+iaS –extra=+q *.h *.c
clean:
        $(RM) -f $(O_FILES) merc  *~ *.bak *.orig *.rej

$(O_DIR)/%.o: %.c
        $(CC) $(C_FLAGS) -c -o $@ $<

This is what I'm working with to try to get Ubuntu to recognize Lua, ive done the whole ls /usr/include/lua* and everything is where it needs to be.
This is the output:

root@aragorn:~/rom/src# make
gcc -O -g -Wall -lm -I/usr/include/lua5.1 -L/usr/include -llualib5.1 -llua5.1  -c -o o/lua_charlib.o lua_charlib.c
lua_charlib.c:32: error: expected ;, , or ) before numeric constant
lua_charlib.c:46: error: expected ;, , or ) before numeric constant
lua_charlib.c:54: error: expected ;, , or ) before numeric constant
lua_charlib.c:63: error: expected ;, , or ) before numeric constant
lua_charlib.c:72: error: expected ;, , or ) before numeric constant
lua_charlib.c:94: error: expected ;, , or ) before numeric constant
lua_charlib.c:103: error: expected ;, , or ) before numeric constant
lua_charlib.c:123: error: expected ;, , or ) before numeric constant
lua_charlib.c:138: error: expected ;, , or ) before numeric constant
lua_charlib.c:186: error: CHL_newindex undeclared here (not in a function)
lua_charlib.c:187: error: CHL_index undeclared here (not in a function)
lua_charlib.c:192: error: expected ;, , or ) before numeric constant
make: *** [o/lua_charlib.o] Error 1
root@aragorn:~/rom/src#

What are the lines in question like? This doesn't look like a problem picking up the Lua files…

32: CHAR_DATA *L_getchar( lua_State *L ) { … }

It seems to be at the beginning of each function that uses lua_State* as an argument?

EDIT:
Oh Shyte! I just remembered that this is ROM and that L is pre-defined elsewhere (Facepalm)

That sounds like a great idea. :p

What? L being defined or the face palm? If the latter, that's just rude :rolleyes:

L being a macro. (I guess?)