LuftWolf and Amizaur's Weapons and Sensors Database Mod v3.072 --- Now Available!!!

[OneShot]

Again some changes to the LwAmi Mod. Aside from some Bugfixing, Lw and myself have decided to change the distributions a bit. But more on that way down.

So whats new ?

XX-Changes for LWAMI 3.072-XX

---Bug Fixes---

--The TLAM and SS-N-27 LAM will now properly follow terrain (LWAMI 3.06 bug)

--The B-871 Alrosa Kilo 877 has been added to the playable Kilo list, since it is currently active in the Baltic Fleet.

--The warheads of some SAM's have been corrected (increased) to properly model their effectiveness in bringing down aircraft.

With v3.071 the LwAmi Mod included the Kegety's Font and Texture Mod, and it continues to do that. However due to the fact that some users seem to have problems with the fonts or cant read them, the font mod is now included but has to be activated separately with the JSGME Tool.

Of course with a new LwAmi Version comes a new Splash Screen, this time actually two of them - as I have taken the general outline of an older screen and made a new one up from scratch looking much better (my opinion) as well as a complete new one.

Starting with this version the splashscreens can be selected in the JSGME Tool so you can have the one you like or switch them around.


Now for the actual Downloads

I recommend to uninstall the older LwAmi versions before installing any new version (this and subsequent ones), but then this is SOP for most Programs anyway. Make sure to deactivate the mod before uninstalling it!!

As a disclaimer, since this issue has been brought up - this installer does not change any stuff in the registry, to my knowledge it doesnt even add anything. It only reads the path to the DW install directory (switched to a different RegKey, hopefully it now consistently reads the right path).

The LwAmi Mod comes only in two flavours now - Complete Installer Package and a Bare Bones zip file.

1.) Full package (size : 16MB)
incl. New Modells from v3.05
incl. Kegety's Font & Texture Mod
4 selectable Splash Screens (Plain LwAmi, P3, SSN, All Plattforms)
Latest JSGME Tool
and of course the LwAmi Database and Doctrines v3.072
- Grab it here : LwAmi 3.072 - Full Package (http://www.commanders-academy.com/luftwolf/LwAmi_3072_Full.exe)


2.) Bare Bones (size : 200kb)
only the LwAmi Database and Doctrines v3.072
- Grab it here : LwAmi 3.072 - Bare Bones (http://www.commanders-academy.com/luftwolf/LwAmi_3072_Bare.zip)


3.) LwAmi Mod v3.072 - Splash Screens (size : 3.6MB)
Just the 4 Splash Screens and the means to install them
- Grab it here : LwAmi Mod v3.072 Splash Screens (http://www.commanders-academy.com/luftwolf/LwAmi_Mod_Splashes.zip)


Cheers
OS

[LuftWolf]

Thanks OS! :up:

Enjoy Captains. :cool:

Cheers,
David

Edit: There is another file to install as well, which makes further adjustments to the land attack missiles. It's not a life or death issue, but this will make them more reliable.

www.commanders-academy.com/luftwolf/TLAMsub.zip (http://www.commanders-academy.com/luftwolf/TLAMsub.zip) (the same file posted below)

To install: Disable the mod, unzip to your Mods/LWAMI_Mod/Doctrine folder, then reenable the mod.

[Sonoboy]

LuftWolf, you work too hard. :rotfl:

[Fearless]

That he does and all do :up:

[Bill Nichols]

Many thanks, once again, LW! :rock:

I've just uploaded 3.072 (Full version only, per your request) to my site. :D

[OneShot]

I forgot ... here are the Splash Screens you get when downloading either the Full Package or just the Splash Screens.

http://www.commanders-academy.com/files/images/lwami_background.jpg

http://www.commanders-academy.com/files/images/lwami_background_all_plattf.jpg

http://www.commanders-academy.com/files/images/lwami_background_orion.jpg

http://www.commanders-academy.com/files/images/lwami_background_ssn.jpg


Cheers
OS

[Micksp]

Again some changes to the LwAmi Mod. Aside from some Bugfixing, Lw and myself have decided to change the distributions a bit. But more on that way down.

So whats new ?

[quote="ReadMe v3.072"]XX-Changes for LWAMI 3.072-XX

---Bug Fixes---

--The TLAM and SS-N-27 LAM will now properly follow terrain (LWAMI 3.06 bug)


Cheers
OS
Have the full package installed. Land target altitude 65 m. Fired more than 10 SS-N-27 LAM with different approaches. No one of them reaches the land target because they did not follow the terrain, just collided immediate. All of them:x

[LuftWolf]

I've tested this thoroughly... you have to be sure not to run them into any mountains... what to say?

It works for me...?

Cheers,
David

[Molon Labe]

I've been able to repeat this problem by installing the mod incorrectly. :D Make sure you uninstall the old mod (not just disable it) before installing and enabling the new mod.

The TLAM is terrain following appropriately. But, there's an issue upon impact...


EDIT: OK, what I said above about proper installation is just wrong. The mistake I was making was that I was copying the files to a location used by an older version of the mod (found in DW/lwami_mod, when the REAL location is DW/mods/lwami_mod). It's possible that the reason you haven't noticed terrain following is because you made a similar error.

In any case, the doctrine is working properly now.

[LuftWolf]

Here is a new TLAM doctrine.

I want all of you having TLAM problems to try this AND GIVE ME FEEDBACK ABOUT HOW IT WORKS.

The TLAM doctrine included in 3.072 was the same one I released four days ago, so I'd like to know what's up with this one before I include it in a new release. If there are problems for users, its good to know this. :)

www.commanders-academy.com/luftwolf/TLAMsub.zip (http://www.commanders-academy.com/luftwolf/TLAMsub.zip)

To install: Disable the mod, unzip to your Mods/LWAMI_Mod/Doctrine folder, then reenable the mod.

Cheers,
David

[LuftWolf]

Ok, there's at least one other person in the world who thinks this doctrine works fine, so I need you guys to test the 27LAM and the TLAM using this doctrine listed above.

If there are any problems, I need to hear about it. Thanks! :)

Cheers,
David

PS The newest file was posted to the above link at 1:30pm EST.

[Fearless]

Ok, there's at least one other person in the world who thinks this doctrine works fine, so I need you guys to test the 27LAM and the TLAM using this doctrine listed above.

If there are any problems, I need to hear about it. Thanks! :)

Cheers,
David

PS The newest file was posted to the above link at 1:30pm EST.

LW, I've tested the TLAM so far and 1 out of 3 reached it's target.

The first TLAM did not have much terrain deviation to content with and reached and blew up the land target. The other two did have greater terrain variation and as soon as they reached the terrain gradient they lost altitude and dove into the ground. Now having said that, could it be that because the first one did have a target to go for and the sensors had something to direct the TLAM to? Because the other two didn't have a target to shoot at and were just following their waypoints. It's as if the sensors lost sight.

There was very minimal response to variable terrain contours.

[ASWnut101]

Um, the TLAM's don't have sensors. It just flies to a given point and blows up.:know: I've had a similar problem with helo-dropped torpedoes.

[Molon Labe]

Ok, there's at least one other person in the world who thinks this doctrine works fine, so I need you guys to test the 27LAM and the TLAM using this doctrine listed above.

If there are any problems, I need to hear about it. Thanks! :)

Cheers,
David

PS The newest file was posted to the above link at 1:30pm EST.
LW, I've tested the TLAM so far and 1 out of 3 reached it's target.

The first TLAM did not have much terrain deviation to content with and reached and blew up the land target. The other two did have greater terrain variation and as soon as they reached the terrain gradient they lost altitude and dove into the ground. Now having said that, could it be that because the first one did have a target to go for and the sensors had something to direct the TLAM to? Because the other two didn't have a target to shoot at and were just following their waypoints. It's as if the sensors lost sight.

There was very minimal response to variable terrain contours. I think a good goal would be to make sure this terrain following doctrine works at least as well as the stock flag did, and TLAMs would crash into mountain ranges with the stock game. So, if you can tell me where this occurred (lat-long would be very helpful), I can try to reproduce it and figure out the thresholds.

EDIT: Never mind. Using Time on Target as a test mission, its clear that the stock flag is doing a better job of terrain following. I even lost 4 of 6 missiles on the coastline!

The "nose-dive" phenomenon seems to be happening with the stock flag though. That, and sometimes just not pulling up enough to clear the feature. With the mod doctrine, what I'm seeing is the missile not reacting to some terrain features and going straight in.

[fatty]

Um, the TLAM's don't have sensors. It just flies to a given point and blows up.:know: I've had a similar problem with helo-dropped torpedoes.

In real life they do, not sure about the game :up:

[Fearless]

That's what I thought as well otherwise terrain following would not be possible.

[ASWnut101]

Hpmf. Look here:


The Tomahawk land-attack cruise missile has been used to attack a variety of fixed targets, including air defense and communications sites, often in high-threat environments. The land attack version of Tomahawk has inertial and terrain contour matching (TERCOM) radar guidance. The TERCOM radar uses a stored map reference to compare with the actual terrain to determine the missile's position. If necessary, a course correction is then made to place the missile on course to the target. Terminal guidance in the target area is provided by the optical Digital Scene Matching Area Correlation (DSMAC) system, which compares a stored image of target with the actual target image.



http://www.fas.org/man/dod-101/sys/smart/slcm6.gif And the terminal guidance, I guess could technically be called a guidance sensor. It compares target images. That's it.



http://www.fas.org/man/dod-101/sys/smart/slcm9.gif

So, I don't consider that a sensor per-se. And the dispenser variant does NOT have a sensor. Just fly here and despense.


courtesy FAS.org

[fatty]

So, I don't consider that a sensor per-se.

Radar and/or some sort of camera... What, then, would you consider a sensor?

