Rock5's CountMobs userfunction

[rock5]

This is a simple function that counts the number of mobs around you. I've posted it in a number of places in the forum and I've now decided it's time to give it it's own page. I've also added a CountPlayers function in the same file for those times you need to know how many players are around you to make a decision.

CountMobs

CountMobs is obsolete. It's functionality has been added to the bot. You can use player:countMobs(inrange, onlyaggro, idorname).

Syntax:

• CountMobs(onlyaggro, inrange)

Arguments:

• onlyaggro - Set true if you want to count only mobs that are attacking you. Optional.
  inrange - The range in which you want to count the mobs. Optional. If omitted, it will count all mobs it can detect.

Example:

• Cast Purgatory Fire if 3 or more mobs are in range.

Code: Select all

if CountMobs(nil,50) > 3 then
	player:cast("MAGE_PUGATORY_FIRE")
end

CountPlayers

Syntax:

• CountPlayers(inrange, printnames, ignorefriends)

Arguments:

• inrange - The range in which you want to count the players. Optional. If omitted, it will count all players it can detect.
  printnames - If true, prints the names of the players. I find this useful if creating a wait loop so I can see how the names change over time while I wait.
  ignorefriends - If true, does not include friends in the count. 'Friends' includes names in your profile friends list, party members if in a party and warden pet if you have one.

Example:

• Code I use to wait until there is at most only one other player in the area I'm doing my dailies. The daily can only really support 2 players at a time.

Code: Select all

if CountPlayers() > 1 then
	print("Waiting till it's less crowded")
	repeat
		yrest(15000)
	until 2 > CountPlayers(nil,true) 
end

userfunction_countmobs.lua

Version 0.4 - Added ignoreFriends option to CountPlayers.

(1.32 KiB) Downloaded 325 times

userfunction_countmobs.lua

Version 0.4 Pre 745 version - For use with rombot versions older than 745.

(1.87 KiB) Downloaded 194 times

[abron1]

hey roc this is cool is there a way to count plz in range and wave at them and not wave at the same person for like 30 mins or a hour? because sometimes you can just wave at a person they wave back and they leave you alone.. or not think your botting... just a thought

[rock5]

These functions just count. You could modify them to do what you want but it would involve keeping some sort of table of players and recording when you've waved at them. I'm not inclined to do it for you. Sorry. I'm busy at the moment.

[Sota]

I do not know how to use it? Where to copy a file?

[rock5]

It's a userfunction file so goes in the userfunctions folder.

Then you can use the functions within whereever you want. Where you use them will depend on what you want to do.

[Sota]

Ok. Thank you. Good idea

[BillDoorNZ]

hmm...haven't had a chance to look at this one yet, but definitely a good idea

was thinking it would be even more useful if you could specify the point from which you wish the count to originate.

e.g. I want to know how many mobs are within 50 of me:

Code: Select all

  if (CountMobs(player.X, player.Y, player.Z, nil, 50) > 3) then
    player:cast("MAGE_PUGATORY_FIRE")
  end

and if I want to see if there is a big group clustered together for my RANGED AOE:

Code: Select all

  if (CountMobs(target.X, target.Y, target.Z, nil, 50) > 3) then
    player:cast("SCOUT_REFLECTIVE_SHOT")
  end

[rock5]

Funny you should mention that. I'm currently looking into making it so the bot can use skills such as Thunderstorm that require mouse clicks and I was thinking of adding more AOE options such as number of mobs in range.

[BillDoorNZ]

lol...very nice

that might tempt me enough to move my combat from DIYCE to the bot

The 2 main issues I currently have with doing this are:

• 1. Speed - running my diyce macro at 20 times per second results in much faster combat (buff checks etc)
  2. Scout Autoshot - my diyce macro checks the state of the autoshot skill before trying to use. i.e. local a1,a2,a3,a4,a5,ASon = GetActionInfo(2) -- # is Autoshot action bar slot number

[rock5]

1. I'd say in game code is always going to be faster. The bot relies heavily on RoMScript commands which are relatively very slow.

2. I don't think the bot checks the status of Autoshot but it does only use it once to turn it on. So it should work as intended.

[BillDoorNZ]

