[TEC] SH5.exe patches to fix bugs and add functionality

[THE_MASK]

Now let me get this exactly right for you . Heres what happens .
My mod list is enabled with the mod enabler .
Patch with the latest patcher .
enable all the patches .
Check patcher by opening it again and can open ok.
Disable all mods in mod enabler .
Enable the Independent_Engine_Controls_Testing mod.
Open the patcher and i get the error "error reading patches"
Copy over the patches to the sh5 game folder again.
Open the patcher and the patcher now opens.

I just cannot fathom what the mod enabler or mods have to do with anything regarding the patcher ?

I just tried the engine controls again and i cannot get it to work .
All True on both sh5 and sim patch .

[TheDarkWraith]

Now let me get this exactly right for you . Heres what happens .
My mod list is enabled with the mod enabler .
Patch with the latest patcher .
enable all the patches .
Check patcher by opening it again and can open ok.
Disable all mods in mod enabler .
Enable the Independent_Engine_Controls_Testing mod.
Open the patcher and i get the error "error reading patches"
Copy over the patches to the sh5 game folder again.
Open the patcher and the patcher now opens.

I just cannot fathom what the mod enabler or mods have to do with anything regarding the patcher ?

I just tried the engine controls again and i cannot get it to work .
All True on both sh5 and sim patch .

Try this: use clean, umodified (i.e. stock) files for SH5.exe, SHSim.act, and SHCollisions.act. Make a mod of them. Patch for the independent engine controls and point it to the mod you just made for the files. Enable the mod. Test.

[Topo65]

You didn't disable all patches with old patcher first :yep: Then you can reenable with new version

Thanks, TDW! I forgot that! :damn: Fixed now! :up:

[TheDarkWraith]

@Sober - did you enable the Independent_Engine_Controls_Testing mod? You have to enable that mod for the single mission and it has the Page Default Hud.py file needed for the commands.

[THE_MASK]

@Sober - did you enable the Independent_Engine_Controls_Testing mod? You have to enable that mod for the single mission and it has the Page Default Hud.py file needed for the commands.Yes , just reinstalling the game now , give me an hour or so .

[TheDarkWraith]

Has anyone been able to use the independent engine controls patch with the single mission successfully besides me :06:

[Topo65]

Yes! I tested! Working ok for me! :salute:

[TheDarkWraith]

Yes! I tested! Working ok for me! :salute:

Good to know. Please try and break it :yep: Try and make it do something it's not supposed to (like change engine speed on engine recharging batteries). I want to ensure it's solid before moving on with it :up:

[THE_MASK]

Try this: use clean, umodified (i.e. stock) files for SH5.exe, SHSim.act, and SHCollisions.act. Make a mod of them. Patch for the independent engine controls and point it to the mod you just made for the files. Enable the mod. Test.Its working now .

[THE_MASK]

when i press u to disable the port prop and then hit 1 for ahead slow . The sub goes to ahead slow and the starboard prop spins but a message comes up in the message box saying cannot comply . The speed indicator arrow stays on the all stop position . I cannot stop the prop by hitting the all stop . I have to then hit the 1 for ahead slow to start both props then i can stop by pressing all stop . Disabling the starboard prop seems to work as intended .

[TheDarkWraith]

sometimes i press u to disable the port prop and then hit 1 for ahead slow . The sub goes to ahead slow and the starboard prop spins but a message comes up in the message box saying cannot comply . The speed indicator arrow stays on the all stop position . I cannot stop the prop by hitting the all stop . I have to then hit the 1 for ahead slow to start both props then i can stop by pressing all stop . Disabling the starboard prop seems to work as intended .

Yes this is one thing I have noticed. The starboard prop seems to be the master in the game. It seems to be the one tied to the dial used in game for denoting engine speed (as you've seen from the port prop when you had it only enabled and you selected speed for it and the position indicator didn't move). I'm trying to track down where this 'Cannot comply' message comes from and how/why it's being generated.

I always see the port engine used for battery recharging also. Never seen the starboard one used for it. Has anyone seen the starboard engine being used for battery recharging?

[Magic1111]

Hi Folks!

Can somebody please upload for me an older version from the Patcher Tool (e.g. one of the above versions), please as .zip Version! :)

Background is, I´ve changed the MapColors (Patches >> MapColors >> Change 1-15) to my own taste. But now I can´t remember which color-values I´ve set...:oops:

And with the actual Patcher-Tool I can´t open the older patched .exe to look into it...!

Therefore I need an older version of the tool that I can open the older patched .exe to look into it and notice me the 15 color-values I´ve set!

Thx for help in advance,
Magic:salute:

**BUMP** :oops:

Anyone? :hmmm:

[volodya61]

Anyone? :hmmm:

The older version (v1.0.42) is included in the NewUIs mod..
Upload it for you??

[THE_MASK]

I think from now on i will treat the installing /uninstalling of the generic patcher as patch 1.2 . In other words i will install/uninstall the patches with no mods installed with the jsgme . Then after the patches are installed , then i will install mods with the jsgme .

[Magic1111]

Upload it for you??

Yes, please...!!! :woot:

And as an .zip File please!

[Magic1111]

EDIT: :hmmm: 7z... reupload??

Yes please, I need as an .zip File, because I´m not at my Home-PC at a while and on this PC I don´t have the 7-z Program installed!

I can only .zip File open (with own Program from Win XP)!

Can you please reupload as an .zip File?:hmmm:

[volodya61]

It's not a problem - http://www.mediafire.com/download.php?ws7t8sn55i2xnyb

Have a nice day
Volodya

[Magic1111]

It's not a problem - http://www.mediafire.com/download.php?ws7t8sn55i2xnyb

Have a nice day
Volodya

Many thx mate, wonderful! :up:

[Deke]

Thanks :up:

[TheBeast]

I always see the port engine used for battery recharging also. Never seen the starboard one used for it. Has anyone seen the starboard engine being used for battery recharging?
In the submarine SIM file there is a setting for "unit_Submarine" - "Ballast" - "is_DieselElectric" (Yes/No). Currently this is set to "No" so only one screw turns when recharging battery. If set to "Yes" then both screw turn when recharging battery.

Does this setting have any effect on this new patch?:06:

[TheDarkWraith]

In the submarine SIM file there is a setting for "unit_Submarine" - "Ballast" - "is_DieselElectric" (Yes/No). Currently this is set to "No" so only one screw turns when recharging battery. If set to "Yes" then both screw turn when recharging battery.

Does this setting have any effect on this new patch?:06:

You know how many months I've been trying to figure out what that entry in the SIM file means/does? WAY too many. Now I know :D

This will probably affect the new patch if set to Yes. Here's why I think this: the game does a check for something set to 0 before updating each shaft's throttle setting. I haven't been able to pin point what this check is actually checking for yet but I suspect it's checking to see if battery recharging is active on that shaft. If the value is not 0 (it's 1) then it skips over updating that shaft's throttle setting. So if what I think is true then if the SIM file entry was set to Yes you'd never be able to set a new throttle setting because both engines would be used for recharging batteries.

Actually you should test this. Set that SIM file entry to Yes. Start game. Submerge sub. Set throttle to 2 and TC up. Drain batteries some. Surface the boat. Go to external cam. Ensure battery recharging active. Try to select new throttle setting and see what happens :hmmm:

[TheDarkWraith]

I was just in a debugging session with ole trusty OllyDebug and I figured out why when you select a speed vice a throttle it overrides my independent engine controls patch. It's not because the game is doing something wacky or anything - it's actually because of what I do in the patch. Now I have to revise the patch :shifty:

[TheDarkWraith]

fixed the problem with the independent engine controls and selecting a new speed (vice throttle). Revised patch coming soon :up:

[Kalleblom]

:salute: TDW, I follow your work for a while and unfortunately can only say, I am speechless and infinitely enthusiastic!

the most honorable thing is that it apparently is not your work, but your hobby, or let us say your passion!

[TheDarkWraith]

the most honorable thing is that it apparently is not your work, but your hobby, or let us say your passion!

It's a very fun hobby at that! I enjoy puzzles and taking a piece of software and breaking it down and figuring out what everything does is nothing but one gigantic puzzle :D I think I like exploiting things the most - especially when it comes to software. Making a piece of software do something it was never intended to do is very gratifying :yep:

The revised patch also fixes the ordering speed from keyboard (keys 1,2,3, etc.) :rock:

[TheDarkWraith]

v1.0.66.0 released. See post #1

Revised the independent engine controls patch. The bug of selecting new speed (not throttle) overriding the patch and selecting new throttle from keyboard (1,2,3, etc.) overriding the patch has been fixed

:|\\


Work begins on my next mega-patch.....:cool:

[THE_MASK]

Just on a side note , is it worth having the blue and red icons for the options editor ?

[TheDarkWraith]

Just on a side note , is it worth having the blue and red icons for the options editor ?

Not following you :06:

[THE_MASK]

In the latest patcher 1.0.66 . Do i need to enable the Independent_Engine_Controls_Testing that is in the MODS folder ?

[TheDarkWraith]

In the latest patcher 1.0.66 . Do i need to enable the Independent_Engine_Controls_Testing that is in the MODS folder ?

Only if you want to test the patch without using my UIs mod :up:

[THE_MASK]

If i want to disable the patch to apply a new one . Say no crew spotting for example where there are 4 sub sections (4 x +) if i disable the first 3 and accidenatally miss the last one it turns to a disabled icon after disabling the first one . Would it be possible when disabling for the blue tick to not turn red unless all the sub ticks are disabled .

[TheDarkWraith]

If i want to disable the patch to apply a new one . Say no crew spotting for example where there are 4 sub sections (4 x +) if i disable the first 3 and accidenatally miss the last one it turns to a disabled icon after disabling the first one . Would it be possible when disabling for the blue tick to not turn red unless all the sub ticks are disabled .

You bring up a good point but not the point I would recommend. I see where you are coming from and I agree it's not the best implementation. If everything is disabled then it should show the disabled icon, if everything is enabled then it should show the enabled icon, if one or more of the changes are disabled then the icon should be something else...I know, a caution sign! (exclamation point in yellow triangle) I'll make the change :up:

[flostt]

...a raw diamond starting to get polished....:up:

[TheDarkWraith]

actually I found the perfect icon for not all changes of the patch enabled: a bomb icon (black ball with a lighted fuse out the top of it). It's perfect because it says what will happen: ticking time bomb just waiting to go off (CTD!) :D

[Mikemike47]

If i want to disable the patch to apply a new one . Say no crew spotting for example where there are 4 sub sections (4 x +) if i disable the first 3 and accidentally miss the last one it turns to a disabled icon after disabling the first one . Would it be possible when disabling for the blue tick to not turn red unless all the sub ticks are disabled .

You bring up a good point but not the point I would recommend. I see where you are coming from and I agree it's not the best implementation. If everything is disabled then it should show the disabled icon, if everything is enabled then it should show the enabled icon, if one or more of the changes are disabled then the icon should be something else...I know, a caution sign! (exclamation point in yellow triangle) I'll make the change :up:

actually I found the perfect icon for not all changes of the patch enabled: a bomb icon (black ball with a lighted fuse out the top of it). It's perfect because it says what will happen: ticking time bomb just waiting to go off (CTD!) :D

Great idea, sober. Great icon, the bomb, TDW.

[TheDarkWraith]

Great idea, sober. Great icon, the bomb, TDW.

Yes the bomb is most appropriate. But the only time you'll see it is when:
- the patch specifies that all changes are required to be enabled and
- you don't have all enabled

If the patch doesn't require all changes to be enabled and:
- there is only one change and:
-- it's not enabled then you'll see the red dash icon
-- it is enabled then the icon will be the blue check mark
- there is more than one change and:
-- not all changes enabled then the icon will be an exclamation point in a yellow triangle (caution)
-- all changes enabled then the icon is the blue check mark

[TheDarkWraith]

v1.0.67.0 released. See post #1

This version adds the new icons for when not all changes of a patch are enabled. It also adds a new entry to each patch: AllChangesRequired

:|\\

[9thinfSword]

So the independent engine controls patch it's not yet ready to be used in campaign mission I understand it? only with mods disabled and in a singleplayer mission for testing cause it dosen't work for me starting a new campaign or I'm I missing something:06:

[volodya61]

So the independent engine controls patch it's not yet ready to be used in campaign mission I understand it? only with mods disabled and in a singleplayer mission for testing cause it dosen't work for me starting a new campaign or I'm I missing something:06:

I think you're missing new NewUIs 7.2.0 test version..

[TheDarkWraith]

So the independent engine controls patch it's not yet ready to be used in campaign mission I understand it? only with mods disabled and in a singleplayer mission for testing cause it dosen't work for me starting a new campaign or I'm I missing something:06:

I think you're missing new NewUIs 7.2.0 test version..

Once you apply the independent engines control patch you are ready to use it. Now you just need something that lets you use it - currently only my UIs mod v7.2.0 Test lets you use it :up:

[9thinfSword]

Once you apply the independent engines control patch you are ready to use it. Now you just need something that lets you use it - currently only my UIs mod v7.2.0 Test lets you use it :up:
Thanks got it

[Dogfish40]

Only if you want to test the patch without using my UIs mod :up:

Hi TDW
I had been away a couple days when you updated the patcher. I've been trying to catchup here, just a quick question that's been asked before.
I would prefer to just enable everything in the new patcher without testing, is this OK? Do I still need to disable any mods?
D40:hmm2:

[TheDarkWraith]

Hi TDW
I had been away a couple days when you updated the patcher. I've been trying to catchup here, just a quick question that's been asked before.
I would prefer to just enable everything in the new patcher without testing, is this OK? Do I still need to disable any mods?
D40:hmm2:

Perfectly fine :up: I don't see why you would need to disable any mods.

[Dogfish40]

Ok. I've finally got everything in order. Game comes up fine.
All patches enabled. UI has all the new buttons. If I change speeds I CTD.
This is with both the keyboard and the UI speed buttons.
What have I done bad here?? :o
D40

[TheDarkWraith]

Ok. I've finally got everything in order. Game comes up fine.
All patches enabled. UI has all the new buttons. If I change speeds I CTD.
This is with both the keyboard and the UI speed buttons.
What have I done bad here?? :o
D40

Did you enable both patches (SH5 and SHSim) for the new independent speed controls?

[Dogfish40]

Did you enable both patches (SH5 and SHSim) for the new independent speed controls?

I've just double checked and I have enabled all patches. Is being at base required?

[TheDarkWraith]

I've just double checked and I have enabled all patches. Is being at base required?

shouldn't matter one bit. This patch is a change to the way the exe and act files work, it doesn't change anything related to any files used by the game.

Anyone else having this problem or is everything working as it should :06:

[THE_MASK]

shouldn't matter one bit. This patch is a change to the way the exe and act files work, it doesn't change anything related to any files used by the game.

Anyone else having this problem or is everything working as it should :06:I enabled the UI 7.2 and the options editor and applied the patch . I cannot get only i prop to turn . Any suggestions sir .

[Dogfish40]

shouldn't matter one bit. This patch is a change to the way the exe and act files work, it doesn't change anything related to any files used by the game.

Anyone else having this problem or is everything working as it should :06:

For the same reasons plus some, it shouldn't make any differance what order I load the patches and UI or,...no differance if I take out all mods before loading the patches, confirm? (except of course the UI itself to make the changes:D)
I'm also sure that I disabled the old patcher correctly as I double checked.
Again, for the reason you listed above, there sould be no problem with any mods either correct?:ping:
D40
PS: I had enabled the "Hotkey for updating the game with current independant engine control settings" in the new UI, could this have any thing to do with this problem?

[Kalleblom]

Moin,

I have a Question, which effect the independent motor control has on the course of the game?

So what advantage or improvement you have in?

[TheBeast]

Moin,

I have a Question, which effect the independent motor control has on the course of the game?

So what advantage or improvement you have in?

With independant engine control you can turn much faster.

i.e. Rudder 35 degree to port, Port engine back 1/3, Starboard Engine ahead 2/3. This would be good manuver to help avoid depth charges dropped in front of you.

[gap]

With independant engine control you can turn much faster.

i.e. Rudder 35 degree to port, Port engine back 1/3, Starboard Engine ahead 2/3. This would be good manuver to help avoid depth charges dropped in front of you.

yes but...



engine control is possible and built into the game. The physics aren't modeled correctly though. I set one shaft to 0.1 (ahead slow) and the other shaft to ahead flank (1.0) and I expected to see the sub turn due to the different torques exerted on the sub by the shafts but alas that did not happen :shifty: I even tried setting one of the shafts to back emergency with the other at ahead flank and the sub didn't turn (it did slow down some though so at least that is partially modeled) :shifty:

[TheBeast]

Seeing that the independent engines control physics are not modeled correctly.
Once testing is complete, shouldn't this patch be removed until it works correctly?:06:

This would prevent much confusion/frustration.

[gap]

Seeing that the independent engines control physics are not modeled correctly.
Once testing is complete, shouldn't this patch be removed until it works correctly?:06:

This would prevent much confusion/frustration.

under sim file:

unit_Submarine > unit_Ship > Rudders > prop_fact

It is tagged as "Propulsion (propeller) influence factor". Has anyone ever played with this parameter? It migh affect propulsion on high rudder deg or well affect steering on different propellers speed... :hmmm:

[Dax]

Sorry i can't find AI_Crew_Damage_Control_Revised_Zones_cfg_Based_On_ FX_Update_By_TheDarkWraith mod. Can anyone give me the link?

TY

[gap]

Sorry i can't find AI_Crew_Damage_Control_Revised_Zones_cfg_Based_On_ FX_Update_By_TheDarkWraith mod. Can anyone give me the link?

TY


Within TDW's patcher pack ;)

[Dax]

TY!!

[TheDarkWraith]

Still looking for some feedback from anyone that has gotton the independent engine controls to work with my UIs mod besides myself :hmmm:

The next patch is going to be huge, you all won't believe it :huh: I for one, can hardly believe it works as I have it currently :rock:

Just to give you an idea of the size of it (the upcoming patch) it's currently at 832 bytes and still growing :dead: It'll probably max out at around 1000-1200 bytes. All my other patches each have been max around 200 bytes with the average around 100 bytes.

[BIGREG]

Great TDW :yeah:

But i have don't try the last patcher (i don't founfd the UI 7.2 :06:)

[Trevally.]

Downloading to test now:up:

[Trevally.]

Great TDW :yeah:

But i have don't try the last patcher (i don't founfd the UI 7.2 :06:)

http://www.subsim.com/radioroom/showpost.php?p=1924433&postcount=9229 :up:

[BIGREG]

Merci :03:

[Trevally.]

Working for me - see pics


Both shafts turning
http://img6.imageshack.us/img6/7549/bothshafts.jpg

One shaft set to all stop
http://img152.imageshack.us/img152/7007/1shaft.jpg

Con Dials showing one shaft stopped
http://img191.imageshack.us/img191/5880/dialsz.jpg


Engine Dials - one shaft stopped
http://img339.imageshack.us/img339/1500/enginedials.jpg


:woot::yeah:

[Trevally.]

http://img401.imageshack.us/img401/1046/dials2.jpg

http://img840.imageshack.us/img840/2136/dials.jpg

http://img198.imageshack.us/img198/9151/speedwi.jpg

http://img850.imageshack.us/img850/2892/speed2fo.jpg

[Tonci87]

Now if we could make the boat turn, or turn faster, when only one shaft is working...

[Dogfish40]

I have another issue here.:o I disabled all of the independant engine control patches just to make sure everything else is OK (which it is by the way), however, I when I booted the save file everything seemed normal. Then I found that my port prop is not turning.:shifty: This is with the patch disabled. I will go back to the UI and disable the hotkey as I left just the Update Hotkey set to true. I left the " Do you have Independant Engine Control enabled" set to false of course.
I have no reason why the prop should not be turning if the patch (Both Sim and Patch file) are disabled and the UI controls are set to False.
Thought's? Please?
D40

[Trevally.]

Tested turning rates with one shaft in reverse - no improvement:wah:

Found a bug when my boat get below 100m
http://img4.imageshack.us/img4/9917/errorqut.jpg

Script error stops when you rise above 100m again

[gap]

Nice pictorial reportage, Trevally! :up:

Are engines following the same behaviour as gauges, reducing their rpm or stopping on the same side as the disabled shaft?

[Dogfish40]

OK. So far I was able to fix the problem I was having with the port prop not turning (with the Ind Engine Patch(s) Disabled). I disabled all in the new patcher. Loaded my SH5.exe bacup and reloaded the new patcher and enabled all except for the Ind'Engine Control Patches for now. Loaded the game save and both props are turning. So, whatever the problem is, at least it's not very hard to get back to square. :D
Question::ping:
TDW; In the new UI, there is a setting called "Hotkey for updating the game with current independant engine settings". Say that I only enabled the Hotkey but not the Hotkey Default values, what would that do to the patch or the functions on the HUD commands. Could it cause my CTD?? :hmmm: And...What does this do?
Thanks
D40

[TheBeast]

I have no reason why the prop should not be turning if the patch (Both Sim and Patch file) are disabled and the UI controls are set to False.
Thought's? Please?
D40

If Batteries are recharging, only one (1) screw will turn.

@ Trevally.
I noticed in your screen caps that the Telegraphs do not match engine rpm.
In the CT and Engine Room, the Port Engine RPM gauge was stopped but Port Telegraph show Ahead Standard.

Has this issue been addressed yet?:06:

[Topo65]

Yes. Below 100 meters, suddenly the engine telegraph shown inverted. :yep: 1/3 ahead was 1/3 back.

[Dogfish40]

If Batteries are recharging, only one (1) screw will turn.

@ Trevally.
I noticed in your screen caps that the Telegraphs do not match engine rpm.
In the CT and Engine Room, the Port Engine RPM gauge was stopped but Port Telegraph show Ahead Standard.

Has this issue been addressed yet?:06:


Thanks for that. I didn't really think about it because I had not submerged for some time. It's possible though that the batterie chrging had started late or something.
I still need to go back and enable the Ind Eng patch and try it again.
Can anyone tell me if I need to enable the "Hotkey for updating the game with current independant engine settings" in the UI? I know this is not the thread but it's connected to this issue. I might have missed one parameter in that. I wonder if it caused my CTD's.
Thanks
D40

[TheDarkWraith]

Can anyone tell me if I need to enable the "Hotkey for updating the game with current independant engine settings" in the UI? I know this is not the thread but it's connected to this issue. I might have missed one parameter in that. I wonder if it caused my CTD's.
Thanks
D40

No you don't. It's actually not needed anymore and will be removed in next version of UIs mod.

[Trevally.]

Nice pictorial reportage, Trevally! :up:

Are engines following the same behaviour as gauges, reducing their rpm or stopping on the same side as the disabled shaft?

No the engine animation kept on going - looks like only the shaft and rev guage is being adjusted

If Batteries are recharging, only one (1) screw will turn.

@ Trevally.
I noticed in your screen caps that the Telegraphs do not match engine rpm.
In the CT and Engine Room, the Port Engine RPM gauge was stopped but Port Telegraph show Ahead Standard.

Has this issue been addressed yet?:06:

Yes - this is not working correctly
Its a pity but hopefully the start of somthing.

So - what does work:06:
The shaft control works
This effects the speed of the boat
Running one shaft made it easier for my to sneak away at 0.1knot (very little noise)
The rev guage works

What does not work yet:06:
Shafts effecting the turn rate of the boat
Telegraph dial
Engine animation

[gap]

What does not work yet:06:
Shafts effecting the turn rate of the boat
Telegraph dial
Engine animation

add to the list the under 100 mt script error tha you have just discovered :03:

[potus]

i did everything i was supposed to do with the generic mod enabler

now i want to use the sh5.exe patcher thingy to adjust the colour of my map tools. and some other stuff off course

i found the sh5exe patcher in the same folder as the generic mod enabler namely the tdc 7 1 0 by the darkwraith folder (and yes i replaced those files with the latest update and yes i disabled everything first when patching the patcher)

then i start up the sh5exe patcher (which is btw V1.0.24.0) found in the same folder as the generic mod enabler
from here the problems start
evertytime i specify the path to silent hunter 5

i get an error saying. c/ubisoft/ sh5 /mods newUIs _tdc7_1_0 by the darkwraith/ data/ applications /sh5exe patcher tdw_sh5_patches.s5p

Where is my problem?

[TheDarkWraith]

then i start up the sh5exe patcher (which is btw V1.0.24.0) found in the same folder as the generic mod enabler
from here the problems start
evertytime i specify the path to silent hunter 5

i get an error saying. c/ubisoft/ sh5 /mods newUIs _tdc7_1_0 by the darkwraith/ data/ applications /sh5exe patcher tdw_sh5_patches.s5p

Where is my problem?

The GenericPatcher is currently at v1.0.67.0. You should download latest version from bottom of post #1 of this thread.

What error are you receiving? Do you have Steam version of the game or DVD version? If Steam version the GenericPatcher (specifically the patch files) do not support Steam version of the game.

[potus]

I have the DVD version not the steam version.
after a disaster in a first attempt modding the game i removed everything and start all over

i got a clean install of sh5 i only played the tutorial mission so far without mods off course then i start preparing the game to be modded :)
i installed the JGSME thingy (i performed steps as directed by sober in his his thread updating to 1.2 also performed steps directed in the posts under his opening post)
I downloaded every mod from sobers list. and install them (placing them in the mods folder)
i also installed the newUIs _tdc7_1_0 by the darkwraith where you can find the generic patcher under applications (BTW WHEN DOING ALL THIS NO MODS ARE ACTIVATED WITH JGSME!)
i also did tinkering here and there i believe on some files as directed by some mods (adding some lines on the menu file etc if i am not mistaken?)

anyway i remove these files with al the needed steps taken (first disabling disabling patches from all 3 files i even followed a freaking movie on youtube how to do this) then i am installing the new generic patcher. which is indeed version 1.0.67.0
So far so good or did i missed something?

there is another file in this folder the sh5 patcher when opening in says sh5patcher v1.0.24.0 by the darkwraith (is this the same thing as the generic patcher? just an older version? ) when i use that and want to open the s5p file and after selecting sh5 path i get the error message saying:
error reading patch file c/ubisoft/ sh5 /mods newUIs _tdc7_1_0 by the darkwraith/ data/ applications /sh5exe patcher tdw_sh5_patches.s5p
(I DO NOT HAVE THIS WHEN USING generic patcher 1.0.67.0 for all 3 files i located the sh5 path succesfull) i am probably confused or/and i am overlooking again something...:/\\!!:/\\!!:/\\!!

basicly my Q is i want to adjust my colors when i draw lines and place markers and such without using that hex editor i read about.. how do i change that? my eyes are tired of looking through the forums on older posts and i don't want to **** up anywhere so i don't have to start all over.



sorry if this has been posted before but day 6 or 7 (i forgot) in modding sh5 is beginning to take its toll :dead:

Knock on wood when i am redy to try everything out

friendly greetz :salute:

[gap]

I have the DVD version not the steam version.
i got a clean install of sh5 i only played the tutorial mission so far without mods off course then i start preparing the game to be modded :)
i installed the JGSME thingy (i performed steps as directed by sober in his his thread updating to 1.2 also performed steps directed in the posts under his opening post)
I downloaded every mod from sobers list. and install them (placing them in the mods folder)
i also installed the newUIs _tdc7_1_0 by the darkwraith where you can find the generic patcher under applications (BTW WHEN DOING ALL THIS NO MODS ARE ACTIVATED WITH JGSME!)

i remove these file with al the needed steps taken (first disabling disabling patches from all 3 files i even followed a freaking movie on youtube how to do this) then i am installing the new generic patcher. which is indeed version 1.0.67.0

there is another file in this folder the sh5 patcher when opening in says sh5patcher v1.0.24.0 by the darkwraith (is this the same thing as the generic patcher? just an older version? ) when i use that and want to open the s5p file and after selecting sh5 path i get the error message saying:
error reading patch file c/ubisoft/ sh5 /mods newUIs _tdc7_1_0 by the darkwraith/ data/ applications /sh5exe patcher tdw_sh5_patches.s5p
(I DO NOT HAVE THIS WHEN USING generic patcher 1.0.67.0 for all 3 files i located the sh5 path succesfull) i am probably confused or/and i am overlooking again something...:/\\!!:/\\!!:/\\!!

basicly my Q is i want to adjust my colors when i draw lines and place markers and such without using that hex editor i read about.. how do i change that? my eyes are tired of looking through the forums on older posts and i don't want to **** up anywhere so i don't have to start all over.



sorry if this has been posted before but day 6 or 7 (i forgot) in modding sh5 is beginning to take its toll :dead:

friendly greetz :salute:

May I suggest you to go through this last tutorial (http://www.subsim.com/radioroom/showthread.php?p=1926563&posted=1#post1926563) for an easy method to use TDW's patches without risking to mess things up every time a new patch is released?

[potus]

May I suggest you to go through this last tutorial (http://www.subsim.com/radioroom/showthread.php?p=1926563&posted=1#post1926563) for an easy method to use TDW's patches without risking to mess things up every time a new patch is released?

:sign_yeah: like i said i watched a video on youtube on how to do, that was the video i watched. i followed all the steps. maybe this makes more sense.this is ith the latest version.
http://i1101.photobucket.com/albums/g421/potus1/Naamloos-1.png

i understand that part i did all that now the colors for the map is that done with this thingy or with that other file in the sh5.exe patcher?
which results in this
http://i1101.photobucket.com/albums/g421/potus1/Naamloos4.png
now i notice in the first screen using the 1.0.67.0 i can acces the colors but when changing them and after checking if every colors is correct i notice they all changed back to the first color...
its probably something stupid that i am missing here :hmmm: like i said modding this game is beginning to take its toll :)

[potus]

oh god i am stupid :/\\!!:/\\!! i think i see what the prob is here

[gap]

oh god i am stupid :/\\!!:/\\!! i think i see what the prob is here

Very easy to get confused when you have to disable/re-enable very often that many patches. If you follow the step by step tutorial that I recommended before, things will be a lot easier and the probability to make mistakes will be close to 0 :yep:

[potus]

Very easy to get confused when you have to disable/re-enable very often that many patches. If you follow the step by step tutorial that I recommended before, things will be a lot easier and the probability to make mistakes will be close to 0 :yep:

my god it is i am struggling with this for a week now :/\\!! i am a complete computer noob when it comes down to all this stuff but i am a persistent person :)

so 1 did the part in the video like i said before so i don't need to do the first tutorial? just go by the video like i did? (btw i did it anyway:O: the first step by step tut. but at step 4 use the patcher: direct it to TDWpatchv1.067 i cant seem to find that directory :hmmm:

[gap]

my god it is i am struggling with this for a week now :/\\!! i am a complete computer noob when it comes down to all this stuff but i am a persistent person :)

so 1 did the part in the video like i said before so i don't need to do the first tutorial? just go by the video like i did? (btw i did it anyway:O: the first step by step tut. but at step 4 use the patcher: direct it to TDWpatchv1.067 i cant seem to find that directory :hmmm:

If you follow the pictorial tutorial and if you backed up the unpatched exe, you won't need to disable any mod. It makes things a lot easier. :up:

Since you just admitted to be a computer noob I suggest you to follow that method, rather than the one explained in the video tutorial :)

[potus]

If you follow the pictorial tutorial and if you backed up the unpatched exe, you won't need to disable any mod. It makes things a lot easier. :up:

Since you just admitted to be a computer noob I suggest you to follow that method, rather than the one explained in the video tutorial :)

oh so you do not have to do them both!? :know:
my god haha i am so sorry about all this :oops:
its kinda overwhelming when you decide to get in al this stuff at first :)

i am more familiar with modding the total war games and warband series some mods there have launchers with updaters and such so you can swith to the "vanilla version" or to the modded version, it makes the noob happy :yep:
would love to see something like that for sh5

[Dogfish40]

Ahoy everyone.
Well, I'm a bit down, I tried the Indy engine patchs again from the ground up and got the same result.
I CTD as soon as I change engine speeds. Weird. So, I left this disabled and I enabled all the other patches and everything seems to work fine.
So, I'm happy that everything else is working great. The engine patch I can for-go for the time being until either it's updated or maybe I can run an de-bugging program with it if some knows how I can do this.
Thanks again TDW and all of you helping out with this. The game is getting too awesome!
D40 :salute:

[Targor Avelany]

Ahoy everyone.
Well, I'm a bit down, I tried the Indy engine patchs again from the ground up and got the same result.
I CTD as soon as I change engine speeds. Weird. So, I left this disabled and I enabled all the other patches and everything seems to work fine.
So, I'm happy that everything else is working great. The engine patch I can for-go for the time being until either it's updated or maybe I can run an de-bugging program with it if some knows how I can do this.
Thanks again TDW and all of you helping out with this. The game is getting too awesome!
D40 :salute:

Go to your SH5 folder >> MODS >> TDWs NewUI >> data >> Applications >> Dbgviewer.exe

You can copy it on your desktop beside sh5 lunch icon.

In the Dbgviewer you can save the result in the end into a file and post it for TDW to pick on.

[Dogstar359]

Hi all just recently got a copy of SH5 :rock:
And seen all the great mods and work by TDW.

I was wondering TDW if it is at all possible to fix the time of day problem.

I'll try to explain for example i have your UI mod on of course and load the mission past the rock. now on the mission settings for example the time is 21:30 now if i change this to say 12:00 sometimes when i load that mission the sun will be up and sometimes it will be pitch dark in the middle of the day.

I'm not sure what is going on there, but as your are fixing things that are broken i am wondering if this has been mentioned before and is on the todo list.

If not no worries i'm not making any orders or anything, its just at little annoying when the time of day is wrong.

Keep Up the great work though :yeah:

[Trevally.]

@TDW

All historical missions I have tested will ctd on loading with the new patcher. Campaign works ok:hmmm:

Remove patcher - historical missions work again:ping:

[TheDarkWraith]

@TDW

All historical missions I have tested will ctd on loading with the new patcher. Campaign works ok:hmmm:

Remove patcher - historical missions work again:ping:

Is there a specific patch that's causing it?

[Trevally.]

Is there a specific patch that's causing it?

I know there was no issue with TDW_GenericPatcher_v_1_0_53_0 - I tested many single missions with that one.

So short of testing each one - would the dbgview report help:06:

[TheDarkWraith]

I know there was no issue with TDW_GenericPatcher_v_1_0_53_0 - I tested many single missions with that one.

So short of testing each one - would the dbgview report help:06:

No, the patches don't export anything to Dbgview.



My next mega-patch is 95% complete. The testing shows the idea works and it works quite well :D There is one thing left to figure out but I'm not going to let that hold it up. Here is what this mega-patch is:

Ability to call in for wolfpacks :rock: When you send in a contact report there is a 10% chance that Bdu might vector other subs to your position. These subs are not subs pulled from the campaign or anything. These are new subs spawned on the fly. The great thing about how I'm spawning these new subs is the function is setup to be generic - that means I can spawn any unit of any nationality anytime I want, any quantity that I want :rock: Let's get into the meat and potatoes of how this is all working:

You send in a contact report. The game checks to see if you are lucky enough to have Bdu consider your contact report. If they consider your contact report then a timer is set that will not allow Bdu to reconsider you for vectoring of subs to your position for 18 hours. Now the game checks to see how many subs Bdu will vector to your position. The max they will send is 3. Since a random number is being generated there is a possibility that 0 units will be sent to your position. Which means no reinforcements for you! If you are lucky enough to have some subs sent to your position then for each sub vectored to your position:
- a timer is set for when the sub will spawn. The max time can be up to 8 hours. A random number is generated (0-1.0) that is multiplied by this 8hrs to get the spawn time. When the spawn timer times out then the new AI sub is spawned on the surface and given two waypoints: the first waypoint is your current position, the second waypoint is it's current position (so it will return to where it came from). A max spawn distance radius of 15km is used to generate the random spawn distance and location in relation to your sub.
- The new AI sub will follow waypoints until it finds a contact. Once it has a contact then it goes into attack mode and does what it's supposed to do.
- if the new AI sub doesn't 'see' any contacts it will follow the first waypoint to it's end then turn around and head back to where it came from and eventually disappear from the game.

By using these random 8hr timers it's quite possible that one sub can show up a couple of hours later and another may show up 5 hours later. It's totally random :D

I said the mega-patch is 95% complete because I haven't figured out how to send the Bdu messages to the player's sub yet. What I do until I figure this out is I put a message in the messagebox saying "Shadow contact/convoy and await reinforcements" - this way you know that Bdu is vectoring subs to your position. If you do not get this message then no subs are being sent to your position.

All these timer variables and random % chances are variables in my patch file. This means one can adjust to the level of realism/their taste wanted (except for the number of subs that can be sent to your position - that is fixed at a max of 3) :yep:

Now note I said the function that I made is generic so that I can spawn any unit of any nationality anytime and in any quantity that I want. I have big plans for carriers/cruisers in the game now :D

I thought about adding a new command to the game ("Request_wolfpack") instead of tying this new idea to the contact reports....what do you all think :06:

[THE_MASK]

Speechless atm .

[TheDarkWraith]

Speechless atm .

Wait till you see it in action in game. Takes this sim to a whole new dimension.

When I code in my ideas for the carriers/cruisers it'll go up another dimension on the realism scale :smug:

I have about 30% of the game decoded now. Almost all the major functions I have figured out along with variable locations. It's been a long journey up to this point :dead:

[THE_MASK]

Playing SH5 is a hobby for a lot of people , keep up the good work sir :up:

[binzy62]

[QUOTE=TheDarkWraith;1927546]Wait till you see it in action in game. Takes this sim to a whole new dimension.

I'm still picking my jaw up :up:

[Rongel]

Been waiting what the new big update was... This sounds too good to be true! Fingers crossed, awesome work TDW! :woot:

I thought about adding a new command to the game ("Request_wolfpack") instead of tying this new idea to the contact reports....what do you all think :06:

I think that the contact report based option is better, because now people send the reports but they don't have any effect when you are out of the friendly air coverage. With this they suddenly have a real meaning!

Ofcourse if you spot just one small coastal ship, there is no point sending contact reports, and asking assistance. So best to use only on convoys.

[Sartoris]

Thank you, TDW! Another great leap forward for SH5 and its community! :woot::yeah:

Personally, I don't think you need to add the command "Request_Wolfpack" if we already have the functioning Report Contact, but that's just my opinion.

Now I'm off to celebrate this new patch in my U-boot's winter garden with the crew and a bottle of wine!:D

[Kalleblom]

My next mega-patch is 95% complete.

I thought about adding a new command to the game ("Request_wolfpack") instead of tying this new idea to the contact reports....what do you all think :06:

:salute:TDW

It is fascinating that you manage adult men feeling like a child waiting for a present:)

:up::yeah::woot:

[volodya61]

...what do you all think :06:
..
It is fascinating that you manage adult men feeling like a child waiting for a present..

I'm totally agree with Kalleblom.. :agree:

It's great, awesome work, sir!

:salute:

[THE_MASK]

So , the enemy can call in reinforcements as well ?

[Trevally.]

Looking forward to this mega patch TDW :Kaleun_Salivating:

[TheDarkWraith]

So , the enemy can call in reinforcements as well ?

They've had this ability to call in reinforcements since the stock game. What they don't have is what I plan on adding to the carriers and cruisers: the ability to launch airplanes :cool:

[TheDarkWraith]

Of course if you spot just one small coastal ship, there is no point sending contact reports, and asking assistance. So best to use only on convoys.

If you send in a contact report on a single unit the game (patch) will still roll the dice on whether Bdu sends reinforcements or not so use the send contact report wisely :yep: I can't (currently) tell whether the contact report you send in is for a single unit, multiple units, or a convoy. And I highly doubt I'll ever be able to make this distinction because of how the contact report function is coded. So once again, when you enable this upcoming patch use the send contact report accordingly :up:

[volodya61]

Hi TDW!

There is an issue when using the AI Crew Damage Control patch..
The destroyed ships don't sink now..
Damage Control patch continues to work after the ship's destruction..
I'm afraid I won't be able to explain it correctly.. just look at the screens.. at the flooding bar and time..

http://s19.postimage.org/e8fuv6qrj/SH5_Img_2012_08_29_17_43_31.jpg (http://postimage.org/image/e8fuv6qrj/) http://s19.postimage.org/ytumn38cf/SH5_Img_2012_08_29_17_44_05.jpg (http://postimage.org/image/ytumn38cf/) http://s19.postimage.org/d8pjzhblr/SH5_Img_2012_08_29_17_44_42.jpg (http://postimage.org/image/d8pjzhblr/) http://s19.postimage.org/gtlfipg5b/SH5_Img_2012_08_29_17_44_57.jpg (http://postimage.org/image/gtlfipg5b/) http://s19.postimage.org/fsl6tkz5r/SH5_Img_2012_08_29_17_46_21.jpg (http://postimage.org/image/fsl6tkz5r/)

And next morning.. the destroyed ship is steel there.. only via save/load I can get rid it..

http://s19.postimage.org/s8hwnbshr/SH5_Img_2012_08_29_17_49_11.jpg (http://postimage.org/image/s8hwnbshr/)

Could you check this before the release of the your new mega-patch?

PS: AI Crew Damage Control Sink based on FXUpdate is enabled
It happens with all ship models.. .dat and .GR2..

[TheDarkWraith]

Hi TDW!

There is an issue when using the AI Crew Damage Control patch..
The destroyed ships don't sink now..
Damage Control patch continues to work after the ship's destruction..
I'm afraid I won't be able to explain it correctly.. just look at the screens.. at the flooding bar and time..

And next morning.. the destroyed ship is steel there.. only via save/load I can get rid it..

Could you check this before the release of the your new mega-patch?

PS: AI Crew Damage Control Sink based on FXUpdate is enabled
It happens with all ship models.. .dat and .GR2..

That was one determined crew trying to keep their ship alive! It is possible that this could happen with the AI crew damage control patch. For one, it shows that the patch is doing what it's supposed to do :D What I need to do is find the bit that is set (or cleared?) when the game says the unit is destroyed. Then I can check this bit and if game says unit is destroyed then disable the AI crew damage control patch on that unit :yep:

[volodya61]

That was one determined crew trying to keep their ship alive!
Crew already had left the ship in lifeboats.. :O: :D

..What I need to do is find the bit that is set (or cleared?) when the game says the unit is destroyed. Then I can check this bit and if game says unit is destroyed then disable the AI crew damage control patch on that unit :yep:

OK.. Thanks
Only you will be able to find it.. We will wait..

[Kalleblom]

What I need to do is find the bit that is set (or cleared?) when the game says the unit is destroyed. Then I can check this bit and if game says unit is destroyed then disable the AI crew damage control patch on that unit :yep:

Isn´t there the destroyedship icon for the related ship on the screens:06:

There might be coupling, so the system said it´s destroyed and the TAI displayed the icon:06:

Only some thoughts, i actually have no knowledge about computer language.:oops:

[gap]

My next mega-patch is 95% complete. The testing shows the idea works and it works quite well :D There is one thing left to figure out but I'm not going to let that hold it up. Here is what this mega-patch is:

Ability to call in for wolfpacks :rock: When you send in a contact report there is a 10% chance that Bdu might vector other subs to your position. These subs are not subs pulled from the campaign or anything. These are new subs spawned on the fly. The great thing about how I'm spawning these new subs is the function is setup to be generic - that means I can spawn any unit of any nationality anytime I want, any quantity that I want :rock:

Good one TDW :yeah:

I have two questions:

- can you set this new patch to be only effective within a given range of dates? It should be only active a few weeks after the fall of France. Look here for the reason of my request: http://www.uboataces.com/tactics-wolfpack.shtml ;)
The best would be if you can set players free to opt for their favourite starting and end dates, when enabling the patch, as you did for control damage settings.

- from vanilla, sending any radio report/request should have a given probability connected with it that our message gets intercepted by nearby enemy units. As far as you know, is this working? If not, can you use this patch for addressing the problem (if any)?




I thought about adding a new command to the game ("Request_wolfpack") instead of tying this new idea to the contact reports....what do you all think :06:
I think that the contact report based option is better, because now people send the reports but they don't have any effect when you are out of the friendly air coverage. With this they suddenly have a real meaning!

Ofcourse if you spot just one small coastal ship, there is no point sending contact reports, and asking assistance. So best to use only on convoys.

I agree with Rongel

[TheDarkWraith]

Isn´t there the destroyedship icon for the related ship on the screens:06:

There might be coupling, so the system said it´s destroyed and the TAI displayed the icon:06:

Only some thoughts, i actually have no knowledge about computer language.:oops:

Yes that's my exact thinking. I know where the function resides in the exe that's called when a destroyed mark needs to be added to the map. I'll just set a breakpoint there and when it's called run up the stack chain to see who called it and hopefully somewhere in that stack chain I'll see where the game is setting (or clearing) the bit responsible for unit destroyed :yep:

[Targor Avelany]

Crew already had left the ship in lifeboats.. :O: :D



OK.. Thanks
Only you will be able to find it.. We will wait..


yeah, I've seen that happen when I had to sink a merchant with my deck gun.. And then I watched it... for a long time. Eventually the game de-spawned the dead burning unit. Though, maybe, I was just too far away already (the sub itselft)

[Targor Avelany]

..
- from vanilla, sending any radio report/request should have a given probability connected with it that our message gets intercepted by nearby enemy units. As far as you know, is this working? If not, can you use this patch for addressing the problem (if any)?

