A few new ideas - Page 12

Fidd · 03-15-24, 05:27 PM

137. Variable inertia (as a lobby setting) - "easy to realistic"

One of the less realistic aspects of WP is the lack of inertia. Inertia may be described as: Inertia is a property of matter1that describes its tendency to remain at rest or in unchanging motion unless acted on by some external force1.

In other words, a boat that is out of trim, will continue to rise or descend in the water column unless a corrective action is taken, such as adjusting the trim, but even then, there is a considerable lag between changing the trim, and it arresting the rise or descent. What we currently have is an almost instantaneous correction, without lag. The lag is caused because a u-boat displacing 870 tons (submerged), once it's moving in any direction, requires a very considerable and sustained force to stop it!

Inertia applies in every axis, for turning, for rising, diving, and for changes of speed. The corrective forces applied differ. So arresting an unwanted rise just using trim alone, is a small force, and then will take a good deal of time to occur. If on the other hand, the hydroplanes are used, then their effectiveness depends of the displacement from the neutral position, and also the speed of water passing over the 'planes. It follows from this that maintaining periscope depth with no forward speed should be very difficult, but doing so (say) at slow ahead, would be much easier.

Proposition: A slider on the lobby screen for "inertia". This would allow inertia to be set as it is now (easy) to fully realistic inertia. The effects of this would be to introduce an appropriate amount of lag between moving a control surface (rudder or 'planes), making a change to shaft rpm, or to adjusting a trim or MBT value. As the effect of inertia can be implemented simply by adding a lag value that's determined by the known inertia and corrective force, it may be possible to implement this without dealing in any way with the physics model. (If there is one!)

It has some interesting effects: For example, holding PD, one might want to trim slightly heavy, so the natural tendency of the boat is to sink slowly, then hold it at the correct depth with slight up 'planes. That way, simply reducing the amount of "up" planes will quickly offset any inadvertent rise.

Similarly, if DC's explode above the u-boat, it momentarily causes the boat to rise, requiring use of the 'planes to correct. Conversely, if the DC's explode beneath, the u-boat then develops a descent, and in both cases, the inertia of an 870 ton boat then requires considerable correction. It was entirely possible, and indeed there are many historical accounts of this, for WW2 submarines losing vertical control because too much correction was applied, leading to an increasingly divergent error in buoyancy, until the sub either broached the surface, or, sank beneath it's crush depth. Usually the former.

It may seem counterintuitive to be asking for "lag" when so much effort is being made to design it out, but in this case, I think it's worthwhile to make the operation of the boat configurable, and more interesting if desired. Of course this might better be something configurable on a per-boat rather than per-lobby basis..?

Fidd · 03-19-24, 06:04 PM

138. Sound improvements:

1. Improvement to sound-deadening when doors are shut in radio and hydrophone compartments. (increased)

2. Additive sound attenuation dependant on number of intervening closed hatches. So, if all 3 doors are closed between the diesel room and control room, the sound of the diesels is considerably muted, and less so for each open hatch.

3. Addition of alarm-bell repeaters to diesel-room, e-motor-room, and radio-compartment. The latter to aid a radio-operator to have another cue to send "DDD" in a multi-boat game. Repeaters for the alarm-bell existed in EVERY compartment except lavatories. (Decaf has original material)

4. Compartment specific sound-level UI for diesel-room.

5. Audible "ping" from "Echolot" when operated on 100m plus scale. (I believe the strength of sent ping was proportional to the depth scale selected when it was operated)

6. Atmospheric sounds for deck-plate lifting, chain-hoist lifting of reload torpedo, torpedo-tube hatch operation, flooding of tube and bow-cap operations, when a reload is set in operation at the TDC. During the reload, the boat emits considerable noise. These sounds as a place-holder until a manual player operated reload tasks are modelled (?).

7. Increased wind/sea-spray hitting u-boat/"slap" of pitching u-boat hitting waves when on the casing or bridge, subject to wind-speed etc set in game. Some of these sounds also audible inside?

8. Considerable increase in volume and number of pings of EOT "bells" - or the adoption of a buzzer, when an EOT operates, especially in the diesel room.

9. Sound of Enigma being operated whenever a message is sent or received, automatically, unless it is manually being used, at which point the actual sounds of it being manually operated are audible, and the "automatic" sounds are suppressed?

Fidd · 04-08-24, 02:09 PM

139. Two crew deck-guns

One of the perennial problems with the deck-gun, especially on open lobbies, is the clueless or trolls, using the deck-gun without reference to the captain, alerting the convoy and possibly getting the u-boat sunk by return fire. It has been suggested that a lobby setting to disable deck-gun use might be a solution, however, as the circumstances where deck-gun use are hard to forecast, and rare, it seems to me that a better solution would be to require the deck-gun to be served by a minimum of two players, in order for it to work at all. This would render trolls/newbs from using it solo, but also to allow for it's use if circumstances permit.

Fidd · 04-09-24, 02:49 AM

140. How to handle human escort players "spotting" u-boats/periscopes?

I've been giving some thought recently as to how this might be handled in game to sidestep some of the foreseeable potential problems of having human players "on watch" looking for u-boats, and how that relates to visual detection ranges as currently handled by the AI.

The foreseeable problems are: manipulation of gamma, allowing seeing of a u-boat when otherwise it'd be too dark. Graphical limitations meaning that diesel-smoke or water splashes being visible from too great a distance. Lack of natural sea-foam making it too easy to spot one caused by a periscope feather etc.

Possible methods to forestall these problems:

a) Limit the range at which water effects, such as periscope feather, to no more than the normal AI detection-range, so that a human observer cannot use these as a cue outside of the normal AI detection-range.