ah...nice....becuase i often run the bot in parallel to playing (get it to run me places etc and do merchanting etc) I have DIYCE running to speed up combat...however, it sometimes interferes with the bot itself so i should really convert to just using the bot combat when i go afk

[lisa]

The bot relies heavily on RoMScript commands which are relatively very slow.

Wasn't that because RoMScript checks for a response from game, I seem to remember a discussion about that a little while ago.
Like how we do

Code: Select all

local _time = RoMScript("GetTime()")

So the value of the in game function is returned in the code.
Might be more efficient to have an argument or 2 ways of calling in game functions. 1 when you need a value returned and another for just executing the in game function ?

[rock5]

Good point. I have on occasion used SlashCommand for just that reason. Makes a good point to have a look through the bot code for all the times it uses RoMScript and not expect a returned value. We could change all of them to SlashCommand. But SlashCommand needs to be prefixed by "/script". I'm not sure if it would be better to make a third simple SendCommand only function or add an argument to RoMScript to not wait for a reply. I should be able to easily see how the 2 options compare to each other. If the complex RoMScript performs as well, I'd probably go with that. The only problem is RoMScript already has a second argument so it would have to be

Code: Select all

RoMScript(script, default, noreply)

The other option would be a function like this

Code: Select all

function SendCommand(script)
    SlashCommand("/script "..script)
end

[rock5]

Looks like there is not much of a difference

Code: Select all

Command> st=os.clock() for i = 1,100 do SlashCommand("/script os.clock()") end print(os.clock() - st)
5.2860000000001
Command> st=os.clock() for i = 1,100 do RoMScript("os.clock()",nil,true) end print(os.clock() - st)
5.4890000000014
Command> st=os.clock() for i = 1,100 do RoMScript("os.clock()") end print(os.clock() - st)
5.6039999999994

I think there may be some situations where the returned value causes some sort or error that delays RoMScript but getting a returned value only delays it by about 6%.

But maybe if the ingame function actually takes longer then waiting for a response would takes longer and the difference would be greater. RoMScript does allow upto 800ms for a response.

I got a bigger difference with this example.

Code: Select all

Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.4650000000038
Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()",nil,true) end print(os.clock() - st)
5.7580000000016
Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
7.1270000000004

So depending on the script, some improvement might be had ignoring the returned value. I'll have to look through the code for any RoMScripts that look like they might be slow.

[lisa]

So when just using a skill the difference is minor but when doing 2 in game functions the difference gets more noticable?

The search I did found 800+ of "RoMScript" in bot and 157 were "= RoMScript" which wanted an actual value returned, there were also many that used RoMScript inside a table. So you could guess that 500+ uses of RoMScript don't require any value returned.

Might require more testing of different functions to see the effect it has, not sure if lag might play a part in the time aswell. So probably need to run the same code several times to see if there is any difference.


--=== Added ===--

Did some testing

Code: Select all

Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.743
Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.307

ran the same code several times and it did vary but only slightly.

Code: Select all

Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); RoMScript("SpeakFrame:Hide()") end print(os.clock() - st)
11.104
Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") end print(os.clock() - st)
10.592

Code: Select all

Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") loll = RoMScript("LogID"); end print(os.clock() - st)
15.939
Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") RoMScript("LogID"); end print(os.clock() - st)
15.956
Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") SlashCommand("LogID"); end print(os.clock() - st)
15.64

Seems that the time is very dependant on the in game function, if that function returns a value then both RoMScript and slashcommand seem to be much slower even when not actually setting the value to a variable.

Ran each code many times and didn't vary much each time.

[rock5]

I'm not sure I understand your examples. You have RoMScripts and SlashCommands mixed in the same line. The only ones that make sense to me are the first 2, which, by my example, should have been more different. I did them again.

Code: Select all

Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
6.626
Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
6.317
Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.425
Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.431

With no npc targeted.

