Multiple MOB and Influence Tracker

Posted by Thuzle on Thu 24 Aug 2006 01:29 AM — 6 posts, 23,001 views.

Thuzle Thu 24 Aug 2006 01:29 AM #0

"monk74904" a monk disciple in grey robes
"monk74869" a monk disciple in grey robes
"monk74940" a monk disciple in grey robes
"monk74145" a monk disciple in grey robes
Number of objects: 4

This is the main piece of information I need to work with in my mud. I currently have a trigger to pull the first monk into a kill variable (@prey) but I need to somehow keep track of which ones I have killed (Won or Lost)because they don't go away.

Once kept track of, the next step is to bring that screen up again, and have it check with an if statement agaisn't whats already been influenced.

That way I don't have to walk into a room of 10 Monks, check the numbers by hand to see which I've fought and when checking the list such as above, it will automatically select the one I haven't.

Last thing is a clear command for the array.

I am just not sure how to do this in MushClient. If anyone could give me some pointers?

Ked Russia Thu 24 Aug 2006 05:00 AM #1

You'll need a script along the following lines:


influenced = {}

function PickTarget(n,o,wildcs,...)
  local mob = string.lower(wildcs[1])
  if not influenced[mob] then
    SetVariable("prey", mob)
  end
end


function SaveInfluenced(...)
  local mob = string.lower(GetVariable("prey"))
  influenced[mob] = true
end

On top of that you'll need two triggers: one to match on the output you quoted and call the PickTarget function with mob's id in the first wildcard, and another to match on whatever message is given when an influence succeeds or fails and call the SaveInfluenced function.

Thuzle Fri 25 Aug 2006 12:40 AM #2

Thank you for the information. I'm not very proficent with scripting or coding, but can find my way eventually.

I wanted to input the script as either VB or Lua.
I'm getting most of the information from the script, but don't get all the items inside PickTarget() or the extra dots in SaveInfluenced.

This script is nice and will allow me to use the SaveInfluenced bit to colour the numbers of those influenced as well on a successive IH.

Help me understand the (...) and what needs to be in PickTarget and why?

Ked Russia Fri 25 Aug 2006 07:25 AM #3

The script is in Lua, and the "(...)" means that the function can take any number of arguments (including no arguments at all). It allows that function to be conveniently called from either a trigger or a script.

The pick target must be called by the mob trigger. The one that matches on the: ""monk74904" a monk disciple in grey robes" lines. The only requirement is that "monk6354" (without quotes) is in the first captured wildcard. So the trigger might look like:

^"(\w+\d+)" .*?$

Nick Gammon Australia Forum Administrator Fri 25 Aug 2006 07:33 AM #4

Quote:

The script is in Lua, and the "(...)" means that the function can take any number of arguments (including no arguments at all).

However in your example, the ... is not necessary because you are not using the optional arguments. Lua will happily accept more or less arguments than the function defines.

For example, supplying too few arguments:


function foo (a, b)
  print (a,b)
end -- foo

foo (1) --> 1 nil

You can also supply too many arguments:


function foo (a, b)
  print (a,b)
end -- foo

foo (1, 2, 3)  --> 1 2

In this case the 3 is discarded.

However if you want to use the ... construct, then everything from ... onwards is put into the local "arg" table, like this:


function foo (...)
  table.foreach (arg, print)
end -- foo

foo (42, "nick", "gammon", 12345)

Output
1 42 
2 nick 
3 gammon 
4 12345 
n 4

You can see from this that arg is a table comprising the 3 arguments in numeric order (argument 1 is 42), and also an extra entry "n" which tells you how many arguments were supplied in the first place.

Ked Russia Fri 25 Aug 2006 07:58 AM #5

But I find (...) to be more descriptive of what's intended: allow the function to be called from both triggers and scripts without arguments. I use empty parameter lists for functions to be called only from the script, and it's very helpful in distinguishing how what is called by just glancing over the code.

And I never let functions that can be called both ways accept any meaningful arguments, since that leads to needing awkward decision-making code within the function's body.