Realism- and gameplay-related hardcode fixes for SH3.EXE [Archive] - Page 3

SkyBaron

11-18-10, 10:44 AM

I was going to suggest the same thing about external torpedoes! Maybe the u-boat could be unable to dive until the external reserves are reloaded? Something with the message "Cannot comply!" if you command a dive. That would make you more vulnerable to aircraft attacks while reloading.

I have a couple of more suggestions but I'm not sure if they are possible to implement with assembly:

- Treat convoy radio reports as radio messages reducing TC to 1 and playing the Morse sound whenever you receive them - SH3Commander has an option to reduce TC but it doesn't work all the time. This is important if you want to plot an accurate interception course but are traveling in higher TC.

- Get rid of the unrealistic "She's going down!" message. This might trigger other stuff(ship sunk symbol on the map, renown for the ship, logbook entry etc..) so I'm not sure about this one.

Thanks again for all your work h.sie!

h.sie

11-18-10, 03:49 PM

h.sie

11-18-10, 03:58 PM

Hi New Captain,

thanks for the suggestions. but wouldn't it be more realistic to kill e.g. the bridge crew and remove / destroy the uncompletely loaded torpeodoes when dive is ordered during external reload?

Isn't the "She's going down" message only a text message. this could easily be disabled/hidden by editing of en_menu.txt

Change
4140=She's going down!

into:
4140=

Draka

11-18-10, 11:37 PM

The whole problem about diving once the externals are being loaded, is that the hatches to the torpedo rooms are open - and the torpedoes and the associated gear is in the way so they can't be closed. Needless to say, diving with open hatches is definately NOT the hot setup ......

The variable is just how long it would take to either complete getting the eel in, or pulling it all the way out - and then jettisonning all the gear used for the purpose. Neither option is quick, and depends mightily on just how far along in the process you are when you get jumped by the aircraft.

Edit: check out these pix:

http://www.usscod.org/torpload.html

h.sie

11-19-10, 01:58 AM

Thanks for that important information, Draka

Stiebler

11-19-10, 05:05 AM

I would like to expand on H.sie's reply by pointing up that many of the fixes requested by other users are actually unnecessary. Unnecessary, because if the player thinks that they are important then the player can act on them himself.

The reloading of external torpedoes is the obvious example. If anyone thinks that torpedoes should not be loaded at wind speeds above 6 m/s, then check the weather before reloading, and don't reload if the wind speed is above 6m/s! If anyone thinks you should not be able to dive at once if surprised on the surface while reloading the torpedoes, then don't dive until a sufficient time interval has elapsed! (I always allow 10 minutes to 'jettison' the torpedo). [Incidentally, I once asked an old U-boat sailor what the emergency procedure was if the U-boat was suddenly surprised on the surface by a fast-closing destroyer. He said there wasn't one, and he had no idea what anyone would have done if it had occurred. He never heard of a single instance of it occurring, since you only reloaded in remote areas.]

It would be much more useful for everyone if the talented H.sie devoted all his efforts to things which can NOT be fixed by the player himself. Obvious examples are the CO2 problem (which he has done), the too-accurate range reports (which he has done) and similar.

The most useful improvement of all would be to fix the weather bug, which causes persistent protracted storms with zero visibility. The devs made a very complex algorithm for SH3 - too complex, as it turned out - which they no longer understand themselves. What is needed is a much simpler replacement for the broken code. Being simpler, it would be shorter, and thus could patch the existing code as an overlay.

All that is really needed is an algorithm that moves the wind randomly up and down in small increments, and moves the rain up and down when the wind is sufficiently strong, and which reduces the visibility when the rain is sufficiently high. This might not be as clever as that of the original SH3 code (which took into account seasons and latitude), but would be much more useful.

That part is easy. What is not so easy is to locate the damaged code (I've tried). If H.sie can find the code, and discover its extent (that is, what subroutines it uses and the start and exit points of the weather routine) and can understand the parameters it uses (we would need to know what triggers a call to the routine, and how often it calls, as well as which variables control the input and output clouds, rain and visibility), then the replacement coding would be trivial.

Stiebler.

Hitman

11-19-10, 09:16 AM

It would be much more useful for everyone if the talented H.sie devoted all his efforts to things which can NOT be fixed by the player himself. Obvious examples are the CO2 problem (which he has done), the too-accurate range reports (which he has done) and similar.

I agree completely :salute:

Draka

11-19-10, 09:46 AM

I agree to a point - some things are more important and prioritiy setting is a prime function of any programmer's time. However, there are some things that are either not well understood, or not easily referenced and thus the interest in hardcoding realistic behavior into the Kaleun's decisions.

The reloading of externals is just that - as the saying goes, I know just enuf to be dangerous! I have seen photos (on this site) on this in action and have done some engineering tasks with heavy loads, shear legs and tackle on dry land as an combat engineer, so can somewhat envision the same on a moving deck - but can't find any solid references on this anywhere. So I make suggestions and look for assistance, and help such be applied for those others with the same wish to be accurate yet with the same lack of knowledge.

It is similar for the effect of movement on an extended periscope - I lack the sources for a firm knowledge yet can envision the effect of a slender column being forced thru a dense medium (water), yet have no exact knowledge of the exact effect at the various speeds/wave states/etc it would encounter. Again, suggestions and then acceptance of whatever is coded into the sim.

This from an army guy with fairly good knowledge of history, military matters and such and yet only a small amount of actual sea-going experience (sailing small craft in San Francisco Bay).

h.sie

11-19-10, 10:34 AM

I've never seriously played SH3, except for modding purposes, so I cannot judge, how important the changes to the weather system are. But I tend to trust Stiebler and Hitman when they say that it is important. On the other hand: I don't like to be able to cheat the sim. Masochistic as I am, I want to be penalized if I made a wrong decision, e.g. to order a crash-dive while reloading externals or provoke a collision with a destroyer in order to sink him....:haha:. Bru-har-har.

Unfortunately, I have a job and social contacts, so I only have 1-3 hours a day for modding.
Thus, I can/will only do fixes that are:

Hopefully realistic AND halfway easy to fix.

The weather system surely isn't easy to understand and fix. Although I am pessimistic that I'll be successful, I'll try it. But I need help. After successfully finding the code, I'll need an alternative weather algorithm. This I cannot program on my own.

But let me first find the code and the variables and we'll see what the future brings.

Is the weather in SH4 better as in Sh3??

Maybe sh4.exe could inspire me :D

h.sie

Dani

11-19-10, 11:12 AM

If you gonna look at sh4 exe, maybe you could fix the submerged ranges,recharge time for batteries and CO2 for Operation Monsun.:D

ryanwigginton

11-19-10, 12:17 PM

I don't like to be able to cheat the sim. Masochistic as I am, I want to be penalized if I made a wrong decision

I agree completely. Stiebler you are probably one of few who have the knowledge of subs to know 'the rules' and the discipline not to break them. I think most would rather have the rules enforced by the program. That way everyone that installs the patch is forced to play in a realistic manner with realistic consequences, regardless of their knowledge of what a sub is and isn't capable of.

On ordering a dive during torpedo loading, could you make the sub flood at a very high rate? I hazard a guess that a dive could still be made, it just wasn't very smart!

Magic1111

11-19-10, 05:27 PM

New Version online: V15D_BETA3.

For details see:
http://www.subsim.com/radioroom/showpost.php?p=1530834&postcount=458

Tested on WinXP/32 Bit and Win7/64 Bit.

Bugs addressed:
1) CTD on some systems during game loading.
2) Instant fatigue of crew when snorkelling.

Could not reproduce an reported error, in which Free Cam (F12) also shows blur effect when submerged speed is above 4,5 knots.

Hi h.sie !

From me a short Test-Report of the Version V15D_BETA3:

I´ve Win 7 64Bit !

First Test: All Naval Academys works fine, no Problems !

Second Test: I load the Museum, after loading complete I see for a little Moment the first ship (by a little darker screen then normal) and then the game crashed to desktop ! I repeat this Test four times, each time with the same result (CTD). No chance to go into Museum !

Third Test: Loading Museum with patched sh3.exe, but without
the File "CameraBehavior.act", same result (CTD after loading, I see for a moment a ship from Museum, then CTD, not during loading).

Forth Test: Loading Museum with your Patch V15C, all is okay and works fine, the same without any patch from you !!!

All Test with the same MOD-Order in JSGME !

Hope that information helps you a little bit !

Best regards,
Magic

Myxale

11-19-10, 05:28 PM

First off, I don't know how possible at all this is, but is there an easy way to unlock or free up places / Slots for more subs:88)?

Up till now we have to replace one to get the other!

Is this within the probable?

h.sie

11-19-10, 06:04 PM

@Myxale: That's not possible in an easy way. Sorry.

@Magic, thanks for beta-testing and help. I must admit that I didn't test the museum - I even never started it until now, and yes, I could reproduce your bug report. I didn't consider the case that there is no player Uboat at all.

This bug only affects the museum and I've already fixed it. Will be implemented in the next version.

h.sie

Magic1111

11-19-10, 06:11 PM

[QUOTE=h.sie;1538646

This bug only affects the museum and I've already fixed it. Will be implemented in the next version.
[/QUOTE]

Okay, thanks ! That means, I can play my career with V15D_BETA3, right ? ONLY the Museum crashed, right ?

Best regards,
Magic

h.sie

11-19-10, 06:23 PM

Hi Magic,

Yes, that specific bug occurs only when there is no player Uboat: the museum. but since the changes for V15D were complex, I cannot guarrantee that there are no more bugs, although I did many tests, but I could not test all situations. for example, I would never think about to test the museum.

If I were you, I would not play a career with a beta. V15C is stable.

h.sie

makman94

11-20-10, 12:08 AM

H.Sie,

just to confirm...everything works as intended now with the last patch you released !
one question : if i don't use the camerabehaviour.act will that 'break' anything when using your .exe ?

two wishes (if possible will be extremely good news for me):

a) fix the algorithm that is screwing the reflections on water and appearing this UGLYYYYY ''polygon effect'' !

b) this one ....oh will be fantastic if possible : make the ruler showing ALWAYS (not only during the line) at its end the EXACT DISTANCE of drawn line. i have some more ideas about the ruler but just tell me first if this is possible to be done as far as you can know.
(maybe this will help a little : at sh5...the navigator's plotting lines are 'acting' like this ....they show always the exact distance)

bye

h.sie

11-20-10, 06:13 AM

In the data section for the weather I found variables for wind speed, wind direction and an constantly increasing time-counter.

if I manually (using my debugger) set the time-counter to a much higher value, I can immediately trigger the start of a weather change.

this does not mean that I already solved the weather problem, but that I have a chance of lets say 20% to be able to solve it.

wouldn't it be enough to simply shorten the looooong periods of constant weather?
wouldn't this be an effective and perhaps easy to do fix???

so we could furtheron use the complex weather algorithms of SH3 but with shorter changing periods!

h.sie

11-20-10, 06:28 AM

call me "Petrus" in the future, because (at least in Germany) Petrus is resonsible for the weather!

h.sie

11-20-10, 06:40 AM

@Makman:

Thanks for testing!

If you don't use the patched CameraBehavior.act, you'll not see the blur-effect when submerged speed > 4,5 knots. That's all.

Regarding Polygons: That's graphical stuff I fear to touch. Much too complex and very hard to locate the code without SDK. I must admit I never saw any polygons and I don't know what people talking about.

I don't even know what a "ruler" is. But after working through my over-full to-do list I'll look into that problem. how important is that?

h.sie

h.sie

11-20-10, 06:56 AM

I just triggered some weather changes. looked very nice in high TC. seeing clouds appear and disappear, rain, sun storm and so on.

but then I had a funny situation: rain without clouds.

did that ever happen in stock SH3?

CherryHarbey

11-20-10, 08:33 AM

h.sie

11-20-10, 08:45 AM

Deleted

Hitman

11-20-10, 09:23 AM

wouldn't it be enough to simply shorten the looooong periods of constant weather?
wouldn't this be an effective and perhaps easy to do fix???

so we could furtheron use the complex weather algorithms of SH3 but with shorter changing periods!

The main problem with the log periods of constant weather is that they were only with bad weather. Fair weather started, then got worse ... and stuck worse. Stiebler managed to provide much longer periods of good weather, and specially a tendency to return to good weather by setting starting weather conditions in campaign files to zero wind, zero clouds, zero rain, zero fog. It seems that the real bug is that once the game gets the signal to roll the dice and make a weather change, the dice tends to always come up with "worser"

But it is worth a try if the fix you can do is as simple as reducing the weather change interval.

Here you find a patched EnvSim.act with a very short weather change interval of 2 hours instaed of 40 hours:

Does this mean that the weather is encoded there, and not in the SH3.exe?

h.sie

11-20-10, 09:35 AM

yes, weather is in EnvSim.act, at least some important routines.

with the patched EnvSim.act, I run Sh3 in TC=128 and watch the weather. looks good. every 2 hours a random weather change is triggered, but in some cases weather stays constant (that's just random). weather changes from bad to good to bad to good all combinations are there. rain, fog, storm, thunderstorm, sun.

I see no need for further modifications, except for fine-adjusting the weather change interval, which I chose to 2 hours for demonstration purposes.

only issue: I once saw rain without clouds. but that cannot be related to my fix!!(??)
maybe noone saw such a situation, because weather changed so seldom?

irish1958

11-20-10, 09:50 AM

I can't find the download link for this mod. When I pull up the mediafire link, it is not listed. (I am using Chrome.)

h.sie

11-20-10, 09:58 AM

Hi irish, see here:

http://www.subsim.com/radioroom/showpost.php?p=1538886&postcount=524

Should also work with unpatched sh3.exe.

Stiebler

11-20-10, 10:52 AM

@H/sie,
yes, weather is in EnvSim.act, at least some important routines.

with the patched EnvSim.act, I run Sh3 in TC=128 and watch the weather. looks good. every 2 hours a random weather change is triggered, but in some cases weather stays constant (that's just random). weather changes from bad to good to bad to good all combinations are there. rain, fog, storm, thunderstorm, sun.

I see no need for further modifications, except for fine-adjusting the weather change interval, which I chose to 2 hours for demonstration purposes.Well, brilliant work! It shows the power of imagination, it never occurred to me to look for the weather routines outside the main SH3.exe code.

However... it will take more than a change to the time updating to repair the weather routines. What I found, for the Real Weather Fix, was that the faster the weather changes, the more it finally sticks at 15m/s, heavy clouds, heavy rain.

[Edit: Click on this link for my account of how SH3 handles the weather:
http://www.subsim.com/mods1/nygm/nygmweatherreport.zip ]

Stiebler.

h.sie

11-20-10, 11:33 AM

@Stiebler: Thanks. I' ve run SH3 the whole afternoon in TC=128 and I discovered a balanced weather mix - too good in my opinion for atlantic theatre. no sticking on windspeed = 15.

Edith: Ok, in the last time I discovered that windspeed=15 occurs more often than other windspeeds......

Magic1111

11-20-10, 02:03 PM

If I were you, I would not play a career with a beta. V15C is stable.

h.sie

Aaaah, okay, thanks for clarify this h.sie ! Yes, I continue my career with V15C, because during career I need a stable working MOD !

Best regards,
Magic

h.sie

11-20-10, 02:22 PM

After my 1st day working with weather the following is clear now:

1) There is a seconds counter that counts up to a certain maximum value (about 160000 seconds = 44 hrs). This max value represents the weather changing time period.

2) This max. value varies a little bit and surely depends on the settings in scene.dat and campaign files.

3) If the seconds counter reaches the max. value, the counter is reset to 0 and a certain routine (which I already have located) is called which sets new weather settings (windspeed and so on).

4) Then the current weather slowly adjusts to fit the new weather settings.

