I wonder if I can retrieve the Unix Timestamp with the GET object and if so how?
Unix Timestamp:
http://www.currenttimestamp.com/
https://en.wikipedia.org/wiki/Unix_time
Printable View
I wonder if I can retrieve the Unix Timestamp with the GET object and if so how?
Unix Timestamp:
http://www.currenttimestamp.com/
https://en.wikipedia.org/wiki/Unix_time
yes, here's an example:
Attachment 19981
will work as long as:
1) the source page is not modified
(which I have no idea if could happen!)
2) the number of digits will remain the same
(should not happen before about next 8.537.022.567 seconds XD)
Thank you Schrodinger! It is a little to insecure if it would break if the source page would change though. This is for a mobile game so it would be bad to rely on something that could mess up the game if a 3rd party I have no control over changes something.. :/
Do you know of retriving the dates from the date and time object and then converting it to unix time?
Btw, I am trying to get the unix timestamp for the Android runtime. In windows and iOS I can use the iOS timestamp object, but that does not work on Android :(
I see, agreed, a bit unsecure relying on an external page you can't control.
(btw, if you have your own webpage, maybe you can setup your own reliable page to output that?
Look like php has a "time" function that should output Unix timestamp,
if you use other application languages, maybe there are alternatives for that?)
Theorically you could calculate the Unix timestamp with the Date & Time object (android compatible)
the hard part would be getting the date difference in "number of days" (without having an apt function) from 1 jan 1970 to current date.
worse part being taking into account leap years, and counting correctly days in months of current year.
Should be definitely doable, but would require a little thinking-tweaking...
Hmm would it be possible to calculate it if it is only for 1 year max? I would not really need to account for if someone have been away for 5-10 years. In my game there is a cap anyway so people will not be able to get any more bonus if being away for longer than about 24 hours.
As for php I have really never used it :/ I did follow Jeffs highscore tutorial once that was some php I think, but that is pretty much it.
Tried something:
Attachment 19986
(second string is calculated timestamp, first string is the old timestamp retrieved with get object)
not sure it's 100% correct, have to go now but may take a deeper look later
problem is: Unix time is calculated on UTC time, so you should need to know also which timezone your user is in, to apply some hours shifting
(and could be simplified reducing loops just by storing current unix time as of now, and calculating difference from now on...)
Thank you Schrodinger!!
I will test a bit with this, my only fear is if the loops are a bit to heavy on the performance on Android, but I hope not (I need to save the timestamp every minute or so) How do you mean it could be simplified?
About UTC time, I don't know if that will be a problem though? What I am using this for is that I save the users timestamp every 1 minute or so, and then when they return to the game I retrieve their saved timestamp and compare that to the current timestamp to see how long they have been away and thus calculating how much money they resieve depending on how long they have been away. So since I am always comparing the users old timestamp with their new timestamp, timeszones and such should be no problem ? (Unless they move across timezones of course, but that I will not worry about :P )
Simplified because it actually does the calculation starting from 1970 to current day,
but we could just store unix time at (today) and just calculate the difference from (application day) to (today)
saving about 46 loops (in 2016).
From what you say I'm under the impression you may not need unix time,
but some other infos would be useful,
you need to determine "offline" ho much time has passed since the user left the game, right?
And this time must be measured in ... seconds/minutes/hours/days..?
This may happen after a very long time (like weeks, months..)?
Or you have a maximum "cap" of time? (I read 24 hours above?)
We could use a similar approach of previous example just by looping from saved date to current date,
adding minutes/seconds whatever, without converting to unix time,
will be easily much shorter for loops.
I think Julian days could be used to perform date differences also, without having a proper "datediff" function:
https://en.wikipedia.org/wiki/Julian...ian_day_number
would need no looping at all but jus a couple well laid expressions
(btw, Unix time would break from 2038, if Fusion3 won't support 64bit integers / if Fusion 3 won't be out by 2038 >:)XD)
Hmm I don't think I would need from 1970 no :p I dont see how that would be useful. The game will be released 2016, so starting from 2016 would be enough? It needs to work 2017 forward of course also though. But yeah 2038 does not matter... :P There is not really any hard cap, but very very very very veeeery few players will have a cap over 24 hours. To be safe it might be good to set the cap at 48 hours though.
The reason it would be nice with unix time is that I have already my calculations ready with unix time for the iOS version with the iOS timestamp object, so if I could get unix time here also I would not have to redo the calculations for how much gold to give.
How would you go about to simplify it in regards to the 1970 and all the loops that could be removed?
The 1970-to-today thing needs to be stored because unix time starts at 1 jan 1970,
the unix time is seconds elapsed from that day to now,
so wether we calculate it (example above) or calculate and store it up to now, 1970 must be taken into account XD
Ahhh I see, if you are bounded to use unix time, we could store unix time at 1 jan 2016
and then just add the difference looping from that date to (now)
would save us from looping since 1970 :)
this:
Attachment 19991
Thank you Schrodinger! :)
Actually though, when I thought about it now taking a walk I realized that the unix time is not really necessary like you said!
The only number I am actually after is how many seconds have passed since the game last saved the time and when the user comes back to the app again. So it just need to calculate how many seconds passed since then. So if it had been 1 day and 2 hours when they come back, then I would need to know how many seconds that are in total. Maybe that would be possible to make it even simpler?
The reason unix time was useful for this was that I could just compare the old unix timestamp with the new one and get the diffarance in seconds. But yes, maybe that is unnecessary complicated?
Yes, if you only need the difference in seconds, we can avoid calculating Unix time,
but we're probably going to use a similar method like the one in last example
to be on the safe side we have to take in consideration anyway leap years, numbers of days in months etc.
you could store:
year - month - day - hour - min - sec
on game stop, and fire a loop counting difference like the one in example above
OR
we could look in Julian days, I think they could be used to make subtractions.... have to take a look!
There is also this extension for Android that has unix timestamp - http://community.clickteam.com/threads/86067-Extension-More-Android-Info
Not sure if it's still working though.
Oh that extension seem to work ! That must be a simpler way to do it then? :)
The only problem I have is that this timestamp display 3 digits more, it seems to be displaying not only seconds, but also milliseconds etc. Can I remove the 3 numbers at the end? I always forget how one does that :s
I recorded how it looks like (must be run on an android device to display it, I run it on my Andy emulator): https://dl.dropboxusercontent.com/u/...-12_165939.wmv
It is recorded in 10fps though so the numbers goes much faster in reality.
Andy emulator is here btw, it is really practical for fast testing I have found: http://www.andyroid.net/
ahhh great! :D
you can divide by 1000 to get rid of last three digits
but if the number is (likely) too big to be handled by Fusion ( > 32bit int)
you can use some string manipulation trick
like:
left$(str$(timestamp), len(str$(timestamp))-3)
Thanks Schrodinger I will see if I don't mess it up :)
About this to make the number shorter to be able to handle by Fusion and removing the last 3 digits, how should I write it to get an expression that works? I get expression error when trying to do it :/ My full formula looks like this:
left$(str$(GetUnixTimestamp$( "More Android Info Extension" )), len(str$(GetUnixTimestamp$( "More Android Info Extension" )))-3)
It seems there are uneven ( ) but where should I place some?
Ah, looks like "getunixtimestamp$" is already a string,
then you don't need the additionals str$()
so should be simply:
Left$(GetUnixTimestamp$( "More Android Info Extension" ), Len(GetUnixTimestamp$( "More Android Info Extension" )) - 3 )