And these (http://www.navy.mil/navydata/fact_display.asp?cid=2200&tid=1300&ct=2) websites (http://www.missilethreat.com/cruise/id.138/cruise_detail.asp) suggest that the TLAM-D does use TERCOM at least.

[Fearless]

Yep, I didn't think the word "sensor" would become a "proof me wrong" issue.

Whether it is a guidance system, radar or whatever it's deemed to be called, it still is a sensor in layman terms, The TLAM still has to adjust it's flight altitude according to height variations and that's done through sensing height variations.

That's it debate over. :damn: back to the original topic.

Nice piccies though :up:

[fatty]

Apologies for highjacking :oops:

[LuftWolf]

Where was everyone when this problem was in LWAMI 3.06? :hmm:

I've got some test scenarios of people trying to attack things on sea mountain tops and such... pretty extreme conditions, but since the stock works it should work in LWAMI as well.

I'll probably have to reconstruct the TLAM's completely if we want to keep the TIW messages for them, since the change appears to have damaged the terrain following, and doing it the way I've been doing it will only take care of 85% of situations where people seem to want to use TLAM's.

So, I've got a backup plan which actually seems to be tailor made for the TLAM's.

Stay tuned.

Cheers,
David

[Fearless]

Apologies for highjacking :oops:

Quite the contrary fatty, I agree with your statement :up: As a matter of fact some TLAMs have DSMAC which is an electro-optical sensor system. Check it here: http://www.designation-systems.net/dusrm/m-109.html

[Bellman]

LW: ''Here is a new TLAM doctrine. I want all of you having TLAM problems to try this AND GIVE ME FEEDBACK ABOUT HOW IT WORKS.''

Tested the new doctrine and there is no change here from 3.072. The TLAMs still make no attempt to terrain follow. Both 3.072 and new doctrine installed as per instructions.

Edit: Further tests show SS-N-27 fails as above.(including post new doctrine) Both missiles perform correct terrain following in Stock 1.04.when the Mod is deactivated.

[Fearless]

LW,

Ok, I went into the TLAMsub.txt file and made a small adjustment to the following:

IF TerrainAlt > -100 THEN {
SetPriority 249
SetAlt ( TerrainAlt + 800 )

The -100 was -50 before and + 800 was + 400 before. I then targetted a building in a mountainess area and set the waypoints so that the flightpath went over the highest points of the mountains.

Location for testing was Portugal with altitudes of 2500 feet asl

This seem to work as the Tomahawk changed altitude when required and then descended back to 50 feet.

I tried different waypoint directions 4 times and the each of the Tomahawks reached it's target every time. I hope you don't mind me having a go at it as it seemed to work.

[Fish]

When I disable the LWAMI 3.72 and try to play stock 104, I get a error 13023?

[LuftWolf]

When I disable the LWAMI 3.72 and try to play stock 104, I get a error 13023?

Fish, I'm not sure what that error means. Database issues when reenabling stock usually come about as result of not having properly uninstalled ALL of the previous Mod version AFTER disabling the Mod, including manually deleting any files left over in the Mod folder.

I'd recommend reinstalling DW at this point and the Mod fresh, since it's not possible to know what happened to the files at this point.

Let me know how it goes.

Cheers,
David

[LuftWolf]

Ok, here is the best I can do to solve this problem while retaining a true TIW message for the sublaunched Land Attack Missiles.

My solution is simply to have the missiles fly higher. :-?

Not really that fabulous a solution, but's the best I got, after three days of messing around with it.

I'm going to compensate for the increased altitude, and therefore exposure, of the missiles by reducing their radar signature to limit detection to the equivalent LOS horizon range at which they were previously detected on the deck.

You should also be aware that stock LAM's don't really "terrain follow", since they fly about 400ft off the ground when over land to give them an extra cushion.

The only things, from a functional perspective that is going to be lost in this change is the detection of the missiles during their ballistic launch, but there is nothing saying that TLAM's necessarily have to go dead straight up a few thousand feet when fired real life... in fact, I don't think they do. :hmm:

So, here is the hopefully final doctrine: www.commanders-academy.com/luftwolf/TLAMsub_Test.zip (http://www.commanders-academy.com/luftwolf/TLAMsub_Test.zip) .

Please let me know if it works for you. :)

If it doesn't work, I can always go higher... but there is a point at which it would get ridiculous and we just have to not put land targets in certain places... ;)

I'm not suggesting that most users install it, unless they want to fire TLAM's in situations where they are crashing, since I need to reduce the detectiblity of the LAM's to make them less likely to get shot down at higher altitudes.

Cheers,
David

[Molon Labe]

Well, just to be fair about 'certain places,' there's a reason I used Time on Target as my test bed. And those missiles are crashing on the coastline sometimes, I don't have to try to fly them over the mountains in front of the base.

[Molon Labe]

It's definitely an improvement from the last one. The altitude over land is OK too, visually I don't see much of a difference. It's definitely higher over water though.

Anyways, using Time on Target and firing directly over the inland mountains, I had 6/6 missiles reach the target. Two missiles did not detonate on their targets, but I think this was missile-fratricide rather than any sort of deletion-glitch. It's like 688I all over again. =) Maybe this is a realism plus? More on this if I notice it again. But anyways, no problem crossing the coast, and it made it over the inland mountains--which is something you don't have to or should do when you play ToT AND 1/6 will crash in stock.

I also have a custom test set in Iran, 3 targets at different places inland. This isn't so much a practical application test as it is a worst-case scenario, since the terrain is quite mountainous. None of the missiles reached the 3 targets. In the stock game, I think 2 are reached, the long one doesn't get hit because of the "nose dive" issue. What I've found using this map is that you need to watch out for sharp inclines that are on the order of 1500ft+. Now, over what horizontal distance that needs to be, I don't know, but its a rule of wrist.

I'm going to do that test over and see if waypoints alleviate the problem.

[Bill Nichols]

Well, just to be fair about 'certain places,' there's a reason I used Time on Target as my test bed....

Glad to be of service :|\\
:)

[Molon Labe]

Hey, it's not like a TLAM strike on an airbase in the Kola penninsula is random craziness or anything.

Back to Iran...
Using waypoints, I can steer the missiles around 3 mountain ridges to hit a target on a plateau 40 miles inland. The other targets at 240 and 270nm inland I can't get to, at least not with just 3 waypoints.

But like I said, this is a worst case scenario. I picked hundreds of miles of mountainous terrain to fly over, and a really ****ty launch point.

Does anyone know where the key Iranian airbases and nuclear facilities are? Maybe I should test to see if they can be reached with a sane launch point.

[Bellman]

:up: Latest fix now achieves 100% Test success for TLAMS traversing steeply contoured hills/mountains in excess of 1000 ft. Profile may give rise to increase in SAM interception rate - nothing that saturation and multi approach profiles cant beat.

[Bill Nichols]

Hey, it's not like a TLAM strike on an airbase in the Kola penninsula is random craziness or anything.

Back to Iran...
Using waypoints, I can steer the missiles around 3 mountain ridges to hit a target on a plateau 40 miles inland. The other targets at 240 and 270nm inland I can't get to, at least not with just 3 waypoints.

But like I said, this is a worst case scenario. I picked hundreds of miles of mountainous terrain to fly over, and a really ****ty launch point.

Does anyone know where the key Iranian airbases and nuclear facilities are? Maybe I should test to see if they can be reached with a sane launch point.


See http://www.globalsecurity.org/wmd/world/iran/nuke-fac.htm
and http://www.globalsecurity.org/military/world/iran/airfield.htm

[Molon Labe]

More testing...

After 6 attempted flight paths, I managed to hit the Uranium Conversion Facility (thanks Bill) at Isfahan. It only took one attempt to hit the Saghand Uranium mine. =) The trick is getting past the "gates" of mountains north of the Strait. You can "cheat" with the 3d to get a feel for where the passes are in areas the map leaves you unsure. Once you get past that, it's a straight shot over the foothills of central Iran. This is what I meant about using a sensible launch point earlier; from the West you're swimming upstream, so to speak.

Edit: it took me 3, I think, to hit the Natanz Enrichment Facility.

I'm going to say at this point that it is working acceptably for the majority of situations. If anyone has any issues in specific areas I should follow up on, let me know. But if I can hit targets in Iran with 800nm trips over mountains, then it still works. Mission designers may have to designate waypoints in tasking messages in difficult terrain.

[Orm]

More testing...

After 6 attempted flight paths, I managed to hit the Uranium Conversion Facility (thanks Bill) at Isfahan. It only took one attempt to hit the Saghand Uranium mine. =) The trick is getting past the "gates" of mountains north of the Strait. You can "cheat" with the 3d to get a feel for where the passes are in areas the map leaves you unsure. Once you get past that, it's a straight shot over the foothills of central Iran. This is what I meant about using a sensible launch point earlier; from the West you're swimming upstream, so to speak.

Living in a dream, or what? ;)

Oh sorry, back to business and thanks LW for your work.

[Fish]

When I disable the LWAMI 3.72 and try to play stock 104, I get a error 13023?

Fish, I'm not sure what that error means. Database issues when reenabling stock usually come about as result of not having properly uninstalled ALL of the previous Mod version AFTER disabling the Mod, including manually deleting any files left over in the Mod folder.

I'd recommend reinstalling DW at this point and the Mod fresh, since it's not possible to know what happened to the files at this point.

Let me know how it goes.

Cheers,
David

I get lost when I have to delete left oves. Where do I find them?
I am afraid to delete the wrong files. :oops:

[Bellman]

Fish I had similar problem earlier so with 3.072 here's what I did. LW and OS look the other way. :o
1. Used the JSGME tool to deactivate the LWAMI Mod.
2. Uninstalled the Mod using 'All programs' - Dangerous Waters - Mods- Uninstall.
3. Went into main DW Folder/ Mods and deleted everything including remaining JSGME tool, LWAMI folder (and Backup)
4. Installed the 'Full package' LWAMI_3072_Full
5. Activated LWAMI Mod, Kelgety and Splash screen.

That worked fine as did the deactivation to Stock 1.04.

[Fearless]

Yes, sometimes it's best to uninstall everything and remove all reference from the harddrive and registry and do a complete re-install. That works for me.

[Fish]

I did what you told me to do, now DW crashes to desktop after the splashscreen, and back to 104 it crashes immediately after I start DW.:-?

[Bellman]

If you're really screwed , like I was 2, or was it 3, Mods back :doh: -Regedit delete HKEY Local Machine/Sonalysts, uninstall everything, delete everything remaining in the DW folder and start afresh with DW/1.04 plus latest LWAMI Mod. But heck fortunately thats not necessary every Mod upgrade. This latter process preceded the action I mentioned above.

I like the way OS is going with JSGME - soon we may have a list of selectable sub-upgrades/features like the Ghost Recon system. [ Hope ;) ]

[LuftWolf]

What, so everyone is happy? :)

No way... :know:

I'm working on some new documentation, and then we'll see a new version in a day or so. OS has convinced me that it's definately time to rewrite the readme, do some charts and graphs, and also to write a platform by platform user guide.

So expect a new version maybe by Friday, if not a little before. THIS version, should hopefully be the final version of LWAMI 3.xx, which should be a stable version for some time while I begin to make the initial changes for LWAMI 4.xx, and that goes into an extensive testing process, which I'm now convinced is VERY necessary for all future version of the mod.

Cheers,
David

[Molon Labe]

What, so everyone is happy? :)

No way... :know:

I'm working on some new documentation, and then we'll see a new version in a day or so. OS has convinced me that it's definately time to rewrite the readme, do some charts and graphs, and also to write a platform by platform user guide.

So expect a new version maybe by Friday, if not a little before. THIS version, should hopefully be the final version of LWAMI 3.xx, which should be a stable version for some time while I begin to make the initial changes for LWAMI 4.xx, and that goes into an extensive testing process, which I'm now convinced is VERY necessary for all future version of the mod.

Cheers,
David
Happy is pushing it. The terrain following capability is still pretty bad. (Good= as reliable as we'd think the RL weapon is)

It is arguably an improvement from the stock weapons in some situations though. The LW/Ami TLAMs are essentially lower performance, but more reliable. Stock missiles outperform LW/Ami in responding quickly to more radical terrain features. They only need to be steered around the most dramatic obstacles. LW/Ami missiles need to be painstakingly assigned waypoints through the narrowest of mountain passes, since they react to terrain features very slowly. On the other hand, stock missiles are very prone to sudden pitch departures which sometimes result in a crash. This behavior appears buggy; it isn't consistent behavior occuring for certain terrain, although increasing AGL altitude almost certainly triggers it. As a result, stock missiles are extremely unreliable if fired across rough terrain over long distances.

Which missiles are better is a really tough call to make without extensive game experience in a variety of terrain types. And I don't shoot LAMs all that much.

Whether or not we should be happy depends on whether it's an improvement over stock, and if not, whether that sacrifice is worth getting the TIWs for. So I can't decide if I'm happy or not.

[LuftWolf]

I can go as high as you guys want... if 1000ft isn't enough, I can do 1500ft, or 2000ft... it really doesn't matter because I'm going to limit the vulnerabiltiy of the missiles using their radar signature setting. Once the missile is above 500ft, just about any altitude is the same from a vulnerabiltiy standpoint. It's all the same, except for the way the missiles look when flying to target.

So should we go higher then?

Cheers,
David

[Molon Labe]

It's already too high.

[Molon Labe]

Just to clarify.

To the point that we are chasing down bugs caused by adding the TIW warning, I think we have reached a point where the TIW is not worth the trouble.

But, all of this testing has shown that the stock TLAMs really ****ing suck in mountains, even worse than I ever realized. If you want to work on fixing that problem, I'm all for it.

Edit: but as a policy matter, I think the best thing to do right now is to play with the doctrine we have now, and listen for feedback regarding where LAMs are reaching their targets and where they are not. We compare those results to results with stock missiles in the same situations. If we find that we have an improved situation, or that in the majority of situations the LAMs are hitting their targets, then we don't need to take any action.

[LuftWolf]

I'm of the opinion that we are right now at the tipping point.

I'm not taking out the TIW messages because the TLAM's have to graphically fly higher than in stock, especially if this has the extra benefit of making the TLAM's more reliable.

Just to be clear, I've ALWAYS had trouble with TLAM's, SLAM-ER's, and LAM's in terms of 1) getting them to target 2) getting them to detonate on the target to damage it, from DW 1.00 onwards, so I'm really just going to set this and then drop the mic and walk off the stage.

Cheers,
David

[Micksp]

LAM's:
Tested them with last doctrine. Fired couple of them directly across 300-460 m hills and they passed reaching the targets. The next time i have enemy OHP placed nearby, making the LAM waypoints that they flies approx 15 nm from the OHP. Fired 8 LAM's (4 x 2) and all of them were destroyed by OHP SM-2 engaging from ~14 nm.

[LuftWolf]

LAM's:
Tested them with last doctrine. Fired couple of them directly across 300-460 m hills and they passed reaching the targets. The next time i have enemy OHP placed nearby, making the LAM waypoints that they flies approx 15 nm from the OHP. Fired 8 LAM's (4 x 2) and all of them were destroyed by OHP SM-2 engaging from ~14 nm.


I'm going to compensate for the increased altitude, and therefore exposure, of the missiles by reducing their radar signature to limit detection to the equivalent LOS horizon range at which they were previously detected on the deck.

I'm not suggesting that most users install it, unless they want to fire TLAM's in situations where they are crashing, since I need to reduce the detectiblity of the LAM's to make them less likely to get shot down at higher altitudes.


The TLAM's in the next version of the mod will be no more likely to be shot down than TLAM's in past versions.

Cheers,
David

[Bellman]

Is somethings screwed with my JSGME install ?

Having looked again at the matter following Fishs post about problems I decided to do what was advised. I carried out a full uninstall removing all vestiges of DW and LwAmi from my PC., including regedit removal. I then did a clean install and patched to 1.04 followed by a 'Full package' install of LwAmi 3072.

Everything appears to run fine but wanting to look again at the new LwAmisub_Test for TLAM, prior to installing it, I had a look in my various Doctrine folders. (3 - Main folder, LwAmi Mod and Backup) All contained the identical TLAMsub txt file modified on the 24.02.07. Can this be correct ? :hmm:

Edit: See below - It is correct and OK as the original file is switched back in on reverting by JSGME to Stock.

[Bellman]

My reinstall followed a suspicion that all was not well with my earlier 100% success rate using LwAmi 3072 TLAM Test.

