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

[TheDarkWraith]

Originally Posted by gap

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

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?

[gap]

Originally Posted by TheDarkWraith

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?

I think I've never sent one

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

[TheDarkWraith]

Originally Posted by gap

I think I've never sent one

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

I like it 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

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]

Originally Posted by TheDarkWraith

I like it 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

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?

Originally Posted by TheDarkWraith

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

[TheDarkWraith]

Originally Posted by gap

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

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

[gap]

Originally Posted by TheDarkWraith

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

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

what do you think?

[TheDarkWraith]

Originally Posted by gap

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

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]

Originally Posted by TheDarkWraith

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]

Originally Posted by TheDarkWraith

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

Originally Posted by TheDarkWraith

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.

Originally Posted by TheDarkWraith

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?

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

[gap]

Originally Posted by 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

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

[Trevally.]

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

[Trevally.]

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

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