gogogo Marsup! you can fix it ;D Tho I prefer a deny-script on dest ftp... that doesnt allow more than one nfo in dir. But even the two options got its disadvantages... what if the wrong nfo was uploaded first? then the real one will be denied :OMarsup wrote:Skiplist is only based on file being transferred, it can't compare it with existing files, that ain't the right solution.
This option already exists for sfv files but if we don't want to end up with a full screen of specific options, it would be far more flexible to have advanced kind of skips that could take code (.net, js, vb, whatever). That leads me to dream about plugins... :p
A Few suggestions.
-
- Posts: 31
- Joined: Fri Feb 05, 2010 1:15 am
- Location: Medina, Washington, USA
- Contact:
Re: A Few suggestions.
-
- Posts: 14
- Joined: Mon Jun 13, 2005 6:51 am
Re: A Few suggestions.
I would like also to mention that a too heavy regex general skiplist makes ftprush really really slow
between each ftp commands / refreshes during transfers (like 1-2sec lag). I've tried that once and i had
to delete all that work within 10mins.
between each ftp commands / refreshes during transfers (like 1-2sec lag). I've tried that once and i had
to delete all that work within 10mins.
-
- Posts: 1
- Joined: Tue May 11, 2010 9:18 pm
Re: A Few suggestions.
Eff3c7 wrote: 1) the ability to "lock" a container, once locked the current sites for this container will stay with the container and not be used to transfer, this will allow admins to perform matience on a site without loosing there place if automation starts.
2) A feedback thou the win32::api sendmessage when a transfer has finished. and some infomation about what was sent etc.
Eff3c7
Those two requests are very important in my opinion
You must make FTPRush more "scriptable"
Peace
Edit: Few others suggestions...
1. All commands with mirc dll returns $true or $false ( 1 or 0 ) if they success or not.
2. It should be good to have mirc feedback possible for all commands too, not just RAW execution.