Code: Select all

Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.956
Command> st=os.clock() for i = 1,100 do RoMScript("UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.916
Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.504
Command> st=os.clock() for i = 1,100 do SlashCommand("/script UseSkill(1,1); SpeakFrame:Hide()") end print(os.clock() - st)
5.506

That look more like the results you got. Did you have an npc targeted?

As to how many times RoMScript appears, it might improve general bot performance to change them all but we were mainly talking about spell casting. While casting I think it only uses RoMScript to CastSpellByName. Talking about casting, here's some tests casting.

Code: Select all

Command> st=os.clock() RoMScript("CastSpellByName('Wind Arrows')") print(os.clock() - st)
0.059000000000083
Command> st=os.clock() RoMScript("CastSpellByName('Wind Arrows')") print(os.clock() - st)
0.061000000000035
Command> st=os.clock() SlashCommand("/script CastSpellByName('Wind Arrows')") print(os.clock() - st)
0.055000000000064
Command> st=os.clock() SlashCommand("/script CastSpellByName('Wind Arrows')") print(os.clock() - st)
0.055000000000064

That's about 9%. Not really a huge difference. Personally I don't think that accounts for the bots slow casting. I suspects it's just because the bot does so much, even between casts. Whereas something like dyice, or whatever it's called, does minimal checks.

[lisa]

K I'll explain my reasoning for the last ones I posted.

Code: Select all

Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") loll = RoMScript("LogID"); end print(os.clock() - st)
15.939

So we have LogID and setting a variable to the returned value in 2 spots using RoMScript of course.

Code: Select all

Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") RoMScript("LogID"); end print(os.clock() - st)
15.956

Then the same code but not actually setting the returned value of the second to a variable, the time taken was almost exactly the same, so using the returned value didn't affect the time.

Code: Select all

Command> st=os.clock() for i = 1,100 do lol = RoMScript("LogID"); SlashCommand("SpeakFrame:Hide()") SlashCommand("LogID"); end print(os.clock() - st)
15.64

This is the same as second but used slashcommand instead of RoMScript on the second LogID, so it is comparing using slashcommand or RoMScript just for LogID, the other 2 lots of code performed each time is just to give it more to do in order to get a better comparison as the bot does them a lot in normal usage.

So no real difference to using the returned value or not.
slight difference in using slashcommand instead of RoMScript.
The actual in game function used did vary the time taken quite a lot though, maybe more so for addons then default functions.

My conclusion: It probably won't have that much of an affect on bot changing all of the existing code that doesn't need a value returned to slashcommand and we are talking 500+ times RoMScript is used when no return value is needed.

[rock5]

For starters, as your results imply, it doesn't matter if you assign a returned value from RoMScript to a variable or not. RoMScript still waits for the reply and does nothing differently.

Secondly, when comparing RoMScript with SlashCommand, I think it's a mistake to mix them in one test as only part of the time taken is due the the function being tested. The rest of the time, probably about 2/3 of the time, is due to the other commands that are identical in each test. So for all you know a slash command could take half the time of a romscript but, because you added those 2 other commands that don't change, it might look like it only reduced the time by 10% or something. These are hypothetical numbers but my point is, adding those first 2 commands skews the results. With my test, because only the one command is in the loop, I can say it's about 9% faster. But with yours you can't tell without knowing how long the first 2 commands take.

We have to also consider something else besides time. RoMScript has code that makes sure the code is executed (or at least tries a second time if it fails). A simple send only function wouldn't have that check. So that's another reason why we should stick with RoMScript.

Anyway, the end result is I came to the same conclusion. It's not worth changing. Although it might be worth keeping in mind for certain situations in the future.

[Boris-The-Blade]

Funny I just ran into this after talking with you on the teleport thread. This is right up my alley lately, but I'm not sure it would help exactly. I'm working on a FA waypoint, and one of the thing's a lower player running that waypoint would want is to switch targets when say, hollow shell starts spamming zombies. These stack up fast and stun you over and over, which can be a wipe if the bot doesn't know to autotarget the ghouls when they are spawned. This look's close to what I was hoping to find, in that it count's the mobs around you. I wonder if it could be used in such a way as to know when, say a boss, spawn's mobs, and can switch to that mob and kill it before returning attack onto he boss?
Their might be a simple way to do this in some other manner, but I know a lot of bosses spawn adds, and dealing with them with my rudimentary script skills has been a big thorn in my side.

[rock5]

I don't kill bosses but seems to me if you want to switch targets in the middle of a battle you would have to do a check in onSkillCast. If there are x number of mobs then switch target. Or do a search for the spawns and if they exist then switch target.

In the end I'd say it's easier to write custom code for a particular boss than try to make a generic code that can deal with adds from any boss.