well, even if they do get to interccept the message, Enigma knows its job. At least at the start of the war. :smug:

[TheDarkWraith]

Good one TDW :yeah:

I have two questions:

- can you set this new patch to be only effective within a given range of dates? It should be only active a few weeks after the fall of France. Look here for the reason of my request: http://www.uboataces.com/tactics-wolfpack.shtml ;)
The best would be if you can set players free to opt for their favourite starting and end dates, when enabling the patch, as you did for control damage settings.

- from vanilla, sending any radio report/request should have a given probability connected with it that our message gets intercepted by nearby enemy units. As far as you know, is this working? If not, can you use this patch for addressing the problem (if any)?

Maybe a later time when I discover the function call that gets the game's current date/time I'll be able to add something like you mention. If I can find the function call it's just a simple matter of adding code to compare the dates.

As I said the new function I made to spawn units can spawn any unit, of any nationality, of any quantity, at any time (and theoretically at any depth - though I have not tested this part of it yet). So I could 'roll the dice' and see if your contact report gets intercepted by anything and if so spawn a ship or airplane (or even an enemy sub!) But then you get into the tricky details of what to spawn? Ship, airplane, or sub? I (currently) have no way to tell how far any enemy airbase or naval base is from your current position :hmmm:

[gap]

Maybe a later time when I discover the function call that gets the game's current date/time I'll be able to add something like you mention. If I can find the function call it's just a simple matter of adding code to compare the dates.

Okay,
I think it is something we can live with, provided that in the meanwhile we are free to enable/disable the patch whenever we want during campaign...

As I said the new function I made to spawn units can spawn any unit, of any nationality, of any quantity, at any time (and theoretically at any depth - though I have not tested this part of it yet). So I could 'roll the dice' and see if your contact report gets intercepted by anything and if so spawn a ship or airplane (or even an enemy sub!) But then you get into the tricky details of what to spawn? Ship, airplane, or sub? I (currently) have no way to tell how far any enemy airbase or naval base is from your current position :hmmm:

Yes, this is a drawback that I thought about. I suppose tha being harassed by a spawned enemy aircraft due to a radio message sent from the mid Atlantic gap area, wouldn't be very gratifying experience :-?

[BIGREG]

Hi TDW :salute:

You have not seen anything on the status day/night :06:
The only controller that has a variable day/night,is the LightHallo (SHcontrollers)
which gives me a hallo light (white), but attached to the bone (and not on objects) :-?
If you could having a look... that will be really cool :yep:

Ps: or if you find the "timer" ? that to see, does not work on the normal time (i have a lag after 24hours)
otherwise I can try to create bones for each lightbulbs, and use the light hallo :hmmm:

Thank in advance

[volodya61]

@ TDW

The fifth day after destruction..

http://s19.postimage.org/xnqmoak1r/SH5_Img_2012_08_29_22_16_17.jpg (http://postimage.org/image/xnqmoak1r/)

Two days later

http://s19.postimage.org/ou4bkxmgv/SH5_Img_2012_08_29_22_35_40.jpg (http://postimage.org/image/ou4bkxmgv/)

Looking forward to your fix http://www.sukhoi.ru/forum/images/smilies/help.gif

:salute:

[Sartoris]

I hope that gets fixed soon.:up:

[Segwin]

Wait till you see it in action in game. Takes this sim to a whole new dimension.

When I code in my ideas for the carriers/cruisers it'll go up another dimension on the realism scale :smug:

I have about 30% of the game decoded now. Almost all the major functions I have figured out along with variable locations. It's been a long journey up to this point :dead:

Thanks for all the time and effort :salute:

[Magic1111]

Hi TDW!

There is an issue when using the AI Crew Damage Control patch..
The destroyed ships don't sink now..

...


Yes, I noticed the same yesterday!

I think that has to do with the zones.cfg that comes with the Fix (AI_Crew_Damage_Control_Revised_Zones_cfg_Based_On _FX_Update_By_TheDarkWraith), or?! :hmmm:

Because IIRC the sinking times is setting in the zones.cfg.

Can this problem eventually solved when we used the zones.cfg from "AI_Crew_Damage_Control_Testing_Increased_Flooding_ Via_Zones_cfg_file"? :hmmm:

Best regards,
Magic

[TheDarkWraith]

v1.0.68.0 released. See post #1

This new version adds my new mega-patch Contact report wolfpacks. Here's how it works:

When you send in a contact report there is a 10% chance that Bdu will vector subs to your position. After sending in the contact report there can be up to a 1 hr delay before Bdu responds back. If they respond back within an hour you will get a message in your messagebox saying 'Shadow contact/convoy while awaiting reinforcements' (I plan on changing this once I learn how to spawn the official radio messages).

If Bdu responded back saying to shadow contact/convoy then they are sending up to a max of 4 subs to your position. Each sub can take up to 8 hrs to get to your position. Each sub will have a random crew level.

When the subs are close to your position and are spawned they are given two (2) waypoints: the first is your position, the second is their current position (so they return to where they came from).

If during their transit to your position they sight any enemies they will engage them.

If they engage any enemies then once the engagement is done they will continue following waypoints.

They are able to make multiple engagements while they are 'active'.

When they reach the end of their second waypoint they will be removed from the game (they will disappear)

Once you send in a contact report Bdu will not consider trying to send subs to your position again for at least 18 hrs. This means send contact reports wisely!

This is the first version of this patch. More work is currently being done on it :yep:

:|\\

[Trevally.]

:Kaleun_Applaud::Kaleun_Party:

[Daytrader]

Nice job, do you add readme's with this new info in each release ? would be good for new people like me.

[gap]

v1.0.68.0 released. See post #1

This is the first version of this patch. More work is currently being done on it :yep:

:|\\

I got a question and one of my clumsy ideas for you. :D

I will start with the question:

when the supporting subs are given our position as first waypoint, is this waypoint static or is it moving with us? In other words, if we request reinforcements and then move from our initial position for shadowing the convoy, where exactly the supporting units wil look for us? :hmm2:

and now my idea, for when you will be able to read current date/time :)

It requires as well your patch to be able reading an array of map positions from an external file (like the ones used for historical radio messages), and to calculate distances between 2 points.

In a nutshell: using datas available on the web, we could create some tables containing historical U-boat positions for each date. After rolling the dices for determining wether BdU will respond back to our request, and the number of friendly units that will be sent, the game should look in those tables for the n units closer to our position on that date. If they are within a given range from us, they spawn (with some random delay) at the position stated in the table, headig toward us, and BdU send us the 'Shadow contact/convoy while awaiting reinforcements' message. If noone of them meets this requirement, no support unit is spawned, and we get the message 'no unit in your current area' or so.

In this way, the probability to get reinforcements, and the number of supporting units, would be related to the historical presence and frequency of U-boats in any given area and date.

What do you think? :smug:

[Trevally.]

Hi TDW:salute:

I have been testing your new patch today:up:
I am in 1939 and following a convoy.
I sent my first contact report - no response from BdU
I followed for another 18 hours and sent another contact - no message
Another 18 hours and another contact report = no message

So am I correct in thinking that at he moment we will only get a message if our 1 in 10 chance is chosen and we only get a shot at the 1 in 10 chanse every 18 hours:06:

[Trevally.]

Would this be the dbview report for a failed contact report to BdU:-


00001199 1843.79333496 [6664] New radio contact report received
00001200 1843.79357910 [6664] Determining radio contact report course
00001201 1843.79357910 [6664] Radio contact report received. Verifying range
00001202 1843.79858398 [6664] Range was not verified for radio contact report


:06:

[TheDarkWraith]

Hi TDW:salute:

I have been testing your new patch today:up:
I am in 1939 and following a convoy.
I sent my first contact report - no response from BdU
I followed for another 18 hours and sent another contact - no message
Another 18 hours and another contact report = no message

So am I correct in thinking that at he moment we will only get a message if our 1 in 10 chance is chosen and we only get a shot at the 1 in 10 chanse every 18 hours:06:

I put the reset timer @ 18 hours so as to avoid people 'abusing' the new patch. When you send in a contact report if the timer isn't active then it starts. If it's already active nothing happens. Only when the timer starts does it check to see if Bdu will dispatch subs to your position. Does anyone have a better idea? Maybe I need another timer that is the failed timer - i.e. if Bdu does not dispatch subs to your position then a failed timer of X time is started and Bdu will not consider your contact report again until the failed timer times out (maybe set this to 2 hours?). Then when/if Bdu grants your contact report use the 18hr timer as the reset timer before Bdu will ever dispatch subs to your position again?

When the dispatched subs spawn the first waypoint they are given is your current position. This waypoint is static - i.e. it is not updated. So it's best to be in a position in front of the convoy/contact when sending in the contact report and when shadowing the contact/convoy. I never thought about updating the waypoint :hmmm:

[Trevally.]

Yes - spamming the send contact report could spoil things:hmmm:

Perhaps as you say 2 hours for the timer if failed, 18 hours (or even longer -24hrs) if boats sent.
Is it not the case that you can only send contact every 2 hours anyway:hmmm:

Following a convoy and sending a contact report, for me if this resulted in a failed wolfpack send - I would most likely just go ahead and attack my self.

Getting a message that wolfpack will form and me having to follow for up to 8 hours sounds ok, this could be increased to higher, say 12 to 24 hours:hmmm:



When the dispatched subs spawn the first waypoint they are given is your current position. This waypoint is static - i.e. it is not updated.


This may be ok if the u-boat spawn point is not too far away (u-boats will attack a contact within 20km:hmmm:) - When shadowing a convoy, it is easier from behind:hmmm:

[TheDarkWraith]

Perhaps as you say 2 hours for the timer if failed, 18 hours (or even longer -24hrs) if boats sent.
Is it not the case that you can only send contact every 2 hours anyway:hmmm:

Following a convoy and sending a contact report, for me if this resulted in a failed wolfpack send - I would most likely just go ahead and attack my self.

Getting a message that wolfpack will form and me having to follow for up to 8 hours sounds ok, this could be increased to higher, say 12 to 24 hours:hmmm:

This may be ok if the u-boat spawn point is not too far away (u-boats will attack a contact within 20km:hmmm:) - When shadowing a convoy, it is easier from behind:hmmm:

I'm adding a new timer - I'm calling it the failed timer. When you send in a contact report and Bdu doesn't send subs to your position then this failed timer will go active. The minimum time of the failed timer will be 2 hours, the max time will be double the minimum time. A random number will be generated (0-1.0) and multiplied by the minimum time and the minimum time will be added to the result. This will give the new time before Bdu will consider sending subs to your position on next contact report sent.

I can change the spawn time. It's a variable in my patch file so it's an easy thing to change. I set it to 8 hrs currently (this is the max time - a random number is generated (0-1.0) and is multiplied by this time to get the true spawn time for the sub)

When the game spawns a new sub the max radius it can spawn from your sub is 15km - well within the 20km. This means anywhere within a 15km radius of your sub is where the game will spawn the new sub.

Should have revised Contact report wolfpacks patch available here soon :up:

[Trevally.]

I'm adding a new timer - I'm calling it the failed timer. When you send in a contact report and Bdu doesn't send subs to your position then this failed timer will go active. The minimum time of the failed timer will be 2 hours, the max time will be double the minimum time. A random number will be generated (0-1.0) and multiplied by the minimum time and the minimum time will be added to the result. This will give the new time before Bdu will consider sending subs to your position on next contact report sent.

I can change the spawn time. It's a variable in my patch file so it's an easy thing to change. I set it to 8 hrs currently (this is the max time - a random number is generated (0-1.0) and is multiplied by this time to get the true spawn time for the sub)

When the game spawns a new sub the max radius it can spawn from your sub is 15km - well within the 20km. This means anywhere within a 15km radius of your sub is where the game will spawn the new sub.

Should have revised Contact report wolfpacks patch available here soon :up:

Sounds good :Kaleun_Salivating:

[Dogfish40]

Go to your SH5 folder >> MODS >> TDWs NewUI >> data >> Applications >> Dbgviewer.exe

You can copy it on your desktop beside sh5 lunch icon.

In the Dbgviewer you can save the result in the end into a file and post it for TDW to pick on.

Sorry about the late responce Targor, Thanks a bunch. I'll do this.
D40

[Dogfish40]

Can someone tell me the keyboard commands for the Ind Engine control?
I had the 7.2 UI installed but I get a CTD when I change engine speed.
So, I am trying the patch in the 7.1 UI to see if I still get the same result.
I really appriciate it.
Thanks
D40 :hmmm:

[Trevally.]

Can someone tell me the keyboard commands for the Ind Engine control?
I had the 7.2 UI installed but I get a CTD when I change engine speed.
So, I am trying the patch in the 7.1 UI to see if I still get the same result.
I really appriciate it.
Thanks
D40 :hmmm:

You should try re-installing your patched files again.
I made a mistake changing mine and had ctd with speed changes - turned out I used my tutorial version (:doh::D).
After doing it again and ensuring I patched all three files correctly = no ctds (using UI 7.2):up:

[gap]

Should have revised Contact report wolfpacks patch available here soon :up:

So no hope for my convoluted idea to be given a chance, even in a far future? :D

I hope you don't get me wrong: your new patch is already a huge step forward, but as it is now, we have the same probability of getting renforcements in the crowded North Atlantic than we have in South Pacific or in the distant Indian Ocean. The same goes for different phases of the conflict: during late war I wouldn't expect to get as much support by nerby subs as I could during Happy Times. :yep:

Though being a hell of work, collecting, formatting and implementig in your patch historical U-boat positions would add a new dimension to it, and would increase the feeling of a dynamically evolving campaign. :)

[TheDarkWraith]

So no hope for my convoluted idea to be given a chance, even in a far future? :D

I hope you don't get me wrong: your new patch is already a huge step forward, but as it is now, we have the same probability of getting renforcements in the crowded North Atlantic than we have in South Pacific or in the distant Indian Ocean. The same goes for different phases of the conflict: during late war I wouldn't expect to get as much support by nerby subs as I could during Happy Times. :yep:

Though being a hell of work, collecting, formatting and implementig in your patch historical U-boat positions would add a new dimension to it, and would increase the feeling of a dynamically evolving campaign. :)

The idea is great, implementing it will take time :up: If I was writing this code in C# it would be a snap but writing in assembly things takes about 100X longer. I have an idea though: I can write the code in C# and view the assembly generated and hopefully copy it over (making modifications as necessary) into OllyDebug and if everything works copy everything to a patch file :yep:

[gap]

The idea is great, implementing it will take time :up: If I was writing this code in C# it would be a snap but writing in assembly things takes about 100X longer. I have an idea though: I can write the code in C# and view the assembly generated and hopefully copy it over (making modifications as necessary) into OllyDebug and if everything works copy everything to a patch file :yep:

Good, thank you TDW! :up:

Let me know then, if you find a way to implement it without too much hassle from your part.

Getting daily U-boat log positions is not a problem, since they're available from several web resources. The hard part would be arranging this information in a way that you can easily access it, and possibly interpolating lacking info.

This task would require a massive involvement of our community, in order to be raccomplished within a reasonable timeframe :yep:

[TheDarkWraith]

All the modifications for adding the failed timer has been added to the Contact reports wolfpack patch. Doing the final testing now :up:

[Trevally.]

All the modifications for adding the failed timer has been added to the Contact reports wolfpack patch. Doing the final testing now :up:

:up:

[TheDarkWraith]

Noticed a bug...not sure what the severity of it is currently but trying to figure out how to fix it. When you exit the mission and return to the main screen or the bunker my timers are still active. I have to figure out how to determine when you are no longer in the mission and reset all the timers and deactivate them for the Contact report wolfpacks patch.

Since I'm going to be updating the patch yet again I'm going to try and add the ability to update the first waypoint of the subs dispatched so that they always have you current position.

I've also noticed that dispatched subs can spawn really close to your sub and I need to remedy this also (or I should say try to)

[Tonci87]

Another idea: Would it be possible to charge batterys without props turning? That way you could stay at your waiting position and recharge.

[gap]

Since I'm going to be updating the patch yet again I'm going to try and add the ability to update the first waypoint of the subs dispatched so that they always have you current position.

Can't you instead update the first waypoint only when a status report is sent, with all the involved limitations (the sub has to be surfaced, radio functional, and at least 2 hours have to be be passed from the last report)? :hmmm:

[TheDarkWraith]

Can't you instead update the first waypoint only when a status report is sent, with all the involved limitations (the sub has to be surfaced, radio functional, and at least 2 hours have to be be passed from the last report)? :hmmm:

I already added the have to be surfaced limitation in the last update to the patch (unreleased). In order to receive reply from Bdu you must be surfaced (remember it can be up to an hour to receive a reply back after sending in a contact report - no reply back means no subs being dispatched).

Status reports don't have a time limitation do they? I mean we can send them anytime correct? :hmmm:

[gap]

I already added the have to be surfaced limitation in the last update to the patch (unreleased). In order to receive reply from Bdu you must be surfaced (remember it can be up to an hour to receive a reply back after sending in a contact report - no reply back means no subs being dispatched).

Status reports don't have a time limitation do they? I mean we can send them anytime correct? :hmmm:

I think I've never sent one :oops:

...but so far there was little point in doing it, or at least I guess so. Anyway, looking in menu.txt I've found this row:

4030=Send Status Report| Works only if:| - the submarine is surfaced| - the radio is functional| - it has been more than 2 hours since the last status report

My point is, how would the soccurring subs know our new coordinates, if we didn't report them via radio? ;)

Imo, using the status report button for making BdU aware of our changed position, would have the double advantage to put to use an already existing but hardly used game feature, and to add some extra realism to the whole radio reinforcement stuff, making it a bit trickier too :yep:

[TheDarkWraith]

I think I've never sent one :oops:

...but so far there was little point in doing it, or at least I guess so. Anyway, looking in menu.txt I've found this row:



My point is, how would the soccurring subs know our new coordinates, if we didn't report them via radio? ;)

Imo, using the status report button for making BdU aware of our changed position, would have the double advantage to put to use an already existing but hardly used game feature, and to add some extra realism to the whole radio reinforcement stuff, making it a bit trickier too :yep:

I like it :yeah: Yes, this would be perfect for updating the dispatched AI subs.

I only see one little snag: Each dispatched sub is only spawned when it's timer times out. Let's say Bdu is dispatching 3 subs to your position. Sub #1 will appear in 1 hour. Sub #2 will appear in 1.75 hours. Sub #3 will appear in 5 hours. Sub #1 is spawned and player sends a status report to inform Bdu of position and Bdu in turn updates dispatched AI subs (but only sub #1 will be updated as the other two haven't spawned yet). So sub #1 gets updated waypoint. Sub #2 spawns and player can't send status report because it hasn't been 2 hours....acceptable :06:

Or I add a new command to the game, something like "Update_Wolfpack_Position_With_Player_Position" that when sent to the game will update dispatched subs with your current position...

[gap]

I like it :yeah: Yes, this would be perfect for updating the dispatched AI subs.

I only see one little snag: Each dispatched sub is only spawned when it's timer times out. Let's say Bdu is dispatching 3 subs to your position. Sub #1 will appear in 1 hour. Sub #2 will appear in 1.75 hours. Sub #3 will appear in 5 hours. Sub #1 is spawned and player sends a status report to inform Bdu of position and Bdu in turn updates dispatched AI subs (but only sub #1 will be updated as the other two haven't spawned yet). So sub #1 gets updated waypoint. Sub #2 spawns and player can't send status report because it hasn't been 2 hours....acceptable :06:

can't you retain the reported position in memory, and give it as first waypoint to the subsequently spawned subs? Currently, wich coordinates would they be given?

Or I add a new command to the game, something like "Update_Wolfpack_Position_With_Player_Position" that when sent to the game will update dispatched subs with your current position...

I don't get you :hmm2:
Would it be an alternative to the status report? If yes, how this command is going to iron out the problem with "late" subs?
If not, would it be an "hidden" command, executed automatically after the status report is sent, and active until all the dispatched subs are spawned :06:

[TheDarkWraith]

can't you retain the reported position in memory, and give it as first waypoint to the subsequently spawned subs? Currently, wich coordinates would they be given?


I don't get you :hmm2:
Would it be an alternative to the status report? If yes, how this command is going to iron out the problem with "late" subs?
If not, would it be an "hidden" command, executed automatically after the status report is sent, and active until all the dispatched subs are spawned :06:

Everytime a dispatched sub is spawned it's given the player's sub's current position as waypoint 1. So it automatically has the current position of the player's sub. Your idea with the status report would update waypoint 1 with the player's sub's current position. Which now that I think about it what benefit does this have if I already give the spawned sub the player's current position :06:

[gap]

Everytime a dispatched sub is spawned it's given the player's sub's current position as waypoint 1. So it automatically has the current position of the player's sub. Your idea with the status report would update waypoint 1 with the player's sub's current position. Which now that I think about it what benefit does this have if I already give the spawned sub the player's current position :06:

The benefit is related to immersion: dispatched subs should only know our initial position, unless we send an update with our new coordinates at the cost of having to surface, risking that our message gets intercepted by enemies, being able to send only one update every 2 hours, etc.

A possible workaround for subs having automatically our updated position when they are spawned, is making all of them to be spawned immediately after the convoy report (even if BdU will delay their answer by one or more hours).

They should be spawned at different ranges from our sub though. In this way they would join us at different times, and there would be an higher probability for them to get stopped by something while underway, hence increasing randomnes... :hmm2:

what do you think?

[TheDarkWraith]

The benefit is related to immersion: dispatched subs should only know our initial position, unless we send an update with our new coordinates at the cost of having to surface, risking that our message gets intercepted by enemies, being able to send only one update every 2 hours, etc.

A possible workaround for subs having automatically our updated position when they are spawned, is making all of them to be spawned immediately after the convoy report (even if BdU will delay their answer by one or more hours).

They should be spawned at different ranges from our sub though. In this way they would join us at different times, and there would be an higher probability for them to get stopped by something while underway, hence increasing randomnes... :hmm2:

what do you think?

I have to think about this...I like the idea of having them spawn at the end of a timer. What I could do is increase the spawn radius to say 50km. That way by the time the dispatched sub would reach your 'current' position you would be long gone so you would have to send a status report at regular intervals so your current position is relayed to the dispatched subs. There's one negative to this: if the dispatched sub is already on waypoint 2 then it's not turning around to come help you, it's bugging out to where it came from.

[Mikemike47]

I have to think about this...I like the idea of having them spawn at the end of a timer. What I could do is increase the spawn radius to say 50km. That way by the time the dispatched sub would reach your 'current' position you would be long gone so you would have to send a status report at regular intervals so your current position is relayed to the dispatched subs. There's one negative to this: if the dispatched sub is already on waypoint 2 then it's not turning around to come help you, it's bugging out to where it came from.

Has the radio operator's "safe communications" been checked for functionality still when using the status report and the timer options?

[gap]

I have to think about this...I like the idea of having them spawn at the end of a timer.

What is the use of using a timer, besides simulating that they were at different ranges from us when we made our first report?

If you actually make them to spawn at different ranges you don't need to simulate it and we get a step closer to reality :yep:


What I could do is increase the spawn radius to say 50km. That way by the time the dispatched sub would reach your 'current' position you would be long gone so you would have to send a status report at regular intervals so your current position is relayed to the dispatched subs.

yes, imo giving them an higher maximum spawn radius, and widening at the same time its range (difference between max-min), is the way to do it.

There's one negative to this: if the dispatched sub is already on waypoint 2 then it's not turning around to come help you, it's bugging out to where it came from.

Aren't AI subs equipped with sensors? Wouldn't they look for hydro/radar contacts around them before resuming their travel? :hmmm:

I see another drawback to increasing spawn radius: we would increase as well the probability that one or more subs get spawned on land, especially if we are operating around coasts.

Implementing the historical U-boat coordinates database suggested by me for determining spawning positions would obviate to this problem. :)

[TheDarkWraith]

Luckily I've made almost everything reference variables in my patch file so it'll be easy to test different scenarios (spawn radius, timer values, etc.). I see lots of testing to be done with this revised patch forthcoming :yep:

[gap]

Luckily I've made almost everything reference variables in my patch file so it'll be easy to test different scenarios (spawn radius, timer values, etc.). I see lots of testing to be done with this revised patch forthcoming :yep:

:up:

[TheDarkWraith]

I found a function that's always called when ending a single mission or campaign mission so I have a way to disable my timers now :yeah: That bug has been squashed!

[TheDarkWraith]

v1.0.69.0 released. See post #1

This version revises the Contact report wolfpack patch.
The following items were fixed:
- bug of timers not resetting when game end
- bug of able to receive Bdu message when submerged

The following items were added to the patch:
- a fail timer was added. If you send a contact report to Bdu and they do not respond back then the fail timer is activated. It's value is a minimum of 2 hrs up to a maximum of 4hrs. Sending in a contact report before the fail timer times out will result in Bdu totally ignoring you (and you have no idea when the fail timer times out!)
- when Bdu dispatches subs to your position then the reset timer is active. This timer is 18hrs. Bdu will not even consider dispatching more subs to your position until at least 18hrs has passed.

The following items were changed:
- % chance of having Bdu dispatching subs to your position has increased to 20%

@gap - this does not include anything that we have discussed. This is basically a revised version of this first version of this patch. I'll work on implementing what we discussed tomorrow (I have to do a little research and find the function that despawns units first so that I'm not trying to use null pointers and thus causing a CTD). All of this is leading into the carriers in the game having the ability to launch airplanes when they detect a contact! How cool would that be to see?

I have to add more code to my generic patcher app so that you all can edit the variables contained in my patch files :yep:

:|\\

[Trevally.]

Great work TDW - just about to start testing:up:
Does this work within single missions for testing - or campaign only:06:

[Trevally.]

Using timers and radio messages here is how the wolfpacks could work:hmmm:

So far as I understand this we can use timers to control when events happen and sent messages to trigger.

Trigger 1 -send our contact report and BdU
Timer 1 - Bdu will send message within 1 hour if pack will form (we are contact keeper)
Timer 2 - Time to first spawn more than min 2 hours - max 6 hours from our first contact report sent.
Timer 3 - just before (say 30 mins ) 1st spawn a message is sent to us asking us to send status report (to give incomming spawned boat bearings to convoy - just as a contack keeper would do) - this will be the aim point for the 1 st spawn boat.
Trigger 2 - we send our status report.
Timer 4 - within 1 hour of us sending that status report, 1st spawn happens and aims for you possition from last status report.
Timer 5 - we get another message from btu (more than 2 hours have passed perhaps up to 6 hours) to send a new contact keeper bearing for the 2nd spawn

etc etc

Using messages and timed events this way we could give the imersion by the messages sent and the staggering of boats arriving:hmmm:

[Trevally.]

Been testing in single missions (over 20 tests) - still no message from BdU:arrgh!:

When sending contact report - Is there any diff between the one from the capains log/contact report and the one from the radio officers/reports/send contact report:06:

The reason I ask is that when you send a report from the:-
Captains log - no message appears in the message box - send button is greyed out and can't be used again for 2 hours.
Radio Officer/reports/contact report - message send displayed in message box and in DebugView - you can send as many as you like - no 2 hour resend limit
:hmmm:

[Tonci87]

Guys you are forgetting one thing.
If you send a status report, you don´t only send your own position but you also send contact informations like speed and course of the convoy. Therefore friendly subs shouldn´t spawn at the players position or get a waypoint to the players position. BDU should send them to the estimated position of the convoy calculated from the speed and course transmitted by the contact report.

[Trevally.]

Ok - got my first wolfpack:woot:

In single mission - using radio officer/report/send contact report.
I am well behind the convoy (8 to 9 km) just out of their sight
http://img805.imageshack.us/img805/777/46467361.jpg

Some time later I see a uboat heading towards me from the direction of the convoy.
It sails past me and away to the east - gone.


Some time later another one shows up and it sees the convoy.
It turns and gives chase at 14knots.

http://img3.imageshack.us/img3/5924/87824237.jpg

http://img52.imageshack.us/img52/1980/35410642.jpg

When it gets close to convoy (5km) the convoy fires and it dives - convoy moves further away again.
This happens many times and the uboat just can't close the distance.
Even when night starts to fall - uboat can't get close enough.
It then leaves:wah:

So - as the patch stands (and just as TDW said:D) you must be way ahead of the convoy - not behind:hmph:

[Mikemike47]

Guys you are forgetting one thing.
If you send a status report, you don´t only send your own position but you also send contact information like speed and course of the convoy.

This is not totally accurate, the contact report sends information like speed and course of the convoy, not the status report. Unless TDW is rewriting the status report code which includes contact information just for the SH5.exe patch, then my mistake.

[Trevally.]

Ok - I try again and this time stay in front of convoy
http://img545.imageshack.us/img545/6888/90697614.jpg

http://img833.imageshack.us/img833/7126/36599052.jpg

http://img109.imageshack.us/img109/4308/12891919.jpg

http://img89.imageshack.us/img89/1395/47171523mm.jpg

http://img259.imageshack.us/img259/6756/46432899.jpg

http://img841.imageshack.us/img841/1305/61701969.jpg

http://img88.imageshack.us/img88/8703/69028061.jpg

http://img3.imageshack.us/img3/9425/86371956c.jpg

So - being in front of the convoy works as the uboats will be able to turn into the oncomming ships.

I am using IRAI v0.0.37:hmmm:
I have watched many campaign scripted wolfpack attacks and never have the boats fired their torps in the wrong direction.
It was like they wanted to attack a preset map point? Perhaps where I was when BdU message said yes to form wolfpack?
After the first salvo all missed - their next attack runs were ok and at the ships

The uboat tactics were good - staying under as soon as they were fired upon.

[TheBeast]

Ok - got my first wolfpack:woot:

In single mission - using radio officer/report/send contact report.
I am well behind the convoy (8 to 9 km) just out of their sight

Some time later I see a uboat heading towards me from the direction of the convoy.
It sails past me and away to the east - gone.

Some time later another one shows up and it sees the convoy.
It turns and gives chase at 14knots.

When it gets close to convoy (5km) the convoy fires and it dives - convoy moves further away again.
This happens many times and the uboat just can't close the distance.
Even when night starts to fall - uboat can't get close enough.
It then leaves:wah:

So - as the patch stands (and just as TDW said:D) you must be way ahead of the convoy - not behind:hmph:

This actually makes some sense that when you call for wolf pack support, you should be in front of the convoy when shadowing. This would easily enable wolfpack boats joining in on attack to assume attack positions in front of the convoy.

SUGGESTION: (if possible)
Boats coming in one-by-one and attacking does not make sense.
Sinse you are the boat calling for support, you should be the Wolfpack Leader.
All boats joining in on Wolfpack should form up with the Wolfpack Leader (1-3km abrest spacing) and not break formation and attack until the Wolfpack leader gives the attack order.
When attack is done, Wolfpack leader give Disband Wolfpack order.
This would allow several boats to join the Wolfpack prior to engagement.
Also, this would allow you (Wolfpack Leader) to participate in attack as well.

[Tonci87]

This actually makes some sense that when you call for wolf pack support, you should be in front of the convoy when shadowing. This would easily enable wolfpack boats joining in on attack to assume attack positions in front of the convoy.

SUGGESTION: (if possible)
Boats coming in one-by-one and attacking does not make sense.
Sinse you are the boat calling for support, you should be the Wolfpack Leader.
All boats joining in on Wolfpack should form up with the Wolfpack Leader (1-3km abrest spacing) and not break formation and attack until the Wolfpack leader gives the attack order.
When attack is done, Wolfpack leader give Disband Wolfpack order.
This would allow several boats to join the Wolfpack prior to engagement.
Also, this would allow you (Wolfpack Leader) to participate in attack as well.

^this!

[Trevally.]

^this!

It did not feel too bad.
The first boat was still attacking as the third and last boat showed up.
I could then have also joined in making four boats attacking from all directions.

There is still more that could make these attacks great.
Messages before boats arrive to set the scene etc

[TheDarkWraith]

If I had the source code I could do many things but alas I only have what OllyDebug shows me and what I have decoded of the assembly. Thus while it would be nice to do the things you all mention and suggest sometimes it's impossible or next to impossible to do.

I've been working on decoding the sh5.exe and it's supporting files (.act files) for over 1.5 years. This is what allows me to do what I currently do with my patch files. I understand much of how the game works from this also. I don't think some of you understand just how difficult it is to add new ideas to an app via assembly. I don't have the luxury of having high-level source code that I can read over or study to know exactly what is going on in a particular function. Instead I have to make guesses and stumble my way around hoping that one or more of my guesses are correct so that I can set a label on them so that I know what they are doing. Over time when you stumble around and add enough labels things start to become more clear and start to make sense (it gets easier to figure out new functions and figure out what some pointers point to). Even then I may not know what a particular function call does 100% but I do know that if I mimmic it or pass certain parameters to it it will do what I want it to do. It's extremely frustrating and exhilarating at the same time working in assembly.

While some of my ideas may not be exactly what you think they should be realize that I'm making something from nothing, something from pure guesses on my part. As I continue to decode more and learn more about the inner workings of the game my patches will evolve to show that understanding :)

[TheDarkWraith]

So - being in front of the convoy works as the uboats will be able to turn into the oncomming ships.

I am using IRAI v0.0.37:hmmm:
I have watched many campaign scripted wolfpack attacks and never have the boats fired their torps in the wrong direction.
It was like they wanted to attack a preset map point? Perhaps where I was when BdU message said yes to form wolfpack?
After the first salvo all missed - their next attack runs were ok and at the ships

Your scripted campaign wolfpacks probably had crew as veteran or elite also though. Here the crew level of each dispatched sub is random - they could be totally green or elite - you have no idea.

They (dispatched subs) are not given any preset points to fire upon, they are only given two waypoints to follow. Thus their AI (and crew level) dictate how they engage contacts :up:

I like the fact that not all dispatched subs show up at the same time. I also like the fact that I have no idea when they will show up. Forces me to shadow the contact/convoy until they do (which is realistic).

[gap]

If I had the source code I could do many things but alas I only have what OllyDebug shows me and what I have decoded of the assembly. Thus while it would be nice to do the things you all mention and suggest sometimes it's impossible or next to impossible to do.

I've been working on decoding the sh5.exe and it's supporting files (.act files) for over 1.5 years. This is what allows me to do what I currently do with my patch files. I understand much of how the game works from this also. I don't think some of you understand just how difficult it is to add new ideas to an app via assembly. I don't have the luxury of having high-level source code that I can read over or study to know exactly what is going on in a particular function. Instead I have to make guesses and stumble my way around hoping that one or more of my guesses are correct so that I can set a label on them so that I know what they are doing. Over time when you stumble around and add enough labels things start to become more clear and start to make sense (it gets easier to figure out new functions and figure out what some pointers point to). Even then I may not know what a particular function call does 100% but I do know that if I mimmic it or pass certain parameters to it it will do what I want it to do. It's extremely frustrating and exhilarating at the same time working in assembly.

While some of my ideas may not be exactly what you think they should be realize that I'm making something from nothing, something from pure guesses on my part. As I continue to decode more and learn more about the inner workings of the game my patches will evolve to show that understanding :)

Fair enough TDW.

Every time I post a suggestion for improving one of your mods, I try to make some self censorship asking myself: "is this going to be reasonably possible, or rather my post can be catalogued as spam?". I think other members are doing pretty much the same. But, given our little to no knowledge of the game code, we are forced to deduce what can be done and what not from features you have already introduced with other patches. By doing so we can, indeed, misinterpret the "moddable" potential of this game.

On the other hand, it would be a pity if we refrained ourselves from posting a good suggestion, because we erroneously thought that it was undoable. In many cases, the best we can do is to refer it to your judgment, and to cross the fingers in the meanwhile. :)

This is to say: take our ideas for what they are worth. Do what you currently can, put what you think can be done in the near future into your todo list, and trush the rest. Noone with a gram of brain in his head will complain for you doing so :up:

[TheDarkWraith]

Every time I post a suggestion for improving one of your mods, I try to make some self censorship asking myself: "is this going to be reasonably possible, or rather my post can be catalogued as spam?". I think other members are doing pretty much the same. But, given our little to no knowledge of the game code, we are forced to deduce what can be done and what not from features you have already introduced with other patches. By doing so we can, indeed, misinterpret the "moddable" potential of this game. On the other hand, it would be a pity if we refrained ourselves from posting a good suggestion, because we erroneously thought that tha it was undoable.

This is to say: take our ideas for what they are worth. Do what you currently can, put what you think can be done in the near future into your todo list, and trush the rest. Noone with a gram of brain in his head will complain for you doing so :up:

Don't get me wrong I love the ideas and thoughts you all put forward :yep: I just may not have the current skill level or knowledge of the game to implement at the current time. But like I said my patches will evolve as my understanding of the inner workings of the game grows :up:

[gap]

Don't get me wrong I love the ideas and thoughts you all put forward :yep: I just may not have the current skill level or knowledge of the game to implement at the current time. But like I said my patches will evolve as my understanding of the inner workings of the game grows :up:

We are already stunned with wath your current understanding of the game has rendered possible so far. Just can't wait to see the rest! :D

[Trevally.]

For those wanting to test the wolfpack patch - I have uploaded a single mission "TestWolf"

You will start 8 km ahead of a convoy (no estorts) heading west at 7 knots. Convoy also heading west at 7 knots.

Report contact and fast forward - If no message within one hour - reload and try again:D

