[Gambas-user] arithmetic operations on dates and times

Caveat Gambas at ...1950...
Thu Jun 9 14:17:04 CEST 2011


Apologies if I'm missing something obvious here, or have maybe
misunderstood the concept of 'scaling' the time... but wouldn't you need
to account for your scale factor also in the client time calculation?

So for your client to know what "now" is in the game world, you'd need

server_time + (( Timer()/86400 ) * 4)

[if the player has been playing for an hour, the game time has moved on
by 4 hours]

Or should it be that game time only moves at 4x the speed while the
player is absent (a bit like the Lion, the Witch and the Wardrobe)?

Also, again working on the assumption that time goes by 4x as quickly in
the game world as in the real world...  when the server year hits 2012,
your game year would then jump to 12048... meaning 4 game years have
gone by in 1 real year.  But, it would seem more 'natural' for the game
year to increment every 3 months, so it doesn't seem as simple as just
multiplying up the sum of real server year and base year by your factor
(4 in the example).  This means you can't presume that the game year is
12044 just because the real year is 2011, you'd have to know what month
it is too...

Regards,
Caveat

On Thu, 2011-06-09 at 12:54 +1000, Ian Haywood wrote:
> On Thu, Jun 9, 2011 at 12:27 PM, Kevin Fishburne
> <kevinfishburne at ...1887...> wrote:
> > How in the world would one do this? It's not really important that the
> > client know the actual date, but it does need to know the time. The
> > client should be able to add "Timer" to the game world time so it can
> > keep an accurate 24-hour time while the player is playing. Basically the
> > client would receive the game world time upon authentication, then look
> > at "gameworldtime + Timer" to determine what time of day it was until
> > the player stopped playing.
> >
> > I noticed that adding and subtracting to a date or time prints a
> > floating point number, but multiplying or dividing complains about
> > expected datatypes. Any insight or outright solutions would bring light
> > and dark to the world. :)
> Best suggestion is to formally convert the Date to a Float using
> CFloat(...) function.
> This number is the number of days since 8000BC, time is the fraction
> part, so .5 for noon exactly, just before midnight will be .99 and so
> on.
> 
> So your equation is
> 
>    ( CFloat(base_time) + CFloat(Now) ) * 4
> 
> You can then use CDate to turn this nuber back into a real date. BUT
> my advice would be to send this number, before conversion, down the
> wire to the client.
> 
> The client then calculates its own time using
>       server_time + (Timer () / 86400.0)
> 
> 86,400 is the number of seconds in a day, this is because Timer comes
> in seconds and we want fraction-of-day to keep in line with everything
> else.
> 
> This number can then be converted back to a date and displayed by the
> client, using the clients own localisation setting (not the servers)
> so users see the time in their own localisation, but servers and
> clients don't stuff up if they are in different countries
> 
> Ian
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user






More information about the User mailing list