b) Limit the render range of both the surfaced u-boat, and the periscope when submerged, to appropriate detection-ranges, modified by fog value (if any), so that gamma manipulation cannot confer an ability to see a u-boat much beyond the detection range at which the AI can "spot" a u-boat visually.

c) Make the binocular view on escorts powerful in magnification, but with a correspondingly small field of view, so that simply panning cannot guarantee spotting a uboat, as it may be outside of the field of view.

d) Allow the binocular view to pan, but only for 45 degrees or so, before the user has to come off the magnified position to reposition for the next pan for the next 45 degrees. Consider limiting the total angle over which any position can pan, to circa 150 degrees.

e) Limit the ability to use binoculars to a reasonable speed of escort/wind value, so that using the binoculars is not possible at very high speeds/strong wave action combinations. If adequately slow, it should always be possible to use binoculars.

Thoughts on alerts with combinations of human/AI escorts.

Alerts caused by uboats coming within detection range of an AI escort can probably remain as they are now. For playable escorts, a manual means of causing an alert needs to exist. This needs to be limited, so that it one cannot cause an alert without actually seeing a u-boat. Else it could be misused. As the host is tracking the positions of u-boats and escorts, and could also track the positions of binoculars (or gun optics), it ought to be possible to require the captain of the escort to view the u-boat, and for his binos/gun optics to be "tested" to see if is pointed at a u-boat when the "request" for an alert is made. This would make it impossible for a human player to cause the convoy to alert, unless his optic is pointing at the uboat when the request is sent. If it is, then the alert can be set in train, causing the AI escorts and merchants to behave in the required fashion.

I think it's important that a human escort captain has the option to NOT necessarily cause the alert at the instant he can. This would allow, if the circumstances are such where a delay in reacting confers some benefit to the escorts - for the Convoy Commander to quietly send off a couple of escorts to the general area of the u-boat, and therefore increase the chance of catching it at a shallower depth when it is attacked. Anything that "muddies the waters" as to when a detection is made, and when it has not been, helps generate varied content.

Fidd · 04-09-24, 06:33 AM

141. Boat specific and variable presence objects.

I have often felt it would be nice if there were differences between one u-boat and another, slight differences in appearance or location of objects so that when you serve on a different boat to normal, there's a sense of being on a "different boat", rather than having all 4 u-boats look exactly the same, and look the same every single game.

One way to achieve this would be to have objects such as:

Clothing items in the sleeping/mess areas.
Food stored around the boat
Different meals "cooking" in pots in galley
debris such as stacked dirty plates, ash-trays, mops, buckets, books, and other miscellaneous similar objects. Ability for players to set their avatars appearance of age, build, facial hair, clothing etc could also be a part of this.

Different dispositions of these objects could create a little difference between 1 boat and another.

This could also be varied over time, as well, so that not only would there be different objects scattered around in different boats, but over time (multiple play sessions) the objects present on any given boat would slowly change over time, creating the impression of a boat with a larger crew aboard, and a more dynamic environment where things change in appearance over time as well as between boats. But not so much that you can't distinguish one boat from another internally.

Obviously not a high priority, relative to other features, but it'd be nice to have one day.

Fidd · 04-14-24, 11:59 AM

142. Battery-heating after full charge?

This is surmise on my part. In theory, there'd be some form of battery protection that cracked in once you'd reached a little above 9.3Kah, in order to prevent over-charging, with the rate of recharge affecting how quickly this protection - howsoever arranged - came on.

This has implications for a current technique whereby when matching a convoy speed, the e-motor is put "on charge" and then the exact required rpm is maintained watching the e-motor shaft rpm gauge, and moderated using the e-motor speed controller.

So, either a battery temperature gauge, (with it tripping on reaching a max temp) or, the battery "tripping" a rate-dependant trip, would seem to me to be a worthwhile addition. The problem is, I don't know precisely how this aspect was actually handled. Perhaps Stosstrup or Decaf' could comment? The latter is my preferred solution, as it would allow the emotor moderated system for matching convoy speeds, but perhaps not for extended periods?

derstosstrupp · 04-14-24, 08:31 PM

Quote:

Originally Posted by Fidd

142. Battery-heating after full charge?

This is surmise on my part. In theory, there'd be some form of battery protection that cracked in once you'd reached a little above 9.3Kah, in order to prevent over-charging, with the rate of recharge affecting how quickly this protection - howsoever arranged - came on.

This has implications for a current technique whereby when matching a convoy speed, the e-motor is put "on charge" and then the exact required rpm is maintained watching the e-motor shaft rpm gauge, and moderated using the e-motor speed controller.

So, either a battery temperature gauge, (with it tripping on reaching a max temp) or, the battery "tripping" a rate-dependant trip, would seem to me to be a worthwhile addition. The problem is, I don't know precisely how this aspect was actually handled. Perhaps Stosstrup or Decaf' could comment? The latter is my preferred solution, as it would allow the emotor moderated system for matching convoy speeds, but perhaps not for extended periods?

Hi Fidd,

The charging of the batteries followed the same three phase principles by which lead acid batteries are charged even today. Charging began with a high voltage charge at a high level of current to deliver a high level of power (kW hours) to the cells, until the cell voltage reached roughly 2.4 V, or 149 V per bank. This is known as the so-called “gassing voltage”, above which electrolysis of water occurs and formation of hydrogen gas, high heat and the boiling off of the water in the electrolyte can occur in large amounts. And so at this point during the charge, the charging current is gradually tapered off (the “second phase”) while maintaining a bank voltage of 149 V, until the current has been reduced to roughly 400 or so amps, at which point the charge is then stopped.

The above are the steps for typical daily charging. Once a week and once a month, you would perform an equalization charge, taking the charge into a third phase (constant current at 400 A or so) much longer to boost the bank voltage up to roughly 170 V, which ensures that A) a good part of the lead sulfate that has formed on the electrodes gets converted back into sulfuric acid, and B) it helps distribute, or “equalize”, the sulfuric acid in the electrolyte throughout the individual cells. Consequence of this type of charging of course is that you do end up with gassing, and a boiling off of water in the electrolyte. And so monthly, the distilled water would need to be replenished. A necessary evil - if not done, you end up with lead sulfate that can’t be removed, shortening the life of the cells unnecessarily.

And so the charge was purely a function of monitoring voltmeters and ensuring the proper procedure was performed. And monthly, adding an inspection of cells to measure electrolyte density and replenishment of the distilled water in the electrolyte. There were no battery temperature gauges, or anything of that nature, and these were not needed as long as the proper procedure was followed (electrolyte temperature was indeed measured by hand during monthly maintenance).

Fidd · 04-14-24, 09:14 PM

Many thanks Stosstrupp, as always a great pleasure to read some of your amazing knowledge. I am wondering, however, what you might regard as a sensible way of handling operating the engine in charge mode when the batteries are already at 9.3Kah?

derstosstrupp · 04-14-24, 09:36 PM

Quote:

Originally Posted by Fidd

Many thanks Stosstrupp, as always a great pleasure to read some of your amazing knowledge. I am wondering, however, what you might regard as a sensible way of handling operating the engine in charge mode when the batteries are already at 9.3Kah?

I think they should implement some manner of consequence, maybe in the form of gassing. Ventilation appears to be a consideration by them (we see them having implemented workable ventilation foot valves in the diesel room for instance). But it’s hard making any real suggestions at this point because the batteries aren’t modeled accurately at all. They are considered to be “electrolyte buckets” which is not how batteries work. For example, in real life, you could deeply discharge the batteries at AK over an hour, drop to a slow speed, and have another several hours left all of a sudden. That’s not how it works in Wolfpack - the chemistry that causes that phenomenon is not modeled. And so, since the consequence of bringing the batteries above their gassing voltage is also a chemical phenomenon, it’s hard to suggest something in this direction when the fundamental model is not correct.

But as a shortcut, stopgap, something along the lines of a risk of gassing if the ventilation system is not turned on when continuing a charge is not entirely far-fetched. But it is also silly in a way, because there’s no reason to continue a charge in the game. In real life, you prolong the charge monthly for the health of your battery cells. That’s not a consideration in the game. And so it would be purely punitive, which may not be the best for game design.

Fidd · 04-14-24, 10:25 PM

Many thanks, that's given me a lot to think about. I'll ruminate on all this for a few weeks and return to it.

Fidd · 04-16-24, 05:51 PM

143. Refuelling the "daily tank".

Once a day, as I understand it, the daily (overhead) tank in the engine room had to have fuel-oil pumped into it from the saddle-tanks. This could be assumed to be necessary at some point in each game as a one-off task for the engine room players. As the fuel oil in the saddle tanks was displaced by sea-water, this also necessarily changed the trim of the boat, so this task would also add some much needed extra work for the dive-officer, who would have to retrim the boat on the next dive after the fuel-transfer was made.

Ideally, perhaps, each game would start with a random amount of fuel remaining in the daily-tank, meaning that factoring in when this was done would be something for the captain/chief engineer to think about. Accelerated use of fuel from the daily tank would help in this regard, so that the full "daily tank" exhausts in circa 2.5 hours, meaning that in a 3 hour game, at some point, it'll need to be done. One could argue that this would be done prior to nearing the convoy, but as our "3 TOI games" are considered to be representing many hours, rather than just 3 it actually takes us, that it is therefore something that could be included as a game mechanic. It would also add considerable amusement value when the boat comes to a halt because one "ran out of gas"!

derstosstrupp · 04-16-24, 07:09 PM

Quote:

Originally Posted by Fidd

143. Refuelling the "daily tank".

Once a day, as I understand it, the daily (overhead) tank in the engine room had to have fuel-oil pumped into it from the saddle-tanks. This could be assumed to be necessary at some point in each game as a one-off task for the engine room players. As the fuel oil in the saddle tanks was displaced by sea-water, this also necessarily changed the trim of the boat, so this task would also add some much needed extra work for the dive-officer, who would have to retrim the boat on the next dive after the fuel-transfer was made.

Ideally, perhaps, each game would start with a random amount of fuel remaining in the daily-tank, meaning that factoring in when this was done would be something for the captain/chief engineer to think about. Accelerated use of fuel from the daily tank would help in this regard, so that the full "daily tank" exhausts in circa 2.5 hours, meaning that in a 3 hour game, at some point, it'll need to be done. One could argue that this would be done prior to nearing the convoy, but as our "3 TOI games" are considered to be representing many hours, rather than just 3 it actually takes us, that it is therefore something that could be included as a game mechanic. It would also add considerable amusement value when the boat comes to a halt because one "ran out of gas"!

Here is how that might look:
https://docs.google.com/presentation...i4XxoI6DI/edit

Fidd · 04-17-24, 06:25 AM

Quote:

Originally Posted by derstosstrupp

Here is how that might look:
https://docs.google.com/presentation...i4XxoI6DI/edit

That is perfect! Very interesting too. I shall cease calling is the daily tank forthwith!

Fidd · 04-21-24, 06:26 PM

144. Variable visibility over time

