First time I check the sonobuoys persistence time, it's one hour only for all types, not too bad.

I supposed this time is fixed and determined by the Game Engine, and we can only change this value for all the sonobuoys, and not fix a time for each time of sonobuoy, also not too bad.

 

Is not a priority, but I think we should change this time persistence value to a longer and more realistict value, perhaps four hours persistence time (if two times are possible , perhaps 4 hours for passive sonobuoys and 30 minutes for active sonobuoys). As consequence, ASW and submarine tactics will be probably altered.

 

Here some sonobuoys persistence times (from data on my personal tables, compilated for years from many open sources):

SSQ-2 (1951), 1.5 hours.

SSQ-38 Jezebel/LOFAR (1964), 72 hours (probably a reference to waiting time on the water, inactive or sleeping).

SSQ-47/947/522/HQS-31 (1968), 30 minutes (is active, because that his short persistence).

SSQ-53/B DIFAR (1969), selectable for 1, 3 or 8 hours.

SSQ-53D, selectable for 0.5, 1,2,4 or 8 hours.

SSQ-53F (2010?), selectable for 0.5, 1,2,4 or 8 hours.

SSQ-57 (1972?), LOFAR selectable for 1, 3 or 8 hours.

SSQ-58, 100 hours, surveillance, moored, for detect small crafts and scuba divers.

SSQ-75, 3 hours passive. Greater than A-size. Cancelled FY93.

SSQ-77C VLAD, 0.5, 1, 2, 4 or 8 hours. Convergenze Zone capable.

SSQ-79 SVLA, 4-8 hours, not produced.

SSQ-981 BARRA, selectable for 1, 2, 3 or 4 hours.

SSQ-904 Mini-Jezebel LOFAR (1980), 1 to 8 hours.

SSQ-906 Jezebel (1988), 1 to 6 hours.

SSQ-907, 1 to 6 hours.

SSQ-954 (1985), 1 to 6 hours.

SSQ-954B DIFAR (1988), 1 to 6 hours.

DSTV4(TSM 8010)(1970), 1 to 8 hours.

TSM 8040 (1986), 30 minutes.

TSM 8050 (1989), 30 minutes.

TSM 8062 (1992?), 1 to 8 hours.

RGB-1/A(BM-1?)(1967?), 3 hours.

RGB-2 (1976), 3 hours.

RGB-3, 2 hours, unreliable.

RGB-15 Julie (1979?), 2 hours.

RGB-25 (1979?), 40 minutes.

RGB-55 (1979?), 1 hour.

RGB-48 DIFAR (2006?), 24 hours.

RBM-81, 6 hours (has MAD sensor, not Sonar).

RGB-N Iva (employed 1955 to 1975?), 8 hours.

RGB-56-NM(RGB-64-N?)(1956), battery for 4-5 days but sunks at 24 hours.

Tadpole (2000), 8 hours (is an Indian type sonobuoy).

Yes, SBs last for an hour , SR->time = GameTime + 3600L;

 

The second biggie with Sonobuoys is that the GE will only keep 768 of them at a time in the scenario, when SB #769 is dropped, #1 is destroyed even if it hasn't been deployed for an hour. This is pretty obviously an artificial limit to keep the game running at a decent speed on older computers. It may well be time to change this limit as well.

 

I'm open to the changes, you guys figure out what you want.

Thanks Tony.

 

Of the little table data, four hours sembles a middle value for (mostly) passive sonobuoys.

Active sonobouys apparently, because more energy expenditure radiating echo sounds, last less time, between 0,5 or 1 hours, but in some probably the passive element persist useful more time (also remember the sonobouys type Julie, not strictly active sonobouys, they are advanced passive sonobuoys type Jezebel, but not only passive, they are also programmed to analyze the echo provoked by echo generating explosive charges also dropped in the wáter by ASW aircrafts or helicopters).

 

If we can only choose one value, I vote for four hours persistence.

 

 

 

About the 768 number of sonobouys limit, clearly remove it, but it's not a priority because also I think very few scenarios are running with more than 768 SB deployed at once.

Unless we can adjust sonobuoy endurance in the DB, and clearly we cannot (as of now), I think the current one hour value ought to remain.

 

This is because of the unlimited number of sonobuoys available aboard the ship or airfield being used by the rotary or fixed wing aircraft dropping the buoys, as well as the unlimited number of datalink channels.

 

The limited endurance (especially as it pertains to passive buoys) acts as a buffer against this limitation.

 

As for total number of sonobuoys in use simultaneously in a scenario, its a low priority issue because we rarely if ever see those numbers in play.

 

In fact, I'd rather go in the other direction (reduce total number in play) because of the realism issues earlier mentioned.

Yeah, is another view, not bad either.