In the next time I'll set the weather change interval to 1 h or less in order to long-time-record the windspeeds generated in order to see if really windspeed=15 dominates.

If so, I'll try to patch the routine which periodically generates new weather and reduce windspeed a little bit so that we have a homogenuous distribution of windspeed.

Draka

11-20-10, 02:29 PM

Ya'll SURE ya'll don't have a copy o' th' SDK in yer possession??!!?? Ya'll are workin' WONDERS - keep this up and we'll really have a true simulation!

Magic1111

11-20-10, 02:51 PM

Yoriyn

11-20-10, 02:54 PM

h.sie: What setting/configuration/mods you using, cos your modified envsim.act cause no weather change even after week in my game :(

h.sie

11-20-10, 02:58 PM

clean (hopefully) gwx . currently no mods

have you moved the original file away from the sh3 install dir? this is important.

Yoriyn

11-20-10, 03:15 PM

Yes I made one copy of old one to new folder and overwrite it with new one.
Are you doing tests in campaign mode or single mission?

h.sie

11-20-10, 06:05 PM

only single mission. but I tested campaign, too. and it works.

h.sie

11-20-10, 06:22 PM

Hitman

11-21-10, 03:23 AM

Here are some windspeeds generated at the beginning of the weather change interval:

Indian Ocean , March 1944
15/10/14/15/15/11/15/8/12/13/0/0/8/15/4/15/15/14/15/5/15/15/11/
0/15/15/11/10/15/11/14/15/12/0/7/4/3/15/9/12/7/1/8

Arctic Ocean, December 1943
7/7/15/15/15/15/15/7/15/15/7/15/7/15/15/15/15/15/15/14/
15/15/15/7/11/15/7/7/7/7/9/15/15/15/7/10/15

Koenigsberg, March 1941
0/4/0/6/6/0/6/6/0/0/0/6/6/6/6/6/6/0/0/6/5/6

North Atlantic, April 1940
15/8/0/0/15/12/2/15/15/12/15/13/15/14/9/15/15/14/11/4/0/11/
15/8/15/5/8/12/8/15/4/3/0/10/15/7/15/15/14/5/15/8/15/4/
8/13/15/15/15/15/13/11/0/0/0

Windspeed=15 seems to be too often. Maybe one should replace 50% of the 15 by an randomly chosen value.

It depends on the zone and season, of course. Frequent 15 winds for the Arctic, North Sea and northern part of the North Atlantic from October to May is not really that bad. In fact it is quite realistic, and you must remember that 15m/s is not the strongest possible wind by far. In fact it is the wind for a quite rough sea, but not for a huge storm.

Looking at the numbers you posted, it seems that the logarythm is working more or less well, only that it sometimes gives too strong wind in the Indian Ocean, f.e.

The problem comes when rain and fog are added to that 15 m/s wind, as happens usually. With strong winds and high waves (Waves can be easily modded and many environmental mods have detuned consideraby their size) you can still attack, but fog and rain kill the visibility and make it almost impossible.

I don't know if you would be able to fix that, making fog and rain less frequent. Specially, the heavy fog should only appear in areas where warm/cold water meets warm/cold air, like Northern Sea, Ireland, Terranova, etc. and not the centre of the Indian Ocean or the Atlantic!

Can you post the statistics for the generated fog/rain in those areas?

Yoriyn

11-21-10, 03:41 AM

I can say after my readings wind 0m/s is very rare phenomena at sea , more frequent only at 30deg latitude on both hemispheres.

h.sie

11-21-10, 05:34 AM

As one could see in the past, every little code change has the potential for errors (3 bugs in V15D). In Assembler you can easily lose overview. Obvious errors (CTD) are okay, because you can see and eliminate them. but the real problem are invisible side-effects which always are possible even if one works accurate as I do (mostly).

So I tend to make as few changes as possible, hopefully with acceptable results. And only if these easy fixes don't work, I must go the next step in complexity in order to reach the aim.

Reducing weather change interval was such an easy change. I think we should give this little change a chance. According to my observations weather changes are well balanced and homogenuous with some short-time sticking on high windspeed. Where is the problem with that? Because with the much shorter weather change intervals these nasty time periods with wind=15, fog and rain are much shorter now!

In Stieblers NYGM-weather report I could read that the devs - EVEN WITH SDK - lost overview over their weather algorithm. So how should I achieve overview WITHOUT SDK?

Since the time counter always starts at 0 when reloading a game, you had to wait 40 hours in the past for the first weather change after loading a game. now the weather change comes much earlier.

So although I fear very much to make deeper code changes, I try to achieve a better understanding of the complex weather routines. I am not yet able to locate the variables for fog and rain, but I think that's only a quesion of time.

By the way: Could someone provide a better weather algorithm, especially in C/C++??

h.sie

Yoriyn

11-21-10, 05:48 AM

So maybe good compromise is set the weather change intervals to 10-12h. This should create half shorter storms with chances to weather change twice a day.

h.sie

11-21-10, 06:04 AM

@YoriYn: Does it work for you now?

h.sie

11-21-10, 06:14 AM

@Hitman: After loacating rain and fog variables I can post some statistics.

Stiebler

11-21-10, 06:36 AM

I'm very glad to see that H.sie is making progress with this, and that others are willing to test his work with published results.

I have some general observations to make:

1. For testing:
a) I found, with the RealWeatherFix, that the best way to test is to take a IXD2 boat down to the equator (where weather changes occur more often) and then cruise around at tc=1024x. Sail out of France in late 1942 at 2048x tc to avoid most or all air attacks in the Bay of Biscay, then cruise down to the equator, taking readings every 24 hours of game time. That really sorts out when you are getting protracted 'rainy-storms' (15 m/s, heavy rain, heavy fog).
b) It is essential to test in campaign mode. Mission mode is supposed to use its own weather parameters. I don't think it does, due to a bug, but I might be wrong, so why take the chance? Test in campaign mode. That is how everyone plays SH3.

2. Envsim.act.
I've examined this now as best as I can. H.sie is right, this is where all the weather parameters are stacked. However... the subroutines are all short, just changing a couple of parameters, and then call subroutines elsewhere, probably in sh3.exe.

This is really inconvenient, since it means we cannot just slice out a section of buggy code and replace it with fresh code. It becomes necessary to understand the function of each subroutine, and then (perhaps) to replace it without any real understanding of the interaction with the bulk of the weather code that it replaces.

I don't know why the devs did things like this, although there must have been a reason.

3. Replacement C/C++ code.
H.sie asked for replacement code. I'm an AI programmer (AI = Artificial Intelligence) and I could easily write a replacement weather code (not as sophisticated as the original, but less tiresome in its effect) as a chunk of code, but, as stated above, how would you fit it into the existing code? (which also includes sun halo effects, boat shadows and so on.)

Maybe if H.sie could isolate that part of envsim.act that affects ONLY the weather, then we could just redirect the pointer to my code, attached to the end of the envsim.act as a discrete chunk. That might work (if we knew to what point my code should return to the original without being overwritten afterwards), but I suspect from what I have seen that this will affect lots of other parameters too. We would see many unwanted effects that are also controlled by envsim.act.

So everything depends still on H.sie. I must confess that I am also nervous about what Ubisoft lawyers might think about my recoding proposal, although clearly there is no intention to deprive Ubisoft of royalties, nor to steal Ubisoft's programming secrets. Meddling with their code is substantially different from changing the values of parameters.

@H.sie:
When I tried yesterday, I could not find either your V15D beta mod, nor your revised envsim.act file on your mediafire page.

Stiebler.

Yoriyn

11-21-10, 06:44 AM

h.sie: I reinstall my SH3 once again, deleting all old files. But have the same problem on the stock game with your v15d patch. Are you sure you put good file EnvSim.act to download section?

Other thing is, can you create bigger wind then 15m/s, cos 15m/s is moderate wind.
Look here:
http://en.wikipedia.org/wiki/Beaufort_scale

casso

11-21-10, 07:15 AM

Hi H.Sie
I like the idea to change weather code, and as Yoriyn said I have that question too - is it possible to code wind speeds above 15m/s for example to 25m/s (which is 10 on Beaufort scale and when the real storm begins) ? Or is this much more complicated than I can imagine ?:DL

Volk2

11-21-10, 07:36 AM

I like the idea to change weather code, and as Yoriyn said I have that question too - is it possible to code wind speeds above 15m/s for example to 25m/s (which is 10 on Beaufort scale and when the real storm begins) ? Or is this much more complicated than I can imagine ?:DL

Lets focus on the weather problem for now. The constant fog/zero visibility case is much more important. Anyway, the sea at 15m/s looks ok in game, there could be possibly engine/graphical problems with the sea and ship behaviour on 25m/s, like the old sinking ships problem, weird looking waves or u-boat flying above water...

Yoriyn

11-21-10, 08:01 AM

Wolk (sorry for translate you name, but I can't write in cyrillic on my PC): You right !!!! Anyway all decisions depends from h.sie :D

Or maybe the weather stick to 15m/s because game can work on variables above 15, and all variables above 15 are limited to create 15m/s wind. Maybe developers create artificial 15m/s border to prevent above (Wolk writed) problems.

casso

11-21-10, 11:24 AM

If you remember, there is wave height paramter in SH3C, so what you think about doubled wave height when wind speed is above 15m/s? If it's impossible to code speeds above 15m/s maybe make current rough 15m/s sea state appear on 14m/s and at 15 make waves two times bigger to simulate real storm... then if it could be possible too, make WO to report no 15m/s wind but 25m/s.
I was running SH3 for a while to test 2x waves and I didn't see any problems with ships behaviour and graphics.

makman94

11-22-10, 03:02 AM

H.Sie , the envsim.act you uploaded is crashing (maybe is an issue again for the win 7 ?)

seriously now .....you don't know what the ruler is ? Anyway , i will get back to it when you relax a little bit after all these requests-wishes (that some of them are really interesting to be fixed .....such the weather for example)

@Stiebler : when you say ''...zero vissibility...problem'' what exactly do you mean ? i am asking this becuase some settings at sensors and at scene.dat (fog settings) are also responsible for the game's behaviour there

h.sie

11-22-10, 03:18 AM

@Stiebler: Thanks for your detailed information.

1) Tests, SingleMissions & Campaigns:
So in the future I'll test mainly in Campaign mode. Never thought that weather is different in single missions, because I see no reason for that. But now I really discovered a shorter weather change period in campaigns.

2) Envsim.act:
Yes, the code is complex and often interacts with code from other dlls and so it is no good idea to bypass or replace it by our own algorithm. Too dangerous. But there is a little chance left:

Every time the time counter reaches the weather change period (which I can reduce), a certain routine is called which calculates a New_Weather (New_Windspeed, New_Winddirection, New_RainIntensity, New_FogIntensity, New_CloudsIntensity). Then, in the following time, the Current_Weather (Current_Windspeed, Current_RainIntensity and so on) slowly adjusts to New_Weather. New_Weather keeps constant until it is changed at the end of the change period.

At the end of this New_Weather routine I could place a jump command to a code section in order to make some corrections, especially for New_FogIntensity (and maybe New_Windspeed) and than jump back to the original code.

But unfortunately, currently I can only arbitrarily manipulate New_Windspeed, New_Winddirection and New_RainIntensity, but not New_FogIntensity and New_CloudsIntensity. But with a little luck I'll find the variables responsible for New_FogIntensity.

3. Question:
Wouldn't it be enough to
a) shorten the weather change period (already possible)
b) correct New_Windspeed (already possible)
c) correct New_FogIntensity (not yet possible) ???

5. Windspeed:
The internal algorithm for windspeed calculates an emphasis factor (depending on season, region and so on) and multipies this emphasis factor with a random number. The result lies between 0 and sometimes more than 20m/s. But later the values are delimited to [0,499.....15m/s]. We should not change that -> Side effects. But that's the reason why windspeed sticks at 15m/s; the algorithm is overdriven in some situations.

