LuftWolf and Amizaur's Weapons and Sensors Realism Mod

[LuftWolf]

The 53-56KE Wakehomer will now cripple a Harper's Ferry LSD with a single hit, two will sink it. (I think it used to take four).

Molon, are you sure?

Unless the modification to doctrine causes the damage to be modelled differently which is unlikely (I was thinking perhaps that a delayed torpedo detonation on a ship may be somehow modelled as the missing "under keel detonation" but that's farfetched I think), the number of torpedos needed should be the same, as both the warhead of the torpedo and the survivability of the Harper's Ferry have been left unaltered. It should take three 53-56k(e) to sink the HF LSD. :up:

[LuftWolf]

How big is this mod as I am back on crappy dialup until I get my ADSL back

342kb. :up:

I would especially appreciate your feedback.

I think perhaps you have a point about the ADCAP's, however, it's value may be worth it. We especially want feedback about this feature. :know:

[Molon Labe]

Yet one thing .. with all MASSIVE respect to modders .. WHY THE HELL did you include readme in that BEEP BEEP DOC format ? Even if we are all supposted to have windows, do we have to lick Bill's BEEP by using that BEEP BEEP MS Word ? Don't you guys know html or something like that ? :damn: ;)


No, you don't
www.openoffice.org

[Molon Labe]

The 53-56KE Wakehomer will now cripple a Harper's Ferry LSD with a single hit, two will sink it. (I think it used to take four).

Molon, are you sure?

Unless the modification to doctrine causes the damage to be modelled differently which is unlikely (I was thinking perhaps that a delayed torpedo detonation on a ship may be somehow modelled as the missing "under keel detonation" but that's farfetched I think), the number of torpedos needed should be the same, as both the warhead of the torpedo and the survivability of the Harper's Ferry have been left unaltered. It should take three 53-56k(e) to sink the HF LSD. :up:

It is possible that there were two torpedoes fired simultaneously and appeared as one object. If you haven't changed anything, than I'm probably wrong. (In fact, I think the ship sent three damage report messages)

About the seekers on the torps from your prior response....I didn't observe any problems. Acquiring from 2 miles was a bit further than I expected, though but that's consistent with the unmodded game.

[LuftWolf]

2nm is well beyond the specification range of the seeker modelled for the mk50/54, whose stated range is 2300m or around 1.25nm, however that can very for conditions and target type/aspect.

I was just playing around with one of my test scenarios and the Mk50/54 pick up the Gepard around 1.25nm from an angled aspect, perhaps if you were shooting at a large ship from the side, that range could be increased? :hmm: Are you sure of the measurements?

In any case, I think I agree with you and don't feel it's a problem. :up:

[OlegM]

First of all hats off to LW and Amizaur - you're doing great job to improve the game, and I will be using your mod.

Having said that, here goes my criticims - it's not going to be nice, so watch out :ping:

Well call me shallow, stupid, boring or what have you but I am documentation freak, especially when it comes to modding...

I must say I've never seen more confusing documentation than the one that accompanies this mod. Authors really tried to explain everything, I give them that, but it's so confusing, perhaps they went too far.

Good part of the documentation is actually directly copy-pasted - warts, typos, smileys and all - from author's e-mail correspondence, ie. they, sorta, argue whether something should be done this way or that way. Instead of making authoritative decision privately among themselves (hey it's your mod after all) they copy-pasted their dilemmas and diverging opinions directly in the readme?! Hello?

On couple occasions red-letter guy (Amizaur I think) says something directly opposite to the black-letter guy (LW). Hey? Can't you guys, like, agree among yourselves privately and then implement the decision, and document it in a simple manner? I I'm not really interested in reading your e-mails ;)

First of all, are you two sure you understand each other, and that every change intended by guy A is received and implemented by buy B? Just checking guys... after reading the mod docs, and reading about your e-mail problems here on the board I really can't be sure everything you two intended is really "in".

Come on, you have e-mail for that. Once you settle on how some problem should be dealt with, put it in the mod, document it and let us know. It's incredibly confusing to have to sift thru your correspondence badly disguised as "readme" in this way.

Note or paragraph that describes Mk46/Mk54 change or swap has to be among the most confusing paragraphs I ever read in my life :doh: Seriously I think it takes phD to understand half of what you wrote there.

Also, I agree with whoever said MS Word format should not have been used. Use RTF.

And I agree with whoever hinted at the idea of making mod changes be listed in USNI database, accessible during the game. It would be handy and should be easy to do, and there are LOTS of changes in this mod, which will seriously affect the gameply (which in itself is a good thing, as long as players understand what goes on around them).

With documentation this confusing, I feel unable to comment on the quality of the mod itself. I am not always quite sure what you intended to do, or how you two think certain problems should be solved. Once I get thorough understanding of your ideas and intentions, I will be capable of judging the mod for what it is.

I should add I'd be using your mod even in this IMO confusing state simply because I like what you do (at least the parts I *do* understand LOL) - and doctrine changes seem to be quite good (again, those that I managed to test in play).

Keep up the good work but please improve your decision making process, and mod documentation :arrgh!:

Oleg

[OlegM]

Note or paragraph that describes Mk46/Mk54 change or swap has to be among the most confusing paragraphs I ever read in my life :doh: Seriously I think it takes phD to understand half of what you wrote there.


Let me post this small example (from the mod documentation, related to Mk46, or Mk50, or Mk54 or whatever):

"I have given the Mk46 ASW torpedo Mk 46 specs, and swapped out the modded Mk 46 in all non-American platforms and the Mk46 ASROC for the Mk 46 ASW (with Mk46 specs)." :dead: :doh:

ROFL!

:rotfl:

[LuftWolf]

Thank you for your feedback, Oleg and I am glad you are using the mod.

Yes, I am aware that the documentation is a "rough draft." Consider Amizaur's word to be authoritative. In fact, I read the mk46/54 paragraph several times and concluded it was very poorly constructed. On the plus side, all the time that would have gone into polishing the readme went into the mod itself, so I can assure you it's MUCH more polished. ;) That is to say, both Amizaur and I were/are under real time constraints and I wanted to stick close to our announced distribution date, this meant that there are some typos and rough spots in the documentation (sound familiar... now I know why games often come the way they do...). We have already planned v2.01 to clean this up! :up:

Also, Amizaur's comments are directly made to the readme itself not posted from email. I thought it was interesting to have the development be "open source", since we are actively looking for community members to be involved in the process of working to improve DW. Ultimately, the mod reflects the opinions of Amizaur, myself, everyone listed in the readme, and everyone who has posted about DW to Subsim or BFC.

[LuftWolf]

However, I think this line

The purpose of this mod is, straightforwardly, to address the aspects of DW game-play that most bother its authors, while improving the simulation experience and fixing bugs, without introducing any new ones.

is an *amazing* piece of composition and sentence structure. :yep: :-j :P

And frankly I used Word because it was easier. ;) :lol:

I probably should have changed the format, but its here on the forum too. :88)

Once the editing has been done, I will probably take your suggestion and change it to RTF.

[OlegM]

I am OK with this mod being as you say "Open Source" - though thing to keep in mind is that even OS projects have bosses and project leaders ;)

But then some place - say this board, or private messages - should be used for decision making process, and once the decision is made (by whoever is in charge) - it should be documented in simple, clear and straightforward manner.

Another example of using "readme" instead of board. WH doctrine, first the black letter guy says:

"Amizaur has reduced somewhat the effectiveness of wake-homing torpedoes by..." etc.

Then the red letter guy (obviously Amizaur) replies to that:

"Well I think it not exactly this way. I didn’t mean to reduce effectiveness, this is only side effect. " etc.

:doh: :dead: :88)

[LuftWolf]

Without getting into it, Amizaur and I have exchanged dozens, perhaps well over 200 emails in the past three weeks, its not entirely possible for each of us to totally understand each other all of the time.

Putting the total scope of the changes in the readme was a very difficult task and I'm actually glad I did as reasonable a job as I did and that Amizaur did not feel inclined to change whole sections about his additions.

Thank you for your patience, as I know that good documentation is crucial for any project like this, in fact, one of my main goals in creating this mod was to provide the best documentation possible. Please continue to post if you have any questions about specific changes until we can nail everything down in the very soon to come followup 2.01. :up:

[Tgio]

Boys, keep up the good work! :up:
I've downloaded your mod (2.0) this morning :D and had a very hard knife fight OHP/Helos Vs Kilo and Han this evening :arrgh!: Great!

To be honest, I have reinstalled DW (removed while waiting for patch 1.02, please don't blame me) just for trying your mod (from version 1.0).

And now I feel it will remain on my HD for a very very long time now.
Thank you for letting me re-discover this GREAT game.

[Deathblow]

Great mod. Can tell a lot of work went into it. Much props and I'm throughly enjoying it. :up:

You asked for feedback. You might want to reconsider the new AI minimum depths for ASW torps (helo drops, ASROCs, etc). I was able to exploit it in my sub, by emergency blowing to the surface everytime I got a helo-dropped torp that I couldn't evade. Shot to the surface, while the torps circled below unable to reach me. When they finally went into search mode, dropped back down to speed away, until they reaquired, then rinse and repeat. Worked every time against he Mk46s, havn't tried it against the the Russian dropped torps, but if they are using the same doctrines, then it will be the same result.

Its good to prevent friendly fire, but couldn't possibly be exploited against Stallion or SS-n-27-ASW weps. :arrgh!:

db

[Molon Labe]

The FFG cannot assign the MH-60 to drop a Mk54 via ASTAC, even if both Mk50s are expended. Right now, the MH-60's effectively only carry two torpedoes.

[LuftWolf]

Molon, you can still fire the MK54 from the Nav Map, I'm not sure why can't use them with waypoints. I am going to play around with a few things, but for now, fire the torpedos from the Nav Map, that way, you can also select the individual torpedo dropped by the helo.

I think this has something to do with the hardcoding of user platform weapons, and the FFG AI helo is something of a gray area, so part of the game is hardcoded to ignore weapon changes (the interface modules) and the rest of the game allows the change. As I almost never fire torpedos off of waypoints in the air platforms, this doesn't effect me too much, but I don't think we have a workaround in the DB, the game is coded that way.

I have to say thank you very much for putting the mod through such a very thorough review. :up:

[LuftWolf]

I just shot some Adcaps at a few targets, and I noticed one annoying thing about the torpedo active/passive information. The feature itself works very well and is an excellent addition, but the auto TMA keeps merging the torpedo data with the target data, essentially making the torpedo data disappear, and not moving the target into the correct place. Turning auto TMA off would fix this, of course, but for people who want to track other targets and simultaneously have the torpedo data, it doesn't work as well.

Is there any way to prevent the torpedo data from merging with the ship sensors data? Perhaps the torpedo data could somehow be classified as link data?

Sorry about the delay in responding to you. ;)

Thanks for your feedback on this feature. Since the ADCAP is considered a sensor extension of the sub, it cannot be treated as a link contact.

The range of the feedback sensor on the torpedos however is very small, so you know that when it detects a contact along a certain bearing, you also have a fairly good indication of its range and thus its total position. I have to play around with this a lot more during actual gameplay, but you could turn the auto-TMA off during the final acquisition phase of the torpedo if you'd like and that would solve the problem. This would also allow you do to your own target-evasive maneover plots, which can sometimes be better than the auto TMA solution during maneovers, since you can make an educated guess as to where the other sub would try to go to avoid a torpedo. Moving back and forth from the firecontrol wireguidence area, the TMA, and the Nav map to try to give the torpedo final guidence on a ASW target, now that's excitement! :rock: :arrgh!:

[LuftWolf]

Tgio, thank you very much for writing that! We hope you enjoy. :up:

Deathblow, yes that is one of the unintended consequences of the anti-casualty torpedo fix, unfortunately. As with a number of things in the mod, the performance of that feature during actual gameplay needs to be looked at closely, especially in circumstances where there is a regular player exploitation (especially during MP). Right now, it is one of those things like the AI-non detection of sails and mast so player can shoot down planes and helos with their SAMs, it only has an effect on gameplay if the player actively decides to exploit it, and since this is a realism mod, we assume players interested in the mod could overlook such a defect for now.

We are looking at tightening this up for v2.01, but the solution may be to make it an optional feature of the mod, along with the non-CM exploding torpedo doctrine, since some people prefer it the otherway. That is why Amizaur included the only random snake-only version of the torpedo doctrine. The torpedo doctrine mods are completely stand alone, although the ADCAP and USGT would have enormous seeker cones for the standard 45 degree snake pattern, not corrected in any torpedo doctrine but the anti-casualty version for now.

[LuftWolf]

Molon and everyone,

Just so you know, I am working on the MH-60 torpedo way-point issue, although I'm not necessarily hopeful I can change it, just learn more about the parameters, but I don't feel its a huge issue either.

Depending on the results, I may also change the ASW warfare loadout of the FFG AI Helo to two MK54's and one MK50 (I still haven't verified if I can do this, I got this as a quick idea before I have to go do something else, not nearly as fun... :-j ).

Cheers,
David

[gregcom]

I check active sonar frequencies and ADCAP freq are same like other torpedos (22000 Hz). Please make individual frequence also for ADCAP.

Unique sensor name Max- Hz
688I MF Active 2500
Akula MF Active 4000
FFG Active 7500
Kilo MF Active 5000
MH60 Dip Active 14000
SSN21 MF Active 2800
Active Sonobuoy 15000
Active Buoy Deep 10000
Dipping Sonar 13500
HF Act Son 13000
MF Act Son 2500
Surf HF Act Son 15000
Surf MF Act Son 3500
Wep Sonar 20000
DiCASS Act Shallow 10000
DiCASS Act Deep 10000
TorpedoActive 22000
TorpActiveADCAP 22000
TorpActiveUGST 21500
TorpActiveMk50 24000
TorpActiveMk46 21000
TorpActiveMPT-1UE 23500
TorpActiveUGMT-1 22500
TorpActiveUSET-80 19000

[Fish]

Moving back and forth from the firecontrol wireguidence area, the TMA, and the Nav map to try to give the torpedo final guidence on a ASW target, now that's excitement! :rock: :arrgh!:
In the mean time steering your UUV, launching decoy's and making evasive manoeuvres. :huh: :88) :hulk:
Ohh, and try not to ran aground. :shifty:

[Molon Labe]

Molon, you can still fire the MK54 from the Nav Map, I'm not sure why can't use them with waypoints. I am going to play around with a few things, but for now, fire the torpedos from the Nav Map, that way, you can also select the individual torpedo dropped by the helo.

I think this has something to do with the hardcoding of user platform weapons, and the FFG AI helo is something of a gray area, so part of the game is hardcoded to ignore weapon changes (the interface modules) and the rest of the game allows the change. As I almost never fire torpedos off of waypoints in the air platforms, this doesn't effect me too much, but I don't think we have a workaround in the DB, the game is coded that way.

I have to say thank you very much for putting the mod through such a very thorough review. :up:

LW, unless your opponent is incompetent of off-guard, ordering the helo to drop without assigning a waypoint will accomplish nothing but getting the helo shot down. I'm glad you're looking into the waypoint problem, but if you can't do it, I think you should return the loadout back to normal. Using the nav map is simply not a viable option.

Oh, and I haven't been thorough yet. I've just run 3 missions through and noted some observations. I might get thorough over the weekend ;)

[LuftWolf]

Gregcom, oops, yeah we'll make a new frequency for the ADCAP! :up:

Fish, the last thing we want to do is add a burden to the player. However, new information access comes with a price and in this case that price is either the extra work of turning off auto TMA and doing your own TMA for a time or leaving auto TMA on and doing the recalculations and replot in your head to place your target. I have the next two days or so to actually PLAY with the mod, so maybe I'll lean in other direction and say that it's just a pain, but I think if you had a handle on just how short a range the torpedo sensors pick up targets, you'd be able to work around the problem in your head.

Molon, I'm not sure why waypoints with torpedo drops are even useful, let alone necessary. Perhaps I really do need to play the game more. :88) After some thought, here is the actual problem with helo loadout: The original loadout of the AI controlled helo on the player FFG is two mk50 and one mk46 ASW Torpedo, NOT the regular mk46 torpedo. If it were the mk46 normal torpedo as the original we could change the specs of it all day long and nothing would fail. However, if we simply changed the torpedo from Mk46 ASW to Mk46 normal (as should be the case, there is no MK46 ASW only torpedo in real-life, this was put in to prevent the AI helo from attacking surface ships with Mk46 for some unknown reason), the same problem would arise.

So it seems like the choice is either have the normal mk46 ASW torpedo reassigned (we have changed the asw version of the torpedo to normal specs so it could be assignec to non-US platforms) to the AI MH-60 (player controlled helo is unaffected) and get waypoint function for that one torpedo, or have the MK54 for the AI controlled helo but without the ability to drop it on an assigned waypoint. I am going to try some working around now, but I'm not hopeful.

Perhaps you could explain to me how to use torpedo drop points?

[LuftWolf]

Molon,

I have confirmed that restoring the Mk 46 ASW Torpedo to the AI MH-60R of the player controlled FFG restores full torpedo waypoint functionality to the platform's third torpedo. This change effects ONLY the AI controlled MH-60R's. The "bug" is hardcoded into the interface modules and there is no workaround that I can think of.

The choice right now stands at MK-54 with no waypoint capability or Mk-46 (modded to normal version) with waypoint capability.

I am going to try changing the load out of the helo now, perhaps by trying to make the situation worse I'll find a solution. :|\

Edit: I don't think there is any more progress to be made in fixing this, just the decision outlined above. To be honest, I'll need a really convincing argument not to leave it as is, however, I don't think I'll be changing the loadout down to 1 Mk50 and 2 Mk54 in the distribution version since it seems to be a valueable feature, torpedo waypoints, that I just don't use (I'm simply not that on top of when I want to drop a torpedo, usually I decide within seconds of doing it or have plenty of time to deliberate a shot, but not in between anyway...). So I guess only my version will have two Mk54's and only one Mk50 anyone else feels like I do.

I'm really interested to hear what everyone thinks of this situation, since it's a clear choice for once. :lol: ;) :hmm:

Edit: I have created polls on the main DW forum about the Mk54 and the torpedo feedback feature.

[Molon Labe]

LW,

thanks for looking into the loadout.

To answer your question, to set a waypoint, you go to ASTAC and click on the helicopter symbol on the horizontal situation display scope. Then, click the "torpedo" (or maybe "weapon") buttom toward the bottom of the display. A box with a "T" attached will appear on the scope in front of the helicopter. You then can drag this to the location you want the helo to drop at (just as you would do for sonobouys)

[Tgio]

Some feedbak for you guys.

1) Please put in the doc the advice: "End your saved mission before using the mod. Otherwise you will not be able to load them". I discovered this today, not a problem for me (I use just 1 mission saving and 1 campaign saving) - I think it is not a problem with only my installation.

2) Have you modded AI subs to remove the "blind spot"? Just curious...

3) Helo loadout. I've never used torpedo waypoint :hmm: (a lot of buoys, indeed :smug: ). So I don't miss them. Using the map works great for me... My helo dropped its torpedos at a safe distance against enemy surface ships while playing escort to the Viraat (campaign mission) :up: .

4) A Silly question. Have you modded sensor positions? At the end of missions I like staying on the bridge and having a look around. I've pointed my binoculars on the Viraat battlegroup and noted the carrier's radar sweeping. but NOT on its mast!!! It was just FLYING CIRCLES around the ship :o :o !!!! To be sure switched Truth ON (maybe I've seen a helo, after all). Nope. Note this: 3D views is OK, problem occours only using binoculars and watching the Viraat.

I'm not kidding and I'm not drunk too...
:arrgh!:

Cheers

[LuftWolf]

Molon, yes I know THAT! :-j I mean, how do you use them tactically, but you answer that in the poll thread.

Tgio,

1) Yeah, sorry, that should probably be in there, I've changed my DB so many times that I take it for granted that people don't know database changes invalidate saved games for the new db. ;)

2) All sonar-bearing platforms have sonar parameters that reflect their real-world capabilities as modelled by DW. So, subs and ships without a TA have a baffle and subs and ships with a TA have less sensitive sonars in the front sphere and side hull positions. All AI sonar configurations are based and modified off of either the 688(i), the Akula, the Kilo , or the FFG sensors.

3) Sounds good! Me too! :up:

4) No, we haven't changed anything to do with the Viraat radar that would cause that to happen. Since it didn't happen in 3-D view, I would guess that it was some kind of bug related to that particular load or saved-game. Not sure, wierd. Did you notice in with the standard DB and have you repeated it from a fresh game? I can look in the DB to see if there is anything wierd there.

[Molon Labe]

2) All sonar-bearing platforms have sonar parameters that reflect their real-world capabilities as modelled by DW. So, subs and ships without a TA have a baffle and subs and ships with a TA have less sensitive sonars in the front sphere and side hull positions. All AI sonar configurations are based and modified off of either the 688(i), the Akula, the Kilo , or the FFG sensors.

Does this mean that the sensitivity of the AI sensors is the same as the playable platform is was modeled after? That could explain the better-than-expected performance of the Udaloy in detecting the transiting 688I under the layer. (Although I think the performance was a little too good for either vessel, but that's purely speculative)

[LuftWolf]

No, there are something like 50 to 60 AI sonar models in the mod (up from the stock DB which had 2). There are up to three variations of any individual sensor.

I can tell you the Udaloy array is fairly less sensitive than the SQR-19.

I think your tests are showing better than expected performance because you aren't taking into account how much louder platforms become now when they are moving above 1/4 to 1/3 of max speed.

Cheers,
David

[LuftWolf]

Ok, I just wanted to let you guys know that I had an oversight when entering values I was responsible for into the DB: I forgot to correct the seekers for the French torpedos L5, F17, E15, and the Germans torpedos SUT and SST-4. They retain the original seekers.

I have already corrected this in the working database we have now.

The following are also being considered for 2.01:

--Increase effectiveness of launched torpedo CM's to 50% (done).

--Missing torpedo seekers (done) and make distinct active ping frequencies for each torpedo active sonar.

--Passive sonar sound level and Sound vs Speed tweaking.

--Editing of all active sonar models along the lines of the FFG and DICASS mods Amizaur has done for v2.0, based on the success of the initial changes.

--Documentation updates: POLISH THE README (emphasis added for me), add unit specification tables including sonar capabilities, and correct the graphs to reflect new values.

Let me know if there is anything else you have raised that I am forgetting. Thank you! :up:

Cheers,
David

[Amizaur]

Having said that, here goes my criticims - it's not going to be nice, so watch out :ping:
Well call me shallow, stupid, boring or what have you but I am documentation freak, especially when it comes to modding...


Oleg, all criticism is welcomed and your is very well-grounded :) The documentaton should be better and will be made from the scratch.
Only it would took a day longer before mod could be relased.
I didn't know that Luftwolf will include my comments directly into readme :oops: :) And the ReadMe should be in txt or at least there should be a copy of it in txt.

And something I forgot to write before - the mod is not very well tested as a whole. We had no time. So there can be errors. There probably are errors :). But I promise they will be fixed as soon as found and reported to us :up:
Well some things will be fine tuned, documentation will be written again, so now I think we should rather call the relase 2.0beta :oops: but anyway we have some great feedback from you, thanx ! :up:

[LuftWolf]

I didn't know that Luftwolf will include my comments directly into readme And the ReadMe should be in txt or at least there should be a copy of it in txt.

I apologize for that. A reasonable rewritting of the whole thing would have taken hours longer than I had the morning we released the mod.

Future releases will not be made under the same time pressure and so we will be able to document everything in a polished and thorough manner. I really appreciate your forebearance with us on this and a few other rough spots. :know: :up:

[Amizaur]

Great mod. Can tell a lot of work went into it. Much props and I'm throughly enjoying it. :up:

You asked for feedback. You might want to reconsider the new AI minimum depths for ASW torps (helo drops, ASROCs, etc). I was able to exploit it in my sub, by emergency blowing to the surface everytime I got a helo-dropped torp that I couldn't evade. Shot to the surface, while the torps circled below unable to reach me. When they finally went into search mode, dropped back down to speed away, until they reaquired, then rinse and repeat. Worked every time against he Mk46s
Its good to prevent friendly fire, but couldn't possibly be exploited against Stallion or SS-n-27-ASW weps. :arrgh!:
db

Well, now I see your problem. OK, we'll check this :)
The AI torpedos ceiling is modified ONLY if there are surface targets in vicinity. If you are a lonely sub in the middle of an ocean, they will get you on the surface with no problems. If there are surface tagrets in proximity (that torpedo could detect) then ceiling is changed and then you can escape by surfacing.

(so if there were NO surface targets close when you experienced this, then you found a bug! it shouldn't work this way then)

I could do this other way and order to always attack a sub whereever it is, and always avoid surface. I chosed to make it more realistic, and if there are surface targets close you can escape to the surface, as I assume than responsible human operator would NOT set torpedo ceiling up to the surface is there are innocent civilian or own surfaces close. If the sub surfaces... well somebody will take care of him in most cases with some guns or missiles :-). He can't dive down again untill the torpedo is circling below, in most cases.
If there is no surface ships in proximity or the torpedo will be dropped in a way that it will not see other targets than the sub (so in direction away from the surface target) the ceiling will be not affected and surfacing will not help. Also settings of human player torps are not affected, human player can risk and set ceiling to whatever value he wants, it's his responsibility. I hope I cleared this a little.
If it turns on that the doctrine behaviour can in fact be exploited by players too much (so they will be escaping by surfacing close to civilian targets - but this is IMO realistic way to escape, who would set his SUBROC's ceiling to surface when they are civilians or friendlies on the surface ?) then I will change the conditions and escape by surfacing will be not possible in any situation. It's possible and very easy, I only tried to add some realism to AI actions, but if this not work good and is too easy to exploit - I will change it!

P.S. :lol: Luftwolf, it was intended by me to be this way - that you CAN escape by surfacing sometimes - if there are surface targets close :).
I will test it further checking how easy it's to exploit this against AI and can change it to always attact sub if needed.
Well, at least Akula drivers now can attack with SUBROCs enemy subs in proximity of civilian ships - they know that torps will be avoiding them (in 95%). Before they couldn't because they would kill civilian most likely :).

Cheers!

[OlegM]

OK I said some time ago I'd give short tutorial on how to change the data in USNI database to match the changes in mod (this mod or any other mod).

I think it's really simple and intuitive, but if you never edited it before may be confusing at first.

First find usnidata.grp and usnidata.ndx in DW graphics folder. Make backup, copy at safe place blah etc.

Graphics files in DW (and that includes usnidata) are stored in archives, much like Zip or RAR archives. All USNI data (text and photos, not 3D models though) is stored within usnidata.grp file. Unlike Zip and RAR archives, DW .GRP files have external index file, with extension .NDX.

Now take decmpress command line utility, available at many DW sites (Subguru Bill has it, if not ask me and I'll send it to you).

Use command line utility to decompress the usnidata file(s).

Syntax is: decompress usnidata.ndx.

Subdirectory with contents of unsidata.grp is created.

Enter the said directory, and you'll find bunch of photos and simple TXT files describing various stuff from the game. You can easily change any TXT file to match the data you modded! You can even add new items, change or add photos etc.

Of special interest are various xxx_TOC.txt files.

TOC stands for Table of contents, and these files contain "pointers" to sub cathegories. It's really simple, open them for yourself and see.

TOC files are important if you want to add new items to USNI database. Since LWA mod so far didn't add anything, merely changed the data for existing weapons and stuff, I guess for now TOC files need not be changed at all. If you add new weapons - you'll need to change TOC files too.

OK, when you're done editing - you need to re-pack the changed and added files back into usnidata.grp, and usnidata.ndx.

This can be done in two ways.

You will need compress, small command line utility similar to already mentioned decompress, both are freely available and distributable.

First, either you can repack and rebuild the usnidata.XXX pair of files yourself, and make them available to download, in full, to whoever wants it (it's around 12 MB).

Alternative to that is that you make small installer batch file, as many graphic modders already did. Again this is so simple even I, lacking any programming skills, can do it.

Batch file has to use freely distributable compress utility to re-pack the changed and added files.

If you decide to use batch installer, and separate files instead of making whole already packed usnidata.grp for download, the whole download will be MUCH smaller. Because it will contain only the files you changed or added (plus batch installer), not the whole 12 MB USNI database.

Hope all this was clear enough - if not, PM me or ask additional questions. I think mod as complex as this (and getting more complex by each day) really needs USNI support so that players can see various data and parameters for themselves from the game itself.

Oleg

[Amizaur]

Some feedbak for you guys.

pointed my binoculars on the Viraat battlegroup and noted the carrier's radar sweeping. but NOT on its mast!!! It was just FLYING CIRCLES around the ship :o :o !!!! To be sure switched Truth ON (maybe I've seen a helo, after all). Nope. Note this: 3D views is OK, problem occours only using binoculars and watching the Viraat.

I'm not kidding and I'm not drunk too...
:arrgh!:

Cheers

I know what you are talking about :). I know because this is the way I ALWAYS see P-3's propellers by binoculars - flying around the plane :D
I though it's some kind of 3D error, and though that it's on my comp only if no one else reports this :). AFAIK we didn't change sensor positions.
Take a look at P-3 in flight with binoculars, and tell me if the propellers are flying around the plane for you too, I'm curious :)

[Deathblow]

In the map that I tested it on the close surface was about 40km away. And the torps were helo-dropped Mk 46's.

I tested it about 3 times, but only on one particular map. The "Defend Vladivostok" mission (one of the downloadable scenarios on Bill's website. Haven't tried it out against any of the other maps.

That map is also strange in that the AI ships don't shoot ASM at you when you surface, so perhaps its just a glitch. Perhaps test it out on the same map (let the helos find you away from the fleet and then dropp on you. Go to surface and sit and see if the torps hit you.)

I'm not really complaining. Its kindof a nice effect, emergency blowing and splashing through the surface. Just thought "hm... if this is always repeatable, then its going to be sorta a cheat if they always stop at their minimum"

on a side note. man those subs are quiet now! Scary to be faces other sub that doesn't want to be found!

[Amizaur]

OK, will test this on the same map! If there were no surface targets close you should be blasted out of the water even on surface, so maybe you found a bug :) thanks !

P.S.It was a bug :oops: default ceiling was set by mistake to -100ft instead of -10ft.

[Tgio]

Take a look at P-3 in flight with binoculars, and tell me if the propellers are flying around the plane for you too, I curious :)

I've re-played the mission (South China sea, i think), same thing. Then I've done a test mission with a P3 flying arond me, and its prop were right. This is not a big broblem, I can live with it... In fact your P3's "swinging propellers" is worst :shifty: . My notebook is a (old :stare: ) Sony Vaio PCG-FR315B, with a ATI IGP 345M. Using ATI latest drivers (modded with DHmodTool). Maybe I will restore Omegadrivers next time.

Regarding your torpedo doctrine, for me is a 2 thumbs up

:up: :up: . I've learned to stay away from surface two days ago, when I've seen SSMs from a Knox pointing my conning tower :shifty:

Cheers

[Kapitan]

anyone cure this

i left harbour 5 days ago now was it 5 days ago ??? i cant remember some where around that time any way and as i was leaving port i have to pass through a shipping lane to get to the ice pack.

i do it submerged and not at very fast speeds about 11 knots or so anyways periodicaly i have to come to PD to use radar and esm masts to get a fix on ships in the area and how close they are i assend to 18 meters speed 4 knots and yet this time round my radar just wouldnt work the mast was fine just wouldnt show any contacts yet my periscope did pick ships up only 2 miles away and my radar was on a middle level setting

any cures guys ?

[Molon Labe]

Well, in the spirit of going after definite issues/bugs as opposed to things that need more testing to evaluate properly, let's talk AEGIS.

Performance has improved only slightly. I believe you made two modifications: First, improving the ability of the ships to detect and attack the missiles; and second, salvoing two missiles at high priority (fast and close) targets.

The second is working, the first is not. Engagement range is the familiar 10 miles (To compare, AI FFG's are engaging at closer to 15). The missiles are supersonic by this point, so there is usually only time for one salvo; the 2nd salvo can be fired but does not get down in time.

The AI SAM operators are also having trouble with their priorities. Having already decided to engage a flight of subsonic missiles at 10 miles, when those second stages fire, the operators continue their salvoes at the boosters instead of engaging the supersonic weapons first. Is there a doctrine fix for this?

All in all, Burkes and Ticos are still getting slaughtered instead of protecting the fleet. A better engagement doctrine would help a bit, so would an extended engagement range. If realistic detection range is only 10nm, would it be possible for the ship to fire using link data, and having the SM-2 use terminal active guidance instead of semi-active? If we can get E-2's linking missiles properly (In DW 1.01 they don't), then the E-2+AEGIS combination should be able to do the job right. :hmm:

[LuftWolf]

The issue of why AEGIS ships only fire under 10nm is mystery that we have been trying to solve.

Amizaur has looked at the issue closely in the recent past (and in fact created the new CIWS doctrine included in the distribution) and was unable to find the reason, the AEGIS ship are detecting the missiles at range I believe but even if they were specifically instructed to fire at longer ranges in the doctrine they didn't.

We are again looking at this issue.

[LuftWolf]

I have added increased CM effectiveness to the list above, as it stands now they will be returned to 50% effectiveness up from current 40% effectiveness.

[Deathblow]

I'ld like to say that I think the documentation provided with the mod was great! Seemed all inclusive to me and loved the red comments to note any considerations that should be taken into account. What more could be added? Seemed like everything was covered great to me.

As far is requested features for new versions: Randomized search depths for AI ASW torps, to put them below the layer sometimes :|\

[Deathblow]

Sonar profiles may be too quiet now. Was testing the new sound profiles and was completely unable to detect an Akula II 1500meters off my bow with a SW.

Akula was heading 220 @ 4kts. I was in a SW 1500 meters east of him heading 220 @ 4kts with TB-29 deployed. Had truth on to test things out. Could not pick the akula up on any sensors at all. Not the TA, Hull Array, or Spherical. Broadband or Narrowband :nope:

The velocity profiles may be too quiet now for gameplay. Can anyone confirm a similar test?

db

[Neutrino 123]

I think the velocity profiles are fine, but the starting sound levels are too low in my opinion. I couldn't detect a 1-knot non-improved Kilo in a test I just did at 2.5nm with the TB-23 (sea state 3, both platforms at 150ft).

By the way, if you right-click on a platform in the editor, there is a button that allows you to get the maximum sensor range for each sensor targeting another in-game platform. Unfortunately, this feature doesn't work. I ran a test with fishing boats, one a bit outside and one a bit inside the TB-23 circle, and both of them shows the 50Hz line. If I remember correctly, both showed at least a dotted 125Hz line too...

[Molon Labe]

I think the velocity profiles are fine, but the starting sound levels are too low in my opinion. I couldn't detect a 1-knot non-improved Kilo in a test I just did at 2.5nm with the TB-23 (sea state 3, both platforms at 150ft).

By the way, if you right-click on a platform in the editor, there is a button that allows you to get the maximum sensor range for each sensor targeting another in-game platform. Unfortunately, this feature doesn't work. I ran a test with fishing boats, one a bit outside and one a bit inside the TB-23 circle, and both of them shows the 50Hz line. If I remember correctly, both showed at least a dotted 125Hz line too...

You shouldn't be able to detect an SSK at very low speed without nearly running over it; it isn't generating any noise to detect.

In my experience, 688I's and Akulas are detecting each other at about 7-8 miles at low speeds. Akulas are detecting Seawolves at 5 miles at 35 knots. :nope: SW is definitely too quiet, both at low and high speed. 7-8 mile detection for SSNs seems reasonable though.

I bet those range circles represent "hard limits" of the sensors, which have been removed in this mod. Detection ranges are much more dependent on acoustics and contact speed than fixed parameters here...

[Neutrino 123]

Well, a Kilo Improved would have the same amount of noise at 7 knots and an Akula-i at four. Realistically, a stationary Kilo probably shouldn't be detected at that range, but due to limitations in the program, it generates the same amount of noise as a bit less then slow running.

I think used a bad example at first. The question is, should an Akula-i at four knots or a Kilo-i at seven be detectable at ultra-close range with TB-23? I would think so. I would also hazard a guess that with the current values, a stationary Seawolf and maybe a Kilo-i cannot be detected at any range with any passive sensor, making HF active more useful against it...

Exactly where is the noise to DW noise level conversion? Maybe it was posted before, but I must have missed it (sorry if this is so).

Edit: I did another test, and couldn't detect a Kilo-i moving seven knots at ~370 yards with the TB-23. Acousitc conditions were the same as above (subs at 150 feet, bottom limited, total depth a bit less then 300 feet).

[Molon Labe]

Well, a Kilo Improved would have the same amount of noise at 7 knots and an Akula-i at four. Realistically, a stationary Kilo probably shouldn't be detected at that range, but due to limitations in the program, it generates the same amount of noise as a bit less then slow running.

I think used a bad example at first. The question is, should an Akula-i at four knots or a Kilo-i at seven be detectable at ultra-close range with TB-23? I would think so. I would also hazard a guess that with the current values, a stationary Seawolf and maybe a Kilo-i cannot be detected at any range with any passive sensor, making HF active more useful against it...

Exactly where is the noise to DW noise level conversion? Maybe it was posted before, but I must have missed it (sorry if this is so).

Edit: I did another test, and couldn't detect a Kilo-i moving seven knots at ~370 yards with the TB-23. Acousitc conditions were the same as above (subs at 150 feet, bottom limited, total depth a bit less then 300 feet).

At 7 knots, I would think it should be detectable from a rather short distance, but in your first post you said 1 knot.

I'd try it in open water. Bottom limited environments, especially in shallow water, should make sonar performance very crappy. Although I think 370 yards with no detection is a little too crappy. It's weird though, I've detected Kilo-I's with the mod at similar speeds with a VLAD at 2nm.....time for some testing. :huh:

EDIT: Just tested it. Drove a 688I vs a 7-knot Kilo-I. Bottom limited, 300ft, rock bottom, sea state 3, both boats at 150ft.

I started them out 5 nm apart, I detected the Kilo imediately upon turning the TA to bear on target. 2 LINES! I ran off, the 2nd line dissapeared at 7.0nm, and the first line faded out at 11.4nm.

This Kilo plodding along at 7 knots is in crappy water is more detectable than a Seawolf at 35 knots in good conditions! I'd say tweaking is in order, but not in your direction!

[Deathblow]

Just tested it. Drove a 688I vs a 7-knot Kilo-I. Bottom limited, 300ft, rock bottom, sea state 3, both boats at 150ft.

I started them out 5 nm apart, I detected the Kilo imediately upon turning the TA to bear on target. 2 LINES! I ran off, the 2nd line dissapeared at 7.0nm, and the first line faded out at 11.4nm.

This Kilo plodding along at 7 knots is in crappy water is more detectable than a Seawolf at 35 knots in good conditions! I'd say tweaking is in order, but not in your direction!

Strange the inconsistent results we are all getting. Perhaps try a muddy bottom?

[Neutrino 123]

Whoops, my initial tests were flawed. I placed the Kilos relative to the ship, which meant they were out of the TA arc. I redid the test, and the Kilo-i at seven knots was easily detectable at 1.5nm. This didn't seem to be consistant with my results from the campaign I'm playing, so I did another test to be sure. A Pelmidia TA detected the second line of a 3-knot LA at 1.5nm.

Well, now I am not sure about the detection ranges, but do have one suggestion. As far as I know, the Kilo and Kilo-i are very similar, with the main differance being a new propellor and better quieting equipment for the Kilo-i. At low speeds, wouldn't these differences tend toward zero? Perhaps they should have much closer starting sound levels, but give the regular Kilo a much steeper sound-speed profile (rough example: change the Kilo to start at 56 and increase sound level by one for every knot).

I think I'll just learn the calculations for detection. Now where did Jamie post that formula? :ping:

[Molon Labe]

Whoops, my initial tests were flawed. I placed the Kilos relative to the ship, which meant they were out of the TA arc. I redid the test, and the Kilo-i at seven knots was easily detectable at 1.5nm. This didn't seem to be consistant with my results from the campaign I'm playing, so I did another test to be sure. A Pelmidia TA detected the second line of a 3-knot LA at 1.5nm.

Well, now I am not sure about the detection ranges, but do have one suggestion. As far as I know, the Kilo and Kilo-i are very similar, with the main differance being a new propellor and better quieting equipment for the Kilo-i. At low speeds, wouldn't these differences tend toward zero? Perhaps they should have much closer starting sound levels, but give the regular Kilo a much steeper sound-speed profile (rough example: change the Kilo to start at 56 and increase sound level by one for every knot).

I think I'll just learn the calculations for detection. Now where did Jamie post that formula? :ping:

That sounds reasonable to me.

So, Amizaur, if you're listening, how bout a real low starting NL for both Kilos, but the Kilo-I's curve is a bit flatter than the regular Kilo?

[Deathblow]

Just as a final 2cent on the sound levels..... there is a saying in my line of work... "The enemy of good is better....." In this context, maybe making these combatants too undetectable will ruin the gameplay. I've been playing thru the SC converted campaigns and have found that after doing the first three missions all were impossible to complete, only thru dumb luck could someone stumble into the detection ranges, to complete objectives, otherwise mission failed.

[Amizaur]

[Amizaur]

Maybe some different campaigns with different missions would be needed for realistic database ;) noise levels will change very little, but playable sub sensors were not touched yet and will be reviewed for next versions.
But if I were to make Akula sonars realistic... you would have detection ranges 1/3 of those for 688I :P

[Amizaur]

I think the velocity profiles are fine, but the starting sound levels are too low in my opinion. I couldn't detect a 1-knot non-improved Kilo in a test I just did at 2.5nm with the TB-23 (sea state 3, both platforms at 150ft).


Let me notice that base NL for both Kilo and Kilo Improved is exactly same like in standard DW, not changed (60 and 55). And the new noise profiles can make them only more noisy. But at 1kts they should be same like before. Sensors have not changed too, sooo... ? :)
Akula II is MUCH quieter than before, US subs too, but det ranges for both Kilos should not change, if ever then to higher because of higher speed added noise.

BTW what about changing one of playable Kilos to 677 Lada/Amur class, there is only one hull currently St. Petersburg ? The armament would have to be the same, but noise level better than for Seawolf, better sensors and faster torpedo reload times ? Question to other modders - would it be possible to give it a waterfall sonar interface without hacking anything ?
I understand that if I don't hack anything to make this, adding new version of playable Kilo is OK ? :)

P.S. Wow, I'm promoted to XO :|\

[Molon Labe]