I set up a scenario with SAMs in the lee of steeply contoured hills - an unrealistic TLAM target but a severe manouvering problem for the 'new' mod. In stock all the targets were destroyed and the TLAMs were observed to carry out large pitch correction movements. In LwAmi 3072 with the latest 'Test' no targets were hit - there were 50% near misses and 50% enroute ground collisions. The inflight higher ground clearance altitude seems to accompany a very gentle pitch adjustment which proved, in my tests, incapable of responding efficiently to the ground contours.

Edit: Tests show under these severe conditions TLAMs overshoot (as expected) Also given routing over less steeply contoured terrain the success rate is proportionately higher.

[Fearless]

Is somethings screwed with the JSGME install ?

Having looked again at the matter following Fishs post about problems I decided to do what was advised. I carried out a full uninstall removing all vestiges of DW and LwAmi from my PC., including regedit removal. I then did a clean install and patched to 1.04 followed by a 'Full package' install of LwAmi 3072.

Everything appears to run fine but wanting to look again at the new LwAmisub_Test for TLAM, prior to installing it, I had a look in my various Doctrine folders. (3 - Main folder, LwAmi Mod and Backup) All contained the identical TLAMsub txt file modified on the 24.02.07. Can this be correct ? :hmm:

That is interesting :hmm:

I opened up the DW Doctrine folder then tested the JSGME and what I found was that the stock files inside the DW Doctrine folder changed and added the TLAMsub.txt file when I enabled the LWAMI mod. Then I disabled the LWAMI mod and watched the files go back to there original stock files and the TLAMsub.txt file was removed.

Just wondering, did you deactivate the mod first before uninstalling as well as remove all the left over folders on your harddrive after the uninstall was done?

[Bellman]

:D You are right when deactivating LwAmi Mod the TLAMsub file is replaced just by the older TLAM file. My concerns were groundless. Thanks. :rock:

[LuftWolf]

Yes, Molon has demonstrated that some targets that cannot be hit in stock DW can be hit in LWAMI after the TLAM change, and vice versa, some targets that cannot be hit in LWAMI can be hit in stock DW.

This is something we are all just going to have to live with.

Cheers,
David

[Molon Labe]

Yes, Molon has demonstrated that some targets that cannot be hit in stock DW can be hit in LWAMI after the TLAM change, and vice versa, some targets that cannot be hit in LWAMI can be hit in stock DW.

This is something we are all just going to have to live with.

Cheers,
David
Eh. That's not quite right. The stock missiles perform better at getting over radical terrain. But, they're buggy, and will sometime nose dive too steeply to pull out in time. It's not that the stock missiles cannot hit targets, it's that they are unreliable in their ability to do so. The more uneven terrain they have to cross, the more unreliable they become.

LWAMI missiles perform more poorly, and because of that, cannot hit some targets. But they are predictable, and if you're willing to really study the topography, you can find routes to targets provided there are not so many features that the missile just doesn't have enough waypoints to get around them. This is much more of a can-can't proposition than with the stock missiles, where it can just be a crap shoot.

[Bellman]

Yeh I agree with ML and in more recent tests have had greater success with LwTlAms given larger profile targets and carefull route planning.

However it seems that Stock tend to overpitch on more extreme contoured final phase approaches whilst if anything LwTlAms underpitch. This characteristic probably assists LwTlAms in crest riding enroute at the cost of increased exposure to interceptor missiles.

I dont recognise the description of Stocks as ''crap shoot'' as I achieved a higher proportion of kills with them when approaching over extreme topography. The LwTlAms still overshoot too often or plow a furrow in a hillside. The result is a much reduced kill ratio.

[Molon Labe]

I dont recognise the description of Stocks as ''crap shoot'' as I achieved a higher proportion of kills with them when approaching over extreme topography. The LwTlAms still overshoot too often or plow a furrow in a hillside. The result is a much reduced kill ratio.
It sounds like we're using different standards. You seem to be considering not only the missile's performance, but the ability of the player to find a flight path.

I am only analyzing the performance of the missile on a given flight path. For a LW/ami missile, a given flight path will either be passable for all missiles or it will be impassible for all missiles. For a stock missile, there is some unknown probability of failure which increases with rougher terrain and longer flight paths. So for a stock missile, if you're firing over rough terrain, whether any particular missile will reach the target is unknown. With a LW/Ami missile, you know that it will or that it won't.

[Fearless]

I totally agree ML. Since when were TLAMs designed to be mountain climbers anyway. As far as I can see, waypoint plotting is the strategy so that TLAMs have a success in reaching their targets but that also is not a 100% certainty.

I think this is being looked into way too deeply. The more changes made in the TLAMsub.txt, the more irregularities are found. All I did was changed:
IF TerrainAlt > -100 THEN {
SetPriority 249
SetAlt ( TerrainAlt + 800 )

and left the skimming at 50 feet. The TLAMs reached their target no problems even clearing 2400 feet.

[Bellman]

Fearless: ''Mountain climbers'' :lol: - I tested over hills between 1000 - 3000 ft. References to extreme topography or rough terrain relate, as I understand it, to the rate of change in contours and not to the absolute height levels. In practise routing over or through such terrain would only be necessary where the limited waypoints prevented planning low level flight paths. But waypoints are limited which imposes compromises in long distance run-ins over 'hilly' terrain.

My aim was to simulate a target set in a valley or superbowl stadium of surrounding hills where at the end of a long waypointed flight options for approach are limited. Results as reported elsewhere were 'mixed.'

But given a level approach over sea to a 'steep' hill under 3000 ft no ground collision should be expected but I experienced such frequently with the latest LwAmi TLAM mod.

[Bellman]

Pitch and rudder control is of vital importance in the final run-in to target stage. Flight Simmers will recognise the situation where a vital target nestles in the hills. And where have the sneaky defenders placed the SAMs - thats it right behind the brow of a hill on the potential sensible approach routes.

The TLAMs should be capable of dealing with the defence radar, SAMs and targets in hill-shadowed positions. This demands a higher degree of responsiveness to control inputs in the terminal stage/s than the 'ballanced' wave crest riding approach run-in. A 'Formula One' car settings adjustment 'on the hoof' ?

With sim software limitations a compromise adjustment should be found. My preference would be to move in the direction of Stock performance even at the cost of TIWs. I dont think MP considerations should be paramount in this issue.

[LuftWolf]

I totally agree ML. Since when were TLAMs designed to be mountain climbers anyway. As far as I can see, waypoint plotting is the strategy so that TLAMs have a success in reaching their targets but that also is not a 100% certainty.

I think this is being looked into way too deeply. The more changes made in the TLAMsub.txt, the more irregularities are found. All I did was changed:
IF TerrainAlt > -100 THEN {
SetPriority 249
SetAlt ( TerrainAlt + 800 )

and left the skimming at 50 feet. The TLAMs reached their target no problems even clearing 2400 feet.

This is what I did originally... however some people want to shoot them at things on the tops of sea mountains and such, so it's necessary to give them a significant cushion even while over water.

Cheers,
David

[LuftWolf]

Ok, this the first time I've used this card with you guys, and hopefully, the last.

The TLAM's are going to be what they are going to be. Mission designers are going to have to use restraint as to where they put targets. There is LOTS of land in the DW terrain map, in fact the WHOLE WORLD, so, if you want your missions to be compatible with LWAMI, then put your land targets in places where they can be hit with the missiles in the Mod.

If you don't want to do this, then put a note in your mission that it cannot be completed with LWAMI.

Cheers,
David

[Fearless]

Pitch control is of vital importance in the final approach to target stage. Flight Simmers will recognise the situation where a vital target nestles in the hills. And where have the sneaky defenders placed the SAMs - thats it right behind the brow of a hill on the logical approach route.

So there is a dual problem but multi-targets. The TLAMs should be capable of dealing with the defence radar, SAMs and targets in hill-shadowed positions.

True but I wouldn't compare a flight sim with a sub sim though. Precision strikes are much easier from the air than from a surface or sub-surface lauched weapon as aircraft attacks are much closer to targets than subs are and also have altitude advantage when AGs are released. TLAMs are designed for stealth approach to give an element of surprise meaning below radar sig attack and they most definitely have much further to travel.

I still believe this is getting way too deep into the technics.

I certainly wouldn't send a TLAM maximum distance deep into Mountainous terrain on the hope that it would reach it's destination and then destroy the target especially as you said where targets of interest are strategically placed and hard to reach.

[Bellman]

Fearless: You do love your mountains :lol: No comparison with flight simming just the reality of dealing with targets sensibly placed to maximise land utilisation and defence capabilities.

LW: I accept that there are limitations and you will achieve the 'best' compromise to achieve 'reality'. Sorry if I appear to have pushed the limits of testing (as requested) - my intention was only positive ! You know as an avid LwAmi fan I am truly chuffed to have this new superb mod. :|\\

[LuftWolf]

I just think people are reading WAY too far into this for a bug that took a month to catch...

I'm not minimizing the importance of not messing anything up, that's been a primary goal of LWAMI from day one. However, given that mission designers have 100% choice as to where land targets are going to be, I think it's important to realize that there is never going to be a situation where I have made the missiles "unusable", provided that the mission designers take a quarter of the walk with me.

I find everyone's feedback very helpful no matter what, but let's keep things in perspective. :)

Cheers,
David

[Fearless]

My sentiments exactly LW. I'll leave it to the powers to be and yes, It's a awesome mod. :up:

[Bill Nichols]

I just think people are reading WAY too far into this for a bug that took a month to catch...

I'm not minimizing the importance of not messing anything up, that's been a primary goal of LWAMI from day one. However, given that mission designers have 100% choice as to where land targets are going to be, I think it's important to realize that there is never going to be a situation where I have made the missiles "unusable", provided that the mission designers take a quarter of the walk with me.

I find everyone's feedback very helpful no matter what, but let's keep things in perspective. :)

Cheers,
David

I'm happy so long as the new TLAMs are not substantially worse than the stock (re. terrain avoidance). I'd hate to have to re-work some of my prior scenarios.

We Dive at Dawn, for example, is one that requres the player to find a route through mountains for his TLAMs.

:|\\

[LuftWolf]

I doubt there are any situations in current missions that would expose the new TLAM's weaknesses.

The only situations where it would still fail are under pretty extreme conditions. :)

Cheers,
David

[Molon Labe]

I just think people are reading WAY too far into this for a bug that took a month to catch...

I'm not minimizing the importance of not messing anything up, that's been a primary goal of LWAMI from day one. However, given that mission designers have 100% choice as to where land targets are going to be, I think it's important to realize that there is never going to be a situation where I have made the missiles "unusable", provided that the mission designers take a quarter of the walk with me.

I find everyone's feedback very helpful no matter what, but let's keep things in perspective. :)

Cheers,
David
I'm happy so long as the new TLAMs are not substantially worse than the stock (re. terrain avoidance). I'd hate to have to re-work some of my prior scenarios.

We Dive at Dawn, for example, is one that requres the player to find a route through mountains for his TLAMs.

:|\\

Those moutains stopped a stock missile?
I got one through on the first attempt with a LW/Ami missile. There was a pretty obvious valley to go through, and I'm not even sure I needed to use it. This is child's play compared to Iran.

[SUBMAN1]

Why is everyone complaining? The flight model in DW is not the best and is not intended to be, but it works. Make missions that work with it. Simple as that. When DW comes out with a airflow over surface flight based calulations engine, then you can complain about this kind of stuff. Until then, just deal with the simple physics as implemented.

As I see it, feel lucky that you get to shoot TLAM's at all towards land based targets!

-S

PS. LW - Thx for the excellent mod!

[Fearless]

I don't believe anyone is complaining, more like trying to get way too deep into modding the TLAM. :)

[Molon Labe]

unintended side effects are a bitch...but they can't be ignored

[Janus]

I want to bring up an issue I have with sphere array and TA on the seawolf and 688i:
on both subs I've had the problem that there was a clear contact line in broadband on the sphere array (short and intermediate display) and the same contact at the TA's intermediate display (not visible on short).
Although the contact was clearly visible on the sphere array I was not able to designate it there, I had to designate it on the TA intermediate display...
In narrowband the contact was only visible on the TA and not sphere array :shifty:

Is this the LwAmi Mod's fault (or feature?) or is this some kind hardcoded-user -interface-sensitivity problem in Dangerous Waters? I cannot recall a similar problem before installing the mod.

Great mod nevertheless by the way :)

[Fearless]

I want to bring up an issue I have with sphere array and TA on the seawolf and 688i:
on both subs I've had the problem that there was a clear contact line in broadband on the sphere array (short and intermediate display) and the same contact at the TA's intermediate display (not visible on short).
Although the contact was clearly visible on the sphere array I was not able to designate it there, I had to designate it on the TA intermediate display...
In narrowband the contact was only visible on the TA and not sphere array :shifty:

Is this the LwAmi Mod's fault (or feature?) or is this some kind hardcoded-user -interface-sensitivity problem in Dangerous Waters? I cannot recall a similar problem before installing the mod.

Great mod nevertheless by the way :)

It could well have been a Biologic. I have designated targets in SA but not very often.

[Janus]

It could well have been a Biologic. I have designated targets in SA but not very often. No it was not. That is what I would have thought too if there wasn't a frequency on the TA narrowband and apart fromt that it was a custom scenario I have set up for TMA practice with only one cargo ship, so no it definately was not a bio contact ;)

