LWAMI Playtest One Now Available at the CADC! ---UPDATED---

[LuftWolf]

http://www.orionwarrior.com/forum/showthread.php?t=29521

Here is the readme:

To Install: Unzip the file into your main DW directory allowing the unzip program to overwrite all files and install to the correct directories.
This playtest should be considered a beta. It combines LWAMI 3.02 with the following changes:
Advanced Torpedo Control Mod for UGST and ADCAP:
Set the torpedo to fire as normal. If you don't use the wire commands, it will behave as always. The wirecontrol commands are now as follows. Note, you must wait at least a second of game time between clicks, but it is possible to hit the button several times to go through the cycle quickly. A single preenable click will preenable the torpedo if it is enabled or do nothing. A second preenable click will send the torpedo to the preset search depth. A third click will send the torpedo to the ceiling. A fourth click will send the torpedo back to launch depth. The enable button works as follows. A single enable click will set the torpedo speed to 40kts and enable the passive sensor. A second click will enable the active seeker on the torpedo and set the speed to max speed. Further clicks of the enable button have no effect on the torpedo unless it is preenabled again, and then the behavior is reset to the beginning of the enable cycle.
WireBreak Mod:
Wires are now limited in range and ownship maneovering parameters. The ADCAP has a 10nm internal wire and a 5nm wire on the launching platform. If the torpedo or ownship travel farther than those distance FROM THE LAUNCH POINT, or if the range between ownship and the torpedo exceeds that distance, the wire will break. The UGST has a 25km internal wire and a 5km wire on the launching platform. Additionally, if the opening speed between ownship and the torpedo exceeds about 60kts for the ADCAP or 55kts for the UGST, with ownship movement accounting for no more than 20kts of that calculation, the wire will break. These maneovering measurements are unintentionally fuzzy, however, it is something that occurs naturally that I was going to build in anyway, so it works nicely. :-) What this means in practical terms is that a slow running torpedo gives the launching platform much more flexibility in maneovering the ship, whereas a torpedo running at maxspeed is much more prone to a maneovering-related wirebreak. NOTE: When the wire is broken, its broken. However, sometimes the interface will momentarily display the torpedo as preenabled, but it reenables soon enough not to effect the game in any way. The only unfinished part is that you can still shutdown the torpedo even after the wire is broken... we can't take this out. However, it is very minor, in my opinion, seeing as the user would typically reload his tube after the wires are broken anyway. ;-)
Advanced UUV Mod:
The UUV is much more quiet now, and is very hard to detect without cavitation. The passive sensor has been reduced in sensitivity considerably and the active sensor has been disabled completely (mostly because its broken in DW 1.03). The UUV now has a range of 32km and max speed of 20kts, with the sensors effective up to 6-8kts, with washout above 6kts. The operation is as follows. You must be at 4kts as before, and enter the presets in the same way. After firing the weapon it will begin to feed back data immediately and move at 4kts. The speed of the UUV is controlled with the enable button and the depth is controlled with the preenable button. The preenable button has no effect on the passive sensor. One click of the enable button will stop the UUV; it can persist indefinately in this state (although I will most likely have a timer on it in the full version), a second click will speed the UUV up to 6kts. A third click of the enable button will speed the UUV up to 12kts, the max speed the UUV can travel in up to 90ft of water without cavitating. A fourth click of the enable button and the UUV will go to its max speed of 20kts. A fifth click will stop the UUV and reset the counter, although you can click the enable button twice slowly and set it to 6kts. Note the sensors are washout above 8kts and do not feed data. The preenable button depth control works as follows. A single click does nothing. A second preenable click will send the UUV to the preset search depth. A third preenable click will send the UUV to 90ft if it is in over 100ft of water or 45ft if it is in less than 100ft of water. A fourth click will send the UUV back to launch depth, and reset the cycle.
SLAM-ER and Misc. Missiles:
The SLAM-ER now works for ASuW use and will enable a radar seeker at the last waypoint if it is over water. If the last waypoint is over land, the missile will operate in Strike mode, and behave as a light TLAM. The missile has a stealth enable feature that sends it down to just above the ocean before enabling and then after enabling it rising back to its cruising altitude of 30ft. Note, the standard harpoon has also been giving this cruising altitude, and the flight profiles of various missiles have been lowered. Also, the standard SLAM has been fixed and equipped on the AI P-3 as a land attack missile because the AI can't use the SLAM-ER properly. The AI P-3 does carry the Harpoon for ASuW. The Harpoon and the SLAM-ER both have a 40 Radar PSL, which is very low.
Helicopters:
I have attempted to fixed several problems like crashing and reporting contacts at launch, as well as dragging the active dipping sonar. Please use the FFG AI MH60 as well as observe helo behavior in general. :-) Also, the MH60 no longer launches with its radar on. :-)
CIWSAttack Doctrine has been updated to give better intercept performance will allowing for appropriate missile conservation for sustained attacks.
I made a minor change to the TLAM doctrine to make sure it always explode near the target as opposed to disappearing if it overshoots.
The Random Direction Torpedo Mod has been disabled for all torpedoes to allow more predictable subroc and AI MH60 weapon delivery. The torpedoes will always go to the right upon enabling.
The Hull array of the SW has been changed to simulate what we believe to be more close to the actual sonar suite on the SW. The Hull array on the SeaWolf now represents a low frequency receiver with coverage slightly larger than the Sphere array and with the same geometry. The frequency sensitivity and and washout speed remain as before. This sonar suite should be very helpful for tracking evading targets and as well as for all situaions in the littorals where the TA cannot operate.
The Maxspeed of the MPT torpedo payload on the SS-N-27 ASW has been reduced from 55kts to 45kts. This is done partially because the torpedo probably is closer to that speed as well as to reduce the effectiveness of the SS-N-27 relative to the new torpedoes behavior.
That's it!
Please play the heck out of this, specifically looking into these things I have mentioned here and provide as much feedback as you can through the usual channels. :-)
Cheers,
David
LW

[LuftWolf]

I'm beginning to already suspect that I set the threshold for maneovering related wirebreaking too low. However, that's a good place to start to get it dialed in.

Let me know about this aspect of the wirebreak mod especially... and I'm sure you will, Molon. :)

Cheers,
David

[Bill Nichols]

I don't believe torpedo speed should be a factor in wirebreak. The wire unreels from the torpedo and should be stationary in the water even when the torp is at max speed -- at least, one would hope the designers spec'ed the reel mechanism to work at max torp speed.

The sub is where the problem is. The wire unreels from the breech-end of the tube as the sub travels through the water, thus it stretches through the torpedo tube and past the muzzle and outer doors. Theoretically, the wire should be stationary in the water as the sub maneuvers. However, high speeds and/or turn rates can cause the wire to 'snag' at the muzzle/outer door and break.

Can make wire break dependent only on sub speed, turn rate* (use rudder angle?) and distance from the launch point?

*Actually, wire break will depend on magnitude of turn from original launch heading, and is more likely if the sub turns in a direction away from the side the torpedo's initial run-out course.

Complicated, ain't it? :huh:

[Amizaur]

Note, you must wait at least a second of game time between clicks, but it is possible to hit the button several times to go through the cycle quickly.

It was some time ago, and I'm not 100% sure what I write now, but the case was that there WASN'T possible to cycle through modes by fast multiple clicking. Doctrine is evaluated once a second so it can read and note only ONE button click in this time...

Further clicks of the enable button have no effect on the torpedo unless it is preenabled again, and then the behavior is reset to the beginning of the enable cycle.p

Yes, had to take a look at my own readme to check that it's true. Confirm, enable button after active enable has no further effect, and the speed/depth settings ARE reset when preenable button is pressed. This way user can reset it's weapon when he's not sure at which depth it's currently, and set again the depth he wants.


or if the range between ownship and the torpedo exceeds that distance, the wire will break. the ownship can be in fact as far as 15nm from torpedo before wire break, 10nm in torp + 5nm on sub side, if sub is going in the opposite direction as torp... so I wouldn't count at all the sub-torpedo distance, only matters relative distance to launch point, 10nm for torpedo, 5nm for sub.

The UGST has a 25km internal wire and a 5km wire on the launching platform. Additionally, if the opening speed between ownship and the torpedo exceeds about 60kts for the ADCAP

That's only 5kts in the opposite direction for sub. Intentional ?
Well have to test those rules myself in actual game too see how they work ! :up:

UUV sounds great !! :rock: and the passive only mode accidentally allows very comfortable usage of separate buttons for depth and speed.

The MPT torpedo - sure I think in RL the speed is lower than 55kts, but at the time we lowered it, we lowered it from 70kts so 70 --> 45 seemed too radical :-). I think it's a good move, don't see tiny electrical torpedo making 55kts unless it's state-of-the-art western design like MU-90 or even better.

The SLAM-ER turning radar at last waypoint - I though about this too but had no time.. great that it was possible, now P-3 has Harpoons at last :up:

P.S. Have you resolved yourself problem with enabling torpedo outside wire range ? Or am I to look at it still ?

[Bellman]

:|\ Gentlemen may I thank you for all your hard work and devotion to our game. I am off to download immediately.

Well done ! :|\

[Amizaur]

In fact all the work is being made by Luftwolf now :) I've been off DW for few months, only have send him working versions of ATC mod and new torpedo mods, he's done the rest :). Great work !! :up: I'm really happy that there is someone else now who can modify and improve my doctrine mods, when I don't have time for DW, or make his own doctrines utilising some of my solutions and combining them with his own ideas :yep:

