avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • January 23, 2018, 01:32 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - worstje [ switch to compact view ]

Pages: [1] 2 3 4 5 6 ... 23next
N.A.N.Y. 2017 / Re: NANY 2017: BackseatSiege (QuorraBot plugin)
« on: December 23, 2017, 09:02 AM »
It's been a while. I updated this plugin a while ago but I think I forgot to upload it here despite intending to do so. Whoops.

Oh well, yet another DLC came out, so yet more updates from me. Do with it as you will. :-)

Regardless of the amount of 'accessibility features' that recent versions of operating systems contain, I often feel that it's only gotten harder to make an old-fashioned, accessible app. Inbetween all the Aero stuff, the ways windows are made 'non-standard' and the way webpages are a graphical free-for-all, it seems as if consistency and user-preference have been put into banishment.

And Microsoft is not helping. Older customizability settings get plain ignored or overridden by new things. New toolkits are more focused on the looks than on accessibility, too. At this point, I can't exactly call WPF new anymore, but I've complained often enough about the ways it reinvents the wheel for existing controls. (My number one pet-peeve that tends to break with these sorts of shenanigans is that the mousewheel almost never works consistently anymore in modern Windows in regards to how much it scrolls...)

Making programs accessible is (imho) harder than ever nowadays. Everything is custom and skinned and the noticeable limiting of visual tweaking on the OS level is pretty much screwing people with minor visual handicaps over. And it makes me sad. /rant

I should probably have checked those places. Since I ended up using some Steam wallet leftovers I never even considered it though, but that's definitely something people ought to consider!

Weird that American Nightmare seems to be getting different treatment on Steam than it is on GOG. Oh well, it doesn't really matter in the end. Enterprising souls will find a purchase option that suits them. :)

The Announcement:

If you have not yet played Time Magazine’s 2010 Game of the Year, now is your final chance. Remedy’s Alan Wake is going offline from stores. This is due to the expiration of music license agreements for the game. Alan Wake’s American Nightmare is not affected.

For 48 hours, you can buy Alan Wake including DLCs and Alan Wake’s American Nightmare at a 90% discount on Steam.

If you already own Alan Wake – like the majority of the gaming population out there – you have nothing to worry about. The game will stay in your library and continue to work for you.

The Store Page

Worth noting is that the similarly-discounted Alan Wake Franchise Package also includes Alan Wake's American Nightmare, which is not discounted at all were you to buy it separately. This is probably an oversight, but I mention it just in case you only intended to buy one or the other.. :)

Mouser's Zone / Re: Bug report: automatic screenshotter stops
« on: May 03, 2017, 02:37 PM »
Yeah, I think 10k is the limit in recent versions of Windows per application. Back in the 9x days, I think the limit was 1024 or something, so go figure. Since they are per-session identifiers and very archaic beasts that date back to the Windows 3.1 era, there's only 16 bits (~=65535) of them total for your entire login session. So six programs that all try to max out the GDI handles will without a doubt give you this crazy madness. (Look into the testlimit tool from Sysinternals, it can do exactly this. :D)

Honestly, it is already highly extravagant to have 500 GDI handles in a single process imho, because you can (roughly) equate it with using 500 pencils at the same time. To stick with the comparison: it makes sense not to always put the pencil you are using back into the pack because you know you'll need it again in a moment... but in this case, the program keeps taking pencils out of the pack and dropping them on the desk for re-use.. which never happens. And then suddenly, there's more pencils than desk, and no more work can get done... which is why pretty much anything involving traditional graphics tends to die the moment you run out of GDI handles: windows don't get drawn, menus fail to draw properly, random stuff has black or white squares or whatever..

TL;DR: GDI handle excesses are probably my favorite kind of 'traditional' bug because as much of a pain as it can be to find the source of the leakage, the utter chaos is such a nice change of pace.

Mouser's Zone / Re: Bug report: automatic screenshotter stops
« on: May 03, 2017, 02:07 AM »
Another thing I would recommend is to open up Process Explorer and check the properties for the process. In particular, the statistics about the handles (on the performance tab) are where I think you might find a problem; if you run out of handles due to a bug not freeing them up after use you can get some really weird behaviour.

My guess is that the app might be leaking a GDI handle each time it screenshots, but that's just a guess.

