i don't quite get any reply to my post lately, so i hope i'll get some reply for this one
i'm trying to make a mp3 tcl.. but i'm not sure how to do this part.. i'm trying to get the sending speed of each dcc (cps).. well in mirc it's very easy to do.. but i'm not sure how this can be done in eggdrop..
i tried using the bytes sent divided by (current time - time start of dcc).. and got it right most of the time.. but for the ones with dcc resume.. it's not giving out the right reading..
i hope someone can lighten up my problem here.. thanks
I havent looked too closely at it, but doesnt dcc list give you the value of how many bytes have been sent?
If so, when the dcc send starts, why not start a timer for a minutes time which passes the last measured "sent bytes" "clock seconds"and idx to a proc. The proc determines how many bytes have been sent between the submitted time and current time according to the submiited bytes and the idx it has been given.
You could have this timer rerunning itself a few times, once every minute even, and performing some actioan based on the speed.
This is not too hard because the dcc list outpuit is already in an easily manipulated form. However it will take a little bit of thought to make it work. The bottom line is you have the time value, and you can find the byts sent, therefore you can calcuklate bps, however convoluted the process might be. Such a scriptlet would prolly be quite popular..
the problem that i have right now is the ones where i have dcc resume... how can i check using the time it starts, since the byte sent did not start from 0? the value would be inaccurate i think..
Whenever you start the send, do a check on the idx, a check on the current bytes sent, and a check on the time. If it's a new send, bytes-sent will be 0. If it's a resume, it will be a value. It doesn't really matter what this number is, because all you want to do after you started the send and checked those values, is to set a timer, however many minutes in the future, which runs a proc with 3 values:
current bytes sent
current time
current idx
When this timer executes, it calls the proc with those three variables.
Your proc grabs the idx, checks the current "sent-bytes" (regardless of what this is, your expecting it to be larger than your previous value), then compares the current time, with the time which came in the timer, it's then not so hard to do a quick calculation on how many bytes have been sent within the last x number of seconds (seconds being derived from current time minus the time variable which was passed to it). Thus you can always get the current send bps on an idx. I'd write the proc myself, but I dont really have the time.
The only thing you might hafta make sure of before you do the idx check is that the idx still exists.