DOWNLOAD (http://www.4sync.com/archive/ipGgQdTF/Mission_TestWolf.html)

[volodya61]

Thanks a lot Trevally!

[TheDarkWraith]

Now I embark upon the long journey of trying to implement what gap and I discussed here publicly. I will take a baby step approach to this. First order of business is modifying my unit spawner code so that I can specify minimum and maximum spawn ranges (I already have the maximum range coded in just have to add the minimum range). After that I have to figure out how the game keeps track of all units in game (when spawned where are they added to, specifically which function is called that adds them and when despawned what function is called to handle this).
The current version of the patcher allowed for 3 extra words in memory per spawned sub that are currently free and can be used for whatever. One of those words will hold the pointer to the spawned sub when I update the code (this way I can get information from it - depth, speed, number of waypoints, etc.). The other two words are for future use which I currently have no plans for.
After storing the pointer to the spawned sub I should be able to spawn the subs very far out (>=50km maybe even 100km away) and force the player to send status reports frequently which will update the spawned sub's waypoint so they continue heading on the correct course. This all depends on how the game handles waypoints which I'm not well versed in yet (for example when a unit attains a waypoint is that waypoint deleted from memory or is there a pointer that points to the current waypoint and is just updated to point to the next waypoint?) This, ultimately, will decide if I can implement gap's idea. I also have to figure out how to update a unit's waypoint for I will need that for this patch and for some ideas I have for the future.
I also have to figure out how to send the radio messages (the official ones) the game has so I can remove the messagebox one. This is needed again for this patch and for some crazy ideas I have for the future :yep:

[gap]

Now I embark upon the long journey of trying to implement what gap and I discussed here publicly. I will take a baby step approach to this. First order of business is modifying my unit spawner code so that I can specify minimum and maximum spawn ranges (I already have the maximum range coded in just have to add the minimum range). After that I have to figure out how the game keeps track of all units in game (when spawned where are they added to, specifically which function is called that adds them and when despawned what function is called to handle this).
The current version of the patcher allowed for 3 extra words in memory per spawned sub that are currently free and can be used for whatever. One of those words will hold the pointer to the spawned sub when I update the code (this way I can get information from it - depth, speed, number of waypoints, etc.). The other two words are for future use which I currently have no plans for.
After storing the pointer to the spawned sub I should be able to spawn the subs very far out (>=50km maybe even 100km away) and force the player to send status reports frequently which will update the spawned sub's waypoint so they continue heading on the correct course. This all depends on how the game handles waypoints which I'm not well versed in yet (for example when a unit attains a waypoint is that waypoint deleted from memory or is there a pointer that points to the current waypoint and is just updated to point to the next waypoint?) This, ultimately, will decide if I can implement gap's idea. I also have to figure out how to update a unit's waypoint for I will need that for this patch and for some ideas I have for the future.
I also have to figure out how to send the radio messages (the official ones) the game has so I can remove the messagebox one. This is needed again for this patch and for some crazy ideas I have for the future :yep:

Keep us informed on any progress you will be doing TDW :yeah:

[TheDarkWraith]

Well I just found the function that's responsible for the game radio messages :rock: So one down, many to go!

Here's an interesting tid bit of info: while decoding this function call it called out to another function at the start that compared the sub's true depth to -20. The result of that determined whether you received the radio message or not. So 20m depth is the cutoff point where the game says you cannot receive radio messages :cool:

This was an important find (function responsible for radio messages) because I need this for some upcoming ideas :yep:

EDIT: it appears that if the message is critical then depth is ignored :hmmm:

[Mikemike47]

Here's an interesting tid bit of info: while decoding this function call it called out to another function at the start that compared the sub's true depth to -20. The result of that determined whether you received the radio message or not. So 20m depth is the cutoff point where the game says you cannot receive radio messages :cool:

This was an important find (function responsible for radio messages) because I need this for some upcoming ideas :yep:

EDIT: it appears that if the message is critical then depth is ignored :hmmm:
You have created a depth option in TheDarkWraithUserOptions.py under the Radio button, "Below this depth (in meters) do not receive radio contacts/reports". default is set for 30 presently.

[volodya61]

You have created a depth option in TheDarkWraithUserOptions.py under the Radio button, "Below this depth (in meters) do not receive radio contacts/reports". default is set for 30 presently.
I think this option configures the radio messages from the NewUI not from the game.. :hmmm:

[TheDarkWraith]

the things I get into......

http://www.subsim.com/radioroom/picture.php?albumid=669&pictureid=5921

http://www.subsim.com/radioroom/picture.php?albumid=669&pictureid=5920

Notice that I can spawn official radio messages now (and they are automatically added to the captain log also!) I can make the body of the message be anything I want, looking into how to change the to/from now :rock:

Those using my UIs mod the mod will intercept this and reroute it to the radio messages tab of the mod.

Oh and it will adjust the TC level to the appropriate one just like the game does when you get a radio message from it.

Now I need the official statement that Bdu would send to the U-boats for this. We can have multiple statements and I can have the patch randomly choose one if need be.

I'll be updating the Contact report wolfpack patch here in a few :up:

If I can figure out how to change the to/from it will open up a whole world of possibilities and ideas that I have...

[gap]

I also have to figure out how to send the radio messages (the official ones) the game has so I can remove the messagebox one. This is needed again for this patch and for some crazy ideas I have for the future :yep:

What about friendly units asking for our support? :D

the things I get into......

Notice that I can spawn official radio messages now (and they are automatically added to the captain log also!) I can make the body of the message be anything I want, looking into how to change the to/from now :rock:

Those using my UIs mod the mod will intercept this and reroute it to the radio messages tab of the mod.

Oh and it will adjust the TC level to the appropriate one just like the game does when you get a radio message from it.

:rock:


Now I need the official statement that Bdu would send to the U-boats for this. We can have multiple statements and I can have the patch randomly choose one if need be.

something like this?

Your request has been processed. U-xx, U-xx U-xx and U-xx are in your area and have received instructions to join your attack. Stay in front of the convoy, keep undetected and send regular position reports while you are waiting for them.

B.d.U

[TheBeast]

Very nice!:woot:

Would these messages be hand written or typed?

Does the game support Script type Font that looks like hand written message?

Regards!
TheBeast

[TheDarkWraith]

Very nice!:woot:

Would these messages be hand written or typed?

Does the game support Script type Font that looks like hand written message?

Regards!
TheBeast

They are typed. As far as changing the type font it's not possible. The font is dictated in the .ini file for the radio messages (so yes you could change it there via the menu editor included with the game).

I like gap's idea for the reply back from Bdu. Anyone else have any suggestions :06:

[gap]

Two more :cool:

Request of support on convoy attack approved. Be careful. Gain a favourable position in front of the convoy and send regular position reports while waiting for reinforcements.

B.d.U.



U-xx, and U-xx have been dispatched to your patrol area as per your request and will join you briefly. Follow enemy contact from distance and send regular updates on your position.

Befehlshaber der U-Boote


Post your ones guys: variety is the salt of life!

[TheDarkWraith]

Two more :cool:

Request of support on convoy attack approved. Be careful. Gain a favourable position in front of the convoy and send regular position reports while waiting for reinforcements.

B.d.U.

I'll use this one for now. I can always change it later :up:

Actually if you can come up with some that don't include U-xx in them I'll randomize it.

[gap]

What about BdU sending us a reminder, if the first U-boat is about to get to its first waipoint and we haven't sent a position report yet? :hmmm:

[gap]

I'll use this one for now. I can always change it later :up:

Actually if you can come up with some that don't include U-xx in them I'll randomize it.

Can't you add random U-boat numbers within the text? Would be a cool feature but not a vital one indeed.

You could have reworked yourself the messages I've alredy posted, to fit our needs. They are royalty free :O: :haha:
Anyway, since you asked me to do it, you can change the phrase:


"U-xx, U-xx U-xx and U-xx are in your area and have received instructions to join your attack"
to:
"All the U-boats in your area have received instructions to join your attack"

and this one:

"U-xx, and U-xx have been dispatched to your patrol area as per your request and will join you briefly."
to:
"several submarine units have been dispatched to your patrol area as per your request, and will join you briefly."

[TheDarkWraith]

Can't you add random U-boat numbers within the text? Would be a cool feature but not a vital one indeed.

You can rework the messages I've alredy posted to fit our needs. They are royalty free :O: :haha:

for instance, you can change this phrase
"U-xx, U-xx U-xx and U-xx are in your area and have received instructions to join your attack"
to:
"All the U-boats in your area have received instructions to join your attack"

and this one:

"U-xx, and U-xx have been dispatched to your patrol area as per your request and will join you briefly."
to:
"several submarine units have been dispatched to your patrol area as per your request, and will join you briefly."

Yes I could (just have to figure out how to use formatting in assembly via the functions the game exposes) :D

[TheDarkWraith]

What about BdU sending us a reminder, if the first U-boat is about to get to its first waipoint and we haven't sent a position report yet? :hmmm:

That's an interesting idea. I have to figure out the spawning and despawning functions first in order to avoid using a null pointer and causing a CTD :up:

[Cybermat47]

How do I open the patcher and sh5.exe?
Sorry, I'm a complete noob at modding.

[volodya61]

How do I open the patcher and sh5.exe?
Sorry, I'm a complete noob at modding.

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

[Cybermat47]

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

Thx

[TheDarkWraith]

I've randomized the responses back from Bdu.

You can receive back one of these responses when you send in a contact report (the |s are line breaks or new lines):
- Dispatching available submarines to your patrol area|Remain undetected and in a favorable position|Send status reports||Bdu
- All available submarines have been dispatched to your patrol area
- Submarines in your area have received instructions to join your attack|Stay in front of contact/convoy, remain undetected, and send regular status reports|||B.d.u

http://www.subsim.com/radioroom/picture.php?albumid=669&pictureid=5923

Currently they are hard coded in my data section. Tomorrow I will make them menu.txt entries :D

I am now using the stock game function to detemine whether you are able to receive radio messages or not

New version of the patcher coming here soon...

[TheDarkWraith]

v1.0.70.0 released. See post #1

revised the Contact reports wolfpack patch. When Bdu responds back it now uses the radio message window instead of the messagebox. There are 3 possible responses that Bdu can send back. Now using the game's function to determine if able to receive radio messages or not.

The responses are currently hard-coded in my data section. I will turn them into menu.txt entries tomorrow.

:|\\

[volodya61]

Great news and great job TDW!
As always..
Thank you very much!

:salute:


PS:
What do I say on sukhoi.ru to those who don't use your interface?
Will they be able to use this patch when you turn the responses into menu.txt?

[TheDarkWraith]

Great news and great job TDW!
As always..
Thank you very much!

:salute:


PS:
What do I say on sukhoi.ru to those who don't use your interface?
Will they be able to use this patch when you turn the responses into menu.txt?

You don't have to use any UI mod (or any mod) to get these radio messages from Bdu. Since I'm calling the stock function that displays these radio messages it'll work with anything.

Turning these responses into menu.txt entries will allow you to translate them into any language. Currently as they are hard coded in my data section they will always be in English. It will also allow you to add more responses for Bdu in the menu.txt file :up:

[volodya61]

Thanks!

I'll describe this in your patcher's thread on sukhoi.ru..
http://www.sukhoi.ru/forum/showthread.php?t=76762

:salute:

[lesec74]

hello,
I've tried to install the patcher and when I click on sh5 tdw patches a message error says to me that bytes read is not the same than bytes expected!!?I've follwed the tutorial "how use sh5 patcher!":/\\!!

[lesec74]

hello,
I've tried to install the patcher and when I click on sh5 tdw patches a message error says to me that bytes read is not the same than bytes expected!!?I've follwed the tutorial "how use sh5 patcher!":/\\!!

http://img28.imageshack.us/img28/2847/sanstitrebjs.png (http://imageshack.us/photo/my-images/28/sanstitrebjs.png/)
Uploaded with [

[Kalleblom]

Moin,

did you use clean files to patch, or the allready patched versions?

[Kalleblom]

You don't have to use any UI mod (or any mod) to get these radio messages from Bdu. Since I'm calling the stock function that displays these radio messages it'll work with anything.

Turning these responses into menu.txt entries will allow you to translate them into any language. Currently as they are hard coded in my data section they will always be in English. It will also allow you to add more responses for Bdu in the menu.txt file :up:

:salute: TDW,

two days absent and :woot: new pachtes available!

Great work, thank you!

Good news about the menu.txt, eagerly waiting.

[pioleen]

If I had the source code I could do many things but alas I only have what OllyDebug shows me and what I have decoded of the assembly. Thus while it would be nice to do the things you all mention and suggest sometimes it's impossible or next to impossible to do.

I've been working on decoding the sh5.exe and it's supporting files (.act files) for over 1.5 years. This is what allows me to do what I currently do with my patch files. I understand much of how the game works from this also. I don't think some of you understand just how difficult it is to add new ideas to an app via assembly. I don't have the luxury of having high-level source code that I can read over or study to know exactly what is going on in a particular function. Instead I have to make guesses and stumble my way around hoping that one or more of my guesses are correct so that I can set a label on them so that I know what they are doing. Over time when you stumble around and add enough labels things start to become more clear and start to make sense (it gets easier to figure out new functions and figure out what some pointers point to). Even then I may not know what a particular function call does 100% but I do know that if I mimmic it or pass certain parameters to it it will do what I want it to do. It's extremely frustrating and exhilarating at the same time working in assembly.

While some of my ideas may not be exactly what you think they should be realize that I'm making something from nothing, something from pure guesses on my part. As I continue to decode more and learn more about the inner workings of the game my patches will evolve to show that understanding :)

I guess how hard it is. I worked with Z80's assembler long time ago. You also are decoding an exe file from not you. UFFFF!!!! You surprise me. So, I give you a BIG thanks for your job, it is very hard. :up:

An idea... :hmm2: It would be possible to call a dll with your code added by your patcher instead of adding code including all the functions using a more friendly computer languaje than assembler. I mean, your patcher adds the call to the dll but the dll includes the code. Your job would be easier. Ummmm :roll:. No, The problem would be to call some functionality residing in the exe file or delivering the result to the game. Well, It was an idea :03:

Thank you, TDW.

[lesec74]

Moin,

did you use clean files to patch, or the allready patched versions?

files are clean and my game is patch 1.2;
thanks for help

[Kalleblom]

Sorry,

I'm at my wits end. :06:

Have sometimes similar problems, but didn´t recognize how to fit this exactly.

Last i try the tutorial and it works.

[TheDarkWraith]

Sorry,

I'm at my wits end. :06:

Have sometimes similar problems, but didn´t recognize how to fit this exactly.

Last i try the tutorial and it works.

The biggest problem people have is not removing all previous patches with the old patcher first before trying to enable new patches. The easiest way to overcome this 'problem' is to make a new folder in your \MODS folder: \Patched Files. Copy sh5.exe, SHCollisions.act, and SHSim.act into the \MODS\Patched Files folder. Enable the mod with JSGME. Run the patcher app and point it to the \Silent Hunter 5 folder so it will patch those files. When new patcher version comes out deinstall Patched Files mod and then reinstall Patched Files mod. Repatch (now there's no need to disable all patches beforehand!)

As the patcher evolves and patches more files simply copy the needed files into your \Patched Files folder.


Just turned the hard coded data entries into menu.txt entries AND wrote a nice little function that will accept two arguments: start of entry in menu.txt file and number of entries (this will be used for random entries). This nifty little function takes start of entry in menu.txt file + (random number * number of entries) and returns the resultant string. Thus getting a random menu.txt file entry!

[Kalleblom]

Thank you sir! :salute:

i copy my related files before patching (but after the 1.2.0 patch) in my personal "sh5 origininal file" folder.

And when a new patch comes out i use this files. So i have everytime a original version of the files. :rock:

The thing with the menu.txt, will there are problems using a "deutschmod" in the end of the mod list, which include a translation of all menu.txt lines. :hmmm:

[gap]

The biggest problem people have is not removing all previous patches with the old patcher first before trying to enable new patches. The easiest way to overcome this 'problem' is to make a new folder in your \MODS folder: \Patched Files. Copy sh5.exe, SHCollisions.act, and SHSim.act into the \MODS\Patched Files folder. Enable the mod with JSGME. Run the patcher app and point it to the \Silent Hunter 5 folder so it will patch those files. When new patcher version comes out deinstall Patched Files mod and then reinstall Patched Files mod. Repatch (now there's no need to disable all patches beforehand!)

As the patcher evolves and patches more files simply copy the needed files into your \Patched Files folder.

A similar method has been explained several times on this forum, and Trevally started a whole thread about it, complete with pictures and step by step procedures that even complete computer illiterate could follow. :yep:

I wonder what makes installing your patches or using JSGME still so difficult for many people. :hmm2:

Anyway, I think you see now one of the reasons for me asking, a while back, whether you could have done your patcher to patch the game on the fly, instead of modifying the stored exe and act files. :know:



Just turned the hard coded data entries into menu.txt entries AND wrote a nice little function that will accept two arguments: start of entry in menu.txt file and number of entries (this will be used for random entries). This nifty little function takes start of entry in menu.txt file + (random number * number of entries) and returns the resultant string. Thus getting a random menu.txt file entry!

:up:

[Kalleblom]

:salute: gap

what does it mean with the menu.txt file. Can´t figure out and how it´s touch the german translation of the menu.txt. My english isn´t goog enough to understand it.

[TheDarkWraith]

The thing with the menu.txt, will there are problems using a "deutschmod" in the end of the mod list, which include a translation of all menu.txt lines. :hmmm:

Should be no problems. I'm going to modify the patcher app so that it'll recognize entries that say to patch a txt file instead of a binary file. This will allow it to add/remove items from txt files :up:


I added two new variables to the Contact report wolfpacks patch: start of random Bdu responses in menu.txt file (currently set at 10050) and number of random responses (currently set to 5). This means people can add/remove random responses as they wish (all are defined in the menu.txt file starting at 10050)

[Kalleblom]

:salute: TDW and great thx,

now i´ve understand. :up:

[gap]

Should be no problems. I'm going to modify the patcher app so that it'll recognize entries that say to patch a txt file instead of a binary file. This will allow it to add/remove items from txt files :up:

Good idea, though I see a shortcoming to it: if people enable mods that modify menu.txt after having enabled your patch, or if they patch the game after having enabled a modded menu.txt, and then they remove that mod, the patched menu.txt would be overwritten or completely discarded.

I am sure UI mods and language packs will feature soon your new messages. In the meanwhile an esay trick for avoiding confusion, if only people could get accustomed to it, would be following the Tutorial by Trevally, by including the modded/localized menu.txt in the "patch mod" and by making sure to enable it at the end of the JSGME list.

Another solution that occurs to me though is to make your patch to look for a custom txt file, that should be enabled like a normal mod after installing the patch.



:salute: gap

what does it mean with the menu.txt file. Can´t figure out and how it´s touch the german translation of the menu.txt. My english isn´t goog enough to understand it.

Sorry Kalle: I see TDW was faster than me :)

[TheDarkWraith]

Yes could be a minor problem if a mod is enabled that overwrites the patched menu.txt file. Just something user will have to be aware of.

I have the start of the random Bdu responses in the menu.txt file set at 10050...only my UIs mod even comes close to this number.

I built safeguards into the patch that will check to see what the max # of entries defined in the menu.txt is and if that number is less than the entries the patch is calling for then no message is displayed to user (it's actually built into the random menu.txt entries function I made) :up:

[gap]

I built safeguards into the patch that will check to see what the max # of entries defined in the menu.txt is and if that number is less than the entries the patch is calling for then no message is displayed to user (it's actually built into the random menu.txt entries function I made) :up:

I see, :up:
anyway, why not displaying a standard message stored into your code, instead of not displaying a message at all?

[TheDarkWraith]

I see, :up:
anyway, why not displaying a standard message stored into your code, instead of not displaying a message at all?

You make a good point :dead: What should the standard message be then?

[TheDarkWraith]

Added a standard message in case the menu.txt file isn't patched or gets overwritten:

Shadow contact/convoy and remain undetected

So if you see this and it's in English you know your menu.txt isn't updated with the new entries for the Contact report wolfpack patch.

Also changed where the random Bdu messages for this patch are going to start in the menu.txt file to 11000. This will ensure noone will ever get close to these :cool:

I'll have revised version of patcher available here soon (though it will not be able to patch the menu.txt file yet - you'll have to manually add the required entries for now)

[SilentOtto]

TDW, sorry to bug you with this again, but somewhere between version 1.60 and 1.69 it seems you've gone back to compile against .NET 3.5, as you know, some of us (well I think it might well be just me! ><) can't run it under linux... so please, when you have the time, would you be so kind...?

I didn't bug you before since I was quite happy with my patching, but I really want to try the wolfpack function! :salute:

[TheDarkWraith]

TDW, sorry to bug you with this again, but somewhere between version 1.60 and 1.69 it seems you've gone back to compile against .NET 3.5, as you know, some of us (well I think it might well be just me! ><) can't run it under linux... so please, when you have the time, would you be so kind...?

I didn't bug you before since I was quite happy with my patching, but I really want to try the wolfpack function! :salute:

Thanks for bringing that to my attention. I wasn't aware that I switched back to using .NET 3.5 :hmmm:

[gap]

You make a good point :dead: What should the standard message be then?

You could pick any of the messages that you have planned to add to menu.txt. Indeed, it would be only in english, and it wouldn't been shuffled with other similar messages.

Ops... I didn't see your most recent post. I've just noticed that you did it yet :up:

[TheDarkWraith]

TDW, sorry to bug you with this again, but somewhere between version 1.60 and 1.69 it seems you've gone back to compile against .NET 3.5, as you know, some of us (well I think it might well be just me! ><) can't run it under linux... so please, when you have the time, would you be so kind...?

I didn't bug you before since I was quite happy with my patching, but I really want to try the wolfpack function! :salute:

Just checked and I've been compiling against .NET 2.0 for many versions now. What problems are you having?

[TheDarkWraith]

Here is version 1.0.71.0: http://www.mediafire.com/?suulknbpwwr3bg8

Removed the hard coded messages from my data section. Replaced them with menu.txt entries. 5 random Bdu responses are now possible when you send in a contact report.

You will have to edit your menu.txt file and make the following changes:

this is found at the beginning of the file:
MaxStrings=11100

Add these to the very end of the file:
; Contact report wolfpack patch
11000=Dispatching available submarines to your patrol area|Remain undetected and in a favorable position|Send status reports| |Bdu
11001=All available submarines have been dispatched to your patrol area
11002=Submarines in your area have received instructions to join your attack|Stay in front of contact/convoy, remain undetected, and send regular status reports| | |B.d.u
11003=Remain undetected and continue following contact/convoy|Available submarines are heading to your patrol area
11004=Attain favorable position and shadow contact/convoy until reinforcements arrive

When I update the patcher app it will add/check these entries automatically for you :up:

If you get this response from Bdu in English:
Shadow contact/convoy and remain undetected

Then you screwed up somewhere.

By using menu.txt entries this allows other users to translate these messages into their own language (or totally change them to whatever they want).

[volodya61]

Thank you again, sir!. and again.. and again.. and again! :yeah:

:salute:

Is this still the test version (1.0.71) or..?
I thought.. you didn't posted it on the main page..

[TheDarkWraith]

Thank you again, sir!. and again.. and again.. and again! :yeah:

:salute:

Is this still the test version (1.0.71) or..?
I thought.. you didn't posted it on the main page..

It's a releasable version but I'm still playing with it...I have some grand ideas that are starting to mature for this :03:

[TheDarkWraith]

Now I'm going to add radio messages from the dispatched subs to the player. These messages will happen when the dispatched sub starts following it's second waypoint (heading back to where it came from). What are some good messages for this?

Something along the lines of:
Returning to operational duties or
Supplies running low. Returning to base or
:06:

We can have many possible responses and I'll randomize them.

[Trevally.]

Wow TDW some great progress made from last night:woot::woot:

For radio messages - here is the style of message I followed for the campaign wolfpacks.
Perhaps some may fit:hmmm:

http://img692.imageshack.us/img692/4559/53666327.jpg

http://img27.imageshack.us/img27/2613/92302232.jpg

http://img832.imageshack.us/img832/3646/73668310.jpg

I understand that there is only so much info you can give in these messages, but the style of message talk could be used.

All info from this log book - http://www.uboatarchive.net/KTB552-9.htm

:up:

[Trevally.]

Now I'm going to add radio messages from the dispatched subs to the player. These messages will happen when the dispatched sub starts following it's second waypoint (heading back to where it came from). What are some good messages for this?

Something along the lines of:
Returning to operational duties or
Supplies running low. Returning to base or
:06:

We can have many possible responses and I'll randomize them.

Some quotes from that log:-

Attempt to attack fails. The destroyer is now on alert and I'm driven off.


Perhaps the last boat canuse this message (that is if it knows it is the last boat:D)
Abort operation, continue passage on westerly course. Report position and fuel stock immediately.Topp Start homeward passage to St. Nazaire.

[gap]

Good finding Trevally! :up:

Have you found any comm tha could apply to when a sub actually joins the action (waypoint 1 is reached).

@ TDW

Did you manage to make these messages to be received only when surfaced and radio equipment is working?

[TheDarkWraith]

Perhaps the last boat canuse this message (that is if it knows it is the last boat:D)

I would have to add a byte to each spawned sub to denote it's spawn order..could be done.

These messages from the dispatched subs to the player will be menu.txt entries so we can make them whatever we want. I'm just looking for starters so that I can test it.

[TheDarkWraith]

Good finding Trevally! :up:

Have you found any comm tha could apply to when a sub actually joins the action (waypoint 1 is reached).

@ TDW

Did you manage to make these messages to be received only when surfaced and radio equipment is working?

I call the same function the game uses to determine if you are allowed to receive radio messages...this function only checks depth of the sub. I haven't found the damaged items memory locations yet.

[volodya61]

; Contact report wolfpack patch
11000=Dispatching available submarines to your patrol area|Remain undetected and in a favorable position|Send status reports| |Bdu
11001=All available submarines have been dispatched to your patrol area
11002=Submarines in your area have received instructions to join your attack|Stay in front of contact/convoy, remain undetected, and send regular status reports| | |B.d.u
11003=Remain undetected and continue following contact/convoy|Available submarines are heading to your patrol area
11004=Attain favorable position and shadow contact/convoy until reinforcements arrive


This is already translated entries for add to the new NewUIs-menu.txt - http://www.mediafire.com/?fegmhux2bz2jaa7

[SilentOtto]

Just checked and I've been compiling against .NET 2.0 for many versions now. What problems are you having?

This is the error I'm getting, I tried with a fresh sh5.exe to be sure...

http://img19.imageshack.us/img19/5823/patchererror.jpg (http://imageshack.us/photo/my-images/19/patchererror.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

It's not the same kind of trouble as I had before, 'cause then I couldn't load any menu option without getting the error. Now I can select the file to patch, the path, and then i get the error (after confirming the changes in size to the exe file).

[gap]

I call the same function the game uses to determine if you are allowed to receive radio messages...this function only checks depth of the sub. I haven't found the damaged items memory locations yet.

Ok, please don't forget to implement no comm on damaged radio for your messages, if by any chance you find that function lost in SH5 code ;)

[Trevally.]

Good finding Trevally! :up:

Have you found any comm tha could apply to when a sub actually joins the action (waypoint 1 is reached).


No just Topp's own entry where he joined:-

08.00CF 3295 NE 4, Sea 3-4, sky overcast Occupied ordered position in patrol line.


and this:-

Two boats report contact.


Short signal between boats :D

Boats Group Endra***946; report immediately on establishing contact. Take every opportunity to attack. Even knock the corvettes out of action.


So looks like the style of message from one boat to another that it had arrived would be:-

"U*** taking up possition in patrol line (ahead of convoy).
Request bearing signal from contact keeper"

[Trevally.]

This is the error I'm getting, I tried with a fresh sh5.exe to be sure...


With the last two versions - I am getting an error message that Sh5.exe is in use.
When I close the patcher, reopen it and try again - all work fine

[gap]

Occupied ordered position in patrol line.

U*** taking up possition in patrol line



These ones are just perfect! :up:

What do you think TDW?

[TheDarkWraith]

These ones are just perfect! :up:

What do you think TDW?

I'll make 5 entries available for when a dispatched sub spawns. The game will randomly pick from these 5 and send the radio message to the player. You all can customize them and when we all finally agree on them I'll update the patch file to reflect it. How's that :06:

I'll do the same thing for when a dispatched sub starts following waypoint 2 (heading back to where it came from)

[TheDarkWraith]

This is the error I'm getting, I tried with a fresh sh5.exe to be sure...

http://img19.imageshack.us/img19/5823/patchererror.jpg (http://imageshack.us/photo/my-images/19/patchererror.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

It's not the same kind of trouble as I had before, 'cause then I couldn't load any menu option without getting the error. Now I can select the file to patch, the path, and then i get the error (after confirming the changes in size to the exe file).

The only thing different would be I'm compiling for any cpu (can be x64 or x32). Before I was restricting the app to a 32bit app only :hmmm:

[gap]

I'll make 5 entries available for when a dispatched sub spawns. The game will randomly pick from these 5 and send the radio message to the player. You all can customize them and when we all finally agree on them I'll update the patch file to reflect it. How's that :06:

I'll do the same thing for when a dispatched sub starts following waypoint 2 (heading back to where it came from)

Can't you do the same for when a dispatched sub takes position (when it reaches waypoint 1). Messages like the ones posted by Trevally would fit in quite well, and they would warn us that there is going to be some action, in case our watch crew/sonar man missed to do it :)

[BIGREG]

SilentOtto ,have you not forgot to apply the UBI 1.2 patch after your new install :06:

[TheDarkWraith]

Can't you do the same for when a dispatched sub takes position (when it reaches waypoint 1). Messages like the ones posted by Trevally would fit in quite well, and they would warn us that there is going to be some action, in case our watch crew/sonar man missed to do it :)

When the sub spawns I'll have it send out a radio message (it's following waypoint 1 at that time)

[gap]

When the sub spawns I'll have it send out a radio message (it's following waypoint 1 at that time)

:hmmm:

in my opinnion, after our request of getting reinforcements, it would be better getting just one message by BdU, confirming that several U-boote have been dispatched to our area, bla bla bla.

Since -as we have discussed- you are planning to make those subs to spawn at different ranges from us, the interval between their spawning and their joining the attack could greatly vary. With this in mind, I would prefer having individual U-boats signaling their presence just before they reach waypoint 1.

If BdU could also inform us on the number of dipatched U-boats with its 1st message, we would have all the information we need. :up:

[TheDarkWraith]

:hmmm:

in my opinnion, after our request of getting reinforcements, it would be better getting just one message by BdU, confirming that several U-boote have been dispatched to our area, bla bla bla.

Since -as we have discussed- you are planning to make those subs to spawn at different ranges from us, the interval between their spawning and their joining the attack could greatly vary. With this in mind, I would prefer having individual U-boats signaling their presence just before they reach waypoint 1.

If BdU could also inform us on the number of dipatched U-boats with its 1st message, we would have all the information we need. :up:

The messaging system will work as it currently does: when you send in a contact report Bdu will determine if they will honor your report. If they honor it they will send out a reply within an hour. As far as letting you know how many subs I'll have to figure out how to add formatting using the game provided functions.

Now when each sub spawns it will also send out a radio message to you saying "Hey, I'm here!"

When each sub starts following waypoint 2 (heading back to where it came from) it will send you a radio message saying "Hey, I'm bugging out!"

[gap]

The messaging system will work as it currently does: when you send in a contact report Bdu will determine if they will honor your report. If they honor it they will send out a reply within an hour.

Okay :up:
For increasing variety maybe you could also give B.d.U. a little probability of answering just for letting you know that your request had been denied :hmm2:


As far as letting you know how many subs I'll have to figure out how to add formatting using the game provided functions.

Yes, we have already discussed it :up:


Now when each sub spawns it will also send out a radio message to you saying "Hey, I'm here!"

What's its use? I don't see the reason for them to inform us that they have been spawned, since:

a) BdU has already informed us that U-boats had been dispatched to our position;
b) In real life they would have started their passages toward us shortly after receiving the command by BdU, or they wouldn't have done it at all (if they were evading an attack, if they were attacking another convoy, etc);
c) If you accepted my idea to make them to spawn more or less at once (for avoiding that the last spawned subs get our updated position with no need of us sending status reports every so often), we will get in a short while x similar messages that will add little information to what we already know. :yep:

The only use I could see for those messages would be if only they could give us an extimated arrival time for each unit based on its distance from us. Anyway I would rather move them to when each sub is about to reach waipont 1, because it is only by then that real action will start, and it would be logical for a soldier informing his command and his comrades that he is already there and that he is taking position in the battlefield.

Do you want us to mistake our reinforcements for enemy subs? Don't forget that some of us are playing with no map contacts, no external cam and with your real navigation enabled. We are total blinds and we will be relying on the messages you will be passing to us for coordinating with our comrades the best we can :salute: :D


When each sub starts following waypoint 2 (heading back to where it came from) it will send you a radio message saying "Hey, I'm bugging out!"

:up:

[9thinfSword]

Generic Patcher v1.0.70.0 available here: http://www.mediafire.com/?th33p6njaxilh1t


bad download link:dead: its says...



Invalid or Deleted File.

The key you provided for file download was invalid. This is usually caused because the file is no longer stored on Mediafire. This occurs when the file is removed by the originating user or Mediafire.

If you believe you have reached this page in error, please submit a ticket (http://www.mediafire.com/support/submit_ticket.php).
Click here to view our help resources (http://support.mediafire.com/index.php?/Knowledgebase/List)

[Cybermat47]

Hey, does sending regular contact reports increase the chances of getting a wolfpack and/or the number of boats?

[TheDarkWraith]

Generic Patcher v1.0.70.0 available here: http://www.mediafire.com/?th33p6njaxilh1t

bad download link:dead: its says...

Link at post #1 updated with v1.0.71.0 :up:

[THE_MASK]

What mods do i need to enable in the MODS folder found in the TDW_GenericPatcher . thanks .

[TheDarkWraith]

What mods do i need to enable in the MODS folder found in the TDW_GenericPatcher . thanks .

None. They are there for testing purposes.

[THE_MASK]

None. They are there for testing purposes.Whoops , ok thanks .

[Kalleblom]

Here is version 1.0.71.0: http://www.mediafire.com/?suulknbpwwr3bg8

Removed the hard coded messages from my data section. Replaced them with menu.txt entries. 5 random Bdu responses are now possible when you send in a contact report.

You will have to edit your menu.txt file and make the following changes:
...


By using menu.txt entries this allows other users to translate these messages into their own language (or totally change them to whatever they want).

:salute: TDW,

:timeout: Confusing, have to improve my knowledge of english.

maybe a little bit stupid question I have there still:

Can i edit the menu.txt of ruby´s "deutschmod" and put this mod at last in my list? Or must i translate the menu text manual after enabling the patch.

At the moment i understand the menu.txt will be updated in the future by the patcher, so my thought is when i have to translate so the game and the patched subs work as they should.

Sorry for this questions, with better english i think i can solve it by myself, but googlenglish is a little bit puzzling. :O:

[SilentOtto]

SilentOtto ,have you not forgot to apply the UBI 1.2 patch after your new install :06:

No, that is not the problem, since I can still use patcher 1.0.60. I didn't try the next ones until 1.0.69, and that's where my problems started, also with 70 and 71. I know it should be something with linux compatibility (you can't run .NET 3.5 under linux).

[SilentOtto]

The only thing different would be I'm compiling for any cpu (can be x64 or x32). Before I was restricting the app to a 32bit app only :hmmm:

Do you think this can cause some new library or other component to be "pulled" so the needed version is increased to 3.5? I have been testing, with fresh SH5.* files, and I can assure you something is different, I get the same exact response with 0.69. 0.70 and 0.71, while 0.60 and lower work perfect as they always did.

Hope you have some time for me among all these new awesome stuff! :up:

[Burstar]

First off. I take a break for a month and TDW goes "by the way... I just doubled the awesomeness of SH5". Wolfpacks? seriously! Thanks again TDW for all your hard work! :rock:

While you are working on radio messages I'm wondering if something related is possible:

Is there a way to remove kill confirmations, or at least delay the 'ship sunk' message long enough that there is doubt as to your success? Knowing a ship is 'sunk' while its above the water is a major immersion breaker for me. I don't think this has been addressed elsewhere, but if it has please someone let me know :)

[Tonci87]

First off. I take a break for a month and TDW goes "by the way... I just doubled the awesomeness of SH5". Wolfpacks? seriously! Thanks again TDW for all your hard work! :rock:

While you are working on radio messages I'm wondering if something related is possible:

Is there a way to remove kill confirmations, or at least delay the 'ship sunk' message long enough that there is doubt as to your success? Knowing a ship is 'sunk' while its above the water is a major immersion breaker for me. I don't think this has been addressed elsewhere, but if it has please someone let me know :)

Bad Idea. The message is transmitted when the crew abandons ship. You can even see that if you use a lifeboat mod^^

[blkdimnd]

Here is version 1.0.71.0: http://www.mediafire.com/?suulknbpwwr3bg8

Removed the hard coded messages from my data section. Replaced them with menu.txt entries. 5 random Bdu responses are now possible when you send in a contact report.

You will have to edit your menu.txt file and make the following changes:

this is found at the beginning of the file:
MaxStrings=11100

Add these to the very end of the file:
; Contact report wolfpack patch
11000=Dispatching available submarines to your patrol area|Remain undetected and in a favorable position|Send status reports| |Bdu
11001=All available submarines have been dispatched to your patrol area
11002=Submarines in your area have received instructions to join your attack|Stay in front of contact/convoy, remain undetected, and send regular status reports| | |B.d.u
11003=Remain undetected and continue following contact/convoy|Available submarines are heading to your patrol area
11004=Attain favorable position and shadow contact/convoy until reinforcements arrive

When I update the patcher app it will add/check these entries automatically for you :up:

If you get this response from Bdu in English:
Shadow contact/convoy and remain undetected

Then you screwed up somewhere.

By using menu.txt entries this allows other users to translate these messages into their own language (or totally change them to whatever they want).

Well I've been gone from SH5 for about 6 months, and am astounded by the progress of the mods!! :yeah:

Great job DarkWraith! :up:

Being gone for solong, I have forgotten a few things, where is the "menu.txt" file located? And do I still need to make the above changes if I want the messages, or does the current patcher take care of everything?

Thanks