6. Weather report:
Funny: Weather report always relates to New_Weather and NOT to Current_Weather. So if at the beginning of a new weather period Current_Weather has not adjusted to New_Weather, you get a wrong report.

h.sie

Yoriyn

11-22-10, 03:57 AM

I agree with Makman94, after downloading and using MEPv3 even zero visibility is not that bad, so I'm sure we can make fog manipulation.

h.sie: Can you "unlock" stronger wind in the game?

Stiebler

11-22-10, 04:42 AM

@H.sie:
At the end of this New_Weather routine I could place a jump command to a code section in order to make some corrections, especially for New_FogIntensity (and maybe New_Windspeed) and than jump back to the original code.
Now that is a good idea, which will probably solve all problems if you can work out the remaining issues with the fog intensity and cloud intensity.
3. Question:
Wouldn't it be enough to
a) shorten the weather change period (already possible)
b) correct New_Windspeed (already possible)
c) correct New_FogIntensity (not yet possible) ???If by 'correct' you mean 'change to a different constant setting', then I doubt if that would be enough to improve the weather by itself. (But it is worth trying first, of course.)

@Makman, Yoriyn:
When I wrote 'zero visibility', I wrote too carelessly. I meant the visibility that follows after heavy rains and heavy fog, which is too low/short to make attacks on convoys or even on single ships unless you are very close (< 1,000m). I intended no criticism of the poor visibility; my criticism is of the frequency with which this happens due to poor weather control.

@General:
Like Makman, I found that use of H.sie's new envsim.act file caused a crash in second-stage loading (after the main menu appears, and the player starts a patrol). I am also using 64-bit Windows-7. This occurred with an un-modded form of the 4GB_Sh3.exe that I have been using for some time now without problems.
In my case, it was a very serious crash, that apparently corrupted at least one other key file. I had to copy over a clean install from another drive and start again.

Stiebler.

h.sie

11-22-10, 05:08 AM

I apologize for any problems my work makes. These problems are not intended. I understand my work as WIP (Mod Workshop!!) and thus problems can occur - they are almost naturally when working with Asm in different OS. So people who fear CTDs should not use my patches - or they should make tests only with an second Installation of SH3 as I do. A CTD is not that worse. It's only that the EIP (instruction pointer of the CPU) doesn't know where to go......:D.

USE ON YOUR OWN RISK!

Time to update my first post.

h.sie

11-22-10, 05:28 AM

@Stiebler:

No I did not mean a different constant setting. I had random changes of fog in mind.

Yoriyn

11-22-10, 05:44 AM

H.sie: Can you try to upload new EnvSim.act with 12h (or any other) weather change intervals time? Cos last one (with 2h) causing constant weather for me (no change).

h.sie

11-22-10, 06:18 AM

@Yoriyn: Currently not, since work is still in progress. If I'm ready, I'll hopefully upload one working bugfree version.

I am sorry for not being able to fulfill individual wishes. In order to not drive crazy I have to focus on one topic at the time.

And I also apologize for not responding to requests for individual wishes (which normally is not my style).

h.sie

Yoriyn

11-22-10, 06:43 AM

Don't worry about my wishes, I'm very happy of progress you made in the game modification. Just can't wait when you make another big step to fix a weather :yeah:

Magic1111

11-22-10, 06:49 AM

H.Sie , the envsim.act you uploaded is crashing (maybe is an issue again for the win 7 ?)

@General:
Like Makman, I found that use of H.sie's new envsim.act file caused a crash in second-stage loading (after the main menu appears, and the player starts a patrol). I am also using 64-bit Windows-7. This occurred with an un-modded form of the 4GB_Sh3.exe that I have been using for some time now without problems.
In my case, it was a very serious crash, that apparently corrupted at least one other key file. I had to copy over a clean install from another drive and start again.

Stiebler.

Hi h.sie !

I´ve become the same CTD using the envsim.act (Win 7 64Bit) !

Best regards,
Magic

h.sie

11-22-10, 08:21 AM

Every CTD pains me. And I must say "thank you" and "sorry" to those who anyhow help me with testing. But it shows that I have to restrict on only essential fixes in the future. no eyecandy, no "nice-to-have".

Stiebler

11-22-10, 12:04 PM

@H.sie:
5. Windspeed:
The internal algorithm for windspeed calculates an emphasis factor (depending on season, region and so on) and multipies this emphasis factor with a random number. The result lies between 0 and sometimes more than 20m/s. But later the values are delimited to [0,499.....15m/s]. We should not change that -> Side effects. But that's the reason why windspeed sticks at 15m/s; the algorithm is overdriven in some situations.This is a very valuable discovery.

Surely this is the first point to fix: emphasis-factor x random-number can give more than 20 m/s.

Redistribute - do NOT create an upper limit! - the random number so that >15 m/s cannot be achieved. For example, if the random numbers are in the range 0-255, but a random number > 200 results in wind speeds > 15 m/s, then multiply all random numbers produced in this part of the code by 200/256.

This will require a jump out of the code to a few lines of assembly at the end of the code, then a jump back to the exit point. Can you show a few lines of the key assembly code in this forum-thread? (with comments about which variables are referred to?).

Stiebler.

Gammel

11-22-10, 02:08 PM

Yoriyn

11-22-10, 02:18 PM

I have the same problems on moded version, but can't reproduce this problems on stock (clean) game.

CherryHarbey

11-22-10, 02:29 PM

@H.sie:
This is a very valuable discovery.

Surely this is the first point to fix: emphasis-factor x random-number can give more than 20 m/s.

Redistribute - do NOT create an upper limit! - the random number so that >15 m/s cannot be achieved. For example, if the random numbers are in the range 0-255, but a random number > 200 results in wind speeds > 15 m/s, then multiply all random numbers produced in this part of the code by 200/256.

This will require a jump out of the code to a few lines of assembly at the end of the code, then a jump back to the exit point. Can you show a few lines of the key assembly code in this forum-thread? (with comments about which variables are referred to?).

Stiebler.

or alternatively take two random numbers between 0 and 16 and multiply together. Maximum value will still be 256 and answer from the range 0 to 256 but skewed towards the lower end.

h.sie

11-22-10, 05:26 PM

@Gammel, Yoriyn: Thanks for response. I tried to reproduce your sound issue on Win7/64 and WinXP/32. I chose a XXI in 1945. Started snorkelling. In the modded game I could hear the diesel sound for about 20 seconds while going Full ahead, but then engines are limited to 1/3 ahead - diesel sound disappeared almost completely. But the same happened in unmodded sh3.exe when I manually reduced speed to 1/3 ahead: diesel sound disappeared almost completely.

I also cannot reproduce your F12 freecam bug, neither on Win7/64 nor on WinXP/32. F12 always looks good for me. Only explaination could be a modded cameras.dat (maybe someone enabled blur effect for free cam???). I use the original cameras.dat from GWX3. So please disable all mods that change cameras.dat and try again. What GUI do you use?

h.sie

Gammel

11-22-10, 06:08 PM

great work you already did h.sie - sorry for interupting the weather talk... :)

snorkeling with type XXI i have no diesel underwater sound, can anyone using the latest bugfix patch confirm?
Further f12 camera image is blurry 5 knoths and above but thats no biggy to me. I have the same problems on moded version, but can't reproduce this problems on stock (clean) game.dam'n you're right - it's the f**kin mods :DL
but which one?

Clean GWX with h.sie's patch is fine (diesel acoustics snorkeling), sorry for false alarm

note to myself: only reporting here while testing with all mods disabled :-))

gui used was MaGui final...

h.sie

11-22-10, 06:35 PM

@Stiebler:

You can see it by yourself: Take a debugger (I use OllyDbg2) and set a Breakpoint at EnvSim.act+0xDD61. This code section is executed only when new weather is calculated, so use high TC.

Take a look at the variable referenced by [ESI+3d4]. At the end of the routine, it contains the NewWindspeed calculated!!!

At EnvSim.act+0xDD61 you see the routine call for a random number (RND) between -1 and +1. After the call, the RND is in the FPU, st(0).

In EnvSim.act+0xDD66 the random value (RND) is multiplied with 15,0. So that st(0) can contain values between -15 and +15.

Later, after some other code, In EnvSim.act+0xDD99 a value of 15 is added, so that we have values between 0 and 30 in st(0).

Later, at EnvSim.act+0xDDA5 and so on, the value of st(0) is restricted to [0,4499 - 15].

This is what I described earlier. Looking at the windspeed statistics I presented earlier, one can see, that windspeed was never higher than 6 m/s in Koenigsberg. From this I reasoned an (intelligent) emphasis factor (area dependent?), but which I could not locate in the code up to now.

But I made a mistake: The code does not always go this described easy-to-understand path, that means things are more complex than I initially thought. It needs some more time, but I'm pessimistic I'll understand what happens.

So we can only correct the calculated values for windspeed and fog by a little patch at the end of the routine. Maybe some random function or a function that restricts the length of fog periods to a certain value.

h.sie

Magic1111

11-23-10, 02:21 AM

Hello h.sie !

Short question: Is it possible to use your modded File "envsim.act" with your Patch V15C (or without a modded SH3.exe from you as an "Standalone-MOD") ? Or must I use the "envsim.act" ONLY in COMBINATION with your Patch V15D BETA3 ? :hmmm:

Best regards,
Magic

h.sie

11-23-10, 02:28 AM

h.sie

11-23-10, 02:54 AM

@Stiebler: I have an vague idea (that must be tested): If the tendency of the algorithm to produce bad weather is a slow process that slowly converges to bad weather patterns, I could force a "reset" to normal conditions by randomly/casually set the conditions back to "good" (no storm, no fog).

But first

1) I have to find out why EnvSim.act doesn't work in 64Bit OS.
2) I have to find the variable resposible for fog.

Magic1111

11-23-10, 04:06 AM

Hi Magic,

I tested that EnvSim.act only with WinXP/32. It does not work in Win/64Bit. It shoud work with every sh3.exe. But be careful: Use a special SH3 installation for testing. And: the weather change periods are only 2 hours and less for demonstration purposes only. Not for serious play.

So if there are no more bugs in V15D, I'll release a "stable" Version this weekend after fixing the museum-bug which only appears when in museum.

In the next days I'll release a new EnvSim.act which will work with Win/64Bit.

h.sie

Hi h.sie !

Many thanks for your Reply ! :yeah: Now all is cleared !

And that are very good news, that you´ll release in the next days new "stable" Versions from V15D AND EnvSim.act !!!! :up:

For me (and many other Users) is important, that EVERY MOD from you (and/or modded Files like EnvSim.act) work with Win7/64Bit too and we can play career with your MODs (not ONLY testing) ! ;)

Best regards,
Magic:salute:

Stiebler

11-23-10, 04:29 AM

@H.sie:
Many thanks for the detailed reply above. I'll look into this as soon as possible.

One quick thought: maybe most problems could be resolved by setting the 'emphasis-factor' (or its associated random number) for wind speed to zero. Then redistribute the wind speed parameter between 0 and 15 m/s. Or use CherryHarbey's solution (below).

@CherryHarbey:
or alternatively take two random numbers between 0 and 16 and multiply together. Maximum value will still be 256 and answer from the range 0 to 256 but skewed towards the lower end. That is a very imaginative solution - many thanks also. Particularly since, improbable though it may appear, calm seas are actually more common than very stormy seas in mid-Atlantic (according to U-boat war diaries).

My concern would be the source of the random numbers, and how random the numbers would be if plucked in quick succession, at assembler speed, in a few adjacent lines of code. (Most random number generators rely on a time seed for their random algorithm; a few take numbers from a hardware generator that is involved in code or output processing, so results are pseudo-random).

Stiebler.

h.sie

11-23-10, 05:03 AM

@Stiebler:

At EnvSim.act+0xDD61 you see the call for a routine which itself calls Random32(). There you see what happens. Of course this is pseudo-random but hopefully with a very long period since it's based on a 32bit-key. So it repeats the first time after 2^32 = 4G random numbers.

The problems I fear with simply damping down a factor are as follows:

1) The algorithm to calculate wind-speed is not simple and time-independent as I thought at first. It is not only

15*(RANDOM)+15 -> delimited to [0,449-15] and with -1<RANDOM<+1

This could be fixed by using this algorithm

7,5*(RANDOM)+7,5 with -1<RANDOM<+1

which does not even need to be delimited.

There seems to be a loop-back that considers older windspeeds for calculating the new ones. This closed loop also explains the tendency to converge to a certain value (15). An simple random algorithm without loop-back would never converge.

So if we change one factor we could change the whole loop-back behavior (and shred the whole algorithm).

2) As Hitman said, 15m/s is not the hightest windspeed and other people are there wanting higher waves. If we damp down that factor, windspeeds will be lower in average. I would not like that.

But let me first find out how to program for 64-Bit systems. DLL's and ACTs are loaded in a different way in 64 Bit OS, and obviously I made a mistake. If I don't find the cause of my error, there is no need to talk about algorithm.

And then it's important to find out how to manipulate clouds / fog.

And after that all we can test different algorithms to fix the weather.

Greetings,
h.sie

Stiebler

11-23-10, 07:56 AM

@H.sie,

This information acknowledged with thanks.

You made a good point with:
15*(RANDOM)+15 -> delimited to [0,449-15] and with -1<RANDOM<+1

This could be fixed by using this algorithm

7,5*(RANDOM)+7,5 with -1<RANDOM<+1
Don't forget that higher waves can be fixed elsewhere (I think in scene.dat) without needing higher wind speeds. Magic111 or Makman94 or OneLifeCrisis know better than me.

