Realism- and gameplay-related hardcode fixes for SH3.EXE

[Hitman]

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.

That makes a LOT of sense

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

This shoudl suffice already to fix the weather bug

But if I might recommend something, then force windspeed=6 instead of zero after X time steps. The reason is that zero wind is a rare occurence in open sea, and 6 is instead OK for most seasons/locations.

Having the weather reset to wind=6, clouds=0, fog=0 every X time steps/weather changes would be good enough to solve all problems.

[Yoriyn]

Agree wind 6 is more natural.

[h.sie]

Okay, so I'll change my

h.sie's high windspeed convergence distortion algorithm V1.0beta

into

h.sie's advanced high windspeed convergence distortion algorithm V1.1

which does the following:

1) Reduces weather change period (WCP) by a factor of about 5

2) At the end of every WCP, when new weather is calculated, and with a chance of, say, 10%, I set windspeed to a rondomly chosen low value between 1 and 7 m/s.

h.sie

[Yoriyn]

Is a factor 5 not to big?

[Stiebler]

I have now carried out a fairly exhaustive analysis of that part of the assembler code which affects the wind speed, as identified by H.sie.

1. I can confirm H.sie's original finding, that under certain circumstances windspeeds of up to 30 m/s can be reached within this part of the code, due to a strange implementation of wind speed changes. This over-speed is limited by a simple filter to 15 m/s (as H.sie has already explained.)

2. The overflow of wind speed occurs when a high existing windspeed, say 13 m/s, is supplemented with a random result of around 0.8 or higher. (The value of the triggering random number to cause the overflow depends on the previous wind speed, obviously.) I could force overflow windspeeds of up to 29 m/s by artificially altering the start wind-speed value and the result delivered from the random generator.

3. The random generating algorithm creates a floating-point number between -1 and +1. These numbers are generated by the standard Microsoft randomising software algorithm (taking numbers from a published equation), and the results depend rather critically on the seed that is set for the algorithm. I discovered that the generator was providing clusters of similar random results over several calls. The custom is to set this random generator with a time seed at program start time, and then to keep taking subsequent random numbers with each call to the algorithm, so my observation might just have been a coincidence.

4. The wind-speed change code is very peculiar about handling negative numbers from the random generator. Why not just make negative numbers positive? Probably there is a reason, but it is not obvious.

5. The code which calls Microsoft's random generator is set in its own subroutine, and is certainly called by other SH3 routines. Therefore:
*It is essential not to alter this code in the randomising routine* (EnvAct.sim + 3290h). (That is, this subroutine must continue to deliver the same results, however seeded or limited.)

6. The obvious solution to the wind-speed problem is to scale the final output value (esi + 03D4h) before the limiter is reached. The scaling process should take the output value 'windspeed' and - for ALL values - scale it according to the formula:
windspeed = (windspeed * 15.00) / 30.00 ; 30 is the maximum that can be reached.
In other words, just divide the value by 2.
This will not only solve the problem of the overflows, but it will result in generally lower wind speeds, making storms rare. It is also simple to code!

There is certainly another consideration, that the bug occurs only rarely (but it is then persistent, since at 15 m/s already, a much lower random number suffices to cause an overflow of the windspeed). So perhaps use of the scaling factor should be restricted only for when the output wind speed would exceed 15 m/s, before use of the existing limiter.

7. And finally, we should prevent persistent high wind speeds, due to bug or an unhappy coincidence of high numbers from the random generator, with a return to some kind of default value as I have previously described in an earlier post - a 'repeat delimiter' reached after high wind speeds have persisted after too many calls to the general weather code. (I agree with others that a default wind speed of 6 m/s would be better than 0.)


This all looks fairly easy to code (especially for H.sie). Just a jump from near the end of the windspeed routine (envsim.act + DDBE) to new code placed at the end of envsim.act, and then a jump back to (envsim.act + DDD7), returning the corrected windspeed in the eax register. (Better still, why not store the final new wind speed value in [esi + 03d4h] and jump to the beginning of the next part of the code at (envsim.act + DDDD)?) The same new code can contain the repeat-limiter described in (7) above.

Having said all that, probably the easiest solution of all is to use the repeat-limiter of (7) above all by itself. It rather depends on what users really want - a corrected algorithm or a simpler fudged solution.

Stiebler.

[h.sie]

Hi Stiebler,

you obviously had a very good learning curve. Thanks.

3. The random generator creates not always a random number between (-1,+1) but much more between the two limits that have been push'ed on the stack in the 2 commands before the random call itself, so I did never plan to change the random routine. One only needs to put the upper and the lower limit on the stack and things go fine.

Syntax: (float)Rnd=Random32(float UPPER_LIMIT, float LOWER_LIMIT)

4. Yes these negative random values are funny and I didn't understand the reason. But I fear to simply build the absolute value. I would't touch that.

6. I could try to divide the windspeed by 2 for a special Stieber's edition, but I don't really like that overall-damping. I personally would prefer your idea of a forced low windspeed on a (randomized) but regulary basis.