You don't even need to wait for an error to occur to test this theory; just look at the numbers when you start it up, leave the app running for a few hours, and then check the numbers again. If any handle has grown considerably (don't forget to account for some minor variance), then that is likely to give mouser a hint as to where he's looking for the problem.

Eh, this one was pretty simple. Didn't have to fuss much with it, but that's because I did some other batch files in the past month which were absolute nightmares. (I really need to learn PS at some point, but it's so much easier to just work with something I 'get' rather than get lost in an ecosystem and syntax where I'm not even sure how to do something trivial, nevermind combine the complicated stuff I want done!)

Compared to programs borking over unicode characters, delayed variable expansion in batch files and more of such silliness, this was pretty easy. Most of my mind went into the 'ok, I've got A inside A, how do I fix this in a generic way that is fool-proof and does not involve copying files, especially not across drive boundaries' dilemma...

ZIP files come in two varieties, oddly mirroring the users which create them...

The first variety has the files directly in the root of the zip files. These are created by users who select multiple files and create an archive out of them.

The second variety has the files stuck inside a directory that is in the root of the archive. This was accomplished by selecting a single directory and then creating an archive out of that.

(OK, there's far more varieties, but they are just worse and arguably insane variations of the second variety...)

When you extract the first kind, you'll want to extract it to a subdirectory, usually using an option like 'Extract to MyZipFile\'. Otherwise, you get the crap stuck in the middle of all your other files, which is really annoying!

When you extract the second kind, you want to extract it to the same directory, because otherwise you've got a wonderful beginning with matroshka dolls: a single directory inside a directory. It's just annoying.

And unless you peek inside a zip (as opposed to rightclicking and just extracting like I tend to do) there's no other option but to guess... and since the least damaging option is to extract into a new directory, you will thus end up with the worst-case scenario of the second variety.

So what is this little script about?!

Basically, I had to extract about a thousand zip files... and they were a mix of both varieties. Fixing the nested directories manually... yeah. I wasn't going to put myself through that pain. So instead I wrote a pair of batch files.

It's just a simple script, but since I happened to need to do a lot of it, I figured I'd automate it and then share it with all of you.

Squash-All: Squashes all subdirectories of the current directory.
Squash-Directory: Squashes a given directory.

There's no real special features save for the fact it avoids conflicts where you have a folder 'test' inside a folder 'test' which could cause issues whilst moving the files up a level. Other than that, it's just a batch file.

Have fun? :-)

N.A.N.Y. 2017 / Re: NANY 2017 post your mug photos here
« on: January 25, 2017, 11:07 AM »
Perfect for brewing some trouble with. :Thmbsup:


N.A.N.Y. 2017 / NANY 2017: BackseatSiege (QuorraBot plugin)
« on: January 01, 2017, 11:40 AM »
I contacted mouser on Dec 31st about releasing a plugin I created for my own use to the greater community... because hey, I haven't participated in NANY in a while for lots of reasons, and I felt bad. As such, I figured I'd release a script I made for my own use in the hope even one person will somehow find a use for it.

Backseat Siege was created by me in order to involve my (admittedly very limited) viewers and give them a say in what operators i play as whilst playing Rainbow Six: Siege. For those not familiar with the game: it is a squad-vs-squad (anti-)terrorist FPS where every operator has a special ability and distinct playstyle. There are two sides: attackers and defenders, or ATK & DEF as I tend to refer to the two factions.

My requirements for this plugin were as follows:

1. No votes should be ignored; eventually every operators wll get played.

2. Streaming means there is a stream delay. This means people should be able to get their votes in at any time as opposed to a very specific time window.

3. Streaming is stressful. Allow.moderators to help out in case I forget something.

4. Viewers like emotes and love expressing themselves. So make sure their commands have flexibility to them.

5. Due to the design of the game, only half the operators is available every round. This means I can essentially have two voting pools: one for attackers (ATK) and one for defenders (DEF).

6. I don't like my stream to be cluttered; simplicity is important. As such, I want the current top-voted operators to be on screen. In case of a tie, I want them to cycle through the tied ones.

7. As a streamer, I want a simple dashboard with the complete rankings including vote counts to give a bit of auditory commentary. (Example: the number two in votes is only 5 votes away! Keep voting!).... not that it ends up mattering with my small viewercounts...