Keep up the good work! So far I have been unable to link the .act (or other dll) files to sh3.exe in my own disassembler. It is not a task I have ever needed previously.
[Edit: I have just discovered that Ollydbg2 does not function with 64-bit Windows.]

Stiebler.

Hitman

11-23-10, 09:16 AM

To clarify some things, so that h.sie has it easier :):

- Wave size and style can be set in the scene.dat file

- You can set a wave size and style for each m/s wind speed, from zero to whatever you want, so you would see waves change as wind speed increases/decreases with each 1 m/s change

- In the game there are currently only 4 sizes of waves, for 0 wind speed, small (4-8 m/s), medium (9-14 m/s) and hard wind speed (15 m/s). Most environmental mods have changed waves size, but in general keep that number of possible waves.

- 15 m/s waves in the game are actually storm waves and would appear in real life only with much stronger winds. But somehow the game has the maximum at 15 m/s, and hence that's the speed where you get the biggest waves.

So, in general, we can provide "playable" waves even with 15 m/s winds in the game simply by reducing the size of them, as f.e. Manos has already done with his environmental mod.

So where's the problem?

The problem is double:

A) Wind speed tends to stick high, as you already know

B) The game's logarythm seems to have strong winds associated with fog and rain, and that together makes the game almost unplayable. There is a parameter in scene dat for "Randomwind" that relates windspeed and rain. Wether it adds a certain wind speed when rain appears, or makes rain appear when wind goes over the set speed, it's difficult to say. It could also be altogether broken.

But it's a fact that overall softer wind speeds will mean more sunny days and less fog & rain.

To sum up, if you simply manage to have the average wind speed decrease in the algorythm, we will have the biggest part of the weather problem solved, both because we will get rid of "permanent storm" situations, and because in general fog and rain (Which make the game unplayable many times) will appear less often. It is not as important to have "realistic" wind speeds (i.e. wind speeds of more than the game's current limit of 15 m/s) as to have a more logical distribution of wind speed along the days in a patrol.

h.sie

11-23-10, 09:30 AM

@Hitman. Now I understand why you always talk about manipulating windspeed instead of fog.

That means I don't even need to manipulate fog, it's sufficient to manipulate windspeed, because it affects fog. I'll give that a try, because I have already successfully manipulated windspeed in the debugger (not yet by patch code).

Ok, now I have to find out how to program 64bit-compatible .act files. Let's hope I find a solution.

Then we can discuss about how exactly modify windspeed (algorithm).

Question: What if I find out how to directly modify fog/clouds? Would that be better than indirectly modify them by reduced windspeed???

h.sie

h.sie

11-23-10, 10:05 AM

@Stiebler: I am able to run OlliDbg2 on Win7/64Bit. It automatically loads all dll's and .act's at program start and you just have to set the breakpoints as I described above.

h.sie

Stiebler

11-23-10, 12:23 PM

@H.sie:

1. I agree completely with Hitman that wind speed is the critical issue, even before you identified a bug in the wind-speed algorithm.

2. Therefore it would be safer not to alter fog and rain settings until the natural wind fix is tried first.

3. Many thanks for the information about Ollidbg2 with Windows-7/64-bit. I took my pessimistic view from the download page for this disassembler, so I haven't actually tried it.

4. I believe I understand now how to see envsim.act file in my own disassembler (IDA PRO plus), so I can try that too (both tomorrow).

Wish me luck. I think I'm going to need it!

Stiebler.

Hitman

11-23-10, 02:37 PM

Question: What if I find out how to directly modify fog/clouds? Would that be better than indirectly modify them by reduced windspeed???I agree with Stiebler. Wind is the critical issue, and following the spirit of what your work is about, let's do fewer and effective changes instead of complicating things too much. First we must try with a simple fix to windspeed and test, as well as get feedback from the thousands of people who will be able to use it (ACT file will work also for the starforce versions).

If later we see the need and oportunity to tweak something else, then we can talk about it. But in general, the less you change, the easier it will be to keep everything under control. :up:

[EDIT]

Probably the best thing will be a combination of more frequent weather changes and a tendency for lower wind speeds in the algorythm. That should allow the complicated pattern created by the Devs for seasons/zone weather changes to work much better.

h.sie

11-23-10, 05:22 PM

In the meantine I made a new version of EnvSim.act which ran on XP/32 and Win7/64 without problem. Can be used with unpatched sh3.exe.

Only fix so far: Weather change period reduced by a factor of 20.

I suggest to go to the bridge or external cam and set TC=128x. (Normally max. TC on bridge is 32x, but this value can be changed using SH3Cmdr: "When in 3D views").

Then you can see the fast weather changes.

This is for demonstration purposes only.

Use on your own risk.

Can be downloaded from my mediafire page, Folder "Testing".

Tomorrow I'll start to implement a very simple algorithm in which I try to disturb the windspeed tendency to converge to 15m/s

h.sie

Madox58

11-23-10, 08:26 PM

What software do you use for your work at this point?
:hmmm:

h.sie

11-24-10, 01:49 AM

@privateer: A little bit with OlliDbg and mainly with a tool that has been developed in my company - not freely available.

@Stiebler: I think the author of OlliDbg meant that OlliDbg won't run in 64-BIt mode, but it (obviously) can debug 32-bit applications. I had no problems so far.

h.sie

11-24-10, 01:59 AM

My idea for a first very simple algorithm is as follows:

Windspeeds between 0 and 14 are not touched, because they are (hopefully) distributed homogenuously.

But if New_Windspeed==15, then, by a certain chance of, let's say, A=50% this is not changed. But with the remaining chance of (1-A)=50% a new windspeed between B=5 and C=14 is randomly generated. That should at least disturb most of the long periods of bad weather, although, there remains (statistically) a little chance for very long periods, what I think is not unrealistic.

If that works in principle, one can fine-adjust A, B, C.

What I don't know is: how low must the windspeed been chosen in order to guarrantee that bad weather ends or at least will be reduced?

h.sie

Yoriyn

11-24-10, 06:02 AM

After testing new EnvSim.act on clear SH3 installation in campaign mode I can say:
- weather changing intervals for my XP/32bit is 1:33hour, so every one and a half hour weather change.

I don't see the point to making mess in game weather algorithms and change wind behavior. Weather behavior is different, and depends on your location on the map, season of the year and more. So we have different weather on North Atlantic and different on South or Mediterranean sea. Bad weather on North Atlantic is very common. I just finish reading a Jost Metzler book (one of the u-boat captain in WWII), and on all his three patrols on the North atlantic he had heavy storms.

In this moment stock game have weather changing intervals is 33-34hours. In reality weather change more often, almost all the time. So after 33h we have a chance to weather change, even if the wind do not change the fog, rain, clouds can. So changing weather intervals to 12-16h reduce fog duration to 12-16h instead 33-34h, without messing in algorithms.

If the fog change in second or third weather interval this give you:
33h interval - second interval after 66h (2,5days of constant fog) - third interval 99h ( more then 4days constant fog or rain etc)
12h intervals - secind interval 24h (give us only day with fog or rain) - in third interval 36h (1,5 day still ok for me)

h.sie

11-24-10, 06:17 AM

Thanks, Yoriyn, for first impressions. I like the watchcrew dancing on the bridge in TC=128x. I also tend to do as few changes as possible - only what is really necessary.

Let us wait and see what the others think. I for myself have no experience regarding weather because, as I mentioned multiple times, I never played a career.

I'm looking forward for a controverse discussion about weather with 1o people and 12 different opinions. :).

Even if we decide to do some changes to windspeed, I'll make a special version for you with 12h Intervals - without any other change.
Done in 10 minutes.

Stiebler

11-24-10, 06:45 AM

@H.sie:

I've just sent you a PM, concerning Ollydbg2.

@Yoriyn:

H.sie has discovered that there is definitely a bug in the wind speed control. This needs to be fixed, since it may solve other weather problems too.

Stiebler.

Yoriyn

11-24-10, 06:59 AM

Stiebler: What weather bug you have on mind?

h.sie: Did you found any connection between the setting WeatherRndInterval= in campaign_xxx.mis and weather change intervals in game?

h.sie

11-24-10, 08:21 AM

@Yoriyin: No. There has been massive research in the past regarding these WeatherRndInterval settings, but with moderate/diffuse success.
So I think this part is somehow broken and not worth to be investigated furtheron. But maybe I'm wrong with this.

Hitman

11-24-10, 09:11 AM

Stiebler: What weather bug you have on mind?

Mate it's in the previous page ....

Yoriyn

11-24-10, 10:32 AM

Sorry, but I think I got it now little late but is better late then never :)

I don't think the bug is when program generate wind bigger then 15m/s. 15m/s it is modrate strong (moderate gale not a storm) wind on sea, so for me is strange the game wind scale finish on this 15. If you programming you exacly know what you want to do, so they must know the algorithm produce numbers from 0 to 30. It is more logic for me to produce winds between 0-30m/s then 0-15m/s, specialy for u-boats game, where most patrols have a place on north atlantic. For me this strange 15m/s barrier looks very, very strange like abandoned project or rush in developing.
Where are this hevy storms described by u-boat crews, where peolpe in the machine room was shooted in the "air" by waves. I think bigest problem is in weather change period (as I said before few days with fog), and another in wind 0m/s, which is imposible rare phenomena on north atlantic.

h.sie

11-24-10, 11:28 AM

@Yoriyn: You are right, but as Hitman & Stiebler said: One can enlarge the waves later in the scene.dat or using SH3-Commander.

The limitation to 0...15m/s is located on a different location in the code (at the very end) and so I also think this was a quick&dirty fix by the devs perhaps because with higher waves some unwanted side-effects occured.

I'll try a 2nd algorithm according to Stieblers idea: Damping down the output of the algorithm instead of delimiting. Or as a compromise, little damping, so that delimiting occurs very seldom.

I could also test what happens if I simply bypass the limit of 15 and allow higher speeds, but there surely will be side-effects....

Yoriyn

11-24-10, 02:25 PM

Only problem with bypass wind restriction can be CTD if not waves stay the same as are, because stock file scene.dat have a setting for a winds:

0-3m/s - small ribblets
4-7m/s - small waves
8-14m/s - bigger waves
15m/s or more - moderate waves

Hitman

11-24-10, 02:43 PM

The limitation to 0...15m/s is located on a different location in the code (at the very end) and so I also think this was a quick&dirty fix by the devs perhaps because with higher waves some unwanted side-effects occured.

It's difficult to tell why they would cap the wind speed at 15 knots. May be with higher limit the algorythm had a tendency to make weather even worse. May be they had no time to finish the job with the waves, but this seems rather improbable, since the "large" waves assigned to current 15 m/s wind are actually very large ones. In my opinion something did not work well with the algorythm, and they reduced windspeed to 15, then adapting the four sizes of waves to that range (0-15). Another telling element is the speed with which clouds move in the sky. With 15 m/s they are already rushing around, so it seems that indeed they simply adapted their maximum, originally planned fopr much harder winds, to 15 m/s and then scaled all the rest.

Only problem with bypass wind restriction can be CTD if not waves stay the same as are, because stock file scene.dat have a setting for a winds:

0-3m/s - small ribblets
4-7m/s - small waves
8-14m/s - bigger waves
15m/s or more - moderate waves

That shouldn't be a problem even if no bigger waves are added to the scene.dat. The reason is that the waves are defined only with START wind speed, i.e. *from* a certain wind speed, a certain wave model is used, until the wind reaches a strength where the scene.dat has a different wave, and then the new one is used. If you do not add different waves for windspeeds >15 m/s, then the game will simply keep using the current 15 m/s wave. The only difference you would notice is in the speed with which clouds move in the sky, unless other effects (reduce your speed due to aerodynamics, increase drag, etc) are programmed, which I do not know right now.

Yoriyn

11-24-10, 03:19 PM

I agree with you. We never find out if we do not try (of course if the h.sie give as a try :D).

h.sie

11-24-10, 03:52 PM

So which factor should be used at the end to reduce weather change period?

Yoriyn

11-24-10, 03:56 PM

I'm voting something 12-14 hours. :yeah:
I think is more realistic to have weather change in morning and evening the same day.

h.sie

11-24-10, 04:03 PM

that would be a factor of about 3 or 4.

time periods would also be reduced by the same factor.

Yoriyn

11-24-10, 04:12 PM

h.sie: can't understand your last post, what means factor 3 or 4?

Do not base only on my posts, mayby wait till others give they opinions. Together we can solve more problems and have different points of view, and knowledge.

h.sie

11-24-10, 04:35 PM

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

Yoriyn

11-24-10, 04:52 PM

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?

h.sie

11-24-10, 04:55 PM

period varies. my tests showed 44h

Yoriyn

11-24-10, 05:01 PM

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.

h.sie

11-24-10, 05:09 PM

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

Yoriyn

11-24-10, 05:40 PM

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?

CherryHarbey

11-24-10, 06:29 PM

So which factor should be used at the end to reduce weather change period?

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?

Yoriyn

11-24-10, 06:54 PM

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!!

h.sie

11-25-10, 02:33 AM

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

makman94

11-25-10, 04:20 AM

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

h.sie

11-25-10, 05:32 AM

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/showpost.php?p=1540793&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 (??)

SquareSteelBar

11-25-10, 06:22 AM

...1) Can I use JSGME to replace EnvSim.act (which lies out of the "data" folder)? Would make life easiser for testers...Yes, it's possible like patched sh3.exe...

Stiebler

11-25-10, 06:31 AM

CherryHarbey said:
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?
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.

h.sie

11-25-10, 07:02 AM

@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

Magic1111

11-25-10, 07:03 AM

Hitman

11-25-10, 10:21 AM

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

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

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. :shucks:

Yoriyn

11-25-10, 11:07 AM

Agree wind 6 is more natural.

h.sie

11-25-10, 11:37 AM

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

11-25-10, 11:39 AM

