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

Tessa

12-24-10, 01:00 PM

@Tessa: If I start to model chloride/battery damage, I'll try to directly affect crew health values instead of modelling it by exploding mines. To be honest: I fear these changes, because I fear changes are too complex for being fixed in Assembler.

Unfortunately, I don't understand your last question about 4GB patch. But anyway I give you an answer:

1) Make a backup of your original sh3.exe

2) Patch it to V15D

3) Apply 4GB patch.

This should not take longer than 3-7 minutes. If something went wrong, restore original sh3.exe.

h.sie

Hi h.sie

Regarding the 4gb I think I have the info I need. To install this mod correctly it needs an unmodified sh3.exe file? All the changes your mod makes directly changes the sh3.exe file, or does it modify any other files as well? Additionaly, down the road if/when you get the battery gas mod working will you most likely need to repeat the same process used to install the mod now (since I need the 4gb patch which modifies the sh3.exe file, would I then need an unmodified sh3.exe to apply the new mod to)?

Being able to damage the crew directly would be the quickest and easiest way to model the effects; as you point out it will be difficult. After looking at some of the modding/developer tools I didn't see any direct way of doing what needs to be done, I fear that the result may end up in a ctd. Without a direct source of damage to make the crew start loosing health (from the games perspective) for no apparent reason is likely to conflict with controls in place causing a ctd.

If there was a way you could invert the healing function that might be another place to look. Since the batteries are located in the rooms required for an injured crew member to recover health, inverting the function to do the opposite could produce stable results. Upon entering the room instead of beginning to recover you would just start to loose health.

I have very little experience when it comes to assembly code, I know you can pretty much use it to manipulate the machine into doing anything you want it to, even if it violates rules that will cause other problems leading to a core dump/endless loop. The game may continue to run perfectly until that function is needed and then you get an immediate ctd. I fear that is going to be the likely outcome w/o the sdk or a developer that worked on/is familiar with how the game calculates and causes damage to crew members when the ship is damaged from dc's or airplanes.

somedude88

12-24-10, 02:42 PM

CherryHarbey

12-25-10, 04:29 AM

If it decreases crew efficiency in repair, doesn't it effect all the other compartment efficiency as well?

Also I can't seem to get your mod to work properly, even though I installed the fixes, the integrated orders, WB's renown replacement, damage effects and lifeboat and debris mods don't work...

This patch doesn't reduce crew efficiency, it changes the Sh3.exe in order to multiply the repair time by a factor of 60.
It shouldn't cause mod conflicts either, I use the lifeboats, damage effects and integrated orders and this patch without problems.

Have you implemented LRT (Longer repair times) mod? If so then this will cause you problems as it is trying to do similar things to H.Sie patch. You don't need both.

In my opinion H.sie patch (from which you can download from his mediafire site) is the way to go.

If this isn't your issue, then I think you will need to post more details of what exactly you have done and what exactly isn't working.

Hope this helps.

h.sie

12-25-10, 10:56 AM

Thanks CH for helping while I celebrate christmas

CherryHarbey

12-25-10, 12:11 PM

no problem.
season's greetings.

somedude88

12-25-10, 01:07 PM

I got it working, just installed the patches in the wrong order. Thanks!

CherryHarbey

12-25-10, 01:08 PM

no problem,
I'm glad you got going.

h.sie

12-27-10, 08:13 AM

@Stiebler: I already found the memory addresses where the sub's mass and displacemant are stored after the readin process from NSS_UboatXX.sim file. But changing these variables in-game in the debugger does not change the sub's depth position. So things are a little bit harder than you initially thought.

I think the most important thing is to find out how the current depth of the sub is calculated and so to find out from what parameters it depends.

In Sh3.exe+A1D97 depth is calculated from a value which is taken from the stack. This could be a starting point.

h.sie

Edit: In Sh3Sim.act+30DF5 one can find some interesting code. According to this code the current depth of the Sub is coded in float format and gets more negative when sub is deeper under water, so it's something like a Z-position. if you set it to +10, the sub can fly. Cool. There is also a depth change value dZ. If it's positive, the z-value is rising, otherwise falling.

Sh3Sim.act+30DF5:
fld [esp+30] // Loads depth change value dZ
fadd [esi+b4] // Adds dZ to current Z value, Z := Z + dZ
fstp [esi+b4] // stores new Z-value.

Now I need to know how this depth change value dZ in [esp+30] is calculated.

Silent Ace

12-28-10, 10:53 AM

Submarines in World War I remained under water, 50-10% of total time spent on the combat mission.
During World War II, this time increased to 30-35%.
Record time remaining in the submerged condition for WW2 reached the German submarine U-258 (Type 7C) and it is 38 hours.
Other times the length of stay under water a submarine U-744 (Type 7C) and it is 30 hours.
Recall that the 33 surviving crew of 55 on the U.S. Squalus the time of the accident had reserves of oxygen for up to 48 hours but were rescued within 39 hours of the sinking. Link-http://www.lostliners.com/Peril/squalus.html
59 crew members of HMS Thetis had available air for 36 hours stay under water but that the total number of crew and guests on the submarine was 103 men at two times higher than normal, the amount of available oxygen is reduced to only 18 hours. Link-http://www.angelfire.com/co3/submarinethetis/thetis.htm
Apparently the 50 crew members of the Soviet submarine L-271 submerged in theautumn of 1941 in the Baltic Sea survived 50 hours inside their submarine before they were all suffocated .
But on this case does not have enough data.
Time periods of stay under water at the first postwar Soviet submarine project PR.613 Whiskey which is a direct descendant of the German Type 21 is 200 hours with the use of chemical substances (mixture of calcium oxide and sodium hydroxide or lithium hydroxide) for the regeneration air. Link-http://militaryrussia.ru/blog/topic-203.html
If they did not regenerate the air on the USS Pennsylvania (SSBN 735) oxygen would be for 7 days under water.
One man during an hour is in need of 25-28 liters of oxygen and exhales 22-25 liters of CO2.
The content of CO2 in the air section should not be higher than 1-1,5% and O2 can not be less than 18% and not more than 24%.
When these standards in the free space of 2 m3 of a man cut CO2 concentration is reached within one hour.
Conclusion is that you first need to eliminate CO2 from inside the submarine, but need to renew the content of O2 in the atmosphere submarine acceptable 20-21% in order to extend the continuous stay of the crew diesel submarines under the water with the normal 38-48 hours at a respectable 72-80 hours or longer .

Cheers!

B.N.R.T.

12-29-10, 07:26 AM

Ok, I've got a perhaps stupid question. I tried searching the thread, but nothing came up. Is the Long Repair Times Mod compatible with GWX? Can I just 'install' it over the GWX .exe file? I'm not sure if that is "unpatched, uncracked, unhacked". Perhaps an edit to the first post for noobish questions like mine?

Delareon

12-29-10, 08:20 AM

it is compatible, only incompatibility i know so far are other Longer Repair Time Mods.
So just take your current GWX installation, take the .exe and follow the instructions from the first post.
The tool automatically makes a backup of your previous .exe if anything went wrong or u want to deactivate the mod.

B.N.R.T.

12-29-10, 09:20 AM

Great, thanks for the quick answer!:DL

Now, I'll just have to make it make to Lorient to start a new patrol...

h.sie

12-30-10, 09:54 AM

LGN1

12-30-10, 03:41 PM

No further progress regarding negative buoyancy and silent running/pumps so far.

But I found the code resonsible for reloading external torpedo tubes. As a first attempt I plan to connect the external reloadings with the storm-conditions for deck- and flak gun. that means: the time counter that shows the time remaining for reloading externals, will only decrease, when the storm-conditions are NOT met. otherwise, if storm conditions are met, the time counter

a) could stay unchanged, or better:

b) could be reset to it's initial value, so that the reloading has to be started from the beginning (which also happens when one dives during reloading).

If that works, we can talk about the second part:

Program some penalty when one dives during reloading, but I have to damp down too high expectations regarding this.

h.sie

Hi h.sie,

great work as with the weather-change settings :up: Thanks! Do you think it might be possible to also connect the internal torpedo reloading with the storm condition so that you can only reload internal torpedoes when submerged (in a storm)?

Concerning diving when reloading external torpedoes: It might be a good idea to increase the dive time considerably (via the flooding time in the sim files) when reloading so if you want to dive it takes a long time :hmmm:

Cheers, LGN1

h.sie

12-30-10, 06:02 PM

@Tessa: Sorry for late reply. Yes, you need an unmodified sh3.exe. The patcher only modifies the sh3.exe and no other file. But if there are other files needed (V15D and later needs CameraBehaviuor.act), they come in an JSGME ready format and thus must be enabled via JSGME.

@Silent Ace: Thank you for your research report. The most interesting part is (because it's about german subs, the rest is american/russian):

Record time remaining in the submerged condition for WW2 reached the German submarine U-258 (Type 7C) and it is 38 hours. Other times the length of stay under water a submarine U-744 (Type 7C) and it is 30 hours.

Could you please point out from where you got your information above (Link, Reference). Thank you very much.

@ALL: Any other historical information about diving times?

h.sie

h.sie

12-30-10, 06:04 PM

Do you think it might be possible to also connect the internal torpedo reloading with the storm condition so that you can only reload internal torpedoes when submerged (in a storm)?

This I don't understand. Why should it only be possible to reload internal torps when submerged and in storm????

Concerning diving when reloading external torpedoes: It might be a good idea to increase the dive time considerably (via the flooding time in the sim files) when reloading so if you want to dive it takes a long time.

Good idea. I think the most realistic way would be to cause some heavy flooding and some lost torpedoes when dive during external reload, but that will be hard to program, so your idea could be easier to do. What delay for diving could be realistic? 10 minutes?

h.sie

Delareon

12-31-10, 02:12 AM

This I don't understand. Why should it only be possible to reload internal torps when submerged and in storm????

Well i think he wants to say that IF you are in a storm, reloading of internal tubes should only be possible when submerged (Anything with external tubes should also be impossible though).

Hartmann

12-31-10, 10:28 AM

h.sie

12-31-10, 11:29 AM

(deleted)

LGN1

12-31-10, 01:44 PM

This I don't understand. Why should it only be possible to reload internal torps when submerged and in storm????

Good idea. I think the most realistic way would be to cause some heavy flooding and some lost torpedoes when dive during external reload, but that will be hard to program, so your idea could be easier to do. What delay for diving could be realistic? 10 minutes?

h.sie

Hi h.sie,

I wanted to say what Delareon has written. In a storm you can only reload torpedoes when submerged, i.e., you can only reload internal torpedoes and you need to be submerged (your boat must not move/roll too much).

I think a penalty of 10 min would be fine. Depending on the reloading status it might be 2 min as Hartmann has written (at the beginning and end of the reloading process) or perhaps even more than 10 min (if torpedo is partly in the sub :06:). I guess in real-life it varied a lot.

I some old thread someone came up with 10 min as a house rule.

Maybe someone knows if it ever happened that a boat had to dive during external reloading :hmmm:

Guter Rutsch, LGN1

LGN1

12-31-10, 01:49 PM

Record time remaining in the submerged condition for WW2 reached the German submarine U-258 (Type 7C) and it is 38 hours.
Other times the length of stay under water a submarine U-744 (Type 7C) and it is 30 hours.

@Silent Ace: Do you know why U-258 surfaced? Did they have to surface or did they surface because there was no danger anymore?

Cheers, LGN1

h.sie

01-01-11, 08:16 AM

CherryHarbey

01-01-11, 11:00 AM

Happy new year to all!

POLL / Discussion:

What should I program if the reloading process of external torpedoes is disturbed by storm?

A) Pause the reloading process, so that it can be continued at the same state after the storm.

B) Reset the reloading process, so that the crew has to start reloading from the beginning when the storm ended.

----------
I prefer B)
----------

between the two options given I would say B.
Can I add in option C, continue reloading process but bring in random chances of torpedo loss/crew injuries/crew fatalities.
Is it not just one of those jobs that you would not start in bad weather but once started see through to the end regardless of how the weather changes?

Sailor Steve

01-01-11, 11:11 AM