As a refinement of the fog system, it would be interesting if the visibility via the fog setting might vary over time - perhaps once or twice within a 3 hour game-play period, perhaps +/- 15% of the configured value at a rate of change not more than 1% per 5 minutes?

This would mean that rather than being able to rely on a given visibility (and therefore visual detection range) skippers would have to reassess visibility, and adjust their approaches.

A similar variation could be applied to wind-direction and strength. Ideally with fog greater than 8% (or thereabouts) only being able to form if windspeed was equal to or less than 5 kts. (above this value the mixing of air tends to create low stratiform cloud or mist, in both cases allowing greater visibility.

Similarly, to create high sea-states, wind-speed would need to be high, which in turn would completely preclude fog.

03-15-24, 05:27 PM	#166
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	137. Variable inertia (as a lobby setting) - "easy to realistic" One of the less realistic aspects of WP is the lack of inertia. Inertia may be described as: Inertia is a property of matter1that describes its tendency to remain at rest or in unchanging motion unless acted on by some external force1. In other words, a boat that is out of trim, will continue to rise or descend in the water column unless a corrective action is taken, such as adjusting the trim, but even then, there is a considerable lag between changing the trim, and it arresting the rise or descent. What we currently have is an almost instantaneous correction, without lag. The lag is caused because a u-boat displacing 870 tons (submerged), once it's moving in any direction, requires a very considerable and sustained force to stop it! Inertia applies in every axis, for turning, for rising, diving, and for changes of speed. The corrective forces applied differ. So arresting an unwanted rise just using trim alone, is a small force, and then will take a good deal of time to occur. If on the other hand, the hydroplanes are used, then their effectiveness depends of the displacement from the neutral position, and also the speed of water passing over the 'planes. It follows from this that maintaining periscope depth with no forward speed should be very difficult, but doing so (say) at slow ahead, would be much easier. Proposition: A slider on the lobby screen for "inertia". This would allow inertia to be set as it is now (easy) to fully realistic inertia. The effects of this would be to introduce an appropriate amount of lag between moving a control surface (rudder or 'planes), making a change to shaft rpm, or to adjusting a trim or MBT value. As the effect of inertia can be implemented simply by adding a lag value that's determined by the known inertia and corrective force, it may be possible to implement this without dealing in any way with the physics model. (If there is one!) It has some interesting effects: For example, holding PD, one might want to trim slightly heavy, so the natural tendency of the boat is to sink slowly, then hold it at the correct depth with slight up 'planes. That way, simply reducing the amount of "up" planes will quickly offset any inadvertent rise. Similarly, if DC's explode above the u-boat, it momentarily causes the boat to rise, requiring use of the 'planes to correct. Conversely, if the DC's explode beneath, the u-boat then develops a descent, and in both cases, the inertia of an 870 ton boat then requires considerable correction. It was entirely possible, and indeed there are many historical accounts of this, for WW2 submarines losing vertical control because too much correction was applied, leading to an increasingly divergent error in buoyancy, until the sub either broached the surface, or, sank beneath it's crush depth. Usually the former. It may seem counterintuitive to be asking for "lag" when so much effort is being made to design it out, but in this case, I think it's worthwhile to make the operation of the boat configurable, and more interesting if desired. Of course this might better be something configurable on a per-boat rather than per-lobby basis..?

03-19-24, 06:04 PM	#167
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	138. Sound improvements: 1. Improvement to sound-deadening when doors are shut in radio and hydrophone compartments. (increased) 2. Additive sound attenuation dependant on number of intervening closed hatches. So, if all 3 doors are closed between the diesel room and control room, the sound of the diesels is considerably muted, and less so for each open hatch. 3. Addition of alarm-bell repeaters to diesel-room, e-motor-room, and radio-compartment. The latter to aid a radio-operator to have another cue to send "DDD" in a multi-boat game. Repeaters for the alarm-bell existed in EVERY compartment except lavatories. (Decaf has original material) 4. Compartment specific sound-level UI for diesel-room. 5. Audible "ping" from "Echolot" when operated on 100m plus scale. (I believe the strength of sent ping was proportional to the depth scale selected when it was operated) 6. Atmospheric sounds for deck-plate lifting, chain-hoist lifting of reload torpedo, torpedo-tube hatch operation, flooding of tube and bow-cap operations, when a reload is set in operation at the TDC. During the reload, the boat emits considerable noise. These sounds as a place-holder until a manual player operated reload tasks are modelled (?). 7. Increased wind/sea-spray hitting u-boat/"slap" of pitching u-boat hitting waves when on the casing or bridge, subject to wind-speed etc set in game. Some of these sounds also audible inside? 8. Considerable increase in volume and number of pings of EOT "bells" - or the adoption of a buzzer, when an EOT operates, especially in the diesel room. 9. Sound of Enigma being operated whenever a message is sent or received, automatically, unless it is manually being used, at which point the actual sounds of it being manually operated are audible, and the "automatic" sounds are suppressed?

04-08-24, 02:09 PM	#168
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	139. Two crew deck-guns One of the perennial problems with the deck-gun, especially on open lobbies, is the clueless or trolls, using the deck-gun without reference to the captain, alerting the convoy and possibly getting the u-boat sunk by return fire. It has been suggested that a lobby setting to disable deck-gun use might be a solution, however, as the circumstances where deck-gun use are hard to forecast, and rare, it seems to me that a better solution would be to require the deck-gun to be served by a minimum of two players, in order for it to work at all. This would render trolls/newbs from using it solo, but also to allow for it's use if circumstances permit.

04-09-24, 02:49 AM	#169
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	140. How to handle human escort players "spotting" u-boats/periscopes? I've been giving some thought recently as to how this might be handled in game to sidestep some of the foreseeable potential problems of having human players "on watch" looking for u-boats, and how that relates to visual detection ranges as currently handled by the AI. The foreseeable problems are: manipulation of gamma, allowing seeing of a u-boat when otherwise it'd be too dark. Graphical limitations meaning that diesel-smoke or water splashes being visible from too great a distance. Lack of natural sea-foam making it too easy to spot one caused by a periscope feather etc. Possible methods to forestall these problems: a) Limit the range at which water effects, such as periscope feather, to no more than the normal AI detection-range, so that a human observer cannot use these as a cue outside of the normal AI detection-range. b) Limit the render range of both the surfaced u-boat, and the periscope when submerged, to appropriate detection-ranges, modified by fog value (if any), so that gamma manipulation cannot confer an ability to see a u-boat much beyond the detection range at which the AI can "spot" a u-boat visually. c) Make the binocular view on escorts powerful in magnification, but with a correspondingly small field of view, so that simply panning cannot guarantee spotting a uboat, as it may be outside of the field of view. d) Allow the binocular view to pan, but only for 45 degrees or so, before the user has to come off the magnified position to reposition for the next pan for the next 45 degrees. Consider limiting the total angle over which any position can pan, to circa 150 degrees. e) Limit the ability to use binoculars to a reasonable speed of escort/wind value, so that using the binoculars is not possible at very high speeds/strong wave action combinations. If adequately slow, it should always be possible to use binoculars. Thoughts on alerts with combinations of human/AI escorts. Alerts caused by uboats coming within detection range of an AI escort can probably remain as they are now. For playable escorts, a manual means of causing an alert needs to exist. This needs to be limited, so that it one cannot cause an alert without actually seeing a u-boat. Else it could be misused. As the host is tracking the positions of u-boats and escorts, and could also track the positions of binoculars (or gun optics), it ought to be possible to require the captain of the escort to view the u-boat, and for his binos/gun optics to be "tested" to see if is pointed at a u-boat when the "request" for an alert is made. This would make it impossible for a human player to cause the convoy to alert, unless his optic is pointing at the uboat when the request is sent. If it is, then the alert can be set in train, causing the AI escorts and merchants to behave in the required fashion. I think it's important that a human escort captain has the option to NOT necessarily cause the alert at the instant he can. This would allow, if the circumstances are such where a delay in reacting confers some benefit to the escorts - for the Convoy Commander to quietly send off a couple of escorts to the general area of the u-boat, and therefore increase the chance of catching it at a shallower depth when it is attacked. Anything that "muddies the waters" as to when a detection is made, and when it has not been, helps generate varied content.

