A few new ideas

derstosstrupp · 04-10-25, 09:48 AM

Quote:

Originally Posted by Fidd

Interesting. I was trying to find a mechanism whereby at silent running (creep mode) the use of planes and rudder could differ from normal, if indeed the electric motors driving the plane and rudder movements could be picked up on ASDIC. Do you see any broadly realistic ways that the use of creep-mode could cause? (Such as it preventing assisted movement via electric motor).

ASDIC won’t pick this up (that is active sonar), but the escort’s hydrophones would. Both the rudder and hydroplane motors themselves as well as the braking relays.

Creep mode within the context of the switch on the switchboard currently works as it did in real life, it prevents the clacking of the starting relay within the switchboard itself while the e-motor is in the lowest speed configuration. It does this by keeping the holding coil energized that actuated the relay that shorted the starting resistor and thus kept the resistor shorted while creep was on. Normally, the starting resistor was only in the circuit for about two seconds when switching, by a timed relay, then shorted after this time as the motor had then built up sufficient CEMF to mitigate armature current. On starting or switching, armature current can climb tremendously high because of the momentary lack of CEMF and so resistance is needed for a short time.

But, because of the low armature current in the lowest speed configuration, that is, a 55 V drop in series across both armatures and 110 V from the batteries in parallel, the starting resistor could be ignored, and this was taken advantage of with the creep setting so the relay didn’t make noise.

The next logical step for the developers would be to make this relay clacking audible to escorts. So I don’t think anything needs to change with regard to that switch, it would just be an AI thing.

Now, regarding the rudder and hydroplane relays, the only way to make that stop, or the motor sound stop, is of course to switch to manual, and so that would also be an AI change. Nothing needs to change with the creep mode switch though. That works as it should, and is unrelated to the rudder and hydroplane motors.

Fidd · 04-10-25, 10:19 AM

Thankyou for clarifying all that. I did know the difference between ASDIC and Hydrophone but was tired when I wrote that and meant one but typed the other! I broadly understand the function of the start resistor, though not quite to the degree you do, and also realise that the "clack" was readily detectable on hydrophones as a distinct sound. So making that sound detectable by AI and human operators of escort hydrophones, would be a reasonable addition. The next thing to explore, arguably, is to what extent - if any - escort hydrophones were able to establish any directionality to heard sounds, as opposed to merely establishing that there's a uboat within ear-shot as it were... The notion of electric 'planes and rudder motors being audible on hydrophones, is interesting, as it could reasonably be inferred from that the uboat is changing depth, leading to an estimate being made that the uboat is descending or rising...which has implications for the depth fusing of a pattern of DC's. Lots of interesting stuff there I think!

Quote:

Originally Posted by derstosstrupp

ASDIC won’t pick this up (that is active sonar), but the escort’s hydrophones would. Both the rudder and hydroplane motors themselves as well as the braking relays.

Creep mode within the context of the switch on the switchboard currently works as it did in real life, it prevents the clacking of the starting relay within the switchboard itself while the e-motor is in the lowest speed configuration. It does this by keeping the holding coil energized that actuated the relay that shorted the starting resistor and thus kept the resistor shorted while creep was on. Normally, the starting resistor was only in the circuit for about two seconds when switching, by a timed relay, then shorted after this time as the motor had then built up sufficient CEMF to mitigate armature current. On starting or switching, armature current can climb tremendously high because of the momentary lack of CEMF and so resistance is needed for a short time.

But, because of the low armature current in the lowest speed configuration, that is, a 55 V drop in series across both armatures and 110 V from the batteries in parallel, the starting resistor could be ignored, and this was taken advantage of with the creep setting so the relay didn’t make noise.

The next logical step for the developers would be to make this relay clacking audible to escorts. So I don’t think anything needs to change with regard to that switch, it would just be an AI thing.

Now, regarding the rudder and hydroplane relays, the only way to make that stop, or the motor sound stop, is of course to switch to manual, and so that would also be an AI change. Nothing needs to change with the creep mode switch though. That works as it should, and is unrelated to the rudder and hydroplane motors.

Fidd · 04-12-25, 01:11 PM

206. Thoughts on campaign mode time acceleration.

I've no idea what the current plans are for this, but I gather time-compression may come to pass in a similar fashion to how SH3 used to handle this. All time compression runs on the same basis, that you can accelerate time up until a period before something else happens. There are a number of events that could cause time acceleration to cease. After a conversation over the diesels with Hoagie on this topic, we established some possible principles which are I think worthwhile considering:

Events that should/could cause time compression to cease:
Aircraft in the area
Daily fuel tank needs to be refuelled from saddle tanks
Entering an area where within a period of time, a cvy can be heard on hydrophones
Entering an area where within a period of time, a cvy or other uboat may be seen
Receiving an encrypted message from BDU, containing updates on cvy position
Receiving a radio message from another boat to you
Receiving a radio message from another boat to all stations
A change in the weather, wind-speed, direction and sea-state.
Exhausting the battery to less than 2kah
Exhausting air to 70 kg/cm3
Coming within radar range of an escort or aircraft.
Proximity to land, or port.
Proximity to a mined area.
Arrival at a waypoint
Occurrence of a pre-set RL time. (eg the start of a routine play session)
Radar receiver (Naxos/Metox) going off.
The onset of dawn or dusk.
A particular pre-set Wolfpack time of day. (to avoid being presented with too many, or any, daylight attacks)

The first principle we think is important, is that there's a delay before whatever the cause of the time compression occurs, and the event arises. This would allow the captain to direct players to the bridge to watch, for example, for aircraft, rather than immediately knowing that aircraft are in visual range. This means that until the cause of a time compression cessation (TCC) there's uncertainty as to how to react. In other words because it could be any number of things, one of which is aircraft, immediately diving because of the immediate approach of aircraft is no longer beneficial. The TCC might be caused by a need to refill the daily tank, but then have an aircraft turn up 12 minutes later and CD when spotted. This would mean that merely because a TCC has occurred, you can neither infer, nor exclude, the arrival of a different or additional threats.

So by not having TCC occur at the instant something comes into range may help to improve game-play, as well as provide content in terms of determining WHY it is that a TCC has arisen, which may require a few minutes - 5-20? - to arise, or, may even arise because of more than 1 reason.

SH3 time compression would either reduce to 1:1, or, a multiplier according to the nature of the cause. I strongly advise that we do not emulate that, as it gives away too much about the cause of the TCC too quickly?

Consideration could be made, at a lobby level, to exclude some causes of TCC, and exclude some threats - eg aircraft, in order that current play styles - eg the Frost game - can be played as the usual 3 hour standalone game without being troubled by new threats - such as aircraft/mines/weather changes and so forth, so as not to alter the character of those games, should their players not wish to play the campaign game as such.

Thought should be given to "house-keeping tasks" that can provide content for ordinary crew - and captains, to lessen the incidence of prolonged periods of not much happening, and the character of a play session. Current examples of this are the general lack of "stuff to do" for the Dive Officer during parallel attacks, or the engine room crew when at a steady speed for prolonged periods. In other words, just because a TCC has occurred for one reason, does not mean, with a little imagination, that the bulk of the crew are idle for the interval in which TCC is occurring. It could be used for:

Recharging
Filling the daily tank
Loading torpedoes from underfloor stowage
Loading torpedoes from outside stowage (through the required loading hatch) to a tube or the internal under-floor stowage - thus creating a risk of being caught unable to dive if any aircraft arrives!
Navigation changes from BDU messages or those from another uboat(s).
Use of Enigma to encrypt/decrypt messages
Unloading/reloading torpedoes if space permits.
Keeping a visual watch/manning flak.

The aim of such tasks within the campaign game, being to offer the possibility of more varied gameplay, rather than the currently entirely predictable typical 3 hour game of 2 x parallel attacks, and 1 "inside" attack. In particular it should make discovering the convoy the effort of some period of time, possibly over more than 1 play session, involving much more content for the navigator and radio, whilst not precluding the current sorts of games. By not having the cause of a TCC being immediately obvious, it'll still require effort from the rest of the crew to cover the possibility of, for example an aircraft, or, a Hunter-killer group heaving over the horizon!

In effect, TCC's will allow the campaign game to be played on an ongoing basis, with periods of action or tasks to be done, without unGodly amounts of time being spent having your ears hammered by the noise of the diesels, or staring at un-moving gauges!

The next issue is how to handle a TCC when the players are unavailable to play, ie the boat is unmanned, but the cause of a TCC has arisen. The answer may be to have all games be paused at the close of play of a RLevening, with time-compression only being applied when those players launch their boat at the new play-start. As the convoy - and other items will have moved in relation to the position/course/speed etc the time-compression can THEN be applied. So all play sessions need to start at x1 time compression, to give time for the players to assess incoming or queued messages concerning cvy positions/headings/time of observation etc. Once they have adjusted their heading and other navigational or speed parameters, they can seek to compress time in transit until they catch up with the convoy's real time position.

Another wrinkle that will need to be addressed, is what happens if a boat were to submerge and/or stop ahead of the convoy, but so much RL time passes that the unmanned boat becomes detectable. To my mind, if an unmanned boat gets within a certain range of a cvy, it should be randomly placed astern, or the side of, said convoy at a range in order that it can persist within the gameworld but not be threatened, if that boat has long intervals between being manned - eg those who play once a RL week.

This also suggests that instead of having U96, 552, 307 etc, there will be the need, at campaign start, to assign a crew to a numbered u-boat, and then on a given play-session, players can elect to choose a uboat that their captain commenced, regardless of which boats the crew belong to. Only the captain would be tied to a specific boat. This might be necessary to allow different crews to form under a particular captain for a given play session as RL considerations and time-zones will not necessarily permit the same crew to play the same boat throughout the week.

There will also be a need for updates concerning a cvy's status at any given instant, so that as far as practicable, captains can avoid setting a long period of time compression, only to arrive near the convoy the following RL week, only to find the cvy has been entirely sunk already! This implies that may need to be more than 1 convoy being tracked within an area, so that captains can use time compression to approach the most pre-possessing cvy.

This is just the beginning of considering VERY complex game-mechanic, and I'm sure I've failed to consider some potential "gotchas" with time-compression, and how it bolts together with TCC and regular times of play etc. I'd really be interested to read comments from the devs, or players, who can foresee stuff I've missed or failed to address. I do not envy the devs making time compression work! How playable escorts fit into all this will also need to be addressed.

Fidd · 04-14-25, 01:05 PM

207. A very minor irritation taking screenshots.

It would be nice if the central-cursor could be suppressed when taking a screenshot, either with the F12 button, or the "print screen" method. The reason for this is we can then be spared the need to edit out the little white dot manually with a paint program.

It occurs to me there may be several ways of achieving this. One would be to add a "hide cursor" hot button, so we can lose the cursor just prior to taking the screen-shot. Another might be to hide the cursor if there is any mouse-movement above a thresh-hold value, ideally with a slider, so players can set it to a preferred value.

If it's simple to achieve, this would be a cool improvement.

This would also be very useful when recording game-footage without the cursor being in view. With this in mind, a hot-key to suppress the visible cursor - and bring it back - would seem to be the better solution?

Fidd · 04-15-25, 10:10 AM

208. Side view of uboat in bunker

The rather sprawling and informal, and decidedly unmilitary appearance of avatars in the bunker could use some improvement and extra functionality I think.

The 40 or so sailors could be drawn up in formation on the aft casing, and the officers and senior NCO positions (which we usually play), plus the captain, can be forward of the deck-gun. Icons and positions should alternate along the line, above and below each player. It would be a bloody good feature if players could select what role they wish to play, with the added feature of the captain being able to "accept all, "accept some" or "do manually". If he accepts some or all of the position requests, then those players are automatically given the permissions when they spawn in. If a player leaves the boat or server, then his permission if cancelled. The above would be bloody useful in getting games moving more quickly when there are 3 or 4 boats. It'd enable whoever is organising crew to very quickly see which boat is short of a player for a particular role, as well as allowing unassigned players to readily spot a boat that requires someone to perform a role that he or she wishes to play.

It seems to me that the current UI is "prettier", but functionally it seems not to have conferred much if anything to organising a load of players for a larger event? Getting rid of, or greatly diminishing the echo of the bunker, would be very welcome too. When the players prefer to organise play on Discord, rather than use in-game voice because of the bloody echo effect, something is clearly in need of change?