I keep rereading the instructions and being too scared to try anything that serious, but I really want to try this. Pardon me for being stupid (which I don't deny), but how do I do step one:
Step 1:
Create empty Working Directory somewhere on your Disk (where you have write permission.)

h.sie

01-01-11, 11:34 AM

h.sie

01-01-11, 11:36 AM

@SailorSteve: You are one of the most popular persons here, and I'm sure there is someone who offers help by doing the patching for you. If not: I'll do that.

If you don't know how to create a directory, I strongly suggest to ask someone for help. Not everyone is a computer expert, and not being able to create a directory has nothing to do with stupidity.

h.sie

Silent Ace

01-01-11, 12:58 PM

@Silent Ace: Thank you for your research report. The most interesting part is (because it's about german subs, the rest is american/russian):

Record time remaining in the submerged condition for WW2 reached the German submarine U-258 (Type 7C) and it is 38 hours. Other times the length of stay under water a submarine U-744 (Type 7C) and it is 30 hours.

Could you please point out from where you got your information above (Link, Reference). Thank you very much.This is part of my sources of information and there are even books in PDF format as well as military and naval Commons from the public library.
http://img529.imageshack.us/img529/6273/p1010309p.jpg

specifically here:
http://img811.imageshack.us/img811/2818/picture1ss.jpghttp://img810.imageshack.us/img810/3250/imgro.jpg

@Silent Ace: Do you know why U-258 surfaced? Did they have to surface or did they surface because there was no danger anymore?

Cheers, LGN1

have emerged because they had stopped a threat to them, but given the fact that the submarines are normally carried out during the war and an average of 20 hours when compared with other data presented here think that their maximum stay under water was 48 hours and the American and British submarines of similar displacement and number of crew members.

Magic1111

01-01-11, 01:34 PM

Stiebler

01-01-11, 02:07 PM

@H.sie:
[Happy New Year!]

Edit: In Sh3Sim.act+30DF5 one can find some interesting code. According to this code the current depth of the Sub is coded in float format and gets more negative when sub is deeper under water, so it's something like a Z-position. if you set it to +10, the sub can fly. Cool. There is also a depth change value dZ. If it's positive, the z-value is rising, otherwise falling.

Sh3Sim.act+30DF5:
fld [esp+30] // Loads depth change value dZ
fadd [esi+b4] // Adds dZ to current Z value, Z := Z + dZ
fstp [esi+b4] // stores new Z-value.

Now I need to know how this depth change value dZ in [esp+30] is calculated. Many thanks for this information.

But why do you need to know how dZ is calculated?

Much simpler just to insert some code with a test for the silent-running state.
If true, then subtract a small value 'delta' from the new Z-value. Otherwise, leave the Z-value alone.

That seems to provide a complete solution. The only issue is how large the value should be for 'delta', and I think only testing will provide the answer.

Concerning problems of reloading torpedoes:
1. I think 10 minutes to dive is correct, if the reloading is interrupted by an attack.
2. I do not think that there is a problem with the issue of bad weather interrupting the reloading. The reason is due to the difficulty to the player of discovering when the weather is good enough to start reloading. The player, using time compression, will always start reloading long after the weather is good enough. Therefore, it is fair (equitable) as compensation that reloading should be allowed to continue even if bad weather commences.

Stiebler.

h.sie

01-01-11, 06:16 PM

@Stiebler: Best wishes for the new year!

I fear very much to manipulate the dZ value because it's the resulting value of a complex physical model which considers wave amlitudes, ship mass, displacement and so on. It is never constant, since it also controls the Subs movement in Z direction on the waves. If I simply change dZ or add a small value to it, the Z-position of the ship is no more consistent to the physical model and surrounding conditions. So in my tests I had flying Uboats as well as a crew on the bridge when submerged (which indeed is nothing new for sh5 players). I didn't manage to fine-adjust the dZ value to realize a similar behaviour to the Anti-Hummingbird mod: very slow sinking.

If I add a very slow offset to dZ, the physical model corrects this disturbance, so that my manipulation has no effect.

If I add a bigger offset to dZ, the physical model isn't able to correct my manipulation and the sub goes down or begins to fly.

So I think the only way to get negative buoyancy is to affect the mass / displacement proportion of the ship, in order to have always a correct Z value according to the surrounding physical conditions. But unfortunately, until now I did not find a way to manipulate the mass / displacement proportion.

I like the Anti-Hummingbird mod, which I use in my private SH3 installation. What is wrong with it? What is the weak point, which you want to eliminate?

h.sie

Edith: I think dZ in Sh3Sim.act+30DF5 isn't the right place for a manipulation, but it can lead us to the right place. I gave you that information about Sh3Sim.act, hoping you could help. Two seekers are better than one.

Tessa

01-02-11, 05:54 AM

Concerning problems of reloading torpedoes:
1. I think 10 minutes to dive is correct, if the reloading is interrupted by an attack.
2. I do not think that there is a problem with the issue of bad weather interrupting the reloading. The reason is due to the difficulty to the player of discovering when the weather is good enough to start reloading. The player, using time compression, will always start reloading long after the weather is good enough. Therefore, it is fair (equitable) as compensation that reloading should be allowed to continue even if bad weather commences.

Stiebler.

If its possible, I'd suggest another scenario. Base the diving time proportional to how close you are to completing the transfer. Depending on the % you can have several different actions:

0%-25% you're able to shove the torpedo back into the container and dive in 5 minutes.

25%-50% you're far enough along in reloading that it can't be put back into the container and must be dumped overboard. To get everything sealed up takes 10 minutes.

50%-75% Torepdo is partially in the compartment at this point, only option is to drop the torpedo into the torepo room; while at the same time each person in the compartment takes some amount of damage and maybe a few fatalities. Diving takes 15 minutes.

75%-99% Torpedo can be safely dropped without damage to the crew but too much equipment is already out and can't be quickly put away. Sub has to submerge with open compartments and the torpedo rooms will start flooding. Dive time is 5 minutes, but afterwards must stay surfaced for at least 15 minutes in order to correctly put everything away to avoid flooding.

You could also add that there must be no damage to the forward deck, if its damaged or destroyed the appartus used to slide the torpedo into the compartment is also a casualty. Thus, you cannot move any more external torpedoes (if the deck is destroyed) or wait for repairs to complete before the transfer process can start.

CherryHarbey

01-02-11, 06:12 AM

@CH: I had the same idea like you: If the boat dives during reloading, some compartments will be flooded and crew injured or die. but this reqires an menu option to warn the crew to hurry up with reloading/interrupt reloding process, which is very hard to do. And: I don't want to spent much effort to program a situation/option (dive during reload externals) which a kaleun would never choose.

So the much more easy solution is to simply delay the diving by a certain time, which is hard enough.

Delaying the dive is the way to go for the attacked by enemy scenario, but if is for worsening weather, I don't think the crew would abandon the task just because of worsening weather.
Could this work.....
If task is over half complete when weather gets worse - allow to continue.
Less than half complete, 10 minute dive penalty and reset to task not started.
As always, it is easy to throw around suggestions, much harder to write code to do it, so if it is not practical, then feel free to ignore.

h.sie

01-02-11, 06:37 AM

Oh, cool, I can now manipulate the Diving Tank and the Depth Rudders. USeful

Stiebler

01-02-11, 07:27 AM

@H.sie:

Thanks for the feedback, and the complications of changing the dZ value. Pity.

There is nothing wrong with the anti-humming-bird mod, and no need to alter it.
However, it causes the U-boat to sink only when it is stationary.
I was hoping for a mod which will cause the U-boat to sink slowly, when running at slow speed (2 kts or less), when silent-running. Under these conditions the pumps are switched off, so the U-boat should fill very slowly with water (become heavier) and sink.

[There is a bug in the SH3 model, which causes an interrupted crash-dive to leave the U-boat dived at an angle/inclination - the 'crash-dive blues'. Under these conditions, it is hard to control the depth at slow speed. Perhaps this would be an alternative route to provide a solution to what is required. When the U-boat is silent-running, cause it to change its inclination a little. Then it will start to sink slowly. However, perhaps this would be a very complicated and unnatural solution.]

Stiebler.

Hitman

01-02-11, 10:01 AM

There is nothing wrong with the anti-humming-bird mod, and no need to alter it.

IIRC it broke the pump system of the Type XXI :hmmm:

What I'm not sure is if it also brakes the pump system of any sub replacing the XXI, f.e. the XXIII, but I suppose not.

The XXI in Sh3 is above all a "free" slot which you can use to add different subs to the already playable ones, and with specific characteristics (F.e. the VIIC/41, The VIID, etc.). For me, the XXIII is a permanent replacement of the XXI, so I can have always historically correct submarines :up:

Stiebler

01-02-11, 11:02 AM

Hitman said:
IIRC it [the anti-humming-bird mod] broke the pump system of the Type XXI :hmmm:
What I'm not sure is if it also brakes the pump system of any sub replacing the XXI, f.e. the XXIII, but I suppose not.True, I had forgotten that.

It became evident that the XXI pump was broken, because every time you loaded a XXI in NYGM, you got a damage report to that effect. In the end, I disabled the installation of the pump to the XXI, which ended the complaint, and the XXI still seems to sail correctly. [Speculate: the pump is used only as a device for getting repaired and broken in damage control, not actually for pumping?]

There have never been any damage reports from the other U-boats, including the XXIII, so I think it is not a problem for them.

Stiebler.

LGN1

01-02-11, 12:24 PM

Silent Ace

01-02-11, 12:42 PM

Of course B

WH4K

01-02-11, 01:33 PM

Am I the only one who can't find V15D_Patch-Kit.7z on h.sie's Mediafire page? I see a lot of other SHIII mods, but not that one.

CherryHarbey

01-02-11, 01:53 PM

It is in the Sh3 Bugfixes folder.

Magic1111

01-02-11, 03:02 PM

Am I the only one who can't find V15D_Patch-Kit.7z on h.sie's Mediafire page? I see a lot of other SHIII mods, but not that one.

Download Link: http://www.mediafire.com/?a6j533a02wsf39d

Best regards,
Magic:salute:

WH4K

01-02-11, 06:50 PM

Thanks, but it doesn't like my SH3.exe. Not sure why.

Tessa

01-02-11, 07:00 PM

have emerged because they had stopped a threat to them, but given the fact that the submarines are normally carried out during the war and an average of 20 hours when compared with other data presented here think that their maximum stay under water was 48 hours and the American and British submarines of similar displacement and number of crew members.

That is quite an impressive collection of reference and rare books there. I envy that you're able to read both of them in their native languages. Recently have noticed a large number of people selling rare or otherwise difficult to get u-boat books, sadly all but 1 that I've seen wasn't in German. Hard to justify paying $200-$400 for a book you can't read unless it's one that's mainly a photo collection.

I was lying in bed this morning and for some reason started thinking about the question of where/how they got 72 hours. Though there is no longer any question about the actual time, I was trying to figure out how they got the 72 hours in the first place. There are various fact intermingled to support my ideas, but this is purely my guess as to how they obtained such a large number based from certain facts we all know and hands on personal experiences with lab classes in high school/college and the basic scientific method:

1. These tests (likely) weren't performed under combat conditions, they would have been done somewhere safe to ensure that the test wasn't interrupted. Anyone that's had a chem lab or physics lab class can attest that when something is to be measured, any and all surrounding factors that could alter the outcome of the test are removed in order to get a clear result. Your results are based on the test being performed under ideal conditions, therefore they are correct but not practical. A MG42 was capable of firing 1,200 rounds per minute; but this never would have happened. With machine gun belts being on average 250 catridges the time taken to swap new ones in likely wasn't factored in the testing (probably made special belts of 2000 cartridges in order to ensure continous firing) and those barrels overheated frequently when fired for prolonged periods with pause or water.

2. Germany was very meticulous at keeping records of everything they did (which ultimately ruined them when the allies began liberating the concentration camps and from the documents were able to find out detailed everything that was done there) so once the number was found discovered it would have been well documented many times over.

3. Having a boatful of people sitting around reading or sleeping would not have produced CO2 very fast. It's like taking a direct flight from Berlin to Los Angeles, very long and boring so if you can sleep through most of it its not as bad. I imagine (pure conjecture) they had 1 or 2 subs full of people and had them submerge with someone on the boat and the surface keeping tract of time. Once people finally started to pass out, or a set # had passed out; or someone was actuall in imminent danger of dying they would surface and pop the hatch.

4. Math - if they didn't perform the real tests one could figure out with x number of people in y space, how long will it take for the CO2 to get to z level? While the resultant number would have been inflated compared to [3] it would have been mathematically verifiable, even though it would have been impossible to replicate those results on a real test, even under ideal [1] circumstances.

5. Since we can't speak to any u-boat engineers anymore, and unless you've got a book that details how they tested the u-boat (precisely what tests were done and how so that got the statistical numbers) I believe that the 72 hour vs 48 hours is theoretical vs realistic. U-278 could have stayed under water potentially a few hours more, but they have absolutely no reason to, given that the CO2 levels would have started to get very uncomfortable right then I doubt any captain would want to subject his crew to such an experiment in order to claim that his boat stayed submerged the longest. Something not practical at all during war time.

Using U-278 as the baseline, if we knew what CO2% they were at prior to them surfacing we could more correctly calculate a (realistic) maximum submersion time. By recording the CO2 measurements each hour one could easily enough exptropolate from a graph what the max would been given the slope of the line from the 40-48 marks. It would also be easy enough to find the amount of CO2 produced per hour and compute it against the amount of airspace in the sub, and come up (again a theoritcal, albeit much more realistic) with its maximum submersion time.

Just because no boat never dived for 72 hours doesn't mean that wasn't possible. Most cars are capable of hitting a max of 125-150 mph; but do we actually drive that fast?

While this is all my own theory drawn from certain facts and knowledge of methods used for testing to obtain a reference point; I believe that the real max dive time is somewhere between 50-60 hours in a real situation. Most crews didn't need to stay submerged more than 24 -30 hours, there would have been no reason for them to push the limits to find out what the boat was really capable of. Even if you had a boat that could dive safely to a depth beyond what dc's were capable of, having your crew sit there for 2 days hearing constant explosions (despite knowing that they were safe) would start to make people psychological ill. Every minute you're submerged the air quality gets worse, while a captain may lie at the bottom for another few hours in order to be completely sure they were safe to surface after 24 hours they were likely dead, or able to sneak away.

Tessa

01-02-11, 07:12 PM

Thanks, but it doesn't like my SH3.exe. Not sure why.

If you're using the 4gb patch you need an unmodified virgin sh3.exe file (with only the supermod added). If it has any other patches/mods that have changed it the mod won't work. What's your machine's specs?

Since many people have the problem I did (a 4gb patched sh3.exe file and no backup of the original file) would it be helpful if I could post it on my MF/FS site? Since it's only 1 file that in itself is otherwise useless I don't think there would be any legal issues. I would have used this mod a lot sooner if I didn't have to create a new installation just to get a virgin sh3.exe file that this mod needs.

WH4K

01-02-11, 10:00 PM

If you're using the 4gb patch you need an unmodified virgin sh3.exe file (with only the supermod added). If it has any other patches/mods that have changed it the mod won't work.

I don't use the 4GB patch. No need. Mods I use are in my signature - just GWX 3.0, with the following GWX mods enabled via JSGME:

GWX - English Nav Map and Grid Refs
GWX - Enhanced Damage Effects
GWX - Late War Sensors Snorkel Antennas
GWX - Main movie - 'Das Boot'
GWX - No Medals on Crew
GWX - Open Hatch Mod
GWX - VIIC41 Player Sub
GWX - Axis Mediterranean Aircraft Skins

I don't see how any of those would have anything to do with my sh3.exe. As far as I know, GWX doesn't modify the sh3.exe file in any way. I know I didn't even download GWX until a couple of days after SH3 finished downloading from Steam anyway.

What's your machine's specs?

In my signature.

Since many people have the problem I did (a 4gb patched sh3.exe file and no backup of the original file) would it be helpful if I could post it on my MF/FS site? Since it's only 1 file that in itself is otherwise useless I don't think there would be any legal issues. I would have used this mod a lot sooner if I didn't have to create a new installation just to get a virgin sh3.exe file that this mod needs.

That could be helpful, yes. Like you say, one can't do anything with just the .exe anyway.

Tessa

01-02-11, 10:14 PM

I don't use the 4GB patch. No need. Mods I use are in my signature - just GWX 3.0, with the following GWX mods enabled via JSGME:

GWX - English Nav Map and Grid Refs
GWX - Enhanced Damage Effects
GWX - Late War Sensors Snorkel Antennas
GWX - Main movie - 'Das Boot'
GWX - No Medals on Crew
GWX - Open Hatch Mod
GWX - VIIC41 Player Sub
GWX - Axis Mediterranean Aircraft Skins

I don't see how any of those would have anything to do with my sh3.exe. As far as I know, GWX doesn't modify the sh3.exe file in any way. I know I didn't even download GWX until a couple of days after SH3 finished downloading from Steam anyway.

Now that I think about this, how did things get so sidetracked? The main reason you need the virgin sh3.exe is to install the mod that the topic of this thread. It modifies that actual exe file directly, there are a few other items that do as well, none of which you are using.

I've posted a clean sh3.exe file for anyone that might want it (basically those of us that have applied the 4gb patch) here:

http://www.mediafire.com/?dzzfg6153i2i7r9

How did things fare when you disabled your secondary monitor? Does the problem still persist?

WH4K

01-03-11, 02:43 AM

I figured those mods had nothing to do with it.

I downloaded & tried to patch your version of sh3.exe. Still no dice.

Precisely which version of SH3 is your .exe from - Steam, original vanilla SH3, SH3 gold, or...? I assume it's at patch level 1.4, right? I'm not sure why they would be any different. A version 1.4 .exe should be a version 1.4 exe, regardless of source, unless Ubisoft is playing some stupid games.

I also noticed that my Steam-downloaded sh3.exe has a size of 1308 kbytes, where yours is 1300 kbytes. Weird. I can run my GWX 3.0-ed SH3 install using either the original Steam version of the .exe, or yours.

Turning off the second monitor had absolutely no effect. I cannot minimize SH3 to the taskbar. The most that happens is, my taskbar and parts of other applications will sort of flicker through the SH3 menu. Same thing happens when in-game.

When I have the second monitor active, I can shift mouse & keyboard focus to that screen by Alt+Tabbing SH3. But I can't drag over a window that was open on the primary monitor before I ran SH3. So I think what I'll have to do is, open anything I'll want to use while playing SH3 (e.g. GWX 3.0 manual) on the second screen before starting SH3 through SH3 Commander.

h.sie

01-03-11, 02:57 AM

Max. Diving times in V15D4 for Types VII and XI :

-Under normal conditions: approx 54h.
-When repairs are done all the time: 36h.
-Silent Running all the time: 72h.

So the 72h from the "Kriegsmarine Handbook" are reached only under special conditions (silent running). Under normal conditions max. diving times are shorter.

I have no problem to shorten the diving times, but before I do that, I think it's a good idea to collect some more informations.

@Silent Ace, Tessa: Thanks you for all your infos and thoughts.

h.sie

01-03-11, 03:00 AM

WH4K

01-03-11, 03:29 AM

That doesn't make sense.

As I downloaded from Steam, I don't have a physical disc, or Starforce. According to every source I can find, Starforce hasn't been included in SH3 for some time. That's one reason I finally bought SH3. I'm certainly not going to buy it a second time.

I can find no evidence of Starforce being present on my system. The official Starforce removal tool (linked to in this forum about a year ago, here: http://www.subsim.com/radioroom/showthread.php?t=160118), does not detect any Starforce drivers in use on my system, nor do I have any of the registry entries associated with Starforce.

So no, I don't think Starforce is the problem. There is something else going on here. Perhaps it's unique to the Steam version of SH3. It doesn't make sense that the Steam executable would be unique, but apparently it is.

SquareSteelBar

01-03-11, 03:47 AM

...my Steam-downloaded sh3.exe has a size of 1308 bytes, where yours is 1300 bytes...The correct size is 1,331,200 bytes not 1308 or 1300...

MD5 hash: 510b271d14621361386197be6bd8cc0c

WH4K

01-03-11, 10:40 AM

It's another case of the Windows filesystem lying a little. The exact filesize of my sh3.exe is 1339392 bytes, according to Ubuntu.

Wonder what those extra bytes do? I don't understand how I can have the same version (1.4) as everyone else, yet we have different size files. Shouldn't that be a different version?

Silent Ace

01-03-11, 05:05 PM

A drawing that shows the U.S. WW2 submariners psycho-physical condition of his comrades after 31 hours spent under water.

http://img641.imageshack.us/img641/8769/56367802.jpg

fitzcarraldo

01-03-11, 05:24 PM

The correct size is 1,331,200 bytes not 1308 or 1300...

MD5 hash: 510b271d14621361386197be6bd8cc0c

I have 1,331,200 in my 1.4 with 4GbPatch.

Regards.

Fitzcarraldo :salute:

Tessa

01-03-11, 10:46 PM

@Tessa, WH4K: If the patcher doesn't like your sh3.exe, you don't have the correct non-starforce version of sh3 which is required. You can get it for some bucks and it's worth the money.

If you want to change from starforce-sh3 into non-starforce-sh3, it's not sufficient to only change sh3.exe. You also need to change some dll's (see earlier posts in this thread).

The patch worked fine for me using that exe I posted. It's from a non-starforce, DD from Ubisoft that was already patched to 1.4. I did install GWX, in retrospect I should have just left it as the vanilla, though installing GWX can take awhile on older machines.

The version I have is a very rare one, Ubisoft only had direct sales available for a few months before they switched to the current system. It's a real shame I can't re-distribute it to those who have bought a legit copy and are having problems with installs (usually due to Windows 7), mine has no starforce and no need to add any additional patches to get it working with any of the supermods. This version has never suffered any of the install/compatibilty problems that many others experience. When I began playing initially was using the cd; eventually the cd became unusable. At that time it was only $10 from Ubisoft and bought it directly from them. I've never had any problems getting it working, once I installed it onto a different machine (in order to get the unmodified sh3.exe) added GWX applying this mod only took a few seconds and was ready to go.

Its been awhile since I've been able to use dual monitors. When my main large one died I've been left only with my laptop or 32" lcd TV. I do recally from when I was using dual monitors with games that the behaviour as annoying and unpredictable. I spent awhile trying to figure out why the heck the game was opening on the 2nd monitor, then trying to alt tab out would ctd the game. Ultimately when I wanted to play a game I unplugged the 2nd monitor. I'm fresh out of ideas, aside from unplugging the 2nd one and changing the display settings to use 1 monitor I'm not sure what more to suggest.

h.sie

01-04-11, 02:51 AM

I seem to have the same sh3.exe version as Tessa has and I also never had any problems, although I sometimes have mod-salad in one of my sh3 installation (for testing and modding purposes). Campaigns load in 3-4 minutes, never had CTD when loading savegames - this is what I call a stable game. So I recommend to pay some bucks for that version. in german it costs 5 euros.

WH4K

01-04-11, 02:51 AM

I did OLC Gold Mk II to work, which includes its own longer repair times fix. So all I'm missing from the subject mod is the periscope speed restriction.

I'll do without this patching the .exe business. Too complicated, as there are too many different versions of the SH3 executable floating around (way to go, Ubisoft!). I go really slow at periscope depth anyway, because I don't want to get killed to death by alert destroyers and such.

h.sie

01-04-11, 03:00 AM

@W4HK: Nice to read that you finally got it to work. My patches are not essential for gameplay, they are only "nice-to-have". And the periscope-speed restriction can be "modded" by your own self-discipline.

LGN1

01-04-11, 11:43 AM

Hi all,

after the comments I thought again about the submerged endurance. I have reread the original manual for the VIIC and I think that I know now where the 72h come from. So, here is my theory:

The value is the max. theoretical time the sub could stay submerged with full oxygen tanks. However, the oxygen tanks were for a full patrol, i.e., depending on how long the sub had been submerged before, the max. diving duration was less.

This theory is based on the following observations:

- Meanwhile I have read an account of a patrol in which a sub had to return (among other things) because the oxygen tanks were almost empty.

- The original manual does not contradict this theory. It only says that the sub can stay submerged for 72 hours with the given amount of 'Alkalipatronen' and oxygen. Since I don't think they could produce pure oxygen during a patrol I assume the oxygen tanks got more and more empty during a patrol, limiting the submerged endurance in the course of a patrol (I am also not sure whether the 'Alkalipatronen' could be recovered during a patrol).

- The manual says the following:

Volume of sub: 400 m^3
One man needs 30l/h
Max. allowed CO2: 1.5%
Min. oxygen: 17.5%

--> With 37 men the CO2 level is reached after 5h20min. After 4h the concentration should be checked for the first time.

Oxygen tanks: 500l with 150 atü

If you use this information you can calculate that the sub can stay submerged around 72h before critical concentrations are reached.

The main questions about this theory are:

1.) Could a boat produce PURE oxygen?

2.) Could the 'Alkalipatronen' be recovered during a patrol?

Consequences for SH3 modding:

- I think a max. submerged endurance of 72h is not unrealistic, but you should not be able to stay submerged for this amount of time more than once during a patrol.

- Probably the best solution would be if an oxygen tank would be modeled that gets more and more empty if you stay submerged for more than 4-5h. In this case the total diving time (over 4-5h) during a patrol would be recorded and limit your submerged endurance (72h at the beginning and less long at the end).

However, since an oxygen tank is not modeled in SH3 I think it's very difficult to model. So, there might be two solutions:

- Keep the current model with a constant max. diving time. The time can be either the max. value 72h or an averaged ('middle of patrol').

- Try to (ab)use the CO2 gauge in SH3, i.e., changing the code in a way that CO2 is not set to 0 when you surface and increase it with a constant rate when you are submerged for more than 4-5h.

Anyway, these are my thought on this issue. As I said, the current model from h.sie is fine for me and it's anyway up to h.sie what he thinks.

Cheers, LGN1

Myxale

01-04-11, 03:21 PM

An sensible post LGN.

h.sie

01-04-11, 05:23 PM

Question: Is it correct that only Types VII and IX had external torpedoes? If so, there is a little chance that I can model inflooding water / dead crewmen if one dives during reload of external torpedoes.

Myxale

01-05-11, 01:26 AM

Yeah. Only the the type 7 and 9 did have externals. Type 2 was to tiny form that.

h.sie

01-05-11, 03:01 AM

@Myxale: Nice to know that only VII and IX uses external torps. Makes things much easier.

@ALL: Another question/problem:

Imagine the following situation: Crew is currently reloading externals and watch crew sees an enemy warship or aircraft. In this case the player has to alert the crew to hurry up or cancel the reloading process in order to dive rapidly.

This reqires a new system-command, say, "CANCEL_RELOAD" (and a little state machine).

This can be programmed in 2 different ways:

1) Overload/Abuse an existing command, e.g. the first pressing of the crash-dive button "C" could be interpreted as "CANCEL_RELOAD", and all subsequent pressing of "C" key then are interpreted as crash-dive.

2) Use/abuse a so far unused system-command like "WA_report_damage" (see Commands_en.cfg). With a little edit of Commands_en.cfg this new command CANCEL_RELOAD could be assigned its own key like "Ctrl-C", and even it's own menu button in a GUI.

I personally prefer solution 2, although it requires a little edit in Commands_en.cfg (solution 1 doesn't reqire that, but does require more assembler programming).

My question is: Is this command "WA_report_damage" in Commands_en.cfg really unused so far??

I tried to trigger it, but I saw no reaction of the game on this command.......seems to be a command that was planned by the devs but never finished...

h.sie

Tessa

01-05-11, 09:47 AM

Is it possible to make the torepedo get lost in the diving process once transfer has begun? If its going to take 10 minutes to get the torpedo back into the container or 2 minutes to dump it overboard (which would let you dive a lot faster) I don't think crews would think twice about dumping them overboard if it meant life or death.

LGN1

01-05-11, 11:23 AM

I don't know for sure, but I can't imagine that it was possible to dump the torpedo quickly :hmmm: It's quite heavy and IIRC the crane was quite small and could not be used to throw a torpedo over board easily. Two minutes seems to me much too short.

Anyway, I guess modeling all the reloading stuff realistically is just impossible. Far too many unknown issues.

I think it would be already fine if you could not dive during reloading (at least during most of the time). This would already force players to play realistically, i.e., only reloading torpedoes if there was no danger (as it was done in real life). If you get caught, well, bad luck.

Does anyone know whether a boat was ever caught during reloading of external torpedoes in the war?

Cheers, LGN1

h.sie

01-05-11, 11:30 AM

LGN1

01-05-11, 11:40 AM

Hi h.sie,

I think 2a) is fine enough. It forces the player to play realistically and penalizes him if he has bad luck (hits by destroyer, plane,...)

2b) sounds far more complicated and difficult. Possible questions are: How many crew member should die/get injured? How much flooding should happen? Can you close the hatch when submerged? Would a real Kaleun give the order to dive if the hatch is not closed? Just far too many open questions for my taste.

Cheers, LGN1

h.sie

01-05-11, 11:52 AM

h.sie

01-05-11, 12:15 PM

@Stiebler: I found the diving tank of the Sub. It's 32-Bit-Float. Surfaced it's empty (0,0), if you dive, the value slowly rises to full (1,0). If sub is submerged and you immediately set the tank to 0,0 the sub jumps out of the water. Turbo.

IMHO, this is a much better starting point for modelling negative buoyancy depending on silent-running. I could give you more infos if you want to do some experiments on your own.

And maybe somewhere there is the crash-dive-blues bug located??

h.sie

Tessa

01-05-11, 12:35 PM

@Tessa: Not possible ATM but it's maybe worth to be tested. I tried other things in the meantime. The problem is: We don't have the necessary dialog elements for telling the crew what to do: Drop torps over board or not. We are about to add new stuff to the game......that was not my intention :D.

It is alluring to add new stuff like that. But code gets more and more complex - no more solid - that's the problem.

So I have to concentrate on the most important things:

1) No reloading of externals (and internals) during storm (easy to do).

2) Program a certain delay time (2-12 minutes, depending on reload progress), during which

2a) Diving is not possible (dive-commands simply disabled) OR

2b) The player gets huge penalty (flooding, dead crew) when he orders to dive in that time.

I don't know if it's worth the effort to program lost torpedoes, since I don't know whether this situation did happen in RL.

From a book of mine that has some pictures of torpedo transfers, this pic was talking about boat to boat transfers, but the same underlying message is the same:

"Torpedo transfer on the high seas, here U-154 supplies a spare eel to U-564. As can be readily seen, such operations required large numbers on deck, the erection of winches and hoists and the opening of most hatches, an extremely vulnerable condition. Neither boat would be able to dive if discovered by air or sea search. Such scenes, of necessity, became less and less common as the war proceeded"

Though this is describing transfer between boats, all the same equipment needed to move from your own boat's external capsules into the torpedo rooms would still need to be out. IF a captain were to have crash dived as he saw a pair of B-24 on the horizon he would have to leave the hatches open and close the bulkheads to both torpedo compartments, which would flood them 100% until you could safely surface, put the gear away and close all the hatches, then pump all the water out. Would have been a good chance of damage to the deck and gear, and potentially drowning sailors on the deck if the captain is impatient or the bombers and getting too close to wait for everyone to get back inside.

I would go with option 2B, will look into some incidents I've recently read about of aircraft getting the jump on lazy crews to see what their fate and casualties were.

LGN1

01-05-11, 12:36 PM

Tessa

01-05-11, 12:52 PM

@LGN1: I agree, 2b) is more complicated. And I currently don't have a lot of choices. I could set the flooding-counter of the torpedo room to a randomly chosen value between 10% and 90%, but the boat does not even sink and the crew fastly pumps out the water. This is no penalty. But if I set the flooding counter to 100%, the game is over. Not nice. Only chance: Set the flooding counter to exactly 99%. This kills all crew in the compartment and makes it impossible to pump out the water, since no-one can go into that compartment - it's isolated, but the game does not end. This is the only penalty I can offer ATM - which could force the player not to dive and play realistic. But why simulate such a situation which a real kaleun would never choose?

Most of the torpedo crew is going to be on the deck (which can't be mirrored in the game granted) during the transfer. You're at a point where it will take 10-15 minutes to safely stow the gear and close the hatches. During this period you were pretty much be immobile. You see 2 B-24's ~5000m away. In 3-5 minutes those bombers will be in range to drop as much as 8000 lbs of bombs on you (per bomber), situation looks pretty fatal to the u-boat caught with its pants down.

In those 3-5 minutes most of the men could either move from the torpedo compartments into the adjacent ones closing the bulkhead, and the crew on top jump into through the tower. The bilge pumps will keep the flooding somewhat under control but never enough to clear the compartment. The volume and speed in which the water enters thse compartments would be enought to scuttle a ship if they opened up all the compartments in a matter of minutes. Unless they're hit by a bomb the pumps should be enough to keep those compartments at 80%-90% full but never reaching 100% unless there is further damage.

Stiebler

01-05-11, 02:13 PM

@H.sie:
@Stiebler: I found the diving tank of the Sub. It's 32-Bit-Float. Surfaced it's empty (0,0), if you dive, the value slowly rises to full (1,0). If sub is submerged and you immediately set the tank to 0,0 the sub jumps out of the water. Turbo.

IMHO, this is a much better starting point for modelling negative buoyancy depending on silent-running. I could give you more infos if you want to do some experiments on your own.Great work, H.sie. Yes please, I'd like to see if I can achieve anything from there.
Perhaps you can publish it in this thread, or send me a PM.
Many thanks,

Stiebler.

h.sie

01-05-11, 03:28 PM

@Stiebler:

Procedure to locate memory position of diving tank:

1) Surface

2) Set Breakpoint at Sh3Sim.act + 0x8527

3) Order Dive

4) Routine in 2) now tries to write to two memory locations, using register ECX as pointer. One of the memory position is the diving tank. The other maybe controls the depth rudder (not intensively tested).

I don't know if that could help to fix the crash dive blues.

h.sie

Stiebler

01-06-11, 04:04 AM

@H.sie:

Your information acknowledged with thanks.

Stiebler.

Silent Ace

01-06-11, 10:12 AM

1.) Could a boat produce PURE oxygen?
Not in large quantities it has become possible only to nuclear submarines because it requires a large amount of electricity.
On diesel submarines (after ww2) are manufactured oxygen using chlorine candles that contain sodium and potassium chlorate and that release oxygen for combustion.
One such candle can burn for an hour and produce 2.8 m3 of oxygen.
Oxygen is regularly added three times during the day and most mid-day when the consumption is greatest.
2.) Could the 'Alkalipatronen' be recovered during a patrol?
I could not be recovered because it is a very sensitive substances to external factors and it must be carefully handled.

somedude88

01-07-11, 12:21 AM

So if I got this straight from this extremely long thread...

The Steam Sh3exe. is completely and hopelessly incompatible to h.sie's realistic repair time mod?

If so, is there a line of code I can change to make LRT mod's flooding more realistic, rather than difficult; neigh impossible?

Thanks for your time and keep up the good work.

somedude88

01-07-11, 12:48 AM

This patch doesn't reduce crew efficiency, it changes the Sh3.exe in order to multiply the repair time by a factor of 60.
It shouldn't cause mod conflicts either, I use the lifeboats, damage effects and integrated orders and this patch without problems.

Have you implemented LRT (Longer repair times) mod? If so then this will cause you problems as it is trying to do similar things to H.Sie patch. You don't need both.

In my opinion H.sie patch (from which you can download from his mediafire site) is the way to go.

If this isn't your issue, then I think you will need to post more details of what exactly you have done and what exactly isn't working.

Hope this helps.

Damn it... I didn't realize that LRT mod and H.Sie's patch were two different things...

Tessa

01-07-11, 01:07 AM

Damn it... I didn't realize that LRT mod and H.Sie's patch were two different things...

With all the extra functions and realism that h.sie's mod adds I can't see any reason why one would prefer to use the LRT mod. h.sie's mod has LRT for all sake and purpose built into and many nice improvements. If you need a clean GWX sh3.exe file in order to be able to use this mod you can snag it here:

http://www.mediafire.com/?dzzfg6153i2i7r9

somedude88

01-07-11, 02:41 AM

With all the extra functions and realism that h.sie's mod adds I can't see any reason why one would prefer to use the LRT mod. h.sie's mod has LRT for all sake and purpose built into and many nice improvements. If you need a clean GWX sh3.exe file in order to be able to use this mod you can snag it here:

http://www.mediafire.com/?dzzfg6153i2i7r9

But again, from what I've read in the previous posts, I'm getting the sense that Steam-bought SH3.exe files do not work with H. sie's mod... and even if it did work with steam... the directions are a bit confusing to me. Even though I downloaded both your sh3.exe file and H. sie's V15D-PatchKit.7z the Patch_SH3.bat is telling me that the Checksum is wrong and therefore cannot be patched...

And if I had known the difference from the start... I too would have preferred H. sie's mod... I am a stickler for realism after all...

h.sie

01-07-11, 03:09 AM

Message to people who complain that I only support one version of sh3.exe:

I am sorry to say, but ATM I only support one version of sh3.exe (which is the one the patcher accepts as the right one). You can get this version for about 5 euros.

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

You might now say: I already payed for sh3 and I won't pay a second time.

But I ask for your understanding and argue: I spent more than 2 years now for modding a simulation that fits my (and your?) personal taste. And it would take further days/weeks for me to support three different sh3.exe versions instead of only one.

So what are 5 euros (worth maybe 20-30 minutes of work) compared to that?

If you are not willing to pay 5 euro's, why should I spend days / weeks to support a sh3.exe version which I even do not own?

somedude88

01-07-11, 03:37 AM

Message to people who complain that I only support one version of sh3.exe:

I am sorry to say, but ATM I only support one version of sh3.exe (which is the one the patcher accepts as the right one). You can get this version for about 5 euros.

You might now say: I already payed for sh3 and I won't pay a second time.

But I ask for your understanding and argue: I spent more than 2 years now for modding a simulation that fits my (and your?) personal taste. And it would take further days/weeks for me to support three different sh3.exe versions instead of only one.

So what are 5 euros (worth maybe 20 minutes of work) compared to that?

If you are not willing to pay 5 euro's, why should I spend days / weeks to support a sh3.exe version which I even do not own?

But would it be okay if I tried to do what you did and create a patch kit, but with the Steam SH3.exe? That way, people don't have to pay extra and you don't have more mind-numbing slave labor to deal with.
Unfortunately, I don't have too much programming knowledge beyond webpages. (Wah wah...) But if it's at all possible, either through instruction or on-the-job-learning or whatever... I have a few weeks to burn.

h.sie

01-07-11, 03:42 AM

somedude88

01-07-11, 03:54 AM

Yes of course. My patches are freeware. All you need is a Debugger (OlliDbg) and little skills in x86 Assembler language.

But:

1) in my opinion it's not worth the time and

2) I cannot give instant courses in assembler.

How did you learn assembler language? Maybe I can take the same route... if it doesn't involve several semesters of computer science... which is actually the most likely route you took...

h.sie

01-07-11, 03:56 AM

It indeed took some semesters of computer science.

somedude88

01-07-11, 03:57 AM

It indeed took some semesters of computer science.

And so... the idiot that didn't think before he spoke, proceeds to eat his own words... mere minutes after speaking them.

h.sie

01-07-11, 03:18 PM

Storm Conditions

I found the code to calculate storm conditions. Example: In the Subs .cfg file you find for storm-conditions e.g.

StormConditions=11,0.4

Currently, storm-conditions are true (flak & deckgun cannot be used and crew wears rain clothes)

If windspeed > 11m/s OR Rain Intensity > 0.4.

What about changing these conditions a little bit as follows:

If no rain: Windspeed must be > 11 to set storm conditions
If medium rain: Windspeed must be > 9 to set storm conditions
If heavy rain: Windspeed must be > 7 to set storm conditions

Any reasons NOT to do this?

h.sie

LGN1

01-07-11, 04:20 PM

Hi h.sie,

are any rain/wind combinations possible? I am wondering why one should not be able to use the deck gun in heavy rain with wind speed 0m/s :06: It looks strange to me that rain can trigger the storm condition (I think it would make more sense if wind triggers deck gun usage and rain coats, but rain only triggers rain coats and has no influence on the deck gun / flak).

Cheers, LGN1

h.sie

01-07-11, 06:42 PM

Anvart

01-07-11, 06:49 PM

But again, from what I've read in the previous posts, I'm getting the sense that Steam-bought SH3.exe files do not work with H. sie's mod... and even if it did work with steam... the directions are a bit confusing to me. Even though I downloaded both your sh3.exe file and H. sie's V15D-PatchKit.7z the Patch_SH3.bat is telling me that the Checksum is wrong and therefore cannot be patched...

And if I had known the difference from the start... I too would have preferred H. sie's mod... I am a stickler for realism after all...
Tessa's sh3.exe edited under 4GB... may be therefore checksum is wrong... may be not...
Offset = 0x0000011e - byte 2f change to 0f ... and try...

Anvart

01-07-11, 06:53 PM

@LGN1: I tried to fix that, used different storm-condition routines for clothes and flak.

Weather: No storm but rain.

Result: Crew animations look very ugly for crew with rain clothes (stormconditions=1) standing at flak (stormcondition=0).
Do you see animations for crew models without rain clothes...?
...
Why StateMachine class (animations) did not change..?

h.sie

01-07-11, 07:04 PM

yes, without rain clothes all look good.

with rain clothes they stand still like scarecrow.

somedude88

01-07-11, 07:40 PM

Tessa's sh3.exe edited under 4GB... may be therefore checksum is wrong... may be not...
Offset = 0x0000011e - byte 2f change to 0f ... and try...

What? How do I even open the .exe to change 2f to 0f?

WH4K

01-07-11, 09:14 PM

Tessa

01-08-11, 12:54 AM

somedude88

01-08-11, 01:15 AM

Tessa's sh3.exe did not work for me either.

It is, somehow, different from the version of sh3.exe that h.sie's patcher is expecting.

The sh3.exe one gets from Steam is different still. Not only does it not work with h.sie's patcher, it is a different filesize from Tessa's (1308 KB instead of 1300 KB).

I can confirm that the Steam sh3.exe does act differently. When I run it, a Steam window pops up briefly. It will run in "offline mode," so I suspect it is checking to see whether my SHIII install is "activated" or something like that.

You know, I really wouldn't mind shelling out another $10 for this mod, even thought I just bought the Steam version of the game just a month ago... but damn it all... I'm getting pretty sick of putting more money in Ubisoft's pocket... (granted, it's just $10, how much they profit off of that must be small if the company even profits off of it at all) for seemingly half-finished, half-assed games they don't even put the real effort into fixing... (which does seem to be a growing trend, these days... EA, Creative Assembly and SEGA, I'm looking at you...)
I know that with better, more complicated programming come's the difficulty of solving every little problem. The more complex and bigger the program, the bigger and harder every little flaw is to solve. And maybe that downward trend in quality is inevitable. But that doesn't mean I have to like it and I know it's still possible to make an awesome, bug-free, mod-free game.
I mean, let's get something straight. The modder's in this community, who quite literally work pro bono to alter the game's behavior/experience are the people that unlock the game's potential and ultimately... add like 90% more fun to the game. I bought the game because of the mod's I've seen... especially GWX. Hell, Ubisoft should be giving you modder's a cut of the profit because I sure as hell wouldn't have bought Ubisoft's SH3 if you guys weren't there.
So forgive me, H.sie. What you're doing is fine, I'm not angry or disappointed that you aren't going to submit yourself to the ridiculous pain/lengths of terraforming Ubisoft's dying world of a game. But I'd rather wait a few more years or actively find another way to get this mod implemented than throwing more money at the problem... Unless that money actually goes to the modders that are still working on this.

And... end nerd-rage.

somedude88

01-08-11, 01:20 AM

Sorry guys, not sure what to do say. That exe is from vanilla + GWX installed. I know there are other files that are modified by this mod but unsure of which. As a last resort I could post the modified files so you wouldn't need to worry about the patcher, besides sh3.exe I need to know which other files to include.

Hey... not your fault and thanks for trying. Let's just see if there is a simple, solution/loophole in the problem, (which I doubt, but am anxious to find out if possible) and hope for the best.

Andy Webber

01-08-11, 05:26 AM

Hi all,

I think i may have found a way to use this great mod but while having the original version or the Steam Version (possible but not checked yet).

I have been successfully using this mod now on my install that i did from the orginial CD (bought when the game first came out). And also i'm doing it on windows 7 64 bit.

When patched to 1.4 the only difference between the original SH3.exe and the new one is the starforce files (and so the checksum) but the main programming is the same. After all it does the same thing.

Since i bought the pack for SH3+SH4 and Uboat missions on direct to drive i simply copied the SH3 direct to drive exe into my 'work' folder. Ran the patch as instructed and replaced it into my SH3 directory that was created from the original disk install. It not only ran the mod, but also meant that i didn't need the no cd edit.

With hisie;s permission and also some help from someone that has somewhere conveient to host the file. I'll make a copy of my work file, which has the d2d exe and the current version of the mod (V15D_Beta 4).

the beauty of this is that if you rename your old SH3.exe as something else you can drag and drop the new exe into the SH3 folder and if you don't like or want to remove the mod. Just rename/delete the mod exe and you can go back to the old one.

Since this is essentially just turns into a simple drag and drop of the .exe and because of his outstanding work all credit to this should go to hisie, i just rearranged what he'd provided. Mine was just a packaging exercise.

Hope this both works and helps,
regards,
Andy

h.sie

01-08-11, 05:33 AM

@Andi: Good idea (if it works). Why don't you create a JSGME ready mod. Everyone is familiar with that and noone needs to manually fiddle around in the install directory.......and it can easily be deinstalled. But there are more files necessary to make it work in all sh3 versions (some dlls whose names I don't remember).

h.sie

Andy Webber

01-08-11, 05:46 AM

All i've done is drag and drop the patched sh3.exe into the original install. So we know it'll work for the original disk install. And it'll work for the version you've got sorted.

The reason i've not made it into a JGME mod is because you're still working on your mod. If i / we put out a package with the original sh3.exe from the direct to drive version. Then since it has the correct checksum people will be able to use that as a base for applying any future updates of your mod.

But if you really wanted to. The smart thing would be to make it as part of your supplemental file that you already have to enable, so that then becomes the whole mod.

SquareSteelBar

01-08-11, 08:00 AM

...But there are more files necessary to make it work in all sh3 versions (some dlls whose names I don't remember)...
MissionEngine.dll
SimData.dll
StateMachine.dll
Utils.dll

Anvart

01-08-11, 10:14 AM

What? How do I even open the .exe to change 2f to 0f?
Use Hex Editors:
Hex Workshop
WinHex
FlexHEX
010 Editor
...
or other.
... but only if you know what and how to do...

http://img401.imageshack.us/img401/4193/sh34gb.jpg

Anvart

01-08-11, 10:42 AM

MissionEngine.dll
SimData.dll
StateMachine.dll
Utils.dll
Right?

http://img18.imageshack.us/img18/6954/sh3nosf.jpg

SquareSteelBar

01-08-11, 10:57 AM

yep, all right.

I see you got the files already?

Anvart

01-08-11, 11:05 AM

yep, all right.

I see you got the files already?
In world there are many good friends...

h.sie

01-09-11, 08:06 AM

would a speed restriction during reload of external torps be realistic?

if yes, what speed?

Sailor Steve

01-09-11, 09:51 AM

would a speed restriction during reload of external torps be realistic?
Yes.

if yes, what speed?
Realistically? Zero. They may have slowed to one or two knots, but most likely was a dead standstill.

Hitman

01-09-11, 10:06 AM

REMINDER:

I have been watching this discussion, and I would like to emphasize that we at subsim-com will not allow posting here links to modified game engine files and such. Please if anyone is willing to exchange, give or share such files, do it privately, and forget any idea of posting pre-patched files and such here.

The only thing allowed here are H-Sie's fix files, which are essentially programs that run externally and modify each user's legitimally bought and installed program files -on which he can legally do whatever he wants-, but never affecting the "copy protection" that might exist.

Thanks for observing these simple guidelines, so we can keep this discussion open :up:

Anvart

01-09-11, 10:18 AM

@ Hitman
If you about my posts... i have shown byte edited by 4 GB patch... :haha:
... and checksums of files - targets of h.sie's work...

h.sie

01-09-11, 12:42 PM

Thanks, Sailor Steve. Speed restriction could be done in two ways:

A) Disallow higher speeds by program code or

B) Program some penalty if one breaks realism rules (dive or driving too fast during reload).

In the last 2 weeks I spent a lot of time to try to model such penaltys (crew injured or dead, compartments flooded and so on), but only with little success, and: It took a huge amount of program code. So I tend to not continue this way. That means:

1) During reload of external torpedoes speed will be restricted.

2) During reload of external torpedoes one cannot dive, since all diving commands will simply be ignored.

3) There will be a new Command (e.g. Ctrl-C) to interrupt the reloading process, in the case of an alarm or if higher speeds are necessary. After interrupting the reload process, the user has to wait 2-10 minutes. After that, he can dive.

4) No reloading of external torps in bad weather.

Eventually 5) : No reloadings of internal torps when windspeed exceeds a certain value.

This solution restricts the player instead of allowing him to decide if he wants to break realism rules or not and risk some penalty. I am not happy about that solution, but my restricted time does not allow a detailed and realistic modelling of all possible situations/penalties.

Only alternative: The only simple penalty I can offer is to destroy the sub for a certain probability. That means: If the player dives during reload, he risks for a chance of, say, 75% that boat sinks. That's too extreme, I think.

h.sie

h.sie

01-09-11, 12:55 PM

An arbitrary, unused command like

[Cmd348]
Name=WP_Report_damage

or

[Cmd435]
Name=WA_Report_damage

Of course I'll make sure the command is really unused.

h.sie

01-09-11, 02:21 PM

Why automatic interrrupt? I think its better if the player decides if or not to interrupt reloading!

Stiebler

01-09-11, 03:13 PM

@H.sie:
You identified earlier a diving tank and another variable, tentatively thought to be possibly a depth rudder ( = hydroplane). (Seen at code SH3Sim.act + 0x7527, and indexed through register ecx.)

I have now checked out this code, and there appear to be five variables involved, all indexed by ecx. Since there is no way of identifying these by constant memory addresses, I shall identify them by the last three digits of their addresses (these last three digits are probably the same for you too). The values were checked for a simple dive (‘D’-key) from surface, and a crash-dive (‘C’-key) from surface, at TC = 1. I’m using a IXC boat.

xxxxx170: involved in dive + crash-dive. Value reaches a maximum of about +0.5235 in mid-dive, averages zero when at requested depth.
xxxxx05c: value remains steady at 0.0 throughout (dive + crash-dive). However, the calling code leads to:
xxxxx18C: involved in dive +crash-dive. This value rises rapidly from 0.0000 to 1.0000, and presumably represents the memory location of the diving tank.
xxxxx144: involved in dive + crash-dive. Value is frequently the negative value of xxxxx170, but the values differ slightly during the dive. Value averages zero when at requested depth.
xxxxx1A0: involved in crash-dive only. Value rises very fast from 0.0000 to 1.0000, faster than xxxxx18C. It appears to represent (correctly) a quick-diving tank for crash-dives. After the U-boat reaches the crash-dive depth, the value falls very fast to 0.5000.

Comments:
We know already that a crash-dive in SH3 reaches its depth (80 metres here) faster than a high-speed dive to 80 metres. This is obviously modelled correctly with SH3 - well done, devs.
The ‘crash-dive blues’ occurs when a crash-dive is interrupted by changing the depth before the crash-dive has completed. When this happens, the U-boat does not level out correctly, but has a downwards angle. The bug affects all the super-mods, but is particularly noticeable with NYGM.

When a crash-dive is interrupted, the value of xxxxx1A0 does not return to 0.5000, but remains at 1.0000. This is the only difference I have detected (yet) between a completed crash-dive, an interrupted crash-dive, and a simple dive. When the NYGM U-boat is set to slow ahead, after an interrupted crash-dive, it sinks. When the speed is set to half-ahead, the U-boat returns to the depth set by the player when he interrupted the crash-dive. There is *no difference* between the values of the five variables shown above in either circumstance.

This is hard to interpret. Is it possible that that xxxx170 and xxxxx144 can be hydroplanes/depth-rudders, and the difference in water flow over them at different submerged speeds causes a gain or loss of depth? That is how hydroplanes are intended to function. But in that case, why is there not a severe angle on the hydroplanes at slow underwater speeds, when the boat is sinking, but wishes to rise?

Stiebler.

Delareon

01-09-11, 03:16 PM

Eventually 5) : No reloadings of internal torps when windspeed exceeds a certain value.

Because of RL i missed a lot of the discussion here so maybe i ask a dumb question, but anyways: Why no reloading of internal torps at certain wind speeds?

Shouldnt it be possible to reload them all times? (at heavy seas only when dived maybe).
I only had a short experience inside of an Submarine for tourism purposes at the coast of mallorca when the sea was quiet so i have not really a clue how heavy seas feel inside of an sub but i was thinking that u dont feel any waves at a certain depth. So reloading while submerged should work always from my opinion. Dunno if a depth check while in heavy seas is an easy task for u h.sie but my early (or late) wish for christmas is to have an depth check when wind reaches a certain value and allow reloading of internal tubes when deeper than 30m for example ;)

h.sie

01-09-11, 04:34 PM

@Delareon: This is not a dumb question. It's a question that has to be discussed before I start programmming this. LGN1 wrote something about this topic earlier and via PM to me. Either we search the post or LGN1 is so kind to repeat what he knows regarding this question. Or any other historical information welcome, too.

h.sie

01-09-11, 04:52 PM

@Stiebler: Great findings, which could help us to eliminate the crash dive blues.

xxxxx170 indeed is the value of one of the hydroplanes. in a different code section it is multiplied with a cartain value, so that we get values between -30,0 and +30.0 what are exacly the values shown in the gauges in the control-room and which are the current angles of the hydroplane.

The other hydroplane has different sign, that means: If both hydroplanes are up, one has the value +0,52 and +30,0 (degrees) and the other has the value -0,52 and -30,0 (degrees). This also irritated me.

xxxxx1A0 is very interesting and in my opinion the starting point for deeper research in order to locate the cause of the crash dive blues. What about manually setting it back to 0,5 after an interrupted crash dive? If that works, we can fix the according code to set the value to 0,5 instead of 1,0 after interrupted dive.

h.sie

h.sie

01-09-11, 04:56 PM

@Anvart: In my opinion the kaleun (the player) is the person who decides whether to interrupt reloading or not. the watchcrew and the sonarman are only functional crew members without military authority. their job is to support the kaleun with information.

By the way: If I trigger one of these unused commands: nothing happens. No crew animation. So they really are unused. Or do you mean: for further use e.g. for some other mods which maybe could use them for animations??

Stiebler

01-10-11, 07:08 AM

@H.sie:
Yippee!! The *cause* of the ‘Crash-Dive Blues’ is solved!!

If you restore the value for the quick-dive tank at xxxxx1A0 (see my earlier post#866 http://www.subsim.com/radioroom/showpost.php?p=1570620&postcount=866) to 0.5000 after an interrupted crash-dive, then the U-boat regains full operational stability at slow speeds and at high speeds.

Specifically, if the crash-dive is set to 80 metres (default), but you change the depth setting to 40 metres as soon as the U-boat is underwater, then the U-boat descends to 40 metres with xxxxx1A0 variable still set to 1.0000 (should be 0.5000 if the crash-dive had completed). If you now set the speed to standard, the U-boat maintains its depth. If you set the speed to slow ahead, the U-boat sinks slowly.

If we now change manually the xxxxx1A0 variable to a value of 0.5000, the U-boat maintains its depth at 40 metres. If it has sunk already to 50 metres, it returns to 40 metres and levels out.

I discovered something else. The quick-dive tank ‘empties’ quite quickly as you crash-dive, so a crash-dive interrupted at 60 metres has variable xxxxx1A0 set to a value of about 0.65 (not still at 1.0000). When this happens, the U-boat sinks more slowly at slow speed than it sinks when interrupted at 40 metres.

These tests done with a crash-dive (‘C’-key) from surface, at TC = 1, using a IXC boat. ‘Interrupted crash dive at nn metres’ means: ‘As soon as the U-boat is below the surface, click on the dive gauge at nn metres’ (where ‘nn’ = 40 or 60 in the examples above).

One irritating problem: I thought that the variables described here and in my last post would be constant in their last three digits. They are not. I had to work them all out again for these new tests.

So how do we fix the ‘Crash Dive Blues’ by setting the quick-tank to 0.5 after an interrupted crash-dive? One solution would be to set it to 0.5 when the hydroplanes are about zero (say 0 +/- 0.005). However, I think this will be quite difficult to code, since, once the U-boat has ended its interrupted crash dive (and is steady at high underwater speed, or is sinking at slow underwater speed), the calls in code to Sh3Sim.act+0x8527 become much, much less common. Something to think about. Incidentally, most of the variables I mentioned earlier are called from subroutine SH3Sim.act+0xAEB3. The quick-tank variable is called from elsewhere, but intercepted at +0x8527.

Stiebler.

h.sie

01-10-11, 07:16 AM

@Stiebler: Great. One step nearer to the solution.

Regarding the variables: They change almost everytime you load a new game, since they are allocated dynamically. That's the reason one cannot use absolute adressing. One needs a correctly initialized pointer instead. Sometimes, pointers are of high order (pointer that points to a pointer that points to the variable) and difficult to built, but I can help you.

E.g. the flooding level of the front torpedo room needs a pointer of 12th order. (pointer that points to a pointer that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer that points to the variable)

But: Instead of finding a pointer and changing the variable referenced by that pointer, I suggest to first try to find and modify the code that writes the variable. So you don't even need a pointer.

h.sie

Stiebler

01-10-11, 07:19 AM

Regarding the variables: They change almost everytime you load a new game, since they are allocated dynamically.True. But I thought they would be relative to a xxxx(0)000 boundary. Pity they are not.

[Edit:] And thanks for the code idea. I shall try to find the relevant code.

Stiebler.

Tessa

01-10-11, 07:36 AM

E.g. the flooding level of the front torpedo room needs a pointer of 12th order. (pointer that points to a pointer that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer that points to the variable)

But: Instead of finding a pointer and changing the variable referenced by that pointer, I suggest to first try to find and modify the code that writes the variable. So you don't even need a pointer.

h.sie

To write code such that it requires such a massive array of pointers is either severly careless coding, or the result of a recursive function where the 12th iteration gives you the number you need. Sorry that my knowledge of machine code is limited, but might I suggest you look at what the other pointers are linked to? I agree that using such a complex function is not very efficient, it may be done out of some necessity.

h.sie

01-10-11, 07:41 AM

It's common for modern 3D games, which are programmed object oriented with many objects including other objects and so on.

Class Submarine - contains sections - containing subsections - containing machines - containing damage counter.

Compiling/Linking the example above leads to a pointer of at least 5th order.

Hitman

01-10-11, 08:02 AM

@Stiebler and H.Sie

This is excellent news!

I hope that better comprehension of the tanks model for the game can help both making a better Anti-Humming-Bird mod, and a feature I think would be worth adding:

- A % random chance of crash dives getting out of control, as it happened in real life, with a risk of getting below crash depth and crushing. :up: Ideally more probable with greener crew, but this would probably be too complicated.

h.sie

01-10-11, 09:11 AM

Funny: The more progress I, or better WE, make the more wishes arise. To be honest: After fixing the crash dive blues (together with Stiebler) and after progging the external torpedo issue, I really plan to PLAY a sh3 career for the first time. I don't even know if I will like this game.

Silent Ace

01-10-11, 09:51 AM

See how easily and realistically performed control ballast tanks in the next little game-http://www.purely-games.com/unusual_submarine_game.html
Similar simulator at the Museum of Science and Industry in Chicago-http://www.msichicago.org/whats-here/exhibits/u-505/the-exhibit/interactives/buoyance-challenge/
Something like this implemented in GWX and NYGM would be a major step toward realistic management of U-boat.

h.sie

01-10-11, 09:55 AM

@Stiebler: I discovered an Crash Dive Flag (Byte) which is 1 only during crash dive and 0 otherwise, this could be used to control / fix the fast-dive-tank.

Simply writing repeatedly 0,5 into the memory won't help, since the program will repeatedly overwrite it again, so we'll have some dirty oscillation, which could result in a helicopter instead of a submarine. so it will be necessary to do some re-engineering and find the right code (the phyisical model behind that all) to fix. I'll also look at it in the next days. Really interesting.

Stiebler

01-10-11, 11:46 AM

@H.sie:

Your previous post acknowledged with thanks.

It is necessary for me, once again, to try to discover which memory locations are associated with the quick-dive tank, as I try to discover the code associated with this tank. Ho hum.

Stiebler.

Stiebler

01-10-11, 11:56 AM

@H.sie:
Is the crash-dive flag cancelled (=0) after an interrupted crash-dive?

If so, the programming solution should be fairly simple. Check the flag, and always set the quick-tank variable to 0.5000 if the flag is cancelled.

Doubtless this 'simple' solution will not work, or will become more complicated.

Stiebler.

h.sie

01-10-11, 11:58 AM

@Stiebler: For code finding purposes, I often look into the stack. The return adresses in the stack tell me, which routines called my routine, and so I often find the code I search for (stack trace). Also, the stack contains the arguments of the function calls, which also can help.

I'll be able to sit in front of my modding PC in 2 days. Unfortunately.
So I don't remember all details of this flags behaviour. But one can find it easily.

h.sie

h.sie

01-10-11, 01:23 PM

@Hitman: On the other hand: if we manage to fix the crash dive bug, we can easily add a certain chance that the crash dive ends on the ground of the ocean.

LGN1

01-10-11, 02:51 PM

Hi all,

when we discussed the compressed air topic I realized that you consume compressed air when you order a crash dive. My assumption was that the compressed air was used for blowing the quick diving tank. When you interrupt the crash dive this does not happen. Maybe this can help you to solve the crash dive blues :06: 'Give the order' to blow the quick diving tank?

Shouldnt it be possible to reload them all times? (at heavy seas only when dived maybe).

@Delareon: This is not a dumb question. It's a question that has to be discussed before I start programmming this. LGN1 wrote something about this topic earlier and via PM to me. Either we search the post or LGN1 is so kind to repeat what he knows regarding this question. Or any other historical information welcome, too.

As Delareon has written: the idea was to allow reloading internal torpedoes in case of a storm only submerged, i.e., if there is a storm and you want to reload internal torpedoes you have to dive.

See our old discussion on page 52 and my comment there:

http://www.subsim.com/radioroom/showpost.php?p=1564123&postcount=771

Cheers, LGN1

Stiebler

01-11-11, 08:18 AM

@H.sie:
The crash-dive routine is as follows:

The quick-dive tank is filled very fast. In order to see the filling, one has to make a break in the code at Sh3Sim.act+0x8527 immediately after pressing key 'C' (for crash-dive).

The relationship of key variables is this:
hydroplane (A) = (relative 0)
hydroplane (B) = hydroplaneA + 2C
diving tank = hydroplaneB + 1C
quick-dive tank= diving tank + 0x14
I've verified these relative values over four different cold starts of SH3 now, but you have to identify one of these starting variables first.

The quick-dive tank starts at 0.5000 (not at 0.0000, as I thought previously), and rises to 1.0000.
At a depth of about 35-39 metres (it varies even with the same IXC U-boat), the quick-dive tank starts to empty slowly.

The code which empties the quick-dive (q-d) tank is a subroutine called from Sh3Sim.act+0xB002, and located at Sh3Sim.act+0xA690.

This subroutine is called *only* to empty the q-d tank, not to fill it. The subroutine is NOT called after an interrupted crash-dive at 40-45 metres. Hence, the q-d tank never gets emptied (ie, restored from 1.0000 to 0.5000). It may be partially emptied, depending on what depth was reached before the crash-dive was interrupted.

When the U-boat is floating level at a depth of 40-45 metres (interrupted crash-dive), the only calls to Sh3Sim.act+0xAEB3 are to the hydroplanes. Otherwise, Sh3Sim.act+0x8527 provides a break-point for calls to hydroplanes and to the q-d tank.

Therefore it appears that the code needed to handle an interrupted crash-dive (to restore the q-d tank to a value of 0.5) is going to have be quite brutal. We could set a flag when the q-d tank fills to 1.0000 (occurs while the U-boat is still on the surface), check flag and depth and hydroplane status, then restore the q-d tank.

I think all three of these tests are going to be needed wherever, or however, the code gets implements (although your crashdiveflag that you reported earlier could replace the 'q-d tank = 1.0000' test.)

The big problem is this:
After an interrupted crash-dive, and if the player goes to speed = slow, the hydroplanes both have a steep up angle (about 0.5 for the front planes, and nearly as much for the rear hydroplanes), yet the U-boat continues to sink. Therefore the method of checking hydroplanes only works at high underwater speeds.

We need some new way of checking for an interrupted crash-dive, and I think this requires knowledge of depth plus something else. A crash-dive to 80m can be interrupted if the player clicks on the depthgauge for 40m, 80m or 120m, so it is necessary to check only that the depth is below the surface (>10m). But what is the 'something else'?

I suggest the simple test:
IF depth > 40m AND q-d tank value = 1.000
THEN q-d tank = 0.5000

That should resolve all problems, is easy to code, and we know that the q-d tank will be emptied to 0.5000 below 40m anyway! The only potential problem is that the U-boat will now sink less quickly to the crash-dive depth - but it will be safely below the surface. (Implement in code at or near Sh3Sim.act+0x8529.)

In fact, possibly (?) we can even remove the test for the q-d tank - implement the code whenever the depth falls below 40m however the player chooses to dive.

Stiebler.

h.sie

01-11-11, 08:50 AM

@Stiebler: I'll look into it this evening. Higher priority than external torpedoes.

My ideas are similar, but we may not forget the blow ballast. If we permanently force q-d-tank=0.500 when depth > 40m, then a blow ballast would not work as intended (provided blow ballast affects q-d-tank, but I think so).

h.sie

LGN1

01-11-11, 01:44 PM

I suggest the simple test:
IF depth > 40m AND q-d tank value = 1.000
THEN q-d tank = 0.5000

That should resolve all problems, is easy to code, and we know that the q-d tank will be emptied to 0.5000 below 40m anyway! The only potential problem is that the U-boat will now sink less quickly to the crash-dive depth - but it will be safely below the surface. (Implement in code at or near Sh3Sim.act+0x8529.)

In fact, possibly (?) we can even remove the test for the q-d tank - implement the code whenever the depth falls below 40m however the player chooses to dive.

Stiebler.

Hi Stiebler,

nice work :up: The first version, however, might be problematic for people that have a less deep crash-dive depth in their cfg files so that their q-d tank value is already smaller than 1 at 40m :hmmm: I think one should keep it in mind that different people/mods have different crash-dive depths.

Cheers, LGN1

LGN1

01-11-11, 02:27 PM

@Stiebler and H.Sie

...a feature I think would be worth adding:

- A % random chance of crash dives getting out of control, as it happened in real life, with a risk of getting below crash depth and crushing. :up: Ideally more probable with greener crew, but this would probably be too complicated.

Hi Hitman,

shouldn't there be a possibility to stop the crash dive somehow? If there is none, I'm wondering what the idea is? Wouldn't this just be a random chance for a career end whenever you press 'c' :06:, i.e., whenever you press 'c' you play a virtual Russian Roulette?

h.sie

01-11-11, 05:27 PM

@Stiebler: According to my observations the q-d tank is emptied, but extremely slow when crash dive is interrupted.

In both cases (non-interrupted and interrupted crashdive), different routines write to the q-d tank.

By the way: If you have the address of the q-d-tank, simply add 0x8 and you'll have the address of the "crash dive flag" (a single byte), which could be useful.

I'm tired now and continue during the next days.

Gähn!!!
h.sie

Stiebler

01-12-11, 05:42 AM

@H.sie:

Thanks for this important information.
I have sent a PM.

@LGN1:
The first version, however, might be problematic for people that have a less deep crash-dive depth in their cfg files so that their q-d tank value is already smaller than 1 at 40m :hmmm: I think one should keep it in mind that different people/mods have different crash-dive depths.You make a valid point.
The code I have in mind will simply reset the quick-diving tank as soon as the U-boat sinks below 40m.
Therefore, if a player has crash-dive depth set to (say) 20m, the 'crash-dive blues' will be ended as soon as the boat sinks below 40m. Thus, there will be a problem only if the player tries to maintain a depth set to less than 40m, after ordering the crash-dive.
But in any case, if the crash-dive depth is set at 20m, it is probably a simple solution just to allow the crash-dive to settle out before diving deeper. You will have time for that. You may not have time if the crash-dive depth is set to 80 metres.

I believe that I am very close to getting right the code for the solution that I have proposed. Then we shall know if this solution affects the ability to blow ballast, has H.sie has suggested. And we can test other matters, as LGN1 has mentioned, also.

Stiebler.

NGT

01-12-11, 06:31 AM

h.sie

01-12-11, 06:51 AM

@Stiebler: Yesterday I discovered that under certain circumstances (crash-dive interrupted but q-d-tank not completely filled to 1,0) the q-d-tank indeed goes back to 0.5, but very, very slowly, because a certain routine R continuously writes data into it.

So if you simply reset the q-d-tank to 0.5 once, you risk that this value will be overwritten under the above-mentioned circumstances.

And if you write 0.5 repeatedly, this will interfere with the values from the above-mentioned routine R, which also tries to write other values into the q-d-tank. This can lead to "oscillations".

Since the above-mentioned routine R also writes to other things different from q-d-tank, one cannot simply disable or patch it. Patching / disabling the routine R will only work, if one finds out, if R is currently trying to write into the q-d-tank or not. For this reason we need to work with pointers.

So my approach is a soft-hand-solution by trying to understand how R works and then modify it accordingly, but only if the pointer register currently points to the q-d-tank.

Happy hacking!
h.sie

BogdaNz

01-12-11, 09:41 AM

i want realistic repair and flooding time mode but i dont see no link :doh:
i looked at last page but there are only description ,no link:down:

Magic1111

01-12-11, 10:59 AM

i want realistic repair and flooding time mode but i dont see no link :doh:
i looked at last page but there are only description ,no link:down:

Open your eyes and read first post on first page carefully (read under "Step3"...)!

Here are the download link: http://www.mediafire.com/?a6j533a02wsf39d

Best regards,
Magic

Stiebler

01-12-11, 12:03 PM

@H.sie:
@Stiebler: Yesterday I discovered that under certain circumstances (crash-dive interrupted but q-d-tank not completely filled to 1,0) the q-d-tank indeed goes back to 0.5, but very, very slowly, because a certain routine R continuously writes data into it.... [+ More]Not a problem (I think...).

I found that, by observing the crash-dive flag that you found earlier, the flag is set to false (from true = 1) when either of these circumstances occur:
a) the q-d-tank starts to empty.
b) the crash-dive is interrupted.
When the crash-dive flag is false, the q-d-tank is not emptied at all, and the code is not used.

Using this information, I have now complete code that does everything I intended. (Whether what I intended will work usefully, remains to be seen.)

I need only to fix a simple bug (forgot to reset jump addresses when changing the label at the new address), and I expect to have fully working code.

However, there remains a significant problem:
I am testing for the q-d-tank by asking of each value of ecx at my breakpoint if a filled diving tank is at location [q-d-tank - 0x14].
What happens is that the q-d-tank fills too quickly, before the diving tank is itself filled. After that the q-d-tank/ecx value is not encountered again until the q-d-tank starts to empty at about 40m.
So everything works fine, *provided* that no one interrupts the crash-dive before the U-boat has reached around 40m.
I have an alternative idea to fix this, but first I want to confirm the properties of a U-boat whose crash-dive has been interrupted at 40-50m.

That is tomorrow's problem - if I have time.

@NGT:
I understand your argument perfectly, and perhaps we could make the code run from 18m, not from 40m.
But first, I must test that the guiding principle works.

Stiebler.

Captain Birdseye

01-12-11, 12:28 PM

Guys I can't understand the instructions.

I have copied my sh3.exe to my desktop but the batch file still says incorrect check sum, saying fciv isn't recognised. I have version 1.4.0.1

Thanks.

WH4K

01-12-11, 01:36 PM

SquareSteelBar

01-12-11, 01:37 PM

You have to copy fciv.exe to the desktop, too

LGN1

01-12-11, 01:59 PM

Hello Stiebler and h.Sie

The reason for crash–dive in depth less than 25 meters is —for me— simple:

Shallow waters (example: around Britain, raids in ports etc.) + no crash–dive–blues.

Of course, without crash–dive–blues, we can tweak the crash–dive for 300 meters, and interrupt (or restart) at any depth.

So, I don’t understand very well the critical point of 40 meters. If —anyway— I must pass below 40 meters, this solution is not valuable when in shallow waters.

I miss something, yes? :hmmm:

Hi NGT,

I think also in real-life you could not crash-dive in shallow water because you needed a certain depth to stop the diving. So, not being able to use the crash dive command in water shallower than, let's say 40m, sounds realistic to me:06:

Personally, I think the 40m 'boundary' would be fine (I think most super-mods have a deeper crash-dive depth than 40m. So, most players would be fine).

Cheers, LGN1

h.sie

01-12-11, 04:40 PM

@Stiebler: I have different observations, in the following situation:

1) Order crash dive.

2) When boat has depth of about 20m, interrupt dive by ordering new depth of 40m.

This leads to a very slow but constant empying process of the q-d-tank. During this time the code at Sh3Sim.act+0xA7B7:

fst dword ptr [ecx+08]

constantly writes new values into the q-d-tank. This process takes about 5 minutes, until q-d-tank is 0,5.

Happy hacking!
h.sie

Stiebler

01-12-11, 05:15 PM

@H.sie:
Thanks for the new info.

But.... I have solved it all!!

First, I have now functioning code that checks for an interrupted crash-dive and writes 0.500 to the q-d-tank. This works well, with *no* depth limitation, but subject to the complicated limitation that the q-d-tank must be full (1.0000) before the code functions. So you cannot interrupt the crash-dive with a new depth until about 20-30 seconds of game time have elapsed. I had written elaborate code to identify the q-d-tank variable and to separate it from the main diving tank.

If the code is allowed to function properly, then an interrupted crash-dive maintains its new depth at slow underwater speed indefinitely. I have tested it, it is true.
Also the 'blow ballast' function works perfectly both with a completed crash-dive and with an interrupted crash-dive. I have tested it, it is true.

So I have a working program. With a lot of heavy code to identify the q-d-tank and its crash-dive flag.

But I have discovered something else!
the q-d-tank is referenced by float [esi+438h].
the crash-dive flag is referenced by byte [esi+440h].

Tomorrow, I shall re-write my code much simpler, and with no timing or depth limitation!

Stiebler.

ryanwigginton

01-12-11, 11:54 PM

Join the club.

The problem is simple: There are about half a dozen different variants of sh3.exe. h.sie's mod only works with one of them.

Yet, they're all the "same" version, 1.4. But not really, as they are all different in subtle ways.

Some sh3.exe's include hooks for the Starforce malware. Newer ones don't, yet are still incompatible with the patcher.

Tell me about it. I've been following this thread from the start. The other day I decided I couldn't wait any longer and tried to use the patch. Wrong checksum. :damn:

I have a later, budget 'Focus Essential' disc version. No starforce as far as I know, but still, wrong checksum. :wah:

But I have absolute faith in h.sie's abilities and (being an optimist) believe once he's created all the changes he wants, he or Stiebler will turn their efforts to improving compatibility. We can only hope. :D

h.sie

01-13-11, 02:34 AM

@H.sie:

But I have discovered something else!
the q-d-tank is referenced by float [esi+438h].
the crash-dive flag is referenced by byte [esi+440h].

Stiebler.

@Stiebler: What's wrong with that? I don't see any problem.

Congratulations to your fix. I also have a fix that still has some problems. Short code but difficult, since it uses pointers. So as always: 2 solutions are better that none.

Your fix is only located in SH3Sim.act or does it also change sh3.exe?

h.sie

Stiebler

01-13-11, 07:05 AM

I have fixed the crash-dive blues.

Code principle is completely trivial:
IF (crash-dive-flag = 0) THEN quick-dive tank = 0.5000.

Of course, it took H.sie and me some time to discover all the key features. I myself wrote over one page of assembly code just to locate the quick-diving tank. Then I found it fixed at [esi+438h], so I could reduce all the code to a few lines!

The fix appears to solve all problems, even though it sets q-d-tank to 0.500 on surface, when value should be 0.000 (sometimes).

This code is also called uselessly every time there is a call to the hydroplanes. However, the code is so compact, that any code to avoid this useless recall would probably be a lot slower!

I've given everything a massive test under all dive conditions that I can think of: crash-dives, interrupted crash-dives by clicking on depth-gauge above and below crash-depth, conventional dives, orders to periscope depth, interrupted crash-dive with order to periscope depth, blowing ballast, resumed crash dives after interruption. *Everything" works well, with full stability at slow underwater speed.

I shall release the code for some bold testers after H.sie has examined it.

@H.sie:
You have a PM.
You need SH3SIm.act only, no need to alter sh3.exe.

Stiebler.

h.sie

01-13-11, 07:25 AM

@Stiebler: That would be really great!!! I'll look into it ASAP.

One thing I ask myself: With your fix the q-d-tank is 0,5 instead of (as you wrote) 0.0 when surfaced. Doesn't this change the boats physics when surfaced, since the boats mass is higher??

h.sie

Stiebler

01-13-11, 08:51 AM

I have found in further testing that the value of esi, used to point to the crash-dive flag and the q-d-tank, varies repeatedly in the vicinity of a convoy, and ultimately causes a serious computer crash (values written to wrong memory).

Back to the drawing-board.

@H.sie:
One thing I ask myself: With your fix the q-d-tank is 0,5 instead of (as you wrote) 0.0 when surfaced. Doesn't this change the boats physics when surfaced, since the boats mass is higher??I considered that, too. But the U-boat seems to ride perfectly well in the water on the surface.

I also considered if a residual value of 0.500 in the q-d-tank might affect depth-keeping after an interrupted crash-dive at periscope depth, or if it would affect rate of rising from deep waters. Or maybe the crash-dive rate might be affected.

None of these parameters seem to be affected enough to notice.

Stiebler.

h.sie

01-13-11, 03:53 PM

@Stiebler: Good news: I was able to reconstruct direct pointers to the quick-dive tank and the crash-dive flag, so they both can easily be accessed & manipulated from the little controlling routine I programmed in sh3.exe for continuously watching/controlling multiple things (like snorkel speed restriction and so on). I don't have to patch Sh3Sim.act. So my fix will work very similar to yours, but without risking to write into wrong memory locations:

Immediately (or some seconds after) the crash-dive flag is set from 1 back to 0, I force q-d-tank=0,5 once.

And since the fix is active only in the special situation when crash-dive flag is switched from 1 back to 0, it won't affect other situations, e.g. when boat is surfaced.

That's it. Very optimistic that it will work.
h.sie

h.sie

01-13-11, 05:14 PM

I think the "crash dive blues" is history. After some tests I think one can now interrupt the crash dive anytime without losing control of the boat. The fix is only active once, immediately after a crash dive is interrupted, that means: it does not affect boats physics in other situations. (Yeah!)

@Stiebler: Will send you a PM with a BETA version, including Fix code.

h.sie

Stiebler

01-14-11, 11:53 AM

@H.sie,

Great work!

I shall test it immediately. You have a PM.

Stiebler.

Fubar2Niner

01-14-11, 01:03 PM

@h.sie & @Stiebler

Geez guys, don't you ever take a break, I'm going to nominate you both for next years awards already :yeah:

Best regards.

Fubar2Niner

Magic1111

01-14-11, 03:31 PM

@h.sie & @Stiebler

I'm going to nominate you both for next years awards already :yeah:

Best regards.

Fubar2Niner

...yes, me too...:yeah::ping::yeah::up::yep:

h.sie

01-15-11, 06:39 AM

Thanks guys. The best award for me is a working sim.

Waiting now for Stieblers final test results...........

Stiebler

01-15-11, 09:59 AM

Nominate H.sie for the award, not me.

He does all the hard work.

Test results so far:
H.sie's fix for the Crash-dive blues works perfectly.

I have tested it in convoys with crash-dives, interrupted crash-dives, with damage, without damage, after air attacks, after destroyer attacks, with silent running, without silent running, and reloading after a saved game. Everything so far is perfect.

Stiebler.

h.sie

01-15-11, 10:20 AM

Great! So I'm pleased to announce the "Fix for the Crash Dive Blues by h.sie and Stiebler" (whose idea I used in the fix) to be included in the forthcoming patch version V15E. But it will take some time to program the (external) torpedo reload issue.

Crash dive blues now is history!

h.sie

LGN1

01-15-11, 10:24 AM

Great news, h.sie & Stiebler :up: I'm looking forward to V15E!

Cheers, LGN1

Delareon

01-15-11, 03:05 PM

Does this also mean the bug where u cant save your game while dived should be fixed (because your boat sometimes sinks and you cant do anything against it)?
(Probably fixed of course always with the risk of a bug while in mass tests but....you know ;) )

Never experienced the bug myself because since i first heard about that bug from multiple sources i never tried it on my own.

fitzcarraldo

01-15-11, 03:17 PM

Madox58

01-15-11, 03:22 PM

Fantastic work Guys!
:rock:

@Delareon

It MAY solve some issues with saved Games stuff.
But my research says there's a different reason for Saved corruptions.
Most are from useing the early version of SH3 with StarForce.
And other problems from useing the Reloaded hack.

Myxale

01-15-11, 04:37 PM

Dude, your epic...like Moses!:rock:

The Crash-Dive Blues was around since the Dawn of time and every mega-mod.-

Kudos to both of you!:yeah::salute: This is almost a historic day.

h.sie

01-15-11, 07:08 PM

Thank you, guys!!!!

Now the bad news regarding reloading of external torpedoes:

Trying to program a 5-10 minutes delay for all diving commands when reloading of external torpedoes has to be interrupted because of enemy contact, I found out that the necessary code is getting more and more complex and cluttering. I give up. So if you want to play realistic, you need to have the discipline to delay the diving by yourself.

I will only be able to interrupt reloading of external torpedoes during bad weather and maybe interrupt reloading of internal torpedoes during storm and when boat is not dived deep enough.

Sorry!
h.sie

fitzcarraldo

01-15-11, 07:17 PM

Thank you, guys!!!!

Now the bad news regarding reloading of external torpedoes:

Trying to program a 5-10 minutes delay for all diving commands when reloading of external torpedoes has to be interrupted because of enemy contact, I found out that the necessary code is getting more and more complex and cluttering. I give up. So if you want to play realistc, you need to have the discipline to delay the diving by yourself.

I will only be able to interrupt reloading of external torpedoes during bad weather and maybe interrupt reloading of internal torpedoes during storm and when boat is not dived deep enough.

Sorry!
h.sie

No problem. we are all disciplined kaleuns...This means we´ll have the new version soon?

Many thanks!

Fitzcarraldo :salute:

makman94

01-17-11, 01:38 AM

hello ,

can someone tell what exactly is the issue with the crash dive ?

i am asking becuase ,from what i have read about this issue,...i don't see it happening to 'my' sub . is it something like that sub doesn't level up and stays with the bow 'looking' down ?

Magic1111

01-17-11, 03:40 AM

The Crash-Dive Blues

Hi !

Can someone me explain please, what the "Crash-Dive-Blues" exactly is ? :hmmm: I´ve never heard about it....

And what is now all fixed in the forthcoming V15E ??? :06:

I follow this Thread every day, but my english is not soooo good, that I understand each post here ! :oops:

Thanks in forward,
Magic:salute:

h.sie

01-17-11, 04:07 AM

Stiebler

01-17-11, 04:08 AM

Evidently Makman and Magic do not use NYGM. Allow me to recommend that you both try it.

The crash-dive blues occurs when you order a crash-dive; then, *before the crash-dive has completed*, you order a new depth. For example, if your crash-depth depth is 80m, you click on the depth gauge for 150m before the U-boat reaches about 60-70 m.

This causes the U-boat to dive to 150m at an angle. We know now that this angle is caused because the quick-dive tank has not emptied. The quick-dive tank only returns to its normal level when the crash-dive is complete.

It is very hard to control the U-boat at any depth at slow speed, when it floats at an angle.

This is especially noticeable with NYGM, because of its anti-hover mod (no U-boat can hover underwater, it needs forward speed to maintain depth on the hydroplanes.) However, it is also noticeable with stock SH3.

The situation is different with GWX, which has a deliberate buoyancy - the U-boat tries to rise at slow speeds. This is not accurate, though.

Before H.sie's fix, the only way to stop the crash-dive blues was to rise to above the crash-dive depth (for example, rise from 150m to 50m), then crash-dive again, in order to empty the tank. Probably all players of NYGM (and perhaps of stock SH3, Rub, Aces, LivingSH3 etc) have learned this fact the hard way!

[Edit: Ooops. I see that my post has clashed with that of H.sie, who made his post just one minute before mine.]

Stiebler.

h.sie

01-17-11, 04:20 AM

There is a compatibility problem between the Type XXIII sub in NYGM and the periscope mod of V15D, which automatically moves down the periscopes when speed is above 7knots.

Trying to fix this incompatibility only makes sense, if someome of you uses/likes this periscopes mod. So please give some feedback. Do you use/like it?

I e.g. perfer the blur effect and came to the conclusion that it's not necessary that the scopes are moved down automatically.

h.sie

NGT

01-17-11, 09:19 AM

Trying to fix this incompatibility only makes sense, if someone of you uses/likes this periscopes mod. So please give some feedback. Do you use/like it?

I e.g. prefer the blur effect and came to the conclusion that it's not necessary that the scopes are moved down automatically.

h.sie

Yes, please

I play NYGM mod and I like this periscopes mod. I don't use the blur effect.

With periscope tweaked to go down, the game-play is harder for old people like me, using automatic targeting. Because with automatic targeting I can take down any destroyer coming close to me IF THE PERISCOPE IS UP. Even with blur effect, the target can be fixed and the torpedo goes straight to the target.

So, this mod change all the game-play for automatic targeting people, and we are oblige to dive instead of play always successful duels with destroyers.

Nice change after 5 years, thanks to you h.sie :yeah: :rock:

h.sie

01-17-11, 12:17 PM

Ok, NGT, I'll try my best to fix that bug. If I'm unable to do, I'll try the second-best solution: Disable periscopes mod only for type XXIII.

h.sie

01-17-11, 03:16 PM

I already found the reason for the problems with my V15D4 patch and NYGM type XXIII: It has only one (active) periscope, but my mod assumes that there are always two peris. trying to lower both peris when there is only one active will cause a CTD. this will be fixed in the next version.

Fader_Berg

01-17-11, 03:22 PM

Ok, NGT, I'll try my best to fix that bug. If I'm unable to do, I'll try the second-best solution: Disable periscopes mod only for type XXIII.

Stay away from the second best solution... That's my five cents. Either the sub changes or it was just not ment to be.

EDIT:
I already found the reason for the problems with my V15D4 patch and NYGM type XXIII: It has only one (active) periscope, but my mod assumes that there are always two peris. trying to lower both peris when there is only one active will cause a CTD. this will be fixed in the next version.

Nevermind...

Stiebler

01-18-11, 03:20 AM

@H.sie:
I already found the reason for the problems with my V15D4 patch and NYGM type XXIII:That was quick. Good work!

Stiebler.

Magic1111

01-18-11, 06:46 AM

@Magic1111 & Makman:

If you interrupt a crash dive (by setting a new depth) before the sub reaches his crash dive depth (70m?), you may lose the control over the sub - the sub is hanging there aslope with an angle of about 10 degrees. This bug mainly occurs in NYGM, I assume, because of the negative bouyancy used in that supermod. Search the NYGM thread for details.

