A few new ideas

[Fidd]

201. Variable technology introduction dates.

At some point this game may well see the introduction of "hedgehogs", ship and aircraft borne radar, centimetric and millimetric radars, depth charges capable of being fused deeper than early war DC's, Lut and Fat torpedoes, both steam and electric, and acoustic torpedoes and "Foxer" for escorts.

All of these will have nominal entry into service dates. In the campaign-game, I think it would be good if these dates, whatever they may be, were fudged +/- a month or two, so that there is uncertainty, as experienced gamers in what precise technology the enemy players may be equipped with. Another possible avenue would be for only a few, escorts/uboats getting new kit initially, which with passage of time become more generally available.

This has several useful results. The first is that players won't be able to argue about an in-service date for a particular item, as the date is somewhat fudged and incremental. It'll mean captains of both escorts and u-boats will be in the position of suspecting a new technology may be in use, but won't know for sure, leading to variety of outcome for a game. Finally it'll allow the devs, if needbe, to apply some deliberate balancing in terms of capability, to preserve the game as a competitive game-play between the two sides, without getting into arguments about which week-end in April '42 a particular sensor, weapon or other device, anti-asdic coating, weapon etc was introduced....

[Fidd]

202. Hand-holds and Ragdoll physics when under DC attack or in rough seas.

Imagine of the effect of a non-lethal DC explosion was both very much louder, and suppressed the ability to give orders verbally, if instead of the "fire-flies" DC effect, there was additionally marked disturbance in pitch/roll/yaw and buoyancy, with a camera shake that has directionality relative to where the DC has gone off, rendering the ability to read instruments very difficult (if not destroying some of them!), Now combine this with a series of possible items in the uboat which players can use as hand-holds to keep themselves steady (this also holding true in rough seas). Finally, imagine a ragdoll physics model where players can be knocked off their feet, possibly injured, if they are not adjacent to one of these hand-holds, with faster recovery to their station if they are, and longer recovery if they are not....

Seated players would be fairly immune to the ragdoll effect, but those on their feet, away from a hand-hold, may have a rougher time of it....

[Fidd]

203. Better attenuation in radio and hydrophone rooms with doors shut, and microphone switches and lamps for "voice tubes" to tower.

I've had a few goes on the hydrophones, and have noticed that the chatter from voices in the control room is relatively loud relative to the hydrophone sounds, and if the sound is carried via the tower "electric voice-tube" to radio/hydrophone compartment is particularly loud. I think it very likely that in order to use those electric voice tubes, a mic button had to be used at both ends of the line. Similar to the way the telephones operate. This would remove a lot of the passively heard sounds, giving the radio and hydrophone operators a quieter working environment. I think it's also likely that there was some form of signalling lamp that could be employed to tell the radioman/hydrophone operator that the tower is trying to contact them, before two way speech is conducted.

Such an arrangement would enable either role to be less distracted by speech in the tower and control room, when using morse or simple radio, when decrypting or encrypting signals on Enigma, or whilst taking hydrophone readings. With the doors open, speech would be possible with both the control room and tower. Another wrinkle could be use of the head-phones to suppress exterior noises, including voice tubes, with the additional ability to put the output of the hydrophones onto electric speakers in the tower and control room?

Another way of doing this, would be for the hydrophone operator when he puts on his headset, to suppress exterior sounds, and when he doesn't have his head-set on, then, as now, he hears a mixture of hydrophone sound, and the out-put of the hydrophone is played, at a volume audible in radio compartments, control-room and tower, from the speaker above the helm position, and, (if fitted) a speaker in the tower? This would allow most of the control room to hear the hydrophone, but also permit the hydrophone operator to better listen to noises untroubled by chatter in the control room. It might also serve, when the hydrophone is on, to suppress non-essential chatter in the control room, which would add a little immersion.

[Fidd]

204. The reasons why PVP needs to have allied players able to drop into Bitterns, Tribals AND Flower class corvettes.

It seems to me that the PVP aspect of playable escorts is going to be most important in two respects:

1. To allow for more varied outcomes of games, which helps in player retention.
2. To make the current AI less bovine in its stupidity. (such as abandoning a firm asdic contact because another uboat 5 miles away fires its deck-gun).

There are other benefits:

3. It introduces the psychological aspect to the game, where as a uboat crewman you know a real player is tormenting you by ongoing asdic searches and attacks, or conversely that your crew has possibly outwitted the escort players by breaking out if his clutches and sinking tonnage.

4. It blurs the line between AI and PVP, insofar as you won't know if the escort you see, and which is perhaps pinging, is manned by AI, and therefore pretty predictable, or, if it is player-manned, and therefore potentially more dangerous.

Here's the problem, if the only escorts players can man is the Flower Class Corvette, then any Bittern or Tribal cannot be player manned, meaning that it's behaviour and tenacity of searching is definitely AI driven, and therefore predictable.

As I see it, it would be better if all escort types could be manned, ideally with players being able to drop into, or leave, any ship at will. This would render it much harder to discriminate between a PVP escort, and an AI one. It would also allow for either the nearest - or the fastest - escort to be joined in order to conduct asdic searches, and attacks, or carry out lost-contact asdic searches for longer.

There are a few wrinkles that need to be addressed also:

a) No more 185m and you're safe from asdic or hydrophone, or DC.
b) Convoy de-alerts even if a u-boat is held by an asdic search, IF it's depth is 130m or more. An AI or human PVP escort may continue to hold it on asdic or hydrophones, but a re-alert only happens if the u-boat rises to less than 130m whilst being pinged. A HUGE advantage of this, is that escorts could go quiet, follow the contact at dead slow, without asdic, then turn on it's asdic after the blowing of the MBT's is heard and the uboat ascends above 130m. Greatly improving the "cat and mouse" game. This would also mean that a detected boat over a long period would not cause other players in other undetected boats long delays whilst the detected u-boat is too deep to be a threat.

Naturally any such PVP with all types would require play-testing, but it seems to me that if the playable locations on a u-boat are a gun-sight view from a turret, asdic and hydrophone positions, and helm and Captain (on the bridge), then all of these positions could be generic, aside from the Bridge/helm positions, and possibly the main-armament gun-sight? I do not see it as necessary to render the PVP escorts to the same fidelity, for now, as the u-boats are made. The important aspects are 1-4 above, in particular blurring the perception of an escort being AI driven, or a PVP one, which could greatly increase the risk of an approaching escort being known to be AI driven, or, a human-directed one capable of guile and more potential lethality. This suggests that part of the design is going to need to be able to fettle the AI and player sensors of the escorts, in game set-up so it can be played at a level suitable for those on both sides, or in flotillas where they do not wish to be troubled unduly by PVP escorts.

[Fidd]

205. "Silent mode" (schleighfahrt <sp>?) and hydraulic services.

Currently the silent mode does very little of worth. I understand - but would love confirmation - that when running silent, the noise of hydraulically powered services was quietened by going over to manual control

So the rudder was moved from the e-motor room wheel, and the planes by unassisted movement of the wheels.

So - the current "silent mode" switch could be used as a way of turning off hydraulic motors which powered the periscope, planes and rudder, making turns slower, and changes on pitch attitude via the planes also slower to move (but still controlled from the dive station). But quieter. Some reform of sound effects might be in order, to remove/change some sound effects when silent mode is in effect, to emphasise the change?

[derstosstrupp]

Just to be clear, it’s a common misconception that the rudder and hydroplanes were controlled hydraulically on German submarines. This was only the case later with the XXI. I think the misconception might stem from the fact that US fleet submarines operated this way, but the Germans didn’t do so until much later. The control surfaces were operated electrically, using electric motors, with dynamic braking to stop the control surface relatively quickly (the case for all types except II, which was hand-powered, and XXI as mentioned, although hydraulic steering was attempted as a test on at least 1 VII as we have a Skizze of such a system for one boat). I might add as an aside that on the Type II there was no hydraulic system at all, even for the periscopes. All electric, and also the case for VIIA.

Inch for inch, moving a control surface electrically is noisier than hydraulically (assuming sufficient fluid pressure and the hydraulic pumps don’t need to recharge the hydraulic accumulators), so this suggestion still holds, and is good, just wanted to point out the misconception. The electric motors themselves made noise, as well as the magnetic controller relays that alternately switched in the control and dynamic braking circuits.

[Raf1394]

Thanks for info. A lot of those things are interesting to know.
Gaming vs real life.

[Fidd]

Many thanks indeed. It's almost a pity that's the case. Do you know if the planes and rudder could be mechanically moved in the event of failure of the electric motor or battery? Looks as if #205 will have to be binned! The type XX1's hydraulic controls may have occurred because of shortages of copper in Germany at the time - which also did for Porche's petrol-electric drives for his design for what became the Tiger II.

Originally Posted by derstosstrupp

Just to be clear, it’s a common misconception that the rudder and hydroplanes were controlled hydraulically on German submarines. This was only the case later with the XXI. I think the misconception might stem from the fact that US fleet submarines operated this way, but the Germans didn’t do so until much later. The control surfaces were operated electrically, using electric motors, with dynamic braking to stop the control surface relatively quickly (the case for all types except II, which was hand-powered, and XXI as mentioned, although hydraulic steering was attempted as a test on at least 1 VII as we have a Skizze of such a system for one boat). I might add as an aside that on the Type II there was no hydraulic system at all, even for the periscopes. All electric, and also the case for VIIA.

Inch for inch, moving a control surface electrically is noisier than hydraulically (assuming sufficient fluid pressure and the hydraulic pumps don’t need to recharge the hydraulic accumulators), so this suggestion still holds, and is good, just wanted to point out the misconception. The electric motors themselves made noise, as well as the magnetic controller relays that alternately switched in the control and dynamic braking circuits.

[derstosstrupp]

Yessir they could.

In the case of the hydroplanes, behind the BBC unit and wheel at each plane station was an air lever. Pulling it sent a burst of low-pressure air to the respective motor unit in the respective torpedo rooms (where the hydroplane motors are) that pushed a piston that disconnected the respective motor from the shaft - remote disengaging in other words. The air only worked one way on the piston so reengaging had to be done at the motor itself. So pull air lever, then unlock the wheel and then the planesman had manual control of his set of planes.

Similar situation with the rudder, although that disengaging was done only by a lever on the motor itself with no remote option. In that case, pull the lever, and then pull out the manual helm from its stowed position (it is in the stowed position in Wolfpack currently).

The hydroplane and rudder electric motors and associated relay boxes were almost identical, as was the mechanism itself to disengage or engage the motor drive, it’s just that the hydroplanes had the additional air piston option to be able to quickly disengage from the control room.

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

[derstosstrupp]

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]

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!

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]

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]

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]

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?