I'm requesting if it's possible to add

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

Thanks in advance!

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.

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

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.

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