Guess who is trying to make a system again? *waits for the ruckus of boos from the crowd* Yea, Me.

Well I have Zmud and Mush, and I am trying Mush with Lua for now.

Anyway, I am trying to get into the habit of doing as much with Lua scripting as possible, and as little using Mush itself. So I am using variables defined in the script, and not in the Mush variables toolbox, save for the ones I want to be static.

Currently I am trying to do this (see below) and I am not sure what is the best way to get it done...


See, I want to do this in the script. I got this information from here http://www.gammon.com.au/scripts/function....me=AddTriggerEx
and I am not sure that I fully understand the long arse complicated trigger example he gives. Does it really need to be this long and complicated for a script function? I am not sure how this entire thing would be best handled in the long run though... anyway, to continue->


The above is being reused from something else I did about a year ago (that is still on the same thread...) It could be increased to include power and anything else I would want to trap off the initial score. I originally invisioned this as being one of those triggers that fires when you need it (here only when I login) and then vaniashes/deletes/what-have-you as discussed in the speed improvement sticky.


Anyway, thanks for all the help, I'm going to need it.

love,mimi

Hiyas.



A couple of things I notice right off the bat are that you have double quotes inside of doubles - change "Send ("score")" to "Send ('score')" and your flags need to be added together, so 513 instead of 1 512. You can also "OR" flags together. I think that's what I did in my code sample in the speed optimization sticky.

Also, you might need to clarify what you want this to do. In your current line, you're sending the actual text 'Send("score")' to the output window (your 2 in the code) if I'm reading it right.

The best way to understand all the arguments in AddTriggerEx, I think, is to actually look at the GUI screen for adding triggers. The options there match the options you have to supply in the code, and that can give you sort of a visual guide for what you're doing.

Another option is to create it as a MUSH trigger, but set it to disabled, then just enable it when appropriate rather than actually creating it on the fly, which you might find easier to get started, then convert it to an all-script trigger if you want.

Also, there's a different way to code triggers that you want to fire once and disappear. I think I have a code sample back in the sticky. Triggers that fire at login would definitely fall into that category.



What you might do is create these triggers and give them the same group name. Have your alias for score enable the group, run score, then disable the group after the last SetVariable is executed. Once again, that might be a bit easier than a complex adding and removing of several triggers.

What slows clients down isn't so much the number of coded triggers; it's the number of -active- triggers. Reducing the number of things your client is listening for at any given time is where you get the speed. I don't know what the speed difference is between enabling and disabling a trigger versus adding and deleting one, but I would assume the difference is not that dramatic.

I haven't coded a "score" refresh, myself, just because my maximums change so infrequently that I keep them as constants in my script and change them manually, and I'm continually updating the current values from the prompt. I wouldn't mind taking a crack at it, though, if you wanted to compare notes.

Would love to compare notes. I'm still learning. Basically this started as a really long script that would be a subroutine that would let me catch my variables off my score, and then segway into the autosipper, but I deicded that was kind of pointless.

I 'm leaving for Washington D.C now, so I can post a more indepth answer when I arrive.

love,mimi

Here's the score trigger I created. It uses Nick's Lua script for accessing MUSHclient variables easily, but you can easily replace the "var.name" with a "SetVariable(blah..)" function call instead. You should change out "Iasmos" with your character name, too (or just get rid of the first line of the trigger, if you like).



You don't want to use AddTriggerEx every time you login and want to check your score. Adding a trigger should be a one time thing. You can enable/disable it, if that's what you want to do, and there are better ways to script "do this at login" things.

Ok at a hotel so I now have some time to answer. Basically I was only doing this to see how these things worked. I am not too sure on a few things yet, definition wise.

1) Variables: Can be handled by the script (var :: "Blah" or something) or by Mush itself, in the mush variable toolbox. I think I want to handle mine by the script (with an afflictions {} array, maybe? effecient?) save for the ones that won't change very often.

