 |
There's no need to go back to the menu screen for this bug to occur. It is caused by a CURL request never returning a result. One solution would be to add a timeout to the request, but this won't make people with unstable connections happy. Another solution is to allow the player to cancel downloads from the queue even while they're in progress. What was the rationale behind the design decision not to allow this? |
 |
Don't know. I'll post a question in the member's forum to see if anyone can remember the initial design decision, and see if it's okay to cancel a download. |
|
|
No one remembers, so you're clear to go ahead with the cancel. |
|
|
The files in the zip will allow you to cancel downloads in progress from the menu queue, even if they're hanging. Without this, canceling a hanging request will be impossible (unless you exit the game, which is what issue 0003766 was about) since the current way of canceling the request relies on CURLOPT_WRITEFUNCTION, which is not called when your connection hangs and nothing is transferred. A question: if a download that comprises a l10n pk4 is canceled and the l10n download is finished the pk4 will remain in the directory. Should I make it so the localization file is removed when a download is canceled? They're usually just a few kilobytes. |
|
|
It should be okay if the I10n file remains. The player will most likely retry the download a few minutes later. |
|
|
What's the recommended way of cancelling? I left-clicked a hung mission and its name went back to the left side of the screen, and the download picked up the next mission in the queue and started downloading it. Which is fine. Except I left-clicked a mission that had completed at 100%, and it went back to the left side, but was still there when I went back to the new missions screen. Shouldn't a mission at 100% complete ignore the mouse action? |
|
|
You're right. I updated DownloadMenu.cpp |
|
|
Works fine. |
- Anonymous
