Ryzom

Ulukyn,

I took a look and verified that you are correct:

For the rest of the watching world here is the definition of a game cycle.

1typedef uint32 TGameCycle;            // Integer game cycle count from the game (in game ticks)

Here we take a game cycle and return a uint32 - which is consistent. There are next a series of casts to sint32 which result in a loss of data at high values (which a long running server would encounter.)

1inline uint32 saveGameCycleToSecond(NLMISC::TGameCycle tick)
2{
3        // Evaluate the UTC of this event (with the current date of save). Suppose that 1 second==10 tick
4        return  sint32(NLMISC::CTime::getSecondsSince1970()) + (sint32(tick) - sint32(CTickEventHandler::getGameCycle()))/10;
5        // NB: result should be positive since no event should have been launched before 1970!
6}

It appears that loadSecondToGameCycle may suffer similar data issues as well:

1inline NLMISC::TGameCycle loadSecondToGameCycle(uint32 second)
2{
3        // Convert UTC of the event to game cycle. Suppose that 1 second==10 tick
4        sint32  newTick= CTickEventHandler::getGameCycle() + (sint32(second) - sint32(NLMISC::CTime::getSecondsSince1970()))*10;
5        // If game cycle is loaded on a server where current game cycle is too young, we can have here negative values => avoid them
6        return std::max(newTick, sint32(0));
7}

I know this bug was causing a lot of problems in live - I assume you patched the cast? Can you provide us with the patch?