2) Triggers: Can I put triggers in the script, or would I just put the triggers in the trigger toolbox in Mush and have it go to script, so that it does it's thing there? Is that more effecient than say, just doing the triggers normally in the toolbox?
a) How does a trigger, like getting hit with anorexia for example, start/goto a function/subroutine? I would just send to script , and in the script have the pattern match line there with a "when this happens do this" or if statments, set vars to 1, etc?

I am just really confused on what should be handled by the script, ideally, and what should be handled inside of mush itself.

Zarquan thank you very much for the example, I have learned a lot from it already. Is there a difference in using var.foo or SetVariable ('foo', 'true') ?

Time for bed, I should be able to post even better answers and such when we arrive, day after tomorrow.

Thanks for all of your aide, love-mimi

Lua's version of arrays are tables, and that's not a bad way to handle afflictions. In the system I'm writing, for instance, I have a table of the various afflictions and what things can cure them, and another table where I store what I'm currently afflicted with. The only thing you have to remember is that, when you log out, you have to store afflictions that you have that'll persist when you log back on.

The other thing to think about is variable accessibility. If I want a variable to be directly accessible from aliases and triggers, for example, and that variable exists solely in script, I have to have my alias or trigger call a function to change it, rather than just changing the value directly from the alias or trigger.

So, for instance, in the system I'm building, my bashing flag variable is handled by Mush, not my script, because when I type SETBASH, I want it to change to 1, and I don't want to create a scripting function just for this purpose.

Zarquan may have other thoughts on this, but generally, when I'm deciding whether or not a variable should be handled in script in or in Mush comes down to this for me:

1. Will the value change frequently and need to persist from login to login?
2. Will it be easier to have this value accessed directly from triggers and aliases rather than always going through script?

If the answer to either of those is "yes," then I make it a Mush variable. Otherwise, I put it in script.



You can put triggers in the script, as the function you mentioned earlier illustrates. However, I almost never do this, and it looks like Zarquan agrees. I find it easer just to create all my triggers in Mush and use script to enable or disable them (or groups of them) as need be rather than use script to create them all on the fly.

The exception to this (for me) are triggers that fire on a one-shot basis. I will usually create these in code, but that's largely personal preference. You could just as easily do the enable/disable thing.

I mean, in theory, you could do virtually everything in your system purely from script and World events, but you sort of hit a critical mass of effort vs. benefit once you get to the kinds of areas we're discussing, and you may even end up painting yourself into a corner by trying to do everything in script.

As to question A, you call a function actually by filling in the Script textbox in your trigger creation screen and (if I remember correctly) leaving it sending to World. Send to Script is typically used for executing actual script written in your scripting language directly from the trigger. It basically allows you to create your trigger, then write a block of script to run.

Here's me:

1) Aliases and virtually all triggers handled inside of Mush.
2) Variables that need to persist (that are usually changed from game session to game session) or that need to be accessed directly from triggers or aliases handled inside of Mush.
3) Everything else - script.



Zarquan is using a table to act as an interface to his Mush variables. There's an article on how to do this here: http://www.gammon.com.au/forum/?id=4904. This is also what I do. It's mostly a convenience/semantics thing, though. There is no real functional difference between doing this and SetVariable.

In your world properties, you will set a main script file. Use that file to store all your functions, script variable declarations, loading of other script files (if you break things up in to modules), etc.

In your trigger, when you send to script, you can call Lua functions and access Lua variables as though you were just coding any other Lua script, which is what I am doing in my example trigger. I use Nick's "var" module to make the SetVariable function just a little more integrated with my Lua scripts. Internally, the var table passes the values to the SetVariable function and they persist in your world variables.

On the subject of variables and what goes where, I recommend that temporary things not needing to be stored (session variables, some call them) be housed as Lua script variables and anything you want to carry over from one session to the next (persistent variables) be stored in your world file with SetVariable. The former is faster and usually simpler, but the latter is needed to keep your data around for next time you play.