Cheers!

[Bellman]

UUV Mk2 preliminary tests indicate new speed depth control function working as outlined. However the UUVs sonar
performance of my game is, or has been, screwed !

UUV Mk 2 performance is unreliable, random and full of inexplicable inconsistencies. Egs:
(1) Identical Kilo contacts, tracked by 2 UUVs on 180 deg opposite courses. Both contacts at same speed, depth and
course. Kilo A at 8.5 nm tracked but Kilo B at 5.7 nm hidden. Passage of time and repositioning UUVs did not affect this.
(2) FFG close-in had initial track only with no updates.
(3) Phantom contacts.
LW - I have emailed selected dumps.

I remember a while back writing that UUV developments in the game are likely to finish up in a cul de sac.
(By one means or another) Prophetic or just anticipatable ? :yep:

[LuftWolf]

My pleasure to work with you Amizaur. :)

Yes, I fixed the enable past wire break issue... I needed to store the original RunToEnable value in a new variable, because RunToEnableValue gets set to -1 (I think) when the preenable button is used.

I mean that you can slowly press each button while at the console. So if you know you you need two clicks, just hit it once, wait a second or two and hit the button again.

[LuftWolf]

Bellman, I focused on the control aspects of the UUV. I just assumed that the sensor would work like other sensors in the game.

Of course, just like assuming that helos and aircraft would automatically drop contacts once they no longer are tracking them on a sensor, this turned out to be wrong.

Thanks for the testing... I look at it to make sure the UUV sensor is working properly and make sure there is nothing added in the doctrine that would interfere with tracking contacts.

Cheers,
David

[LuftWolf]

Bill, thanks for the information.

I am a bit limited in what I can do with the ownship parameters because of *yet* another latent coding inconsistency/malfunciton in the SimEngine.

I have an embarassingly large toolbox of doctrine functions to work with, a lot of which are no good because the sim isn't feeding good variable values into the doctrine.

All this was done in about 30 hours... now that I have some time and the core done, I can sitback with the testers and talk about what is known of the real world and what would work best for gameplay.

Cheers,
David

[LuftWolf]

Tony:

I think the "phantom" contact is actually ownship.

In terms of the other contacts, I have to look at their parameters exactly and the acoustic conditons. Additionally, I have noticed that sometimes you have to drop a contact for the UUV to update it...

Like I said, I blew through the parts of the changes I took for granted would work the way they should, instead focusing on the parts that had to be engineered and tested completely. Now that the engineering is done, the tuning process can begin.

I'm going to need a team of testers from now on to work with me.

So, that means you guys. ;)

Cheers,
David

[LuftWolf]

Bellman, upon further review it would appear the sensor is working properly. I can't comment on the specific acoustic conditions or platform details in your test, or on what your interpretation of it is really because I would need to have been there.

One thing that I can say is that the UUV actually seems to be ploting a bearing that is the result of TMA calculations rather than the truebearing from the sensor surface.

You can notice this most clearly if you fire a torpedo past your UUV, or on any contact with a high bearing rate on the UUV. There is clearly a big lag on the bearing of the contact, however, the real bearing is displayed if you drop the contact.

Unfortunately, there is nothing I can do about that, most likely, other than to say, that's the consequence of the new less omniscient aTMA system. I mean, the UUV is giving you free data more or less anyway, so dropping the contact if you really need to be sure of the bearing doesn't seem like TOO big a deal, considering it will pop right back up at the correct bearing.

So, maybe consider it, "working the UUV." :lol:

In any case, please run your test again and try dropping the contacts before you take your bearings, and better yet, can you send me the mission file itself, please? :)

Cheers,
David

PS Also, keep in mind, the sonar on the UUV is always assumed by the sim to be doing detection on base tonals like 50hz or 60hz, so I have to adjust the sensitivity based on detection as if it is a TA! The good news is that I can get the same kind of performance if I have the NRD lowered to a very low level. For example the TB-29 is at -14, and TB-16 is at -10, and the UUV sensor is at 7. (and that represents increments on a log scale, not linear). This means that very quiet contacts may not be detected at all or only at extremely close range. In short, you probably are not going to find a Kilo Imp moving at 3kts in 75ft of water with a UUV at all, and a nuke in the open ocean at creep speed only very very close. It is probably more a useful recon tool for general situational awareness to send it to sprint ahead and triangulate with ownship sensors or to see around and over obstacles. In ASW, it is probably only good AFTER the shooting has started to keep track of your opponent's evasion.

[Bellman]

LW: I have sent you my Test scenario file . The UUVs were launched and turned and observed over a relevant time
period at 6 knots which was the minimum attainable speed. No other actions such as classification, TMA etc
were attempted. Just left 'em to rock and roll, initialy, just like the stock ones.

Only a prelim. - my scenario file or the playtest zip may have become corrupted. I will have another look
at it and in the meantime if you have any other suggestions for reruns please let me know.

[LuftWolf]

If you just left them alone, then most likely the bearings will go off after a set period of time. Like I said, the GAME is giving you the bearings that result from the UUV making aTMA calculations. The way the game forces bearing error in the aTMA solution is interfering with the UUV sensor display.

This is present with the stock game as well.

The solution to this is to drop the contact before you try to read its bearing, the contact will immediately pop back up at the correct bearing, assuming you still have sensor contact.

Cheers,
David

[Molon Labe]

Are you sure its doing TMA on a bearing line? I figured it was just averaging the bearing over a time interval. And yeah, this is nothing new, you can notice it every time the UUV detects ownship for the first time.

[LuftWolf]

Are you sure its doing TMA on a bearing line? I figured it was just averaging the bearing over a time interval. And yeah, this is nothing new, you can notice it every time the UUV detects ownship for the first time.

That is entirely possible, but my suspicion is...

The sim engine isn't processing it as a bearing line, its doing the whole solution.

The interface only displays the calculated Tgtbearing for the solution. :know:

But you may be right.

[Amizaur]

Have you tried assign a HF sonar to UUV ? :) I'm curious what would be the result ? Would it return the + marks where the contacts are, like sub-mounted HF sonar ? Would be nice, you coukd detect mines with it and no problems with TMA at all ;)

[Bellman]

Perhaps I failed to explain myself clearly. My problem is that Mk 2 UUV is not behaving anything like stock UUV.

Out of 5 potential close targets in a scenario, it marks and updates only two. An identical target at the same depth,
speed and heading but at a shorter range, it ignores. Concurrently it established an opening track on a FFG
which it failed to update. Using 2 UUVs - same story !

I have replayed this scenario three times and another one twice with similar results. All UUVs launched at 4 knts
and at non-TIW depth.

This cant even be randomised behaviour as the pattern repeats. The mechanical performance is fine but the sonar
'dumbing down' process is excessive ! :nope:

[Bellman]

I have just swapped to Stock via JSGE to test comparitive Stock UUV performance in the same scenarios
and the UUV is behaving like Mk2 . So something went wrong in the Playtest installation. But what could . :hmm: :damn:

Heck that means back to first base :o :huh: :( Consider the following to indicate choice swearwords **#~!!@'' :hulk: ;)

[LuftWolf]

Bellman, DROP THE CONTACTS!

And btw, this behavior has always been in DW.

Testing is a process of sorting out whats different from what's always been. If you can't do that, there isn't much point in testing. :)

And if you revert back to the stock database and doctrines, it's reverted back, there is nothing that COULD POSSIBLY BE HELD OVER.

As you know, the database and doctrines are the only files altered, if you change those back to stock, the mod is gone. Period.

PS You need to read me notes more carefully, the UUV is supposed to launch at 4kts until you hit the enable button. ;)

[Bellman]

:huh: Well I will make allowances for your flu behaviour and complete misinterpretation of what I report.

<1> Dropping contacts, as usual, makes not a jot of difference to what I have reported.
Some closer contacts are ignored !! .....................Thats wrong !!

<2> When changing back to Stock via JSGME the UUV in STOCK is the Mk 2 with its speed/depth change
abilities and blindness !!.....................................Thats wrong !!

<3> ''the UUV is supposed to launch at 4kts until you hit the enable button'' Yep I think I managed to get that :huh:
If you were in a fit state to look at the dumps you would see that I had put a note on about the test UUV -
''NO SPEED OR DEPTH CHANGES.'' and above post ''All UUVs launched at 4 knts.''

Now if there is anything in the above that is'nt clear through the fog of flu let me know. :stare:

Thought attempting to kill the messenger went out in the Middle Ages ! :D
Little advice, returned in the same manner as your contribution - dont attempt work matters under the influence
of flu. It will keep and its easy to lose friends and colleagues. But heck I learnt that 30 years ago !!

[LuftWolf]

I understand about 35% of what you write generally... :roll:

Testing is not necessarily easy. Little of what you give me is useful data because you don't give any context for your reports other than "this ship was here and then x happened."

I need to know everything about the situations in order to get anything useful, especially because what you are reporting is wildly different than what I and everyone else is seeing.

[Bellman]

:lol: It continues ...in the same vein !

I have said the installation of the Playtest, in my game, is somehow flawed, at my end ? In transit ? Whatever !
The evidence for this, can you not see, is that after a JSGME change to stock - stock still gives me the Mk2 UUV .....Thats wrong.