Is a factor 5 not to big?

Stiebler

11-25-10, 01:45 PM

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

11-25-10, 02:13 PM

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

11-25-10, 02:57 PM

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

- 2 normal and 2 special (yoriyn and stiebler) :DL

Can I ask for another special for my mum :haha:

Magic1111

11-25-10, 03:14 PM

Can I ask for another special for my mum :haha:

:rotfl2::up::rotfl2:

h.sie

11-25-10, 04:12 PM

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

11-26-10, 02:41 AM

I prefer solution 2 at the moment.

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

Best regards,
Magic

Stiebler

11-26-10, 04:23 AM

@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

11-26-10, 04:43 AM

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

11-26-10, 06:18 AM

@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

11-26-10, 09:05 AM

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. :shucks:

irish1958

11-26-10, 09:34 AM

LGN1

11-26-10, 03:14 PM

Hi,

it's great to see this thread gathering momentum :up:

Just a comment about higher waves: I don't think they look nice/realistic in-game. They are just too short. It's not really possible to 'ride' them (just compare them to some storm pictures from Buchheim). I guess the engine is not capable to model large waves properly. Maybe that's the reason why they limited the wind speed :06:

Now some weather questions :oops::

- Is it known what happens if a new weather pattern is created before the old pattern has been reached? Can this cause problems?

- A possible weather change every 10-12h sounds really short to me :hmmm: Is this realistic? When shadowing a convoy for some time (up to days) I don't want to see the whole weather pattern of SH3 so that I can choose the best weather to attack.

Anyway, I am sure we will see a good algorithm in the end! Keep up the great work, h.sie.

Cheers, LGN1

h.sie

11-26-10, 03:36 PM

I'm glad that I can finally use some boring statistics knowledge I learnt and never needed up to now.

Lets say because of the bug the weater algorithm sticks at high windspeeds. My fix will only be active if windspeed is 14 or 15. Then, with a certain chance C the windspeed will be reduced to a lower value (1m/s ... 8m/s) .

In order to adjust the chance C, I must have an idea of what is the resulting probability P that the bad weather period is interrupted after n = 1, 2, 3, 4,..... weather periods.

Solution: P = C * (1-C)^(n-1)

That means:

If I chose for the chance C = 10%
---------------------------------
P that bad weather is interrupted after the 1. weather period: 10%
P that bad weather is interrupted after the 2. weather period: 9,0%
P that bad weather is interrupted after the 3. weather period: 8,1%
P that bad weather is interrupted after the 4. weather period: 7,3%
P that bad weather is interrupted after the 5. weather period: 6,6%
P that bad weather is interrupted after the 6. weather period: 5,9%
P that bad weather is interrupted after the 7. weather period: 5,3%
P that bad weather is interrupted after the 8. weather period: 4,8%
P that bad weather is interrupted after the 9. weather period: 4,3%
P that bad weather is interrupted after the 10. weather period: 3,9%
P that bad weather is interrupted after the 11. weather period: 3,5%
P that bad weather is interrupted after the 12. weather period: 3.1%
P that bad weather is NOT interrupted after 12 weather periods: 28%

If I chose for the chance C = 20%
---------------------------------
P that bad weather is interrupted after the 1. weather period: 20%
P that bad weather is interrupted after the 2. weather period: 16%
P that bad weather is interrupted after the 3. weather period: 12,8%
P that bad weather is interrupted after the 4. weather period: 10,2%
P that bad weather is interrupted after the 5. weather period: 8,2%
P that bad weather is interrupted after the 6. weather period: 6,5%
P that bad weather is interrupted after the 7. weather period: 5,2%
P that bad weather is interrupted after the 8. weather period: 4,2%
P that bad weather is interrupted after the 9. weather period: 3,3%
P that bad weather is interrupted after the 10. weather period: 2,6%
P that bad weather is interrupted after the 11. weather period: 2,1%
P that bad weather is interrupted after the 12. weather period: 1,7%
P that bad weather is NOT interrupted after 12 weather periods: 7,2%

So C = 20% seems to be the optimal value for me.

By the way: this is not for bragging with formulas. I'm too old for that. But much more I think it's good for all interested people to know what we can expect from the fix (which is almost done!)

h.sie

h.sie

11-26-10, 06:54 PM

@Stiebler: Funny, I found out that in the arctic sea I could not force windspeed lower than 7,5, even if I set ESI+3D4 to 0.

In other regions, St. Naziere, setting ESI+3D4 to 0 lets the wind go down to 0. So there is more code related to windspeed, maybe a location-dependent lower limit?

Lets hope that reducing wind to 7,5 is sufficient to remove fog.

h.sie

Yoriyn

11-27-10, 06:15 AM

I'm very sceptic about all this messing in weather algorithms. Even the described Stiebler constant bad weather bug don't convince me. Maybe I only one who wahe a different weather experiences. I agree the storms can be big pain in the a**, but when they finish weather can back to "normal". Only problem what I see is a waiting for a weather change. Problem with fog is bad, cos minimum constant fog period is to first weather change interval (as we agree 40h), so that give as almost two days with fog. I think reducing intervals time should reduce all problems with weather. Reducing waiting time for change we also reducing time of duration of specific weather.

Actual "fixing" wind in north atlantic can have a bad effect on wind in south atlantic or mediterranean sea or increasing bad weather periods or decrasing muchly on arctic sea.

h.sie

11-27-10, 06:31 AM

In fact: The delimiter at EnvSim.act+DDA5 does not always use the same limits. In the arctic, windspeed limits are not [0,49....15] but [7.5....15].
The limits itself can be found at ESI+3DC and ESI+3E0.

@Yoryin: I'll make a special version for you without any code messing except for time period reduced by 3. but for Stiebler et al. this is not sufficient. where is the problem?

h.sie

11-27-10, 07:09 AM

In some tests in the northsea:

1. I fixed windspeed to 1m/s and watched fog over the time. then
2. I fixed wind to 15m/s and watched fog.

My first impression: Reducing windspeed does not affect fog and rain, at least there is no obvious strong correlation, which we need to control fog by windspeed. So I fear our idea does not work as intended. So I'll try to control fog directly.

Maybe in the game fog often occurs when wind is 15. but that does not automatically mean that windspeed controls fog.

Yoriyn

11-27-10, 07:35 AM

Sorry I was sure there will be only one version. I thought you joking with all this extra versions. Sorry again, no more problems with me :D I'm closing my mouth forever :smug:

h.sie

11-27-10, 08:02 AM

I'm not joking

h.sie

11-27-10, 09:04 AM

@Yoriyn: So what factor would you like? 3.0?

Since I wasn't able to reproduce the long-time sticking on no-visibility, I think the idea to simply reduce time interval is not that bad. i like there more often changes, even if they are not 100% realistic. and even if the bug occurs, its length is reduced by 3.

Nevertheless I'll not give up to make a better fix. But for this I need to REPRODUCE the bug. Under which circumstances does it occur? location? season? year? month? any suggestions?

h.sie

Yoriyn

11-27-10, 09:19 AM

Yes factor 3 for me please :)

When I can expect relase?

h.sie

11-28-10, 06:57 AM

@ALL (who are interested) : Good news:

1) I finally managed to get write access to EnvSim.act. That means, I can work with a counter and store some stuff, which could be important when measuring the length of a bad-weather period. Patched sh3.exe is not required.

2) Also, I found a way to force windspeed AND fog to good conditions. The trick is not to change windspeed variable itself directly, that didn't change fog. Instead, I found out that the random numbers generated influence not the absolute weather but the weather tendency. If the random number is +1, weather gets worse. storm, fog are the result in 2 of 3 cases (@Stiebler: the other missing case of these 3 cases is caused by a scrambler related to the counter at 0xDD02BC). When the random number is -1, weather gets better in most cases (not always, maybe also because of a scrambler, but not absolutely sure in this point).

So I can now realise a fix that:

1) Measures the length of the bad weather period, which could be identified

a) either only by the amount of fog, or,
b) by the amount of fog AND windspeed.

2) If the bad weather period is longer than a certain value (could be a constant or a randomly chosen value), I bypass the random generator and load some -1 instead (or allow only negative random values), and wait, until weather gets better. I am slightly optimistic now, that we can fix the weather bug (which I have never seen, bru-har-har!)

@Yoriyin I think, your patch will be done in the next 0-2 days.

h.sie

h.sie

11-28-10, 07:25 AM

Release: Bad Weather Fix - Yoryin special Edition

From the readme:

Weather Fix - Yoriyn Edition
----------------------------

Background
----------

Due to a serious bug, the sh3 weather sometimes sticks at high windspeeds with 15m/s and fog, rain and no visibility.

What does this mod do
---------------------
It simply reduces the weather changing period by a factor of 3, so that bad weather periods are shorter now. I don't know if now all problems are solved.

- Tested with WinXP/32Bit and Win7/64Bit.

- Should work with every version of sh3.exe

h.sie

Download: See my mediafire page, folder "Bad weather fix"

Magic1111

11-28-10, 07:27 AM

@ALL (who are interested) : Good news:

1) I finally managed to get write access to EnvSim.act. That means, I can work with a counter and store some stuff, which could be important when measuring the length of a bad-weather period. Patched sh3.exe is not required.

2) Also, I found a way to force windspeed AND fog to good conditions. The trick is not to change windspeed variable itself directly, that didn't change fog. Instead, I found out that the random numbers generated influence not the absolute weather but the weather tendency. If the random number is +1, weather gets worse. storm, fog are the result in 2 of 3 cases (@Stiebler: the other missing case of these 3 cases is caused by a scrambler related to the counter at 0xDD02BC). When the random number is -1, weather gets better in most cases (not always, also because of a scrambler).

So I can now realise a fix that:

1) Measures the length of the bad weather period, which could be identified

a) either only by the amount of fog, or,
b) by the amount of fog AND windspeed.

2) If the bad weather period is longer than a certain value (could be a constant or a randomly chosen value), I bypass the random generator and load some -1 instead, and wait, until weather gets better. I am slightly optimistic now, that we can fix the weather bug (which I have never seen, bru-har-har!)

@Yoriyin I think, your patch will be done in the next 0-2 days.

h.sie

Hi h.sie !

Wonderful news ! :yeah:

When do you plan to release your mod / the files ?

Best regards,
Magic:salute:

Yoriyn

11-28-10, 07:43 AM

Thank you, I starting tests now.

After first tests I can say weather changing intervals in my SH3 is 10h:40min. So it is perfect :D exacly what I expect. Now I'm starting longer tests to check weather behavior.

Great job :yeah::yeah:

h.sie

11-28-10, 12:43 PM

@Yoriyn: In the arctic sea weather changes more often, hopefully not too often now.

@Magic1111: I don't know. days? weeks?

@LGN1: One has to differ between the, say "current_weather" and, say, "current_end_weather". the second is what's calculated every weather period (20-40h), the first then slowly fits to the second during the time. but only the second is considered for the calculation of a new weather, that means it doesn't matter if the first has already fitted to the second or not. We have to discuss about the weather period. I asked earlier, but only got 1 answer: factor 3. I don't know what e.g. Hitman and Stiebler are thinking about that.

@ALL: The released Fix "Yoriyn edition" is not my final fix, it's just a quick fix for those who want shorter weather periods without any changes to the weather algorithm.

There will follow my fix I described above and perhaps, if necessary, a Stiebler's edition containing Stieber's approach to fix the weather bug.

h.sie

LGN1

11-28-10, 01:10 PM

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

NGT

11-28-10, 02:22 PM

Release: Bad Weather Fix - Yoryin special Edition

.................................................. .....................

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)

Magic1111

11-28-10, 02:50 PM

@Magic1111: I don't know. days? weeks?

h.sie

Hi !

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

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

Best regards,
Magic:salute:

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.

h.sie

11-28-10, 05:08 PM

@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

h.sie

11-28-10, 05:32 PM

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

Volk2

11-28-10, 07:11 PM

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.

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

Stiebler

11-30-10, 10:25 AM

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

h.sie

11-30-10, 02:36 PM

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

Hitman

11-30-10, 03:29 PM

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

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??

Stiebler

12-01-10, 04:52 AM

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

h.sie

12-01-10, 05:01 AM

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

rik007

12-01-10, 02:14 PM

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

SquareSteelBar

12-01-10, 03:29 PM

Buy a SF free version...

E.g.:

http://www.amazon.de/Purple-Hills-Silent-Hunter-3/dp/B002YNS4FY

Victor Schutze

12-01-10, 03:42 PM

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:

Jimbuna

12-01-10, 04:43 PM

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

Suport SubSim....you'll feel a whole lot better http://www.psionguild.org/forums/images/smilies/wolfsmilies/thumbsup.gif

h.sie

12-05-10, 05:49 PM

New Version V15D_BETA4 available.

Bug fixed: CTD when in Museum, reported by Magic1111. So if you don't use the Museum, this update is not necessary for you.

Since there have no other bugs been reported for weeks now,
this version seems to be stable (but I'll anyhow call it beta - you never know).

New: The modded CameraBehavior.act (which is also required), is now contained in a JSGME ready mod.

Maybe it's a good idea to also put the patched sh3.exe in that JSGME mod after patching and enable both files via JSGME.

h.sie

Magic1111

12-06-10, 04:25 AM

h.sie

12-06-10, 04:43 AM

In V15D_Beta4 a bug is fixed which caused a CTD when in Museum.

Features of V15D_Beta4 see this post:

http://www.subsim.com/radioroom/showpost.php?p=1530834&postcount=458

I'll update the 1st post of this Fred in the next time.

h.sie

Magic1111

12-06-10, 06:10 AM

Delareon

12-06-10, 06:29 AM

Thanks h.sie :)

Stupid question: installing this mod for an existing career (while in harbor as usual) should work, yes?

h.sie

