Hi h.sie,

thanks for the explanation. I am not sure what the effect of an interval change would be so I would rather not change the interval too much if not necessary. Maybe reduce it a bit so that after loading a save game the weather changes earlier :06: (if it's too short, I guess, the weather will be 'locked' again because there is no time to adjust :hmmm:)

I guess if you can avoid the long fog periods without changing the interval I would be conservative and follow your rule: Don't change too much. Maybe a factor of 1.5 or max. 2.

Anyway, I am quite happy with the weather at the moment, so I might not be the right person to answer :oops:

Cheers, LGN1

Bad Weather Fix
 

Thank you very much, for all effort and time. :yeah:

May I suggest to open a new thread for bad weather fix?

V 15 C is a work on SH3.exe for repair and flooding times and other values, and Bad Weather took an other way, is totally independent.

Discussions will be mixed, with answers one time for repairs, other time for weather.

Thanks, again :salute:
(sorry for bad English)

Hi !

Okay, I know, please let your time ! ;)

And now I´ll test the Bad Weather Fix Special Edition ! :yeah:

Best regards,
Magic:salute:

@H.sie:
I have now a working version of envsim.act with one of my new ideas for reducing the windspeed.

The principle is very simple - since the root of the windspeed problem lies in the fact that the winds can often exceed 15 m/s internally, and are then limited to a maximum 15 m/s, it seemed like a good idea simply to remove 15 m/s from any windspeeds that exceed 15 m/s. Thus we retain the original random value before it overflowed.

I have attached the new code to the end of the envsim.act file main block, starting at location envsim.act + 149CDh, and, after a lot of checking with the debugger, and a subsequent series of short patrols, the code seems to work. There is one defect, which I could fix easily: I have not applied the minimum limit after subtracting the 15 m/s. This is just the test version.

Preliminary tests around the Azores at tc=2048 (well known to intensify bad weather):
No windspeeds of 15 m/s have persisted for more than one or two weather changes (statistically, this behaviour is as expected). Little fog and heavy rain either - I still think the fog and rain are primarily tied to windspeed - but I have had fog and heavy rain at 7-9 m/s on a couple of occasions.

I would call that good weather behaviour.

I haven't used my own counter-limiter idea because, like you, I found it hard to create a safe, free variable. (Congratulations, by the way, on your announcement that you have succeeded in that task.)

One thing that mystifies me, though:
I'm using your recommended Ollydbg2 disassembler for this. When I save the amended file to 'envsim2.act', and then detach the debugger, and close down SH3; and then I start SH3 up again, it is apparent that SH3 is now using 'envsim2.act' as its new file, not the original 'envsim.act' file. This is easily tested, just by moving the original envsim.act file to a different folder, when SH3 functions properly. Also, if the running SH3.exe is now attached to Ollydbg2 again, this confirms in the debugger that file envsim2.act is the active file.

Of course, I could easily alter this behaviour by re-saving envsim2.act (from Ollydbg2) as envsim.act again. But how is SH3.exe retaining knowledge of this change?

Thanks for your notifications to me above in your other posts. (I was away for the weekend.)

@NGT:
I agree with your suggestion that H.sie's weather and repair fixes should be separated, for ease of reading.

Stiebler.

@Stiebler: Great news. So I save the time for programming your idea and can concentrate on my own idea. So three different approaches to fix the weather bug are better than none!

1) Reduce weather period by a factor of 3
2) Subtract 15m/s from values > 15m/s
3) Force good weather after long bad weather periods.

I agree, this weather issue is worth a new thread. So this will be my last answer regarding weather in this thread.

Some words:

1) I would not dare such a deep intervention in the algorithm as you did, but that's only my "intention", not knowledge, and I may be wrong. So I'll restrict on a fix that is only active when long bad weather occurs, because I like the sh3 weather from what I've seen so far. Hope, "your" weather isn't too good now.

2) I could give you a unmodded EnvSim.act but with code section write-enabled. So you can store values. But if you store data, I suggest to use relative pointers instead of absolute, because in WinVista and later the DLLs and ACTs can be loaded to different memory locations every time the game is started. So static pointers may work on your sytem, but possibly not on others. This was the reason for the CTDs on Win7/64 in my earlier fixes.

3) Maybe as a programmer you know that already, but let me in spite of that say what could lead to sometimes non-obvious side-effects: In my first patches I was not 100% accurate by reconstructing the state of the CPU and FPU after the patch. FPU registers, FPU stack pointer, CPU registers and CPU stack pointer should look the same before and after your patch. otherwise side-effects are possible (example: crew fatigued instantly when snorkelling, because I forgot to reconstruct FPU registers and so a wrong value was taken to calculate fatigue).

4) Yes, funny, SH3.exe seems to load all files it can find in that directory, it seems not related to the filename. Same behaviuor in the library folder, where I renamed an old Materials.dat to Materials_old.dat but this file was loaded anyhow. It's related to sh3.exe, not OllliDbg.

Greetings.
h.sie

Please from now on lets discuss about the weater in this thread:

http://www.subsim.com/radioroom/showthread.php?t=177507

This thread now is only for fixes to sh3.exe.

Since no further bugs have been reported for patch V15D_beta3, I'll release the next version in the next day. It will contain the "museum-bug" (CTD in museum only).

h.sie


EDIT: It of course will contain the fix for the museum bug

It's good to finally see some words about this. Not one time I had problems with "filename_bak.ext", or probably even "filename.ext.bak" loading instead of "filename.ext".

@H.sie,

Just a quick return to the original purpose of this thread.

I've completed a long patrol in 1944 with your SH3 patch V15D_Beta3.

Everything functioned as expected, and no problems. Using Windows-7/64-bit + NYGM.

Good work!

Stiebler.

Thank you very much, Stiebler.

I don't know if these longer repair times fit to the special damage model of NYGM, which itself has longer repair times.

If you need help to disable this specific repair time mod or to adjust the factor of which repair times are multiplied, feel free to contact me.

Or: Do it yourself :).

h.sie

Was wodering that myself :hmmm: John, did you make any changes to NYGM repairs model, or how come the new longer repair times did not extend unreasonably when combined with the existing one in NYGM??

@H.sie/Hitman,

It was the multi-talented Observer (now long-absent from this forum) who made the changes to the NYGM repair model.

I haven't noticed anything special in my patrol test, concerning the effect of H.sie repairs, but your two queries have un-nerved me. I shall make some further tests especially for damage.

Stiebler.

@Stiebler: No reason to be nervous. Only side-effect: longer repair times than with GWX. but these could reduced to fit individual tastes.

I have the old starforce version DVD so I'm excluded from this great achievement. Suggestions?

Buy a SF free version...

E.g.:

http://www.amazon.de/Purple-Hills-Si.../dp/B002YNS4FY

I think that Subsim sells a SF free version as well if you want to support it.

I discovered it AFTER i bought my SF free version unfortunately.:oops: