Funnily enough I went back to my bot (where the script has been working for months), typed !bash, and nothing happened.
I've looked at the script again and I'm wondering if there are problems with the floodprotection.
I've just finished 1.4.4 which tackles this issue as well as fixing another couple of bugs. I'd love to post a link to it here but my webspace has just gone down. I'll post links when it comes back up again as well as links to a few previous versions.
In the meantime, you might like to try this:
delete the line:
set bash_last_quote_time -1
and replace it with the following two lines:
set startup_time [clock clicks -milliseconds]
set bash_last_quote_time [expr $startup_time - 60000]
Let me know when you have it so i can remove it from my website thanks
Just an FYI, I've looked at the script, and it doesn't use egghttp, It uses the http package that comes with TCL.
egghttp.tcl isn't a drop-in replacement for the http package, however it does provide compatibility between eggdrop versions allowing all egg versions to execute http queries in a non-blocking mode (which btw, from looking over the bash.org tcl code, this script operates in blocking mode in some instances <oversight by author perhaps>, even though the http package provides a method for operating in non-blocking mode), and also provides simpler ease of use.
That's interesting info about egghttp which I didn't know.
The use of both blocking and non-blocking modes in the script is deliberate. The non-blocking fetch is done to parse 50 random queries from the site as the regexp processing of these is very slow (up to 20 seconds) and I didn't want to go locking the bot up for this length of time. When a random quote is requested it is fetched from this 50-result cache rather than from the bash.org webserver, so there is no performance hit. When the cache expires it launches another non-blocking fetch to get another 50.
The blocking mode fetches are used to get instantaneous queries, namely quote by text string and quote by number. Experimentation indicated that the time taken for a non-blocking query in this case was unacceptably long.
Incidentally I'm still none the wiser as to whether 1.4.4 works on other people's bots or not.
DJGrenola wrote:
The blocking mode fetches are used to get instantaneous queries, namely quote by text string and quote by number. Experimentation indicated that the time taken for a non-blocking query in this case was unacceptably long.
How did you perform these tests? Non-blocking should be no slower than blocking. Not to mention, if the server is lagged/down/unresponsive to queries, the bot will end up locking, until a 'timer drift' saves it.
I've done more experiments and non-blocking fetches still seem to take several times longer than blocking ones. The new version of the script, 1.4.5, has config options to let you set blocking / non-blocking modes for the three different query types, so everyone can have it their own preferred way.
Also, I totally bungled 1.4.3 (oops). The clock ticks -milliseconds thing means that it won't display anything at all unless you patch it as described earlier. 1.4.5 incorporates this fix.
Awesome! Except for one thing, is there a way to make a bot say the long mesage as a notice, not as a private?
PS: found a strange bug:
[15:57:54] [@3zzy]: !bash
[15:57:56] [@barabashka]: |bash| <WaterBomb> Actually, I?m only 23% gay
[15:57:57] [@barabashka]: |bash| <Justin8649> So your head and penis are gay.
[15:57:58] [@barabashka]: |bash| <WaterBomb> Whoa, that means my penis is 10% of my body
[15:57:59] [@barabashka]: |bash| <Justin8649> ...
[15:58:01] [@barabashka]: |bash| <WaterBomb> Since the head makes up approximately 13% of the body?s mass.
[15:58:02] [@barabashka]: |bash| <WaterBomb> so by your logic, my penis is 1.3 feet long and 6 inches in diameter
[15:58:04] [@barabashka]: |bash| <WaterBomb> if you want to figure it another way, my penis would be 4 feet long and 1 inch in diameter
[15:58:06] [@barabashka]: |bash 22829| <CaptainCasual> thats just goatse enough to work
[15:58:08] [@barabashka]: |bash 22829| <NickBlasta> Fruedian slip?
Even though it is set set bash_max_public_line_length 3 in the config
Weird, no.. The first time I have used !bash command after i installed the new version of the script, the bot read an 8 line long quote into the channel even though the limit in the config was 3 lines. However, the next times I've used the script everything was qust fine!
PS: Just a suggestion, is it possible to add an option in the next version of the script to make a bot automatically read a random quote into a channel in predefined periods of time?