04-09-24, 06:33 AM	#170
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	141. Boat specific and variable presence objects. I have often felt it would be nice if there were differences between one u-boat and another, slight differences in appearance or location of objects so that when you serve on a different boat to normal, there's a sense of being on a "different boat", rather than having all 4 u-boats look exactly the same, and look the same every single game. One way to achieve this would be to have objects such as: Clothing items in the sleeping/mess areas. Food stored around the boat Different meals "cooking" in pots in galley debris such as stacked dirty plates, ash-trays, mops, buckets, books, and other miscellaneous similar objects. Ability for players to set their avatars appearance of age, build, facial hair, clothing etc could also be a part of this. Different dispositions of these objects could create a little difference between 1 boat and another. This could also be varied over time, as well, so that not only would there be different objects scattered around in different boats, but over time (multiple play sessions) the objects present on any given boat would slowly change over time, creating the impression of a boat with a larger crew aboard, and a more dynamic environment where things change in appearance over time as well as between boats. But not so much that you can't distinguish one boat from another internally. Obviously not a high priority, relative to other features, but it'd be nice to have one day.

04-14-24, 11:59 AM	#171
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	142. Battery-heating after full charge? This is surmise on my part. In theory, there'd be some form of battery protection that cracked in once you'd reached a little above 9.3Kah, in order to prevent over-charging, with the rate of recharge affecting how quickly this protection - howsoever arranged - came on. This has implications for a current technique whereby when matching a convoy speed, the e-motor is put "on charge" and then the exact required rpm is maintained watching the e-motor shaft rpm gauge, and moderated using the e-motor speed controller. So, either a battery temperature gauge, (with it tripping on reaching a max temp) or, the battery "tripping" a rate-dependant trip, would seem to me to be a worthwhile addition. The problem is, I don't know precisely how this aspect was actually handled. Perhaps Stosstrup or Decaf' could comment? The latter is my preferred solution, as it would allow the emotor moderated system for matching convoy speeds, but perhaps not for extended periods?

04-14-24, 09:14 PM	#173
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	Many thanks Stosstrupp, as always a great pleasure to read some of your amazing knowledge. I am wondering, however, what you might regard as a sensible way of handling operating the engine in charge mode when the batteries are already at 9.3Kah?

04-14-24, 10:25 PM	#175
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	Many thanks, that's given me a lot to think about. I'll ruminate on all this for a few weeks and return to it.

04-16-24, 05:51 PM	#176
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	143. Refuelling the "daily tank". Once a day, as I understand it, the daily (overhead) tank in the engine room had to have fuel-oil pumped into it from the saddle-tanks. This could be assumed to be necessary at some point in each game as a one-off task for the engine room players. As the fuel oil in the saddle tanks was displaced by sea-water, this also necessarily changed the trim of the boat, so this task would also add some much needed extra work for the dive-officer, who would have to retrim the boat on the next dive after the fuel-transfer was made. Ideally, perhaps, each game would start with a random amount of fuel remaining in the daily-tank, meaning that factoring in when this was done would be something for the captain/chief engineer to think about. Accelerated use of fuel from the daily tank would help in this regard, so that the full "daily tank" exhausts in circa 2.5 hours, meaning that in a 3 hour game, at some point, it'll need to be done. One could argue that this would be done prior to nearing the convoy, but as our "3 TOI games" are considered to be representing many hours, rather than just 3 it actually takes us, that it is therefore something that could be included as a game mechanic. It would also add considerable amusement value when the boat comes to a halt because one "ran out of gas"!

04-21-24, 06:26 PM	#179
Fidd XO Join Date: Apr 2005 Location: Blighty! Posts: 420 Downloads: 10 Uploads: 0	144. Variable visibility over time As a refinement of the fog system, it would be interesting if the visibility via the fog setting might vary over time - perhaps once or twice within a 3 hour game-play period, perhaps +/- 15% of the configured value at a rate of change not more than 1% per 5 minutes? This would mean that rather than being able to rely on a given visibility (and therefore visual detection range) skippers would have to reassess visibility, and adjust their approaches. A similar variation could be applied to wind-direction and strength. Ideally with fog greater than 8% (or thereabouts) only being able to form if windspeed was equal to or less than 5 kts. (above this value the mixing of air tends to create low stratiform cloud or mist, in both cases allowing greater visibility. Similarly, to create high sea-states, wind-speed would need to be high, which in turn would completely preclude fog.