12-06-10, 06:49 AM

should work! but make backup of your career files.

Dani

12-06-10, 03:00 PM

@Stiebler

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.

Have you tested h.sie's patches with NYGM?
Are there safe to use regarding repair times?

Stiebler

12-06-10, 03:23 PM

@Dani:

Yes, H.sie's V15D patch seems to be compatible with NYGM's repair times.

In fact, this patch works very well with NYGM.

Stiebler.

h.sie

12-09-10, 03:26 AM

People who play NYGM together with patched SH3.exe should contact Stiebler or me, if they have any problems. There seems to be an incompatibility between "my" longer repair times and the special NYGM damage model from Observer.

GWX users are not affected.

h.sie

12-10-10, 05:35 AM

makman94

12-10-10, 10:39 AM

Question: In order to make my fixes compatibe to further windows versions (Win7 successors), I have to re-write some fixes, especially the code section responsible for the blur-effect to simulate periscopes vibrations. This only makes sense, if the majority likes this effect. If not, I can save my time.

Thanks for your answers
h.sie

hi H.Sie ,

i , personally , don't like that effect so my vote is to not include it at your next version (or ,if possible,to be a version without it)

thank you for your efforts

bye

Hitman

12-10-10, 10:45 AM

Periscope vibration is not a priority for me, and I think we might eventually find alternative ways of discouraging the player from raising it >4 knots, like damaging it or whatever.

CherryHarbey

12-11-10, 05:35 AM

Periscope blur is not a priority for me as I go for the simple "don't raise the scope above 4 knots self discipline mod":DL
I would suggest concentrating on those things that the player cannot fix themselves thorugh their own gameplay.

NGT

12-11-10, 06:14 AM

Hello h.sie and others,

I don't like periscope vibrations, and for this reason I don't use the CameraBehavior.act included in your mod.

So, were is the point? If someone don't likes, he must just avoid to install the CameraBehavior.act, no?

Or I have got something wrong? :06:

Thanks for asking our advice. :yeah:

NGT

12-11-10, 06:34 AM

I would like to say that the post 669 (Stiebler) is contradictory with 670 (h.sie)....:hmmm:

Any —supplementary— comment, please?

Thanks

LGN1

12-11-10, 08:17 AM

Question: In order to make my fixes compatibe to further windows versions (Win7 successors), I have to re-write some fixes, especially the code section responsible for the blur-effect to simulate periscopes vibrations. This only makes sense, if the majority likes this effect. If not, I can save my time.

Thanks for your answers
h.sie

Well, I like it a lot :oops:, but it's not too critical because you can enforce the '4kn rule' by yourself.

If it's not too much work I would be happy if the effect would be also present in future versions. As said previously, if people don't like it they can just leave the file out.

Cheers, LGN1

Magic1111

12-11-10, 08:26 AM

hi H.Sie ,

i , personally , don't like that effect so my vote is to not include it at your next version (or ,if possible,to be a version without it)

thank you for your efforts

bye

Yes, me too ! I don´t like the effects with the file cameraBehavior.act and I use the V15D BETA4 without the .act File !

Best regards,
Magic

h.sie

12-12-10, 05:29 AM

There have been requests in the past for individually switching ON/OFF some of my Fixes. I planned to program a configurator program at the end when all fixed are done. In the meantime you have to do the changes by yourself.

1) Make backup copy of patched sh3.exe

2) Take a Hex-Editor (e.g. NEXT-Soft Hex Editor MX) and open patched sh3.exe.

3) Scroll to address 0x148F60, where the ON/OFF switches are located.

4) A switch is ON, if the value is FF, otherwise the switch is OFF.

5) If you e.g. want to disable the repair time fix, change the value of the byte marked with "A" to a value different from FF, e.g. set it to "00". Save the file. Done.

http://img221.imageshack.us/img221/963/v15dconfig.png

h.sie

12-12-10, 06:23 AM

My next actions here are:

1) Repairs affect detection probability

2) Re-write some code to make it position-independent and thus compatible to further Win versions (Win7 successors).

But this will take time, since I decided to reduce my time for modding.

NGT

12-12-10, 06:43 AM

Just wonderful ! ! ! :yeah:

Thank you very much. :up:

It makes a difference if the SH3.exe was patched with 4GB patch after your patch or not ??

Can I find the address and the switchers after applying the 4GB patch??

* * * * * * * * * * * * * * * * * * * *

What are you mind exactly by "repairs affecting detection" ? You mind easier detection from destroyers hydrophone, because of more noise ?

* * * * * * * * * * * * * * * * * * * *

This is not any more SH3. This is SH3 GOLD EDITION.

The gift for everyone stick in this game after almost 6 years.

h.sie

12-12-10, 07:31 AM

@NGT: Thanks, mate!!

Regarding your questions:

0) The problem with the CameraBehavior.act fix is, that it would be hard to make it compatible to Win7 successors. And so I can save my time if the mayority doesn't like that effect.

1) Stiebler found an issue with NYGM, so it's not clear if the Repair times fix works with NYGM or not.

2) Yes, switches do not change position after 4GB patch.

3) Yes, easier detection due to repair noise. Maybe I can fix it.

h.sie

Myxale

12-12-10, 08:23 AM

@NGT: Thanks, mate!!

3) Yes, easier detection due to repair noise. Maybe I can fix it.

h.sie

Why fix it?? Isn't that the point! Being easier to locate, cuz the damage crew is clanking with nuts and bolts!

Tessa

12-12-10, 10:16 AM

h.sie, am really glad to see that you got this figured out; however you managed to get the CO2 under control is very cool. Once I finish my current patrol am looking forward to testing this out, you do simply brilliant work :up:

If you want to re-open pandora's box and try working on battery acid like we talked about quite a long time ago I've got a few ideas that might be a starting point or item to use to transform into what is needed. With what you originally were planning on (sorry, kinda got out of touch for a few weeks and missed all the development), what the final product is was much more than I ever anticipated!

My install will be one of the messy ones (Win 7 x64 w/6 gb ram), if it crashes or fails does it leave anything like a core dump that you could possibly use to help troubleshooting?

Awesome job :|\\

h.sie

12-12-10, 05:23 PM

@Myxale: I wanted to say, that currently repairs do not affect detection probability, and this issue I try to fix.

@Tessa: I fear I am too tired to touch again CO2. Even in its current state the code is very complex, so I fear to risk deeper changes. Maybe after a rest from programming.

If you had a CTD (did you?) the information given on the CTD window (module and offset) would be of interest for me in order to determine if my fixes caused the CTD, and if so, which code position is responsible

h.sie

Tessa

12-12-10, 07:43 PM

@Tessa: I fear I am too tired to touch again CO2. Even in its current state the code is very complex, so I fear to risk deeper changes. Maybe after a rest from programming.

If you had a CTD (did you?) the information given on the CTD window (module and offset) would be of interest for me in order to determine if my fixes caused the CTD, and if so, which code position is responsible

h.sie

I can imagine the long sleepless nights working on the CO2; when I read the amount of detail and changes in it I was really shocked. Have been at the same point as you many times before at work, finish a large program/fix some unsolvable issue and then the last thing you want to do is ever see that item/software again for the next week or two else you go ballistic.

With the mods you were able to make, I think a very large portion can be re-used if you do ever want to try doing the battery acid mod.

Currently my boat is out on patrol so haven't been able to install it yet. You answered the questions I had though; if anything comes up I'll pm or post it for you.

Stiebler

12-13-10, 03:13 AM

@NGT:

I can confirm what H.sie has said.

After making my earlier post, saying that the H.sie repair mod did not conflict with NYGM, I discovered that certain types of damage caused a strange scrolling effect on the screens (key strokes F5, F3, F4).

This is undoubtedly due to Observer's damage model for NYGM, which used parts of the XXI U-boat for the compartments. However, Observer's work needed very little improvment anyway, so H.sie and I have agreed that it is not necessary to change H.sie's repair mod for NYGM.

However, NYGM users should disable the repairs mod of H.sie's V15D Beta 4 as H.sie has described above (#679). Use a hex editor to change 148F60 from FF to 00.

All the other functions of this mod V15D work excellently with NYGM. I have completed almost a complete campaign with NYGM and V15D now.

Stiebler.

h.sie

12-13-10, 03:30 AM

If there is interest, I could create a special NYGM compatible patch V15D with repair fix disabled. Takes 5 minutes.

Dani

12-13-10, 11:31 AM

I'm interested for the NYGM V15D patch ....please.

Hitman

12-13-10, 01:32 PM

I'm interested for the NYGM V15D patch ....please.

Ditto :yep:

coronas

12-13-10, 03:59 PM

I'm interested for the NYGM V15D patch ....please.

Me too, please!

Stiebler

12-14-10, 12:17 PM

Here is an interesting new problem for H.sie:

When the U-boat goes to silent-running, the pumps are turned off and the U-boat should sink very slowly. However, the U-boat in SH3 does not sink at all. This problem is not fixed with any mod, and it cannot be mimicked in any way by the player. Therefore, when the U-boat attacks any convoy, the easy (and unrealistic) procedure in SH3 is to go to silent-running at once. It would be much more interesting for the player if he has to judge when to turn silent-running on and off, in order to avoid detection and also to avoid sinking. (The old 'Aces of the Deep' program had this feature.)

One solution to this problem would be to alter the parameter 'mass' loaded from file NSS_Uboatxy.sim (where 'xy' = 7c, 9c etc). The value loaded from the .sim file is zero in stock SH3 and NYGM (a high value with GWX), and represents 'negative buoyancy'. That is, the *lower* the figure, the more the U-boat will sink. The parameter needs to become negative when silent-running to ensure a slow sinking. Then restore the value to its original value when silent-running is cancelled.

I think H.sie has already discovered the silent-running code routines for his realistic repairs mod, so I hope that this problem would not be too difficult for him.

Stiebler.

LGN1

12-14-10, 02:11 PM

Hi Stiebler,

I have also thought about this a bit, but I am not sure how useful it is. The main reason is that in real-life you could use the explosions of the depth charges to use the pumps without getting detected. However, in SH3 there is no 'noise shadow' of the depth charges, so you cannot take advantage of this.

It would be great if the effect of the depth charge noise was modeled in SH3. However, I think adding this feature is a huge task (I think there is a variable that contains the probability that you are detected, however, I have no idea how to determine that a depth charge has exploded sufficiently close to the sub and then change this variable).

At the moment neither repairs nor running pumps do influence the probability that you are detected (really weired, you have a destroyer above you and you can repair diesels without getting detected :har:). It would be great if h.sie could fix this issue. In this case running the pumps (when you have flooding) would also increase the probability that you are detected :up:

Having the 'noise shadow' of the depth charges and the noise of the pumps modeled would be definitely fine, however, I think it requires a lot work and also testing because it would change the whole sensor/detection setting (it might become too easy to evade :06:).

Cheers, LGN1

Hitman

12-14-10, 04:17 PM

Stiebler has again put the finger on a very important aspect of the game, which NYGM already adressed partially with the anti-humming bird mod. :up: I also would like to see a more realistic buoyancy behaviour without having to mod the game in a forced way as has been done until now due to the only alternative available. :yep:

h.sie

12-14-10, 05:02 PM

h.sie

12-14-10, 05:21 PM

LGN1

12-14-10, 05:37 PM

Question: Would it make sense to restrict speed/rpm while in Silent-Running? Currently, speed is reduced to 50 (?) rpm when you order Silent-Running, but after that you can order higher rpm and Silent Running is still active. I never understood this. Is that a bug?

@LGN1: While we are discussing about buoyancy and so on, my next job is to consider repairs for detection probability, as I promised months ago. That will take time, since I have to re-write some fixes to make them position-independent and thus compatible to Win7-successors.

Hi h.sie,

great that you are looking into the detection probability issue! Thanks!

Concerning the silent-running setting: I don't think one should limit the rpm in silent-running mode. Of course, if you use higher rpms it's not silent anymore, however, I regard the setting more in the way of 'Guys, stop any repairs, don't reload torpedoes and rest/be quiet'. If you limit the speed you cannot use the command for just conserving O2 when running submerged over a long time without any direct threat (ok, probably you run out of batteries at higher speeds than the CO2 will limit you :hmmm:).

Anyway, I think it's not really necessary to limit the speed and the present situation gives you more flexibility than if you tie max. speed and silent-running together.

Cheers, LGN1

NGT

12-14-10, 05:39 PM

h.sie

12-14-10, 05:50 PM

@NGT, LGN1: Great, Thanks. Now I understand.

h.sie

12-14-10, 06:13 PM

Question: Is there any reason to NOT include the 4GB patch into my patches?

So there would be no need to apply the 4GB patch after patching the patch of the patch.

h.sie

12-15-10, 01:52 AM

@LGN1: Currently thinking about repairs/detection:

I thought about a simple fix like:

If (REPAIRS) then RISE_DETECTION_PROBABAILITY

or similar. But: Let's assume the following situation: A destroyer is hunting you and throws depth charges everywhere without exactly knowing where you are. Let's now assume, one depth charge causes a minor and uncritical damage. In sh3, the crew immediately begins repairs. This is dumb in this situation and will rise detection probability and the destroyer now can locate you. In GWX life is hard for a kaleun even in the current state, but this change would make it impossible to escape from this situation. Only idea: Delaying the effect of repairs on detection, so that the user has enough time to order silent-running and thus stop repairs.

Hitman

12-15-10, 02:12 AM

I already thought about to program negative buyouncy similar to the NYGM anti-hummingbird mod, but without "abusing" the XXI-pump, as the NYGM team did as only possible (conventional) workaround. and hopefully without crash-dive-blues.

