You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is related to the new event system integrated in the API.
Context
With the arrival of Benchmark 2, we needed a way to clear the leaderboards of its maps, but keep them saved for the original maps. Thus, the leaderboards needed to be separated. However, at the time, the only way to do this was to insert a new entry for each map with a distinct UID, such that we can retrieve the UID of the original map and vice-versa. The solution was to edit each map file manually to mark the _benchmark suffix for the map UID.
At the time, we also wanted to save the records made on maps with a UID *_benchmark to the original map, but not the reverse obviously. The only solution for this at this time is to hardcode it.
This mechanism needs to be generalized for all events incoming: we want to make a distinct leaderboard for the maps in the context of an event. This goes for the campaign, the benchmark, the Storm Runners, and any other incoming event that would be integrated in the Obstacle system.
What's new with this feature
From now on, events like Campaigns and Benchmarks are entities in their own right. It is based on an event "handle" (an identifier that is common for the various editions), and an edition ID. For example, the Summer 2023 campaign has the event handle "campaign" and the edition id "1" ; Benchmark 2 has the event handle "benchmark" and the edition id "2" ; and so on.
The events can be accessed with different routes:
/event: get the list of event handles with their last edition id
/event/:handle: get the list of edition ids of the provided event handle :handle
/event/:handle/:id: get almost-full information about an event edition with its handle and edition id (name, banner image, maps...).
Every route related to a map or a player in the context of an event is prefixed by the route of the event, eg. POST /event/:handle/:id/player/finished is used in the API to finish a map in the context of the given event. The API will thus save the record for the map in the event context and also to the original map.
This issue is related to the new event system integrated in the API.
Context
With the arrival of Benchmark 2, we needed a way to clear the leaderboards of its maps, but keep them saved for the original maps. Thus, the leaderboards needed to be separated. However, at the time, the only way to do this was to insert a new entry for each map with a distinct UID, such that we can retrieve the UID of the original map and vice-versa. The solution was to edit each map file manually to mark the
_benchmark
suffix for the map UID.At the time, we also wanted to save the records made on maps with a UID
*_benchmark
to the original map, but not the reverse obviously. The only solution for this at this time is to hardcode it.This mechanism needs to be generalized for all events incoming: we want to make a distinct leaderboard for the maps in the context of an event. This goes for the campaign, the benchmark, the Storm Runners, and any other incoming event that would be integrated in the Obstacle system.
What's new with this feature
From now on, events like Campaigns and Benchmarks are entities in their own right. It is based on an event "handle" (an identifier that is common for the various editions), and an edition ID. For example, the Summer 2023 campaign has the event handle "campaign" and the edition id "1" ; Benchmark 2 has the event handle "benchmark" and the edition id "2" ; and so on.
The events can be accessed with different routes:
/event
: get the list of event handles with their last edition id/event/:handle
: get the list of edition ids of the provided event handle:handle
/event/:handle/:id
: get almost-full information about an event edition with its handle and edition id (name, banner image, maps...).Every route related to a map or a player in the context of an event is prefixed by the route of the event, eg. POST
/event/:handle/:id/player/finished
is used in the API to finish a map in the context of the given event. The API will thus save the record for the map in the event context and also to the original map.Transition issues
See #7
The text was updated successfully, but these errors were encountered: