![]() |
Quote:
|
Quote:
|
**** i may as well dl the replay as well...
|
Unless I am mistaken, the sub's tactic was to drive in a straight line at the same speed.
So, after reading your message Su88, what you are saying is if the torps I fired went from really deep to really shallow and then back to search depth, they might loose the sub? Well, I guess that's possible, but that has nothing to do with what happened in this dive. I launched from about 500 feet, layer was at 550 or so, target was above the layer the whole time. I set search depths for active torps at 700, 600, 500, and 200. Passive was set at 200. So there was no parabolic climbing and diving by the torps, most were above the layer the whole time. Like I said, still looking for a reason... |
Quote:
With LWAMI, not stock as in the replay. |
If this doesn't cut it I don't know what will:
http://subguru.com/BluebookR20.zip Refer to page 38, section L - Blue Defense I'd say someone was doing their homework - and someone else forgot to... again.. tactics IS tactics.... |
Quote:
|
Quote:
i give up! besides i found some bugs in beta testing.. i think id have a far better chance resolving those than my chances resolving this one.. either inform SCS about it for a clear understanding... or spend the rest of your natural lives figuring it out.. good luck |
Would be too much to ask people to just stop using the tactic? It's dubious at best...so...with a little self-constraint...DON'T DO IT! :stare: Or do...see if I care. :smug: But remember...you're not a fellow navy-simmer in my eyes. Just a small, wet, sardine.
|
the incoming torps did to lock onto the mine.they did not detonate on the mine.just becasue of the net laggs problem,before swim's torps enable,I have fire 4 missiles to him,only 2 to him there,another two are not normal,disappear.this is why his torps not detonate on my mines.
on the normal situation,if the net is normal, his torps should lock onto my mines, and can detonate on the mine. |
Quote:
I'm glad you stopped by here. How does this work? |
I never saw the torps lock onto the SLMM, perhaps I missed that in the replay?
I too don't see signs of lag, but maybe I am missing that? I am very open to learning about this valuable new tactic, although it doesn't seem to be one I can reproduce. I can't get the torps to just keep going by my sub in search mode, they either lock onto the SLMM or my sub.:down: EDIT: Oh, and if all the SLMM does in this tactic is make a torp lock onto it and explode, according to the Bluebook, isn't that what an active cm does in stock 1.03? Why would you launch a slmm to decoy a torp, but knowing that you have 5 torps in the water, all on your bearing, all within 1.5nm of you, why would your only tactical move be to: (1) drive in a straight line at a set speed (2) launch 1 slmm (3) drive right in front of the slmm until torps miss you. Is that what it says to do in the Bluebook? Someone wrote a document that gives this scenario as how to avoid torps? Funny, I did my homework and read the whole section on Blue Defense, couldn't find anything like that in there. Could someone tell me what page that is? So we are all agreed then that the above tactic (drive in straight line, maintain speed, launch 1 slmm) is a standard, published, commonly used tactic that works for everyone? And it should work for everyone, easily reproducible? Hmm, I better read that book again... |
Quote:
|
That's a very good point about the Bluebook tactic, Swims. Attracting several torps to your exact location by using a mine as we have seen would be suicide. In fact, the Bluebook calls for you to leave the mine behind, not to run it just behind you. For this reason, I'm very skeptical about Worker's explanation that his goal was to get the torpedoes to acquire the mine. Of course, dishonesty is not the only explanation for this, it might just be a mere tactical error that he survived because of a lag problem.
Since Worker posted that he believed the odd behavior was connection related, I've re-reviewed the replay in question. Of all the anomalous replays I've seen, this looks like the most lag-free. But, upon closer examination, there are a few signs of minor lag that begin to come in once the torpedoes are enabled. Specifically, Worker's sub warped four times during "evasion." I am a bit reluctant to accept lag as an explanation, because I've never known lag to prevent acquisitions (quite the opposite, I've seen lag cause a sub to be killed where the host computer thinks that sub is, even though the skipper changed course awhile back and was not in that position! the weapon "acquired" just fine! I've also seen connection problems cause weapons to acquire but not detonate...again, not what we see here). But, since I haven't been able to reproduce this on my own, it may well be the case that there was something unique in that game, instead of a doctrine problem. Unless we are able to reproduce the behavior and/or find a specific bug in the doctrine that is being exploited, I'm content to accept lag as a reasonable explanation for this behavior at this point. |
Fine by me, we call it a lag issue.
That sounds better than "this is a tactic that's in the Bluebook".:rotfl: McFester used to have lag problems all the time, and, as you mentioned, what usually happened was that he died, but he showed himself as alive for another 5 minutes. Ok, I'll just dive against people that don't have lag issues! |
All times are GMT -5. The time now is 08:05 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 1995- 2025 Subsim®
"Subsim" is a registered trademark, all rights reserved.