[Dr.Sid]

You could also have frequency range set to low frequencies. TA NB shoould show something anyway. Something simmilar never ever happend to me and I use all the mods all the time.
I guess you should try to repeat the situation. If it happens, save the mission. Try if it exists after mission reload. If so, post the save.

[Janus]

You could also have frequency range set to low frequencies. TA NB shoould show something anyway. Something simmilar never ever happend to me and I use all the mods all the time. The frequency range is set to 2000 and I see the contact now (it was rather faint and a bit off bearing the first time).

I guess you should try to repeat the situation. If it happens, save the mission. Try if it exists after mission reload. I've done that and unfortunately it does not help. The situation is I have the contact at bearing 30 on TA and sphere broad- and narrowband and I can assign trackers on all arrays but sphere broadband although it is very clear.

I have uploaded the mission file and save file (http://rapidshare.com/files/18995259/array_test.rar.html) on rapidshare.

[Dr.Sid]

I've tried the save and I see both contacts perfectly on NB. The sphere contact is quite dim .. I believe you could miss it if you don't have screen properly set. But the TA contact is nice and bright.

http://roger.questions.cz/other/dump00053459.jpg
http://roger.questions.cz/other/dump00046891.jpg

Edit: OIC .. you can't mark the sphere on BB .. that's perfectly OK .. it's just too weak yet. Such situations happens in stock too, but at different ranges/sound levels. Mark it on NB and be happy.

[Janus]

Edit: OIC .. you can't mark the sphere on BB .. that's perfectly OK .. it's just too weak yet. Such situations happens in stock too, but at different ranges/sound levels. Mark it on NB and be happy. Thank's for your help. The screenshots resemble what I was seeing too.
I am a bit disappointed to hear that this is normal. I find it lame to be able to mark a relatively dim sphere NB contact but cannot mark the same contact on BB which is clearly visible in short and intermediate timescale whereas the TA is more washed out and only visible in intermediate :doh:

Okay I'll have to cope with it...

[Dr.Sid]

Yes .. it is lame .. but it is not LWAMI issue.

[Molon Labe]

This is actually a very old issue, and it's sort of a LW/Ami issue, but not really.

Sometimes, BB traces will appear that just aren't markable. It has to do with the thresholds set in the sim. LW/Ami increased the BB sensititivy of the spherical array. Is it turned out, this also increased the gap between the visual threshold and the markable threshold, which means that the bug occurs more with LW/Ami than it does with stock DW.

[LuftWolf]

READ THE README!!! :)

Sphere and Hull Arrays—The sensitivity of the Sphere and Hull arrays has been increased relative to the Towed Array (to be clear, the TA is still much more sensitive in terms of long range performance) to better simulate their reported real world specifications. Also, the stern facing baffle of the Sphere has been increased to 120 degrees for active and passive modes, including the FFG and all AI platforms. It is not uncommon for contacts to show up on the broadband sphere before they show up on the narrowband sphere, and loud contacts will also show up more clearly on the sphere array broadband than the towed array broadband once both arrays have detected the contact. Expect to use the Sphere and Hull arrays more now to track and identify surface traffic and build situational awareness utilizing DEMON and TMA, and reserve the TA for finding and tracking those quiet hostile submarines or distant warships on narrowband. NOTE: Known Issue. It will be possible to see and hear contacts on the Sphere array before you can assign a Broadband tracker to them. You can immediately assign a narrowband tracker to all contacts on the sphere with a narrowband signature, although it is intended that generally contacts will be detected on the sphere broadband first. The broadband tracker issue is not intended, although it is present in stock DW as well, and the mod does not make it any worse in game play terms.

Cheers,
David

[Molon Labe]

Yeah, what he said!

We're going to need a new acronym: RTFRM :yep:

[Bellman]

Well here's another one - we know about in stock but I leave others to interpret whether the feature has intensified in LwAmi.
I would label it Psychic NB Classification.

Facts - my SW 6 kts 492 ft other side layer and 14.4 nm from Collins at 3 knts and 147 ft. SA BB has no indications except a very infrequent spasmodic SNR 1 which would mostly be missed. NB 'Search' has no indication nor does a slow scan reveal any tonals BUT (as we know) the 'Ship classification window' attempts an incorrect classification which is adequate for attack purposes !

The TA had both BB and NB tonals so as has been claimed previously that for some reason the software is porting extra info. from the TA to the SA. OK we know, we know, but come on a Collins at 3 knts at 12.4 NM on SA ?? :o And what if this feature is not TA dependent !

Now I can live with that just but when I take the MH60 for testing I still get the very prescient 'Pschic classifications' reported above, mainly with the dipping sonar.:hmm:

[Dr.Sid]

Somehow I don't understand what is the problem.

[Molon Labe]

Definitely a stock issue.

Don't forget about the sonobuoy filters seeing one more dot than is displayed on the screen.

[LuftWolf]

I love it, I release a new version of the mod, and everyone forgets what they've been experiencing for two years.

Forget "psychic classifications", I've got the Memory Erasing Mod here! :lol:

Cheers,
David

[Bellman]

In the SW its merely inconvenient NP but in the MH60 it provides a cheat and if its present in non TA subs its a big cheat.

Sid: Simple there shouldnt be a line twitching 'ship classification ' attempt giving away a contacts position when there are no available tonals indicated on that sonar source.

[LuftWolf]

Yes, it's absolutely all my fault, including the updates that have to be done to the NWP for the new version of FC, and the incompatibilities between SCX and the NCP version of SC.

It's all my fault... I need to fix it all right away. LOL :rotfl: :rotfl: :rotfl:

Cheers,
David

Edit: That's not directed at you Bellman, it's just a general statement. :)

[Bellman]

LW: Accepted - I said known issue. The question is in tuning-up sonar sensitivities, as reported, has the impact of this 'cheat' increased ?

[LuftWolf]

Beats me... I'm at the point with this sim where I just accept the problems and focus on the things I have control over.

At some point, someone else has to gain some kind of competancy with the basic workings of this sim.

Cheers,
David

Edit: Nevermind that last comment, plenty of people do, but few of them have the lack of sense to post to the message board every day and make a mod for public use. :p

[LuftWolf]

Ok, I'm going to do the files for LWAMI 3.08 today... I hope no bugs have been missed because we've spent so much time focused on things like the TLAM. :know:

I've been pretty busy these past few days, so I haven't done much testing myself, my sincere hope is that 3.08 is going to last at least as long as a gallon of milk in an American grocery store.

Cheers,
David

[Bellman]

My Kilo in LwAmi at 50m 3 knts Layer 200 m.

The following contacts were marked in NB SA by ctf (No visual indications) :

13.4 nm Trafalgar at 147 m 4 kts.
16.3 nm Type 206A at 46 m 2 kts.
18.7 nm Daphn at 75 m 2 kts.
22 nm Victor 111 at 150 m 5 kts.

I was really just admiring the new models BUT....

[LuftWolf]

Just a quick question, I assume people don't mind if I hold off on the major readme changes and just do 3.08 as I had done before in terms of documentation?

I know there is at least one tournament on hold pending a stable version of LWAMI, so getting that out is my primary concern... then after that, I can release a separate guide and some charts and graphs.

I hope no one minds. :sunny:

Cheers,
David

[LuftWolf]

My Kilo in LwAmi at 50nm 3 knts Layer 200 m.

The following contacts were marked in NB SA by ctf (No visual indications) :

13.4 nm Trafalgar at 147 m 4 kts.
16.3 nm Type 206A at 46 m 2 kts.
18.7 nm Daphn at 75 m 2 kts.
22 nm Victor 111 at 150 m 5 kts.

I was really just admiring the new models BUT....

Sounds like people need to avoid cheating. :yep:

Hasn't this been around in DW since the beginning?

In any case, I can't control things in the engine that are obviously broken.

If I worried about these sorts of things, I wouldn't even play DW let alone spend time modding it. If people want to cheat, they can cheat, this is pretty much the case in any game.

Cheers,
David

[Janus]

READ THE README!!! :) True.
I haven't meant to offend or blame anyone on hardcoded user interface bugs. I just had to ask my question, and I like the mod (although I am not experienced enough with (stock) DW to understand the importance of all the fixes that come with the mod :yep:)
So see it like this: you have taken me away from the fate of experiencing all the stock DW issues that are fixed by your mod :ping:

[Bellman]

I thought this bug/cheat had been eliminated by SAS and am genuinely surprised to find that its still here. It is well enough documented to ensure that those who can read will I'm afraid use it.

But I am beeing diverted - further tests with a separate installation of stock have confirmed
1. That the bug(etc) is also present in Stock 1.04
2. That it is not TA dependent and
3. That the 'tuning-up' of LwAmi SA sonar sensitivity has increased the bug/fault/cheats impact.

Given the same scenario in stock the Daph was located at 18.7 nm but nothing beyond that range. Whereas LwAmi had the Victor 111 at 22 nm. I will determine the max range.

[LuftWolf]

Thankfully, this falls into the catagory of "things that aren't my problem," since the only solution is to return the Sphere and Hull sonars to the state where they can't even detect civilian shipping at reasonable ranges.

It is unfortunate that SCS can only do threshold fixes for this, rather than a true recoding of the sonar interfaces to actually eliminate this problem at the source.

Fortunately, you can't accidently use this, it's squarely within the realm of "intentional cheats," and it's also fairly obvious when reviewing the replays.

Cheers,
David

[Bellman]

Maximum range (to date) Kilo SA NB bug(etc) under LwAmi 44 nm
Maximum range (to date) Kilo SA NB bug(etc) under stock 19 nm.
So a ''modest'' 100% increase in range.

The ability to track neutrals at an increased range comes at a heavy price.

I dont agree that :
1. "things that aren't my problem," You have turned up the sensitivity and therefore the power of the bug/cheat.
2. Its obvious on 'replay' as many 'could' merely use it as a strong 'hint' - not firing down the bearing at an early stage.

But interpretation is not for me - I am just startled at what I've found.

[LuftWolf]

I'll admit, that is pretty extreme. :-?