Just as a final 2cent on the sound levels..... there is a saying in my line of work... "The enemy of good is better....." In this context, maybe making these combatants too undetectable will ruin the gameplay. I've been playing thru the SC converted campaigns and have found that after doing the first three missions all were impossible to complete, only thru dumb luck could someone stumble into the detection ranges, to complete objectives, otherwise mission failed.

Missions have to be designed around the detection ranges of the version of the game you're playing. If you play a mission not designed for your version, bad things like that will happen. That's not the modder's fault.

Edit: Which means I'll probably have to re-do and re-release all my missions...hoo boy... :roll:

[Neutrino 123]

I just did some investigations into sensor washout. Apparently, sensors can perform at full efficientcy at 75% of their 'max speed' as shown in the editor.

One thing to note is that the 688i TB-16 washes out at a slightly different speed then the Seawolf TB-16. The 688i TB-16 should probably be moved up to 25 with the Seawolf for efficientcy at 18 knots.

Right now, a few sensors have somewhat odd washout ranges. Most sensors washout at some multiple of three, but the TB-23 and both Pelmidia TAs do not. These have max speeds of 18 (TB-23), 14 (Pelmedia II), and 10 (Pelmedia) for efficient speeds of 13.5, 10.5, and 7.5. I suggest increasing the max speeds of each of these by two. This will give the TB-23 the same washout qualities as the TB-29. Another option would be to increase the Pelmedia speeds (letting them use their tactical sppeds), and decrese the TB-23 speed by two, to help counterbalance the increase in sensitivity for the TB-23 over the Pelmedia.

P.S. I've read the 688i has sensors three times as sensitive as the Akula's, but this wouldn't triple the detection range compared to the Akula since there are many other factors besides just sensitivity and noise (in the most very basic 2-D calculation, the noise decays as 1/r^2 giving a detection range of ~1.73 times).

Edit: P.P.S. I realized why my previous Akula tests didn't work too well. I was traveling at 8 knots, thinking it was an efficient speed for my TA, but the TA was suffereing from being .5 knots above the efficient speed.
I just did another test with the TB-23 under the same conditions as above. I could not detect a noise level 53 Seawolf (three knots) at 3nm, and lost the thin black 50Hz line of a noise level 55 Kilo-i (one knot) at slightly more then 3nm (edit: the Seawolf was lost at slightly more then 2nm). The noise levels could probably use some tweaking, but I am not sure how at the moment. I will think about it after I review the necessary equations.

[Deathblow]

Missions have to be designed around the detection ranges of the version of the game you're playing. If you play a mission not designed for your version, bad things like that will happen. That's not the modder's fault.

Edit: Which means I'll probably have to re-do and re-release all my missions...hoo boy... :roll:

You mean, make missions where the player just can't help but stumble onto a sub that been placed 2nm from its bow? Or do something to give the enemy AI subs away to the player?

[Molon Labe]

I think it's only the Seawolf that they made so ridiculously quiet. Ranges can be tweaked a bit using the SSP, sea state, and bottom type. I've observed a very strong bottom bounce or surface chop effect (not sure which) with this mod that I never saw in stock DW. The acoustic environment matters much more than it used to...and there are some environments where you shouldn't be able to hear anything unless you run it over. That may be appropriate for some missions, but not for others. The mission designer has to figure it out.:know:

In a surface duct, 688's and Akulas are detecting each other from 8-12 miles. That's very easy to work with, in fact, probably easier than the 15-20 mile detection ranges common in DW 1.01 hotfixed. Shorter detection ranges mean less time for the subs to crawl into range of each other (they will start closer, yet be moving the same speed), more room for sneaky tactical manuevering, less time waiting for torps in transit, and probably a more realistic experience. Provided that the NL's are tweaked a bit, I think missions made for this mod will be easier to make, more realistic, and more fun to play.
:cool:

[LuftWolf]

Ok, Amizaur wanted me to let everyone know that in the discussion of NL and Sound vs. Speed, we are limited in our ability to make anything other than linear increases due to the parameters of the way thrusts are coded in the DB.

The only option that we have to make a curve that is anything other than linear from 0-max speed is to make a small flat area at the beginning that goes up linearly from a certain value, however, this comes at the cost of having to increase the minimum speed (forward or backwards, absolute value) to something other than 0. This was used to make the SW, 688i, and Akula II thrusts, meaning that your minimum speeds are slightly increased. For SSN's, this is not a big issue since in RL they would almost never be bottomed or move at a speed slower than their planes would be able to keep them trimmed, which is about 3kts.

However, this is not an option for modelling the SSKs due to gameplay considerations, so at this time we don't have a way of making their sound increase from something other than 0 in a linear fashion.

So, unfortunately, the long and the short of this is that all sound vs speed curves have to linear, between min-max speed.

[Molon Labe]

LW, just wanted to say thanks for the games today.

For everyone else, seriously consider giving this mod a try. The shorter detection ranges and the deadliness of the weapons due to them not detonating on CMs makes for a very, tense, very exciting game. The art of stalking, seemingly lost since DW succeeded SCX, may be in for a comeback! :up:

Now if we could just get SCS to make some of these changes and fix the things the mod can't work around...

[LuftWolf]

LW, just wanted to say thanks for the games today.

Absolutely any time. Thanks for the opportunity for hands on testing! I'm sorry I had to go but I knew I'd have over an hour's worth of "administrative" stuff do to online! :-?

I have to say, based on our games, that DW is an *amazing* game if given the chance to shine with a reasonable database.

The whole discussion we had about me picking your SW on NB and feeling the need to ping right away only to find you in a sprint 9000m away instead of creeping up on me at 1500m was worth the price of admission (game price plus weeks of modding)! :rock: :arrgh!:

[LuftWolf]

Based on testing and feedback from you guys, we have decided to removed the torpedo feedback feature. Thank you very much to you all your your input on this. :up:

If you really liked the feature for Single Player, let me know, and I can tell you how to put it back in for your copy of the mod. :arrgh!:

Cheers,
David

Also, I would like to let everyone know that the next version of the mod will be released most likely in the next day or two. It will contain generally what we have talked about, however, the final list of changes will be finalized soon. A revised readme will definately be included in this distribution, as well as some very useful .bat files Amizaur has created that allow the mod to be installed and uninstalled with a single click for quick swaps, even while you are chatting in Hyperlobby. :up: :rock: :arrgh!:

[LuftWolf]

I'm fairly sure the next version of the mod will be released either today or tomorrow. :rock:

I'm going to post the readme as soon as Amizaur has had a chance to look at it. :sunny:

Cheers,
David

[Bill Nichols]

I'm fairly sure the next version of the mod will be released either today or tomorrow. :rock:

I'm going to post the readme as soon as Amizaur has had a chance to look at it. :sunny:

Cheers,
David

I'm ready!

[LuftWolf]

I have sent the v2.01 distribution to Bill! :rock: :up:

Here is the v2.01 version of the readme.




LuftWolf and Amizaur’s Weapons and Sensors Realism Mod v2.01
Hosted by www.subguru.com
Readme by LuftWolf
Edited by Amizaur

Amizaur has made a more substantial and significant contribution to the creation of this mod than me. Thank you to finiteless, Ludger, and jsteed for their contributions to modding DW. Thank you to Bill “Subguru” Nichols for hosting the work of so many talents modders and mission designers. Thank you to Molon Labe for extensive testing and multiplayer testing.

All doctrines by Amizaur.

The purpose of this mod is, straightforwardly, to address the aspects of DW game-play that most bother its authors, while improving the simulation experience and fixing bugs, without introducing any new ones. Thank you in advance for downloading this mod. Please send as much feedback as you can via the dedicated thread on the www.subsim.com mod forum, http://www.subsim.com/phpBB/viewtopic.php?t=41581&start=0.

INSTALLATION: Unzip the file into your Dangerous Waters directory. If you have a previous version of the mod installed, restore your ORIGINAL, stock DW v1.01 Doctrine and Database folders (or whichever version of the game database and doctrine set you would like to backup). Run the LwAmi_Backup_1.01_first.bat file, this will create backup folders for your original Doctrine and Database folders. Then, to install the mod, run the LwAmi_InstallMod.bat file. To uninstall the mod, run the LwAmi_UninstallMod.bat file. The install and uninstall .bat files allow you to quickly swap your game version from stock v1.01 to the LWAMI mod version so that you play in multiplayer easily with those who use the mod and those who don’t, as you must be using the same game version as your opponents. NOTE: Saved games created with one Database are not compatible with any other versions of the database, however, you can restore a previous version of the Database at any time to load saved games associated with that Database.

Note: This mod represents substantial changes to DW core game-play, and as such, will probably require fine-tuning in subsequent versions to particular values based on game-play experiences. However, such is the case precisely because, we feel, it represents a quantum leap towards bringing out the full potential of the massive and dynamic DW engine in terms of providing the feel of a quality simulation experience for both those new to the simulation genre and weathered deep blue warriors. Please send us AAR’s and comments in as great a quantity as you can! We would be especially encouraged to hear from players in the multiplayer community.

CAUTION: Missions designed for stock DW v1.01 maybe made unplayable by the greatly reduced detection ranges in this mod. We strongly encourage mission designers who enjoy the mod to support it by creating missions designed with these new realistic parameters specifically in mind. We plan on releasing a guide for mission designers along with the expanded charts and tables to assist you in this endeavor. Please let us know if there is *anything* we can do to help you design missions for our mod!

A Sound vs. Speed profile chart and new Ship, Sub, and Torpedo specification table will be released in support of this readme, to cover any specific changes to AI ships or weaponry (such as the complete listing of sonar parameter assignments) not covered in this document, however, I have taken to care to note the most important specific parameter changes to user platforms and weapons.


Specific changes for v2.01:

Active Sonars—All active sonars have been given the same fix as the DICASS and FFG active arrays, meaning that detections WILL NOT occur at max range automatically and are greatly effected by acoustic conditions, especially thermal layers. Also, additional active sonar models have been added to the game to simulate variable quality and assigned to appropriate platforms, including all playables, which now have variable active sonar quality.

VLAD Performance—The sensitivity of the VLAD has been reduced somewhat, meaning that subs slightly above “silent speed” will by marginally less detectable.

Torpedo.txt Doctrines—For the “torpedo.txt” doctrine included, Amizaur has changed the default ceiling set in the doctrine from -99.5 to -10.5, as the previous value was unintentional and allowed users to escape AI torpedoes by surfacing. The anti-casualty mod should function with the rest of the torpedo doctrine as intended now. Thank you to Deathblow for finding this. The other two torpedo doctrines included are BETA tests: Torpedo.beta1 converts the search depth set by the AI from meters to feet (the engine gives the number to the doctrine in meters but the doctrine treats all values as feet), meaning that the AI now sets properly deep search depths for submerged targets; Torpedo.beta2 enables random search depth for AI platforms meaning that sometimes the AI will fire torpedoes under thermal layers at submerged targets. Both of these doctrines are largely untested, so you can try them if you’d like (by removing the other torpedo.txt doctrine and changing the names of these files to simply “torpedo.txt”) and if you experience any crashes you can revert to the standard non-casualty version of the torpedo doctrine.

Torpedo Feedback—This feature has been removed from all torpedoes due to game play balance considerations, as it created problems with the auto TMA and torpedoes guided by an experienced operator were virtually assured kills within maximum range.

Launched CM Effectiveness—CM “weapon effectiveness” has been returned to the original value of 50%. The previous version of the mod used 40% and this was found to make CMs much less effective than desired. CMs should now be more effective in causing torpedoes to “hard-lock” onto them. It is not known at this point what the exact effect this change will have on torpedo “jamming” (causing the torpedo to lose its target but not necessarily home on the decoy) behavior under different conditions.

Sound Levels and Sound vs Speed Curves—Amizaur has worked on tweaking the sound levels for many platforms as well as the speed-noise curves. In general, these changes have been a mix of making platforms more realistically noisy or quiet at certain speeds based on the remodeling of real-world data, along with some changes made for game-play considerations, most notably making the Seawolf slightly more noisy (detectable) at all speeds.

Submarine Damage Levels and ASW Torpedo Warhead Modeling—The damage levels of some submarines known to be particularly tough (such as the Typhoon and Oscar) have been increased and the warheads of lightweight ASW torpedoes have been reduced. The combined effect of this is to make some submarines capable of sustaining a hit from an LWT, as we believe to be realistic, and makes LWTs much less effective against surface ships as is correct. Specifically, the Oscar will take multiple hits from LWTs and the Typhoon will take two ADCAPs to sink. Also, some torpedoes known to have very light warheads have been modeled as such, making it possible for most subs to sustain a hit from some of these torpedoes. In game-play terms for playable platforms and weapons, all playable submarines will still be killed immediately by all playable launched torpedoes (except for the SET-53ME which won’t kill any playable with one hit), however in cases of indirect hits with LWTs, a submarine may survive if the torpedo doesn’t impact directly.

Mk48 ADCAP—Amizaur has given the ADCAP active sensor the unique ping frequency 20050 Hz and increased it’s warhead to 400kg to simulate advanced fusing.

SS-N-14 Silex SUBROC—The torpedo payload of the Silex subroc (equipped on Russian Kara and Udaloy) has been updated to reflect the current version of the missile most likely in use with the Russian navy. It now has the UGMT-1, the same torpedo as the SS-N-16 Stallion, which is more effective than its original torpedo payload.

Missile Parameters—The weapon effectiveness of the RAM, Aster, and ESSM have been increased from 40% to 75% and the effectiveness of the SA-N-6,7, and 11 has been increased to 60%. Also, realistic minimum ranges have been added for all SAMs except for MANPADs.

Game-Play Changes

Sonar:

Passive Sonar—Amizaur has changed all passive sonars so that there is no longer an artificial “hard cap” on their ranges, meaning that there should be no sudden spikes when loud contacts come into detection ranges. Sonars are still limited by detection curves, however, the maximum range of each sensor has been set to at least 20% greater than the sensor could detect the loudest of contacts under most conditions, so for virtually all situations, acoustic factors should determine detection ranges rather than artificial database limitations.

Active Sonar—Amizaur has been able to reduce the detection range of all active sonars on submarines to something under max range, so now it is possible for the sub player to avoid detection within the range of the sonar by lowering speed and showing a low aspect to the active sonar array. This change represents a fundamental database correction for the “active sonar bug” currently in DW v1.01 and should help balance the game until the fix is hard-coded in the next official patch, especially aiding Kilo players in attacking surface targets undetected, as previously it was almost impossible to stalk a convoy. Also, additional active sonar models have been added to the game to simulate variable quality and assigned to appropriate platforms, including all playables, which now have variable active sonar quality.
Note: thermal layers are now effective protection against active detection. Comment by Amizaur: Well I will write that it’s only half-solution (in fact 10% solution) and it’s VERY far from perfect, but this is best I could achieve with current sonar model and at least in some cases and for some targets the range will be lower than maximal. But the active sonar bug still is in the game and it’s the most important DW bug currently. As jsteed said, there is somewhere x10 factor in the equation and minimal change in target SL result in great detection range difference. So we still have to wait for the SCS fix to have proper active sonar model, but with those changes Kilo drivers at least stand a chance against air units 

AI Sonar (Thank you to Periscope Depth for input on this aspect of the mod)— I have added sensors to all sonar-bearing platforms that reflect realistic sonars. I have done this in the following method. Divided the sonars into three catagories: Western, Modern Russian/Soviet-Nuclear, Eastern Diesel/Old Eastern Block. From the Western, I made three scaled versions each of the Sphere, Hull, and TA sonars from the 688i sensors, and assigned them to each platform in the game with Western sonars, according to level and whether they had a TA. I then did the same for the Modern Russian, borrowing from the Akula Sensors, assigning them to nuclear submarines with modern Eastern Sonar. The Kilo array model I used for diesels with eastern sonars and old submarines, which are mostly eastern. For surface platform sonars, I have used the FFG sonar as a model.

The primary difference between the Western and Eastern sonars are the washout speed. The best Russian arrays are more sensitive than the worst Western arrays (still good), but the Western arrays maintain a signal at a higher speed. The new Eastern sonars and the old Eastern sonars differ in terms of their maximum range, the Kilo sensors I used for the model are much shorter range than the Akula sensors.

A separate chart listing sonars, assignments, and detection parameters will most likely be released subsequent to the mod after further testing.

Object Sound and Sound vs. Speed Fix (for sound levels credit also to finiteless, jsteed, and Periscope Depth; research, final design, and implementation by Amizaur)—Amizaur has completely reworked the object sounds and the sound vs. speed behavior for realistic effects. Submarines and ships are realistically quiet across platforms and have been assigned varying speed-noise curves. New SSNs have different speed curves from old SSNs, and slower SSBN’s have their own speed-noise curves so they don’t increase their noise as much at max speed. Old diesels are quiet when stopped but very noisy when moving at speed, and the latest SSKs are very quiet. In addition, all surface platforms have been assigned more realistic speed-noise curves based on max speed, and American ships, especially the OHP FFG, are quieter than before relative to other platforms. Specifically, the OHP does not increase noise above stationary level until it is running above 10kts (this was in the game from the start, just nobody noticed it until seen in Ludger’s Analyzer). The Akula II, SeaWolf, and 688i have a somewhat flat curve from 0-4kts, meaning there sound levels do not change in those speed ranges. Please see the separate Sound vs. Speed Chart for specifics.

Playable Passive Sonar Parameters—All playable passive sonar arrays have changed to have a Maximum detection of height of 10m. Previously hull sonars and buoys had a Max of 0m and sphere and towed arrays had a max of 300m. This caused any object with a passive sound level to show up on sonar as if it were underwater, specifically sea-skimming missiles whose sound levels were changed in this mod to simulate underwater missile launch (Thank you TLAM Strike for finding this). I have not set the depths to 0m because this causes contacts to display inconsistently on the BB waterfall. I do not believe that cone sensitivity is effected in any way by this fix within the detection Max and Mins, but there could be other issues I am not aware of. This may be refined later, but it is necessary now to address persistent sea-skimming missile transients.

Torpedos:

Amizaur has been able to make significant improvements to torpedo function.

TorpHoming Doctrine—This doctrine completely disables torpedo explosions on countermeasures. The torpedo, after acquiring a dropped decoy, will pass through the decoy and re-enable on the other side. Sometimes the torpedo will demonstrate odd behavior immediately after being spoofed, as could be realistic, but should always return to seeking properly if within its max range. Note: some of the TEST-71s on the Kilos use the wake-homing doctrine, so their behavior is unaffected by this mod.

Torpedo Doctrine—The updated version of this doctrine: reduces the search arc of the snake pattern for torpedoes from +/- 45 to 30 degrees; randomizes the circle or first snake turn direction, and, most importantly, prevents AI torpedoes launched against submerged targets from striking surface ships 90% of the time, by lowering the minimum depth of AI launched torpedoes.

Torpedo Seekers—Amizaur has modeled a wide range of active and passive seekers, with individual seekers for the most important torpedoes, including distinctive ping frequencies for classification over active intercept, as is realistic. The ADCAP active seeker is max range 3000m and its passive seeker is max range 1000m, will all other torpedoes scaled down from there, meaning there has been a significant reduction in the effectiveness of all torpedo weapons to reflect realistic parameters. Note: the parameters of all of the torpedo seekers have been tweaked so that thermal layers have a much greater effect on torpedo performance. Also, the width of seekers cones of the ADCAP and USGT have been increased to minimize the effect of the reduced snake search pattern on the effectiveness of these weapons. Some small warship active sonar levels have been increased to make the new seekers effective against them and very small civilian ships are nearly invisible to active torpedoes now, due to seeker changes.

Wake-Homing Torpedoes—Amizaur has reduced the visual sensor of the wake-homers, used in the terminal homing of the weapon, to 50m. The practical effect of this is that wake-homing torpedoes now act like true wake-homers, meaning they will no longer home in on the front of ships and must be fired behind the target to insure the torpedo makes contact with the target’s wake. Now, if the wake-homing torpedoes do not make contact with where the target’s wake actually is (behind the ship and slightly to the sides), you must have a near perfect shot to hit a target, so they weapons are practically not effective if fired in front of a ship’s path. In addition, surface ships now have an opportunity to lose acquired wake-homing weapons with hard maneuvers at the last moment, if they are able to turn inside the torpedo so it loses the wake and cannot acquire with the visual sensor. Also, all strictly wake-homing torpedoes have altered to be fired only against identified surface targets.

Fast Torpedo Speed Oscillation Fix—Due to a hard-coded error in the DW v1.01 engine, all torpedoes from speeds 56-159 display a wide speed oscillation and or increased speed. We cannot change this directly, however, the speeds of all torpedoes over 55kts have been reduced to 55kts and compensated with more realistic parameters.
ADCAP—Speed raised in v1.03 of our mod to 60kts. Lowered again to 55kts and given the best seeker in the mod as well as torpedo sensor feedback. Also the warhead has been increased from 350kg to 400kg to simulate advanced fusing and max depth increased to 1000m
Spearfish—Range increased by 10,000m to 32km.
Type 89—Reduced turn radius to 100 (as all other torpedoes) as previously high turn radius is now unnecessary with lower speed. Increased range by 15,000m to 45km and given it ASuW capability.
Type 40—Increased range of SS-N-27 ASW family of subroc missiles to 27nm, as is realistic.
APR-2E—range increased from 3.2km to 5km.

ASW Torpedo Warheads—The warheads of strictly ASW torpedoes have been reduced to realistic levels. Combined with the reworked damage modeling, it will now take two lightweight torpedoes to sink some tougher submarines, such as the Typhoon. Also, some torpedoes known to have very light warheads have been modeled as such, making it possible for most subs to sustain a hit from some of these torpedoes.

Damage Modeling:

All values for neutral and supply ships have been adjusted to make them more realistic in terms of the damage they will sustain. Light civilian ships are made more fragile and heavier ships are made realistically difficult to sink. Heavy military supply ships are made slightly more sturdy than the OH Perry Class FFG. Medium supply ships and oil tankers are slightly less rugged than the OHP, medium civilian ships have been made slightly tougher. Expect to have to use several medium and light torpedoes or missiles against heavy shipping now, with more necessity to be careful in wasting weapons when facing a convoy. We have also decided to rework the damage modeling for most warships as well, with heavier ships of better build being modeled with appropriate levels of survivability. Expect some ships to be a little more difficult to sink and some ships to be a little easier in a sensible and predictable way. Further, some submarines known for being particularly rugged, such as the Typhoon, have been given higher damage ratings so that they may now sustain single hits from lightweight torpedoes, as we believe to be realistic. Specifically, the Oscar will take multiple hits from LWTs and the Typhoon will take two ADCAPs to sink. Please refer to the unit information tables to be released following the release of the mod for details.

Masts and Cables:

Periscope Depth’s Cable Length Mod—Thank you to Periscope Depth for providing this. The length of user-platform cables have been changed to real-world lengths: SQR-19/TB-29/23—5000ft, MH-60 Dipping Sonar—2500ft, and Pelamida TA—2300/701m.

Universal Doctrine Fixes:


SubAvoidxx-- Doctrines correct a bug in sub evasion routines that tells them to come too shallow while evading, causing cavitation. Well tested.

Missle/MissleSam-- Corrects minor bugs in missile launch angles. Well tested.

SubrocAttack-- Improves accuracy of Subroc torpedo drop points.

CIWSAttack.txt-- Directs ships to fire a barrage of missiles at "hard" targets, very close or very fast. This represents an improvement in the behavior of AEGIS and other ships’ anti-missile behavior, as previously they fired many fewer missiles at potentially lethal threats than they were capable of firing.





Missile Parameters:

Passive Signature for Underwater Missile Launch--All sub-launched missiles now produce a very noisy transient when launched. The exception to this is the Harpoon, which is much quieter, simulating its launch from a canister which opens up once it gets to the surface, making it a better option verse the TASM than previously.***Underwater missile launches will not give a TIW or any other audio warning.*** Thank you Bellman for raising this issue and Fish for confirming it over a LAN. Also, Amizaur has include a doctrine addition to the general submarine avoidance doctrine that allows subs to recognize underwater missile launches and evade under parameters in which it could be a subroc attack, giving AI subs a better chance of clearing the target datum and surviving subroc attack.


IR Signatures-
IR signatures added for all missiles based on type, with a reasonable scaling from
Sea-skimming cruise-missiles to supersonic, rocket powered anti-ship missiles. This now makes RAMs effective against anti-ship missiles.

Amizaur's MANPAD Seeker Fix-
We have included the fix that has been around for sometime, reducing the seeker cone
of MANPADs to 3 degrees.

Radar Heights Changed—Some radar heights have been lowered, as previously some ships had been able to see too far over the horizon. Also, the minimum altitude
of the AEGIS SPY-1 Radar has been lowered from 5000ft to 10ft, which should
help them better track sea-skimming vampires.

Launched Anti-Missile CM's—effectiveness raised from 20% to 25%.(Thank you Mau for
suggesting this.)

Missile Effectiveness and Minimum Ranges—The weapon effectiveness of the RAM, Aster, and ESSM have been increased from 40% to 75% and the effectiveness of the SA-N-6,7, and 11 has been increased to 60%. Also, realistic minimum ranges have been added for all SAMs except for MANPADs. This will prevent unrealistic last minute shots against incoming missiles.


MAD/SAD:

MAD—sensors have had max detection depth reduced from -3000ft to a realistic -1000.ft

SAD—sensors have had max detection depth reduced from -3000ft to a realistic -750ft. Note:
the only difference between a MAD and SAD detection in the game is the depth at which
they are detected, so if I set the depths the same, the sensors would be exactly the
same sensor,as the platforms only vary in MAD characteristic, and have no separate SAD
characteristic).

AI MAD—AI platforms do not have a separate MAD/SAD detector. Previously, they had been setto detect from 0 to -3000ft. In order to permit realistic evasion tactics from MAD
equipped AI air platforms, I have set the AI MAD sensor to have SAD characteristics
(have fun under those funky sounding cargo ships!)

User Platform, Weapon, and Sensor Specific Changes

User Torpedo Specification Changes: (Thank you to Bellman for raising the issue of torpedo balancing)

53cm Torpedo—given UGST specifications: Active/Passive Multipurpose Wireguided Torpedo, 50km@50kph, with maximum depth 800m (less on fire-control preset panel) with 300kg warhead.

Mk48 ADCAP—The maximum depth of the ADCAP has been increased to 1000m and the warhead has been increased to from 350kg to 400kg to simulate advanced fusing.

65cm Torpedo—guidance sensor and doctrine changed to simulate 65-76 Wakehoming Hydrogen Peroxide-powered Torpedo (the type supposedly removed after the Kursk Incident). All specifications have been left the same except guidance-following the wakehome doctrine now-and the wire has been removed. The wire-guidance option has been disable in-game, but I can't change the fire-control graphics, so you'll just have to remember that the A/P and search pattern buttons do nothing, and that the torpedo will continue in a straight line after it enables. LAUNCH THE TORPEDO WITH THE DEPTH SET AT ~10m, depending on how lucky you feel that day. The Nixie should not affect this weapon in any way, but over-the-side decoys will cause enough of a disturbance in the water to disrupt the wake-homing, but the torpedo will not detonate on the CM's, and usually reacquire. Also, due to changes in the wake-homing sensors, you MUST fire this weapon behind a ship so that it will make contact with its wake in order for it to home onto the target; it is no longer sufficient to place the torpedo within 500m of the target from all aspects.

Mk46—Given Mk54 hypothetical specs, 17km@50kts with max depth 500m and a light weight, for airdrop use in littoral waters (the turn radius may be decreased in subsequent versions to further increase this effect). All non-American platforms are armed with the standard Mk 46 torpedo they had previously, and all American platforms have upgraded to Mk 54. The Mk 46 ASROC has been left the same for all platforms and will still drop the Mk46. I thought it wasn't good to have a useless Mk46, so I did some research and came up with a torpedo that is marginally better than the Mk50 all round, but doesn't replace it, reflecting a torpedo with the upgraded propulsion of a Mk46 with the seeker of the Mk50, which constitutes the actual Mk 54 as indicated by my information. As the Navy's intention is to have a lower cost option to the Mk50, the propulsion system of which is very expensive. For me personally, I will be taking more Mk 54's now, unless I need to kill something deep! Note: When playing as the FFG, you cannot order your AI controlled MH-60 to drop the Mk54 on a waypoint, only from the command on the Nav map. This is due to an interface issue hard-coded in the game, however, you can work around this by creating a manual solution where you want the torpedo dropped and order the torpedo dropped on that solution rather than the actual contact.

53-65 Wake-homing Torpedo Family—The minimum running depth of the torpedo has been set to -14m in order to ensure proper launch depth against surface targets. You can still launch the torpedo from as deeply as before.

Shikval Mad Sensor—The MAD detonator on the Shikval has had its range reduced by half to 250m, as previously any shot within 500m of the target resulted in a kill, this makes it possible to evade one of these weapons if it is off target and proper maneuvering is used quickly.

SLMM and Mobile Mine—Includes Doctrine Files, Mod by Amizaur
A fix that makes them stop making noise after they have stopped moving has been
applied to both weapons. In addition, they will now actively try to stop once
they have reached their assigned location and will be reliably on target and hold
their position, making them an effective weapon, which they were not before. Their
maximum usable depth remains the same (300ft for SLMM and 450ft for Mobile mines,
the range of their seekers), but the weapon will shutdown below 600ft. These weapons
are for use in shallow water and will "malfunction" in deep water. ;-) Also, do not
try to use these weapons against a steep slope.

Seawolf Max Speed—The max speed of the Seawolf class has been reduced to 38kts, as is more plausible. The Seawolf is still easily the quietest, fastest, and most heavily armed submarine in the world. ;-)

688(i) Towed Arrays- Added TB-23 as starboard array. The reason I have kept it
on the starboard, against what is commonly reported, is because in missions
where ownship starts with TA deployed, it is always the starboard array, and I
figured in most situations I would want that one deployed. The port TB-16
washes out at ~20kts and the TB-23 washes out at around ~16kts (you folks
can tell me if that feels right once you play around with it...
or if I'm just completely off...). I have set the sensitivity of the TB-23
to be pretty much in the middle of the TB-16 and the TB-29. I was even able to
change the names in game, so have fun captains!

Akula II Modified Gepard TA—The array of the Gepard has been upgraded to hypothetical Pelamida II standards, with a Max speed of +4kts over the original Pelamida, and the in game name has been changed to “Pelamida II”. The sensitivity has been left as it is. This array has also been assigned to the Oscar SSGN, to reflect the latest developments in the most funded Russian submarine projects.

VLAD Passive Sonar Performance—The sensitivity of the VLAD has been reduced somewhat, meaning that subs slightly above “silent speed” will by marginally less detectable.

Midget Sub—The Midget sub has been given a periscope sensor, as previously it had no sensors at all, and its active sonar parameters have been changed to make it more detectable as is realistic.

Russian SVTT-Ship Launched Torpedos—Changed to USET-80, to better reflect Russian
capabilites. Note, only Russian SVTT launchers previously
equipped with 53cm torpedos have been changed, some launchers are equipped
with other torpedos. Also, the Grisha FFL retains the 53cm Torpedo w/UGST
specifications, as the USNR in-game database says its launchers have
been modified to fire wire-guided torpedos, so I thought it might be interesting.

Russian Airdropped Torpedoes—Platforms that had previously been firing the 53cm will use the APR-2E, the torpedo which comes equipped as the default weapon the Helix ASW Helo.

SLAM-ER Fix—I have removed the missile's IR seeker, which apparently was interfering with its terminal homing. The missile now looks in the DB and behaves in the game
like a light TLAM, and, *functions correctly*, exploding on target with
the same accuracy of a TLAM. Note, this weapon is not the most effective strike
missile, as it has less than half of the warhead of the TLAM, meaning you need
more than one missile to destroy medium and heavy targets if the missile does
not land directly on target. Even small, light targets may escape the blast of
this missile if it overshoots. For some reason, IF YOU DO NOT CHANGE THE
WAYPOINTS, THIS MISSLE WILL NOT WORK!!! I can't change this, and I'm not sure why.

SS-N-27 Two Stage Mod—Mod by Amizaur, doctrine file included—The first stage of the missile launches the second one and falls to the water or sometimes rises into the air as a decoy, to simulate the reported real-world function of the missile. This version of the mod uses a streamlined doctrine format that needs only one doctrine file. The enable point of the first stage, which is a cruise missile at 500kts with a max range of 200km/108nm, enables its seeker as usual, however, when the seeker has acquired a target, the missile will fire the second stage, which is the supersonic attack phase equipped with the final seeker and warhead with speed 2.5 mach and range 24km/13nm. This version of the mod requires less finesse in entering the proper range, as the missile will tend to detect targets around the max range of the second stage, but it is good to enable the missile somewhere around the max range of the second stage (11-12nm before the target) to minimize the chance of an early fire and take full advantage of the coordination of the second stage supersonic sea-skimming attack phase and first stage post-launch decoy (to cover most of the air defense zone by supersonic stage, not by vulnerable subsonic stage).



That's it! We hope you enjoy! Please let us know if you find any errors, would like to
contribute to a future release, or have any suggestions or comments. The place is http://www.subsim.com/phpBB/viewtopic.php?t=41581&start=0.

Happy Hunting.

LW



We hope you enjoy! ;) :arrgh!:

Cheers,
David

[PeriscopeDepth]

Thanks guys!

[Bill Nichols]

Download Version 2.01 now from my site. :D

[LuftWolf]

:sunny: :sunny: :sunny:

Thanks Bill! :up: :rock: :arrgh!:

Cheers,
David

[zma]

About the .bat files in v2.01...

LwAmi_UninstallMod.bat copies the unmodified files from the backup folders. However, since the mod contains more doctrine files than the standard version, the "surplus" files (especially MissileSkim54E_stg1- and -2.txt) are not overwritten and remain in the Doctrine folder after the uninstall .bat file has been run. Correct me if I'm wrong, but wouldn't this mess up the standard doctrines a little?

Perhaps the Doctrine folder should be emptied before new files are copied there?

Awesome work with the mod, by the way! :rock:

[Fish]

As far as I understand you have to re-install DW.

[LuftWolf]

No, if you have saved your stock and database folders from the previous version, you can copy them back over in your DW folder.

This will return DW to a neutral, stock state.

Then you run FIRST the backup .bat. This will create new folders for your stock files in addition to the normal ones used by the game.

At this point, you use the "install" .bat to instate the mod, and "uninstall" .bat to return to stock.

Extra doctrine files in the doctrine folder do not, in any way, effect game function. If you would like to use an alternate torpedo doctrine full-time, then change the name of that doctrine to "Torpedo" in the database.LwAmi folder and discard the other torpedo doctrine. Then, when you use the .bat file, that new doctrine will be instated in the doctrine folder in place of the original.

For most users, you will only need to: unzip package into DW directory; make sure you have 1.01 restored first; run the backup .bat; run the "install" .bat to switch to the mod; when you wish to play stock DW, then use the "uninstall" .bat to restore your original version.

I hope this clears things up.

If you did not save your doctrine and database folders from a previous install of the mod, then you will have to reinstall DW (or get a friend to email the Doctrine and Database folders to you).

[compressioncut]

Hey, uh, I'm sure this is the first tiome this has been mentioned but it's something that's really come to light with the mod.

Now that the SQR-19 has a correct 5,000 feet of tow cable, the [over]buoyancy of the array is really starting to show up. It takes a very long time to react to changes in cable length and tow speed, with respect to its depth. That can be a fairly critical problem, as placing the array where you want it is priority, and capability, #1 with the critical angle TACTAS.

I don't know if it's a hardcoded problem or what. But something to be aware of, as array depth is very important to a skimmer puke.

If the tow speed vs. cable length vs. depth curves aren't classified, I'll see what I can come up with.

Something weird, however - I've only seen it once, but I noticed that when I began paying out the cable, and accelerated time, that once I went back to 1:1 time after the cable fully payed out, that the array was still sinking at the accelerated rate. Not a mulitplayer concern but strange nonetheless.

[LuftWolf]

It says in the DW manual that depth is NOT modelled for the TAs! :cry:

So the 3-d view may show you one thing, but it doesn't at all effect the performance of the array, as far as we know. This is hardcoded (not enabled in the acoustic engine) and I don't think we can change this unless SCS does a major reworking of the TA acoustic modelling. :-?

[compressioncut]

It says in the DW manual that depth is NOT modelled for the TAs! :cry:

So the 3-d view may show you one thing, but it doesn't at all effect the performance of the array, as far as we know. This is hardcoded (not enabled in the acoustic engine) and I don't think we can change this unless SCS does a major reworking of the TA acoustic modelling. :-?

I think you may be interpretting the manual entry incorrectly - it reads thus:

"Note: Be aware that ownship always appears as a contact on the FFG's towed array. In SCS - Dangerous Waters TACTASS provides 360* detection even if the array is not fully deployed. The array is always modelled as level even when it appears to droop in the 3d view" [p. 7-36]

I added the bold. What I interpret that to mean is that the array is modelled at the same depth all along its length, no matter what it appears to be in the 3d view. The depth of the array definitely appears to be taken into account in the acoustic model, and that is borne out in the fact that ownship signature can move down the array the deeper you place it. Also, I have a couple of simple CZ detection missions where array depth will affect POD.

[LuftWolf]

Oh, thanks a lot for that clarification!

That makes a world of difference!

Thank you again, I'll be much better skimmer captain now! :D

[Bellman]

:D Well we were asked to give some feedback on the mod and I have been looking at the interaction between torps v CMs.

Time has only permitted SP testing of SW Mk 48 launches against AI subs and self targetting.

I have noted elsewhere the pathetic AI subs in 'Quick Missions' and their inadequate performance cannot be laid at LWAMIs door.

With a SP of 1200 ft I attacked 3 Akulas (8, 10 & 12 nm)each with an active and a passive launched on snapshot bearings,
and allowed to run guidance free but enabled at about 4-5 nm from targets.

This scenario was run 3 times. Each time 2 Aks were despatched and not one single counterfire occured.
The effect of the CMs was a very limited. Twice only passive torps locked on to a passive cm burnt
through maintaining course free of lock for about 500 yds before re-starting a search.
Active torps acquired an active cm on one occasion and on another seemd to lock earlier on a duo of active and passives cms.

On no occasion did I witness torp confusion/dazing/blindness - it was always a lock or nothing.

AI sub manouvering, or I should say lack of it, was very poor but in the test this threw protection
on the cms and they failed nearly 70% of the time.

Self targetting proved in general that it is still own manouveres which save the bacon until the torp is
under 5 nm which is a completely different ball game now. CMs dropped outside that range (Appx) were
marginaly effective in creating a diversionary lock occasionaly. Not necessary to survival at all.

Under 5 nm IMO the CMs are useless and the targetted sub is going shrimping in the majority of cases
given the poor (realistic) sub rates of turn.

So I regret that I'm puzzled - what usefull function do cms perform in sub v sub in the mod ?

My impression is that the cm doctrine setting of 40% efficiency does not appear to be confirmed in-game
If I had'nt been told this I would have gauged it at 25-30 % max. (on a good day) :hmm:

[Molon Labe]

The CMs in this mod are still effective, but need to be combined with skillful tracking and manuever in order to evade the torpedo. I think last week I was able to get away from a UGST that had locked onto me...it can be done but it's not going to be ridiculously easy like in DW 1.01.

The AI just doesn't have the chops.

[Bellman]

ML:The CMs in this mod are still effective

Can you be more explicit - what do you mean ''still effective''

In what way ? Did you see anything other than a small % occurence of locking-on - was there any spoofing ?

Skillful tracking and manouvre yes that is, I hope a constant :lol: ........particularly in your case. ;)
But what have you observed about the contribution of CMs ?

[Bellman]

:sunny: I will look at UGSTs tomorrow - just in case, someone, somewhere has been tipping the playing
field, or should I say ''Balancing -out'' ;) :o :huh: :roll:

[Molon Labe]

I've seen torps lock onto CMs, and torps lose the lock on the target when passing close by the CM. The interaction betwen torps and CM's is very similar to how it was in Sub Command, except I don't think torps in SC would ever lock onto a decoy first.

[Bellman]

ML: torps lose the lock on the target when passing close by the CM

Thats what I have'nt seen yet (in SP) but I will get my microscope out and have another look.

Passives seem more positive in locking on to passive cms but the only time I have seen torp ''confusion''
is with an active when there was a choice between cm and sub and it quickly made up its mind. - sub every time.

[Tgio]

I've seen a collision between a Tico and an Arleight Burke escorting the carrier in the last campaign mission :damn: :damn: . Is possible to make they avoid each other using the doctrine language?

[Amizaur]

I would say that it's possible.... but this would require HUGE doctrine that would track position and courses of all ships in proximity and checked all the time if there is collision danger and then ordered emergency maneuvers... which could lead to another collision ect. :/. Any idea for simple algoritm that would check if there is collision danger ?
Or maybe just implementing collision checking in part of doctrine that orders evasive anti sub/torpedo maneuvers would help... but this would not prevent all collisions... and I'm not sure how the targets should be tracked - in ship doctrine itself by variables or maybe designate friendly ships as targets to get target doctrine for each, just not order shooting that collision preventing... but this would mean LOT of simultaneous doctrines running and maybe generating contradictory orders and game crash... well it's hard task, I even don't think of that until there are no simple things to fix and improve left ;)

P.S. hmm maybe there is a way to send a signal from one doctrine to others, so when ONE ship begins evasive maneuver then ALL ships in convoy will start THE SAME maneuver at once so collision risk would be minimised...? Would look quite cool ;) but I don't know if it's possible, my knowledge of doctrine language is too weak, EntVar commands probably work only between platform and target doctrine, not between two platform doctrines...?
Maybe at least optimisation of evasive maneuvers, one would have to think what orders would minimise collision risk... but in convoys that would probably not help much... :hmm:
No, thanks, I'll take other bug :-j

edit: :hmm: :hmm: :hmm: tracking all near targets all the time would be difficult and time-consuming, but what if we added for each ship separate, specialised anti-collision sensor of very short range (visual would be best I think) maybe even with cones looking at specific angles, and order emergency maneuver if something was detected by this specific sensor ? :hmm: not sure if it would work, all targets would be detected long before by other sensors so they wouldn't be called as new tracks ? but for torpedo proximity fuse it works so should work for a ship "proximity fuse" :) have to thing on this.
But still I prefer other bugs ;)

[LuftWolf]

Bellman, in a multistation dive recently, with darksythe and MaHuJha (full AAR to be posted soon if not already) we came out of sprint less than 5nm from an Akula II that had bottomed itself and was waiting in ambush, already having fired a torpedo at us.

It fired on us while we were running blind at 20kts and when we came out of the sprint, the torpedo was already tracking us 45 degrees of the bow at 2.5nm. We immediately turned hard left and headed due north and dropped two active decoys and snapshot down the torpedo bearing.

When we counterfired, the Akula II put anothre torpedo in the water, very accurately. The first torpedo's lock was actually broke by our torpedo counter shot, that gave us enough time to get behind our decoy screen, and the first torpedo acquired the double decoys and ran past us. The second torpedo had us dead on so we cut back to the south west and dropped another decoy, this one just confused the torpedo enough that it ran directly between us and the decoy, missing our sub by less and 100m (probably closer to 50m) and ran right by.

The bottomed Akula II couldn't get going in time and we gave her the old rapid decompression death. :rock: :arrgh!:

So decoys are effective under 5nm, you just have to be on your game, as Molon said. ;)

[darksythe]

This is very much true i had us running at 20 knots to close distance and encourage a shot by what we thought was going to be a delta class.

We came out of sprint after around 5-7 minutes to get the TIW call . We were heading 090 I ordered us to drop the actives and cut back to 000' runing at flank. Once we saw that the first fish had taken the bait we dropped out of flank started turning to the south to reacquire the target (didnt have time to snap on the first fish :nope: )

As soon as we came out of warp :lol: he once again fired on us i ordered a snapshot down the bearing to shot (Believe it was 110' now) ordered to drop the actives and go left full at flank ( i think our navigator ran us in a complete circle :hmm: ) but it worked out because the fish got confused by our snapshot and started to run at it for a while.

Then I think it probably acquired both us and the countermeasures(we were still close to the decoys) and split the difference between us as we turned into its baffles...

Stay tuned for the full AAR.
Also expect a full AAR from our dive early in the night with same crew on board a Akula II!!

[LuftWolf]

Yeah, I accidently left the rudder at hard left while I went back to firecontrol to snapshot... :oops: I thought we did fire on the first torpedo?... I was WAY too busy flipping switches, entering values, and repeating back order calls to have a clear memory of the events. It's a good thing the Captain had a clear head and remembers. :yep: ;) :D

Thanks Mike, for the fantastic dives as well! :rock: :arrgh!:

Cheers,
David

[darksythe]

Hehe clear head..... right??? Um thats my job isnt it. Lol j/k i think we all did a excellent job especially considering the time we started the mission and the time we ended. gulp... 0300-0830 est.

[LuftWolf]

Not to mention 11:00pm-2:30am for the sinking of the Nimitz. ;) :rock:

[darksythe]

Shhh... thats supposed to be a secret untill you do the AAr lol j/k stay tuned for that AAr to folks its just as good maybe even better. :|\

[Bellman]

:lol: Ok guys - looks as if you have me triangulated. :o :yep:

There is no substitute for MP experience and I am aware of the severe limitations on my SP testing without a dual PC setup. :P

I sha'nt waste any more time 'tilting at windmills' - probably displacement activity from head banging 'triggers' ;)

I will sort out my router for MP access one day. :damn:

[darksythe]

Hope you get it sorted out soon wed love to see you in game with us. If you need any help im willing to give it a try. I hve some networking experience especillay with stubborn routers ;)

[Bellman]

Thanks that would be great :rock:

I nearly got into a game with Luftwolf testing the mod last week.
HL was fine but multi players was'nt on (my end) so LW and I atttempted a 1 v 1 start.
No luck - he could see me 'ready' at launch point (I think) but that was it. We didnt persist as others were waiting patiently to join.

[Bellman]

:sunny: Dont suppose you are available for HL now ?

[LuftWolf]

Bellman, since you were able to connect to my lobby, but not to the lobby of the game with multiple people, your configuration may be rejecting connections to multiple computers. However, that night, things were rather confused in terms of what was working and what wasn't working with everyones' systems, so it may not have even been you.

Let us know when you are available to play, darksythe's system is very friendly for multiplaying, so I think trying to connect to his lobby would be a good test of your system.

I apologize for that night, things were rather confusing all around, I think.

[darksythe]

I wish i was available to play right now but im at work :down: :hulk: tomorrow i will be on HL advertising games all day though (I host str8 ip i dont like HL myself) so i hope to see you there!

[Bellman]

:) That is encouraging LW.

NP the other night I was keen not to log-jam the game start for others.

I can fit in with you guys anytime. I am GMT + 1.

Would appreciate any help to get under way as SP isnt doing it for me.

[Bellman]

:up: OK fine Darksythe I will look out for you. :cool:

[OKO]

I've seen a collision between a Tico and an Arleight Burke escorting the carrier in the last campaign mission :damn: :damn: . Is possible to make they avoid each other using the doctrine language?

I would say that it's possible.... but this would require HUGE doctrine that would track position and courses of all ships in proximity and checked all the time if there is collision danger and then ordered emergency maneuvers... which could lead to another collision ect. :/. Any idea for simple algoritm that would check if there is collision danger ?....

Amizaur, there is a script instruction =>
collision avoidance.
It works quite fine
On each mission I make, I always use an initialization trigger calling a script where I used collision avoidance and pathfinding for all plateform susceptible of needing this (sometimes on more than 20 plateforms !).
I could say it works 95% of the time.

On one recent MP mission, a WASP was on a collision road with a freigther, I was in the OHP and my human helo (Darksythe maybe ? I couldn't remember exactly who he was, sorry ...) told me : "there is going be a collision problem !"
I told him : it is supposed to be managed with the script (and I crossed fingers)
And the Helo said : you right, I can see the WASP manoeuvering well to avoid the collision.
So it REALLY looks like it works quite well.

I saw more collision problem inside a formation than with independant ship vs indepedant ship I must admit.
Sometimes, when a formation is engaged, some ships could collide with ships of their group.
But it's really not that often if you use collision avoidance script.

[darksythe]

I was in the mission but i was the sub. ;)

[OKO]

The depth of the array definitely appears to be taken into account in the acoustic model, and that is borne out in the fact that ownship signature can move down the array the deeper you place it. Also, I have a couple of simple CZ detection missions where array depth will affect POD.

Yes, that's a fact, and that's why, for example, a nuke sub need to go above 7 knts to make a TMA merged on TA and SA.
If the sub go slower when recording LOBs, the depth difference beetween TA (falling deep) and SA (above the level of TA) will conduct to a quite difficult and inaccurate TMA.
If you go 7 knts and over, your TMA could be VERY accurate, but under 7knts, TMA will be corrupted and sometimes totally innacurate.
Same if you stay just above a layer => if you let your TA falling in the other layer, TMA will be totally innacurate.

This let me remember I started a TMA tutorial 1 month ago, and need to complete it ...

[darksythe]

I am definatly looking forward to that TMA Guide. Same as briefs if you need proof reading done on your english conversion(im assuming there'll be an english conversion. :lol: ) i can lend a hand.

[Amizaur]

OKO, do you mean that you can't get accurate TMA only by merging SA and Towed under 7kts ? Or maybe that you can't get very accurate TMA at all (even from Towed only) at under 7kts ? In second case I suspect TMA would be shifted a little but still accurate bacause all readings come from same source ?

[darksythe]

i have been wondering are the TA contacts reported in relation to the end of the TA it self or computed on board and in relation to ownship?

[LuftWolf]

The TA contacts seem to come from some bearing off of the sub, so I guess it's either at the end or the somewhere in the middle, probably the end since that is where the TA facing is calculated in the sonar station (why you can be going straight forever after a sharp turn and only see the TA start to come around very quickly at the end).

If it's at the end, then the longer TA lengths for the TB-23 and TB-29 (added courtesy of Periscope Depth's cable length mod in the LWAMI meta-mod v2.0 and higher) give the player an advantage in possible quick triangulation with the sphere or hull arrays for close contacts, although I wouldn't trust this result too much, just a quick heurtistic if you need it for a quick resolution or TMA solution check.

[OKO]

OKO, do you mean that you can't get accurate TMA only by merging SA and Towed under 7kts ? Or maybe that you can't get very accurate TMA at all (even from Towed only) at under 7kts ? In second case I suspect TMA would be shifted a little but still accurate bacause all readings come from same source ?

hoho ... you make me think you give new length to the TA, and hope this won't affect this problem ...

TMA is not shifted.
You could tought it is, because of side effects, but I can assure you it isn't.
During beta test, I spent around 100 hours on TMA, during 3 month, diging it everyway, because the thing was totally buggy at first LOL.
dot stack was inverted and shifted, time scale was shifted etc etc etc, lots of things.
I even made ~ 6 or 7 movies to show the problems.
And Sonalysts worked hard on this problem, especially Renee.I think I gave him quite few new white hairs ... LOL
I was always unsatisfied, each time Renée changed new settings.

But they finally released a real jewel of accuracy, after long, technical but very professional work..

But, to make a good TMA, there is lots of factor to respect :
no change of depth/course/speed during LOB recording, and 7 knts or more.
If you respect this, you can have a TMA around 2% of error with only 3 LOBs -so a bit more than 4 minutes of LOBs recording in good conditions- (merged TA and SA) and ~ 5% with only one sensor, on 6 LOBs (real minimum) -so around 10 minutes of LOB recording in good conditions-.

On Hull array, there is a beam wander effect if your contact is close to the edge of the sensor, so the most accurate TMA with the hull (especially the conformal of the KILO, the main tool for TMA on this platform) is made when the target is at 270° or 90°
recording LOBs coming from your 320 or 40 or 140 or 220 will give you corrupted LOBs, leading you to a VERY difficult, and anyway corrupted TMA.
Distance to the contact will be VERY hard to find in this case, and often lead to a missevaluation that could be twice, or half, the real values on the contact range. No TMA possible in this situation.

This is the usual problems encounter to makes good TMA on DW, on both nukes and KILOs.

I will need to test what happen with your longer TA ... (I rarely play nukes on MP matches, except on sub matches, so I didn't tried it with your new values)
I scare a bit for the Akula, because 7 knts was the minimum AND the maximum speed to make a correct TMA whith conserving the best detection capabilities, when the 688i could do the same until 14 knts, and the Seawolf 15 knts.
I hope with a longer TA (I'm not sure you also lengthened the TA of the Akula ...) the Akula won't have his TA falling down, in deeper water and by the fact corrupting the TMA.
I will test tomorrow and report.

cheers !

[LuftWolf]

The length of the Pelamida has been increased from, I think, 301m to 701m. :up:

7kts for TMA... yikes! Well at least the Gepard won't have to worry about such a narrow restriction, as the Pelamida II has max speed of 14 kts, leading to max 100% effective speed around 10kts. Not much more, but it helps! :88) :up:

[OKO]

The length of the Pelamida has been increased from, I think, 301m to 701m. :up:

7kts for TMA... yikes! Well at least the Gepard won't have to worry about such a narrow restriction, as the Pelamida II has max speed of 14 kts, leading to max 100% effective speed around 10kts. Not much more, but it helps! :88) :up:

Anyway, once you tracked the target, you could follow it on the TA until 10 knts (even if the TA looks washed out, the data still record), but this will kill you detection capabilities during LOBs recording.
I will see tomorrow with test if there is a new problem here.
crossing fingers :roll:

[LuftWolf]

I'm not clear on the interaction between TA length and TMA error, all other conditions being equal. :dead:

Can you give me some insight as to what a potental problem might be so I can do some testing as well?

[PeriscopeDepth]

I'm not clear on the interaction between TA length and TMA error, all other conditions being equal. :dead:

Can you give me some insight as to what a potental problem might be so I can do some testing as well?

I think he means this:

If you are performing manual TMA with a contact that has been detected by both the sphere and TA, the LOB the TA generates may be warped because it has drifted so far down that the direction the sound is striking the sensor from is different.

So, if this is correct, don't stream your TA the whole way unless you need to (dipping it under a layer). I never do anywho.

[LuftWolf]

ARGH! I've been busy... :damn:

Everyone who has sent me a PM or email and my MP and fleet partners, expect to hear from me tomorrow. :ping:

Cheers,
David

[Molon Labe]

I've been playing a bit more SP/MP games while testing a few missions for re-release, and of course, I've been collecting feedback for you guys! :sunny:

I'm very happy with torpedo behavior, and sonar performance in general. By tweaking the environmental conditions, we can pick and choose our detection ranges within a pretty wide range. It's a mission designer's dream! :up:

I'm also liking the revised loadouts of surface and air platforms, as well as the removal of the Uber-Type 40 from the SS-N-27. The APR torpedo on the IL-38 is working nicely, as are the USET's and UGST's on the skimmers.

Overall I think the Sound-Speed curves you have now are working pretty well. I still think you're being a bit harsh on the Kilo, but then again I haven't had a chance to play in it too much so I'm not sure. I do urge you to fine-tune the SSN balance further, however. The Akula-I Imp should be slightly quieter than a 688I (according to the US, at least), and the Akula II slightly quieter than the Akula-I Imp. Right now, you've got the 688I between the two. Even by making the Akulas quieter, the 688I should retain an edge in first detection because of better sonar...

VLAD performance is very, very weak, failing to detect a 7-knot Akula on the same side of the layer in a CZ SSP from under 1000 yards. That pretty much means it's useless.

Can you reduce the detectability of missiles? I think it would be better if subsonic missiles were a little harder to detect than their supersonic cousins, since many of them are small and steathly to begin with, and their lower speed should reduce the doppler that separates them from the wave clutter. It'll give the American missiles a chance to break through on occasion.

You turned up the RAM SAM a bit too much. It's smacking missiles down and making it look easy (it looks like the missile salvo doctrine is working for it too; making it twice as effective!). The SA-N-9 Gauntlet is also a bit too good; I have yet to see it miss once out of about 15 or so shots.

[PeriscopeDepth]

Overall I think the Sound-Speed curves you have now are working pretty well. I still think you're being a bit harsh on the Kilo, but then again I haven't had a chance to play in it too much so I'm not sure. I do urge you to fine-tune the SSN balance further, however. The Akula-I Imp should be slightly quieter than a 688I (according to the US, at least), and the Akula II slightly quieter than the Akula-I Imp. Right now, you've got the 688I between the two. Even by making the Akulas quieter, the 688I should retain an edge in first detection because of better sonar...



I wouldn't be too sure about the 688. What the US puts out publically in terms of 'threat' country's capabilities is often to scare Congress into buying the military shiny new stuff.

Oh, and about the VLAD and the Akula. I'd say that's acceptable, searching for modern subs at those speeds with passive buoys should be useless IMO. I'd say around 10-12 knots you should get hits. That's what would feel right to me anywho.

[Alleyviper7]

Wow, you guys are arguing about very small weapon parameters that no one can really answer because the ture info is classified. How about you guys work on the glaringly unrealistic stuff like subs using the SAM launcher or the one-armed bandit on the FFG. I've been to 4 or 5 naval bases in the last couple years and of all the frigates I've seen, not one still has the missle launcher. They've all been removed due to cost, maintanece issues, and the fact that the technology was really outdated. I understand that removing it would cause huge balance issues and would most likely take all the fun out of using the FFG ;) , so it's really a judgement call about whether or not to leave it in I guess.

[LuftWolf]

We can't edit the weapons loadouts or launchers of playable platforms because it is hardcoded in the game engine. ;)

[Molon Labe]

Hey, I might have been a little premature on the VLAD sensitivity. I'm actually baffled by it right now.

An Akula-I (i) generated a hot buoy at 2.4nm at 7knots. This is in a CV SSP, SS=2, Rock bottom, buoy and boat below the layer. Went to a solid 50hz dot at 2.0nm.

Same test, the Akula-II, 7 knots, ran over a VLAD and only set it to hot. Shoot, I don't know if that was a deep or shallow buoy...

In any case, 7 knots isn't exactly racing speed, and these are modern subs... I think its probably good enough to be useful without making it too easy. :up:

[MaHuJa]

I'd like to declare that lwami 2.01 (or earlier) has officially killed the ffg hull passive.

I mean, it can't even detect a torpedo closing in on you before it detonates anymore. Nor can you see your own torpedoes launched.

[XabbaRus]

Just curious but do you have AI specific sonar arrays for the 688i, Seawolf , Akula and Kilo?

[LuftWolf]

MaHuJa, this is a consequence of the torpedo noise level being lowered for every torpedo. I'm not sure, but this probably has to be looked at.

Xabba, no the playable objects retain the same sensors as before and we have not created AI only versions of those objects with separate sensors.

[LuftWolf]

MaHuJa, regarding the FFG Passive Hull Sonar, even with the stock DB, the passive hull array is deaf enough that it won't detect a supertanker at 8kts within visual range of the contact. We haven't changed the sensitivity at all of any passive sensor in the game, other than the VLAD, in the modified database, only reduced the passive sound levels of objects in the game, which creates a relative decrease in passive effectiveness for all passive sensors.

It really is a poor passive sensor, almost a waste of time to use in anything other than active mode, IMHO.

[Pigfish]

It really is a poor passive sensor, almost a waste of time to use in anything other than active mode, IMHO.

Hello. Ive mentioned this before but I can find subs at up to 20 miles away using the OHP hull passive. Depends of coarse on the type of sub, sea state etc. Just 'click' around and you will acquire. You DO NOT have to click around degree by degree-just be kinda close. If you've got a contact on TA first and have got a bearing check out the hull passive as another source of info. This is a way to speed up the 'legs' required for accurate auto TMA. Really a bug I think, not intentional. I would sure like to see this station improved so I could see something. :yep:

I think I should be able to see, say a noisy Victor at 10-15 miles, while Im going slow under the right conditions instead of 'cheating' by clicking around. I know shes called the "Hellen Keller" of sonars but...

I tried playing around with my limited DWEdit and doctrine skills to improve this station visually but I think its hard coded like weapons. :(

Ive never found this station useless but taking advantage of a bug is no good either... My 2 cents...

Should also mention once acquired this "bug" will not auto update. You can manually update but now have to be pretty bang on the bearing unlike the first time you acquire so don't let it age to much.

Again I would love to see this station improved. :up:

[Molon Labe]

To what extent can you guys modify AI doctrines?

I think the torpedo evasion doctrine needs work. They aren't using decoys enough, and some manuevering might be nice to (the Russians in particular seem to only use one passive decoy against an active homing torpedo that will probably need two active decoys to be evaded).

More importantly, there is apparently an AI doctrine causing all platforms to race at max speed when an unknown contact is detected. This is particularly problematic for subs, which are going to flank and giving their positions away to chase after a surface contact that the Orion is going to get to first anyways.

If it can be done, I would like to see the "unknown detected" doctrine to be modified for subs.... they should only investigate unknown sub contacts within a certain range (outside that range I'm thinking the mission designer can use triggers and scripts to send it off, so I wouldn't worry about unintended consequences), they should only investigate once they have come to comms depth and have become aware of the contact, and they should proceed carefully... I'm thinking the best solution would be deep sprint and drifts, with a 60 degree turn so make sure the sonar checks 360 degress, and slowing to tactical speed once it is within 10nm of the contacts last known position.

I know that's a lot to ask for, but if SCS doesn't do it, maybe you guys can... You're doing great work. :D

[Amizaur]

About FFG passive sonar not detecting torpedos - we didn't changed it at all. Only reason could be lower NL of torpedos. I tried to calculate torpedo base NL and noise curves so to get unchanged original NL as a result, but maybe I made a mistake somewhere, I'll check it ! :up:

About AI sub doctrines. We didn't change it at all beside little fixes of miscalculated ft/m depth settings and added AI reaction if it detects underwater missile launch (reaction is set same as for enemy torpedo launch). Yeah, default doctrines are very basic, I said it few times already, ans MUCH can be done. But it's a lot of work and later testing if all works correctly, I have little time lately, maybe now I find some to further improve 1.02 and maybe add some new already tested stuff (like custom ADCAP and UGST doctrines).

Maybe try to modify the default sub doctrine ? The language is really simple, only you have to paid attention to things like spaces, { and so on. Jsteed's descriptions and his tools to check doctrine integrity (SCDoctrineChecker and doctrine language templates for EditPlus text editor) is all I had and all my knowledge about doctrines comes from.
Later you have to test doctrine with DbgView active to check how it works, it's good to add custom debug comunicates (Debugout, DebugValueOut) after each more important command in test phase and delete them in final version of doctrine.

And finally, IIRC in SCX the AI behaviour doctrines (for example torpedo evasion) were in fact much improved and it made a distinct difference, maybe importing some SCX doctrines into our mod would be good idea, they are ready and very well tested. Much of my work was inspired by SCX doctrines and database solutions, I even used parts of them for example in my ADCAP torpedo doctrine doctrine, but up today I never used complete SCX doctrines. I know that great amount of work was needed to develop and test them. Anyone know who I should ask for permission use them in our mod ? Or maybe it would be OK just to use them with original headers and mention use of SCX stuff in mod documentation ?

[XabbaRus]

I wouldn't touch the SCX doctrines at all if I were you.

Best to send a PM to Thomas first and let him know and WAIT for an answer before going ahead.

Things could get touchy if you blast away with it.

[LuftWolf]

Since so much is coming out of X camp lately. :-?

[XabbaRus]

No its just a case of modding manners and avoiding accusations of stealing.

Just something similar happened with SCX and it would be better for their not to be any repeats.

There hasn't been much out of X camp due to waiting for the patch as they alter things that had been set.

Also exporting all the SCX stuff in the DW database will be a very time consuming task, I do understand Ludger is working on an SCX to DWX exporter but since there are twins on the way or arrived I guess he is bsuy.

Also just exporting the data isn't really the end of it. If you remember SCX stuff didn't come out too quickly either due to the testing of the database.

I'm just saying it is wiser to ask then just borrow it even if you add the credits.

[LuftWolf]

Well, the doctrine fixes have nothing to do with the 1.02 patch.

I would never steal another persons work, but I also wouldn't let prefectly good enhancements rot on the table when the community could have been using them since month one. :down:

[LuftWolf]

Their knowledge FAR exceeds mine, so I'm sure they have a good reason for keeping their work to themselves for a year and, of course, when and if DWX comes out, it will be truly remarkable. :up:

I'm just not sure why they aren't playing with the rest of the boys out in the field as of now and sitting in their basements instead. :hmm:

But that is the privledge of the people with the knowledge and thus the power.

[Amizaur]

I'm not going to blast away with anything :) that's why I'm asking

Just checked for sure because it was few months ago. I didn't use any parts of Thomas work in my DW demo of ADCAP doctrine, it was based on standard SCS doctrine. Only demo of my SC ADCAP doctrine was based on SCXIIc version, because it was mentioned to be used under SCXIIc so it was simply SCXIIc ADCAP doctrine with only parts calculating torpedo fuel/range/speed changed and notes in header added.

[XabbaRus]

I am afraid do am unable to say yes or no.

Send Thomas a PM he might answer.
Some times he disappears for ages then comes back and something has been done. Same happened with SCX...thought nothing was happening and then SCXIIC was here almost done.

[N00be]

Hi! I gor a question: I installed the mod, and played with it fine. Before I ran the install bat, I ran the backup bat file.
Now I wanted to play with someone who hasnt installed the mod. So I ran unisntall bat file but when I am ingame it still sais that my game database differs. Are there any files I need to delete manually, that were added with the mod? What else is changed than the 2 folders doctrine and database?

[Molon Labe]

Hi! I gor a question: I installed the mod, and played with it fine. Before I ran the install bat, I ran the backup bat file.
Now I wanted to play with someone who hasnt installed the mod. So I ran unisntall bat file but when I am ingame it still sais that my game database differs. Are there any files I need to delete manually, that were added with the mod? What else is changed than the 2 folders doctrine and database?

Well it sounds like you backed up and removed the mod properly. This means that your pre-mod database is different from your friend's. The most common database inconsistency is that one person has the hotfix installed and one of you doesn't. It's also possible that one of you has other mods installed.

If you don't have the hotfix installed, make sure the LW/Ami mod is uninstalled, install the hotfix, and then run the backup.bat again. Then try connection again and check for database errors. If the errors persist, try connecting to someone else, to see if the problem is with your database or your friend's.

[Amizaur]

Nothing beside the database and doctrine folders is changed, uninstall script should return game to the state it was at the moment when you run backup script. There is no need to delete anything manually, all important files are overwritten, and additional files does not interfere with anything.
But it's good to have original database and doctrine folders archived somwhere anyway, just in case. Deleting them in game folder and restoring clean versions from archive should solve everything, but uninstall script should work as well, even though some additional files are left there. Simple additional "delete *.*" line in the uninstall script would make the same, maybe I add in later, just in case... You may manually delete contents of doctrine and database folders and then copy to them files from .LwAmiMod folders.
But the most probably cause, as was said, is that your database files were not standard already when you run the backup script.

[LuftWolf]

I've sent a new SubAvoidWeap doctrine to Bill, which signficantly improves the AI torpedo evasion routines, especially with the non-exploding on CM torpedos from the Mod.

http://www.subsim.com/phpBB/viewtopic.php?t=44047 for details.

[darksythe]

@ LW & AMI.

Any idea on if your still interested in getting a website put together for the mod? if so get ahold of me so i can start putting somethings together for it.

Thanks,

Mike "DarkSythe" Young.

[LuftWolf]

Mike, we've both been dang, darn busy. :damn:

I'm sorry about leaving you hanging about that.

Amizaur, any thoughts on my email?

[darksythe]

Np.. As you witnessed last thursday night i was pretty busy.. ummmmm Unwinding? :rotfl: See post http://www.subsim.com/phpBB/viewtopic.php?p=402065#402065
<--Here and youll remember what i mean. :know:

[Amizaur]

I replied you already, week ago or so, that would be great to have a dedicated place for the mod :-). I'm up for it :up:

[LuftWolf]

Oh, Doh!

I thought you were going to send another one... my mistake. :damn:

Ok... you and Mike should get in touch about the specifics. I'm a bit out of my league here with the webdesign issues. :hmm:

[darksythe]

lol sometimes underwater comunications can move slow. lol ill standby to get ahold of ami, and discuss any desires he would have for the site.

You can reach me
msn at jfc_darksythe@comcast.net
email mike.young2@gmail.com
icq hmm what was that number... i forget well LW has it lol
cell phone is available if you wish
and also team speak on my days off thursday/friday

Some things to be considered.

1. Monthly costs for hosting. (i can handle these to start with. depending on the amount of traffic we draw we may need to take donations to front bandwidth costs.)

2. Domain Name registration. lwami.com etc...(or i can just get a a domain of my own and host you under it at something like www.lwami.mydomain.com etc..)

3. What kinda color schemes do you want to look at.

4. How graphic intensive do you want the site

5. Shall we have our own forums for the mod (I suggest this, Its not much extra work. Maybe an hour or so.)

6. Do you want a user management system to keep track of users feed back on the site seperate from forums.(Along with other features)

Im going to assume a few things such as.

1. We will want a News System Dynamic based(Database driven)

2. We would want a download system(duh download the mod lol. Unless youd rather just leave it at subguru.com (I would suggest we host our own copy and have subguru.com mirror it. that way you could also post also host beta versions for the beta testers which we could have using the user management system.))

So you can look these things over see how they fit with your ideas and get ahold of me either here or at any of the other ways listed.

ttys

[LuftWolf]

This was posted over at the SCS forum by DaveB, a former MPA flyboy.

It seems we got the buoy sensitivity pretty close. :cool: :D

Now assume a 3nm detection range on your buoys (generous - in reality some buoys don't even register they've been run over by the target)

[Deathblow]

Can anyone think of any sort of way of introducing launch transits into the game?

I just played a singleplayer mission where a Kilo was sitting a few nm off my bow taking continuous missle shots at the convoy I was escorting and I was none the wiser because no launch transits. :shifty:

:down:

[Amizaur]

Some kind of it is in the mod already. Were you talking about stock DW game ? In the mod every missile launch is very loud event (NL=100) lasting several seconds (longer when launching sub is deep, very short or no at all when it's on the surface), which usually can be observed on passive sonar. Still no autocrew reports of course, like TIW - this is not possible to make for modders. But you can watch passive sonar when you expect enemy missile launches and should see it there as short but very loud effect on the bearing of enemy sub.

[Amizaur]

Just took a look at too quiet torpedos issue. Yep, because of my error, in most cases they really ARE quieter now than in stock game... Sorry :oops:

And how this happened - originally torpedo speed-added-noise was +10, so torpedo at flank was database value + 10, in most cases 82+10 = 92.
I changed torpedo speed-added-noise to +20, to increase difference between slow and fast torp setting, and recalculated the base noise levels by -10 in general, to get the same result at flank 72+20=92.

Edit: can't believe but seems that I made yet another error... base noise levels were in fact reduced not by 10, but by 20 !! Or was it intentional, maybe I wanted to reduce overal NL somewhat ?? :hmm: :hmm: can't remember now. Maybe I wanted to bring NL back to state of 1.0 game, without speed-noise fix, which was betatested and balanced. But torps were usually cavitating anyway so speed-noise fix didn't change much here.

But...

I forgot about cavitation... In game most of the torps cavitates if not run below 500ft, and cavitation adds +20 to base noise value (overwriting speed-added-noise) so most torps run at max speed were 82+20=102 in stock game !! I forgot about this. In 2.01 torpedo base noise were generally about 72, and after adding even +20 from speed or cavitation this resulted in 92 overal noise level, 10 less than cavitating stock game torpedo :oops:

Have to think how to fix this. Have few ideas, revert things as they were in stock game, so NL=82 and speed noise +10, then deep-running torps have a -10 noise bonus of not cavitating, beside being under the layer. Slow running torp had about -2 to -3 bonus in noise level.

Or bring back 82 base value but leave +20 speed noise, slow running torp has -4...-6 bonus in noise level, but then torp at flank would be same noisy like cavitating one.

I think I'll combine two above, 82 base value and +15 speed noise, then deep-running non-cavitating torp would still get -5 NL bonus, with retained nice -3...-5 bonus for slow running torps.

Or what do you think ? Should deep-running max speed but non-cavitating torps get -5 or the whole -10 NL bonus in comparison to shallower cavitating one ?

And then maybe we'll include all quickfixes to 2.02 ? :)

And nice source to read about real-world detection ranges of various sonars. Guys from H3 project have made this work long before us :-)

http://mediawiki.advancedgaming.biz/index.php/Sonar_model

Very, very interesting reading :)

[Molon Labe]

I'd generally be in favor of the cavitation being the biggest factor, but I'd be happy as long as it's possible to make the weapon stealthy, especially when attacking skimmers. ;)

[Deathblow]

Some kind of it is in the mod already. Were you talking about stock DW game ? In the mod every missile launch is very loud event (NL=100) lasting several seconds (longer when launching sub is deep, very short or no at all when it's on the surface), which usually can be observed on passive sonar. Still no autocrew reports of course, like TIW - this is not possible to make for modders. But you can watch passive sonar when you expect enemy missile launches and should see it there as short but very loud effect on the bearing of enemy sub.

Try this.

1. Assign a sonar profile to each missle called "MissileLaunch".
2. Make the profile of "MissileLaunch" 1 distinct frequency.
3. Give each sub a new Sensor called "LaunchDetector" with the ability to detect only the the "MissileLaunch" frequency.
4. Set the "LauncherDetector" number of trackers 0, prefix = "L" and labeled "LaunchTransit".

That way the autocrew will detect the launch transit and place it on the navmap as "LaunchTransit". To help determine the difference between a misslelaunch noise and a normal contact.

This is untested but may work.

[Amizaur]

After some thinking I'll revert things to like they were originally :-). I can't change base noise level without changing resulting max cavitating NL, so I can't increase speed added noise because I would increase torpedo NL overall, decreasing possibility to make them stealthy. Even though difference between slow and fast torpedo would be greater, the actual noise level of slow torp would be greater too.
So I'll revert it to stock game settings, can't find anything better for now. Database NL back to around 82, speed noise +10, only changes left in mod would be that big or thermal torps would be somewhat more noisy than small or electric ones.

edit: I'm confused now because I noticed that torpedo base NLs in the mod were reduced not by 10, but by 20 ! So reverting them to original would mean increase them by 20, huge difference. Maybe first I should add 10 and see if it's enaugh ? :hmm: Don't know to do now, to be honest... Maybe I should make two versions and send them to you Molon Labe for betatest ? :)
Was it possible to send a "stealthy" (slower, non-cavitating) torpedo in stock game ? Don't think NL around 85 is much stealthy...
And is it possible in real life at all ? For example ADCAP is very noisy torp and not much stealthy even at 40kts...

[Amizaur]

1. Assign a sonar profile to each missle called "MissileLaunch".
2. Make the profile of "MissileLaunch" 1 distinct frequency.
3. Give each sub a new Sensor called "LaunchDetector" with the ability to detect only the the "MissileLaunch" frequency.
4. Set the "LauncherDetector" number of trackers 0, prefix = "L" and labeled "LaunchTransit".

That way the autocrew will detect the launch transit and place it on the navmap as "LaunchTransit". To help determine the difference between a misslelaunch noise and a normal contact.


Seems to be briliant idea !! I'm only not sure if autocrew will use this additional sensor (with sonar autocrew off??) on playable platform, but can't wait to try this :) Thanx !!!
P.S. I'm a bit less enthusiastic now after few minutes ;) because even now autocrew detects missile launch sometimes, but only sometimes because they lasts so short. And AI platforms detect them nearly always, but don't put them on a link for human players... And if ever, this would work only with autocrew on... Anyway worth to try, sometimes such experiments even unsuccesfull, gives next more fortunate ideas :)

[darksythe]

still waiting to hear about site needs...

[LuftWolf]

Oooo send it to me too! :-j

I'll help test! :yep: :D :lol:

[LuftWolf]

Mike, :oops:

We're talking it over. Very soon you'll have the information.

Sorry, we got "sidetracked" by some modding issues. :88)

[Deathblow]

Seems to be briliant idea !! I'm only not sure if autocrew will use this additional sensor (with sonar autocrew off??) on playable platform, but can't wait to try this :) Thanx !!!

How about this.....

1. give each missle a Active Sonar with a ping of a distinct frequency that give one ping when launched.
2. give each platform an Active Intercept sensor called "launchertransit" and with the ability to detect only the missle ping frequency.
3. Give the "Launchertransit" sensor 0 trackers. Tracker prefix "L" and a name "launchtransit"

Don't know how well this will work.....the tricky part may be changing the doctrine so that a missle is sure to emit the "ping" before it breaches the surface, but it might provide the automated "launchtransit" signal that we are looking for thats independent to whether a person is playing with the Sonar AutoCrew on or off.

Then again, the first method may be a better solution....if it works at all. :88) .... does anyone know if Sonalyst is planning on given us launch transits in the next patch anyway?

[Molon Labe]

After some thinking I'll revert things to like they were originally :-). I can't change base noise level without changing resulting max cavitating NL, so I can't increase speed added noise because I would increase torpedo NL overall, decreasing possibility to make them stealthy. Even though difference between slow and fast torpedo would be greater, the actual noise level of slow torp would be greater too.
So I'll revert it to stock game settings, can't find anything better for now. Database NL back to around 82, speed noise +10, only changes left in mod would be that big or thermal torps would be somewhat more noisy than small or electric ones.

edit: I'm confused now because I noticed that torpedo base NLs in the mod were reduced not by 10, but by 20 ! So reverting them to original would mean increase them by 20, huge difference. Maybe first I should add 10 and see if it's enaugh ? :hmm: Don't know to do now, to be honest... Maybe I should make two versions and send them to you Molon Labe for betatest ? :)
Was it possible to send a "stealthy" (slower, non-cavitating) torpedo in stock game ? Don't think NL around 85 is much stealthy...
And is it possible in real life at all ? For example ADCAP is very noisy torp and not much stealthy even at 40kts...

I'm the last person to go to about real life data. I just think it would be cool if you could surprise a skimmer by running a slow torp under the layer and enabling it really close. :arrgh!:

[darksythe]

Mike, :oops:

We're talking it over. Very soon you'll have the information.

Sorry, we got "sidetracked" by some modding issues. :88)

Ok just let me know once and a while that its still being discussed so i dont have to keep asking :P

[LuftWolf]

BTW, Mike thanks again for keeping on top of us about this... we are both headsdown in the modding stuff, so thinking about stuff like that is tough with the attention deficet issues from spending days buried in the DB editor... kills braincells, really. ;) :lol:

[Amizaur]

How about this.....

1. give each missle a Active Sonar with a ping of a distinct frequency that give one ping when launched.
2. give each platform an Active Intercept sensor called "launchertransit" and with the ability to detect only the missle ping frequency.
3. Give the "Launchertransit" sensor 0 trackers. Tracker prefix "L" and a name "launchtransit"


Very interesting too ! :up: Maybe even more promising, because almost everyone plays with active intercept autocrew, and a ping is nice audio warning that something is happening. The range of this dedicated AI sensor could be set to 20nm for example. Will try this, after correcting current 2.01 torpedo issue, thanx !

[ohadbx]

I'm sorry if this has been posted before...
I have installed the mod in version 2.01, but the splash screen says the version is still 1.01.
IS the mod supposed to change it in the splash screen?
Is there an easy way to check if the mod has been installed correctly?

[Amizaur]

The first question is easy - the mod doesn't change game version, you still have 1.01 game version only with modded database and doctrines.
The second question is more difficult... Is there any way to say if you are modded or not ? :hmm: If you have done backup of original database/doctrine folders (have run backup script) and you are not sure at which state you are currently, you may run Install or Uninstall script once again,nothing will broke :).
To quickly see the difference in the game best would be... :hmm: I know, launch a missile (Harpoon, SS-N-27) and quickly go to sonar to see if it shows on broadband display as a bright line (US subs) or high spike (Russian subs) :)

Cheers!

[LuftWolf]

ohadbx,

You could also check the dates in Windows explorer of your database files, if most of them are from september of this year, then you have the mod installed.

If most of them are from January of this year, then you have the stock DB installed.

That's how I check to see what I've got installed! :)

[ohadbx]

Thank you both! I think I got it modded now

[Amizaur]

Really on-line help, answers from both authors in less than an hour :lol:
Nice to see you here ohadbx, wish you good hunting with the mod :up:

[Molon Labe]

How about this.....

1. give each missle a Active Sonar with a ping of a distinct frequency that give one ping when launched.
2. give each platform an Active Intercept sensor called "launchertransit" and with the ability to detect only the missle ping frequency.
3. Give the "Launchertransit" sensor 0 trackers. Tracker prefix "L" and a name "launchtransit"


Very interesting too ! :up: Maybe even more promising, because almost everyone plays with active intercept autocrew, and a ping is nice audio warning that something is happening. The range of this dedicated AI sensor could be set to 20nm for example. Will try this, after correcting current 2.01 torpedo issue, thanx !

And it will actually make a ping sound? Yuck!
The transient system you have right now is pretty close to perfect...

[Amizaur]

The "ping" sound would have to be understood as "udnerwater missile launch" message, just sounding like a ping ;-))))
I'm thinking of that, unfortunately we can't have only perfect solutions with current engine. And missiles pinging at start is probably only way to make AUTO notification, without need to watch the sonar screen...
Of course missile launch will be still visible on broadband sonar like in 2.01 ! Just there would be additional ping sound and with enabled AI autocrew a contact line would appear on map named Missile Transient or similar.

BTW - I returned to Oleg description of how USNI database works and... I should make this month ago... It's in fact very easy to modify USNI descriptions, and it's a shame we didn't make it for 2.01 already. It's only little more difficult to install modified file because it's big and outside of database/doctrine folders (it's in graphics). But I think I can make backup of original USNI database file and build new at mod install and later switch modded/original versions with install/uninstall scripts just like databases :up: So next relase of mod will probably have correct USNI descriptions :)

[Deathblow]

And it will actually make a ping sound? Yuck!
The transient system you have right now is pretty close to perfect...

No its not. Its no where near perfect. Not being able to differentiate a launch transient from a normal broadband signal is equivalent to not being able to differentiate a active sonar ping from just another broadband source. Being able to delineate that the sound source was in fact a "ping" and not just another "sierra contact" is a crucial piece of information....
.....just as being able to delineate a source as a launch transient not "just another sierra" is as crucial a piece of info.

"oh by the way captain, did I mention that Sierra 21 was a active ping that probably detected us.... ooops forgot to mention that... oh and Sierra 22 was probably a missle launched at us.... forgot to mention that too... oh well." :88) :doh: :nope:

[Deathblow]

BTW - I returned to Oleg description of how USNI database works and... I should make this month ago... It's in fact very easy to modify USNI descriptions, and it's a shame we didn't make it for 2.01 already. It's only little more difficult to install modified file because it's big and outside of database/doctrine folders (it's in graphics).

ooooooo........ :hmm: :ping:
I want to play with the USNI database too.... where can I read about Oleg's description? Which file in the graphics folder is it?

[Molon Labe]

And it will actually make a ping sound? Yuck!
The transient system you have right now is pretty close to perfect...

No its not. Its no where near perfect. Not being able to differentiate a launch transient from a normal broadband signal is equivalent to not being able to differentiate a active sonar ping from just another broadband source. Being able to delineate that the sound source was in fact a "ping" and not just another "sierra contact" is a crucial piece of information....
.....just as being able to delineate a source as a launch transient not "just another sierra" is as crucial a piece of info.

"oh by the way captain, did I mention that Sierra 21 was a active ping that probably detected us.... ooops forgot to mention that... oh and Sierra 22 was probably a missle launched at us.... forgot to mention that too... oh well." :88) :doh: :nope:

The very large BB noise that the missile launch generates is hard to mistake for anything else in this mod. That's a tremendous improvement over DW 1.01, where there was only a tiny increase in signal that was nearly undetectable. The goal of the mod was to improve the realism and balance of the game without creating any new issues....the missile transient fix accomplished exactly that.

[LuftWolf]

The way the fix stands now, its also a balancing factor between Russian and Western platforms.

The Russians have better missiles, and the Americans have a better ability to detect missile launches, as the missile launches leave a very distinct trace on the waterfall BB which can be observed on the long-term scope, even if you aren't at the sonar station the moment the missile is launched.

However, if we can make an automatic signal without creating any new issues or something funny in game, then that works for me.

Remember, you don't have an inalienable right to an automatic missile launch warning. :-j :P :lol:

If a more heads-up (heads-down in the sonar station?) player gets an advantage from the current system, I don't have a problem with rewarding diligence.

[Amizaur]

Guys, it's only an idea now !!!! Nothing more !!! I even didn't try yet if it works at all :D. Of course that I would like to know people's opinion (maybe little poll but only if I confirm that it works), and I won't do anything without consulting this with Luftwolf as long as he's online :).

About editing USNI database - well not too far, search in this thread, page 12. And I searched for it half an hour only because I used wrong optio0ns in search engine :lol: One thing - when using decompress, give it a file name without extension, this is way it works for me.

[LuftWolf]

I'm all for making the feature better!

Let's try. :yep:

I just don't want to add anything forced. :)

[Bill Nichols]

The "ping" sound would have to be understood as "udnerwater missile launch" message, just sounding like a ping ;-))))