It is the Mk2 because its speed (etc) can be varied in stock ! Once more, for the Queen....................in stock !

[LuftWolf]

I just looked at your test scenario.

Everything seems to be working fine on my computer. The only contacts detected are the two Russian ships, which are quite loud. I certainly would not expect any of the subs to be detected.

The FFG's are a marginal case, they are very quiet when running slowly. I think its fine they aren't detected on the UUV at those distances.

Actually, the UUV is performing very nicely in all aspects, in my opinion.

I think you maybe botched some kind of install somewhere.

Just unzip the distribution into your main DW directory, that ought to take care of any problems.

[LuftWolf]

:lol: It continues ...in the same vein ! Absent youself until recovered !

I do this "for a living." I've spent many many hours testing DW. I'm quite good at it. :)

Trust me, there is something you aren't doing right.

[LuftWolf]

Oh, some more things, be certain to clear the contacts if you decide to send your UUV into a sprint or if you have left it alone for a long time.

All of the contacts will become corrupted if given enough time because of the SimEngine and the interface, but it's not a problem for the player to have to do some work so the UUV isn't simply free data.

Basically, the rule is, every time you need a bearing from the UUV or want a complete, up-to-date picture of its what its hearing, clear all its contacts. Whatever it is tracking will reappear at the correct bearing. This is especially important to remember if you decide to reposition the UUV.

[Bellman]

LW: The only contacts detected are the two Russian ships, which are quite loud. I certainly would not expect any of the subs to be detected.

No - wrong. Look again at my dump. It detected a Kilo at about 8 nm and a surf further out ...BUT ignored a Kilo
(repeat at the same depth and speed) on an adjacent bearing and much closer.

However this is irrelevant as something srewed my instalation - so if you did actualy read my post of yesterday
I said so ''Its back to first base'' Tell me what is not clear about that.
Choose your 30% - any bit will do - try it ! :lol:

PS. Oh yes and thanks for the lessons in basic UUV deployment ENS !

[LuftWolf]

No, there is no possible way the UUV would detect a Kilo at that distance.

That is a corrupted bearing line from one of the Russian surface ships.

For example, the UUV will not detect a 688i at 4kts until around 500 yards.

So you are certainly misintepreting the tests.

I ran the same test on my computer, the only contacts detected are the Russian surface ships. I am very very very sure of this.

[LuftWolf]

The seven lines in your dump are: two ownship detections at launch, one UUV detecting the other one at launch, and the four bearings from to the two russian surface ships.

PS There is a possibility that the close FFG was detected, but that was at the extreme threshold, so it certainly went out of range, that is why it was not updated. That would make the seventh line an ownship detection, and the other four would be the russian surface ships.

This all looks just fine to me... still.

[LuftWolf]

And even if it isn't, there ain't sh*t I can do about it, because all I can do is set the sensor parameters, the interface isn't my department. :rotfl: :rotfl: :rotfl:

So in other words, this is what it is. It ain't going to get any better until SCS decides to look at it.

[Bellman]

Then if thats what you see we are not looking at the same dumps. I ran this scenario several times and have other
dumps showing exactly as I reported. Online/transmission interference again ? Its happened before !!
But I say again I think I can make the obvious distinctions you keep hammering-in !
What we see has been distorted ! Firstly by my faulty instalation and secondly evidently en route to you.

:lol: David are my earlier posts invisible ? I will say again (Heck how many times is this now)
REPEAT-'' My Playtest instalation is screwed '' - REPEAT ''Back to first base !''

I am just trying to revert and the LwAmi uninstaller still leaves the 'Blind' Mk2 UUV in situ IN STOCK.
So now its a complete reinstal - but lesson learnt this time there will be separate Stock and LwAmi versions
on different HDs.

On second thoughts I'll ice the UUV Playtest process - I can see where this is heading. ;)

[LuftWolf]

David are my earlier posts invisible ? I will say again (Heck how many times is this now)
REPEAT-'' My Playtest instalation is screwed '' - REPEAT ''Back to first base !''

No, but your use of english is often very Dickensonian... :lol:

Ok, so if its a messed install, then yeah, anything could be happening.

All you really need to do to have the mod on the same install is to be able to have Doctrine/Database folder sets stored and ready to be swapped in and out (completely), depending on what version you want to run. You can do this with JSGME, batch files, or simply using the delete, copy and paste commands in windows explorer.

[Bellman]

:lol: ''Heck how many times is this now''

Oh yes very Dickensian :o Well I will try NY taxicab stuff in future especialy targeted for USA readers.

My stuffs screwed man. Got it bud ! :rotfl:

[LuftWolf]

On second thoughts I'll ice the UUV Playtest process - I can see where this is heading.

Yes, if there are issues in your testing process that are unrelated to the material being tested, like operator error, I'd prefer that you don't test. ;) :)

[LuftWolf]

And where the heck are Molon and TLAM with the abundance of comments they ought to have about this? :hmm:

:cool: :D

[Bellman]

:lol: Maybe they dont fancy getting head-bashed and are lying low until the flu cloud moves over. ;)

LW: '' If there are issues in your testing process.....'' :lol: Are you running for the Senate ? Politico speak !
Repeat: The 'issues' here are in the Playtest software instalation. CICA.....My game is ********d ! *
Play the ball not the man, bud ! * ( * I am trying to adopt sympathetic vernacular .. Ooops )

Please advise if this is unclear :roll:

PS. Let me spell out the meaning of 'Icing' here. You/we/I will end up in a cul de sac with UUV Mk2 proposals.
You are going nowhere only backwards believe me - read the signs!

Expect advise to tune things down - accept it !

[LuftWolf]

What's unclear to me is the difficulty in saving and overwritting folders.

The "mod install" is a .zip containing 71 files. 14 of them are database files and will unzip to the Database directory, overwritting the 14 files already there. 56 of the files are .txt files that are doctrine files, which will be copied to Doctrine directory, overwritting the files there and creating new ones. The extra .txt file is the readme that will be copied into your main DW directory.

That's it.

If you take original copies of the folders and copy them back into the DW directory, your game is back exactly as it was before (some extra doctrine files may remain in your Doctrine directory that are new, but they aren't going to do anything but sit there).

So, yes, this is all very confusing to me, assuming that your game was not corrupted to begin with.

[Bellman]

:D Sorted - working properly now - and running 'that' scenario again the UUV performed as trailed !!

Ran her in at speed slowing from time to time for sonar and picked up the Kilo at 3 nm when it spooked,
at the incoming, dropped a CM and ran. But (SQ haunts me) a torp would have had the same 'spooking' effect
and my sub sonar did a better job at picking up the the spookee.

The real question to be answered is at what range Mk2 will pickup a loitering Kilo while the UUV is beeing
deployed in a stealthy approach.

Impressed with the ASuW sonar performance in my first proper run though.
The Jurys out on ASW though, but good luck with that element .

[LuftWolf]

:D Sorted - working properly now - and running 'that' scenario again the UUV performed as trailed !!

Ran her in at speed slowing from time to time for sonar and picked up the Kilo at 3 nm when it spooked,
at the incoming, dropped a CM and ran. But (SQ haunts me) a torp would have had the same 'spooking' effect
and my sub sonar did a better job at picking up the the spookee.

The real question to be answered is at what range Mk2 will pickup a loitering Kilo while the UUV is beeing
deployed in a stealthy approach.

Impressed with the ASuW sonar performance in my first proper run though.
The Jurys out on ASW though, but good luck with that element .

Great news. :up:

I'm glad everything is working the same on your comp as it is on mine. :rock: :)

In terms of ASW performance, subs running at "silent speed" are going to be invisible to the UUV. In the test scenario that I am using, my 688i isn't picked up even at 500 yards by the UUV! However, a 688i going 14kts, is picked up by the UUV at about 5.5nm.

Personally, I like the way this works a lot. You can move steathily all you want, but if you want to step on the gas, you better be sure there is no UUV lurking about! :know:

In gameplay terms, what this means is that the UUV is a good tool for ASW *after* the shooting starts, to keep track of an opponent's evasion. So picture this, you and your opponent pick each other up on the TA at about 13nm. You close with your opponent, taking multiple unpredictable legs on a closing course to get within good wire range. On your way in, you fire a UUV deep and try to run it by your opponent, hoping to pick him up. Once the TIW's start coming, your opponent decides to flee and he shows up the UUV, and with a nice triangulation from your TA or sphere, you get a good solution and guide your torpedo on target!

Cheers,
David

[Amizaur]

Just launched a mission just to confirm that the whole thing works - for Bellman. I would consider reinstalling DW, if you don't have original database and doctrines folders backed up, to restore original state.

UUV launches, changes depth and speed as advertised :-) But I'm little worried about sensor performace. First, it detects targets that are behind it !!! Has it omnidirectional sonar assigned ?? Have to look into db to check.
Second, it detected Ametyste class at 7kts from... 20nm :-/. It's not particulary quiet sub, but not a November after all. Also detects civilian ships from long way. :hmm: :hmm: :hmm:

Let me look into db... I see, almost omnidirectional (300deg) sensor... are we expecting such device in a UUV ? :hmm:

But the second thing is, that it's a LF, well, in fact VLF sonar !!! From ZERO to 1200Hz. Jesus, that's a towed array parameters !!! It has better frequency coverage than a large sub sphere sonar :-/.