The reason for this bug is, that the quick-diving-tank is not emptied correctly when you interrupt a crash-dive. The positive buoyancy in GWX seems to hide/compensate this effect, but it will be visible e.g. when compartments are flooded.

The fix from Stiebler and me empties the quick-diving-tank in this situation.

If V15E is done, I'll tell more details about the changes.

h.sie

Evidently Makman and Magic do not use NYGM. Allow me to recommend that you both try it.

The crash-dive blues occurs when you order a crash-dive; then, *before the crash-dive has completed*, you order a new depth. For example, if your crash-depth depth is 80m, you click on the depth gauge for 150m before the U-boat reaches about 60-70 m.

This causes the U-boat to dive to 150m at an angle. We know now that this angle is caused because the quick-dive tank has not emptied. The quick-dive tank only returns to its normal level when the crash-dive is complete.

It is very hard to control the U-boat at any depth at slow speed, when it floats at an angle.

This is especially noticeable with NYGM, because of its anti-hover mod (no U-boat can hover underwater, it needs forward speed to maintain depth on the hydroplanes.) However, it is also noticeable with stock SH3.

The situation is different with GWX, which has a deliberate buoyancy - the U-boat tries to rise at slow speeds. This is not accurate, though.

Before H.sie's fix, the only way to stop the crash-dive blues was to rise to above the crash-dive depth (for example, rise from 150m to 50m), then crash-dive again, in order to empty the tank. Probably all players of NYGM (and perhaps of stock SH3, Rub, Aces, LivingSH3 etc) have learned this fact the hard way!

[Edit: Ooops. I see that my post has clashed with that of H.sie, who made his post just one minute before mine.]

Stiebler.

@ h.sie and Stiebler: Many thanks for clearify ! :salute:

Best regards,
Magic

NGT

01-18-11, 09:59 AM

I already found the reason for the problems with my V15D4 patch and NYGM type XXIII............................................. .. this will be fixed in the next version.

Thank you very much h.sie :up:

h.sie

01-21-11, 03:29 PM

Little Bugfix V15D5 available. This update is worth downloading only for NYGM players, because it only fixes an incompatibility with the NYGM type XXIII (CTD when periscope is moved down automatically). But there will be a new Version available soon:

Current work: V15E

Bugfix for crash dive blues
"Realistic" restrictions for reload of external / internal torpedoes.

Magic1111

01-21-11, 06:15 PM

This update is worth downloading only for NYGM players,

...but you have two versions on you MediaFire Page, one with (NYGM) in clamp and one without this...?:hmmm:

Are now both Versions for NYGM Players or do I need as not NYGM-Player the version without the (NYGM) in clamp ?:hmmm:

Best regards,
Magic

fitzcarraldo

01-21-11, 07:35 PM

Great job, and waiting the "E" update.:yeah:

A dream: independence of port-starboard motors (diesel and electric). Is there some possibility from the perspective of modifiy the SH3.exe?

Many thanks and best regards.

Fitzcarraldo :salute:

Silent Ace

01-22-11, 02:09 AM

Great job, and waiting the "E" update.

A dream: independence of port-starboard motors (diesel and electric). Is there some possibility from the perspective of modifiy the SH3.exe?

oh yes, as it is carried on a ship simulator series.

h.sie

01-22-11, 02:17 PM

@Magic: This was only to have 2 equal versions.

@fitzcarraldo: The engines can be controlled independently from each other in principle, but the main problem are the missing interaction elements for the user. GUI elements, system commands and so on are designed for controlling both machines together. I think this will remain a dream, as long as I do this kind of modding. But maybe a more experienced and talented modder will be able to fulfill your dream.

h.sie

h.sie

01-22-11, 02:29 PM

Currently programming the reload process of INTERNAL TORPEDOES and I need some details.

My plan:

When surfaced, internal torpedoes can only be reloaded for
windspeeds between 0m/s and W1.

For windspeed between W1 and W2 boat has to dive below D1 meters.

For windspeed between W2 and 15m/s boat has to dive below D2 meters.

What values W1, W2, D1, D2 should be used?

Some historical info available?

Silent Ace

01-22-11, 03:05 PM

Currently programming the reload process of INTERNAL TORPEDOES and I need some details.

Some historical info available?

I will try to find something.

Magic1111

01-22-11, 03:25 PM

@Magic: This was only to have 2 equal versions.

h.sie

Okay, thanks !

LGN1

01-23-11, 06:51 AM

Hi h.sie,

I guess there is no historical data. Commanders just dived until the boat stopped rolling and pitching too much. Given the wind speeds in SH3 and the corresponding wave heights, I would guess that 20m should be fine. Since diving 10-20m deeper does not matter much, I think one single depth for all wind speeds would be fine. The two depths depending on wind speed seems to me more complex than necessary.

Cheers, LGN1

Stiebler

01-28-11, 06:10 AM

Just a bump, to keep this important thread near the top of the Mods page.

Also, an update.

A. H.sie is still working on the torpedo reloads problem, but he is held up with real-life issues.

B. Most players of SH3 are familiar with the irritating problem of running along the surface in fine weather at time compression (TC)= 1024 or more, when, suddenly, you get the Black Screen of Death: 'You have been sunk by Collision.' What has happened has been that the weather has changed suddenly to dense fog, your idiot watch crew has not bothered to tell you, and you have moved with large jumps - as the game moves the U-boat 'piece' across its giant board - straight onto a ship without ever seeing it first. (At slow TC, this is not a problem, because the jumps are much smaller).
H.sie and I have had the idea that, whenever heavy fog first occurs as a change from other visibility, then the TC will drop to 16. Since TC=16 is not used for any other purpose, the cause will be obvious to the player, who can stop, check the weather, and take appropriate action.

C. I have found a way to provide the U-boat with slow-sinking properties at 1 kt or less when it is silent-running. This has caused a lot of technical problems:
i) the U-boat floats at 2 kts at periscope depth about 1-2 metres lower than previously.
ii) The GWX U-boat has different buoyancy properties from the NYGM, which is an issue that has to be addressed somehow.
iii) The same code is needed for all U-boats, which causes the type II U-boat to be tricky to control at periscope depth when silent-running.

These issues can be avoided. The periscope control problems (i) and (iii) are avoided by ensuring that the new code operates only at depths below 20m. (A better solution might be to extend the periscope lengths in the turms.) The GWX issue is avoided easiest by changing the U-boat mass in GWX back to neutral.

The idea is that a U-boat lacks the ability to pump water when silent-running, so that there is in real life a tendency to sink slowly when the speed is too slow.
The result of this new code is that your U-boat has a tendency to slip slowly downwards when silent-running at slow speed below 20m. The tendency is not very strong, but it has the effect that you will not wish any longer to run into a convoy on silent running from the moment you sight it. Silent-running now needs a little management, especially when avoiding warships at great depth. Depth is maintained on a U-boat by hydroplanes. If you are running level at 2 kts with silent-running, and you set a higher depth, the hydroplanes acquire a steeper angle, so that the U-boat loses buoyancy while it also loses speed to 1 kt. So suddenly you start to sink instead! The devs really did a great job on modelling U-boat manoeuvrability.

So what do you do when you are being hunted, and the U-boat is slow-sinking at 160m? You can secure from silent running, or you can increase speed to increase the water flow over the hydroplanes, so that they are more effective. Both options will make more noise, which may be detected by the hunters. Suddenly management of silent-running becomes important!

I have a fully modded version of SH3.exe for silent-running on my own computer, but Copyright (and SubSim) rules prevent me from distributing it for general testing. However, H.sie will soon be able to make an SH3 patch file for legitimate owners. I want H.sie to check out the code first, anyway.

D. Anvart and I are working on some ideas concerning the placement of radars on different turms. A little of this also requires intervention in the SH3.exe code.

We cannot tell yet how these ideas will develop; whether they will be successful or not. But H.sie and I don't need any other new ideas for a little while, thanks!

Stiebler.

h.sie

01-28-11, 06:45 AM

Still lurking here from time to time.

The fog warning Stiebler mentioned above will be included in forthcoming V15E. also the fix for the crash dive blues and also the external/internal torpedo reload fix (speed restriction during external reload, no external/internal reload when storm, delayed diving).

After that I'll have time to look into the negativ bouyancy issue. I think that it will be a huge project (worth a new version V15F) to eliminale unwanted side-effects and make it compatible to GWX and NYGM (and other supermods).

@Stiebler: If you don't want to wait, I could tell you how to make your own patch so that you could start testing with others.......it's easy!

h.sie

Myxale

01-28-11, 08:22 AM

Great news people! Keep up the magical works!:rock:

@Stiebler

I remember the old NYGM, has something like negative buoyancy. Or anti-hummingbird effect as they called it!

Inst that the same thing? sorry if this has already been asked!:88)

Stiebler

01-28-11, 02:40 PM

@Myxale:

The anti-humming bird mod in NYGM is intended to prevent the U-boat from hovering underwater at 0 kts, and is independent of whether or not the U-boat is silent-running. As you say, it does create an anti-buoyancy specific to NYGM. Probably it could now be removed from NYGM, but that needs a lot of further testing.

The Silent-Running change is a different mod, implemented directly in code. It is actually an extension of the crash-dive blues fix.

@H.sie:
You have PM.

Stiebler.

Magic1111

01-28-11, 06:34 PM

NGT

01-29-11, 06:16 AM

Still lurking here from time to time.

The fog warning Stiebler mentioned above will be included in forthcoming V15E. also the fix for the crash dive blues and also the external/internal torpedo reload fix (speed restriction during external reload, no external/internal reload when storm, delayed diving).
.................................................. ....................................
.................................................. ....................................

@Stiebler: If you don't want to wait, I could tell you how to make your own patch so that you could start testing with others.......it's easy!

h.sie

@h.sie and Stiebler:

If you need help for testing, I am disposable :DL

Stiebler

01-29-11, 10:26 AM

I have now placed a patch (StieblerSR1.7z) for SH3.exe, courtesy of H.sie, onto this link:

http://www.subsim.com/mods1/nygm/StieblerSR1.7z

You will need to make the patch exactly the same way as with H.sie's V15D patches, starting from an *unmodified* version of SH3.exe that lacks Starforce. Instructions available with the download - please read them!

For convenience, the patch contains all H.sie's previous fixes from V15D and his Crash-Dive Blues fix.

Feedback welcome - especially from users of GWX, which I do not test, and whose buoyancy model is different from stock SH3 and NYGM.

I believe that it is going to be necessary to adapt the value of the slow-sinking variable in the mod for each different U-boat type (II, VII, IX, IXD, XXI), but I have not yet done this. One general value is used for all U-boats.

Stiebler.

LGN1

01-29-11, 11:48 AM

Hi Stiebler,

just two short questions:

- Didn't the crew trim the boat slightly positive so that without speed the boat was raising? I think I read something like that before. They did it for safety purposes (you prefer going up over going down if you have problems).

- In real-life you could pump water around in the boat during depth-charge explosions. This seems not to be possible in SH3. So aren't you more punished in game than it is realistic with your patch?

Regards, LGN1

LGN1

01-29-11, 11:54 AM

Hi h.sie,

will it easily be possible to switch off the fog warning? I ask because I guess many players never use TC=1024 and higher and thus, do not need this feature (didn't you recommend to use lower TC because of problems inside the code?).

Cheers, LGN1

h.sie

01-29-11, 11:57 AM

@lgn1:

yupp, every fix can be disabled individually

h.sie

LGN1

01-29-11, 12:09 PM

Hi h.sie,

thanks for the reply and the possibility to switch off the fog warning :up: I hope your real-life issues are not bad issues!

BTW, have you thought about the CO2 issue? Last week I read another report of a Kaleun who did not submerge for too long during his trip through the Bay of Biscay because he wanted to save the Kalipatronen/O2 for his operational area. I'm pretty sure now that the total submerged time during a patrol was limited. In other words, it's quite unrealistic how this is handled in game at the moment and I think, limiting the submerged time over a complete patrol would definitely add an interesting new element to the sim (especially in mid-war when you do not yet have a snorkel and there are already quite a few planes around).

Anyway, I am looking forward to V15E!

Cheers, LGN1

h.sie

01-29-11, 12:37 PM

Stiebler

01-29-11, 02:48 PM

@LGN1:

- Didn't the crew trim the boat slightly positive so that without speed the boat was raising? I think I read something like that before. They did it for safety purposes (you prefer going up over going down if you have problems).True, but not when attacking convoys, for obvious reasons - you really don't want your submarine to pop out of the water from periscope depth. There are numerous accounts of U-boats slowing filling up with water while silent-running at deep depths. And then slowly sinking, because the trim was altered.

- In real-life you could pump water around in the boat during depth-charge explosions. This seems not to be possible in SH3. So aren't you more punished in game than it is realistic with your patch?Also true, but this is a question of degree/extent. The idea of the mod is to force the player to manage silent-running, and not to have it switched on at all times when in the vicinity of warships. The SR mod is not very effective - you will not sink fast, and only when the underwater speed is around 1 kt. But it forces the player to think about the management of this issue. The old 'Aces of the Deep' U-boat simulation mimicked this very well, but SH3 currently lacks the facility completely.

Stiebler.

LGN1

01-30-11, 05:52 AM

Hi LGN1,

no bad issues. thanks.

regarding kalipatronen / diving time: I see no chance so far for this idea, because the kalipatronen supply must be stored in the savegame, but I don't know how to store additional stuff. so I can only mod sh3 to have average diving times.

h.sie

Hi h.sie,

good to know that it's nothing serious!

Concerning diving times: I understand that you cannot save any new variable, but one could just use the CO2 variable. It's stored in a savegame. In addition, it's anyway wrong at the moment. It should be constant until you have no O2 left and not rise linearly during being submerged. So, the CO2 dial would just become an O2 dial which decreases linearly during being submerged (showing the O2 supply left).

Cheers, LGN1

h.sie

01-30-11, 07:46 AM

@LGN1: but then we don't have a CO2 level which limits the duration of a single diving. we only have limited the total diving time for the whole mission.

Fader_Berg maybe had a good idea regarding saving. This could work.

Milestones for the next year :DL:

1) Finish V15E. Almost done.

2) Look into negative bouyancy for V15F.

3) Try to save a counter (for kalipatronen) that limits total diving time for whole mission. But I'm pessimistic that it can be done easily.

4) Start to play SH3 and don't accept new ideas :DL.

h.sie

Magic1111

01-30-11, 07:50 AM

@LGN1: but then we don't have a CO2 level which limits the duration of a single diving. we only have limited the total diving time for the whole mission.

Fader_Berg maybe had a good idea regarding saving. This could work.

Milestones for the next year :DL:

1) Finish V15E. Almost done.

2) Look into negative bouyancy for V15F.

3) Try to save a counter (for kalipatronen) that limits total diving time for whole mission.

4) Start to play SH3 and don't accept new ideas :DL.

h.sie

Good steps h.sie ! :up:

LGN1

01-30-11, 12:24 PM

@LGN1: but then we don't have a CO2 level which limits the duration of a single diving. we only have limited the total diving time for the whole mission.

Hi h.sie,

sure, we have. It's the oxygen left. Nothing changes there. Your submerged endurance in a single dive would be limited by the O2 (instead of CO2 rising you had O2 in tanks sinking).

As soon as your O2 is used up, it's either surface or game-over. In real life the CO2 should have stayed constant at approx. 1.5-2% until your O2 was used up. Then you had to surface. There was nothing really interesting in the CO2 dial. If it did not stay constant after 3-4h you had a problem.

Cheers, LGN1

LGN1

01-30-11, 12:27 PM

@LGN1:

True, but not when attacking convoys, for obvious reasons - you really don't want your submarine to pop out of the water from periscope depth. There are numerous accounts of U-boats slowing filling up with water while silent-running at deep depths. And then slowly sinking, because the trim was altered.

Also true, but this is a question of degree/extent. The idea of the mod is to force the player to manage silent-running, and not to have it switched on at all times when in the vicinity of warships. The SR mod is not very effective - you will not sink fast, and only when the underwater speed is around 1 kt. But it forces the player to think about the management of this issue. The old 'Aces of the Deep' U-boat simulation mimicked this very well, but SH3 currently lacks the facility completely.

Stiebler.

Hi Stiebler,

thanks for the reply! I am just wondering whether in real life it had not been just a matter of blowing a tank (making noise) for just a few seconds to correct the issue :hmmm:

LGN1

Sailor Steve

01-30-11, 01:56 PM

thanks for the reply! I am just wondering whether in real life it had not been just a matter of blowing a tank (making noise) for just a few seconds to correct the issue :hmmm:
Unfortunately blowing a tank for a few seconds isn't accurate. It not only would make a lot of noise (as you said) but could easily overcorrect and make your boat start rising, and you'd have exactly the same problem.

LGN1

01-30-11, 02:07 PM

Unfortunately blowing a tank for a few seconds isn't accurate. It not only would make a lot of noise (as you said) but could easily overcorrect and make your boat start rising, and you'd have exactly the same problem.

