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

Support for GetAchievementAndUnlockTime #5

Open
Yanrishatum opened this issue May 2, 2016 · 5 comments
Open

Support for GetAchievementAndUnlockTime #5

Yanrishatum opened this issue May 2, 2016 · 5 comments

Comments

@Yanrishatum
Copy link
Contributor

This method takes two pointers, bool with unlocked state and uint32 with unlock time in unix timestamp.
This issue is more about how to format it for Haxe code, I can implement it and make a pull request myself.
Unlock time may be 0, even if achievement already unlocked (if it was unlocked before December 2009).
So there a several ways:

  1. getAchievementUnlockTime(id:String):Int
    Will return 0 if achievement is not unlocked, and non-zero value otherwise. This will automatically cease the support for 2009< achievements, but I think this is not very bad in current case. (We're not making some sort of achievement unlocker, yes? :) )
  2. getAchievementAndUnlockTime(id:String):{ achieved:Bool, unlockTime:Int }
    E.g. object/typedef with both values.
  3. Make both methods :)
@larsiusprime
Copy link
Owner

Another approach is to return a sentinel value like -1 for "is unlocked, but we can't determine the time (ie it was before December 2009)". Then you wouldn't need two functions or a typedef. Any reason this wouldn't work?

Like you said it really doesn't seem like it will be an issue for us as the only case I can really imagine it mattering for is if someone wanted to rewrite their pre-2010 game in Haxe or something and re-use the same steam ID.

@Yanrishatum
Copy link
Contributor Author

Yanrishatum commented May 2, 2016

Then it's better to return -1 as "not unlocked"? It would make more sense, as "not unlocked" is a state without time at all.
UPD: Plus it's defined as unsigned int in steam API, so -1 would be more dangerous, no?

@larsiusprime
Copy link
Owner

larsiusprime commented May 2, 2016

Yeah sure, whatever makes the most sense, as long as the function documentation explains it. So:

-1: not unlocked
 0: unlocked, but we don't know when
 X: unlocked at time X

0 seems like an appropriate "unknown time" sentinel value since it's literally impossible for a Steam Game to have an achievement unlocked in the 70's. Since it's a unix timestamp the value for the int is milliseconds, right? Is -1 safe for us to use in that case? I'm not sure if DateTime is going to be wanting to interpret that value as an unsigned integer, and thus -1 is actually representing some valid amount of time. If it's not safe to use -1 as a sentinel value, then maybe we do need to have the two functions after all.

@Yanrishatum
Copy link
Contributor Author

It's in seconds. Time is seconds since January 1, 1970. - from isteamuserstats.h.
And condition for 0 time is: If the return value is true, but the unlock time is zero, that means it was unlocked before Steam began tracking achievement unlock times (December 2009).

@larsiusprime
Copy link
Owner

Okay, cool, so we've got a 32 bit integer here which only going off the positive value will let us get to 2038? Seems good to me.

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

No branches or pull requests

2 participants