It's tiny, it - just like torpedo seekers - should work in medium and high frequencies. What's the difference ? Limited detection range. And realistic performance... This was one of things I wanted to do for torpedo seekers, re-tune them to high frequency, it's also much easier det range controlling. But there is plenty of torpedo seekers, quite a work, and only one UUV seeker, and quite important one, so I think this should be done for it.

Please, anyone who knows, tell at what frequency range a modern passive torpedo seeker works. Or it can be estimated based on receiver physical dimensions IIRC ? Hm UUV sonar would have about 0.5m diameter. That equal to sound wave length at about 3000Hz.

On the other hand, 688I sphere sonar have set good sensivity limit at 800Hz (because I'm pretty sure it can receive even 50-100Hz sound, just with very poor sensivity). What it's physical size ? about half of sub hull diameter ? About 5m ? Then it's ten times larger than the UUV seeker (0.5m). Then corresponding good-sensivity limit for UUV seeker would be 8000Hz !!

Now, while working in VLF range, the UUV sensor when set to sensivity at which it can detect quiet contact at close or very close range, it will also detect a moderate or loud target at 10-20nm if not longer - just like towed array does ! HF passive sonar range would be less dependant on target noise level, or to say it another way, it would be range-limited - even very loud contacts unlikely to be detected outside effective range. High frequencies have much higher signall loss with range than LF, high frequency absorbtion, we all know this. That's why sphere sonars are limited in range. And UUV sonar is MUCH smaller than 688I sphere sonar !!

Of course same thing should be made to torpedo seekers, and I planned that, but it was much less important there, because torpedo seekers where hard range-limited by detection curves, so exccessive det ranges of loud targets was not a problem. When (and you say you are planning this) hard limits are being removed from torpedo passive seekers, this is a must too. It simply can't be achieved proper characteristics with curent 0-1200Hz freq range. When very quiet targets detected from 100yd, noisy civilian would be detected from 20nm or so... by a torpedo seeker. At 40kts.

I think you should take DWAnalyzer and compare 0-1200Hz seeker range characteristics with something like 3000-15000Hz seeker. By DWAnalyzer it's much faster and also much easier to understand the difference than in gameplay tests.

I think it's ABSOLUTELY unlikely than UUV passive sensor has better range against loud contacts than sub mounted Sphere or cylindrical sonar. If it was so, such sonars would be mounted on subs :-). And don't say me about OS self-noise, Kilo at stop doesn't produce more self noise than UUV at 4kts... If my sphere sonar didn't detect this 7kts Amethyste at 20nm, there is absolutely now way that tiny UUV sonar could here it.

BTW, single-sensor sonobuoys (are they such, or they are all line arrays like VLAD ?) should have no LF capabilities too. BUT then we couldn't use them to target identification, as there would be no frequency lines in low freq range... so they have to be LF in game. Unfortunately, the sensor sensivity in DW is same for all frequencies... maybe a solution would be give such object few sensors, covering different frequency bands, but with different sensivity ? I wonder if giving it's possible to give DIFAR a two or three passive sensors covering different frequency bands with different sensivity, and would this work ok with GRAM display ?? Can't remember now how are sensor/display connected in DW, can there be only one sensor assigned to a display ? I think this would work for AI sonobuoys (LOFAR?).

P.S. Oh yes, helo dipping sonar. First, I'm under impression that it's a davice few times larger than a torpedo seeker. Second - don't look at it's in-game characteristics. It HAVE TO be VLF capable, to allow players ident targets by frequency lines. But I'm quite sure, that in RL it's sensivity in this range is much lower than at medium frequencies. But in game you can set only one sensivity value for the whole range, so reducing it to give realistic results at VLF, would make it too deaf in higher freq. Again, I wonder if it's possible to assign two seekers to dipping sonar display :hmm:

To summarise:

- speed and depth changes works wery well, no problems. Also can't see how JSGME could NOT uninstall the mod, or uninstall it partially (??), most probably messed game installation...

- please change UUV passive sensor form VLF to HF passive sonar. We don't need to see low frequency lines from it, it has no display, it's an AI sensor in fact, so we CAN make it realistic in terms of frequency coverage and det ranges

- are you sure the UUV should have 300deg sensor cone ? Greater than torpedo, sure, but 300deg ? Maybe 180deg ?

- I would vote for UUV to have max speed 10-12kts. If not, and you insisted in 20kts max speed, then range at this speed should be MUCH shorter - even more than for torpedos. It's propulsion is probably optimised for long endurance at low speeds, and even if it was capable of 20kts (maybe it has smaller (but quieter) electric motor ?) it would strain the battery very much. 32km at 4kts, then 10km at 20kts. But better 10-12kts max speed with some range penalty. Maybe 32km at 10kts and more at 4kts ? On the other hand practical range at low speed would be probably only wire-limited. On the third hand ;-) the "wire" is probably a thin glass optical wire, not a copper wire, and in device of such size you can easily store 50NM of such wire ! There are even much smaller missiles with wire optical guidance (Polyphem to name one) with plenty of wire.

[LuftWolf]

- please change UUV passive sensor form VLF to HF passive sonar. We don't need to see low frequency lines from it, it has no display, it's an AI sensor in fact, so we CAN make it realistic in terms of frequency coverage and det ranges

Game engine ignores such values for the UUV. I left it as it was for reference.

[LuftWolf]

In terms of the sonar performance... I'm quite surprised by this. I tuned it so that it would never detect a contact before the sphere arrays...

In terms of the sensor coverage, I left it the way it was, I assumed this would be discussed.

The sensor performance you describe is a big surprise and is unlike anything I've seen.

[Amizaur]

Game engine ignores such values for the UUV. I left it as it was for reference.

I'm surprised. It's possible to change UUV sensor sensivity, but impossible to change frequency range ? Have to try it myself... right now, I'll set it to 1100-1200Hz and see if it reduces det ranges.

The mission I run, was simply Capitallists vs communists - there is Rubis at 7kts (non cav) which was detected by UUV right out of the tube from 20nm...

edit: I changed UUV sensor freq range to 1100-1200Hz and in the same mission it didn't detect anything (but me), and there were two cavitating Akulas and Type-206 10nm from me. Now reverting to 0-1200Hz...

Cavitating Type-206 detected from 28nm, Rubis 7kts from 15nm, many other contacts, just after leaving tube.

Yeah I know should test same scenario, but from above seems that what is set in frequency limits is making difference in UUV performance.

Now changing to 1200-12000 range...

OK, I have setup with some close targets, Rubis 7kts at 10nm. Launching UUV... didn't detect it. It even didn't detect a close freighter from 6nm !!!

LW, db freq range definitely works for UUV sensor for me. At least this is what I can conclude from above. Two times nothing detected with high freq limit (1100-1200 and 1200-12000), lots of targets, even far away, detected with stock 0-1200 freq limit.

P.S. Cross layer trawler not detected at 5nm, detected at 3.6nm, 1200-12000Hz freq limit. At what range is 8kts trawler detected by 0-2000Hz UUV sensor ? Freighters were even at 10-15nm if not longer...

P.S. Now, when I believe that frequency range is in fact working, I'll try to use DWAnalyzer to give some results for comparison. As long as there is no layers involved, DWAnalyzer sonar model is still very good.

Sea state 1, convergence (but above layer, target and sensor both at 60m/200ft, rock bottom, DWAnalyzer results, all tests on LwAmi302 database

Playtest One UUV, +7 sensivity, 0-1200Hz freq range

Akula II 10kts 180 meters
Akula II 5kts 12m
Kilo Imp 5kts 9m
Kilo Imp 0kts 5m
Rubis 7kts 300m (very strange, maybe mine was CZ contact ?? anyway it is detected by UUV from 10-15nm in every my test in CvC scenario)
Han 5kts 6500m
Han 10kts 12130m
Trawler 5kts 6700m
Cargo Ship 10kts 24000m
Cargo Ship cav 33000m
Supertanker 15kts 29000m
Car Carrier cav (most noisy sound in db) 43000m

so loud targets are detected from far ranges

Now +7, 1200-12000Hz sensor:

Akula II 10kts 10m
Akula II 5kts 4.8m
Kilo Imp 5kts 3.7m
Kilo Imp 0kts 2m
Rubis 7kts 213m
Han 5kts 1922m
Han 10kts 4630m
Trawler 5kts 2333m
Cargo Ship 10kts 10133m
Cargo Ship cav 16300m
Supertanker 15kts 12133m
Car Carrier cav (most noisy sound in db) 21850m

Now +7, 3000-12000Hz sensor:

Akula II 10kts 9.6m
Kilo Imp 5kts 3.9m
Rubis 7kts 212m
Han 5kts 1922m
Han 10kts 4024m
Trawler 5kts 2012m
Supertanker 15kts 12074m
Car Carrier cavitating 19230m


Now for comparison -3 (!!!), 3000-12000Hz sensor:

Akula II 10kts 250m
Kilo Imp 5kts 200m
Rubis 7kts 1920m
Han 5kts 6700m
Han 10kts 9400m
Trawler 5kts 7300m
Supertanker 15kts 18100m
Car Carrier cavitating 25500m

results for stock db -3, 0-1200Hz UUV seeker - later

P.S.

Hm, found something really interesting. I couldn't further decrease detection ranges by increasing freq limit over 3000Hz, even for 20000Hz ranges were the same. So I checked how frequency absorbtion values (visible in DWAnalyser) are looking for different frequencies. And I'm little disappointed.... Seems there is no frequency absorbtion function, only four discrete bands with fixed freq absorbtion coefficient value for each...

Results of freq. absorbtion for passive sonar at 50000m:

Hz 50km 1m (min value)

0 38 4
20 38 4
40 38 4
49 38 4
50 38 6
59 38 6
60 55 6
80 55 6
100 55 6
300 55 6
500 55 6
800 55 6
900 55 6
909 55 6
910 71 8
1000 71 8
1200 71 8
1300 71 8
1400 71 8
1477 71 8
1478 81 8
1480 81 8
1500 81 8
2000 81 8
3000 81 8
5000 81 8
8000 81 8
12000 81 8
20000 81 8

edit: I wonder if this changes with depth or conditions... maybe another time... no, checked this - at least in DWAnalyser water depth doesn't change frequency absorbtion value. So that's why in very shallow water we can get better propagation than on deep water !!!! (narrow sound channel, yes, but I believe in RL multiple bottom bounces should weaken and disperse the sound quickly, and the very low frequency sound waves maybe can't propagate at all when the sound channel is smaller than sound wave length ??). So that would be next thing to ask Sonalysts for - after discussing it with our experts here - to make frequency absorbtion value depending also on water depth and bottom type.

As can be seen, there are only 4 different values for whole range 0-20000Hz... Freq bands would look something like that:

0 - 59Hz 1 or 1.52dB/km
60 - 909Hz 1.45 or 2.2dB/km
910 - 1477Hz 1.87 or 2.84dB/km
1478 - 20000Hz 2.13 or 3.24dB/km

little strange... comparing this to this graph:

http://www.fas.org/man/dod-101/navy/docs/es310/SNR_PROP/IMG00005.GIF

on the graph in 1000-10000Hz range, freq absorbtion changes 100x !! At 10kHz it's one dB for 1000m, at 1kHz it's only one dB for 100.000m. Is that graph good ?

And we have... one freq. absorbtion value for this band !!! Any thoughts ??

According to the graph, between 100Hz and 1kHz real frequency absorbtion in water increases about 100 times. 100 times (in dB already - because coefficient value is in dB/m). In DW seems that between 100Hz and 1kHz there is difference of only about 1.44-1.87 times... :o What's up ?

In original DB there are values 100, 300 and 800Hz used. From data above it would seem that 100 and 800Hz are valid but 300Hz would not make any difference as it comes into same band as 800Hz... This has to be checked in gameplay tests - is there is ANY difference between 300 and 800Hz sensor...? BTW the minimum possible (at 1-100m distance) frequency absorbtion values are greater than zero (-4 at 0Hz to -8 above 1000Hz) and this value has only 3 freq bands... How there can be frequency absorbtion loss of 4 to 8 game dBs (8 to 16 real life dBs) at 1 meter distance ??? All this is little complicated, I'm far from understanding fully how this works in DW :-/.

So in fact there are only 4 sonar "performance" bands, depending on sonar min frequency value. Anything higher than 1500Hz doesn't make any difference. I would suggest to set UUV sensor min. frequency to 1500Hz to get the last, higher frequency absorbtion.

P.S. While searching for frequency absorbtion graphs on the web, i've found this:

http://www.npmoc.navy.mil/KBay/oceano.htm

Absolutely fantastic site with lot's of sound propagation examples and info !!

[LuftWolf]

Huh?

I tested the sh*t out of this...

[LuftWolf]

Let me say for the record that this whole UUV business if beginning to thoroughly p*ss me off.

Just one frustration to the next...

I tested the UUV at 1200-2000 and no change what so ever.

I tested the UUV from 1800-2000 and I get something difference.

Just like there is a fairly predictable sensitivity curve up to 7, and then after 7, it just drops way the heck off.

There is no good predictable way for this behavior to be calibrated with the other sensors... a player sensor with sensitivity 1800-2000 and 7 would be basically useless. I'm just going to have to do this all from the seat of my pants and test it with every kind of contact.

Every time this is run, its giving someone a different result from the next person, based on some minutae BS.

Obviously, if I thought it would do anything, I would have changed the frequencies sensivities.

So everyone just ignore the UUV sensor for now. When I'm not really frustrated by this whole thing, I'll work on it again. :nope:

[Amizaur]

a player sensor with sensitivity 1800-2000 and 7 would be basically useless. Of course when you reduce frequency band, you can simultaneously increase sensivity by few points to restore planned performance for quiet contacts. And range for loud contacts will be still shorter than before.

Well UUV sensor is in fact AI sensor (no display, detections handled by AI) so can't be compared directly to human player sensor specs...
I see dramatic difference in performance between 0-2000 and 1200-12000 or 3000-12000 sensor. To be sure, I'll try tomorrow to make a test mission (instead of taking CvC one) and get clear results (det ranges for both) and then send you the mission for you to check if you get the same results as me. My new specs for UUV passive will be 1500-12000Hz (however I think 1500-2000Hz sensor would work exactly the same...)

Such sensor would be impossible for human player platform, as there is not many discrete lines above 1500Hz, so in most cases there would be nothing on NB display to identify :-). Only BB would show trace...
But for AI seems to be no problem - even 3000Hz up sonar works without problems, detects targets even though there is no discrete lines above 2000Hz in the game, highest are around 1800Hz.

[LuftWolf]

Really, I never even thought about that! :o

That's great news! :D

Thanks Amizaur.

Cheers,
David

[LuftWolf]

BTW, you have the 1.03 Analyzer version? :doh: :o :up:

May I have that please? :)

Cheers,
David

[LuftWolf]

edit: I wonder if this changes with depth or conditions... maybe another time... no, checked this - at least in DWAnalyser water depth doesn't change frequency absorbtion value. So that's why in very shallow water we can get better propagation than on deep water !!!! (narrow sound channel, yes, but I believe in RL multiple bottom bounces should weaken and disperse the sound quickly, and the very low frequency sound waves maybe can't propagate at all when the sound channel is smaller than sound wave length ??). So that would be next thing to ask Sonalysts for - after discussing it with our experts here - to make frequency absorbtion value depending also on water depth and bottom type.

Amizaur, in this case, I'm not sure the analyzer is kicking back the correct result... for a shallow rock bottom limited environment, the signal travels quite far, but for a mud and sand bottom, the distances drop off very rapidly.

The rock bottom limited environment may transmit signals better than the top level of a surface duct, but the mud and sand bottoms create a very bad acoustic environment, especially in shallow water. Am I understanding your analysis correctly?

[LuftWolf]

Amizaur, the frequency ranges for the UUV aren't doing anything on my computer. :-?

[LuftWolf]

The good news is that it really doesn't have to matter... as long as I can set the NRD the way it needs to be, the actual detection ranges will be the same, since DW isn't using a multichannel model anyway, just using an algorithm to determine signal loss as a function of frequency... SO, if I change the gain of the sensor capable of detecting 50hz signals to detect them at a range equivalent to the sensor with a higher signal gain detecting only the same contact at 1800hz, the end result will be exactly the same, in DW terms.

Gosh this has been any annoying problem. Ok, so the end result is that I'm going to reduce the sensitivity of the UUV even further from where its at, perhaps to about +15.

[LuftWolf]

I have posted the LWAMI Playtest One WITH ATP correction to the CADC:

http://www.orionwarrior.com/forum/showthread.php?t=29521

From the playtest readme:

To Install: Unzip the file into your main DW directory allowing the unzip program to overwrite all files and install to the correct directories.

This playtest should be considered a beta. It combines LWAMI 3.02 with the following changes:

ADDED IN THE ATP VERSION

UUV-The UUV sensor sensitivity has been reduced and given a hardcap of about 20nm. Also, the range of the UUV is now greatly reduced by running it at high speed, especially at 20kts. Also, and I just noticed this although it appears on my computer to be in the stock game as well, the course of the UUV is going to be off whatever is indicated in the fire control panel controls by the firing angle of the torpedo tube that fired it... I can't correct this, but I tried, although it doesn't seem like a big deal to me. :-P

UGST and ADCAP- I have tuned the wirewatch sensor and doctrines. The only ownship condition now monitored by the wire is the distance from the launchpoint of the torpedo... this is measured as a radius. I can't have it be the truerun of the submarine because the doctrine isn't getting good info from the Sim. Again, this is fine in my opinion because it allows the submarine some loiter capability. Also, the Enable distance and the wiredistance for the torpedo are now measured as the true distance run rather than the radius distance from launchpoint. AND THE MOST IMPORTANT THING: the Advanced Torpedo Physics have been implimented for the ADCAP and UGST, so that means they will run farther when slower and running more shallow (although the database still needs to be updated to fully take advantage of this at the extreme long/slow range/speed settings).

END OF THINGS ADDED IN THE ATP VERSION

Advanced Torpedo Control Mod for UGST and ADCAP:

Set the torpedo to fire as normal. If you don't use the wire commands, it will behave as always. The wirecontrol commands are now as follows. Note, you must wait at least a second of game time between clicks, but it is possible to hit the button several times to go through the cycle quickly. A single preenable click will preenable the torpedo if it is enabled or do nothing. A second preenable click will send the torpedo to the preset search depth. A third click will send the torpedo to the ceiling. A fourth click will send the torpedo back to launch depth. The enable button works as follows. A single enable click will set the torpedo speed to 40kts and enable the passive sensor. A second click will enable the active seeker on the torpedo and set the speed to max speed. Further clicks of the enable button have no effect on the torpedo unless it is preenabled again, and then the behavior is reset to the beginning of the enable cycle.

WireBreak Mod:
Wires are now limited in range and ownship maneovering parameters. The ADCAP has a 10nm internal wire and a 5nm wire on the launching platform. If the torpedo or ownship travel farther than those distance FROM THE LAUNCH POINT, or if the range between ownship and the torpedo exceeds that distance, the wire will break. The UGST has a 25km internal wire and a 5km wire on the launching platform. Additionally, if the opening speed between ownship and the torpedo exceeds about 60kts for the ADCAP or 55kts for the UGST, with ownship movement accounting for no more than 20kts of that calculation, the wire will break. These maneovering measurements are unintentionally fuzzy, however, it is something that occurs naturally that I was going to build in anyway, so it works nicely. :-) What this means in practical terms is that a slow running torpedo gives the launching platform much more flexibility in maneovering the ship, whereas a torpedo running at maxspeed is much more prone to a maneovering-related wirebreak. NOTE: When the wire is broken, its broken. However, sometimes the interface will momentarily display the torpedo as preenabled, but it reenables soon enough not to effect the game in any way. The only unfinished part is that you can still shutdown the torpedo even after the wire is broken... we can't take this out. However, it is very minor, in my opinion, seeing as the user would typically reload his tube after the wires are broken anyway. ;-)

Advanced UUV Mod:

The UUV is much more quiet now, and is very hard to detect without cavitation. The passive sensor has been reduced in sensitivity considerably and the active sensor has been disabled completely (mostly because its broken in DW 1.03). The UUV now has a range of 32km and max speed of 20kts, with the sensors effective up to 6-8kts, with washout above 6kts. The operation is as follows. You must be at 4kts as before, and enter the presets in the same way. After firing the weapon it will begin to feed back data immediately and move at 4kts. The speed of the UUV is controlled with the enable button and the depth is controlled with the preenable button. The preenable button has no effect on the passive sensor. One click of the enable button will stop the UUV; it can persist indefinately in this state (although I will most likely have a timer on it in the full version), a second click will speed the UUV up to 6kts. A third click of the enable button will speed the UUV up to 12kts, the max speed the UUV can travel in up to 90ft of water without cavitating. A fourth click of the enable button and the UUV will go to its max speed of 20kts. A fifth click will stop the UUV and reset the counter, although you can click the enable button twice slowly and set it to 6kts. Note the sensors are washout above 8kts and do not feed data. The preenable button depth control works as follows. A single click does nothing. A second preenable click will send the UUV to the preset search depth. A third preenable click will send the UUV to 90ft if it is in over 100ft of water or 45ft if it is in less than 100ft of water. A fourth click will send the UUV back to launch depth, and reset the cycle.

SLAM-ER and Misc. Missiles:

The SLAM-ER now works for ASuW use and will enable a radar seeker at the last waypoint if it is over water. If the last waypoint is over land, the missile will operate in Strike mode, and behave as a light TLAM. The missile has a stealth enable feature that sends it down to just above the ocean before enabling and then after enabling it rising back to its cruising altitude of 30ft. Note, the standard harpoon has also been giving this cruising altitude, and the flight profiles of various missiles have been lowered. Also, the standard SLAM has been fixed and equipped on the AI P-3 as a land attack missile because the AI can't use the SLAM-ER properly. The AI P-3 does carry the Harpoon for ASuW. The Harpoon and the SLAM-ER both have a 40 Radar PSL, which is very low.

Helicopters:

I have attempted to fixed several problems like crashing and reporting contacts at launch, as well as dragging the active dipping sonar. Please use the FFG AI MH60 as well as observe helo behavior in general. :-) Also, the MH60 no longer launches with its radar on. :-)

CIWSAttack Doctrine has been updated to give better intercept performance will allowing for appropriate missile conservation for sustained attacks.

I made a minor change to the TLAM doctrine to make sure it always explode near the target as opposed to disappearing if it overshoots.

The Random Direction Torpedo Mod has been disabled for all torpedoes to allow more predictable subroc and AI MH60 weapon delivery. The torpedoes will always go to the right upon enabling.

The Hull array of the SW has been changed to simulate what we believe to be more close to the actual sonar suite on the SW. The Hull array on the SeaWolf now represents a low frequency receiver with coverage slightly larger than the Sphere array and with the same geometry. The frequency sensitivity and and washout speed remain as before. This sonar suite should be very helpful for tracking evading targets and as well as for all situaions in the littorals where the TA cannot operate.

The Maxspeed of the MPT torpedo payload on the SS-N-27 ASW has been reduced from 55kts to 45kts. This is done partially because the torpedo probably is closer to that speed as well as to reduce the effectiveness of the SS-N-27 relative to the new torpedoes behavior.

That's it!

Please play the heck out of this, specifically looking into these things I have mentioned here and provide as much feedback as you can through the usual channels. :-)

Cheers,
David
LW

Please do not post this file to any other site, as it is NOT an official LWAMI distribution. Thank you.

