mIRC Home    About    Download    Register    News    Help

Print Thread
#243055 11/10/13 02:47 AM
Joined: Jan 2013
Posts: 10
F
Fabius Offline OP
Pikka bird
OP Offline
Pikka bird
F
Joined: Jan 2013
Posts: 10
I'm requesting if it's possible to add
Code:
$get(N/nick,[N]).pack

property to retrieve the pack number of a DCC transfer that has been opened/completed/failed.

Thanks in advance!

Joined: Nov 2009
Posts: 295
P
Fjord artisan
Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
I'm not positive but I believe the pack number doesn't exist after the dcc transfer starts. So this might not be possible.


http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Jan 2013
Posts: 10
F
Fabius Offline OP
Pikka bird
OP Offline
Pikka bird
F
Joined: Jan 2013
Posts: 10
Originally Posted By: pball
I'm not positive but I believe the pack number doesn't exist after the dcc transfer starts. So this might not be possible.

well yes, after the DCC transfer has started only filename and sender nickname are involved, but i think that when the user sends the command /msg nickname xdcc send #N it could be easily stored by mIRC as a variable associated to that transfer, and that can be retrieved.

Joined: Jan 2004
Posts: 1,358
L
Hoopy frood
Offline
Hoopy frood
L
Joined: Jan 2004
Posts: 1,358
Why should mIRC handle the arbitrary implementation of some random script? DCC transfers have no inherent link to any pack number. If you want to decide on the rules for linking the two, you should write a script to do so.

Joined: Jan 2013
Posts: 10
F
Fabius Offline OP
Pikka bird
OP Offline
Pikka bird
F
Joined: Jan 2013
Posts: 10
Originally Posted By: Loki12583
Why should mIRC handle the arbitrary implementation of some random script? DCC transfers have no inherent link to any pack number. If you want to decide on the rules for linking the two, you should write a script to do so.

DCC transfers are directly linked only with sender nickname and ip/port, and file name and size.
however you can retrieve the seconds elapsed since transfer started with $get(1).secs - even though this is not an essential information, and even though this also can be easily scripted with a /timer command

Last edited by Fabius; 17/10/13 09:58 AM.
Joined: Nov 2009
Posts: 295
P
Fjord artisan
Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
actually time elapsed for a download is a standard piece of info for downloads. Pack number as said before is only a way to request a certain file from someone.

For mirc to record a pack number it would have to parse all messages you send to people and then assume when it sees an xdcc request that the next file received is that pack number. With something like this were not a lot people are asking for it, you should just script it.


http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Jan 2004
Posts: 1,358
L
Hoopy frood
Offline
Hoopy frood
L
Joined: Jan 2004
Posts: 1,358
XDCC as such is a custom function written and supported by a client script. There's no rule or expectation how different implementations may behave. mIRC doesn't even have built-in support for services such as nickserv and chanserv which are used by almost every network.

Aside from that side of the argument, it also can't support it in full confidence. As pball explained, mIRC would need to parse every message you send and then hope that the next transfer was for that pack. That's not necessarily going to be the case. Can't packs be queued and split into multiple transfers? Now not only does mIRC have to parse your messages, it needs to maintain a list of them and then match up the file names you receive to the packs you requested. I don't think that's possible for even you to do without also parsing and storing the file list you were given.

Joined: Jan 2013
Posts: 10
F
Fabius Offline OP
Pikka bird
OP Offline
Pikka bird
F
Joined: Jan 2013
Posts: 10
Originally Posted By: Loki12583
XDCC as such is a custom function written and supported by a client script. There's no rule or expectation how different implementations may behave. mIRC doesn't even have built-in support for services such as nickserv and chanserv which are used by almost every network.

Aside from that side of the argument, it also can't support it in full confidence. As pball explained, mIRC would need to parse every message you send and then hope that the next transfer was for that pack. That's not necessarily going to be the case. Can't packs be queued and split into multiple transfers? Now not only does mIRC have to parse your messages, it needs to maintain a list of them and then match up the file names you receive to the packs you requested. I don't think that's possible for even you to do without also parsing and storing the file list you were given.

well, assuming the next package downloaded has the corresponding pack number of the last "/msg nickname xdcc send #N" is obviously not a reliable way to do this, since, as said, packages can be queued. but, if this info is simply combined with nickname of the sender, it becomes sure that the next package received from that user will have that pack number.
btw since this feature request is receiving so many objections it's probably better to abandon the idea and just write it as a remote script.
thanks anyway smile


Link Copied to Clipboard