So what features does this mean I have beyond the obvious stuff already written out?

1. Broadcast software agnostic. OBS, xsplit, whatever... it should work.

2. Decently commented source code; disabling an operator because you dont have it (damn unlocks) or adding new ones is pretty simple. All configuration is clumped up near the top of the file.

3. Sometimes you just want to mess with your viewers, so there is also a facility to fudge around with the democratic process, bahaha. :) (People can see it in chat of course, so don't think that you can hide it...)

4. Should be easy to translate since pretty much all output strings are clumped together.

I am kind of lazy and not including screenshots right now (because eh, it is a bot and those installation instructions took forever) and if you want to see it in action, you can always check it out when I am streaming the game in question.

Perhaps tomorrow (Jan 3rd?) I'll find it in me to properly spruce up this post some more; I'm just glad to have the release out at this point.

DC Gamer Club / Re: Keep Talking and Nobody Explodes!
« on: October 30, 2015, 09:47 AM »
I wouldn't be surprised if that scene inspired the game, or vice versa. (I don't watch Archer.)

Multiple things from that clip give me a very strong deja vu feeling...

DC Gamer Club / Re: Keep Talking and Nobody Explodes!
« on: October 30, 2015, 09:30 AM »
Slave driver. :) Check out this playlist.

DC Gamer Club / Re: Keep Talking and Nobody Explodes!
« on: October 30, 2015, 09:25 AM »
I've uploaded plenty of those videos myself, seeing how I ended up streaming this game on twitch. :)

DC Gamer Club / Keep Talking and Nobody Explodes!
« on: October 30, 2015, 09:19 AM »
Disclaimer: mouser is currently bugging me in chat to post something here and bring this game to everyone attention, and since I am the ever-benevolent me, I decided to go along with it. (That, and it is a very damn good game!) :-*

Link to game website
Link to Steam Store page

To be precise, mouser was linking me to a certain review, but personally I'd like to talk all of you into not looking at it. Instead, I'm going to describe the game in as basic a way as possible; to do anything more would simply ruin the curve where you first meet the game, then explore its intricacies and finally smash your face into the wall trying to find the right way to tackle that particular bomb.... ah fine, I digress.

This game can generally be put into the 'party game' genre: you are supposed to play it with multiple people. These people can be in the same room, although I've personally played it with other people through skype, teamspeak and/or mumble.

At that, it is an asymmetric game that only requires one person to actually own the game; this person is the one who will be interacting with the bomb, the so-called defuser. There's bonus fun to be had if there's an Oculus involved, but it plays completely fine with the mouse or gamepad. They describe the bomb, decide which modules (which are basically mini-games that have no relation to eachother) need to be tackled, and then spend all their time followin the instructions of the experts in order to not die. Easy peasy!

All other players are the so-called experts, and all they have to go on is a bomb manual as well as a pen and some paper which they will need in order to write down notes. There can be one experts, there can be five; some bombs can actually be more difficult with more people, whereas others are simply too difficult with too few people. During the game, the defuser will describe things on the bombs, and the experts will use this information to as quickly as possible figure out the instructions that the defuser needs to follow in order to disarm the bomb. This is not as easy as it sounds: many of the instructions are confusing as hell, and the nature of some games preys on misunderstandings and other communication mishaps!

This game has a very good tutorial. Actually, it does not amount to much in a practical sense, but the levels themselves gradually increase the difficulty, both by introducing you to new modules step-by-step, but also by removing the room for error as well as lowering the time limit. You essentially teach yourself how to play the game! And because the game could end up too easy (hah), the game also throws some curve balls for the defuser to work with as the difficulty increases. Think of environmental distractions as well as special bomb modules that exist for no reason other than to increase the pressure on the defuser even more.

As a whole, everyone I know really enjoys playing this game. Sure, all the experts have is a manual and pen and paper, but the fact they do not know the bigger picture and are always low on time without being able to see the clock is what gets their adrenaline pumping something fierce. As for the defuser.. suffice to say that this game (ab)uses plenty of auditory cues in ways that even an suspenseful action movie would have trouble contending with.

I can wholeheartedly recommend it to anyone. There will definitely be some fighting and laughter as a result of people screwing up, but that is a part of the game... although the finish line and 10 seconds left on the clock can make a final trivial mistake really hard to swallow!

