Map veteos refactor

[GrantBartlett]

Refactor map vetoes into a new table, not dependent on the order of the map pool. Faction pick / Vetoes should map to player_id, map_id.

[alexp8]

Table name: qm_map_picks
Columns:

• id, primary key
• ladder_id, foreign key to ladders.id
• qm_map_id, foreign key to qm_maps.id
• user_id, foreign key to user.id
• side_index, foreign key to sides.id
• rejected, boolean

Questions:

1. By relating to users instead of players we avoid having to store n+ map choices for every single player that a user may have. Some users have 20+ players on a single ladder. Thoughts?
2. Would we prefer map rejection derived from side_index == -1 or a rejected column
3. Should the QM client update the server every time a user updates a map, or when they click "Find Match"?

[alexp8]

Proposed payload from QM client, a JSON array with following structure @Sneer-ra2

BULK update (QM client makes the request upon clicking "Find Match":

{
   "ladder_id": 5,
   "user_id": 560,
   "mapChoices": [    
       {
           "qm_map_id": 33,
           "side_index": 4,
           "rejected": false
       },
       {
           "qm_map_id": 38,
           "side_index": 3,
           "rejected": false
       },
   ...
   ]
}

OR

Single map update: (every time QM client updates a map, make a request)

{
   "ladder_id": 5,
   "user_id": 560,
   "qm_map_id": 33,
   "side_index": 4,
   "rejected": false
}

[alexp8]

Proposed ladder response from server, when QM client boots up and fetches map sides from the server, (/api/v1/user/ladders)

[
    {
        "id": 1,
        "name": "Yuri's Revenge",
        ...
        "mapChoices": [    
            {
                "qm_map_id": 33,
                "side_index": 4,
                "rejected": false
            },
            {
                "qm_map_id": 38,
                "side_index": 3,
                "rejected": false
            },
        ...
        ]
    },
    {
        "id": 2,
        "name": "Tiberian Sun",
        ...
        "mapChoices": [    
            {
                "qm_map_id": 49,
                "side_index": 4,
                "rejected": false
            },
            {
                "qm_map_id": 61,
                "side_index": 3,
                "rejected": true
            },
        ...
        ]
    },
    ...
]

[rohsyl]

The method createQmMatch into QuickMatchService needs to be adapted.

The following methods are using the bit_idx too.

• setClanSpawns of QuickMatchService
• set1v1QmSpawns of QuickMatchService
• createQmAIMatch of QuickMatchService
• and probably somewhere else

Otherwise the propositions looks good

[alexp8]

bit_idx is specific to qm maps and their order in the qm map pool. User map faction picking shouldn't be impacted