Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow Connect client to backdate unlocks #2618

Merged
merged 3 commits into from
Aug 19, 2024

Conversation

Jamiras
Copy link
Member

@Jamiras Jamiras commented Aug 17, 2024

While a Connect client is unable to communicate with the server, it will continue to send unlocks periodically. The server currently sets the unlock time to be when it receives the unlock message. If it takes 10 minutes of retries for an unlock to finally reach the server, this will cause the unlock to be logged 10 minutes later than when it was actually unlocked.

Generally, this isn't an issue, but players are starting to rely on the disconnected behavior to do long play sessions while travelling without internet. When internet becomes available, all unlocks are handled in a short period of time. This makes following the flow of a player through a game difficult and can lead users to question the validity of the unlocks.

This PR adds a new o parameter to the awardachievement and submitlbentry APIs that allows the server to backdate the event up to two weeks. To minimize abuse of this functionality, a validation hash is required. If the correct validation hash is not provided, the event will not be backdated.

Because sessions are abandoned if inactive for more than 10 minutes, these backdated events will normally appear outside of sessions and will appear in Generated Sesssions when viewed:
image

Copy link
Member

@wescopeland wescopeland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified locally.

The only thing I had to do a little digging on was what the unit of measurement for the offset is. I ultimately determined it by seeing $maxOffset definition and the subSeconds() call. While skimming the code, my brain initially intuited it was in milliseconds (thinking: time since UNIX epoch), though this is obviously not correct.

I'm wondering if it may be helpful to better designate, either through a comment or changing a variable name(s), that the offset is measured in seconds.

@Jamiras
Copy link
Member Author

Jamiras commented Aug 17, 2024

I'm wondering if it may be helpful to better designate, either through a comment or changing a variable name(s), that the offset is measured in seconds.

It's better documented in the (uncommitted) client code:

/**
 * API parameters for an award achievement request.
 */
typedef struct rc_api_award_achievement_request_t {
  /* The username of the player */
  const char* username;
  /* The API token from the login request */
  const char* api_token;
  /* The unique identifier of the achievement */
  uint32_t achievement_id;
  /* Non-zero if the achievement was earned in hardcore */
  uint32_t hardcore;
  /* The hash associated to the game being played */
  const char* game_hash;
  /* The number of seconds since the achievement was unlocked */
  uint32_t seconds_since_unlock;
}
rc_api_award_achievement_request_t;

@Jamiras Jamiras merged commit b7e4c64 into RetroAchievements:master Aug 19, 2024
5 checks passed
@Jamiras Jamiras deleted the feature/unlock_offset branch August 19, 2024 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants