yes of course I consider others.

a factor of 4 means the stock time periods will be divided by 4.

40 hours will be 10 hours
and so on

I sorry h.sie but from my test I know the weather change every 33 hours not 40. So I think factor should be between 2.5-2.75 or if need to be integer 3.

Your successes start to push me to start learn assember as a more practical then my C++ :)
Is a big difference between this to languages?

period varies. my tests showed 44h

It's no good, so maybe let's use a average of ours intervals 37-38h. Factor 3 is good and give as 11-14h weather intervals.

ok, I'll program a special Yoriyn-version with factor 3 and no messing with algorithms. needs some time.

Can't wait to test it :) and I hope not only me.

Are you want to check SH5 EnvSim.act? Mayby you can move weather algorithms from one to another?

Have we determined if there is an in-built worsening of the weather over time or not? I thought I read somewhere on this thread that it does.
If the weather is more likely to get worse than better each time it changes then shortening the period that each weather lasts for will result in the weather reaching unchanging bad weather sooner in time.
Or am I missing something?

That's why we need testing. But reducing time needed to weather change theoretically give us more chance for more sun, increased by more oportunities to randomize new weather.

40h interval give us a 4 "dice rolls" for every week in the game.
14h interval give us a 12 "dice rolls' for every week in the game.

So what hapend when fog don't change on first dice roll? you need to wait to second roll and for 40h second roll take half week!!

@CherryHerbey: After reading STieblers & Hitmans posts I assume that there is in fact some in-build sticking. I rely on their words instead of spending weeks to test it myself. This sticking I called "tendency to converge to 15m/s"

And it must be tested now how to disturb this tendency. In an first attempt I'll not change the weather algorithm code itself but only do some "postprocessing", that means I'll change only the windspeed variable after it has been calculated by the algorithm: if windspeed=15 then by a certain chance (50%) a new windspeed between 5 and 14 is randomly chosen. Since the history (older windspeeds) seem to affect the calculation of the new windspeed, this simple "postprocessing" could be sufficient to disturb this sticking at 15m/s, the algorithm never can converge. This is my idea.

I already have programmed that algorithm, and it works, but I must test it with Win7/64Bit. Maybe this evening I'll upload it.

And then the big testing period begins.

H.Sie,

i am very excited with the new envsim.act !!! :yeah:

haven't test it ''deeply'' but definetely it shows that is a matter of time to get (with the valuable help from Stiebler) to a nice result !
from my tests at training academy (yes ,i know that valid results will be only from campaign mode....will get at it) i didn't notice any real hard stick to 15.
i notice that the weather always changed and yes had a tentesy to stay at high winds (from 10 to 15 ) but it didn't stick to 15
i just want to point out that my scene.dat is using the weatherfix values so maybe this is something that must be cleared at tests for all.

i am waiting with great impatience your next achievement (s)

oh yes....the machine has start its engines now!!

@Privateer: i think that here is a thread that is ....''calling'' you ! (of course if H.Sie need help)

bye

I think I'll release two (alpha) versions:

1) Version with only weather change interval reduced by a certain factor but without any further changes.

2) Version with both weather change interval reduced AND "h.sie's high windspeed convergence distortion algorithm V1.0beta" (already copyrighted :D), as described here:

http://www.subsim.com/radioroom/show...&postcount=585

But there remain 2 questions:

1) Can I use JSGME to replace EnvSim.act (which lies out of the "data" folder)? Would make life easiser for testers.

2) Which factor should I use to reduce weather change interval? I'd say somewhere between 3 and 8 (??)

Yes, it's possible like patched sh3.exe...

CherryHarbey said:
I think this outcome is extremely likely - that faster weather changes (and no other changes) will make things worse. (You probably read, or inferred, this point from something I posted earlier.)
Everyone: Please don't forget that the time change interval for several weather parameters can be set in scene.dat, where faster time changes for wind updates definitely make things worse. So it hardly needs to be tested by changes to code.

Nevertheless, since several contributors to this thread are demanding this change, and are willing to test it, and H.sie is happy to provide it, I suppose it will settle the question definitively.

Concerning the RealWeatherFix (RWF), now fitted to most super-mods (including NYGM and GWX):
This alters start-up parameters in scene.dat in a way which appeared to give the best mix of desirable weather properties that we could manage.
However, the RWF does not affect the weather code, and the weather code contains a serious bug. We know this, because the devs said so when reviewing my documentation for the RWF.
H.sie has discovered a problem in the code with the wind speed variation. This (perhaps) is the 'serious bug'. In any case, it is the obvious and natural place to start when trying to fix things.

Incidentally, the devs made an interesting safety innovation for the weather in SH4: as soon as you move away a certain distance (I think it was 50 km) from the earlier position, the next weather check triggers a major weather change. So you can always cancel bad weather by moving off a sufficient distance. However, I suspect this might be too complicated for SH3 without a much better understanding of the weather code and also of the U-boat position in code.

But what if we reset the wind speed to 0 m/s after every 50 (say) time checks? (As well as making any other changes.) This new suggestion would be only a fail-safe device for the wind-speed, and would be much simpler to code.


After help from H.sie by PM (much appreciated!), I am now able to start investigating the assembly code for the weather routines too. Unfortunately, there is a steep learning curve with Ollydbg2, but at least I can repeat H.sie's work now. I hope to be able to make a more useful contribution in the next few days.

Stiebler.

@Stiebler:

My assuption after inspecting a little bit the weather code is as follows:

the weather change speed parameters in scene.dat determine only the speed a certain aspect of the weather (rain, clouds, windspeed) changes after a new weather has been calculated, that means, after a weather change period has ended.

AFAIK and as far as I have seen in the debugger, the weather change period is the same for all aspects (windspeed, rain, fog). after such a period (about 20-40hours) a new weather is calculated and the current weather then fits to that new weather - according to the change speed values in scene.dat. Rain fits immediately, wind slowly to the new calculated weather, according to their individual parameters and then keeps constant - until new weather is calculated.

but the starting time for these changes is the same and determined by the weather change period.

Until now I thought that all other weather parameters in scene.dat and campaign files have been optimized during a 5 years process of modding work and so will stay constant now. But when we start to change these parameters also, this could become a never ending story, and, to be honest, I fear I'll lose orientation what to do next.

By the way: It would be easy to force a windspeed=0 after 50 time steps, but I recommend to randomize that number, lets say 40-60 time steps ....

OR (easier) I could force windspeed=0 EVERY time step by a certain chance, say, 5%.

h.sie

...I´ll test then Version 2....:D

Best regards,
Magic:salute: