103. Hissing noise of compressed air in the control-room, any time high-pressure air is being released, no matter the compartment from which the valve is opened. This would help dive-officers realise that there's an open valve somewhere, especially the diesel start valves, which are often missed due to the general noise level, as well as prompting him to reverify all his own valves are closed as appropriate. The noise should possibly be a relatively low frequency version of the usual "hiss" when an air-valve is opened. The reason for creating this noise in the control room, is that that is where a good number of the high-pressure air-cylinders are located.

Consideration could be given to the adding of the port electric compressor, and give this the ability to gain compressed-air even whilst submerged, providing no crew remain in that compartment, and intervening doors are closed. Entering an airless compartment would be possible for very short period of a minute or so, allowing: Compressed air available to blow the bilge, and a partial MBT blow to get the u-boat's hull-valves above the waterline, to in turn open the hull valves (equalising the pressure in compartments) and starting the diesel-powered compressor in the usual fashion. Once this was done, it'd be possible to complete the MBT blow, and get to the surface?

Primarily we need some means other than continuous and unremitting watching of the compressed-air gauge, to tell players that there's a discharge of high pressure air on the boat at that time?

104. Cupboards and contents - and depth-charges.

It might be fun if some items loose in the control-room, or within closed cupboards and lockers elsewhere, were strewn about the deck (floor) in the event of near-misses from DC's. This might be clothing, tins, boots, gas-masks, saucepans, etc, each in a compartment where such items might be found. If items were in plain sight prior to the detonation, eg the chess-board and pieces, or books and folders in the control-room etc, if they vanished to be replaced by the same items now disarrayed...

Closing cupboard or locker doors, or clicking on the debris, would revert such debris to it's former stowed position.

Consideration might be given to adding the noise of some items crashing onto the floor in the immediate aftermath of a DC detonation?

105. Hurricane lamps - or similar portable lamps.

Torches (flash-lights) are useful, but not always very adequate. Seeing the tops of "black +/-" oil valves on the diesels can be very difficult to see when the boat has been damaged and light-bulbs destroyed as torchlight from one's own torch cannot be positioned to cast light on them. It might be handy to have a few "hurricane lamps" or similar larger battery-operated temporary lighting available for use in such situations, which would also serve to give some situational and appearance variety to individual missions where they are used?

I would suggest that they be installable on certain horizontal surfaces of approximately desk height, eg on the tables in the NCO's and Officers mess, the desks in hydrophone or radio room, the small desk area in the diesel-room, or (perhaps) on the floor in the emotor room. Some fairly stark shadows would need to be cast with softening of shadows where remaining lights in other areas cast light on said shadows. I find it hard to believe there was no provision for portable lighting other than individual torches, and would be interested to hear what form such lighting took! (if anyone knows!)

The game is missing the emergency lighting system as well. 8 mounted lamps, battery powered, which kicked on automatically at the loss of the general lighting. The only other option was 8 handheld lamps stored around the boat which is what the game avatars carry.

Do you have a picture of the emergency lighting?

They were red, and powered from their own rechargeable batteries:

https://www.subsim.com/radioroom/pic...ictureid=13404

106. New players voices - who is whom?

It would be helpful in game if there was a means by which when someone speaks, and is audible (with attenuation), that their position on the boat, and their handle appear in text in the top left corner. A simple toggle on/off of this feature should exist. This would be hugely useful on a boat where there are many new voices and one is seeking to differentiate them and determine if it's a given person speaking. Voices from tubes or telephones would likewise shew the name(s) of the people speaking. In order for this not to be an "immersion killer", the default for this would be off, perhaps, but simply toggled on when it'd be useful? EG:

"Dive Officer: Bloggz"

107. Crossing convoys. It would add interest to the game if it were possible - but perhaps not routinely done - to have two convoys, possibly opposite-direction - either coalescing into a large convoy, or, splitting off, or passing each other, to complicate the initial stages of the game, especially where it's not "quick start". So, a picture of the disposition of two bodies of ships would have to be determined by Enigma decrypts, hydrophones and visual contact, with the relative positions and tracks sorted out, and their composition, before the u-boats attack one or both of the two convoys.

If one of the two convoys were purely additional escorts, moving to increase the protection of a convoy ahead, but was mistaken for being a merchant convoy on the hydrophones, then this might create a variety of game situations to deal with, especially if it was a faster "Hunter Killer" group of escorts. Independently settable ASDIC (always on/off) would add to this. For multi-boat games, with a lead-boat, this would present some issues for the commander to deal with as he seeks to piece together observations from the radio and dispose his boats accordingly....

108. Pitch roll and yaw (originally posted as an idea in separate thread)

With the usual caveat that this game is incredible work from such a tiny team, does anyone else think that our U-boats seem to "run on rails" rather than small craft, ill-designed for surface stability tossed hither and yon by a capricious sea?

I'd like to see, in time, more varied dynamic and believable sea-states, both externally, in terms of oscillating periscope views and random and unpredictable heavier than normal wave strikes dousing the bridge watch/sending water down the conning tower if the hatch is opened..

But also internally, so that the crew perhaps have difficulty keeping their footing in heavy weather. Has anyone yet induced sea-sickness in a sea-faring pc game? From my sailing days, a heavy wave was quite a visceral experience, in every sense of the word, it was a hammer-blow of a crash on the hull, followed by everything not screwed down continuing blithely onwards despite the boat being momentarily stopped in its' tracks, which usually included me! So there's lots graphically to play with there, sound, movement of the internal view relative to the viewer, (I always liked the "swinging hams etc" in Sh3) the little lag in keeping yourself upright in the boat as you adjust slightly belatedly to the next impact... Sound effects of sprog crews retching... You could have a ton of fun as a developer, even if the heavier sea-states were infrequent!

(Edit - added thoughts)

The sea-state has lots of interesting ramifications: The deeper the U-boat is at periscope depth, the more stable the boat is compared with being fully surfaced. In the event un-stabilised periscope optics arrive in conjunction with differing sea-states, then it follows that there will be a tactical trade-off between periscope depth attained and accuracy of observations, but also, that the U-boat is going to be more likely to be accidentally partially surfaced if it tries to operate very shallow in a rough sea-state. Conversely, operating at deeper periscope depths will give better accuracy of observations, but more intermittent glimpses of the target owing to the periscope being more frequently submerged.

Furthermore, if "swell" - as opposed to wave action - is also modelled, then the direction of swell can become a tactical factor as to how much pitching or rolling and/or yawing the U-boat and periscope views attain. This means that operating parallel to the swell, one would have lots of roll, but little pitching - optimal for measuring target distance, and perpendicular to the swell one would have little roll, but lots of pitching, better for taking convoy speed observations.

In my view these new wrinkles could give a much wider set of difficulty permutations, and give some needed "re-playability" to the game, where each approach to the convoy, has to be considered in terms of sun-position, sea-state, moon-path, sea-swell and visibility... The sea-state could also confer some advantages - much harder to spot a periscope in a rough sea than a flat-calm...?

109. Crowd-sourced "ship skins"

Many years ago, I was involved in a project called "SAC" which changed the appearance of aircraft in a game called "Air Warrior", at a time when "re-skinning" was by no means a mainstream modding process. This involved taking submissions from the player-base of bitmaps and incorporating them in a program written by G42 to make backups of the original game-files, and to swap in historically correct skins for a particular air-battle, period or theatre. It was basically a fore-runner of JGSME.

This resulted in a very wide range of art-work in a very short time, far beyond what the game's developers could produce.

Is it, or would it be, possible for the artwork used to "skin" ships in game to be modifiable in this way I wonder? (If indeed skins are used at all?)

I think it would greatly improve the diversity in appearance of our convoy ships. Ideally there should be some moderation involved so that "bright luminous pink ships" do not result, and the choice of ship renderings be that of the lobby-owner? It'll be important that everyone sees the same art, so that "see that red-funnelled ship at 056?" actually is seen as a red-funnelled ship by all concerned.

Thoughts?

110. Different AI behaviour for different types of escort.

Or, put another way, a variable amount of patrolling randomly away from a general convoy direction, with escorts capable of higher speeds being those most likely to move further away from the convoys mean course.

Or, put the other way around, corvettes, on the slower end of the spectrum of escort speeds, would tend to hold the same position relative to convoy, not venturing too far from the convoy mean course, thus making their station a safer axis of attack than (say) a "Tribal", which being much faster, would be more likely to swing out of position on a random basis before resuming their usual position.

By giving different AI properties to different types of escort, it would mean that surface attacks from one direction might have to be undertaken at greater range, than an attack towards a different, slower, escort type.

The effect of this would be to make the escort dispositions something that has to be considered when deciding from what range and direction, and whether submerged or surfaced, for an attack. It might also mean that deliberately attacking an escort might be worthwhile...

A further wrinkle might be if the escorts changed their basic disposition about every 2 hours of gameplay, perhaps by having all change their relative poistions to the convoy..... or..... the change in disposition of escort types around the convoy commences after a de-alert.....

111. Intermittent sonar setting, in addition to always on and always off.

We know that ASDIC could only be successfully operated when the returning signal wasn't swamped by engine noise, meaning that it was only of use when "looking" ahead roughly 45 degrees either side of the escort's bow, and below a top speed of circa 18 kts. It's effectiveness was likewise diminished in rough seas.

For our purposes, this means that Bitterns and Corvettes would be able to use ASDIC most of the time, but Tribals could not, if above 18 kts in speed.

This would allow an intermediate setting between "always on" and "always off" whereby the Bitterns and Corvettes were (ASDIC) always on, but the Tribals were only periodically on, if any escort made a hydrophone contact, or, a visual one (which then submerged). Further complexity to added if idea #110 was simulataneously implemented, whereby the Tribals tended to range further away than the other two types (at 36 kts), from their "home" position in relation to the convoy, then searching an area with ASDIC at 18 kts, before racing back at 36 kts to their "home" position. This behaviour would make approaching the convoy with a Tribal between you, and it, more dangerous both surfaced or submerged, as the former could rapidly erode the "safe" distance away from escorts detection at night, or catch the u-boat submerged during the periodic ASDIC phase...

As a lobby-setting (preferably a concealable setting), this would again make the distribution of particular escorts something to take into consideration both in daylight and at night, when approaching a convoy...

112. AI gunnery accuracy proportional to illumination

One of the weaknesses in the game is the very considerable accuracy of enemy gunnery v the (tiny) u-boat, compared with the poor accuracy of the u-boats deck-gun v the (much larger) merchants.

It seems to me that the initial accuracy of enemy guns v a moving u-boat needs to be dialled back considerably, with gradually increasing accuracy over time.

One logical way to do this is to make AI accuracy dependent on the sum of these factors:

Range
Natural light (daylight or moon-light)
Artificial light (held in a search0light or with illumination flares above*
Number of shots fired by the escort or merchant
Number of shots fired by the u-boat (aiding seeing the u-boat)
Expertise of gunner (greater in escorts)
Sea-state
Speed of u-boat
Rate of change of u-boats heading
Visibility (fog)

Not all of these would have an equal effect, however, all would cumulatively affect the probability of a hit on a u-boat. This would mean that a u-boat commander might get a few shots off with a deck-gun before incoming fire becomes so accurate that he's compelled to dive. Whether or not he chooses to employ a desk-gun therefore be driven by an assessment of the factors above. It might be that the conditions allow for it to be tried, or, conversely are deemed to make it took risky. The difference with the current game being that it's not simply a matter of the factors of range and time only.

To what degree given factors affect the escorts ability to fire on a u-boat, and which affect accuracy and by how much, is all open to discussion, but the ability to get a reasonable number of shots off and then scuttle down the tower before diving would be some good content now and again?

113. Viewable interior of u-boat from outside, without pressure-hull etc.

I encountered a bug on the beta today, which shewed me the interior of the entire boat on a black background, unfortunately without being able to pan and tilt etc. It was amazing to see, and seems to me to it would be great to do "deliberately" as it were, but with pan/tilt and zoom as it shews off the structure and all the modelling beautifully!

https://media.discordapp.net/attachm...945020/bug.jpg

114. Periodic high amperage draw for cooker/electric torpedo battery heating/u-boat heating.

Suggestion: Once per game, when surfaced only, the "cook" notifies engine room that the cooker is being used, drawing 50A or so, for say 40 minutes? When electric torpedoes are loaded, a suitable amperage is drawn (Stoss-trupp/Decaf may know the amperage so drawn per torpedo?) and u-boat heating (when dived only) with a modest current draw of circa 40A.

Why? These ancillary loads (as well as those for radio/periscopes/gyroscopes/planes etc, on the battery will make battery-use more critical, as well as making recharging more frequent and more pressing, adding workload for the engine-room crew. The captain might defer some of these. Consideration could be made to extend electric torpedo distance if pre-heating occurs, or, diminish it from current distances if it doesn't. (Subject to what assumptions are made currently).

Lack of heating could cause visible "breath" from avatars, which could also become a visible and atmospheric indicator of "stress" when dived and under DC attack, with a rise in frequency of breath-rate? Lack of u-boat heating could be used to increase condensation-related electrical problems at some point in the future?

Hotel load is a deep subject. Very difficult to quantify. All periscope operation was hydraulic, so no worries there. The ventilators were hardly run at sea except during charging and briefly to ventilate the boat after surfacing, so no worries there. Battery heating is hard to quantify, because the automatic regulator only kicked on when the electrolyte dropped below 30°C. But heating drew about 20 A. Eto Battery charging initially was 30 A, which tapered down to 22 as the torpedo battery cells approached gassing voltage. Hard to quantify. U-boat heating can be considered a non-issue as the electric heaters typically weren’t used on war patrol to save battery. Then there is all the other ancillary equipment on the regulated and unregulated circuits. At one point, back of the envelope, I calculated a hotel load on a typical day of about 200 A. That is also high as it assumes careless all-day use of the ventilators. So maybe cut that in half.

I do really like the idea of equipment drawing current. We have data on pretty much every piece of electrical equipment, so this could be modeled.

There is already a net loss of battery charge with prolonged running on diesels, (obviously without recharging!), but it's a tiny rate, in the rough order of 100Ah, and the rate doesn't seem to vary, except by reducing the brightness of the lighting.

As regards the hydraulics, the safest (least awful!) system would be an electrically-powered hydraulic pump, hydraulic accumulator and hydraulic motor in one place near the driven service, to minimise the length of pressurised hydraulic piping, and thus minimise the risk of a cloud of highly flammable hydraulic fluid in the boat during depth charging.

So it'd expect the hydraulic services to involve an electrical load every time they're used, simply to replenish the hydraulic accumulator.

I'd be interested to know how Jerry did mitigate the risks of using hydraulics.

You are absolutely right. One of two hydraulic pumps could be selected, and, when the oil in the collecting tank got high enough, the pressure in the tank caused an automatic switch to close, which kicked on the pump to pump oil back up into the accumulators. Generally though, the pressure wasn’t allowed to drop to the minimum 48 kg/cm², but was normally pumped up by hand by switching the pump on at 60 to pump it back up to 80.so that the commander always had good hydraulic pressure to operate the scope efficiently. I would be all for implementing some form of the hydraulic system.

115. Thoughts on escort radar implementation....... :ping:

There are a number of players who are somewhat nervous at the prospect of the gameplay ramifications of escorts receiving radar. As I see it, this is something not appropriate for use by AI, but rather one better suited to human interpretation, and the full range of deficiencies early radar possessed.

Early radar was tempramental, and when it did work, suffered problems in rougher sea-states where the escort was pitching and rolling, as any time the radar-head was tilted down, it caused back-scatter from the surface - effectively false returns, and viewed over a period of time, it meant a considerable skill was needed on the part of the operator, to spot an actual consistent return on a given bearing amongst the false returns, if the escort was in rougher water. It is forecastable that AI interpreting such returns is either going to be far too capable and recognising a return as a u-boat, or, will be hopeless at it. A happy medium in AI's ability in almost any situation is usually not realised in game. So, conclusion one is that escorts should be playable before radar is implemented, and it be usable only by human players.

Early radar had an oscilloscope presentation, rather than the PPI (Plan position indicator) we know today. In other words as the radar-head rotated through a bearing, assuming the radar head was not pointing at the sky or the sea surface around the escort, then an intermittent return of the u-boat would occurr, usually with some amount of clutter from the sea surface. The amplitude of the spike in the return would be a function of the strength of the return, with no range indication, other than that amplitude. So, a surfaced u-boat side-on to the radar-head, close to the escort would be a large amplitude, but one at AOB zero would be less in amplitude, and a distant one still less. That of a schnorkel viewed on the radar at range would be very difficult to make out amongst all the other spurious returns by a player.

Conclusion 2 is that player-skill on the escort should be a major factor as to whether - or not - a correct interpretation is made from an early iteration of radar.

Later on in the time-line the PPI should replace the oscilloscope presentation, but according to the pitch and roll of the escort, the ability to spot a contact amongst other spurious returns from the radar-head being tilted too far down, fairly difficult, especially at range. Similarly. as the radar head faces the the convoy, many strong returns are caused, however a ship or u-boat BEHIND a ship generating a return nearest the escort, will create a blank area behind that return, in which a u-boat can remain undetectable by radar, assuming it is surfaced. This would make spotting a u-boat's return the other side of the convoy, very difficult indeed.

As the date becomes later war, more and more escorts should have radar. Radar was preferentially fitted to destroyers, then sloops, then eventually corvettes. The height of the radar-head raising the range considerably. Similarly, as the date becomes later, sets with PPI should become the norm. Failure rates - or periods where the radar has to be turned off, should reduce as the timeline continues. Counter-measures such as Metox should likewise alert the radio-operator that the u-boat is being struck by radar.

My estimate is that AI escorts should not be able to "spot" u-boats on radar unless the u-boat is both surfaced an close - under circa 6km for an extended period. If AI is able to use radar at all! A trail of returns caused by life-boats, carly-floats and suchlike would further complicate use.

116. Password request interface for locked lobbies.

There is, I think, a balance to be struck between the ability of a lobby to be locked, and the ability of a fairly new player to find a game. The other day I logged on to find all 6 lobbies locked, with no unlocked ones, and with in game comms being used, no means of contacting the players to ascertain the password. Plainly, players in a locked-lobby do not wish to be spammed by a player wishing to join, however, I think we may need a means for newer players, who are yet to form the network of friends to play regularly, to join a game.

Suggestion: A player can click on a locked lobby, and instead of entering the password, can "contact captain" ONCE per game, provided that there are 6 crew or less on the boat. If it's full, then that captain cannot be contacted. If there are several boats, the player attempting to gain entry may make a single text-contact to each captain with an unfilled boat, and any captain may then click on a "send password" if he wishes to admit that person, or, decline. Whereupon the player attempting entry has the password automatically entered, but he does not actually see the plain-text of the password (to prevent them distributing it more widely). They can then join the lobby in the normal way, but are restricted to joining the boat of the captain that accepted their request only.

This would aid newer players being able to join locked lobbies without materially causing a problem for that lobby, or adding any burdensome communication to the captain. Players who are banned by any individual in the lobby would be unable to send a password request to any captain within that lobby. This would help preclude trolls and the disruptive to employ the password-request as a nuisance mechanism.