However, reversing one of the most important changes made in the mod (making 2/3's of the player sonars useful) is not on the table.

The cheat is not created by the mod, nor is the cheat altered in qualitative terms, therefore the increase in range is irrelevant, as far as I am concerned.

My advice regarding this remains what it has always been, only play DW with people you trust, because 2+ hours of your life is worth a lot. :up:

Cheers,
David

[LuftWolf]

Bellman, be aware that the limitation on the stock sensor Click-to-Mark is because of the hardcap on the sonar, which also limits it's detection of exceptionally loud contacts to the same range.

So, what this means is that the stock Kilo sonar will suddenly get a huge spike contact at on it at 19nm for all loud contacts like tankers, etc. In fact, the hardcap on the stock Kilo Sphere array is 36575m, or 19nm.

So, this really all sucks doesn't? Really big range for the cheat, or ridiculous myopia? :-?

But again, the solution is far better than the problem, provided you aren't playing with people inclined to use an obvious exploit.

Cheers,
David

[Fish]

I thought this bug/cheat had been eliminated by SAS and am genuinely surprised to find that its still here. It is well enough documented to ensure that those who can read will I'm afraid use it.

But I am beeing diverted - further tests with a separate installation of stock have confirmed
1. That the bug(etc) is also present in Stock 1.04
2. That it is not TA dependent and
3. That the 'tuning-up' of LwAmi SA sonar sensitivity has increased the bug/fault/cheats impact.

Given the same scenario in stock the Daph was located at 18.7 nm but nothing beyond that range. Whereas LwAmi had the Victor 111 at 22 nm. I will determine the max range.

Bellman can I get your map for testing, we tested the Kilo conformal bug in beta and the bug was found and removed.

Fish.

[LuftWolf]

Apparently not. :-?

It is possible using the Kilo Narrowband sonar to mark contacts that cannot be seen, however, it is not possible to assign a tracker to them.

The bug has been fixed for the broadband sonar.

Cheers,
David

[Molon Labe]

Apparently not. :-?

It is possible using the Kilo Narrowband sonar to mark contacts that cannot be seen, however, it is not possible to assign a tracker to them.

The bug has been fixed for the broadband sonar.

Cheers,
David

Well, **** me in the ass and call me a bitch. :damn::damn:

[Bellman]

Fish: On the way.

Test Kilo SA NB 'Mark' Bug in LwAmi 3072 - range maxima 64 - 85 nm.

[Bellman]

Test Akula TA NB marking to range 38 nm.(same test location conditions as before.)

Edit: Comparitive tests SW and Ak :
Test SW TA NB Same scenario, same target no discernable NB tonals just an infrequent very missable SNR 1 flicker now and again.

Apparently adjustments to the TA sensitivity have adjusted the odds ?

[Fish]

Bellman,

Tested with Kilo, well see for yourself.
You have to place the cursor on the excact baring and click repeatedly to get a new contact at distance, so in a normal mission you do not find those faraway contacts I think.
http://www.xs4all.nl/~peschiwj/Kilotest.JPG


Not possible with the Seawolf. (used auto TMA).
http://www.xs4all.nl/~peschiwj/Seawolfsonartest.JPG

[Bill Nichols]

The 'click' cheat has never been a issue for me. I would hate to have this discussion hold-up LW's fine work. :cool:

[Fish]

The 'click' cheat has never been a issue for me. I would hate to have this discussion hold-up LW's fine work. :cool:

Its only a issue when playing multiplayer. :yep:

[Bellman]

The good news for me is after testing SW v Ak I am content that the previous balance of sonar performances has been maintained in this mod. I agree ctc is only a potential MP problem - well policed in the Fleets. But also avoided, as can be seen from Fleet reports, as more and more players in sub v sub dives are selecting the same platforms - egs. 2 SW v 2 SW.

So I do hope LW will press ahead in spite of these minor quibles. They are completely dwarfed by the extent of other accomplishments but I make no appology for addressing them at the 'eleventh hour' as we were asked to test and can only do so when RL permits.

Edit: Fish I think you cite the extreme range as an example of difficulty, but I found intermediate range contacts quite easily with just progressive clicking at a couple of degree or so jumps. This is down to SAS not LW and I am at a loss to understand how it crept back in.
Patch 1.04 Readme - '' Corrected an issue in which the Kilo was capable of creating Sonar contacts at excessively long ranges.'' So what happened ?

[Molon Labe]

The 'click' cheat has never been a issue for me. I would hate to have this discussion hold-up LW's fine work. :cool:
Its only a issue when playing multiplayer. :yep:

It's only an issue when playing multiplayer with an absolute cock.

[Fish]

The 'click' cheat has never been a issue for me. I would hate to have this discussion hold-up LW's fine work. :cool:
Its only a issue when playing multiplayer. :yep:

It's only an issue when playing multiplayer with an absolute cock.

You are right!

[SUBMAN1]

Did 3.08 ever make it out? Stll waiting with baited breath and can't seem to find it. Thought it was supposed to be out on Thurs or Fri??

-S

[Dr.Sid]

I guess, since it is not here, it is not out. But I'll be glad to be wrong :arrgh!:

[Bellman]

Kilo SA NB ctc Bug Patch 1.04.

SAS: Patch 1.04 Readme - '' Corrected an issue in which the Kilo was capable of creating Sonar contacts at excessively long ranges.''

Note the use of the word ''excessive'' - this bug/fault was not eliminated and is still present at 'acceptable' ranges up to 20 nm as tested today in a separate install of Stock 1.04.

This would suggest that any SA sonar adjustments have intensified the fault within LwAmi. This means that contacts can be readily identified, if not marked, with increasing difficulty from 20 nm - 65+ nm.

[LuftWolf]

LWAMI 3.08 will be available either today (Sunday), Monday, or Tuesday.

Sorry for the excessively large window of uncertainty... lots going on.

Cheers,
David

[Bellman]

Great news David. :rock:

I dont want to be a 'party-pooper' and its nothing that cant be tweaked but as requested, with time permitting, testing has continued.

I must regretably withdraw my earlier remark - ''The good news for me is after testing SW v Ak I am content that the previous balance of sonar performances has been maintained in this mod.''

I am a SW diver (mainly) so have taken a closer look at the sonar changes. I was lead to believe that it was mainly the SA that had been 'adjusted. However I have found significant changes to the relative performances of the SW and Ak TAs in the mod.

Under identical Test conditions and using separate installs of Stock 1.04 and LwAmi
3.072 I found the following maxima with TA NB marking(***):

Stock SW - 47.9 nm. marked and 65.7 nm unmarked (***) with difficulty
StocK AK 1 - 38.8 nm. marked
LwAmi SW - 33.3 nm. marked.
LwAmi AK 1 - 37 nm. marked.

An equivalence of performance for the LwAmi SW and AK TA NBs swings the balance towards the AK. But I leave others to judge.

[LuftWolf]

A lot goes into those detections other than the sonar sensitivity, namely the platform noise levels and thrust sound vs. speed curves, which are very different in the modded and unmodded versions.

The relative sonar strength between the TB-29 and the Pelamida have not been changed at all from stock DW, mainly because there is no gameplay reason to do so, nor any real world data suggesting this change be made. To be clear, the TB-29 is MUCH more sensitive (by a factor of 2/3) than the Pelamida.

Taken as a balance, the SW has a massive advantage over the Akula in terms of detectibility in actual tactical situations, mostly because of the fact that it's maximum tactical speed is more than double that of the Akula, and it manages to be quieter at that speed than Akulas at their tactical speed.

Cheers,
David

PS I assume your SSP is a convergence zone for these tests, in which case the ranges aren't really useful information, because you are getting them all on a bounce... all those contacts will eventually fade as they become closer (in theory) as those ranges HUGE.

Conducting sim-level evaluations of sonar performance in a convergence zone SSP is basically a waste of time, unless you are testing convergence zone SSP's specifically for their impact on sonar performance.

[LuftWolf]

BTW, what is the point of bringing up stuff I changed years (!) ago? :hmm:

You can PM me any questions you have, that might be a better way to go, since I'm not really clear what I'm supposed to read as a "problem", what is a question, and what is merely observation... and I'm sure I'm not the only one confused.

Trust me, if I am aware of a problem, I'll be the first one to tell everyone about it.

Cheers,
David

[Bellman]

No not a convergence zone - surface ducts may account for some maximums but not the general run.

Anyways - ''for others to judge'' - I'm done as times run out.

Good luck.

[LuftWolf]

Regardless, those numbers reported from your tests don't make sense.

It's probably not worth saying that you can look into the database yourself with DWedit and see exactly how everything is set.

Either that, or I secretly replaced the SW with Folgers Crystals... let's see if they notice! :lol:

Cheers,
David

[Bellman]

Well if you or anyone want to plough through a dozen plus test dumps ( about 50) - be my guest . I can place them on YouSendIt ?

Some of my earlier findings on other issues certainly did'nt seem to make sense to me - but they seemed to catch your attention, eventualy. :hmm:

Let me recap - the Test scenarios were created in 3.072 and took place in deep waters central Med, rock bottom, January, surface duct. SSP - a very gentle isovelocity over negative gradient with the layer well below the depth of all the participating subs.

Which findings do you challenge - the Kilo SA enhanced bug or the Akula TA boost ?

[LuftWolf]

The kilo issue is documented.

The Akula "TA Boost" is non-existent. Look in the database... I'm not sure what else to say other than that.

Here is the text dump of the relevant sensor dialogues.

Index 0050
Name SSN21 TB29
Mast 0007 (SSN21 Stbd TA)
SensorClass 0007 (Passive Sonar)
CounterDetectSensor 0000 (None)
UpdateInterval 0001
DetectionCurveRange1 120000
DetectionCurveRange2 0000
DetectionCurveRange3 0000
DetectionCurveRange4 0000
DetectionCurveRange5 0000
DetectionCurveRange6 0000
DetectionCurveLevel1 0000
DetectionCurveLevel2 0000
DetectionCurveLevel3 0000
DetectionCurveLevel4 0000
DetectionCurveLevel5 0000
DetectionCurveLevel6 0000
MaxOperationSpeed 0020
MaxOperationAlt 0000
MinOperationAlt -3000
SonarFreqMin 0000
SonarFreqMax 1200
SNR -012
sNumTrackers 0004
sConeRotAxisZ 0105
sConeRotAxisY 0000
sConeRotAxisX 0000
sConeAngleXZ 0000
sConeAngleXY 0076
nRptAccuracy 0002
nMaxDetectionAlt 0000
nMinDetectionAlt -3000
fData60 0.00
fPosX 0.00
fPosY 0.00
fPosZ 0.00
fMinBeamWidth 1.00
fMaxBeamWidth 15.19
cRootTracker I
cSierraPrefix S
<SensorAttrib>
AFFECTEDBYRANGE 1
THERMALLAYER 1
SEASTATE 1
AFFECTEDBYASPECT 0
TARGETMASS 0
TARGETNOISE 1
PLATFORMNOISE 1
AFFECTEDBYGROUNDNOISE 0
EARTHCURVATURE 0
AMBIENTLIGHT 0
UNKNOWN1024 0
MIRROR 1
DOUBLESIDEDCONE 1
RPT_TGTBEARING 1
RPT_TGTRANGE 0
RPT_TGTCRS 0
RPT_TGTSPD 0
RPT_TGTALT 0
RPT_TGTFREQ 1
RPT_TGT003 1
</SensorAttrib>
szDisplayName TB-29
--------------------------------


Index 0006
Name 688I TB16
Mast 0021 (688I Port TA)
SensorClass 0007 (Passive Sonar)
CounterDetectSensor 0000 (None)
UpdateInterval 0001
DetectionCurveRange1 120000
DetectionCurveRange2 0000
DetectionCurveRange3 0000
DetectionCurveRange4 0000
DetectionCurveRange5 0000
DetectionCurveRange6 0000
DetectionCurveLevel1 0000
DetectionCurveLevel2 0000
DetectionCurveLevel3 0000
DetectionCurveLevel4 0000
DetectionCurveLevel5 0000
DetectionCurveLevel6 0000
MaxOperationSpeed 0023
MaxOperationAlt 0000
MinOperationAlt -3000
SonarFreqMin 0000
SonarFreqMax 1200
SNR -008
sNumTrackers 0004
sConeRotAxisZ 0105
sConeRotAxisY 0000
sConeRotAxisX 0000
sConeAngleXZ 0000
sConeAngleXY 0076
nRptAccuracy 0002
nMaxDetectionAlt 0000
nMinDetectionAlt -3000
fData60 0.00
fPosX 0.00
fPosY 0.00
fPosZ 0.00
fMinBeamWidth 1.00
fMaxBeamWidth 15.19
cRootTracker I
cSierraPrefix S
<SensorAttrib>
AFFECTEDBYRANGE 1
THERMALLAYER 1
SEASTATE 1
AFFECTEDBYASPECT 0
TARGETMASS 0
TARGETNOISE 1
PLATFORMNOISE 1
AFFECTEDBYGROUNDNOISE 0
EARTHCURVATURE 0
AMBIENTLIGHT 0
UNKNOWN1024 0
MIRROR 1
DOUBLESIDEDCONE 1
RPT_TGTBEARING 1
RPT_TGTRANGE 0
RPT_TGTCRS 0
RPT_TGTSPD 0
RPT_TGTALT 0
RPT_TGTFREQ 1
RPT_TGT003 1
</SensorAttrib>
szDisplayName TB-16
--------------------------------

Index 0014
Name Akula Towed
Mast 0009 (Akula TA)
SensorClass 0007 (Passive Sonar)
CounterDetectSensor 0000 (None)
UpdateInterval 0001
DetectionCurveRange1 120000
DetectionCurveRange2 0000
DetectionCurveRange3 0000
DetectionCurveRange4 0000
DetectionCurveRange5 0000
DetectionCurveRange6 0000
DetectionCurveLevel1 0000
DetectionCurveLevel2 0000
DetectionCurveLevel3 0000
DetectionCurveLevel4 0000
DetectionCurveLevel5 0000
DetectionCurveLevel6 0000
MaxOperationSpeed 0010
MaxOperationAlt 0000
MinOperationAlt -3000
SonarFreqMin 0000
SonarFreqMax 1200
SNR -008
sNumTrackers 0004
sConeRotAxisZ 0105
sConeRotAxisY 0000
sConeRotAxisX 0000
sConeAngleXZ 0000
sConeAngleXY 0076
nRptAccuracy 0002
nMaxDetectionAlt 0000
nMinDetectionAlt -3000
fData60 0.00
fPosX 0.00
fPosY 0.00
fPosZ 0.00
fMinBeamWidth 1.00
fMaxBeamWidth 15.19
cRootTracker I
cSierraPrefix S
<SensorAttrib>
AFFECTEDBYRANGE 1
THERMALLAYER 1
SEASTATE 1
AFFECTEDBYASPECT 0
TARGETMASS 0
TARGETNOISE 1
PLATFORMNOISE 1
AFFECTEDBYGROUNDNOISE 0
EARTHCURVATURE 0
AMBIENTLIGHT 0
UNKNOWN1024 0
MIRROR 1
DOUBLESIDEDCONE 1
RPT_TGTBEARING 1
RPT_TGTRANGE 0
RPT_TGTCRS 0
RPT_TGTSPD 0
RPT_TGTALT 0
RPT_TGTFREQ 1
RPT_TGT003 1
</SensorAttrib>
szDisplayName Pelamida
--------------------------------

Here is a text dump of the relevant Object dialogues

sID 0367
sMaxSpeed 0035
sMinSpeed 0000
sClimbAngle 0030
sArmorDamage 0120
sData0A 0005
sUnusedSL 0000
sActiveSonarSL 0075
sActiveInterceptSL 0000
sESMSL 0000
sVisualSL 0008
sMADSL 0066
sInfraRedSL 0066
sPassivSonarSL 0059
sRadarSL 0040
sFCRadarSL 0040
sIFFSL 0000
sCMSL 0000
sJammerSL 0000
sLauncherID[00] 0920 (Imp Akula TubesS1)
sLauncherID[01] 0919 (Imp Akula TubesP2)
sLauncherID[02] 1119 (Imp Akula TubesS3)
sLauncherID[03] 1118 (Imp Akula TubesP4)
sLauncherID[04] 1121 (Imp Akula TubesS5)
sLauncherID[05] 1120 (Imp Akula TubesP6)
sLauncherID[06] 1123 (Imp Akula TubesS7)
sLauncherID[07] 1122 (Imp Akula TubesP8)
sLauncherID[08] 0922 (Imp Ak Ext TubesS1)
sLauncherID[09] 0921 (Imp Ak Ext TubesP2)
sLauncherID[10] 1125 (Imp Ak Ext TubesS3)
sLauncherID[11] 1124 (Imp Ak Ext TubesP4)
sLauncherID[12] 1127 (Imp Ak Ext TubesS5)
sLauncherID[13] 1126 (Imp Ak Ext TubesP6)
sLauncherID[14] 0148 (Akula Portable SAM)
sLauncherID[15] 0944 (AkulaCM_Int)
sLauncherID[16] 0000 (EMPTY SLOT)
sLauncherID[17] 0000 (EMPTY SLOT)
sLauncherID[18] 0000 (EMPTY SLOT)
sLauncherID[19] 0000 (EMPTY SLOT)
sLauncherID[20] 0000 (EMPTY SLOT)
sLauncherID[21] 0000 (EMPTY SLOT)
sLauncherID[22] 0000 (EMPTY SLOT)
sLauncherID[23] 0000 (EMPTY SLOT)
sLauncherID[24] 0000 (EMPTY SLOT)
sLauncherID[25] 0000 (EMPTY SLOT)
sLauncherID[26] 0000 (EMPTY SLOT)
sLauncherID[27] 0000 (EMPTY SLOT)
sLauncherID[28] 0000 (EMPTY SLOT)
sLauncherID[29] 0000 (EMPTY SLOT)
sAirstripID[00] 0131 (AkulaIDSRV)
sAirstripID[01] 0000 (EMPTY SLOT)
sAirstripID[02] 0000 (EMPTY SLOT)
sAirstripID[03] 0000 (EMPTY SLOT)
sAirstripID[04] 0000 (EMPTY SLOT)
sAirstripID[05] 0000 (EMPTY SLOT)
sAirstripID[06] 0000 (EMPTY SLOT)
sAirstripID[07] 0000 (EMPTY SLOT)
sAirstripID[08] 0000 (EMPTY SLOT)
sAirstripID[09] 0000 (EMPTY SLOT)
sSensorID[00] 0009 (Akula MF Active)
sSensorID[01] 0061 (Active Intercept)
sSensorID[02] 0013 (Akula Sphere)
sSensorID[03] 0010 (Akula ESM)
sSensorID[04] 0072 (Visual)
sSensorID[05] 0123 (MRK-50(akula))
sSensorID[06] 0056 (HF Act Son)
sSensorID[07] 0012 (Akula Hull)
sSensorID[08] 0014 (Akula Towed)
sSensorID[09] 0011 (Akula PeriESM)
sSensorID[10] 0350 (Akula SailESM)
sSensorID[11] 0039 (AI Passive S1 Sphere)
sSensorID[12] 0359 (AI Passive S1 TA)
sSensorID[13] 0053 (AI PassiveSW1W2TAD )
sSensorID[14] 0052 (AI Passive S1 Hull)
sProfileID 0161 (Akula I Impr SSN)
s3DObjectIndex -001
sThrustID[00] 0044 (Akula SSN +23)
sThrustID[01] 0000 (EMPTY SLOT)
sThrustID[02] 0000 (EMPTY SLOT)
sThrustID[03] 0000 (EMPTY SLOT)
sThrustID[04] 0000 (EMPTY SLOT)
TargetCaps_SUB 0
TargetCaps_SURF 0
TargetCaps_AIR 0
TargetCaps_HELO 0
TargetCaps_LAND 0
TargetCaps_MINE 0
TargetCaps_TORPEDO 0
TargetCaps_MISSILE 0
MC_AAM 0
MC_ASM 0
MC_SSM 0
MC_SAM 0
MC_TANKER 0
MC_TERRAIN_FOLLOW 0
MC_GUIDED 0
MC_THROWN 0
MC_REFUELABLE 0
MC_FEEDBACK 0
MC_PRELOCK 0
MC_SMOKELESS 0
MC_REATTACK 0
MC_REMOTE 0
MC_SNAPSHOT 0
MC_BALLISTIC 0
sData106 0000
fMastHeightx10 07.7
fLengthx10 110.6
fWidthx10 15.5
fDraftx10 09.4
fcd 00.4
fMass 0000
fTurnRadius 500.0
ObjectType 0001 (Sub)
SimType 0000 (Sub)
nWpnMaxRange 0
nWireLength 0
nWpnMinRange 0
nFfuel 0
nPointValue 0750
nMaxAltitude 000000
nMinAltitude -00569
szName Akula I Impr SSN
szAmbientSound sub_nuke
szBBsoundFile BB_sub_nuke.wav
szDoctrine SubDef
cMisASW 1
cMisSUW 2
cMisAAW 6
cMisStrike 2
cMisRecon 3
cMisComms 0
cMisMineSweepBomber 0
cWpnEffectiveness 0
cBuoyCount 0
CM_CHAFF 0
CM_IR_FLARES 0
CM_ACOUSTICS 1
CM_TOWED_ACOUSTICS 0
CM_ECM_JAMMER 0
CM_CIWS 0
DBUser_VAL1 0
DBUser_VAL2 0
DBUser_VAL3 0
DBUser_VAL4 0
DBUser_VAL5 0
DBUser_VAL6 0
DBUser_VAL7 0
DBUser_VAL8 0
DBUser2Flags(BYTE VAL) 000


sID 0002
sMaxSpeed 0033
sMinSpeed 0000
sClimbAngle 0015
sArmorDamage 0110
sData0A 0005
sUnusedSL 0000
sActiveSonarSL 0075
sActiveInterceptSL 0000
sESMSL 0000
sVisualSL 0008
sMADSL 0062
sInfraRedSL 0062
sPassivSonarSL 0058
sRadarSL 0040
sFCRadarSL 0040
sIFFSL 0000
sCMSL 0000
sJammerSL 0000
sLauncherID[00] 0003 (LA SSNI MidtubesP2)
sLauncherID[01] 0004 (LA SSNI MidtubesS1)
sLauncherID[02] 1106 (LA SSNI MidtubesP4)
sLauncherID[03] 1107 (LA SSNI MidtubesS3)
sLauncherID[04] 0946 (LA SSNI VLS S5)
sLauncherID[05] 0005 (LA SSNI VLS P6)
sLauncherID[06] 1108 (LA SSNI VLS S7)
sLauncherID[07] 1113 (LA SSNI VLS P8)
sLauncherID[08] 1109 (LA SSNI VLS S9)
sLauncherID[09] 1114 (LA SSNI VLS P10)
sLauncherID[10] 1110 (LA SSNI VLS S11)
sLauncherID[11] 1115 (LA SSNI VLS P12)
sLauncherID[12] 1111 (LA SSNI VLS S13)
sLauncherID[13] 1116 (LA SSNI VLS P14)
sLauncherID[14] 1112 (LA SSNI VLS S15)
sLauncherID[15] 1117 (LA SSNI VLS P16)
sLauncherID[16] 0945 (688CM_Int)
sLauncherID[17] 0000 (EMPTY SLOT)
sLauncherID[18] 0000 (EMPTY SLOT)
sLauncherID[19] 0000 (EMPTY SLOT)
sLauncherID[20] 0000 (EMPTY SLOT)
sLauncherID[21] 0000 (EMPTY SLOT)
sLauncherID[22] 0000 (EMPTY SLOT)
sLauncherID[23] 0000 (EMPTY SLOT)
sLauncherID[24] 0000 (EMPTY SLOT)
sLauncherID[25] 0000 (EMPTY SLOT)
sLauncherID[26] 0000 (EMPTY SLOT)
sLauncherID[27] 0000 (EMPTY SLOT)
sLauncherID[28] 0000 (EMPTY SLOT)
sLauncherID[29] 0000 (EMPTY SLOT)
sAirstripID[00] 0130 (688IDSRV)
sAirstripID[01] 0000 (EMPTY SLOT)
sAirstripID[02] 0000 (EMPTY SLOT)
sAirstripID[03] 0000 (EMPTY SLOT)
sAirstripID[04] 0000 (EMPTY SLOT)
sAirstripID[05] 0000 (EMPTY SLOT)
sAirstripID[06] 0000 (EMPTY SLOT)
sAirstripID[07] 0000 (EMPTY SLOT)
sAirstripID[08] 0000 (EMPTY SLOT)
sAirstripID[09] 0000 (EMPTY SLOT)
sSensorID[00] 0001 (688I MF Active)
sSensorID[01] 0354 (AN/WYL-1)
sSensorID[02] 0005 (688I Sphere)
sSensorID[03] 0002 (688I ESM)
sSensorID[04] 0072 (Visual)
sSensorID[05] 0108 (AN/BPS-15)
sSensorID[06] 0056 (HF Act Son)
sSensorID[07] 0004 (688I Hull)
sSensorID[08] 0006 (688I TB16)
sSensorID[09] 0003 (688I PeriESM)
sSensorID[10] 0007 (688I TB23)
sSensorID[11] 0352 (688I SailESM)
sSensorID[12] 0428 (AI 688i TA)
sSensorID[13] 0429 (AI 688i TAD)
sSensorID[14] 0008 (AI Passive W1 Sphere)
sProfileID 0002 (Improved LA SSN)
s3DObjectIndex -001
sThrustID[00] 0043 (688i SSN +16)
sThrustID[01] 0000 (EMPTY SLOT)
sThrustID[02] 0000 (EMPTY SLOT)
sThrustID[03] 0000 (EMPTY SLOT)
sThrustID[04] 0000 (EMPTY SLOT)
TargetCaps_SUB 0
TargetCaps_SURF 0
TargetCaps_AIR 0
TargetCaps_HELO 0
TargetCaps_LAND 0
TargetCaps_MINE 0
TargetCaps_TORPEDO 0
TargetCaps_MISSILE 0
MC_AAM 0
MC_ASM 0
MC_SSM 0
MC_SAM 0
MC_TANKER 0
MC_TERRAIN_FOLLOW 0
MC_GUIDED 0
MC_THROWN 0
MC_REFUELABLE 0
MC_FEEDBACK 0
MC_PRELOCK 0
MC_SMOKELESS 0
MC_REATTACK 0
MC_REMOTE 0
MC_SNAPSHOT 0
MC_BALLISTIC 0
sData106 0000
fMastHeightx10 06.7
fLengthx10 109.5
fWidthx10 15.8
fDraftx10 09.8
fcd 00.4
fMass 0000
fTurnRadius 600.0
ObjectType 0001 (Sub)
SimType 0000 (Sub)
nWpnMaxRange 0
nWireLength 0
nWpnMinRange 0
nFfuel 0
nPointValue 1000
nMaxAltitude 000000
nMinAltitude -00492
szName Improved LA SSN
szAmbientSound sub_nuke
szBBsoundFile BB_sub_nuke.wav
szDoctrine SubDef
cMisASW 1
cMisSUW 1
cMisAAW 0
cMisStrike 1
cMisRecon 2
cMisComms 0
cMisMineSweepBomber 0
cWpnEffectiveness 0
cBuoyCount 0
CM_CHAFF 0
CM_IR_FLARES 0
CM_ACOUSTICS 1
CM_TOWED_ACOUSTICS 0
CM_ECM_JAMMER 0
CM_CIWS 0
DBUser_VAL1 0
DBUser_VAL2 0
DBUser_VAL3 0
DBUser_VAL4 0
DBUser_VAL5 0
DBUser_VAL6 0
DBUser_VAL7 0
DBUser_VAL8 0
DBUser2Flags(BYTE VAL) 000


sID 0003
sMaxSpeed 0038
sMinSpeed 0000
sClimbAngle 0015
sArmorDamage 0120
sData0A 0005
sUnusedSL 0000
sActiveSonarSL 0074
sActiveInterceptSL 0000
sESMSL 0000
sVisualSL 0008
sMADSL 0057
sInfraRedSL 0057
sPassivSonarSL 0055
sRadarSL 0040
sFCRadarSL 0040
sIFFSL 0000
sCMSL 0000
sJammerSL 0000
sLauncherID[00] 0006 (SeaWolf Midtubes P2)
sLauncherID[01] 0007 (SeaWolf Midtubes S1)
sLauncherID[02] 1060 (SeaWolf Midtubes P4)
sLauncherID[03] 1061 (SeaWolf Midtubes S3)
sLauncherID[04] 1062 (SeaWolf Midtubes P6)
sLauncherID[05] 1063 (SeaWolf Midtubes S5)
sLauncherID[06] 1064 (SeaWolf Midtubes P8)
sLauncherID[07] 1065 (SeaWolf Midtubes S7)
sLauncherID[08] 0940 (CM_Internal)
sLauncherID[09] 0941 (CM_External)
sLauncherID[10] 0000 (EMPTY SLOT)
sLauncherID[11] 0000 (EMPTY SLOT)
sLauncherID[12] 0000 (EMPTY SLOT)
sLauncherID[13] 0000 (EMPTY SLOT)
sLauncherID[14] 0000 (EMPTY SLOT)
sLauncherID[15] 0000 (EMPTY SLOT)
sLauncherID[16] 0000 (EMPTY SLOT)
sLauncherID[17] 0000 (EMPTY SLOT)
sLauncherID[18] 0000 (EMPTY SLOT)
sLauncherID[19] 0000 (EMPTY SLOT)
sLauncherID[20] 0000 (EMPTY SLOT)
sLauncherID[21] 0000 (EMPTY SLOT)
sLauncherID[22] 0000 (EMPTY SLOT)
sLauncherID[23] 0000 (EMPTY SLOT)
sLauncherID[24] 0000 (EMPTY SLOT)
sLauncherID[25] 0000 (EMPTY SLOT)
sLauncherID[26] 0000 (EMPTY SLOT)
sLauncherID[27] 0000 (EMPTY SLOT)
sLauncherID[28] 0000 (EMPTY SLOT)
sLauncherID[29] 0000 (EMPTY SLOT)
sAirstripID[00] 0129 (SSN21DSRV)
sAirstripID[01] 0000 (EMPTY SLOT)
sAirstripID[02] 0000 (EMPTY SLOT)
sAirstripID[03] 0000 (EMPTY SLOT)
sAirstripID[04] 0000 (EMPTY SLOT)
sAirstripID[05] 0000 (EMPTY SLOT)
sAirstripID[06] 0000 (EMPTY SLOT)
sAirstripID[07] 0000 (EMPTY SLOT)
sAirstripID[08] 0000 (EMPTY SLOT)
sAirstripID[09] 0000 (EMPTY SLOT)
sSensorID[00] 0044 (SSN21 MF Active)
sSensorID[01] 0355 (AN/WLR-9)
sSensorID[02] 0048 (SSN21 Sphere)
sSensorID[03] 0045 (SSN21 ESM)
sSensorID[04] 0072 (Visual)
sSensorID[05] 0109 (AN/BPS-16)
sSensorID[06] 0056 (HF Act Son)
sSensorID[07] 0047 (SSN21 Hull)
sSensorID[08] 0049 (SSN21 TB16)
sSensorID[09] 0046 (SSN21 PeriESM)
sSensorID[10] 0050 (SSN21 TB29)
sSensorID[11] 0051 (SSN21 WA)
sSensorID[12] 0353 (SSN21 SailESM)
sSensorID[13] 0430 (AI SSN21 TA)
sSensorID[14] 0431 (AI SSN21 TAD)
sProfileID 0003 (Sea Wolf SSN)
s3DObjectIndex -001
sThrustID[00] 0030 (Seawolf SSN +18)
sThrustID[01] 0000 (EMPTY SLOT)
sThrustID[02] 0000 (EMPTY SLOT)
sThrustID[03] 0000 (EMPTY SLOT)
sThrustID[04] 0000 (EMPTY SLOT)
TargetCaps_SUB 0
TargetCaps_SURF 0
TargetCaps_AIR 0
TargetCaps_HELO 0
TargetCaps_LAND 0
TargetCaps_MINE 0
TargetCaps_TORPEDO 0
TargetCaps_MISSILE 0
MC_AAM 0
MC_ASM 0
MC_SSM 0
MC_SAM 0
MC_TANKER 0
MC_TERRAIN_FOLLOW 0
MC_GUIDED 0
MC_THROWN 0
MC_REFUELABLE 0
MC_FEEDBACK 0
MC_PRELOCK 0
MC_SMOKELESS 0
MC_REATTACK 0
MC_REMOTE 0
MC_SNAPSHOT 0
MC_BALLISTIC 0
sData106 0000
fMastHeightx10 05.8
fLengthx10 107.8
fWidthx10 15.4
fDraftx10 08.2
fcd 00.4
fMass 0000
fTurnRadius 600.0
ObjectType 0001 (Sub)
SimType 0000 (Sub)
nWpnMaxRange 0
nWireLength 0
nWpnMinRange 0
nFfuel 0
nPointValue 1000
nMaxAltitude 000000
nMinAltitude -00656
szName Sea Wolf SSN
szAmbientSound sub_nuke
szBBsoundFile BB_sub_nuke.wav
szDoctrine SubDef
cMisASW 1
cMisSUW 1
cMisAAW 0
cMisStrike 1
cMisRecon 2
cMisComms 0
cMisMineSweepBomber 0
cWpnEffectiveness 0
cBuoyCount 0
CM_CHAFF 0
CM_IR_FLARES 0
CM_ACOUSTICS 1
CM_TOWED_ACOUSTICS 0
CM_ECM_JAMMER 0
CM_CIWS 0
DBUser_VAL1 0
DBUser_VAL2 0
DBUser_VAL3 0
DBUser_VAL4 0
DBUser_VAL5 0
DBUser_VAL6 0
DBUser_VAL7 0
DBUser_VAL8 0
DBUser2Flags(BYTE VAL) 000

The thrust dialogue doesn't dump, so I'll list the relevant values.

Sound vs Speed increase at Max speed- SW +18, 688i +16, Akula I +23.

So, there, you can see all the data yourself.

There isn't much I can do, other than make the database set... if there is some magical thing in the engine that makes those results you have, then that sucks, but it's out of my control.

I've done what I can do, and I'm done with this line of conversation. It's bloody inane to be debating this when the database IS OPEN SOURCE.

If you find something in the database I ought to change, then I'll seriously look at it.

DWedit, it's free.

Cheers,
David

[Fearless]

Phew!! now for the next topic and puttin TAs and SAs aside.

LWAMI v3.08 will be out soon:up:

[Bellman]

Mmmm - lets wait and see. :yep:

When the TV technician throws you the wiring diagram and blames your ''magic'' :hmm:

[Bill Nichols]

Phew!! now for the next topic and puttin TAs and SAs aside.

LWAMI v3.08 will be out soon:up:

I think we should re-visit the TLAM issue, first. :dead:

(Just kiddin')

[LuftWolf]

Mmmm - lets wait and see. :yep:

When the TV technician throws you the wiring diagram and blames your ''magic'' :hmm:

So, let me just be perfectly clear... you can't find a single situation on your computer where the SW sonar out performs the Akula sonar?

Because if that's the case, then that is really twisted, and I don't have an explanation and I'm not sure anyone else is having this experience, at least they shouldn't be.

If you want to post your scenario we can all look it at together. :)

Assuming your results are genuine (and I trust you, it's just that things are usually pretty complicated) I have a theory that you might be getting these results from a strong bottom bounce, in which case the TA length and depth at the time of your tests would impact the detection ranges.

A lot goes into detection ranges once the sim is in motion, including bottom terrain and other things like the random layer depths.

I assume since I haven't been bombarded from every quarter that you might be the only one to have found a situation where this is the case.

So two things, can you find a SINGLE situation on your computer where the SW sonar outperforms the Akula, and can you post your scenario?

Cheers,
David

PS Time off has arrived... LWAMI 3.08 will be done in the next day... blame Bellman for the delays. :p :p :p

[Bellman]

I offered to post up the info at the top of the page 48 hours ago so the delays are not mine. So not to incur more ''blame Bellman'' for delays, I suggest I ''wait and see'' and then test and post the results of 3.072 v 8.

My contention is first that the Kilo SA 'bug' which SAS claimed to have eliminated at ''excessive ranges'' though latent in 1.04 has returned in 3.072.

Secondly that various changes have altered the balance in the relative performance levels of the Akula v SW TAs. This has been confirmed by running several different scenarios with different SSPs. There is a marked change from Stock 1.04.

RL time does not permit my devoting any more time to this matter until the weekend when I look forward to running the new 8.

[LuftWolf]

I offered to post up the info at the top of the page 48 hours ago so the delays are not mine. So not to incur more ''blame Bellman'' for delays, I suggest I ''wait and see'' and then test and post the results of 3.072 v 8.

My contention is first that the Kilo SA 'bug' which SAS claimed to have eliminated at ''excessive ranges'' though latent in 1.04 has returned in 3.072.

Secondly that various changes have altered the balance in the relative performance levels of the Akula v SW TAs. This has been confirmed by running several different scenarios with different SSPs. There is a marked change from Stock 1.04.

RL time does not permit my devoting any more time to this matter until the weekend when I look forward to running the new 8.

But you haven't answered my question... does the SW sonar EVER outperform the Akula sonar on your computer?

Cheers,
David

[Bellman]

LW: '' But you haven't answered my question...'' Snap ....except questionS:
You pass no comment on the Kilo bug except that it is ''documented'' But why is it back and why apparently enhanced ?

The answer to your question is in 3.072 at Test 4 kts both AK and SW TAs in various SSPs give (me) about the same max ranges 30- 34 nm. BUT in Stock the SW still achieves an increase of range of 33% plus. 4 knts is a good lurking/detecting speed and so fair to compare both subs at that speed. Quite obviously, it should'nt need saying, the performance of the SW TA has range and receptivity advantages at higher speeds but that is not the issue.

The stand-off capability of the AK lurking at low speed is now enhaced by 3 Mod changes:-
1. Improved Stallion performance.
2. Revised Torp run range performance.
3. Some levelling of the relative sonar performances AK v SW.

I dont particularly quarrel with these changes but item 3 above has to be weighed with 1 & 2. Perhaps this message of the changed 'odds' has carried to the Fleets where it can be seen in sub v sub dive reports an increasing preference for all divers to take the same platform.

[Bill Nichols]

:zzz:
Maybe you guys should take this off-line.

[Molon Labe]

LW: '' But you haven't answered my question...'' Snap ....except questionS:
You pass no comment on the Kilo bug except that it is ''documented'' But why is it back and why apparently enhanced ? You'll have to ask SCS why it's back.
If by "enhanced," you mean that the range at which it works is greater, then it is for the same reason that all sonars are "enhanced." Please try to understand that DB tweaking can change the sensitivities of the sonars, but it cannot change the mechanics of the sonar model, the user interface, or the way the data is displayed.


The answer to your question is in 3.072 at Test 4 kts both AK and SW TAs in various SSPs give (me) about the same max ranges 30- 34 nm. BUT in Stock the SW still achieves an increase of range of 33% plus. 4 knts is a good lurking/detecting speed and so fair to compare both subs at that speed. Quite obviously, it should'nt need saying, the performance of the SW TA has range and receptivity advantages at higher speeds but that is not the issue. You're going to need to provide hard data. The fact that you're reporting detection ranges of 30-34nm in ANY SSP for a 4knot SW or Akula tells me you're not actually doing any testing (or you're not using a LW/Ami DB). The fact that your reported det ranges only vary by 4nm for both SSP and sonar sensitivity bolster this conclusion.

Here's some hard data for you:
Default environmental settings (SD SSP)
Both subs in the duct
SW det 4 kt AK-II at 16nm.
AK-II det 4kt SW at 5.6nm.

The SW has nearly triple the Akula's detection range!
I'm not going to bother testing the other SSPs.

If you can give me some hard data on how you're getting those extreme results, I'll try to reproduce it.


The stand-off capability of the AK lurking at low speed is now enhaced by 3 Mod changes:-Standoff capability requires both the ability to detect/localize and to engage. At least for the SSP I tested above, the SW can not only detect the AK at greater range, but can close to within no-escape range for the ADCAPs without being detected. Considering that a surface duct is where some of the longest det ranges occur, it seems unlikely that the Akula ever has standoff capability against a SW, and it might be the case that the SW always has standoff capability against an Akula (this assumes of course that the captains are keeping their speed down)


1. Improved Stallion performance.
2. Revised Torp run range performance.
3. Some levelling of the relative sonar performances AK v SW. 1 needs to be balanced against the fact that the -27 ASW was nerfed. The -16, although enhanced in speed, was nerfed in that it's easier to spoof. So 1 doesn't even need counterbalancing.

2: What ASW torpedo has the mod altered the range of? The UGST has the same range as the "65cm" and the ADCAP has the same range as it does in stock.

3. Assuming that your stock data of a 33% advantage going to the Seawolf, the relative performance has become more disparate with the mod, not leveled. (According to the above test, the SW has a 186% edge)

[Bellman]

ML thanks for addressing the AK v SW issue.

I will PM you to arrange to send you the relevant scenarios and Test dumps and perhaps you will em me copies of the Database and Doctrine files that you have for LwAmi 3.072.

I cannot believe that my copies have been corrupted in any way. I have a partitioned HD which has separate installations of DW Stock 1.04 and JSGME LwAmi 3.072.(which has only ever been used for LwAmi.) Both installations were carefully made anew on the 28thFeb 07. Each installation has its own registry entry shortcuts and previous entries are deleted before chnging from partition A Stock to partition B LwAmi and vice-versa.

If you wish to see the full Tests I can place them on YouSendIt (free membership available.) The Dumps amount to 500 mb plus but I guess I can edit - your choice !

Heeding Bill Nichols perhaps we should go off-line. If my install was screwed I will be very happy to return later with a full retraction and report of latest test findings.

[Molon Labe]

Solid data from at least one test demonstrating the problem is what this issue really needs now. If you want to get into "bonus materials" after that, that's fine, but let's get a floor before we get to the ceiling.

[Bellman]

:D OTW.

[Molon Labe]

Okay, I've run your scenario and I think I have a few insights.

First, the contact detected was not a SW for the AK tests and an AK for the SW tests. In all cases, the target sub was a Victor-III. (Nothing wrong with that--in fact, if the issue is specifically the TA performance rather than relative detection ranges, it is superior--but it's not what I thought you were doing) That explains the extreme detection ranges.

Your method seems a bit odd; you've got several subs thrown around and you seem to record whether or not they are detected, instead of the maximum range detection occurs at. I wanted a single maximum detection range rather than a locus of binary data points. So, I took your scenario and deleted all but the testing sub and one target sub. I drove the testing sub at the target sub until I got a NB signal.

SW detected the Victor at 37nm (and I was a little slow, I think I need to turn my gamma up...)
AK detected the Victor at 31.5nm.

So there you have it... even under your testing conditions, the TB-29 outperforms the Pelamida-II.

Now, where could things have gone wrong? My guess is that the phenomenon we sometimes see in DW where the initial NL of a platform is high for a few seconds after mission start allowed you to tag several victors immediately with the SSAZ display, but many of those signals had faded by the time you found them on the waterfall. Maybe I'll have to ask for method in addition to data in the future...

[Bellman]

Thanks ML for having a good look - there's nothing there I dont agree with. :up:
Perhaps we just disagree on a degree of interpretation of the results.

You dont refer to the Stock scenario Test results. I happen to think that your test results of 37 v 31.5 nm confirm my finding that the relative differential has been narrowed from Stock where one can obtain 47.9 v 37 or even (with difficulty 65.7 v 37) in that scenario.

PS. Good point about the fading I referred to that in my test reports - but that feature is something which of course is exploitable particularly with gamma adjustment.

[Molon Labe]

Thanks ML for having a good look - there's nothing there I dont agree with. :up:
Perhaps we just disagree on a degree of interpretation of the results.

You dont refer to the Stock scenario Test results. I happen to think that your test results of 37 v 31.5 nm confirm my finding that the relative differential has been narrowed from Stock where one can obtain 47.9 v 37 or even (with difficulty 65.7 v 37) in that scenario.

PS. Good point about the fading I referred to that in my test reports - but that feature is something which of course is exploitable particularly with gamma adjustment.

OK, I'll go test the stock ones for a comparisson, but I'll retest on mod first since I got the SW a little late.

[LuftWolf]

Ok, the good news is that we've got some progress on this discussion.

The bad news is that I'm really sick, and won't be able to work on 3.08 today, and maybe not tomorrow.

When I feel better, I'll finish it up.

Cheers,
David

[ASWnut101]

Cold? Flu? Smallpox? ASWnut has your cure!:up:




*Side-effects are given "as is," and any negative effects from ASWnut's cures are in no way his fault. Use at your own risk*

[Molon Labe]

Okay, I've done two more rounds of testing instead of one. Why two? Because as it turns out, the sonar model is more complex than I give it credit for, and it's effect needs to be shown for the results to make sense.

The surprise is that the louder a contact is, the less of a difference there is in sonar performance. So, when we go from stock to lw/ami, there is a variable changing that our tests haven't accounted for: the NL of the target vessel. I can't tell exactly how great this effect is, because the margin of error caused by differences in the SSP between each startup is too great.

But, I can give you some raw data:
First, the continuation of the test above:
Target contact: Victor III 5knots
TB-29 mod: 37nm
Pel mod: 31.5
Modded gap: 17%

TB-29 stock: 43.4nm
Pel stock: 35nm
Stock gap: 24%

Next, we'll try a quieter contact...like one you might actually fight against
Target contact: 688I 5 knots
TB-29 mod: 14nm
Pel mod: 6nm
Modded gap: 133%

TB-29 stock: 22.8nm
Pel stock: 16.8nm
Stock gap: 35%

I tried to run some tests to establish that the greater the NL, the smaller the difference in performance, but the data came out on both sides. Essentially, large NL differences show the effect while small NL differences show the opposite. I think that I'm right about the NL effect (the huge difference between the Victor and 688I is too significant to overlook), but that there is something else at work too. Maybe there's just a large margin or error (at least 5nm around NL=70) from the differences in the generated SSPs. Or, maybe the charts we've been relying on for NL are off a bit?

So, I can't say that in all cases, there has not been a decrease in the performance gap between the TB-29 and Pelamida, but I can say for sure that for performance against quiet modern subs, the gap has increased significantly.

I hope this puts the underlying balance concern to rest, since in game we'll be dealing with subs with NLs closer to the 688I than the Victor III.

[Bellman]

ML I think that you have fingered an important feature the effects of which are more
relevant in SP than in MP.

The test speed of own platform is crucial as at 4kts the very faint tonal or more often an intermittent BB SNR of 1 may account for increased range results in the SW. Also sprint, drifts may be a test variable. Perhaps these may account for my Stock test ranges beeing greater and therefore showing a higher performance edge of the TB29 over Pel. Your tests confirm the 24% gap on average but higher performance is frequently obtained with a 60% gap with care. The SWs BB SNR has an advantage over the AKs
and the AKs early-day fleeting tonal ghost is no compensation.

But for MP I will have a look (this weekend) at the implications for quiet sub v sub contests. If only to reassure myself in confirming your findings. Thanks again for your testing and valuable contribution.

[Bellman]

It only seemed fair to take time out to bring forward tests.

The AK v SW sonar game has been a major hook for many bubbleheads since SC days. So whilst ML has chosen to run the 688i against the SW I thought it may add a bit to test the AK v SW TA NB performance.

Here are my results from tests today:

Tests TA NB Range maxima.

Stock:
Ak tracking SW and 688i

688i at 18.6 nm
SW at 13.7nm

SW tracking AK
AK at 19.9 nm

Conclusion - SW has 45% increase in range over AK head to head.

Mod:
Ak tracking SW and 688i
688i at 9-10 nm
SW at 8.7 nm ( Greater ranges found in other scenarios but the differential is always steady.)

SW tracking AK
AK at 9.3 nm ( Greater ranges found in other scenarios but the differential is always steady.)

Conclusion - SW has a reduced advantage in range over AK in head to head.
The absolutes have indeed been reduced from Stock, but the differential in TA sonar performance has been dramaticaly reduced. (Test scenarios available.)

NB. Used ranged target subs and MLs run-in range reduction to obtain results. All subs at -5 knts above layer and SSP and location as before. No BB SNR readings were taken just NB tonals.(This could improve SW ranges but not material to NB comparison)

[LuftWolf]

It's a good thing this discussion is entirely academic... the database can't be set any more correctly than it already is. :-?

Except for those "secret values" only Ludger and I know about. :cool: :rotfl:

Cheers,
David

PS And Bellman, your last findings directly contradict Molon's findings, so you might want to look at your scenario again, but it's really none of my business at this point... because like I said, the database isn't changing from something that's correct, to something that is incorrect... especially because this is the way things have been set for over a year and exactly zero people before this have made any comments regarding this, and believe it or not, I tend to hear about problems reasonably quickly...

[LuftWolf]

Just to give MY last comment on this.

I haven't changed anything related to sonars or platforms noise levels in over a year (December of 2005).

So, I think you missed the boat, since I'm certainly not changing anything now. The SW has a VAST detection advantage over other submarines, and in some situations the mod makes this greater and in some situations the mod makes this less. These are simply the facts and the database itself is the ultimate piece of evidence.

Cheers,
David

[Molon Labe]

Well, I've been corrected by LW that ownship speed doesn't matter as long as you're not in washout range, so I retract my statement about needing to retest controlling for speed. All testing was done at tactical speed and washout was not a factor.

I also want to express my agreement with LW concerning the fact that the NL's and sonar sensitity has not been changed for ages. I've been playing with these levels for a long time now, and it's always been absolutely clear that the American subs had a substantial detection range advantage due to the combination of quieter subs and superior sonar. In fact, the principal fair matchup in LW/Ami was the 688I vs the Akula II, instead of the SW vs. Akula II, because the SW just pwned the Akulas. (1.04 probably tips the matchup back to the SW).

I can only guess this issue is surfacing now instead of when the sonar sensititivies were set because of the changes in 1.04. But, what these test results make abundantly clear is that even in sonar conditions that favor long-range detection (being inside a surface duct), the Seawolf can close with an Akula-II to within no-escape range without ever being detected. And that's without playing any layer tricks. It's only a matter of time before SW skippers learn to control their speed at the right times to become proficient at doing this, and once that happens, it will be the Akula skippers bitching and moaning about the balance changes in LW/Ami--because they are going to die without ever having detected the launching platform, and CMs aren't going to defeat wireguided torps guided in from less than 8nm.

[Bellman]

OK guys I'm going to quit the field now (general sighs of relief :D)

I am not yet convinced that something, possibly 1.04 as ML says, has'nt changed the mix.
But I'll mothball-it and perhaps return to the matter further down the road.

Thanks at least for addressing my concerns.

[LuftWolf]

There were no passive sonar changes in the DW engine in 1.04.

Cheers,
David

[Molon Labe]

I said 1.04 tilts the fair matchup; I didn't say that it changed anything with the sonar.

[Bellman]

:D So who tweaked the Kilo SA ? :lol:

[LuftWolf]

:D So who tweaked the Kilo SA ? :lol:

*yawn*

I don't have the energy to explain the difference between the acoustic engine and the interface.

Cheers,
David

[Bellman]

:rotfl:''Yawn'' .........................catch you later. ;)

Thats a promise. :yep:

[LuftWolf]

Then you really wouldn't have liked all the stuff I wrote about SW divers being
"special" and feeling "entitled" and then deleted for not wanting to be inflammatory... :lol:

Cheers,
David

[LuftWolf]

For the five people who are still reading this thread outside of Bellman, Molon, and myself...

I'm feeling a bit better today, so I'd expect LWAMI 3.08 to be out tomorrow.

Cheers,
David

[Bill Nichols]

For the five people who are still reading this thread outside of Bellman, Molon, and myself...

I'm feeling a bit better today, so I'd expect LWAMI 3.08 to be out tomorrow.

Cheers,
David


Okay. I wonder who the 5th person is...?

:cool:

[Dr.Sid]

Me and my other nick ..

[Linton]

Luft wolf would it be possible to archive the details of each of your mods plus more importantly the data that you rely on to make your mods,such as detection ranges etc.

[LuftWolf]

I thought that's what I was doing with the readme? :hmm:

Regarding materials on detection ranges and platform noise levels, all of this data was taken from primary source materials available to Amizaur in Poland, mostly by the Russian Eugene Miasnikov, and then adapted to the DW database format by finiteless, jsteed, and Amizaur.

http://www.armscontrol.ru/eugene/e-pubs.htm

You'll notice one of Miasnikov's specialities listed on that page is "detectability of submarines and its impact on strategic stability in the world."

Cheers,
David

[LuftWolf]

For those of you who want to do some reading, I suggest this as a starting point:

"Can Russian Strategic Submarines Survive at Sea? The Fundamental Limits of Passive Acoustics", http://www.princeton.edu/~globsec/publications/pdf/4_2miasnikov.pdf , Science & Global Security, 1994.

Cheers,
David

[Kazuaki Shimazaki II]

Then you really wouldn't have liked all the stuff I wrote about SW divers being
"special" and feeling "entitled" and then deleted for not wanting to be inflammatory... :lol:

Last night, I was within an inch of starting a thread on this very subject myself (and giving up for the same reason), triggered by this latest row. It always seems (to me anyway) that the Akula guys are more "stoic" about things not to their favor (at least in their opinion) and it is the Seawolf guys that make massive noises every time something happens that seems to reduce their massive advantage. I don't find fighting for your own side particularly wrong, but I do personally find this fascinating.

Anyway, I, like all the others, await v3.08. Actually, I'm in a break period on DW (I tend to go on breaks when LWAMI keeps changing until it stabilizes), so it is more realistic to say I'm waiting for v3.1 or so... :cool:

[LuftWolf]

Beh! :smug:

I'll make as many versions in two days as I want! :p

Seriously... I'd rather not have things go this way, and after 3.08 every version of the mod will go through a thorough testing process.

I got seriously surprised by the DW engine a couple times... and I thought I'd seen everything. :88)

Cheers,
David

PS The 688i divers are the most stoic of all! :cool:

[Micksp]

Maybe i'm the 5th element reading this thread:lol: most regulary... LW, you do great work and i'm always pleased playing with the mod. I have some knowledges about Russian navy, i was on real navy duty in the past, not in Russian navy but very close. I'm so sorry because i can't share here most of my knowledges, just to say DW can't be as it is in the RL and navy operations but LWAmi makes the game most better and interesting. Keep going, mates:up:

[LuftWolf]

Thanks mick! :)

I've sent the final files for 3.08 to Oneshot, he should publish them soon! :up:

Cheers,
David

[Micksp]

Do you mean LWAMI_v308_GOLD.zip?

[LuftWolf]

That's for Oneshot... but there is no harm if you would like to download it, it's just not "official".

Cheers,
David

[Micksp]

I'll just take a look later. Thanks!