But the problem is to keep the compatibility to both supermods NYGM and GWX (which I personally prefer) WITHOUT making two different versions of my patch. If I fix an issue that is common to both supermods, this will be no problem. but if I fix an issue that is only present in one of both supermods, the fix will not be compatible to the other supermod. Example: Repair time fix works well in GWX but conflicts with NYGM. Problem can fortunalely be solved by disabling repair times fix for NYGM.

But the pumps/buoyancy systems of NYGM and GWX are totally different from each other (NYGM made deep changes I don't understand) and this would require to program two different versions. I don't like this.

Lets now assume I manage to program negative buoyancy.

1) It will work with GWX but it will of course break the old positive buoyancy settings and reqires changes in all Uboat types .sim files ("mass" entry). Okay, no big problem.

2) It will conflict with the old anti-hummingbird mod currently integrated in NYGM, so that someone first has to remove it from NYGM. But what if someone really removes old anti-hummingbird mod from NYGM? This forces all NYGM users to use my fix in order to still have negative buoyancy. I don't like the idea that people are forced to use my fix. This would only make sense if I take money for my work. :-)

But it's not just supermods, even if the majority of users have them. For example, I myself have been working slowly for a long time in a "custom" supermod built from the old RUB, which basically has just the addition of many separate mods I have been collecting and some work by me. For me adding that to your fix would be most useful, in fact I am considering using my mod package intentionally as a basis for your patch, so that all posibilities can be fully used :up:

Also, I think that if you add the buoyancy, we could rip it off NYGM in a future patch as optional or whatever.

Of course, if the programming of this buoyancy is too complicated, then it will not be worth the effort, but if you find it to be a relatively simple thing, then I would beg to add it so that all posibilities are open.

Again I'd like to raise the question of creating in teh future a very simple interface for your tool, where you would be presented with a screen listing all possible fixes and you simply tick/untick those you want to use, then press the button to apply them :yep:

h.sie

12-15-10, 02:55 AM

@Hitman: I'll look into the buoyancy issue (in conjunction with silent running, as Stiebler suggested), and if it can be fixed in a halfway easy way, I'll try to do it. It will be switchable in order to prevent from conflicts.

And I also planned to make a configurator program (user interface) which makes switching (activating/deactivating) some or all of my fixes easy. This I'll do if I finished patching - what could mean: never!

By the way: There have been five (5!) requests from users for "co-operation" regarding this "project". My callback, how such a co-operation could look like, have never been answered concretely. Really funny. So I decided to work on my own. But such a configurator program would be a good starting point for a co-operation. All the young and highly motivated programmer needs can be seen in post #679:

http://www.subsim.com/radioroom/showpost.php?p=1552245&postcount=679

NGT

12-15-10, 12:35 PM

Question: Is there any reason to NOT include the 4GB patch into my patches?

So there would be no need to apply the 4GB patch after patching the patch of the patch.

The real question is: how many SH3 players here with less than 4 GB RAM?

Probably, all with XP 32 bits.

Fader_Berg

12-15-10, 02:18 PM

By the way: There have been five (5!) requests from users for "co-operation" regarding this "project". My callback, how such a co-operation could look like, have never been answered concretely. Really funny. So I decided to work on my own.
?!? Yeah right... :shifty:

Well done deriding it in public b.t.w... :88) that really makes sense.

I offered co-operation because a) I want to contribute to this community b) It's fun and creative c) I come from years in open source development and this is the way things get done d) why not.
As I said, I respect that you want to go on your own, and don't want to share your findings (yet?). Please respect me back and don't ridicule my offer.

I wish you the best, good luck and keep up the good work.

h.sie

12-15-10, 02:35 PM

I didn't mention any name, so where is the problem? But I did ask everyone of these guys how such a (well-balanced) cooperation could look like in his opinion (which is the least I have to do in this case of a very sensible and time-intensive work like Hex-Coding a 3D game) - without getting ANY concrete answer!!!!! - which indeed made me laugh, because this behaviour I know from my former job: Others talking about progress and success and I did the job. So it's more the situation I laughed about. Not you. So please, FB, don't take it personally. That really was not my intention. Ok, I am a little bit cynical sometimes. If you would know me, you would understand.

Best wishes, FB!

h.sie

By the way: One guy even talked about merging patches to one SuperPatch. I asked, which patches he could contribute. He didn't answer.

By the way2: My cooperation with Stiebler regarding the "Bad weather fix" should indicate that I have no problem to work together with others and share what I know.

LGN1

12-15-10, 03:00 PM

Question: Is there any reason to NOT include the 4GB patch into my patches?

So there would be no need to apply the 4GB patch after patching the patch of the patch.

As NGT said, I think it's problematic for all people with Win XP 32-bit. So, probably it's not a good idea for many players.

@LGN1: Currently thinking about repairs/detection:

I thought about a simple fix like:

If (REPAIRS) then RISE_DETECTION_PROBABAILITY

or similar. But: Let's assume the following situation: A destroyer is hunting you and throws depth charges everywhere without exactly knowing where you are. Let's now assume, one depth charge causes a minor and uncritical damage. In sh3, the crew immediately begins repairs. This is dumb in this situation and will rise detection probability and the destroyer now can locate you. In GWX life is hard for a kaleun even in the current state, but this change would make it impossible to escape from this situation. Only idea: Delaying the effect of repairs on detection, so that the user has enough time to order silent-running and thus stop repairs.

IIRC, reloading torpedoes increases the detection probability in SH3. As a simple fix one could just do exactly the same for repairs (assuming that repairing and reloading creates the same noise level). A more advanced version would be increasing the probability depending on the damaged items (radio, diesel, batteries,... but one has to keep in mind that the crew always repairs all items in one compartment). However, I think this is not necessary.

You are right that it might be problematic if you have damage. However, I think the answer is that you just have to stop repairs by ordering silent-running before. If some items are damaged that you desperately need to repair, well, then you must live with the increased detection probability...like in real life :smug:

I guess this makes it harder, however, the idea to repair diesels/batteries,... during a depth charge attack without any consequences is just too ridiculous for me. I guess the main thing that really requires repairs during a depth charge attack is flooding.

Cheers, LGN1

LGN1

12-15-10, 03:10 PM

Hi h.sie,

if you still have it take a look at page 24/25 in the Schiffskunde document. There's a list with how loud different things are, e.g., it says that you can hear the persicope going down at a distance of 250m 'mäßig laut' :o Walking in the boat is considered 'laut', talking 'sehr laut' (like working). So, imagine repairing things without creating any noise at these levels.

Cheers, LGN1

h.sie

12-15-10, 03:11 PM

Fader_Berg

12-15-10, 03:47 PM

By the way: One guy even talked about merging patches to one SuperPatch. I asked, which patches he could contribute. He didn't answer.

Way to go h.sie... that's a good one. So much for the respect... :shifty:

I gave you an answer. At the time I had not looked around in the code yet, so I couldn't know anything about the potential, could I? I told you that. If that wasn't good enough for you - fine, but don't jibe at me.
I was going to get back to you when I had something going.

I'm sorry that you think that I want to steal your fame here or brag around on your effort. That was not my intention, so stop insinuate that.

h.sie

12-15-10, 04:45 PM

oh, then I misunderstood you. I thought you wanted to cooperate NOW. what I didn't understand was, how that should work in practice, if you, as you wrote, "had not looked around in the code yet".

what would you think if you were me in that situation??? isn't my reaction comprehensible?

but now I understand: you meant to cooperate in the FUTURE.

fame isn't my intention. only a good sim. 36 downloads of V15D_BETA4 so far. fame??
if (virtual) fame were my intention, I'd focus on graphical stuff.

I neither want to spam my own thread nor I want to argue maybe because of an misunderstanding, so please don't be angry if I stop to continue this dialog now, but of course I'll answer via PM if necessary.

Fader_Berg

12-15-10, 05:39 PM

oh, then I misunderstood you. I thought you wanted to cooperate NOW. what I didn't understand was, how that should work in practice, if you, as you wrote, "had not looked around in the code yet".

Well, I meant now from the beginning. I didn't thought you would mind to introduce me to what you've found out. But when I realized that you didn't want to do that, I respected it and had in mind to come back later for a "trade" - or what ever we should call it.

what would you think if you were me in that situation??? isn't my reaction comprehensible?

No.

I wouldn't think of it much. I've been in that situation a few times with my open source projects. I don't have a problem with it. People join and leave as they wish. They contribute and they fork too if they wish, (the forks contributes too, you know). You think it's a messy sallad, I think it's progress.

I'll drop this now... but don't deride people with good intentions. No one on this forum can possibly (or - I guess - want to) rip you off this work. Most of us just want to contribute if we can.

Have a nice day.

LGN1

12-15-10, 06:26 PM

@LGN1: What about delaying the effect of repair noise for detection, lets say about 1 minute. So you have enough time to decide if repairs should be done or not?

Or, one could only consider repairs but not flooding recovery for detection probability??

Phew!

Hi h.sie,

I don't fully understand why you want to delay the noise :06:

In-game I would do the following: if I think I will get some damage I turn on silent running. When I get damaged I stay in silent running mode, except if I get flooding. In this case I switch off silent running until the flooding is stopped. I think this is realistic :-?

The only advantage I see with the time delay is that it would allow you to check the damage amount (repair times) without increasing the detection probability. You might also argue that it allows you to stop smaller floodings without increasing the detection probability (you can think of this as modeling the effect that when you get flooding from a depth charge the destroyer is deaf for some time because of the explosion). :hmmm:

Anyway, I guess a fix with no time delay would already do a fine job, however, having a small time delay to counter weak flooding might also be a good idea (maybe 30sec. With your longer repair times this small amount does not help you much for doing larger repairs :up:)

Cheers, LGN1

PS: I think the noise from stopping flooding and repairing items is not too different, so I think it's not necessary to distinguish between the two issues.

Stiebler

12-16-10, 06:15 AM

@H.sie:

To address a number of issues raised recently in this thread:

1. Buoyancy issue.
The NYGM buoyancy with XXIPump was created by Der Teddy Bar, whom I can still contact if necessary.
However, I have examined all the posts that DTB made on the subject of the 'Anti Humming Bird' mod, and it seems likely that a common mod for NYGM and GWX (and others) can be made simply as I have suggested earlier.
When silent running is selected (it seems to be toggled in SH3Sim.Act; that is where the switches are listed), then raise the value of 'Mass'. The value of zero in NYGM for mass means only that the surfaced displacement should be used.
Therefore, for a type VIIC, in NSS_Uboat7c.sim, NYGM has mass = 0 (therefore use surfaced displacement of 761 tons). GWX has mass = 760.8, which gives it a slight positive buoyancy. It seems that a value for mass of around 761.5-762 tons ought to cause a slow sinking, when silent running is selected.

2. The 4GB issue for SH3.exe.
There are two easy solutions to this.
a) Provide an extra patch to install the 4GB value in SH3 after installing the patches for V15D. (I think you have provided this previously.)
b) Provide two different check-sum values for sh3.exe with.without the 4 GB patch before installing V15d.

3. Co-operation with H.sie.
I am happy to confirm that H.sie has given me a lot of help with my work on adjusting windspeeds for the bad weather fix. Both in these threads and by PM. I hope he would agree that I have tried to give a lot back.
I know also from my own experiences with computer programming outside SH3 that, when someone asks for a 'co-operation', what that person really means is 'I will tell you what I want, and you can do all the work, while I give you lots of reasons why I cannot complete the share of the work that I promised.' Unfortunately, this does tend to make one suspicious of other people's motives.

Stiebler.

h.sie

12-16-10, 06:58 AM

"Unfortunately, this does tend to make one suspicious of other people's motives."

I couldn't find better words that those, since I am not a native english speaker. My behavior is the result of what I've seen in the past. This could lead to be unfair in some cases. So IF I were unfair, I apologize.

As I said in the Readme of the Bad Weather Fix: That fix wouldn't be there without the co-operation with Stiebler and the help of Hitman.

SquareSteelBar

12-16-10, 07:13 AM

...2. The 4GB issue for SH3.exe.
There are two easy solutions to this.
a) Provide an extra patch to install the 4GB value in SH3 after installing the patches for V15D. (I think you have provided this previously.)
b) Provide two different check-sum values for sh3.exe with.without the 4 GB patch before installing V15d...This is not really an issue...

There's is already a patch (http://ntcore.com/4gb_patch.php) that works independently of checksum and file size.

Simply apply it after h.sie's patch...

h.sie

12-16-10, 07:20 AM

Yup, one can apply the 4GB patch after V15X. But I thought to make peoples life easier by directly put 4GB patch into V15X. But that seems to be no good idea. h.sie

Hitman

12-16-10, 07:48 AM

Please Fader_Berg and h.sie, would you take the conversation to private messaging if there any more issues to resolve? I see you had some sort of misunderstanding, but cluttering the thread and solving it publically is against the customs here,and it will also make the end of your controversy more difficult. Thanks, I'm sure all will be cleared and no harm done :up:

h.sie

12-16-10, 08:03 AM

h.sie

12-16-10, 05:04 PM

Released: V15D4 for NYGM.

Same as V15D4, but with repair time fix disabled, for NYGM users who have compatibility problems.

h.sie

LGN1

12-16-10, 05:47 PM

@LGN1: Imagine the following situation: A destroyer hunts you without exactly knowing where you are, so he throws depth charges randomly. one of these depth charges causes a little damage of an unimportant instrument, say, the coffee machine. In real life the crew would NOT start repairs, because this would cause noise. But in sh3, the crew would immediately start repairs, so that your position will be known by the destroyer. My idea was to delay the effect of the repair noise on detection probability, so that you have about 1 minute time to look into the damage screen and decide if immediate repairs are really necessary or not. If not, you have time to order silent running.

Best solution would be a dialog like "System damaged, Sir. Should we start repairs? Yes, No, Cancel". But new dialogs are heavy for me, maybe impossible, because they change program flow.