Yes, sure you would overcorrect. However, it's not exactly the same problem afterwards because sinking slowly at 200+x meters is not the same as rising slowly at 200+x meters. I prefer slowly rising at this depth :yep:

NGT

01-30-11, 06:33 PM

I have now placed a patch (StieblerSR1.7z) for SH3.exe, courtesy of H.sie, .........................
.................................................. .............

Feedback welcome - especially from users of GWX, which I do not test, and whose buoyancy model is different from stock SH3 and NYGM.

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

Stiebler.

With GWX the crach dive blue do not exist (any more?).

But I haven't slow sinking, at any depth, with or without silent running, at 1 or 2 knots, all test with Academy patrols.
____________________

I did some trials also:

I placed GWX submarine VIIB (with turms) inside NYGM, only the folder NSS_Uboat7b and the appropriate files from Objects:

Like that, I loose 14 meters per minute in every depth below 20 meters, with silent running or without, at 1 or 2 or 3 knots. After half crash dive or after normal dive.

What is the "target" of slow sinking in meters/minute?

Stiebler

01-31-11, 04:20 AM

@LGN1:

Many thanks for this feedback - it is very useful.

H.sie - please notice!

The SH3 target for slow-sinking is around about 1 metre per 5 minutes (and that is probably too fast for real-life).

Since you are losing 14m/minute both with *and without* silent-running, it is clear that there must be a conflict between a GWX U-boat and NYGM. This is not due to my slow-sinking mod. The problem is probably due to the 'Anti-Humming Bird' mod in NYGM, which expects to find part of a XXI compartment in the type II, VII and IX U-boats. The GWX U-boat naturally lacks this.

What you need to do is to find 'SH3 Mini-Tweaker' and set the 'mass' of your U-boat to '0' in your GWX U-boat .sim file.

If Mini Tweaker is hard to find, then I could place a copy onto the NYGM web-site as a temporary measure.

Stiebler.

Magic1111

01-31-11, 04:42 AM

If Mini Tweaker is hard to find
Stiebler.

Mini Tweaker Download Link: ftp://hartmuthaas.no-ip.org/Volume_1/Sharing/SH3COMMUNITYMODS/TIMETRAVELLER

Best regards,
Magic:salute:

Silent Ace

01-31-11, 05:07 AM

To all who are interested in this topic I recommend that you read the following book-http://hotfile.com/dl/56399975/2b721c4/Submarine_Design_and_Development.pdf.html
Will find answers to many questions and dilemmas that have been set here.

NGT

01-31-11, 12:42 PM

@LGN1:

Many thanks for this feedback - it is very useful.

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

What you need to do is to find 'SH3 Mini-Tweaker' and set the 'mass' of your U-boat to '0' in your GWX U-boat .sim file.

If Mini Tweaker is hard to find, then I could place a copy onto the NYGM web-site as a temporary measure.

Stiebler.

Emm....I suppose you address to me (NGT no LGN1)...:cool:

I set the mass to "0" (with S3D) and inside GWX the U-boot -VIIB- is stable like "rock", no one meter down, silent running or not. (all tests below 20 meters depth)

But with my little trial [GWX VIIB inside NYGM] the boat with mass "0" loose 27 meters per minute now, but only with 1 knot/h. By 2 k/h is stable!

Obviously, you (we) need special version for GWX, with more files that the simple patch for SH3.exe.

I don't do trial with NYGM, I suppose you do that. Personally I am interested to apply new patch to WAC too, if possible.

Best regards.

Stiebler

01-31-11, 03:22 PM

@NGT:

Emm....I suppose you address to me (NGT no LGN1).Sorry about that, NGT. My error.

Yes, I test NYGM. It was a good idea to alter the mass in GWX VIIC with SD3Ditor, I did not think of that.

I believe that WAC's game-play is similar to stock SH3. But perhaps you know better than me.

Stiebler.

Silent Ace

02-01-11, 04:51 AM

One question:
Is it possible to enable manual control of the closure of external doors torpedo tubes which, combined with manual loading torpedoes (disable Auto loading) finally enable compliance with the procedures of the torpedo tubes.
Example if you tried to manually insert a torpedo in the torpedo tube outer doors which are not closed automatically would have had flooding torpedo room.

Myxale

02-01-11, 02:31 PM

It doesn't work this way!

The doors could never accidentally be opened like this. There was a mechanism that prevented the opening of both doors.

Silent Ace

02-01-11, 02:49 PM

One such incident occurred in 1939 on HMS Thetis.

h.sie

02-04-11, 05:06 PM

(Reserved)

h.sie

02-05-11, 05:07 AM

V15E (BETA 1) is out.

Courageous Beta Testers welcome!

What's new?

1) "Crash dive blues" bugfix (by h.sie and Stiebler)

From now on, you don't lose control over the sub anymore if you interrupt a crash dive before the sub has reached its designated crash dive depth. Especially NYGM players will benefit from this fix, since in NYGM the Crash dive blues is more noticable.

2) Fog warning (Idea: Stiebler, Programming: h.sie)

During high time compression (TC) it can happen that suddenly heavy fog occurs, but the player doesn't even notice it and so he won't be able to act according to that new situation. This fix reduces TC>16 to TC=16 whenever fog occurs in order to warn the player.

3) More realistic reload of external/internal torpedoes.

No reload of external torpedoes possible during bad weather (=storm conditions defined in .cfg file of the sub). If bad weather suddenly occurs during external reload, the torpedo will be considered as reloaded if more than 75% of the reloading work is done, otherwise the torpedo will be put back to it's initial position, but the reloading process will be automatically restarted when bad weather ends.

Speed restriction to "slow" during external reload.

No diving possible during reload of external torpedoes, since all diving commands are simply ignored. If an enemy is sighted, the first pressing of the 'C' key (crash dive) is now interpreted by the game as "ALARM, interrupt reloading!!!". From now on, the ingame-clock begins to blink and alternatingly shows a) the remaining time in minutes during which diving still isn't possibe and b) the time of the day as usual. If this countdown reaches zero, the clock stops blinking, what signals that the sub can finally dive now. The time one has to wait until diving is possible is randomly chosen between 4 and 13 minutes.

No reload of internal torpedoes during storm and when surfaced. During storm one has to dive below 30m in order to reload internal torpedoes.

Comment: This solution forces the player to play realistic, instead of allowing him to play unrealistic (dive during external reload) and model some penalty like injured crew or flooded compartments. I chose this simple solution because it's much easier to program, but even this simple solution consists of 9 code patches and took about 6 weeks. I don't want to spend more time for modelling a situation that never happened during WWII, if I'm informed correctly.

SH3.exe Patch Configurator (Announcement)

Stiebler has programmed a comfortable Configurator program that allows the user to individually disable/enable the fixes for sh3.exe, for those users who want some but not all available fixes. This Configurator will be released soon.

h.sie

fitzcarraldo

02-05-11, 06:42 AM

V15E (BETA 1) is out.

Courageous Beta Testers welcome!

Many thanks! Downloading and trying...

Best regards

Fitzcarraldo :salute:

Silent Ace

02-05-11, 07:00 AM

Thank you h.sie for the new version.

reaper7

02-05-11, 07:01 AM

Nice one mate. trying it now :up:.

Magic1111

02-05-11, 07:59 AM

Many thanks h.sie for the new version ! :salute:

I´ll give it a try ! :up:

h.sie

02-05-11, 09:20 AM

Thanks, guys.

I suggest to use the weather transitions test fix in order to analyse the influence of the weather on the torpedoes reloading process. with this fix the weather changes every 30 minutes.

http://www.mediafire.com/?6h7v5xkka645dgl

h.sie

And don't forget to install the Supplement to V15E mod (via jsgme).

NGT

02-05-11, 10:28 AM

Thank you h.sie

You are in SH3.exe for long time now, but, still, I can’t believe what you accomplish.

In fact, it is unbelievable that so important things are solved just now. They come out from “Classified Impossible” to reality, thanks to you.

Congratulation!

One remark: Is not possible to apply the 4 GB patch from Privateer (after your patch). Reason: unknown file.

May I suggest implementing a 4 GB patch, especially with the configurator file from Stiebler?

Thanks again, I go back for testing.

h.sie

02-05-11, 10:42 AM

Hi NGT,

good point, maybe Stiebler is willing to include the 4GB patch into his configurator program. Should not be hard, since it's a single bit somewhere in the exe. easy to locate using fc /b .

In the meantime you could use the 4GB patch I'll upload to my mediafire page in the next minutes.

h.sie

NGT

02-05-11, 11:00 AM

Sorry, I can't apply yours too (always after your patch V15E). But it seems like the one from Privateer.

Please try to do. If you succeed, I do something wrong, obviously....

Best regards.

h.sie

02-05-11, 11:38 AM

@NGT: works for me

NGT

02-05-11, 12:28 PM

I ask myself what can be wrong...

Without V15E, no problem with 4GB patch. After V15E, no way.

I did it 3 times.

However, I found in my archives, another 4GB patch, and it works. It is an older than the one from Privateer.

Thank you for the upload anyway.

WH4K

02-05-11, 12:30 PM

The 4GB patch doesn't even do anything if you're using a 32-bit OS, correct?

Would love to try this mod, although I've been playing SH4 more lately, because it behaves a whole lot better than SH3 (=doesn't crash as much, if at all).

LGN1

02-05-11, 01:02 PM

Hi h.sie,

excellent work :up: Sounds really great! Thanks a lot for your relentless efforts! I'm looking forward to trying it.

Cheers, LGN1

SquareSteelBar

02-05-11, 01:27 PM

There's a universal 4GB patch for x86 executables:

http://www.ntcore.com/4gb_patch.php

makman94

02-05-11, 01:40 PM

aaa GREAT NEWS H.Sie ! :up:

thank you very much for this last version ! :yeah:

question : the ''switces'' are now in line 0x148FE0 (not at 0x148F60 anymore ) right ? if yes....can you please tell what 'switch' is each one of these at the last version ? (becuase i see more ''switces'';)...now)

also, can remind me for what exactly the sh3sim.act file is for in your mod ?

again...a big Bravo to all involved at this effort ! :up:

reaper7

02-05-11, 03:18 PM

There's a universal 4GB patch for x86 executables:

http://www.ntcore.com/4gb_patch.php

This way the one I used. Worked no problem :up:.

h.sie

02-05-11, 04:13 PM

@Makman: Thanks, mate. Shortly, after beta testing period, I'll publish Stieblers fix configurator, which allows you to enable/disable individual fixes by manipulating the according switches. But in short, if you don't want to wait:

0x148FE0: RepairTime_Switch:
0x148FE1: WO_Switch:
0x148FE2: WP_Switch:
0x148FE3: CO2_Switch:
0x148FE4: Snorkel_Switch:
0x148FE5: Peri_Switch:
0x148FE6: Hydrophone_Switch:
0x148FE7: FogWarning_Switch:
0x148FE8: CrashDiveFix_Switch:
0x148FE9: TorpedoReload_Switch:

-----------------------

Sh3Sim.act contains the code responsible for the reload process of the torpedoes. If you remove the patched Sh3Sim.act file, my torpedo reload fix won't work and you'll see stock sh3 behaviour.

h.sie

Magic1111

02-05-11, 07:11 PM

Sh3Sim.act contains the code responsible for the reload process of the torpedoes. If you remove the patched Sh3Sim.act file, my torpedo reload fix won't work and you'll see stock sh3 behaviour.

h.sie

Short question from me: For what exactly was the "CameraBehavior.act" ? Sorry, but I can´t remember....
And do I need this absolutely ? :hmmm:

Best regards,
Magic:salute:

h.sie

02-05-11, 07:48 PM

@Magic: It's for the periscopes blur effect to simulate vibrations for higher speeds

makman94

02-05-11, 10:25 PM

Magic1111

02-06-11, 05:44 AM

@Magic: It's for the periscopes blur effect to simulate vibrations for higher speeds

Aaah, okay ! Thanks h.sie ! :up:

h.sie

02-06-11, 07:51 AM

I am slightly optimistic that in the near future the lazy 1WO will move automatically on the bridge when boat surfaces.

SquareSteelBar

02-06-11, 07:55 AM

:up:

What did you do - did you threaten him with demotion?

Magic1111

02-06-11, 08:00 AM

I am slightly optimistic that the lazy 1WO will move automatically on the bridge when boat surfaces.

WOW :o, I can´t believe that´s eventually possible....!:up:

Best regards,
Magic:salute:

Stiebler

02-06-11, 10:30 AM

H.sie said:
maybe Stiebler is willing to include the 4GB patch into his configurator program. Should not be hard, since it's a single bit somewhere in the exe. easy to locate using fc /b .I've done it.

H.sie has the revised test version.

I have also worked out a complete code solution to the slow-sinking when silent-running problem. (Applies to ALL U-boats and ALL super-mods.) So you cannot just go rushing into a convoy with silent-running on from the moment you see it. It takes some management instead. Especially when you are being depth-charged by three escorts at 200m.

Again, H.sie now has the code. It affects SH3Sim.act.

Stiebler.

LGN1

02-06-11, 02:28 PM

H.sie said:
I have also worked out a complete code solution to the slow-sinking when silent-running problem. (Applies to ALL U-boats and ALL super-mods.) So you cannot just go rushing into a convoy with silent-running on from the moment you see it. It takes some management instead. Especially when you are being depth-charged by three escorts at 200m.

Stiebler.

Hi Stiebler,

I have no idea about this, but wouldn't be the problem of slowly sinking easily solved in real-life by trimming the boat upwards? I understand that you don't want to do this close to the surface, but as soon as you are a few meters deeper? I would guess that re-trimming the boat just took a few seconds :hmmm:

Anyway, you mentioned that there are numerous accounts of this problem. Do you know why back then the boat was not re-trimmed?

Cheers, LGN1

Stiebler

02-06-11, 03:03 PM

@LGN1:

you mentioned that there are numerous accounts of this problem. Do you know why back then the boat was not re-trimmed?

Too much noise, if close to the enemy. (Water has to be pumped in and out of tanks, or compressed air has to be used to expel water.)
Also, when in the presence of the enemy, you need to be able to dive fast, which is not aided if you are trimmed up.
You can also control depth with the hydroplanes, but they require sufficient forward speed, depending on buoyancy.

Herbert Werner reported, in his well known book 'Iron Coffins', that his U-boat was trimmed up when it reached deep depth, but the depth was too deep to pump out bilge water caused by slow leaks, which resulted in a slow sinking anyway.

That was why I proposed originally that this slow-sinking problem should be mimicked by resetting the mass of the U-boat slowly upwards, when silent-running. Unfortunately, both H.sie and I found that the SH3 model ignores this simple solution.

Stiebler.

LGN1

02-06-11, 04:33 PM

Hi Stiebler,

thanks for the reply! After thinking more about it, I realize that there is one thing I did not consider: the water pressure at great depth might be just too high to pump any water out :hmmm: IIRC, in the original U-Boot handbook it's written at which depths the pumps are still working. I have to check it.

So, when you dive deeper, the pressure compresses the boat, you loose buoyancy, then you start to sink, and because of the high pressure you cannot compensate this by trimming. Sounds reasonable.

Cheers, LGN1

Tessa

02-06-11, 07:46 PM

hi h.sie

Have noticed an unusual bug/feature since using your mod (now that I've had some decent amoung of time playing with the mod itself active), it seems (ime) to produce extremely unstable savegames - but only if you exit the game; conversely as long as you don't exit it produces rock solid saves under circumstance that would normally ctd.

As I play SH3 on my laptop if I find myself in a position where I need to leave or go to bed (when I'm not going to on my machine for 12+ hours and have a game still in progress I usually turn it off; rather than letting it sit there taxing the cpu and cooling fans needlessly) and exit the game to turn my laptop off. When I go back to play the game and try to resume via my last save 95% of the time the savegame gets corrupted even if I'm in the middle of the Atlantic, 100's of miles from any ship, plane or piece of land. Usual result is having to start the entire patrol over :down:

On the other hand, as long as I have the game on and running the saves that are produced can successfully save in condition that would almost always result in a ctd. Several times I've had to temporarily suspend my game for a few hours and say I'm in the middle of a convoy attack, am submerged and in firing position. I save the game and exit, but still leave SH3 running. When I come back my save works much to my surprise as saving a game while underwater tradtionally has always resulted in a ctd, made even worse with the close proximity to other ships. Normally that would instantly ctd, instead I've been able to resume saves inside harbors, in convoy attacks, inside the convoy lanes, under other ships or even when being actively hunted!

When I exit the game itself (so I can shut my laptop down) no matter where my last save was under any conditions they fail. While the ability to finally save your game in virtually any situation is a miracle in itself, it seems isolated to only while you have SH3 running. Have you/anyone else had problems (same, similar or something different) with loading saved games?