Bug #1328

Map time and weather Issue

Added by Ricke about 7 years ago. Updated almost 6 years ago.

Status:Closed Start date:07/07/2011
Priority:Normal Due date:
Assignee:kervala % Done:

100%

Category:NeL: General
Target version:Version 0.9.0

Description

I use a alt Char on windows and my main on linux and it seems most of the time when my alt care planing me we have dif weather also the time on windows seems to change faster than on linux it makes it a bit harder to get them exc mats.

History

#1 Updated by usm4rin3 about 7 years ago

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.

#2 Updated by Naush about 7 years ago

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 :)

#3 Updated by kervala almost 7 years ago

  • Category set to NeL: General
  • Status changed from New to Assigned
  • Assignee set to Sywindt

#4 Updated by kervala almost 7 years ago

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

#5 Updated by usm4rin3 almost 7 years ago

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.

#6 Updated by kervala almost 7 years ago

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 ?

#7 Updated by usm4rin3 almost 7 years ago

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.

#8 Updated by kervala almost 7 years ago

I will try some benchmarking :)

#9 Updated by dnk-88 over 6 years ago

  • Target version set to Version 0.9.0

#10 Updated by usm4rin3 over 6 years ago

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.

#11 Updated by kervala over 6 years ago

Please could you confirm if this patch fixed the issue ?

#12 Updated by kervala over 6 years ago

  • Assignee changed from Sywindt to kervala

#13 Updated by kervala over 6 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

usm4rin3 wrote:

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.

You were right :)

We disabled fast floats and it worked fine :) Weather is exactly the same under Windows and other OSes now ! Thanks a lot :)

#14 Updated by kervala about 6 years ago

Applied in changeset commit:380f811ebb8c.

#15 Updated by kervala almost 6 years ago

  • Status changed from Resolved to Closed

#16 Updated by usm4rin3 almost 6 years ago

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.

#17 Updated by kervala almost 6 years ago

Did you check with shift+F2 in DEV client ?

#18 Updated by usm4rin3 almost 6 years ago

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.

Also available in: Atom PDF