Hi h.sie,

if you have ordered silent-running before getting hit the crew will not start repairing. I guess it's quite sensible that you should be running in silent mode when there are destroyers close :hmmm: As I said earlier, I interpret the silent-running order in the way 'Guys, don't reload torpedoes, don't repair anything, and don't breath too much :)'

Anyway, I was thinking that a fix without a delay is much easier and would do the same. However, if it doesn't make any difference a time delay is also fine.

Cheers, LGN1

Magic1111

12-16-10, 05:50 PM

Many thanks h.sie for all your fantastic MODs !!! :yeah:

I use four of your MODs (Bad weather Fix; V15D4; No continuous ship...; ColoredHull...) and I must say, I can´t play without these MODs !

I´m very happy with your MODs and I wish you all the best for your work to make SH3 better and better....:salute:

Best regards,
Magic

Stiebler

12-17-10, 05:44 AM

Released: V15D4 for NYGM.

Same as V15D4, but with repair time fix disabled, for NYGM users who have compatibility problems.

h.sie Thanks very much, H.sie.

Stiebler.

h.sie

12-17-10, 06:06 AM

"and I must say, I can´t play without these MODs !"

@Magic: Thanks very much for feedback! If some guys like you really cannot play without my mods, time has come to think about including DRM.

coronas

12-17-10, 08:24 AM

Same as V15D4, but with repair time fix disabled, for NYGM users who have compatibility problems
Thank you, master!
:salute:

Dani

12-17-10, 11:13 AM

Released: V15D4 for NYGM.

Thanks!:salute:

Silent Ace

12-18-10, 05:52 PM

@H.sie:

Sea water into sections with batteries led to the production of toxic chlorine gas inside the submarine, which would SH3-GWX can be simulated as the rapid growth of CO2.

Hitman

12-19-10, 04:49 AM

Playing a bit yesterday I remembered something else that has been wished for everyone for a long time ago :DL

Would it be possible to change the action to follow when sighting an airplane from "dive to periscope depth" to "crash dive"? (pop-up window that appears 1st time you sight one)

h.sie

12-19-10, 01:43 PM

@LGN1: Regarding: Repairs affect Detection Probability:

I found the memory position and the code responsible for the detection probability (DP). But changing DP manually only changes the colour of the stealth meter (this ugly ship symbol that indicates the DP) but does not change the behaviour of the enemy. So this variable is only for generating output but cannot be used for controlling something.

I found no other DP variable that could be used to control something similar to your initial idea: Simply rise this variable in order to rise the probability that the enemy detects you.

So I looked deeper into the code and found that DP is calculated from 4 variables: One for engines sound level, one for visibility of the Uboat and the other two I don't know. The idea is obvious: I tried to rise the variable that contains the engines sound level in order to simulate repairs sound. But no change of the enemy behaviour. So the situation is clear: These variables also are only for generating output but cannot be used for controlling something.

So I looked one level deeper into the code in order to understand how this engine sound variable is calculated. This search lead me from Sh3.exe into Sh3sim.act which, if I see things right, deals with sound sources and controllers and so on. So I assume, things are much more complicated than just rising a variable in order to simulate repairs sound. I assume one has to add a separate sound source or similar for repairs, but without SDK this is impossible for me.

I think now, detection is a complicated interaction between the enemy ship and your sub and is not controlled by a simple DP variable. I fear to mess around with sound sources and controllers in Sh3sim.act, and I'm very pessimistic that I'll be able to do the job.

BUT: As you wrote above: "I guess it's quite sensible that you should be running in silent mode when there are destroyers close".

That means: If you follow your own rule to order Silent-Running when destroyers are close, there will not be any repairs that could betray your position -> This problem can be solved by discipline.

LGN1

12-19-10, 02:19 PM

Hi h.sie,

thanks a lot for all your efforts! :yep: It's a pity that it seems to be so complicated :hmmm: I have only one idea that might be useful: if privateer is right, torpedo reloading increases the DP, so I guess one of the four variables is connected to torpedo reloading (he mentioned RPMs and reloading). Maybe it's possible to trigger the 'status reloading' when repairing :06: ,i.e., abusing the torpedo reloading noise to simulate repairs :hmmm:

Anyway, thanks again for all your efforts so far. Even without the increased DP your work is a huge step forward!

Cheers, LGN1

Concerning your edited comment: You are right as long as you don't have to do repairs. However, as soon as you HAVE to do repairs it's not becoming more dangerous for you (if DP is not increased). In other words, you can easily enforce the 'house rule' that you don't do any repairs during an attack, however, this does not help you in the situation that you have to do repairs and live with the increased sound/risk in real life.

h.sie

12-19-10, 03:10 PM

@LGN1: I'll try to "abuse" torpedo reloading sound for repairs in the next days. maybe easier, since it's perhaps only an ON/OFF flag - we'll see. If that won't work, I'll give up.

@Hitman: Couldn't your "problem" easily be solved by hitting "C" everytime bridge crew reports aircraft? Even simple fixes are hard for me to program and thus I prefer to concentrate on essential bugs/issues.

Hitman

12-19-10, 03:59 PM

@Hitman: Couldn't your "problem" easily be solved by hitting "C" everytime bridge crew reports aircraft? Even simple fixes are hard for me to program and thus I prefer to concentrate on essential bugs/issues.

Well of course, but the standard action is good for when you play a bit away from your computer. Not all players like to stare at the screen seeing the dot move at 256x TC, so I for example like to let the game run and meanwhile classify papers, do some house maintenance, etc. In those situations, the seconds away can mean death if an aircraft pops up :haha:

But no problem, I just throw the idea in the air because it could happen that you say "Oh yes I noticed that when looking at the code and it would be an easy 5 minutes fix". If it takes more than those 5 minutes, then as you say it's better to keep your efforts on other more important things :yep:

h.sie

12-20-10, 04:21 PM

@LGN1: There is something very irritating regarding silent-running:

In a special adjusted test mission with a destroyer in 2000m distance I fine-adjust engines rpm (without silent-running) in order to have a detection probability of DP=5, which is equal to an orange/brown colour of the stealth-meter. (DP in game is understood as the average number of minutes until enemy will detect you).

This state is very labile, because the stealth meter either has the tendency to get red or green, but that's practical to see, what else affects DP.

Now I shoot one torpedo (which the destroyer seems not to hear). DP is unchanged 5. The crew starts to reload, but the DP is still 5. Now I take all crew out of the bow torpedo room, so that no reloading can be done. DP is unchanged about 5.

Now I order silent-running. DP=1000, Stealth-meter green.

For me that means, that reloads do not affect DP directly.

But ordering silent running does. This I don't understand.

Result: Reload work sound cannot be taken for simulating repair sound.

By the way: DP is calculated from 4 variables. None of these 4 changes if I start/stop torpedo reloading.

LGN1

12-20-10, 04:34 PM

Hi h.sie,

can it be that when you ordered silent-running the rpms dropped and therefore the stealth-meter went green :hmmm:

Concerning torpedo reloads: maybe the sound of reloading cannot be heared at a distance of 2000m :06:

Anyway, my knowledge about the torpedo reloading is just from this comment/post:

http://www.subsim.com/radioroom/showpost.php?p=1442676&postcount=5

It might be good to get privateer into the discussion.

Cheers, LGN1

LGN1

12-20-10, 05:15 PM

I have tested it myself and you're right, h.sie. Ordering silent running even at 0 rpms changes the color of the stealth-meter to green. At least concerning the stealth-meter it seems that the findings in this thread http://www.subsim.com/radioroom/showthread.php?p=1442676#post1442676 are wrong :hmmm: Maybe the stealth-meter is more eye-candy in this case :-?

Anyway, it seems that the issue is more involved than I thought. Maybe without further input it's better to leave it alone.

Cheers, LGN1

h.sie

12-20-10, 05:31 PM

@LGN1: No, the rpm is so low, that it isn't reduced when ordering silent-running. So rpm is unchanged. If I see things right, DP MAINLY depends on Silent-Running and engines rpm, but not (directly) on torpedo reloading.

New discovery:

If I reduce distance to destroyer from 2000m to 1800m, stealth meter is orange/brown even without engines running. Nice balance. Color does not change if I allow/disallow torpedo reloading by moving crew in/out of torpedo rooms. But it gets green when I order silent running.

If I reduce distance to destroyer to 1600m, stealth meter is dark-red even without engines running. So for this distance and lower there is no need for additional repair sound, because you'll be detected soon even without it. But stealth meter gets green when I order silent running.

So if I see things right, it would be nice to have a effect of repairs sound for longer distances > approx. 1800m.

I could give you my test mission for own testing.

One thought: I think life is hard enough for Kaleuns, especially in GWX, so I fear to make it even more harder. And I also think, the GWX and NYGM team spent many time in fine-adjusting sensor balance, and so I fear to break that, at least as long as I don't fully understand how things work.

But I'll not give up so fast.

h.sie

12-20-10, 05:42 PM

I forgot: My missions are in March 1944 with a Hunt II destroyer.
Maybe things look different in 1939.

Edith: Same behaviour in 1941.

Edith2: I think it makes sense to first find out if the stealth meter and DP really are strongly correlated to the behaviour of the destroyer and not only eye-candy.

Stiebler

12-21-10, 07:32 AM

@H.sie, LGN1,

The behaviour you are describing with the stealth meter may vary between super-mods. NYGM and GWX definitely have different detection models.

For NYGM, it is essential to go to silent running to avoid detection by a destroyer which is close, although it also depends on the stage of the war and the competence of the destroyer crew. Destroyer hydrophones and asdic are *much* more effective in late 1944 than 1939!

The 'state' of the U-boat is described within the SH3.exe code, where it can be 'hunter' or 'prey', or 'silent-hunter' or 'silent-prey', among other states. This state presumably is set with the 'statemachine.dll' code.

Stiebler.

h.sie

12-22-10, 12:00 PM

Thanks, Stiebler, but I put this topic back to the long to-do list, until we have more information, currently I fear to do changes. h.sie

next topic: buoyancy/silent-running

Silent Ace

12-22-10, 03:26 PM

Data on the maximum amount of air inside a ww2 submarine for 72 hours was incorrect.

LGN1

12-22-10, 04:01 PM

Data on the maximum amount of air inside a ww2 submarine for 72 hours was incorrect.

Hi Silent Ace,

in the original U-Bootskunde document from 1940 for the VIIC is written on page 85: 72 hours for 37 men.

Why do you think this is wrong? What should be the right values? What are your sources?

Cheers, LGN1

h.sie

12-22-10, 04:20 PM

Hi Silent Ace;

thanks for replying. I now also remember an older post of you regarding CO2/batteries. I also had that idea, but programming that isn't easy, so I set in on the todo-list for later, with more experience and after all essential fixes are done. I also like the idea to simulate defect batteries / chloride.

What in your opinion should be the correct diving-time / where did you get your information from?

h.sie

Silent Ace

12-22-10, 04:27 PM

Hi Silent Ace;

What in your opinion should be the correct diving-time / where did you get your information from?

comparative analysis of submarines incidents and the Russian documents

LGN1

12-22-10, 04:42 PM

Thanks for the answer, Silent Ace. What should be the correct time according to your sources?

Cheers, LGN1

h.sie

12-22-10, 04:46 PM

And: Which documents exactly? references? very curiuos.:)

Tessa

12-22-10, 10:24 PM

I also like the idea to simulate defect batteries / chloride.

Hiya h.sie

Sorry for the dissapearance, got sick and didn't start playing again till couple of days ago. It's been awhile but this is an idea you already had that we had started discussing about a month ago. In lieu of getting everything else finished you decided to put it aside for the time being, both of us agreeing without sdk this will be a major challenge.

For the mod to be realistic crew in the battery sections will have to take damage while they are in the exposed areas. An out of box solution I came up with is (would need to ask a GWX developer if its possible) to have a small mine detonate directly under that room, everyone in that compartment will take some damage as they would taking in lungfills of acid; albeit all at once.

Obvious potential road block is deliberating getting a mine with a very small yield to explode at a specific location only, and also have no clue as to simulating people that spend prolonged periods in exposed compartments to take more damage (gradually loosing hp like you do with resilience with fatigue on) without setting off another mine at set (but partially randomized) intervals to simulate further damage from expose, and to make anyone that is 100% health that goes into the compartment so that they'll take damage. One easy cheat would be to just swap out crewmen after they've been exposed, so they wouldn't take more damage - thus the need for continuous mine hits so that fresh people going in don't get a free ticket to do the repairs. Maybe have the mine detonate every 5 minutes +/- 3 minutes?

Since the reaction itself doesn't consume all its fuel at once, acid will continue to pour out until it either runs out of water or depletes all the batteries. Using the flooding models might be workable, just don't make the compartment implode if it fills up to 100%. While this wouldn't model the physical damage you take from the fumes it could effectively seal off a compartment if it isn't fixed in time. You could lengthen battery repair times and increase flooding in that compartment to simulate the buildup of gas. The flooding would obviously need to be greatly increased such that the bilges don't clear it before the batteries are repaired. Then if/when they fill to 100% they stay flooded such that they can't be cleared by the bildges to simulate a lethal enviroment (have inhaled my fair share of toxic fumes in my chem and o-chem labs back in college, a room full of acid like that would either kill you after 15-30 seconds of exposure or cause you to pass out, which you breath in 100% contaminated air killing yourself anyways).

Now that I'm in port am adding on some new mods (MaGUI widescreen, and see if I can get the merchant fleet mod working). Since I'm a 4gb patch user I can't just add this mod in easily like most others. Which is the file that gets modified? I don't relish the idea of uninstalling and re-installing; but could install to an alternate location, add GWX and then move over the virgin file(s) into my main folder. Afterwards apply this mod and then the 4 gb one and step right back into my current career.