Queue map downloads with a max limit of 4

[antoni-g]

This is a small PR that addresses a minor issue raised, #423

What this does is use a lightweight p-queue package (from sindresorhus, which there are multiple dependencies from in the project already) to add a max concurrent map downloads to map.store.ts. This prevents a user from downloading every map and waiting for them to complete simultaneously. This is a very minor performance/ux enhancement.

When a map is queued for download, it is marked into the isQueued state. It will be processed FIFO as queued. The UI reflects this by marking the map as Queued.... Once maps are done downloading it will pass along the next map and move to a Downloading... state.

The change was tested by artificially throttling the node app with sudo tc qdisc add dev eth0 root tbf / rate 128kbit burst 32kbit latency 400ms to simulate poor internet. Screenshots of the expected behavior are attached below.

There are a few extensibility improvements we can do from here but they also apply to map downloads overall. I think we could extend this in the future by:

1. allow the user to remove maps from the queue
2. allow the user to cancel existing downloads (an improvement that can be made regardless of this PR)
3. Change the size of the opened map downloads to either fit 4 maps or change the limit to 5 to fill out the opened window. Or simply have the window sized to fit.

Map queued while 4 other maps are already downloading

Queued map moved to downloading once the first in the queue has completed

Contributor Checklist (remove after completing)

• I have read the CONTRIBUTING.md file.
• I've scoped pull request to a single change or feature.
• I have tested my changes locally.
• I have updated the documentation, if necessary.

[bcdrme]

Hi there, thank you for your contribution !

A UX problem I see with this implementation is you'd have to wait for everything in front of the map you wanna play to finish downloading. I'd suggest implementing some sort of prioritisation. So not a queue but a stack.

That'd mean being able to pause some downloads to prioritise the latest thing.

[p2004a]

not a queue but a FIFO

This doesn't compile. Please clarify.

[bcdrme]

A stack, the latest thing you asked the client to download is the most important thing to download. In a mulitplayer lobby settting, you wouldn't want to wait for players to download 5 maps in the queue THEN the map that the lobby is set up with.

Edit: I messed up, not FIFO obviously... last in first out, so a stack

[antoni-g]

I see the logic in either data structure.

Actually, your comment though raises what I would like to work on next - the ability for users to pause and stop and cancel downloads. Right now they are started and just go.

Let me know what y'all think about this PR. Can change to a stack, merge, and work on adding user controls around downloads next.

[bcdrme]

the latest thing you asked the client to download is the most important thing to download

That would be my only requirement. Tbh I'm not entirely convinced it makes a lot of sense to queue a bunch of stuff to download... Maybe if we want to provide a button to load a map pack ? Like the 10 most played maps or something... Or download all scenarios.

Most of the time there's only one map to download at a time.

Anyway, check out this lib https://github.com/hgouveia/node-downloader-helper that we use in this app here.

I think pausing / canceling everything that's not the latest file asked to download makes sense. See if you can resume afterwards what's been in the queue/stack, how long you can keep a partially downloaded file etc...

[antoni-g]

Sounds good. I'll reapproach this from that perspective.

To clarify, do we want to limit to a single concurrent download? In the original issue I linked, it was discussed to do something like 4-6. I'm trying to figure out what the shape of this feature could look like then.

For context, the current impl is quite barebones; you can queue up any number of maps and they will just download in parallel. While it isn't a huge hit, I think folks with slower internet may experience a giant concurrent block of maps waiting to download.

[p2004a]

People do want to download multiple things at the same time. Often e.g. all maps because they have slow internet connection. It's a valid use case to cover we got many requests for, so cancelling last download sounds like invalid behavior to me.