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
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
top