Cheers,
David

[LuftWolf]

And, of course, I forgot to mention the "obvious", the ADCAP and UGST will run slower when deep. :)

[Amizaur]

LW, so 1500-3000 UUV sensor works for you ecactly the same like 0-2000 ? On my comp difference is so drastic like between detecting targets 10-20nm out just after launch, and detecting nothing at all initially, only if distance reduced to less than 2-3nm.

And if you mean there is no difference between 0-2000Hz +5 sonar and for example 1500-3000Hz -5 sonar, then I didn't checked this precisely, but for other sensors there was a clear difference (low frequencies propagate far, high freq sonars are semi-capped in range, even very loud contacts are muted at longer ranges), and I think I have seen the difference for UUV sensor too - the proportion between loud target det ranges and quiet target det ranges was quite different.

For example, low freq sonar that detects Akula II 5kts from 300yd, detects noisy civilian from 20+ nm

high freq sonar tuned to detect Akula II 5kts from 300yds, detects noisy civilian from 5-7 nm only. Thats the difference (of course numbers are pure example) And it could be even greater if there were more frequency absorbtion bands above 1500Hz in sonar model... :-/ But now seems (in DWAnalyzer) that highest frequency that matters is 1500Hz... have to check if it's the same in game, there is no passive sensors set to lower limit above 1500Hz in original DB, but there are active sensors with much higher freqs.

P.S. I wonder if we are using same game version to tests and if not maybe that's why we see different things :lol: I have single install of the game only, if it's telling you something ;)

[LuftWolf]

I tried the version of the game you are using a bit... and nothing.

I am really getting no effect whatsoever from the frequency range.

[Molon Labe]

Is there any data available (or about to be available after you get some rest?) on the effects of the ATP?

I was thinking something along the lines of a chart with x=speed, y=range with a few representative curves for different depths or something like that. Really, anything just to give us a ballpark idea how it's actually going to work. =)

[jsteed]

Hi,

You may be making things more difficult for yourselves than need be. The sonar sensor model is a very simplified one. It only cares about one frequency. For this discussion, I will create a vessel profile with freq1 = 50, freq2 = 125, freq3 = 320, freq4 = 1050, freq5 = 1500. Now lets create 2 sensors, one is a LF sensor with a freq. range of 10-800. The other is a MF sensor with a freq range of 1000-3000.

When using the LF sonar, the only freq. of interest is freq3. (320). If freq3 happens to be 810 instead of 320, the LF sensor will not see the vessel. Freq1 & 2 play no roll except to add individual lines to the narrow band display.

The MF sonar only cares about freq5. If the line at freq5 is outside of the MF range, again, the vessel will not be seen. So changing freq5 to 3500, will make the sensor useless.

If we create a sensor with a range of 10-3000, the only freq. of interest is freq5, (1500Hz).

At least this is how the model worked for SC and DW1.01. I put the game away after that.

This simplified sensor model was created in order to save cpu cycles. The game only has to worry about one discreet freq. instead of many.

cheers, jsteed

[Amizaur]

Hi,

The MF sonar only cares about freq5. If the line at freq5 is outside of the MF range, again, the vessel will not be seen. So changing freq5 to 3500, will make the sensor useless.

It's indeed very simplified, what have striken me lately is the extremely crude frequency absorbtion modeling, well at least if it works like Ludger's tool shows.

I have made even 8000-20000 and 19000-20000 AI sensors for UUV and they did detect contacts. As there are no discrete lines at all that high, they really should be useless in game but they worked, probably exactly same like a 1500-3000 sensor. I will reply te tests to be absolutely sure, probably will try them on torpedos too.

P.S. From what freq up a passive sonar is treated by game as an MF passive ? Or is there a separate flag for it in DB maybe ?

[Molon Labe]

Instead of making LW or Ami do this for us, I went into the doctrines myself, and after much head scratching and fist pounding, came up with this... I think this is simple enough to do in combat if you have a calculator handy. =)

Range, Variable with Speed
ADCAP Range = 27 - 6(SetSpeed - 40)/15
UGST Range = 27 - 6(SetSpeed - 35)/15
(short version, every 5 knot decrease increases the range by 2nm, from a base range of 21nm)

Range, Variable with Depth
ADCAP Range (and speed) reduction = .29(depth{feet})/3000
UGST Range (and speed) reduction = .2(depth{meters})/735

