SUBSIM Radio Room Forums - View Single Post - Realism- and gameplay-related hardcode fixes for SH3.EXE

Stiebler · 11-28-10, 04:01 PM

@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.

11-28-10, 04:01 PM	#649
Stiebler Fuel Supplier Join Date: Oct 2005 Location: London, UK Posts: 1,237 Downloads: 29 Uploads: 4	@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. __________________ NYGM Tonnage War Mod - More than a mod: it's an experience!