04-12-25, 01:11 PM	#3
Fidd Captain Join Date: Apr 2005 Location: Blighty! Posts: 542 Downloads: 10 Uploads: 0	206. Thoughts on campaign mode time acceleration. I've no idea what the current plans are for this, but I gather time-compression may come to pass in a similar fashion to how SH3 used to handle this. All time compression runs on the same basis, that you can accelerate time up until a period before something else happens. There are a number of events that could cause time acceleration to cease. After a conversation over the diesels with Hoagie on this topic, we established some possible principles which are I think worthwhile considering: Events that should/could cause time compression to cease: Aircraft in the area Daily fuel tank needs to be refuelled from saddle tanks Entering an area where within a period of time, a cvy can be heard on hydrophones Entering an area where within a period of time, a cvy or other uboat may be seen Receiving an encrypted message from BDU, containing updates on cvy position Receiving a radio message from another boat to you Receiving a radio message from another boat to all stations A change in the weather, wind-speed, direction and sea-state. Exhausting the battery to less than 2kah Exhausting air to 70 kg/cm3 Coming within radar range of an escort or aircraft. Proximity to land, or port. Proximity to a mined area. Arrival at a waypoint Occurrence of a pre-set RL time. (eg the start of a routine play session) Radar receiver (Naxos/Metox) going off. The onset of dawn or dusk. A particular pre-set Wolfpack time of day. (to avoid being presented with too many, or any, daylight attacks) The first principle we think is important, is that there's a delay before whatever the cause of the time compression occurs, and the event arises. This would allow the captain to direct players to the bridge to watch, for example, for aircraft, rather than immediately knowing that aircraft are in visual range. This means that until the cause of a time compression cessation (TCC) there's uncertainty as to how to react. In other words because it could be any number of things, one of which is aircraft, immediately diving because of the immediate approach of aircraft is no longer beneficial. The TCC might be caused by a need to refill the daily tank, but then have an aircraft turn up 12 minutes later and CD when spotted. This would mean that merely because a TCC has occurred, you can neither infer, nor exclude, the arrival of a different or additional threats. So by not having TCC occur at the instant something comes into range may help to improve game-play, as well as provide content in terms of determining WHY it is that a TCC has arisen, which may require a few minutes - 5-20? - to arise, or, may even arise because of more than 1 reason. SH3 time compression would either reduce to 1:1, or, a multiplier according to the nature of the cause. I strongly advise that we do not emulate that, as it gives away too much about the cause of the TCC too quickly? Consideration could be made, at a lobby level, to exclude some causes of TCC, and exclude some threats - eg aircraft, in order that current play styles - eg the Frost game - can be played as the usual 3 hour standalone game without being troubled by new threats - such as aircraft/mines/weather changes and so forth, so as not to alter the character of those games, should their players not wish to play the campaign game as such. Thought should be given to "house-keeping tasks" that can provide content for ordinary crew - and captains, to lessen the incidence of prolonged periods of not much happening, and the character of a play session. Current examples of this are the general lack of "stuff to do" for the Dive Officer during parallel attacks, or the engine room crew when at a steady speed for prolonged periods. In other words, just because a TCC has occurred for one reason, does not mean, with a little imagination, that the bulk of the crew are idle for the interval in which TCC is occurring. It could be used for: Recharging Filling the daily tank Loading torpedoes from underfloor stowage Loading torpedoes from outside stowage (through the required loading hatch) to a tube or the internal under-floor stowage - thus creating a risk of being caught unable to dive if any aircraft arrives! Navigation changes from BDU messages or those from another uboat(s). Use of Enigma to encrypt/decrypt messages Unloading/reloading torpedoes if space permits. Keeping a visual watch/manning flak. The aim of such tasks within the campaign game, being to offer the possibility of more varied gameplay, rather than the currently entirely predictable typical 3 hour game of 2 x parallel attacks, and 1 "inside" attack. In particular it should make discovering the convoy the effort of some period of time, possibly over more than 1 play session, *involving much more content for the navigator and radio, whilst not precluding the current sorts of games. By not having the cause of a TCC being immediately obvious, it'll still require effort from the rest of the crew to cover the possibility* of, for example an aircraft, or, a Hunter-killer group heaving over the horizon! In effect, TCC's will allow the campaign game to be played on an ongoing basis, with periods of action or tasks to be done, without unGodly amounts of time being spent having your ears hammered by the noise of the diesels, or staring at un-moving gauges! The next issue is how to handle a TCC when the players are unavailable to play, ie the boat is unmanned, but the cause of a TCC has arisen. The answer may be to have all games be paused at the close of play of a RLevening, with time-compression only being applied when those players launch their boat at the new play-start. As the convoy - and other items will have moved in relation to the position/course/speed etc the time-compression can THEN be applied. So all play sessions need to start at x1 time compression, to give time for the players to assess incoming or queued messages concerning cvy positions/headings/time of observation etc. Once they have adjusted their heading and other navigational or speed parameters, they can seek to compress time in transit until they catch up with the convoy's real time position. Another wrinkle that will need to be addressed, is what happens if a boat were to submerge and/or stop ahead of the convoy, but so much RL time passes that the unmanned boat becomes detectable. To my mind, if an *unmanned* boat gets within a certain range of a cvy, it should be randomly placed astern, or the side of, said convoy at a range in order that it can persist within the gameworld but not be threatened, if that boat has long intervals between being manned - eg those who play once a RL week. This also suggests that instead of having U96, 552, 307 etc, there will be the need, at campaign start, to assign a crew to a numbered u-boat, and then on a given play-session, players can elect to choose a uboat that their captain commenced, regardless of which boats the crew belong to. Only the captain would be tied to a specific boat. This might be necessary to allow different crews to form under a particular captain for a given play session as RL considerations and time-zones will not necessarily permit the same crew to play the same boat throughout the week. There will also be a need for updates concerning a cvy's status at any given instant, so that as far as practicable, captains can avoid setting a long period of time compression, only to arrive near the convoy the following RL week, only to find the cvy has been entirely sunk already! This implies that may need to be more than 1 convoy being tracked within an area, so that captains can use time compression to approach the most pre-possessing cvy. This is just the beginning of considering VERY complex game-mechanic, and I'm sure I've failed to consider some potential "gotchas" with time-compression, and how it bolts together with TCC and regular times of play etc. I'd really be interested to read comments from the devs, or players, who can foresee stuff I've missed or failed to address. I do not envy the devs making time compression work! How playable escorts fit into all this will also need to be addressed. Last edited by Fidd; 04-12-25 at 09:49 PM.