LW, Ami, if this is wrong, please correct me.

[Doc Savage]

Not sure if this is a problem with the new mod version or the way I installed it...
I've noticed two problems with the FFG controls for the Helo (when AI helo is controled by the FFG)

1) Whenever I assign a waypoint to the helo I find that the helo takes a while to start dipping. It circles around a bit around the waypoint and then drops down to dip.

2) This is a bigger problem, sometimes if I assign a waypoint to the helo while it's dipping, it ignores the new waypoint. It's the damnest thing. Assign a waypoint, it does nothing, delete it and assign a new one, it rises and moves a bit but then goes back to dip at the same spot. (it doesn't matter what kind of waypoint it is - Fly to, buoy, torpedo) This problem comes and goes. I could play a mission for an hour or so and then this happens. (I checked the usual suspects. The helo is within range of my FFG, It's in Sync)

Like I said, I'm not sure if it's just my install or a bug. Thought you should know...

[Bellman]

Nice work there Molon - Thanks. :ping:

When you are ready, I hope that you will post this info. up at CADC.

Heck you're busy - looks like we should recognise a MoLab version of DW as your contribution/s warrant it. I'm trying to find a non-Dickensian phrase translation for that NY wizard ;)
So the best I can do is 'Yuse d' business man !!' :|\\

NB. This advertisement was paid for by ALOLL (American League of layabout lawyers )

[LuftWolf]

Not sure if this is a problem with the new mod version or the way I installed it...
I've noticed two problems with the FFG controls for the Helo (when AI helo is controled by the FFG)

1) Whenever I assign a waypoint to the helo I find that the helo takes a while to start dipping. It circles around a bit around the waypoint and then drops down to dip.

2) This is a bigger problem, sometimes if I assign a waypoint to the helo while it's dipping, it ignores the new waypoint. It's the damnest thing. Assign a waypoint, it does nothing, delete it and assign a new one, it rises and moves a bit but then goes back to dip at the same spot. (it doesn't matter what kind of waypoint it is - Fly to, buoy, torpedo) This problem comes and goes. I could play a mission for an hour or so and then this happens. (I checked the usual suspects. The helo is within range of my FFG, It's in Sync)

Like I said, I'm not sure if it's just my install or a bug. Thought you should know...

I'm pretty sure I know where this behavior is coming from, I need to add a variable check to a search section that was previously broken that I left in from the stock doctrine to make sure the MH60 doesn't get a mind of its own and start thinking it is some other helo that is free to do such things. I fixed the section, but because it was broken previously, I'd never thought to update it to make sure the MH60 doesn't use it. Thanks for letting me know. :)

Cheers,
David

[LuftWolf]

@Jsteed The new 1.03 sonar model is more or less completely different from the previous models in several important ways, although I'm not sure if frequency absorbsion is one of them. Thanks for the information, I'll have to try them for the playable sensors and see what I can come up with.

@Amizaur and Jsteed The UUV is just a big pain... at the end of a lengthy testing process, I basically just said 12+ and screw it, the playtesters will let me know if it needs to be changed. :know: Thanks guys.

