v1.2 - PhotonMessageInfo.timeStamp is really really negative

scritch · October 2011

So, just updated from v1.1 from asset store to 1.2 from asset store and switched to using cloud server vs my test box.

This created a variety of problems for me, but the one that I actually can't solve has to do with PhotonMessageInfo.timeStamp.

Following along the chain of events, this appears to be ultimately a float converted into an int, back into a float again. Which is already a bit strange, but worse, in the last version it appeared to start at 0, but now starts at -1.9million something.

The bad part about this is that the number is so largely negative that it's losing all of the mantissa precision, and so if you're trying to compare time stamps that are close together to throw out out of order packets in an unreliable transmission situation, you're going to be wrong sometimes because the precision is too low.

There's no way for me to solve this on my own using the cloud servers that I can see... or is there?

It seems like you want double precision floats and long ints for this in order to not lose this precision and cause a number of incorrectly dropped out of order serializations...

Can somebody help illuminate this beyond what I've said above?

Tobias · October 2011

Oh. Thanks for reporting this.

In fact, we didn't want floating precision. We think an int with millisecond precision should be fine and that's what we send and sync to the clients. Signed integers have the benefit that you get a correct delta even between a large and the (next) very small value.

When we re-implemented Unity's networking, "time" became a float with second precision.
This is the root of the problem.

Workaround: Change PhotonNetwork.time from float to double.

public static double time
{
    get
    {
        if (offlineMode)
        {
            return Time.time;
        }
        else
        {
            return ((double)networkingPeer.ServerTimeInMilliSeconds / 1000.0f);
        }
    }
}

Part of the problem is that our server rarely restarts, so all timing based on "since server start" is going to blow the size of float sooner or later.
We could add a time based on "room creation", if that helps.

by0logic1 · January 2012

Hey Photon guys,

I'll bump this thread instead of starting a new one as my problem is the same. I'm using PUN 1.7 with PhotonClouds for a week or two and everything's been great. Last friday I implemented Interpolation/Extrapolation, using PhotonMessageInfo.timestamp and it was all good when I left for the weekend.

Since yesterday the game will only work half of the time. Turns out I get the -19millions timestamp issue, too. This thread had me looking at PhotonNetwork.time, but it looks like it was already fixed in 1.7 and correctly returns a double. I tried a few types/cast and nothing seems to fix the issue, best I get is the initial settings. I'm printing a test on the very first line of the receiving end of a OnPhotonSerializeView() and I'll get something like this (getting this right now) :

PhotonMessageInfo.timestamp = (double)-1888696.96 | (float)-1888697 | (int)-1888696 | (uint)4293078600 | (long)-1888696
Time.time: 19.3624 | DateTimeUTC: 1/17/2012 1:14:12 PM | Network.time: 670.198

Again, it might be my implementation that's incorrect but in in any case, I'd appreciate a pointer in the right direction. I can post my whole script if desired though its pretty much only a modified Unity's NetworkRigidbody. Thanks in advance!

EDIT: Probably useless to you, but it finally work again for the first time today, with:

PhotonMessageInfo.timestamp = (double)705820.8 | (float)705820.8 | (int)705820 | (uint)705820 | (long)705820
Time.time: 12.10483 | DateTimeUTC: 1/17/2012 8:14:48 PM | Network.time: 25905.623

Tobias · January 2012

See this reply please: viewtopic.php?f=17&t=1295&p=5863#p5863

v1.2 - PhotonMessageInfo.timeStamp is really really negative

Comments