Then we can compare these 2 approaches and take the better one.

Greetings,
h.sie


Edit: If I remenber right, there were TWO limiters to [0,4999....15] without exactly knowing the reason for that. So we must be careful by finding the correct exit/entry-point for our patch.

[Yoriyn]

So how many versions of EnvSim file can we expect?
I already counted 4

- 2 normal and 2 special (yoriyn and stiebler)

Can I ask for another special for my mum

[Magic1111]

Originally Posted by Yoriyn

Can I ask for another special for my mum

[h.sie]

There is a problem: In order to count the weather change periods for forcing windspeed=low on a regulary basis, I need write-access memory to store the counter. At the moment I'm not able to get write access in the memory environment of EnvSim.act.

There are 3 solutions:

1) I find a way to get write-access. Maybe possible.

2) I don't use a counter. Then, the forcing windspeed=low can only be done on a random basis, let's say, with a chance of 10% every time new weather is calculated.

3) I use my special memory area in sh3.exe, which I created for my fixes. This would mean, EnvSim.act works only with patched sh3.exe.

I prefer solution 2 at the moment.

[Magic1111]

Originally Posted by h.sie

I prefer solution 2 at the moment.

Yes, me too ! In my Opinion is Solution 2 okay !

Best regards,
Magic

[Stiebler]

@H.sie,

Yes, solution 2 is OK for me, but it can be implemented in two ways:

a) apply the probability of a wind speed change only when the wind is > (say) 12 m/s. Then you need perhaps 10% or 15% probability of change.

b) apply the probability of a wind speed change every time the wind speed code is called. In that case 5% probability will be unnecessary most of the time, but too little when the wind does reach 15 m/s.

I think option (a) of the above is better (if it is not too complicated to code - I presume you are thinking of making an inline code change, rather than a jump to a new code section?).

I'm not clear about the write-access difficulty for the weather-'counter' that you mentioned.
1. Would there be a problem if everyone runs SH3 with administrator rights, or if they install SH3 outside 'program files'? My own copy of SH3 is installed in C:\Ubisoft\SilentHunteriii, and gives me no trouble.
2. It is certain that the 'counter' will not need to exceed 255, so you can use a byte for data storage. Even if the byte cannot be set when the game is loaded, just start from whatever random value is found in byte 'counter'. If you plan to use a lower maximum in counter than 255, reset it with inline code to zero whenever the value of counter is found to exceed your maximum. You could even re-use one of the existing data variables, since it is evident that some are used effectively as constants. The constants can be made constant in the code, freeing up the variable for reuse.

Good luck, anyway.

I shall not be able to do any more work on this wind problem until Tuesday.

Stiebler.

[Yoriyn]

I think option 2 is ok as well. But 10% is much to much.

If you want to use factor 5 to weather intervals, it's mean we have weather change about every 8h (40:5=8).

Theoretically 10% means after every 10 changes this chance is rolled (10x10=100%). So 10x8h=80h of bad weather. 80h/24h=3,3days so maximum storm duration is 3,3 days.

Chance 3% means after 33 weather changes chance is rolled (3x33=99% almost 100). So 33x8h=264h, 264h/24h=11days. So maksimum storm duration is 11 days.

Of course all this calculations give us only mathematical probability and change can be rolled even after first occasion or never. But showing most probable situation.

[h.sie]

@Yoriyin: These values (10%) are intended only as a first approach. Then long-time tests have do be done in order to see if this approach works in principle and in order to eventuallly fine-adjust some parameters like probabilities.

@Stiebler: It's not related to file system security. In Memory Map of Ollidbg2 you see some flags which determine how the modules of sh3.exe and dll's are loaded. EnvSim.act e.g. is divided into several sections (PE-header, code, data, ressources, imports). Only the data section has write permission. I could use it for my counter, but who guarrantees that my single counter byte is not overwritten by other data? That is, because assembler patching does not go the (correct&secure) way by allocating memory, as one does in C++, because it would be too complicated - at least for me. so my counter is not protected from being ovrwritten in that data section. A simple common used way for patching is to add / expand a special data section with write access as I did at the end of sh3.exe. That data cannot be overwritten, simply because sh3.exe does not know about that additional data area, where my fixes and data are located. I tried to do the same with EnvSim.act, without success, because I didn't manage to change the PE header and the access flags accordingly.
Only way out: Use expanded data section from patched sh3.exe, but then you HAVE TO USE patched sh3.exe.
Other way out: Writing code without the need to store data as I try by randomly set windspeed=low instead of using a counter.

h.sie

[Hitman]

I prefer the "other way out". While it is good to encourage all people to buy the official starforce free SH3, this simple fix (And it is a true fix) to the weather should deserve a wider public.

[irish1958]

Originally Posted by Hitman

I prefer the "other way out". While it is good to encourage all people to buy the official starforce free SH3, this simple fix (And it is a true fix) to the weather should deserve a wider public.

Second the motion