On Join Auto Voice

ppslim · Post by **ppslim** » Thu Jan 09, 2003 5:16 pm

They are not faulse details, more incomplete.

Most people forget that one function of a program, can effect another. In this case, messages in the queue before pushmode is called (the mode queue doesn't just help mode changes), can direct effect how and when the pushmode change will take place.

I hate being right, as much as I love it. However, it's my and my mighty ways, that requires me to ram home messages

.

strikelight · Post by **strikelight** » Thu Jan 09, 2003 10:42 pm

ppslim wrote:They are not faulse details, more incomplete.

Most people forget that one function of a program, can effect another. In this case, messages in the queue before pushmode is called (the mode queue doesn't just help mode changes), can direct effect how and when the pushmode change will take place.

I hate being right, as much as I love it. However, it's my and my mighty ways, that requires me to ram home messages .

Well, in this case, you are wrong about the documentation

As Papillion posted:

pushmode <channel> <mode> [arg]
sends out a channel mode change (ex: pushmode #lame +o goober) through
the bot's queueing system; all the mode changes will be sent out at
once (combined into one line as much as possible) after the script
finishes, or when 'flushmode' is called

Note the sentence: "all the mode changes will be sent out at once after the script finishes...". This is false, as proved by yourself, and by the example I gave in my last post.

ppslim · Post by **ppslim** » Fri Jan 10, 2003 6:42 am

Nope, you are forgetting to acknowledge the sentance before the one you quote.

As noted, they are queued. As we know, eggdrop queue support flood protection. This is where is the reason behind modes not being sent. It should probably read "sent as soon as possible" though.

If there is a real need to bypass the flood protection of the queue system, you can use the non-documented putdccraw command. It is very simalar to putdcc, but has 1 extra requirment, and 1 extra function.

putdcc uses the format

putdcc <idx> <string>

While putdccraw uses

putdccraw <idx> <string> <length>

You are required to pass the length of the data you wish to send. In most cases, a Tcl "string length" will be enough.

The extra function, is that you can use a IDX of 0, to send to the currently connected IRC server.

strikelight · Post by **strikelight** » Fri Jan 10, 2003 7:58 pm

ppslim wrote:Nope, you are forgetting to acknowledge the sentance before the one you quote.

As noted, they are queued. As we know, eggdrop queue support flood protection. This is where is the reason behind modes not being sent. It should probably read "sent as soon as possible" though.

Well of course they are queues, but the sentence implies that the queue will be flushed/dumped to server upon exiting of script code. Thus, the doc is in error.

Quad Erad Demonstrantum.

SmokeyOne · Post by **SmokeyOne** » Tue Jan 14, 2003 6:13 am

putdcc comands can be tricky, from experience every knows that it can be annoying

ppslim · Post by **ppslim** » Tue Jan 14, 2003 6:19 am

putdcc is not at issue here.

The partyline and an IRC server are 2 different things.

putdcc doesn't queue any of it's output.