WinMX World :: Forum
Third Party Stuff => Chat Servers => Topic started by: Bearded Blunder on May 20, 2007, 09:30:28 am
-
Anyone having problems running Shareguard on the current WCS beta, & finding it doesn't run on entering the room the following workaround seems effective:
Enter bot into room
/setaccess or /forcelogin to something with b access (to put it in bot mode)
hide it
unhide it
It will then issue it's on enter commands (make sure those commands don't take it back out of bot mode) & start sccanning ...
I strongly suspect this of actually being a shareguarg bug, rather than a WCS one (it's buggy as hell)
-
probably the exact same bug as robomx, which I had to add a workaround for whenever it sees the robomx client identification, i guess i'll probably need to do the same for the shareguard client name...
i guess bender probably thinks it's correct to use completely the wrong thing for determining when a client has joined a room... (a server doesn't have to send an entry notification for the user if it doesn't want to, it's just that most winmx servers do... until b12 with fancy entry anyway...)
but then again he does use the 3.53 protocol for a program that only needs the 3.31 protocol, and breaks in most servers when using the 3.53 protocol (requiring bot mode to be enabled)... heh
-
Yup same prob here, wont auto login and doesnt scan :wink:
-
Note: Since updating to WCS 1.8 rc1 not only does the above workaround no longer work, but it also appears impossible to get shareguard to both enter & STAY in the room without resorting to cumbersome measures...
i just get the following, over & over when i try to get it into the room
30/05/2007 09:55:23 [C3] Robbie555_16328 Joined (127.0.0.1)
30/05/2007 09:55:24 [C36] <Røbbie555_00000> Hi Robbie
30/05/2007 09:55:25 [C3] Robbie555_16328: Software caused connection abort (10053/436)
30/05/2007 09:55:25 [C3] Robbie555_16328 Disconnected (127.0.0.1)
currently.. setting FancyEntry=0 save /reload enter bot then restore fancy entry appears to be the only workaround
-
erm...
it should apply the workaround + drop it in to the 3.31 protocol automatically
did you disable the workaround in your other bot in case it's the fact it is doing it twice that is causing the problem?
-
i didn't have the bot set to apply it, was doing so manually, this afternoon it's decided to enter, doing nothing different, so damn if i know what the matter is/was..
-
My shareguard works just fine with the Fancy Entry.
-
I actually found another bug in robomx/shareguard that can be used for a cleaner workaround for it (instead of depending on detecting the client name)... a bug exploited to work around a major design flaw... hmm... lol
however that's more of just a clean up (basically just looks nicer in the client doing it that way) then anything, but still looking for any bugs for rc2...
-
well i don't see it as a bug as such.. but {/¥\Ð} -+-Gûrµ-+- {/¥\Ð} was complaining /stats <name> only displays Text Format: under certain conditions, rather than always, aparrently being able to deduce it's default or one of the numbered ones from Access: or having it displayed if it's been changed isn't good enough.. he'd like it shown always, i can kinda see his point, making bots deduce it (why he wants it) involves reams of extra code
-
it only shows the text format if that user has a specific text format set, if they don't have a specific format set then there is nothing to display
-
What if they use text format...7? That's a specific format, all the number formats are. So I think it should show them as well. Or maybe make the server set a user's format on enter to the default format, and if their format number ever changes. But have it not show a format changed message or anything. That way the stats will always know what format the person is using. It would prove useful if the bot knew what format every user had, instead of just special users. If not, then there's really no point in adding the text format stat in there if it only shows for people that have their own login, or had their format changed with /setformat
-
i think KM is saying the information is always all there, just needs interpreting..
if format is given, that's the format
if none, format is the number in access
if none, format is default
yes it's much harder to make metis work this out, & no hope with the other common bots,(easy enough for a human)..
then it wouldn't take someone *that* much better with metis than me to do it..
i might even be able to, but i don't see enough value in the excercise to bother
-
If you want a bug though.. the topic on winmx chatrooms is short enough.. stealing six characters to put [WCS]<space> at the front sure bugs HELL out of me (I need 2 of them to make my topic FIT)
-
removing the [WCS] was added to my mental to-do list several times for 1.8, however i kept forgetting to add it to the written to-do list that i actually do... lol
but it's not a bug as it's meant to add it :-P
-
Well, I kinda need Metis to be able to do a /stats on any user that does the /setcolor <number> command. It has to then read the format that the current user has and change the color code before the $TEXT$ variable or the last %s variable. And most users would be the default access, so Metis would always have to be pre-programmed and updated when the default format is changed. Harder to share stuff that way. It would be much easier if it could just read all text formats, there could be a few uses for it. And I plan to use them for the scripts I've got in the works.
-
Right having a few problems wid robomx at first on the new rc2.
When robo joins the room metis checks %SERVER% and get is response and then picks which command it should do to activate bot mode,
But now it Reads WinMX in %SERVER% instead of WCS so it just doesnt do any BOT activation at all,
Duno if anyone else has this problem
<out type="echo" condition="_?" lvalue="%SERVER%" rvalue="WCS">This server (%SERVER%) supports colored text. Metis does not work properly with colored text. Attempting to disable color support now.\n</out>
<out type="normal" condition="_?" lvalue="%SERVER%" rvalue="WCS">/bot</out>
Thats the bit im on about, its at the begging of the mxc.xml
If this is just another thing you have to sort out due to bender sorry mate lol, i bet you are hating it now ;-)
-
Erm...wow, you're right. Metis must be so stupid that it probably reads the topic for the [WCS] tag before deciding it's a WCS server and checking for the actual version. Sounds like Bender's doing alright, that's kinda stupid though. Glad I don't really use the %SERVER% variable in Metis. But I honestly believe this small fix should be done to Metis it's self and not WCS this time, as for it's not a WCS bug. Just a poorly coded Metis bug.
-
Oh yeah, side note...I think it would be nice if the server version was included in the stats of the room. Then we'd have at least one quick way of having it know what version the server really is. Even though it sorta needs the access to do it...but who doesn't give their chat bot that kind of access? :P
-
actually the reason it can't find the WCS version is because the workaround actually puts the join/part for the workaround before the sending of the server version... i'll fix that for rc3 ;-)