Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ Lua ➜ Lua script idea

Lua script idea

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Ix   Canada  (3 posts)  Bio
Date Wed 15 Jun 2011 11:08 AM (UTC)
Message
So I had an idea, and I was wondering about the feasibility of it. My idea is to have a folder of Lua script files to be loaded and run on-demand. The idea behind this is that each file would have a main() function. The final result is that this should be self-contained scripts with their own functions (which have no interaction with other script files unless called using an include directive).

But I'm wondering if there is a way to contain these scripts using your script engine implementation, and have each script file be self-contained so as not to do something silly like accidentally call a function from one file in another one.

Is this feasible, or would it require a rewrite of the implementation?
Top

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #1 on Wed 15 Jun 2011 05:36 PM (UTC)
Message
Basically, there is the scripting environment which has its own context, and MUSHclient which has its plugins (or the main context) that each interface with their own seperate scripting environment.

Thus, give each file its own plugin, and you know for sure all the MUSHclient related stuff is also in its own context. If you do not need MUSHclient matters to be seperate, rely on the Lua facilities for loading scripts alone - they support sandboxing. However, do know that this means these scripts can interfere with one another as they have access to the triggers, aliases, variables, etc bound to the MUSHclient context, and in that manner can interfere with one another.

About your idea: why do you not familiarize yourself a bit with the MUSHclient scripting facilities so you know how the different parts fit together? Your question, pardon my rough and direct way of saying it, sounds as if you have a vague idea, and if it cannot work you expect MUSHclient to be rewritten to suit it.

MUSHclient is pretty powerful and has plenty of facilities in place that would support your general scenario: you just need to determine what exactly it is you want, and then try to script it. If you have concrete problems, we can help with those - vague ideas are very difficult to respond to.
Top

Posted by Ix   Canada  (3 posts)  Bio
Date Reply #2 on Wed 15 Jun 2011 07:22 PM (UTC)
Message
While I appreciate your reply, this thread has nothing to do with MUSHClient itself and is about Gammon's implementation of Lua in Smaug.
Top

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #3 on Wed 15 Jun 2011 09:59 PM (UTC)
Message
Oh oops. I saw it was the Lua subforum, but I totally failed to spot it was in the SMAUG section rather than the MUSHclient one.

Can't help you in that case, although I think you can get pretty far with a pure Lua implementation - especially if you set up the proper environments.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #4 on Wed 15 Jun 2011 10:03 PM (UTC)
Message
Ix said:

But I'm wondering if there is a way to contain these scripts using your script engine implementation, and have each script file be self-contained so as not to do something silly like accidentally call a function from one file in another one.


Well anything's possible. My implementation (as I recall, it is a few years ago) had a different script "space" for each character. This had the flexibility that a problem with one player would not affect another.

To have multiple script files (per character, is that what you mean?) one approach would be to have multiple script spaces, or perhaps just create a script space, do something, and then destroy it afterwards.

There is nothing particularly wrong with doing that (for example in MUSHclient if you do a Global Replace in the text editor it briefly creates a script space for executing your find-and-replace).

However what you get in safety you lose in convenience. For example, making/destroying script spaces loses persistence of variables.

Or you could have one script space per script file. This would let variables persist at the expense of using more memory (which may not matter that much these days).

Another approach is to just try to "sandbox" scripts in a single script space. Using "environments" helps do that quite well. In fact the Lua "module" approach is designed around that. Using modules (and without the "seeall" technique) each module has its own global variables. Inside a module you basically only expose what you want, and thus local variables inside the module are protected.

This is (depending on your exact requirements) probably the best and simplest approach. Just make each file a module that is required when needed.

- Nick Gammon

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

Posted by Ix   Canada  (3 posts)  Bio
Date Reply #5 on Sun 17 Jul 2011 12:00 PM (UTC)
Message
Nick Gammon said:

To have multiple script files (per character, is that what you mean?) one approach would be to have multiple script spaces, or perhaps just create a script space, do something, and then destroy it afterwards.

Yeah, this is what I had in mind actually. A "fire and forget" approach if you will for simple things like replacing the conventional one_hit and damage functions with Lua counterparts which allow for scripted weaponry.

So say, you fire a laser blaster in a Star Wars Reality MUD and it's set to stun, the Lua can actually determine if it needs to even bother firing off a stun function which adds a stun timer, etc, etc.

I also had this idea for boss mobs and things like that, creating enemies which are not meant to be taken down by a single player. So it becomes more like a console RPG or even an MMO as a bad example because I don't know a better way to feasibly explain it.

So say the players are taking on a boss mob who has thousands of HP and the players themselves have maybe hundreds. Obviously you have a jedi or a field medic or some such who is treating the wounds of his fellow party members.

But the actual functionality itself is meant for the boss, so when the boss say hits 75% hp, the Lua script for the boss determines to throw in the function for that and the boss says his spiel for now being at 75% hp, fires any special attacks, etc.

It's very railroady/story-driven so I mean, the mechanics themselves may or may not be fun, you can never really tell, but the point isn't whether or not it's fun at this time (though that is an important factor), this is just about adding in the possibility for such wild experimentation.

Obviously I've spoken more than I needed to, trying to explain something you most likely figured out 4 paragraphs ago... But either way, thank you for your input on the feasibility of this.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #6 on Sun 17 Jul 2011 09:39 PM (UTC)
Message
I don't see any big problem with that.

For example, in MUSHclient, when using the inbuilt Notepad editor, and using the Search Menu -> Global Replace function, it actually creates a Lua script space every time you run it, and calls string.gsub to do the find-and-replace action (once per line, if you are replacing on a per-line basis).

Creating a Lua script space would only involve a few memory allocations internally, plus setting a few variables, so it should be quite fast.

Personally I think I would use one script per boss fight, not each fight round, that way the script can do something (say) every 5 fight rounds or something like that.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
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.


24,827 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.