My problem is i need TCl script there can search from Qstat and give me info back someting like this !find wolfplayer and the BOT say where the player is
1. !find wolfplayer
2. The BOT say -> Looking for 'wolfplayer', patience. 3.And finaly the BOT say
WolfPlayer score: 5 is on T2Server1 Depot Only (128.176.224.13:27910)
DK WolfPlayer score: 20 is on gamesdomain.co.uk - Objective Event (213.221.165.14:28960)
[HP]WolfPlayer score: 23 is on Happy_Penguin (216.234.192.28:27960) 3 players found.
I'm afraid the only way to do this with Qstat is to run a seperate batch file that does the qstats into another file and then grep them for the results. Its tricky, but it does work, we've done it. You've been watching the BY bots havent you? They can do it because they have access to the server logs btw...
However I am writing a bot that can do this (for wolf) right at the minute on remote servers (qstat built in). Not sure when it will be finished tho.
[edit] start with the qstat4eggdrop script that can be found around about. but I warn you - it has been removed from a number of places because the exec it calls can be exploited. Also, if the program you call with exec does not return (lags out in any way) then your bot will also lag out of IRC.
Thinking about it .. using the qstat4eggdrop script it is possible to modify it so that it searches each line for the string specified ... you'd have to call it multiple times (once for each server you want to query) tho...
The reason I went the route I did is that I want to do rcon stuff as well...
This is not available with the standard script tho. So you'd have to build a list of servers (maybe with an !addserver command ...) and then run through that list.
So I would research string matching and list building in tcl. (no, I'm not going to do it - I make modules)
You can use the open command, and use file based events to prevent this sort of blocking.
Exec the script, and setup a event handler, passing all needed information, that is required to get the data to it's destination once complete (IE, nick, channel, information type).
With this, you can fancily use token based variables (like those that are generated by the http package), and store all the incoming data, until the applications goes EOF, and you issue a close.
This is the most sane method of doing it. The downside, it's aucward to impliment. However, it's far easier to maintain once complete. It will allow more queries that a standard exec method, and it can't block.