(P.S.: I obviously own the game. If people want to experience it as an expert, I'll gladly play with them!)

Well, it isn't meant to be that way. It just grew that way. With enough effort, anything ought to be possible. But that is imho something that requires a lot of time, effort and... money. (I think a commercial company would be the only one with enough staying powe to make it actually convenient to use and easy to understand...)

I understand what you mean, but my point is that it is not as reliable as you think it is.

For one, context menu handlers do tons of disgusting shit they should not do when adding menu items, so the order in which stuff appears has zero bearing on where you see it in the list.

Second, context menu handlers have a habit of fucking around the moment stuff gets actually displayed / drawn, which only gives them more ability to screw with the ordering and presence of menu items. (Probably ought to fall under point 1.)

Third, the order in which Windows executes the context handlers is unknown / unspecified, which will affect the stuff in the first few items only more. A bug in a single context menu handler can affect others, and errors can cascade with the most confusing shit to debug for a programmer. (You and your target audience may well be smarter than me, but I've found it a good practice to always idiot-proof stuff as much as possible. This stuff alone makes me anticipate a lot of bug reports that are nor ever were mine to fix.)

From the points made upto here, it follows that even a minimal, perfect implementation of your two shell extensions could actually affect the ordering/display of menu items. (For example, assume that a shell extension moves all of its items into a submenu whenever there's more than 20 items displayed. Shenanigans would happen if you bump it over that magical number!)

Fourth... temporarily dumping stuff in the registry, running a test and then unregistering it is prone to error. Your program might crash and your users might be stuck with the things. Maybe you remove it in an improper fashion. It might somehow interfere with other programs on their computer, or those programs might interfere with you. All of it comes down to you trying to solve a local problem with a global solution, and that shit is poison.

In the end, keep in mind that whatever you do, when you deal with context menus you are dealing with shell extensions, and it wouldn't be surprising if there's a dozen shoddily coded context menus that interfere with eachother that you do not have the source code for to inspect. You do not really have the code Windows uses to build  the context menus either. All you have is an understanding of the API, but you do not have an understanding of the way either side violates the API! (Programmers are idiots, and Windows breaks stuff in a gentle way to try and guard against it. It's madness!)

When you know so damn little, how useful are your print debugging statements really? While I haven't taken your exact path of print debugging, but I did do a lot of print debugging whilst doing Cautomaton, and the results made sense as often as they defied it. :(

I feel the need to say this (again): I do not want to discourage you nor shit on your request. But I know first-hand that context menus are a nightmare that fall apart based on implicit assumptions. This stuff amounts to 20 years worth of hackery and abuse, and for all the simplicity it ought to be, it has turned into a terrific frankenstein of gotchas. Nothing is as it seems to be, and you do not know what you think you know.


Have fun?  8)

This topic just now caught my eye by sheer chance. As someone who has gone into very nasty territory with regards to properly recreating context menus in as authentic a manner as possible (look up Cautomaton if you're interested), I can tell you one thing: rocket science is more predictable.

Back before the Windows XP days, there was no API to properly summon a context menu. During some version of Windows XP, there was an internal API that got published as a part of a lawsuit deal in the EU, although it was hardly the most suitable thing. Around Vista, a 'better' API came out, and iirc Windows 7 improved on even that with yet more miracles. Even the latest API is not easy to use, and the ones before that are pure hell.

What I can tell you based on my experiments is that the ordering is both directly and indirectly based on the OS. Why indirectly? Because of those APIs I mentioned. Some of the old ones expect the calling applications to pass the relevant registry keys to them in an array... and the ordering of said array alone can shuffle things considerably. Throw in that the Windows versions actually brought in new features and other messes, and there is no such thing as a simple 'order' for context menu items. Of course, all this still ignores the marvel of the schzophrenic 32/64 bittiness that others have already mentioned.

Probably the most unreliable part of it all are the shell extensions that get loaded. In theory, it ought to be relatively simple in how they are implemented. But programmers do silly things out of sheer incompetence (or to please their bosses). Combined with all the differences that already exist between the Windows versions, these shell extensions can behave wildly different depending on the Windows version, even if they aren't version sniffing.

(And this is the point where I read some more posts in the topic and realize what you were really asking for...)

I think that the stuff you are looking for is really hard to do. Ignoring the wildcard that is dynamic verbs that could screw everything up, some results are possible.

For static verbs, it is basically a matter of automating what you do manually already in the various places (extension / file 'class'). Don't forget to keep an eye on the mime type (or wtf the registry key is called); it also affects the menu items that pop up (although this stuff may actually end up being dynamic, now that I think of it). Since it is pretty much all static in nature, there's no need to simulate anything and the registry gives you your answers.

For dynamic items, it is possible to manually try and figure out what the shell extension modules are, and then manually run them and try to create some results. But false positives would run rampant: ideally you'd want to feed it an empty context menu so that all the things it adds are the ones you are interested in. But if it does sniffing ('put me right underneath send-to' logic for example), that stuff could really backfire and it might not sniff up any items whatsoever.

I know this shit has given me many headaches, and my successes are completely based on tenacity and the blood and tears of others who have tread the path before me. Either way: what you want is not something that is a simple matter of just tearing out existing code. It involves recreating the Windows internals regarding context menus with enough precision to stave off all sorts of awkward edge cases. Even if a lot of the context menu could be simulatedly recreated using a 'phantom' file that kind of matches the criteria you are looking for, it will break, and you won't have your neat separation of 'X is located in All Folders, Y in All Directories, etc'.

All that said: I do not want to discourage you. But the depths of context menus are where masochists venture in need of their fix. That's all. :)

N.A.N.Y. 2011 / Re: NANY 2011 Release: JottiQ v1.2.0
« on: March 24, 2015, 08:35 AM »
Sujay, today is your lucky day, although it isn't really...  :o

Version 1.2.0 is now out. Sadly though, this release adds nothing new; it only prevents breakage in the nearby future. Because upgrading really matters to keep JottiQ working, I decided to engage in some psychological warfare and bump up the minor version to v1.2.0 rather than going with a more sensible v1.1.2. :Thmbsup:

Jotti is in the process of revitalizing his service with new features, amongst which is the ability to deal with the load JottiQ threw at it during its release. (That last thing has been implemented for a while I believe; I haven't seen a server-side queue in ages!) Some of his upcoming changes however are not compatible with JottiQ (broken scan results link, anti-virus images moving and such), so an update is required for continued functioning. :)

I do hope to get back into JottiQ development again. I still have some plans for it. But for now, I am going to wait and see to what degree Jotti's upcoming changes affect things. Some of the features I'd love to implement require a little bit of help from him, and he understandably needs to focus on his current efforts first.

If there is anything else you want to know, check the first post in this topic or see the website. Or simply ask in this topic; I'll be glad to answer any questions there may be.

v1.2.0 (2015-03-24)

    Compatibility release. Jotti is undergoing some changes so we must too. :)
    Upgrading is highly recommended; previous versions of JottiQ may break or
    otherwise show reduced functionality as Jotti improves his service.

Edit: It seems the DCMembers server has some issues at present, so I can't actually update the website right now. But I hopefully will be able to do so soon!

You are technically correct on pretty much everything, Vurbal. :)

I just wanted to keep it simple and to the point for the sake of clarity. (That and I had to dash out for a meeting, so I didn't have the time to be very in-depth.)

Switches, parameters... They're basically different words for the same thing, although the context matters greatly.

Parameter usually refers to anything passed after the program / batch file itself.
Switches refer to things like -f, --preserve-root, /help, /? and so forth.

Suppose you have a batch file you call like: test.bat One Two Three Four Five Six

Then in that batchfile itself, you can refer to 'test.bat' with %0. If you want 'One', then you'd use %1, you'd use %2 for 'Two' and so forth.

General Software Discussion / Re: change mouse behaviour
« on: January 27, 2015, 04:27 PM »
While I don't want to be a negative influence and squash your morale, this is a pretty tall order you are asking for here.

Programs are designed to be interacted with by a user. Some parts are not intended to be changed, and the kind of tricks you describe are meant to change such things. But with that comes all the nitty-gritty stuff that takes some hackers who really like that sort of thing to figure out adequately. Code injection used to be rocket science before the great security realization dawned upon the worlds collective consciousness, making a bad thing, and nowadays it has been given more hurdles to make it even more difficult. (Look into AppInit hooks some time; there is a reason these are hated upon nowadays!) The tiniest of mistakes while hooking into another program can make it behave erratically or outright have it crash at random times; there's a lot of pain ahead of you if you really decide to sink your teeth into this subject. I dare say very few people could tell you how to do it, and especially not 'exactly': comparing this sort of exercise to brain surgery would not be too bad of a comparison to make.

A more suitable alternative would likely be to interact with the Windows accessibility APIs. These do not require hooking and can do a good amount of the things you may want it to, as they are intended to allow programs to control Windows more easily for the handicapped who may not be able to press multiple keys together, read actual text and more of those things. Of course, this may not be as successful with something like responding to rightclicks in the empty area of a webpage.

Finally, there's also the option of tackling your needs with different approaches. Develop a plugin for Firefox to do what you want done in that program. It is _far_ simpler to take that route and simply leverage all the existing plugin infrastructure than it would be to reverse-engineer Firefox' behaviour.

I have done code injection and hooking in the past, and it was some very simple stuff, but getting it stable was a nightmare. If you value your sanity, do not go there.

N.A.N.Y. 2011 / Re: NANY 2011 Release: Cautomaton
« on: January 21, 2015, 10:43 AM »
Yet more updating... but this one doesn't really matter (unless you are like me and are really attached to the old hat...) as it only involves licensing and legalese-esque little details.

Oh, and I added a little blurb in the ReadMe on how to get started using Cautomaton, so I suppose there's that, too.

v1.0.1 (2015-01-21)

    Absolutely nothing changed! Except all the stuff that matters...

      Changed: ReadMe.txt has had a huge makeover. There is now a tutorial
        as well as a clear statement regarding the license.
      Added: The version history now has its own file in Changelog.txt.
      Changed: the Cautomaton icon has been changed because the licensing for
        the old icon is unclear with regards to commercial use. (Hopefully, its
        author will respond to my inquiries at some point in time, because I
        already miss the awesome hat!)

N.A.N.Y. 2011 / Re: NANY 2011 Release: Cautomaton
« on: January 04, 2015, 01:31 AM »
If it had broken, I'd blame Windows XP. Buggy piece of #@$%#$%. Ahum...

Thanks for giving a whirl. Duly appreciated!

N.A.N.Y. 2011 / Re: NANY 2011 Release: Cautomaton
« on: January 03, 2015, 02:18 PM »
Well, you stole the surprise away now, mouser!

For those unaware.. he's talking about the long-anticipated (by an imaginary someone, I'm sure! :tellme:) release of Cautomaton v1.0.0! It introduces the support for invoking a context menu on multiple files that I've wanted to put in there since the moment I started implementing Cautomaton several years ago.

Thank you to mouser for testing v1.0.0, for organizing NANY for yet another year, and to everyone else I say... have a good 2015!

v1.0.0 (2015-01-03)

    Over four years have passed - most of which consisted out of my eternal
    procrastination - but at long last, magical version v1.0.0 has come. Who
    ever said Cautomaton was in eternal beta? Not me. (It was implied, though!)

      Added: the long-awaited support for multiple files!
        The first file listed is the primary source for the context menu that
        will be loaded. This matches the normal Windows behaviour: the one you
        right-click on determines the way the context menu is built up.
      Added: support for files in arbitrary locations. So now you can create a
        context menu that applies to "D:\Donkey.txt" and "E:\Elephant.bmp".
      Known issue: Windows versions prior to Vista may have odd-looking menu's
        when dealing with multiple files. Menu items may be missing, doubled
        and/or placed in weird positions. I _think_ this may not happen any
        longer, but I lack (the will to set up) a proper test environment for
        such old OSes at this time. This issue should not affect invocation
        that relies on verbs or text matching; as long as the items appear
        somewhere invocation should still work.
      Added: yet more debug messages (/d). Most are of a very technical level
        and inspired by the above features, but in case of problems these might
        just help one find a cause (and maybe a solution) for an issue they are

Try looking at file copying software like TeraCopy, TotalCopy or similar. I used these over a decade ago, so they may not be the best option anymore. You can just copy files with them as usual, but besides some retry-stuff in case of dropping connections, there's also a speed slider I'm pretty sure.

Pages: [1] 2 3 4 5 6 ... 23next