Gammon Forum : SMAUG : Lua : Crossroads (Lua and Merc)

Entire forum ➜ SMAUG ➜ Lua ➜ Crossroads (Lua and Merc)

Crossroads (Lua and Merc)

Posting of new messages is disabled at present.

Refresh page

Posted by

Tyn USA (6 posts) Bio

Date

Sun 19 Nov 2017 07:23 PM (UTC)

Amended on Sun 19 Nov 2017 08:49 PM (UTC) by Tyn

Message

I posted a few years ago about integrating Lua with Merc. I didn't get far, as I did not have the bandwidth to dedicate to the effort. Fortunately, another coder stepped in and took on the project. She made good progress, but did not complete the integration, and we ended up abandoning the fork.

I have recently taken up re-integrating Lua. I'm excited about the possibilities, even after spending an embarrassing amount of time troubleshooting a problem with coroutines. I was working on a simple test, but although the wait function would register the thread in the threads table, the threads table would be empty when the update process would run. It acted like the threads lexical scope was different for the update function than it was for the wait.

The actual problem was that the coroutine was being run in the context attached to ch, and the update was acting on the mud-time Lua context. Intellectually, I knew that each context is separate and distinct. It was a silly mistake, and one I won't make again.

It's been 10 years since Nick provided his sample implementation of Lua into SmaugFUSS. At the time, he utilized a Lua context for each PC. He used a global Lua context for resets.

Is there a consensus as to whether it's better to run everything through one Lua context, or if it's more appropriate to use separate contexts? I'm trying to think it all through before I commit completely, and it seems wise to ask others that have already been down this road.

Thank you for your time.

Top

Posted by

Lasher USA (22 posts) Bio

Date

Reply #1 on Tue 21 Nov 2017 03:33 PM (UTC)

Amended on Tue 21 Nov 2017 04:23 PM (UTC) by Lasher

Message

Hi Tyn,

Every scripted event and interaction on Aardwolf is now LUA based and we have been doing this for about 10 years. I just counted and we have over 35,000 individual progs spread across items, mobs and rooms. Some are only a couple of lines, some are hundreds of lines in the end game heavily scripted "epic" areas or our new player tutorial. Some of them rarely run at all, some of them run every second.

I have a run counter on each individual prog but apparently never coded any aggregate reporting on that so I can't tell you exactly how many programs run in a day but, based on browsing the list since our last reboot, it is easily in the millions.

The game pulses 8 times a second and, even with all this going on, LUA handles it perfectly. I take a time stamp each pulse of the game and if the next time stamp is over a certain threshold, pop up a lag warning. Honestly it kind of blows my mind that Lua handles it all so well when I look at the amount of activity taking place every 125ms plus all the regular game code on top of it, but it does. I guess it's partly because I grew up on processors measures in hz and mhz, got 3 gigahertz! The only time we really see lag from LUA progs, and it's minor, is when a prog is trying to locate an item or mob by keyword and that item / mob doesn't actually exist. The reason is that the global item / mob lists are quite long and obviously a "fail" has to search the whole thing. It isn't enough for me to care enough to refactor everything into hash tables of keywords etc.

Hopefully none of this is coming across as "bragging", we're proud of what we have been able to do with LUA but that isn't the point, it's to give you some context for the answer. I can't say which is best as we never really tried it any other way but I can tell you that we run all of this in a single LUA context. We very strongly discourage global variables and have a naming convention that avoids conflict for those few we do allow. We have a review process on our test server before any new LUA programs make it to the live game so this works for us but it wouldn't be ideal in an environment where you allowed people to make programs "live" and just trust them not to make globals. I can point to a number of text book reasons why a single context is bad but haven't had a single one of them actually happen.

There are some very simple examples on the Aardwolf website if you want to see the kind of syntax we use. We're pretty easy going on memory usage so players have created local functions and tables in their own programs to create all kinds of crazy things, even a tetris game in text (*hat-tip Fiendish). Part of what helps there is a player 'luadata' array which is kind of a shared memory space but each area is only allow to access the bytes we alloc to it. If you tell me your area needs 5 bytes of "permanent" storage per player then to you they are luadata0 through 4 but behind the scenes you might actually be 110-114. I do also maintain a call stack back manually back in 'C' to prevent prog A (let's say flee') pushes player into prog B (attack in next room), which causes them to flee back into program A type loops and cut them off and unwind them at a certain depth.

I also do have some game commands and spell code written in LUA too but those are in a separate context completely sandboxed from anything on the "mobprog" side so didn't really bring them into the discussion. Mostly things like damage calculations so that I can edit them real-time without having to reboot.

At the very core of it all, it's been so long since I've looked at the C integration works with the metatables etc so I'm not sure I can help you much with things like getting coroutines working, but hopefully the reply helps a little with your decision.

Regards,
"Lasher"

Top

Posted by

Nick Gammon Australia (23,122 posts) Bio Forum Administrator

Date

Reply #2 on Wed 22 Nov 2017 06:26 AM (UTC)

Message

Thanks for that post, Lasher.

The Aardwolf implementation of Lua was completely independent of my suggestions ( http://www.gammon.com.au/forum/?id=8000 ). His MUD has been using Lua for many years now and it seems to work seamlessly.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Tyn USA (6 posts) Bio

Date

Reply #3 on Thu 23 Nov 2017 06:17 PM (UTC)

Message

That was a wonderfully detailed post, Lasher, which provides the feedback I was looking for. Thank you!

I was a bit concerned about scalability, but you've laid those concerns to rest.

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

15,608 views.

Posting of new messages is disabled at present.

Refresh page

Go to topic: Search the forum

top