@Molon and Bellman You see, here is Amizaur's real genius. His ATP mod calculates the fuel flow of the torpedo for each set speed and then removes that from the set torpedo fuel value in the doctrine each cycle. So in other words, the range of the torpedo doesn't just matter for the speed set, but rather for all the speeds the torpedo takes until it runs out of fuel, just like an automobile or a plane... if you step on the throttle, that means you are using more gas. Each weapon has a most efficient power band in terms of fuel consumption vs. distance, and for torpedoes that tends to be about 60% of its max speed or so (at least according to Amizaur's calculations).

So, in other words, the range of the torpedoes *depends*... on a lot. (And don't forget the various depth changes the torpedo has taken on its run, these are factored in as well for non-electrics)

Cheers,
David

PS I told you we were going to mod the hell out of this MFer.

[Bellman]

Phew ! Impressive ! :rock:

Now if I could only persuade someone out there not to extract all the UUVs teeth (in one go !) I mean like leave it with one canine and a molar - even half a bites better than none ! :damn:
Surely it should track CMs at + 3 nm ? Even if thats gamey.

I still cant control my torps properly after RTE in my (?) Playtest :hmm: So either thats the PT, my installation or (GF) me .......(indent for a new head ? If only !! :lol:)( Maybes Molon could donate a few grey cells - he has more than his share :yep: ) .................Life just aint fair :cry:

[LuftWolf]

Actually, no the active CM's are very quiet... in fact, the UUV definately should NOT pick up active CM's on passive sonar.

The UUV is fine, trust me. It can track shipping, torpedoes, and fleeing submarines. It has speed and depth controls, and a battery-drain calculation in the doctrine for range vs. speed.

What more could you possibly want in a UUV? :cool:

As an aside, Fragmaster just reminded me to test the MH60 and P-3 lookout visual sensors to see if they can detect submerged submarines for the player (on the topic of transparent water) and, in fact, they *can*!

So, while we can't have transparent water, LWAMI will make the water "transparent" for your automated lookout crew. Using the SAM launcher is now less appealing than ever! :arrgh!:

Cheers,
David

[Bellman]

David - you're very quiet on post RTE torp control - if its working OK then what the heck am I doing wrong ? Nobody else has pitched in (yet :roll:) I had the same problem with Amis original - I'll dive it again. :damn:...and again ..................Recap - I take control pre-RTE no problems with entire new control system. But let her run and enable and I cant establish steerage or depth and speed control :hmm:

Back to sea !

[LuftWolf]

It works fine for me.

If a torpedo is on the wire, and it enables on its own from the RTE preset, I still have total control over torpedo until the wire breaks.

I don't see anything in the doctrine that would cause that to be happening. :hmm:

[LuftWolf]

I do, perhaps, see a problem with your testing method.

If you enable the torpedo before it reaches RTE, and then preenable it again, the RTE feature is disabled if the RTE is reached before the wire runs out.

In other words, if you set a RTE that is 5000m, and the torpedo runs 3500, and you enable it, and then preenable it again at 4000m, the torpedo will not enable again until the wire breaks.

In the same scenario, if you had set the RTE to 20000m, the torpedo would not enable again until the torpedo hit RTE, even if the wire is broken.

So, I think you may be confusing the wirebreak point with your RTE point if you are testing the torpedoes enabling them first and then preenabling them.

Try this. Set a torpedo to RTE of 1000m. Launch it, let it run. After it enables try to control it. Do the same and this time enable it before it hits the RTE range, and then preenable it again. You should not see the torpedo enable again until the wire is broken.

These are all features designed to make the torpedo more effective to use, we hope.

Cheers,
David

[Bellman]

David - Prior to reading your post above I had returned from testing again after some tweaking to my dam**d system. ( the game install !)

I am very happy to report that my previous problem of lack of control after allowing the torps to run (untouched) to RTE has disappeared completely. The birds flew beautifully after RTE - they did everything I asked of them (direction/depth/speed. )
Sorry for my flak !! A very sweet job gentlemen - thanks a lot !:|\\:D:sunny:

I will revisit enabling the torps prior to RTE :hmm:

[LuftWolf]

I really thought there would be at least a few major bugs. I'm actually really happy to hear that you guys are only reporting "minor problems". :up:

All of the work that has to be done is really just making new versions of the work that's already complete, and a little bit of bonus work for some really nice features on the wireguided torpedoes which I hope will really work out nicely. And of course the ever popular database tuning.

That's for the torpedo changes... then there is a about 35% of the work to go on other things for LWAMI4, but nothing compared to the torpedo mods in terms of difficulty and time.

Cheers,
David

[LuftWolf]

Each weapon has a most efficient power band in terms of fuel consumption vs. distance, and for torpedoes that tends to be about 60% of its max speed or so (at least according to Amizaur's calculations).

So, in other words, the range of the torpedoes *depends*... on a lot. (And don't forget the various depth changes the torpedo has taken on its run, these are factored in as well for non-electrics)


I should have said here that the most efficient power output is at about 60% *throttle*, not 60% of maxspeed, because the fuelflow is calculated based on throttle, not speed as the decrease of speed on depth does reduce speed for the same amount of fuel used, and thus reduces range at greater depth.

[Deathblow]

Suggestion:
I've found that the Passive Sonar sensor on torps don't really wash out until about 45knots. Perhaps a automatic passive sonar speed of 42-45 knots would be better than the current 40knot value.

[Molon Labe]

I really thought there would be at least a few major bugs. I'm actually really happy to hear that you guys are only reporting "minor problems". :up:

All of the work that has to be done is really just making new versions of the work that's already complete, and a little bit of bonus work for some really nice features on the wireguided torpedoes which I hope will really work out nicely. And of course the ever popular database tuning.

That's for the torpedo changes... then there is a about 35% of the work to go on other things for LWAMI4, but nothing compared to the torpedo mods in terms of difficulty and time.

Cheers,
David

Well, actually, now that you mention it, I had a problem with an AI Seawolf that was firing ADCAPs that immediately dissapeared. Well, I think it was the Seawolf shooting ADCAPs anyways, there was nothing on the map to look at to confirm. Just a TIW alert and a SW that appeared to have been tracking a nearby target.

[jsteed]

Hi Amizaur,

If the sensor range does not overlap either freq3 or freq5, then it defaults to a freq of 0. So in my example if a sensor has a range of 0-300 or 400-1400 or 10000-20000 then the detection distance is the same in all three cases. Since the freq = 0 then the detection distance is greater than if the sensor range overlaps freq3 or freq5. Do you see a clever cheat here? :know: When creating sensors it is critical to make the range large enough so that every vessel will have freq3 or freq5 included.

There is no definition for LF, MF or HF. I use LF = 20-1000, MF = 1001-10000 and HF = 10001 and above.

cheers, jsteed

[LuftWolf]

Well, actually, now that you mention it, I had a problem with an AI Seawolf that was firing ADCAPs that immediately dissapeared. Well, I think it was the Seawolf shooting ADCAPs anyways, there was nothing on the map to look at to confirm. Just a TIW alert and a SW that appeared to have been tracking a nearby target.

I told you, the AI isn't going to be able to use the ADCAPs and UGST's in this playtest version, but thanks for confirming it. ;)

[Fish]

Hi Amizaur,

If the sensor range does not overlap either freq3 or freq5, then it defaults to a freq of 0. So in my example if a sensor has a range of 0-300 or 400-1400 or 10000-20000 then the detection distance is the same in all three cases. Since the freq = 0 then the detection distance is greater than if the sensor range overlaps freq3 or freq5. Do you see a clever cheat here? :know: When creating sensors it is critical to make the range large enough so that every vessel will have freq3 or freq5 included.

There is no definition for LF, MF or HF. I use LF = 20-1000, MF = 1001-10000 and HF = 10001 and above.

cheers, jsteed

Masterminds..........:doh:

[LuftWolf]

Hi Amizaur,

If the sensor range does not overlap either freq3 or freq5, then it defaults to a freq of 0. So in my example if a sensor has a range of 0-300 or 400-1400 or 10000-20000 then the detection distance is the same in all three cases. Since the freq = 0 then the detection distance is greater than if the sensor range overlaps freq3 or freq5. Do you see a clever cheat here? :know: When creating sensors it is critical to make the range large enough so that every vessel will have freq3 or freq5 included.

There is no definition for LF, MF or HF. I use LF = 20-1000, MF = 1001-10000 and HF = 10001 and above.

cheers, jsteed

But the whole method of using the frequency ranges at all to alter detection ranges is a matter of simplifying the math... couldn't you get the exact same performance from a sensor responding to 0hz as one responding to freq5 if you set the NRD's to be equivalent?

[jsteed]

Luftwolf wrote:
But the whole method of using the frequency ranges at all to alter detection ranges is a matter of simplifying the math... couldn't you get the exact same performance from a sensor responding to 0hz as one responding to freq5 if you set the NRD's to be equivalent?

If the dynamic range is great enough I suppose you could create sensors like this, but why would you want to? The idea behind SA's sonar model is that every vessel emits all of it's sound in two discreet frequencies. They happen to be freq3 & freq5.

So let's say there are two vessels, each with a noise output of 75. One has freq3 = 300 and the other has freq3 = 500. The one with a freq3 = 300 will be detected before the other. This is also true in real life. If all sensors were frequency independent, then both vessels would be detected at exactly the same distance.

The flaw in their model occurs if a sensor does not cover either freq3 or freq5. Instead of setting the freq. to 0Hz, they should have used some nominal value such as 1kHz.

cheers, jsteed

[Amizaur]

Instead of making LW or Ami do this for us, I went into the doctrines myself, and after much head scratching and fist pounding, came up with this...

I'll make some Excel tables and plots for you, as usually :) they definitely ARE needed to know what range and speed expect in given situation, just didn't know they will be needed so soon. I'll try to make it tomorrow maybe.

[Amizaur]

If the sensor range does not overlap either freq3 or freq5, then it defaults to a freq of 0.
cheers, jsteed

Thanx jsteed, that explains a lot :up: Now I have to check my 19k-20k sensor again and see if it works like 0Hz sensor... and if freq absorbtion ranges are calculated not for sensor freq but rather for discrete lines freq, that would explain why I noticed so little and discrete values for freq absorbtion function :D I'll compare it with active sonar also.
And have to write down all the 3rd and 5th freqs from db to see what freq ranges are possible to use...

Lw, I wrote this somwhere already, if you have two sensors, one LF and one MF, then even if you set the nrd value to get same detection distance against one (quiet for example) target, you get (at least should!) quite different det ranges against other (loud) contacts

for example, two sensors:

LF sonar, nrd set for 1nm against Akula 2, then 25nm against supertanker
MF sonar, nrd set for 1nm against Akula 2, then 10nm against supertanker

the difference in DW sonar model is maybe little smaller, but you can see it clearly on this example.

[LuftWolf]

Ah gotcha. :|\\

I'll work on this some more once the torpedoes are done (holding the design in my wetware is taking up system resources :88) ).

Cheers,
David

PS In fact, this comes just in time FOR the torpedoes themselves. Thanks for this data... I'll find out what I can do with it very shortly. :up:

[Molon Labe]

I'll make some Excel tables and plots for you, as usually :) they definitely ARE needed to know what range and speed expect in given situation, just didn't know they will be needed so soon. I'll try to make it tomorrow maybe.

Does that mean that the equations I posted are wrong????

[Amizaur]

Does that mean that the equations I posted are wrong????

They are most probably correct :up: (I didn't checked them) but the nice graph is speaking to me better than equations, so I though it will be helpfull anyway :)

[Molon Labe]

They are most probably correct :up: (I didn't checked them) but the nice graph is speaking to me better than equations, so I though it will be helpfull anyway :)

I actually find numeric tables to be better for that sort of thing. I made one using speed and depth input into those equations to get a range result. =) It will soon have a place right next to my NL tables. :up:

[Amizaur]

So check your equations if they are consistent with those thables and graphs (I'll take a look at them myself too hm I'm putting them into my spreadsheets to see if I get correct results ).

So, I had something like that on my mind:


Most important parameters of all new torpedos:
http://img184.imageshack.us/img184/5672/lwamiplaytestonetorpedostable1.png

(note: the standard long range mode is 40kts (passive speed) for ADCAP and 35kts for UGST. But you may note that minimum speed is listed as 30kts for ADCAP and 25kts for UGST, and running torpedo that slow will give you some extra range even outside 27nm. And it's all you can get, because torpedo will not slow down below it's minimum speed (if you set 10kts for example you still get 30kts) so it's absolute maximum range of weapon in the mod - about 31nm/30kts for ADCAP and 35nm/25kts (maybe this will be limited by db value as it's little long) for UGST. Anyway very slow run can give you more endurance (loiter time) or time to move away from launch point without spending much of torpedo fuel, then when ready you can speed up torp by enabling it. In real life VERY low torpedo speeds (in 10-15kts range IIRC) results in longer run but suprisingly smaller torpedo range, because torpedo (having negative buoyancy) runs at high angles of attack which increases drag and decreases speed and fuel effectiveness... and many torpedos simply don't have such low speed settings, engines were designed usually for two or three fixed speed settings only.)



Below table and graphs are valid ONLY if playtest one version of torpedos uses the parameters shown above ! LW if you have changed something in torpedo parameters, tell me I'll make another graphs (and send you spreadsheets to make them too).

Speed and range at various depths for ADCAP and UGST:

http://img306.imageshack.us/img306/638/lwamiplaytestonetorpedostable2.png

ADCAP - graph shows how the speed and range decreases with depth for two speed settings - 55kts and 40kts. But for other settings speed decreases with depth in the same way - linear.

http://img306.imageshack.us/img306/1377/lwamiplaytestonetorpedosgrapha.png


Same for UGST - speed and range decrease with depth

http://img306.imageshack.us/img306/9188/lwamiplaytestonetorpedosgraphu.png


P.S. If "autothrottle" of depth compensation feature is added, the graphs would look quite different... something like that:

(thin line is current performance, thick lines are what would be - as you see for max speed nothing changes, for 40kts setting you get more speed at depth but at cost of much greater fuel usage so shorter range - near max depth the engine is working at max so range is same like for 55kts setting).

http://img288.imageshack.us/img288/1377/lwamiplaytestonetorpedosgrapha.png

P.S. I have to think about deep passive torpedos (are they going to happen?) - the speed can be controlled by throttle setting like now (without adjustment which eats range), but what should be done is adjusting the PASSIVE ENABLE LIMIT (of 40kts) to be "40kts of true speed" and not "throttle for 40kts" as currently.

[Amizaur]

I actually find numeric tables to be better for that sort of thing. I made one using speed and depth input into those equations to get a range result. =) It will soon have a place right next to my NL tables. :up:

Note that to get exact range for variable speed and/or depth torpedo run, you would have to calculate fuel usage for each portion of run at different speed and depth. Just like a plane that covers some distance at medium speed at low altitude, then cruises at high, then returns back to low alt and during the flight thrust was also changed few times from cruise to military and afterburner... each part has different fuel usage, and it's not easy to calculate this on paper...

[Amizaur]

Range, Variable with Speed
ADCAP Range = 27 - 6(SetSpeed - 40)/15
UGST Range = 27 - 6(SetSpeed - 35)/15
(short version, every 5 knot decrease increases the range by 2nm, from a base range of 21nm)

Range, Variable with Depth
ADCAP Range (and speed) reduction = .29(depth{feet})/3000
UGST Range (and speed) reduction = .2(depth{meters})/735

LW, Ami, if this is wrong, please correct me.

Seems they are OK :up: