Ryzom

Thats why no one can figure out how the weather system works. I already digged into this issue , and in fact, the Linux weather is the right one, that means its equal to the weather the server expects.

Its caused by a compilation issue. The 'random' number generator that feeds the weather system gives different values in the windows compilation.

You can check with your linux version, that every time it 'sap storms' in LoC, you will get sup zun amber. Thats why I know its the right weather. In windows, its random.

Ah, yes I remember :)

IIRC, Weather system use a noise matrix (CRandomGrid3D) to perform this job. The noise generation is based on the libc PRNG aka: srand(), so the result is platform dependent.

This is probably why your two OS have different weather :)

Please someone could check if commited patch is enough to fix the bug ? Thanks :)

kervala wrote:

Please someone could check if commited patch is enough to fix the bug ? Thanks :)

If I remember right, I don't think this patch will fix it, because there are other 'obscure' reasons (rounding) with the fp unit in linux. I think that maybe the easiest way to solve this is to create this precomputed noise table (CRandomGrid3D) in a binary file, and use it, instead of calculating the values on initialization.

Of course this would lead to the problem of packaging this file with the client/server, and its not a elegant solution.

You're right, it should be related to OptFastFloor inline function which is using default rounding under Linux and round down under windows x86 (under x86-64 it shouldn't use the same code because inline ASM is disabled).

Are fast floor tricks still useful under Windows in VC++ 2008 and later ?

I dont know....

I messed with some notes I wrote about it a long time ago, maybe it can help:

-on windows: FPU using ROUND_DOWN and DOUBLE_PRECISION and table populated with msvc rand() (I think you took care of this already)
-on linux: FPU not touched, default should be: ROUND_NEAR, SINGLE_PRECISION.

I will try some benchmarking :)

Im not sure if this is resolved in the last patch , but I think I know at least one collateral effect.

The material position inside a deposit has changed with this new 'random table'. This can be observed in deposits with lots of mats (like basic/fine/choice of all families). People must find now in the vicinity where the mat is. It dosn't change much, but it breaks the knowledge of years of digging.

Please could you confirm if this patch fixed the issue ?

Applied in changeset commit:380f811ebb8c.

Im not sure if the clients (win/linux/mac) are displaying the same weather, but I've made a small verification today and im prety sure that the windows client is with a different weather than the server.

Did you check with shift+F2 in DEV client ?

No, I don't have it. You can verify that in one moment, tracking a sup on a 'sap storm' weather is successful, and on another moment (another cycle), its not (for the same material). The 'sap storm' weather is unique (not shared as the 'fair' weather) and can be used as a solid reference. I hope it helps.