Does it have to sound like a 'ping'? Couldn't you use a different (new) sound, more like how a weapon launch would actually sound?

(I'm thinking now of how, in Silent Hunter III, I (at the sound operator's station) can actually hear the splash of depth charges entering the water, seconds before they explode.)

[LuftWolf]

That gives me an idea Bill. :up:

Or, maybe we could get the missile to sound like a member of the crew saying "Missile Launch Transient Detected". :yep: :)

[Tgio]

That gives me an idea Bill. :up:

Or, maybe we could get the missile to sound like a member of the crew saying "Missile Launch Transient Detected". :yep: :)
If you can do that, SCS has to assume you
;)

[Amizaur]

Well, correct me if I'm wrong but I understand that the ping sound is just sound played when enemy ping hits the boat, so if we changed it, then EVERY ping would sound like missile launch :-).

(Edit: after looking into sfx.agg I see that not every ping - just every torpedo ping :lol:
IF we could add custom ping sound to active sonar, the we could make it missile launch, but there is no such thing in database... most probably every active mounted on a torpedo calls for torpedo ping sound.
If so :hmm: what sound would be called for active sonar mounted on a missile ? :-j maybe nothing, or game crash ? :) so better first we check if it is possible at all, later we could discuss how should it look (sound) like :) )


And if we assigned a crew comunicate as missile sound, then I guess the missile would say it over and over in flight, instead of normal flying missile sound :-). It would be audible in 3D view, but not on other sub.
The thing we didn't make, was to assign BB sound file to a SUBROC missiles, this is the sound heard in BB sonar station on bearing of the contact. If we assigned a sound of a distant underwater missile launch to it (or rather missile motor working underwater) then there should be no more problems with discriminating it from any other target, you would just hear the missile at the bearing. Best would be sound already present in game, this would require only database change. If we don't find it (because it has to be underwater missile sound) then we would have to add it to sfx.agg which means more complicated install and changes outside database folder... but we probably have to do it anyway to update USNI reference database.

P.S. I though for a moment that we can use BB_shkval sound, shkval underwater, but it's wery poor choise... it sounds like a missile combined with a torpedo, so you hear missile with rotating propellers :down:
But we could use it and add a stand-alone second little mod with better skhval sound, which can be used both with stock game and modded.
We can try also just missile launch sound, who knows maybe it would work ok... edit: probably wouldn't, seems I can't use fx_xxx sound as bb_xxx sound...

Best would be combined sound, beginning from torp launch with missile launch later, processed to sound like underwater. Then if you listened on the bearing and the distance wasn't long, you could actually hear whole missile launching sequence. I wish Finiteless was around... wonder what happened with him ? :hmm:

[Deathblow]

Bah, been testing the first method I proposed and I can't get it to work. Adding the new sensor to a platform isn't having any effect, just ignores the sensor as if it wasn't there.... :damn:

:-? perhaps a 3 passive sensor limit is on platforms? more testing needed...

[Amizaur]

Well, you want the autocrew to mann it, maybe autocrew is programmed to use only 3 original sensors on playable platform...

[LuftWolf]

Ok, so what are we looking at for 2.02?

Changes and Additions

-Add updated Missile.txt and SubAvoidWeap doctrines to distribution

-Increase Torpedo Passive SL and alter sound vs speed thrust values

-Add LWAMI section to USNI (pending Jamie's clearance on copywrite)

-I would like to review the sonar sensor assignments to individual platforms

-Create the unit information tables (if I have the time... :damn: :hulk: )

-Work on trying to automate Missile Transient Warnings.

Anything else? :hmm:

[Molon Labe]

Ok, so what are we looking at for 2.02?

Changes and Additions

-Add updated Missile.txt and SubAvoidWeap doctrines to distribution

-Increase Torpedo Passive SL and alter sound vs speed thrust values

-Add LWAMI section to USNI (pending Jamie's clearance on copywrite)

-I would like to review the sonar sensor assignments to individual platforms

-Create the unit information tables (if I have the time... :damn: :hulk: )

-Work on trying to automate Missile Transient Warnings.

Anything else? :hmm:

Fix the loadout on the MH-60 to include torpedoes when on strike (Hellfire) configuration (ASTAC).

Make the Akula I-Improved a bit quieter than the 688I to better reflect best real-world estimates.

Try to identify and edit the doctrine files that are causing AI subs to sprint and reveal their locations.

Increase the warhead of the A244 Torpedo to be more proportional to the Mk 46 (the A244 has a slightly smaller warhead, but only inflicts ~30% damage to a 688I).

Decrease detectability of slower missiles to simulate reduced doppler effect to separate the missle from wave clutter and/or use of radar absorbent materials.

Just a wish list, really. :cool:

[LuftWolf]

Molon, thank you! :up: :rock: :arrgh!:

Fix the loadout on the MH-60 to include torpedoes when on strike (Hellfire) configuration (ASTAC).

Unfortunately, this is hardcoded in the interface and we can't do anything about it. I really really would if I could, that's something that bugs me too, a lot. :damn: :damn: :hulk:

Make the Akula I-Improved a bit quieter than the 688I to better reflect best real-world estimates.

I think you and Amizaur are going to have to joust over this one. :-j His data puts the Akula I Imp as being noisier than the 688i in design, and given the maintance and engineering quality difference, it's a harder case to make. I'm sure he'll comment on this one. Sorry... :-?

Try to identify and edit the doctrine files that are causing AI subs to sprint and reveal their locations.

This is a big issue. The problems probably won't be hard to find, but the fixes are most likely a going to be bear. Top on our list, you can be assured. :|\

Increase the warhead of the A244 Torpedo to be more proportional to the Mk 46 (the A244 has a slightly smaller warhead, but only inflicts ~30% damage to a 688I).

Amizaur reduced the warheads of some torpedos to be very light weight, either to simulate very light torpedos or torpedos known to proximity fuse and thus not directly contact hulls, causing much less damage than normal for a warhead of the same weight. I don't have direct information on this. We'll look at it.

Decrease detectability of slower missiles to simulate reduced doppler effect to separate the missle from wave clutter and/or use of radar absorbent materials.

This one's easy. We'll look at it. :up:

Thanks again Molon, you're a champion! :up: :rock: :arrgh!:

[stormrider_sp]

Looking for new platforms, even if they´re not playable.

[LuftWolf]

Adding new platforms to the database is fairly straighforward. However, doing it correctly means adding new 3-d models as well, which requires a modeller and painter and we currently don't have them "on staff."

What we are currently working on falls more into the catagory of "gameplay mod: realism," so we are currently focusing our efforts on tuning the gameplay to work as well as possible.

Periscope Depth has been working on adding additional Navies and platforms into the database, which we will probably include in a subsequent release, but at this time, it remains on another level than we are currently working.

Also, we can add the platforms to the database, but mission designers would STILL have to decide to include them in their missions, and this would make those mission incompatble with the standard database.


Thanks for your suggestion!

PS When/if DWX comes out, there will be a whole bunch of new platforms added to the game, as they have the advantage of using their 3-d models from SCX, which represents a considerable body of work.

[TLAM Strike]

Well if you can get someone to convert it to the proper format for DW you can use any of my models. Only the GUPPY II would really fit in to the DW time frame. But I do have a Zulu IV class sub in the works.

[LuftWolf]

Thanks TLAM! :D

When we look at expansions, we'll be sure to contact you about those models. :arrgh!:

[Molon Labe]

Is there a way you can look at link behavior? Some platforms seem to provide link data better than others. If you could get an E-2 to provide link data (I'm not sure it does at all right now), this might allow DDG/CG's to engage at ranges greater than 10nm.

[LuftWolf]

I just did a quick test scenario.

I had an E-2 circling around an Vishnaya with a Tico VLS and playable FFG about 50nm away, both in EMCON. The E-2 does promote the Vishnaya to the link and the Tico in fact will engage the Vishnaya with Harpoons.

I also had a Akula playable in the same scenario near the E-2. I played the scenario from the Akula side and fired a volley of missiles at the two warships. The E-2 detected the missile launches and promoted the missiles to the link, because even in EMCON, the CG started evasive manovering immediately after the launch of the missiles. However, the CG still did not engage the vampires with its SAMs until they had gotten within 10nm.

This remains a mystery. It must be somewhere in the doctrines, rather than the link behavior, or so my logic tells me, which I guess is good news, because it can be changed by modifing the doctrines, and doesn't require a change of the gamecode. But then again, I have my suspicions that AEGIS ships are hardcoded to hold fire on vampires until 10nm. I dunno... I'll look at some doctrine stuff.

[LuftWolf]

AEGIS-Fixed (Beta)

If you remove the fire control radar flag on the AEGIS launchers, they will launched on linked missile contacts at max range.

CAN I GET HEYAA! :rock: :rock: :rock:

This will be in the next version of our Mod. :rock: :rock: :rock:

[LuftWolf]

Ok, so the AEGIS fix consists of:

-Take the FCR Flag off of the SAM launchers on ships we want to enable link-missile firing, primarily AEGIS ships.

-Increase all of the engagement ranges on the CIWSAttack doctrine

-Change the cone of the E-2 Hawkeye radar so it scans the entire sky

Simple, eh? ;) :D :rock:

[Molon Labe]

Adding new platforms to the database is fairly straighforward. However, doing it correctly means adding new 3-d models as well, which requires a modeller and painter and we currently don't have them "on staff."

What we are currently working on falls more into the catagory of "gameplay mod: realism," so we are currently focusing our efforts on tuning the gameplay to work as well as possible.

Periscope Depth has been working on adding additional Navies and platforms into the database, which we will probably include in a subsequent release, but at this time, it remains on another level than we are currently working.

Also, we can add the platforms to the database, but mission designers would STILL have to decide to include them in their missions, and this would make those mission incompatble with the standard database.


Thanks for your suggestion!

PS When/if DWX comes out, there will be a whole bunch of new platforms added to the game, as they have the advantage of using their 3-d models from SCX, which represents a considerable body of work.

Nice work on the AEGIS/link discovery. :up:

If you are thinking about adding AI platforms, I think a good place to start would be on SAM/SSM installations, since they are quite generic. Some badass shore-based SSMs besides those whimpy little Styx's would be great!

The Russians are also short a few key ships, like the Kiev class VTOL carriers (a great addition to limit the patrol areas of MPA), and the US is missing several classes of auxiliary ships that tend to deploy with carriers. Yep, a wish list once again. ;)

[Fish]

I wonder LW (Ami), could you guys make the AI or even humans link info to landbased SAM and SSM sites, work?
It doesn'twork now, isn't it? :-?

[Molon Labe]

SSM links seem to be working, but are a bit iffy. They don't engage at maximum range, but they do engage as long as someone is out there spotting for them. Sometimes they shoot in the wrong place, as if the link was inaccurate.

[stormrider_sp]

Fish, it does, but as far as I know, you have to update the link minute after minute in order to have a launch.

[XabbaRus]

I wonder LW (Ami), could you guys make the AI or even humans link info to landbased SAM and SSM sites, work?
It doesn'twork now, isn't it? :-?

Never seemed to be a problem.

Seen plenty times when land based SSMs have launched on link data.

[Hanu]

Umm, do I still need Jamie's official "Sound vs. Speed" - Database HotFix when using this mod? Should it be installed too or not?

[Hanu]

Darn, sorry. Just noticed that some versions of those files were included too so I guess I'll dont need the Jamie's version.

[LuftWolf]

I would install the hotfix first, just so you have the complete 1.01 set for backup purposes. Then when you run the install script, the Mod will copy over the necessary files.

So, it's entirely up to you. :up:

Enjoy! :rock:

[LuftWolf]

To be sent to Bill very soon after some final testing, LWAMI 2.02 for you enjoyment! :|\ :rock:

Here is the 2.02 addition to the readme:

LuftWolf and Amizaur’s Weapons and Sensors Realism Mod v2.02
Hosted by www.subguru.com
Readme by LuftWolf
Edited by Amizaur

Amizaur has made a more substantial and significant contribution to the creation of this mod than me. Tgio has made a significant and direct contribution.

Specific changes for v2.02:

Sphere and Hull Array Modeling—THIS REPRESENTS A SIGNIFICANT GAME-PLAY CHANGE. All Sphere and Hull Passive Arrays, playable and AI, have had their sensitivity increased significantly from stock DW. These arrays should be much more useful now for detecting and tracking civilian traffic, torpedoes, loud and close submerged targets, etc. Expect to use these arrays much more frequently for general situational awareness and establishing TMA on surface traffic, meaning the TA is now going to be used primarily for tactical awareness, e.g. finding and establishing a track on hostile submerged contacts (or that sneaky FFG stalking slow and quiet). Establishing the correct bearings of Master contacts has never been easier! I have also increased the baffling of all Sphere arrays ACTIVE AND PASSIVE to 120 degrees directly to the stern. The most dramatic effect this will have, in game-play terms, is on the FFG player, who no longer has nearly omni-directional awareness from active sonar, and in submerged stalking of escorted convoys, making it easier to get in behind the escorts. All of these changes are dramatic (in my opinion) and may need to be tweaked later on, hopefully not the day after we release the mod… ;-)

Sonobuoy Modeling—THIS REPRESENTS A SIGNIFCANT GAME-PLAY CHANGE. To better reflect the way different sonobuoys are utilized in actual practice, the VLAD Shallow has been given the depth of 800ft, and the VLAD Deep has been given the depth of 1200ft, to prevent the use of VLAD’s in shallow water, as is realistic. The DIFAR buoy (90/400ft) MUST now be used in shallow water in the game, as it is the preferred buoy for shallow water operations in the real world. You may also want to take DIFAR Deep buoys along if you feel there may be a shallow surface duct and you want to have a good above-layer passive buoy option, that is a personal player preference. The DICASS Deep has also been given the depth of 600ft, to give an under-layer option for medium to shallow surface duct environments. Be aware, that this will change the game-play balance further in the direction of submarines for littoral operations, and possibly slightly in the favor of air-platforms in open ocean operations, given the option to put VLAD’s under layers in deep waters. Just remember NOT to load any VLAD’s if you are going to be operating in water that is shallower than 800ft. New buoy depths at a glance:
DIFAR 90/400
DICASS 90/600
VLAD 800/1200

AEGIS Ship Behavior BETA—The Fire Control radars of AEGIS cruisers and destroyers were previously limiting their engagement range to an unrealistic degree. We are currently in the process of thoroughly reworking the entire radar modeling treatment in the database. However, in the meantime, we have changed the FC Radars on the AEGIS vessels to enable missile intercept behavior at the limits of the horizon, and slightly further if there is a linking platform, simulating decreased response time. These changes are essentially modeling the realistic engagement ranges on incoming missiles for AEGIS vessels in the real world, meaning that AEGIS ships will now provide effective fleet defense against missile threats at range. Mission designers, enjoy! Note: From a simulation standpoint, the way this has been accomplished WILL change in the next version to better model the way these platforms work in RL, however, from a game-play standpoint, the effect will be nearly the same. This version’s modification also includes a change to the CIWSAttack doctrine, which will be altered again in the next version of the mod. Also, as part of this temporary fix, I have changed the E-2 Hawkeye and E-3 Sentry radars, as previously they were only scanning half of the sky, meaning these should now be much more effective link participants.

Decoy Modeling—I have added a Passive Sound Level of 60 for active decoys, as the cloud of bubbles created by the active decoys have to make some kind detectable broadband sound. I have also added a small Active SL of 40 to passive decoys, which is still significantly less than torpedoes, as should be expected from any metal object in the water of comparable size.

Torpedo SL and Thrusts—Due to our error, torpedoes were much too quiet in LWAMI 2.01. This has now been corrected. We have introduced some variability in torpedoes to reflect real-world differences and have altered the thrust values to make possible, in some cases, deep running, slow, stealthy shots, but this tactic still cannot be relied upon, especially given the near-universal TIW calls, which we can’t change.

MANPAD (sub-launched SAM’s)—We have reduced the effectiveness of MANPAD’s as follows: Stinger (FIM-92) 75%, SA-N-8 65%, and SA-N-5 60%, to reflect what we believe would an accurate representation of the real world effectiveness of these should-launched weapons. And… also to further discourage the gamey and unrealistic use of SAM’s from submarines in missions. :)

TASM and Harpoon—We have reduced the radar signature of the TASM to 45 and the Harpoon to 40 (verses all other missiles which are 50), making them marginally more effective (read: detectable at slightly closer range) against defended surface targets than before, and giving another slight advantage to the Harpoon over the TASM. All missiles will be looked at when we remodel the radars. This is not a drastic change, but should help a bit when attacking with these missiles.

Maverick Missile Fix—The Missile.txt doctrine has been altered to prevent the missile from homing in and destroying submerged targets and aircraft. This constitutes a total removal of the “Magerick Missile Cheat,” however more testing is required to proclaim it totally dead without consequences, but we are 95% certain it’s gone with no residual traces.

SubAvoidWeap.txt—We have changed the submarine avoidance routines so that AI subs will always throw an Active CM when attacked and will evade incoming torpedoes at 100 to 140 degrees from their initial incoming bearing. This constitutes a simple yet dramatic alteration in the AI submarines’ ability to evade torpedoes in all conditions. Expect AI subs to avoid the first pass of ADCAP’s or UGST’s from less than 5nm as well as just about every LWT fired at medium to long range. I believe this to be a major game-play improvement for AI platforms, but more work is required to make evasion routines more complex.

Torpedo.txt Doctrine—I have decided to include the full Torpedo Doctrine Mod in this release featuring random circle/snake direction, the anti-surface casualty mod, the correction from meters to feet so that AI subs will launched torpedoes set at proper depth for submerged targets, and the variable randomized search depths for airdropped torpedoes, meaning sometimes torpedoes will be fired under layers. We don’t believe there to be any bugs in this full modification at this point, but, as always, all feedback is welcome on this or any aspect of the mod! In case you experience any crashes or undesired behavior, I have included the standard non-casualty torpedo.txt doctrine, which will be placed in your main DW directory for backup purposes. So, in the unlikely event you need to install this backup, just delete the “torpedo” doctrine installed with the mod in the Doctrine folder, and change the name of the “torpedo.avoidcasualtyonly” to simply “torpedo” (without the .txt, this extension is stored by Windows XP automatically) and place it in both your Doctrine and LwAmi.doctrine folders. But like I said, it shouldn’t come to this. ;)

[Beer]

The Random Circle pattern direction on the torps (left or right turn) has got to go :down:
Should be to the right for gameplay.

The fact that ones knows what the weapon will do when it hits the water is important for weapon placement and delivery.

[LuftWolf]

Good point.

We'll consider it. :up:

Thanks for your interest in the Mod! :rock:

[LuftWolf]

Actually, Beer thanks for bringing this up.

Amizaur, I was looking at the doctrine and doing some tests... does the random direction command work for CircleSearchPattern as well? The command in the doctrine is snakeleft/snakeright?

I assume that is for both snake and circle search pattern. :hmm:

If it does work for both, we should probably consider not having random circle direction, for the flyboys, as beer suggested... maybe you can enable it for subrocs only?

[LuftWolf]

:oops:

Yeah, I just did test it... the circle direction is randomized as well.

Hmm... if that is the command, then it seems like we are stuck with either randomized direction for both snake and circle or randomized direction for neither.

Amizaur, what do you think about this? I'm not sure what the best option would be... I like the randomized direction personally. :hmm:

[Amizaur]

Of course it can be removed easily :).

P.S. After little work it can be even made that human player torps would turn always right, and AI torps random :) But SUBROC torps would be treated as AI drops, I can't discrimine in doctrine if torp was dropped by human or AI SUBROC... so maybe better remove this completly ? Or maybe not, the random circle for SUBROCs makes them less "sniper" weapon after all ?

So what to do ? Remove completly ? Or right circle for human torps, random for AI and SUBROC dropped torps ?

[LuftWolf]

Is it possible to set it based on depth?

Even number depth-right snake/circle

Odd number depth-left snake/circle

AI or SUBROC-random

That might be the best of all situations... if you can't do that, I'd say right for human and random for AI and subroc. :)

[Molon Labe]

Just did a little AEGIS testing. The engagement range is extended to 15nm at least. What is interesting is that the ships aren't shooting until the missiles enable. Apparently, they are detecting them at range but are not classifying them as hostile.

So, if someone sets their missiles to enable at a range of 10-12 miles away, there is no change in engagement range.

It's still an improvement though, at least if aTMA is off some skill will be required to deliver the missiles that accurately.

[OneShot]

I would go with the the Human = Right turn / AI = Randomized. As Beer already pointed out, if you have randomly turning torpedoes you have a hell of a time bringing them on target. And dont forget, unlike Subdrivers - Air guys cant resteer. Now, especially with the Mod, if you arent right on the money at the beginning you most likely just wasted a torpedo. So just for the sake of balancing, make them predictable turning right (or left) as long as its one direction - all the time.

[LuftWolf]

Molon, what you are describing is what happens when you set EMCON for the AEGIS ships.

Make sure they have their search radars on, and you should find the range increased to 18-25nm, depending on the conditions. :)

[LuftWolf]

Oneshot, I've actually found that a torpedo that initially circles in the opposite direction of the target can be just as effective as one that circles directly towards the target, since its approach angle once it completes its circle is often better for preventing spoofing from decoys.

I've dropped many torpedos with show truth on, and the difference in weapon effectiveness actually isn't terribly different.

But I agree, there should be some predictability. I'm not trying to suggest that I dissagree with you and Beer about that basic point.

