the problem is, on what you say, you need laaarge scenarios during many hours :o/

One other solution I start to use is to put Orions quite far away from the search area.
this way, subs have time to position themselves during half an hour without beeing threathened from the first 5 minutes of game.

But this mean orion will have nothing to do for 30 mn except cruising.

Well since the bubbleheads seem so keen on breaching the surface the airdales have a new tactic.
Its not optimal because mad/sad can't be used and the camera is near to useless but at 100% the p-3 will be out of reach of the subs.
Take as a loadout only dicass and cruise at 6000 ft out of sam range, drop buoys all over the area and start pinging.
Sooner or later the sub will show out and a torpedo will be launched at him ;)

Yes, the AI uses buoys very well.

If you are in a P-3 in a mission, and you have a lot of AI platforms in the search area, you can drop a good buoy pattern and the AI will do most of the actual work.

That's why I think that moving to larger search areas isn't such a bad thing.

In any case, if the sub driver is essentially tasked with AA duty in a mission, then of course he will find it necessary to use his SAM launcher.

I guess it would be good for mission designers to strive for around 50% or less detections by airplatforms in missions (that percentage can be a lot less if there are other friendly platforms around), since detection more or less means a sure kill.

so how do i force ai to immediately drop buoys upon contact ?

how do i script the helos to randomly place a sonobuoy field ?

using "sonobuoy search" results in helos driving off to nowhere.

am i required to place all sonobuoys myself in the mission script itself ?

helos set as "in station" also rarely break formation despite the fact that one on "random box" or an ffg has picked me up.

i cant seem to program decent ai defenses without going way overboard on the # of vehicles defending.

Ah, that's the rub...

The AI does not DROP sonobuoys on their own very effectively, however, once the pattern is in the water, the AI will read them well.

Some mission designers have found it useful to place sonobuoy fields on their own using place object triggers, sometimes in combination with an planned aircraft fly-by.

You can post over in the mission design forum to see what the mission designers say about this. Personally, I have recommended placing the buoy fields yourself in the mission design phase and then just making sure there are platforms around to read them.

EUREKA !

OK hopefully i wont need 20 helos to the job of 2. THANKS

i am trying to set up a convoy traveling over a large area.
sub placement pretty wide and never detects a thing at start
the sub knows its generally start area but has to go find it.
it can take several tc hours of sprint drift to locate and arrive.

do buoys placed in the mission file have the same 2 hour time limit as ones i drop as helo ?

is there any other particular tactic setting (like sonobuoy search) to make the helos use em ?(or that are useless and should be avoided )
do i have to prog the helo's to use them ? or will every sonobuoy equipped vehicle "hear" the data and uplink it and react ?

thanks again !
sorry for the rush of question :oops:

As long as you do not set their tactic in the mission design to "transit" and they have a LOS to the buoys detecting the sub, the AI will effectively track and attack hostile buoy contacts.

In terms of sonobuoys, yes, they have the same time limit.

You can get over this by attaching the attach object script to a location trigger set off by a convoy or ASW aircraft.

For example, you can program a number of different patterns for each stage of the journey or ASW search, and then as the trigger fires, you can use a dynamic group to determine which of the patterns is actually triggered. Once you get the hang of it, you can actually make effective and unpredictable combinations to catch players as they try to stalk the convoy.

Up to this point, there has not been much utilization of this technique, it would be great if you got it to work well. Make sure you keep us up to date on your progress! :up:

Cheers,
David

yep :)

i was thinking once i have dynamic group(s) of buoys set up i could re spawn it further along the route at regular time interval(s).

as sosus is nowhere to be found i have no problems with the realism of it :P

thank you again

l'chaim,
dave

SWEET ! so diff its like freakin nite and day

added a few buoys to that test mission where i blow away 6 helo's while at flank

start at 30m depth
call flank
accelerated to 35kts.
call 16 m
many torps in water :o

:dead:

if my sail broke surface , it was already in pieces. :up:

Yep, if a future patch can address the issue of getting aircraft to lay buoy patterns on their own, the aircraft/helos will be in great shape! :)

I DO have faith that SCS is going to address this one in the future. :up:

A bit late, but I thought I'd mention that while this whole "mast" thing can be abused by leaving the masts up for hours, a compensatory factor is that the willing-to-play-by-RL rules but average gameplayer will find this whole "30 second" or "12 second" fast sweep thing a lot harder than the real Captain, in both periscope and ESM:
1) He doesn't get nearly as much practice and training in this whole thing.

2) The interface's limitations. The periscope sweep is reasonably fast at low power, but the range is short (the more so because the resolution of your monitor is low compared to the best resolution of your eye). In real life you can force the scope around fast even at high power and use your peripheral vision to cue you in on specks. In the game, you have those controls that make your scope crawl its way around, so you can't do a 12-second sweep because the scope crawls no matter how good you are. You can also do such things as flash the scope across a ship, mutter "Grisha about 250", and your crew can correlate it with the sonar bearings, while in the game if you want the message that it is a Grisha to transmit correctly you will have to lay the scope with some accuracy, click Photo, fight with the classification interface to get to "Grisha" and if you don't want to accidentally send the wrong range and course to TMA you waste time fighting the stadimeter and AOB system. Plus you don't have VCR recording your fast sweep for later scrutiny.

3) In ESM, it is the same story. You have to fight with your mouse to lay the marking arrow. In real life, they would have a dedicated expert that does only this, and he'd presumably have a dedicated ring control he can twist to achieve the correct lay very fast. In real life, if three radar sources suddenly pop up, all of them will be marked on their first sweep and you can put the mast down for awhile. In the game, by the time you fight your marking arrow onto the first strobe, the second and third will disappear, and to get them you have to wait for them to come at you again.

Of course, you can minimize this problem in SP by pausing the game, but that often isn't an option in MP, which is where most people want to eventually go.

TEST 2

setup
settings to full manual

player helo at 600 ft altitude

ai akula2 set to 56 ft depth 5 kts

note at this depth the ai akula's conning tower just barely breaks the
surface and basically submerging/surfacing with the waves.

game starts - helo on akula's 180 at approx 7500 yds

IMMEDIATELY GET "VISUAL SIGHTING" with full range course and speed info. and yes i can see a spot in the ocean

flip on radar - get a blip there too.

------------------------------------------------------------

as player helo
the radar and visual sighting model is too good.
i immediately detect on both radar and visual from 7500 yds yet the akula's con is at lowest point possible above waterline.

this would result in a player subs getting detected very very very easily.
something i m sure we would all be highly perturbed about.

ai helos do not act on this info, suggesting they dont receive it at all.
and
"eyewitness reports" state that player subs do not get picked up while blasting away at player helos

dubious conclusion - radar and visual info on player controlled subs conning tower is being suppressed.

optimistic view - changing the suppression point and applying it to both ai and player subs would seem to be possible.

TEST 3 (run 4 times )
stock 103

conditions clear seastate 3

akula set to 56 ft depth 5 kts
the top of the conning tower is only visible above surface maybe 50% of time but there is a small wake being created by design as result of sub speed.

helo moved back to 40 miles away

close at high speed

turn on radar

get blip on sub conning tower at ranges of 30000 - 31500 every time.(!!!!)

get visual at ranges of 7200 - 8000 every time.

sink sub with stunning lack of effort every time.

further supports "suppression" theory.

I have just tested this whole setup for the AI using Dbgviewer.

Indeed, the AI cannot detect sails at all... the viewer reported no detections at all for the AI P-3.

I have said before on this forum that I'm pretty sure that SCS decided to intentionally disable sail detections for the AI because they wanted human players to be able to use the SAM launcher against AI aircraft with impunity, but knew that this would not be acceptable for MP so allowed detections for human platforms.

Strange but perhaps true... I dunno. :damn:

Another theory is that the code for human platforms is newer (via the interface files) and that they never got around to updating it for AI platforms, which is perhaps more likely, because it would appear there is less code in common between human and AI platforms that one would think a priori.

So based on this, would it be possible to do something about that?

I mean if one way we can see it, I guess we are closer and closer to be able to do something.

In a way, no, this means it is out of our hands.

The sensors for the AI P-3 and the human P-3 are the same in the database... the engine is hardcoded to have certain parameters in this case.

I have to do more testing to figure it out, but my initial tests now and testing in the past has demonstrated to me that there is something being overridden from the database by the engine itself that we don't have access to be able to change.

How about if we compromise and make a sensor just for the AI? Basically, said specialized sensor has a max alt of say +10m and a min alt of -10m. If we set the altitudes and sensitivities (detection curves and all) just right, in theory we should be able to make the sensor hit a part of the submarine (the top part) if it rises too high and bounce some signal back. That way, we'd discourage people from being too brazen about rising to periscope depth close in - and if they aren't at that depth they won't be able to use their scopes and ESM efficiently.

But that's assuming the database even matters in this case... there are a number of examples where database values are never actually used by the sim, depending on the situation.

For example, in the Thrust Dialogue, although I can set PropEfficiency, it is calculated on the fly by the Sim, so the value entered in the database is irrelevant.

There are any number of reasons why this isn't working, but the database does not appear to be the culprit, although I really have yet to do a full schedule of testing on this aspect of DW.

sorry, i dunno from debug view or how to read the databases.

do the ai and human models actually have the identical sensors ?
or are their possibly sensors just for player vehicles ?

maybe human models themselves have been rendered "invisible to ai lookouts and radar" unless the sub crew says "surfaced" (or some such)

:damn:

Get DWEdit. It is pretty good. It is available at SubGurus.

:damn:

Worse comes to worst, make the darn thing an "active sonar", with Max Operating at 0 and Min at -15m. They can't possibly deny our rights to the sonar. It won't be perfect but at least it'd discourage people from PDing, which is probably what is wanted. Grrr...

Actually, as I mentioned in a previous post, I don't mind this particular flaw as much as some, but:
1) I don't fly the planes much.
2) I'm all for player modifiability.