04-14-25, 01:05 PM	#4
Fidd Captain Join Date: Apr 2005 Location: Blighty! Posts: 542 Downloads: 10 Uploads: 0	207. A very minor irritation taking screenshots. It would be nice if the central-cursor could be suppressed when taking a screenshot, either with the F12 button, or the "print screen" method. The reason for this is we can then be spared the need to edit out the little white dot manually with a paint program. It occurs to me there may be several ways of achieving this. One would be to add a "hide cursor" hot button, so we can lose the cursor just prior to taking the screen-shot. Another might be to hide the cursor if there is any mouse-movement above a thresh-hold value, ideally with a slider, so players can set it to a preferred value. If it's simple to achieve, this would be a cool improvement. This would also be very useful when recording game-footage without the cursor being in view. With this in mind, a hot-key to suppress the visible cursor - and bring it back - would seem to be the better solution? Last edited by Fidd; 04-15-25 at 09:54 AM. Reason: addition of final paragraph

04-15-25, 10:10 AM	#5
Fidd Captain Join Date: Apr 2005 Location: Blighty! Posts: 542 Downloads: 10 Uploads: 0	208. Side view of uboat in bunker The rather sprawling and informal, and decidedly unmilitary appearance of avatars in the bunker could use some improvement and extra functionality I think. The 40 or so sailors could be drawn up in formation on the aft casing, and the officers and senior NCO positions (which we usually play), plus the captain, can be forward of the deck-gun. Icons and positions should alternate along the line, above and below each player. It would be a bloody good feature if players could select what role they wish to play, with the added feature of the captain being able to "accept all, "accept some" or "do manually". If he accepts some or all of the position requests, then those players are automatically given the permissions when they spawn in. If a player leaves the boat or server, then his permission if cancelled. The above would be bloody useful in getting games moving more quickly when there are 3 or 4 boats. It'd enable whoever is organising crew to very quickly see which boat is short of a player for a particular role, as well as allowing unassigned players to readily spot a boat that requires someone to perform a role that he or she wishes to play. It seems to me that the current UI is "prettier", but functionally it seems not to have conferred much if anything to organising a load of players for a larger event? Getting rid of, or greatly diminishing the echo of the bunker, would be very welcome too. When the players prefer to organise play on Discord, rather than use in-game voice because of the bloody echo effect, something is clearly in need of change?