[LuftWolf]

The main difference for flyboys with this mod are the greatly reduced seeker ranges for the LWTs. Given the 500yard circle direction, no matter which way the torpedo circles initially, you are going to have to put the torpedo within about 1.5nm max of the target to get a reliable kill, maybe even closer depending on conditions. You no longer have the 3.5nm Circle of Death. ;) :lol:

Not that I would presume to be able to tell you experts anything useful, but I think you may find the snake pattern more useful now in some conditions. :88)

[Amizaur]

Of course it can be done to steer by depth - even number right, uneven number - left :-).

Molon Labe - in tests of Tgio's FC radars I noticed that first detection was often by ESM, not by radar. You have to use DbgView (it's really easy, I wrote description few times here on forum) and see what sensor makes first detection - radar or ESM. If ESM, then probably detection is made by ESM, and target is engaged immediately because it's within FC det range (FC radars are disabled at start, enable only when platform fire - and then possibly are left enabled). Or maybe it's indeed ID, DbgView reports identification of targets too, you can check.

P.S. Right - ESM and FC radars are "mounted" higher than SPY radar !!
Have greater radar horizon. For SPY I've set correct height, for ESM and FC radar is still zero so 2/3 of mast height is used ! And it's higher.
It's OK for ESM which can be high on mast, but FC radars should be set height equal to SPY, even though they are higher physically, they probably have to be fed with target data from SPY radar to acquire.

[Molon Labe]

Of course it can be done to steer by depth - even number right, uneven number - left :-).

Molon Labe - in tests of Tgio's FC radars I noticed that first detection was often by ESM, not by radar. You have to use DbgView (it's really easy, I wrote description few times here on forum) and see what sensor makes first detection - radar or ESM. If ESM, then probably detection is made by ESM, and target is engaged immediately because it's within FC det range (FC radars are disabled at start, enable only when platform fire - and then possibly are left enabled). Or maybe it's indeed ID, DbgView reports identification of targets too, you can check.

Well, I guess it wouldn't hurt for me to learn dbgview. But the Burke is not in EMCON, that's for sure.

[Amizaur]

Download http://members.chello.pl/m.ostrowski7/files/DebugView_4_DW.zip

There is short graphical guide how 2 use with DW. Notice that there is one space between DW executable name and -debugoutput addition. Use filters "detect" if you want detections only, or more arguments spaced by , if you wants more. Best to run once with all inclusive * filter to see what kind of info you get, and then choose few keywords you want and use them as filter arguments (f.ex. "detect","launch","hostile","evad")

[LuftWolf]

I should mention that there is a difference in engagement range for AEGIS vessels if they are able to detect the launch of the missile before it reaches its skimming trajectory or if they have a linking platform.

If their first warning of the incoming missile is the missile in its search phase, then they will engage the missile later than if they knew the missile on launch before it went low or had a link contact for the missile.

To be honest, I'm not exactly sure why this is, but it's not from the ESM detection, which there usually isn't until the missile gets much closer. Perhaps there is a delay in turning on the FC radars? The detection information from DBGViewer is a little confusing on this issue, and I can't figure out why.

Like I said in the readme, the simulation aspects of this will change, but for now, it behaves in a way that feels right, to me anyway, simulating reaction times and everything (even though that is a bit of an accident). :|\

[Molon Labe]

I should mention that there is a difference in engagement range for AEGIS vessels if they are able to detect the launch of the missile before it reaches its skimming trajectory or if they have a linking platform.

If their first warning of the incoming missile is the missile in its search phase, then they will engage the missile later than if they knew the missile on launch before it went low or had a link contact for the missile.

To be honest, I'm not exactly sure why this is, but it's not from the ESM detection, which there usually isn't until the missile gets much closer. Perhaps there is a delay in turning on the FC radars? The detection information from DBGViewer is a little confusing on this issue, and I can't figure out why.

Like I said in the readme, the simulation aspects of this will change, but for now, it behaves in a way that feels right, to me anyway, simulating reaction times and everything (even though that is a bit of an accident). :|\


OK, got DbgView up and running.
Launched 4 ASM from 20 miles out. E-2, DDG, and FFG all detected at launch.

ASMs enabled 10nm out. ESM contact was made, and missiles were identified hostile. Chaff was fired and a barage of SM-2 were launched. I'm not sure which stage they were fired at. A second volley, however, was required, resulting in one missile getting through.

As far as I can tell, even with Dbg, they are holding fire until the targets are classed hostile, and this does not occur until their seekers enable.

[LuftWolf]

Huh?

In my tests, the missiles are never classified before they are engaged.

Do you have the ships and the launching platforms set on different sides?

[Molon Labe]

Huh?

In my tests, the missiles are never classified before they are engaged.

Do you have the ships and the launching platforms set on different sides?

Of course!

[LuftWolf]

I tested again from 20nm.

The first barrage of missiles are engaged around 15nm.

The second are engaged as soon as I launch them. Apparently there is a delay in turning on the FC radars and then once they are on, the engagement is made much faster.

I dunno what's up... there must be something in your test setup that is different than mine. :hmm:

[Molon Labe]

I tested again from 20nm.

The first barrage of missiles are engaged around 15nm.

The second are engaged as soon as I launch them. Apparently there is a delay in turning on the FC radars and then once they are on, the engagement is made much faster.

I dunno what's up... there must be something in your test setup that is different than mine. :hmm:

What was your enable range?
You also might have been detected when you launched, classifed hostile when the missiles that came from you were classifed, and then all further missiles coming from you were classifed hostile. Maybe.

[LuftWolf]

I've also tested the missiles launched from over 100nm away.

Give me one second to try something. :up:

[LuftWolf]

I just tested again, firing from 100nm+, and set the missiles not to enable at all.

And I got the same results. First missile engaged around 16nm and second missile engaged about 20nm.

I don't know why your ships are waiting until they get an ESM contact. DBGview is reporting for me that the missiles are never classified as hostile and are never detected on ESM under any conditions. As soon as the detection occurs, the ships switch to CIWSAttack and engage.

[LuftWolf]

Can I email you my test scenarios?

PM me.

[Molon Labe]

Can I email you my test scenarios?

PM me.'


Go ahead.

I just got a few longer range engagements, but those occured when a helo was nearby and ID them hostile. I see a pattern emerging.

[LuftWolf]

Unless I force the search radars off, I never get an ID before engagement. :hmm:

[LuftWolf]

[3772] SC2: Launched entity - hull: 4001
[3772] SC2: Launched entity - time - speed: 34.710002 25.722223
[3772] SC2: Launched entity - rates speed: 28.293801
[3772] SC2: New Track Num 3, ent hull 4001, tgt hull 4001
[3772] NSE: 3M54E stage 1 Enabled
[3772] NSE: Run:
[3772] NSE: 138995.328125
[3772] NSE: SS-N-27 ASM detected by TICO CG (VLS) with Radar at rng 35063
[3772] NSE: CIWS Attack Init
[3772] NSE: CIWS Attack Init
[3772] SC2: New Track Num 4, ent hull 34004, tgt hull 34004
[3772] SC2: New Track Num 5, ent hull 34005, tgt hull 34005
[3772] NSE: SS-N-27 ASM detected by O.H. Perry FFG with Radar at rng 33544
[3772] NSE: CIWS Attack Init
[3772] NSE: CIWS Attack Init
[3772] SC2: New Track Num 6, ent hull 34006, tgt hull 34006

[Molon Labe]

Your test scenarios are locking my computer up. Try sending them again inside a zip file, I think outside of a zip they get corrupted.

[LuftWolf]

Done. :cool:

Sorry about that.

[Mau]

Luftwolf and Molon Labe,

This is by far for me the most interesting Topic to discuss
(Can we please put that one on the main one - the general topics, may be under another name like ``Detection of SSM``)

Like you are saying I think the behavior looks all right.
Let say I am well implicated in this in RL. The fact that there is no indication prior to a detection of let say inside 20nm (which is real life - Radar horizon + Atmospheric condition/effect depended and height of sensors) will absolutely take more time to engage that same missile. The assessment of an OPs Team in this has to be quick. Secondly, as in RL, the lock with the FCR will not be immediate (sometimes way faster than other).
If linked by an helicopter, the team knows at that time so as soon as there is a ``Pop-up`` on the same bearing and same speed has reported by link or previous Intel than you are right on top of it with your assessment.
Unfortunately like I was saying couple of weeks ago, we don`t have an altitude provided with our FCR like in RL or automatically (3D Radar) with AEGIS. Than you can assesses if it is a Fighter attack Bomber (usually 500ft) or an SSM (0 feet or on the deck).

I am really really interested in your testing with this!
I know with a ship without AEGIS, even though you have an hostile Link track you can`t engaged until you have it on your FCR radar and locked on the track that has a blip under it. Now I have to find out with AEGIS equiped ship. I don`t think so too. However they shall be able to engaged a bit faster (like in your testing) because of that 3D availability that they have with the AEGIS and the great ``resolution`` provided by AEGIS radar.
I will find out early for you guys if an AEGIS can engaged a Link track for sure.
I would expect to see more missiles in the air however when attacking a threat (CG - 4 FCR and Arleigh Burke - 3 FCR with all AEGIS controlling in te mid term.

Continue your good work!

Mau

[LuftWolf]

Mau, thank you! :up:

I was getting AEGIS ships to fire at link missiles contacts, sometimes up to 70nm away! I accomplished this by disabling the requirement of the AEGIS SM-2's to require the FCR to lock on the missile.

This was done to experiement with the parameters which limit engagement.

The solution put in place now, is to still require the FCR, however the range of the FCR's on AEGIS ships has been greatly increased. Previously it was limited to picking up missiles within 10nm and that was way way too short. So, now, the ships still require the FCR, however for "no-warning" threats, there seems to be a delay between acquiring the missile on the search radar, and the ships painting the vampires with their FCR, which slows down launch a little bit. With link or launch-track warning, the FCR radars seem to be on sooner and the ships have a bearing for the vampire, so engagement occurs a bit sooner.

Interestingly, a lot of this has been largely unintentional, on my part, and seems to be built into the sim. So I think this is another example of how DW was hardcoded with some amazing features, that nobody ever saw because of limitations in the database, in this case, the extremely unnatural range limits on the AEGIS FCR's.

[Amizaur]

Guys, if you are launching SSMs from 20nm, they even don't get low to their cruise altitude before being engaged :). You know that after launch they climb few hunderds (if not 1k+) feets in the air and then dive low again. Reaching the 50ft altidute takes them quite long time. And they are detected in climb phase usually (by SPY), then if FC radar range is enaugh they would engage them immediately (in my tests I've launched SS-N-27s from well over 50nm (Sink the Nimitz mission), they were detected by SPY while climbing and engaged if FC radar could detect them. By the time SAM arrived, the SSM was again low under radar horizon but this didn't prevent SAM from hitting and destroying it.) The only thing that prevents this now is probably not too great FC radar range.
Try to launch your missiles from over 50nm. I know it's not very game-like scenario, but then you could observe true radars performance against true low flying targets, after gaining this inf you can return to game scenarios (so missiles launched from 20-30nm).
Also if you want to observe FC radar performance, try to disable SPY radar in database and rely on links for initial detection, then first DbgView report would be from FC radar.
Hmm it's interesting than in your tests ships waited untill target was ID hostile. I never observed that (or maybe I had only "detect" filter set in DbgView ?? :hmm: :hmm: )

[LuftWolf]

That was my testing procedure as well, Amizaur. I have achieved the same results (which is good because we are using the same files :) ), although the FCR's included with the 2.02 Mod won't detect the missiles beyond 22-25nm at the absolute most because the detection curves are 91,000m-100 and 9,100-1, so a 50 FCR missile will show up around 45,000m at the farthest.

I have sent Molon my test scenarios to see what we can find out about why his ships were waiting for posID... I think it may have had something to do with the setup of his test scenarios, but I can't figure out what. :hmm:

[Amizaur]

Well, I suspect that the det curves are NOT linear, because in my tests a SL=50 missile was always detected at a range corresponding to det curve value of 5, not 50! :-? But this missile was really probably 40 (front aspect -10) and detection was affected by low altitude and sea state.
Anyway it's quite confusing and I plan extensive tests that will clear this all definitely (starting at high alt, measuring aspect effect, plotting det curve value/SL dependance, measuring effects of low alt and sea state for sea skimmers, combining it all together).

[LuftWolf]

Well, I sleep well at night because I don't do math. :lol: :-j

[Deathblow]

Re: Sub evasion doctrine. I've witness several incidents in littoral ASW missions where the new sub evasion doctrine is causing the subs to bottom out and run aground. Happens about 40-50% of the time in waters less than 100 meters deep.

Anyone else confirm this behavior. Sometime the behavior can be written off as role-play with the sub purposely sitting on the bottom to spook the torp, but most of the time is pretty much a nosedrive at 20knots into the seafloor with the sub scrapping the ground trying to obtain flank speed.

To witness the behaviour I recommend the mission FF Gatekeeper and watch the Oscar and/or Trafalgar when evading torps.

[LuftWolf]

This is a feature of the original doctrine as well. AI submarines don't handle gradual inclines very well starting from stock SC onward.

All I have done in the modified doctrine is alter the evasion angle off of the bearing of the torpedo and instructed the subs to always drop an active decoy.

As I said in the readme, this doctrine in particular needs a lot of work, but I wanted to "quickfix" it to give the AI subs SOME chance of avoiding any torpedo, and the result has been to increase their effectiveness pretty dramatically, if you take into account the fact that I just changed a few numbers and swapped one word.

There could also be some issue with the anti-cavitation routines put in the doctrine, but this has been in the Mod for sometime and we haven't noticed any problems.

Thanks for bringing this up though, because there is something that needs to be done to help with this problem. :up:

[LuftWolf]

Just to be sure it wasn't the anti-cavitation routine the Mod uses, I tested the stock SubAvoidWeap doctrine, and the same grounding problem exists, so it isn't anything we've done, just something we haven't fixed yet. :up:

[Amizaur]

Quite simple to check - replace SubAviodWep doctrine by standard one and play the scenario again. BTW Luftwolf have you checked your doctrine changes with SCDoctrineChecker ? To check all spaces, quotes, bracket balance ect. ? Original doctrine shows 8 errors and your 16 :-/ I should have checked it :oops:

P.S. I hope they are caused only by no space after ;
Nope, your comments were causing that... strange, were interpreted as commands somehow... taking them into quotes helped. Don't know if the same happened in the game, maybe not (checker is sometimes more restrictive than original SCS doctrines) but it's good to try avoid such possible errors. Worse when DoctrineChecker don't show anything but game interpreter has problems, MUCH harder to find :-/
I seen this only once, when I had keywords and calcs in comment, they were tried to be taken as commands... but usually don't matter what's in the comment, whole lines of code are disabled by adding ; before them :hmm:

[LuftWolf]

Yes... :-?

I mean no. :oops:

Well, all I did was change some numbers and add a couple comments to the CIWSAttack and SubAvoidWeap doctrines and then tested the heck out of them in game... I specifically didn't add any clauses or anything because I don't have a programming editor on my computer that adds those nice color codes, plus I dropped out of my programming course in college. :lol: :oops:

In any case, I was very very careful not to do anything that would necessitate me dealing with syntax and then I tested everything in the game, so we shouldn't need to worry about it, but in the future I will do that when I change anything. Thanks for reminding me. :sunny:

[LuftWolf]

Yes, I just checked them as well, it is caused by the lack of whitespace after the comment, all eight of them.

:damn: :damn: :damn:

Still, it won't effect the operation of the doctrine in game... I think.

[LuftWolf]

Ok, so we are ok...? :up:

I have tested these doctrine a bunch, and there have been no problems, so I think the interpretor is ok with my comments.

[Amizaur]

Are you sure ? I added the space after ; (I have no spaces after the comment txt anywhere :hmm: ) and still showed errors. Will check again.

:hmm:

LegCourse = ( TgtBrg + 100 + rnd 40 mod 360 ) ; LW edit to 100 to 140
*** Unknown word or variable present ***
*** Unknown word or variable present ***
*** Unknown word or variable present ***
*** Unknown word or variable present ***


But moving whole comment to next line helped too :) I usually use them this way (in separate line)

[LuftWolf]

I ran the SC checker on a some of the stock doctrines just for the heck of it, and it returns errors all over the place.

I think there are some things that have been modified and added in the DW interpretor that the SC checker doesn't account for.

[LuftWolf]

Yeah, the doctrine checker doesn't like comments on the same line as commands, regardless of whitespace. the DWInterpretor seems fine with it however, or the doctrine changes I have made would cause a total failure of the doctrine in the tests I've done, and I tested every effect after I made changes.

So we are in the clear on that issue.

Time for some football! :rock: ;) :lol:

[Amizaur]

Because it's SC checker, not DW :)

But when you learn first what errors are "legal" i.e. showed even on original DW doctrines (new keywords for example) then checker is VERY!!!! helpfull in finding new ones !! I usually check how many errors were before modifications and after, if number is the same then usually OK :).
If my doctrine shows more errors, then I check if those are real errors or caused by checker/DW incompatibility. In 99% of cases it turns out to be my error (something unbalanced, no space, ect.). Couldn't work without this tool :yep: I hope jsteed will relase DW version.

[LuftWolf]

Doh! We are posting past each other. :lol:

[Deathblow]

Just to be sure it wasn't the anti-cavitation routine the Mod uses, I tested the stock SubAvoidWeap doctrine, and the same grounding problem exists, so it isn't anything we've done, just something we haven't fixed yet. :up:

Hm.... how to fix this... :hmm: It might be with the subs preception of the layer in the SubAvoidWeap doctrine, or maybe the minalt settings.

In the stock SubAvoidWep doctrine

; Set Depth Opposite Layer
IF TgtAlt < LAYER THEN {
SETALT ( -100 - RND 50 )
} ELSE {
SETALT ( LAYER - 100 ) ;set depth to 100 ft below layer
} ENDIF

It could be a layer problem. In the FFGatekeeper mission, the seafloor is at 200meters, but an XBT launch will report a layer depth of 300meters. Perhaps the AI is trying to set its evasion depth to an obtainable layer depth.

But in the modded doctrince...
; Set Depth Opposite Layer
IF TgtAlt < LAYER THEN {
SETALT ( -600 - RND 50 )
} ELSE {
SETALT ( LAYER - 400 )
; set depth to 400 ft below layer
} ENDIF

; Setalt ( ( MinAlt / 0.3048 ) + 100 )
; DebugOut "MinAlt + 100 feet set"

Seems like it could be the same problem. The AI might be using a layer depth that is actually below the seafloor depth. It probably happens when part of the map is above the continental shelf and the other part in the open ocean.... The AI might be using a layer thats inappropriate.

Perhaps another IF statement could remedy the problem...

IF MinAlt > LAYER
Setalt ( (MinAlt / 0.3048) + 100)
ELSE
IF TgtAlt < LAYER THEN {
SETALT ( -600 - RND 50 )
} ELSE {
SETALT ( LAYER - 400 )
; set depth to 400 ft below layer
} ENDIF
ENDIF
Just guessing for now.

[LuftWolf]

I've also not ruled out the possiblity that the combination of a hard-turn plus rapid acceleration might be making the subs drift deeper, just as happens with player subs as well.

To test whether it is a layer or not, you could set the environment type to be bottom limited, thus removing the layer entirely.

I should test this.

[Deathblow]

One question. Is SETALT measured in feet where MinAlt is measured in meters? Trying to understand why the MinAlt is divided by 0.3048.

Oh, and does anyone know what "TgtSilos" controls?

[LuftWolf]

Nope, its not the layer issue, because even in Bottom Limited environment the subs ground. :hmm:

One question. Is SETALT measured in feet where MinAlt is measured in meters? Trying to understand why the MinAlt is divided by 0.3048.

Oh, and does anyone know what "TgtSilos" controls?

The doctrine is fed information from the game engine in meters, but all doctrines are interpreted in feet, so... :dead:

In terms of TgtSilos, I have *no* idea at all. :stare:

[Deathblow]

Just ran a test of the above missoin with bottom limited conditions (Layer = 0meters). The sub still ran aground.

Then again, it still might be a layer problem. Isn't the default evasion depth set at 400 ft below the layer? So in a bottom limited sea, (layer =0 ) would that make the AI got to 400ft no mater what?

More testing coming.

[Deathblow]

Ran more testing with a default depth shallower. Sub still bottomed out. I agree, it just might be that that subs can't make the turn without loosing that much depth.... :hmm:

Maybe the solution is to change the mass the AI subs, so that they won't dip when turning...

Makes it hard to simulate a littoral combat environment when the AI captains don't even know how to drive their boats. :dead:

[LuftWolf]

Or the mission designers could set the depth of their AI subs shallower... perhaps no less than 30-40ft off of the bottom, except when absolutely necessary.

[LuftWolf]

Hey guys, we can change the acceleration of the subs and FFG by altering the drag value for each platform. :rock:

What do you guys think? ;)

[Deathblow]

I always thought that the acceleration/deceleration curves in the game were a bit too steep. Sounds like a good idea to me.

Only thing to worry is if the drag increase will make the ships stop even quicker than they do now. It would be asymetrical if the ships took 2minutes to reach speed, but only 20seconds to go from top speed to standstill.

What about prop efficiency in the thrust dialog menu... does that influence acceleration?

[LuftWolf]

None of the thrust values seem to effect acceleration and deceleration... but we can do it with the object masses, I believe. :up: :|\