SUBSIM Radio Room Forums

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)
-   Dangerous Waters (https://www.subsim.com/radioroom/forumdisplay.php?f=181)
-   -   One more thing to do for LwAmi 4.0 (https://www.subsim.com/radioroom/showthread.php?t=94467)

LuftWolf 06-16-06 12:06 AM

Quote:

Ok, here's the problem, I have to keep the range of the APR consistent with the range the AI should be firing them at. If I have the torpedo start out its already limit range at a slow or very slow speed, it will eat up a large amount of its already limited range and then when it fires its rocket it will shutdown almost immediately. Also, given the fact that the ***torpedo doctrine cannot undergo a state change when newtrack*** I can't do the terminal homing speed mod, at least not on target tracks if we want the torpedo to slow down again.
Then again, there is nothing saying that the APR can't be modelled as a "oneshot" weapon, it doesn't really have any kind of range to be reattacking anything... and in fact this is how it works in real life... So perhaps I could start it out at something like 50kts, and only set maxspeed on newtrack... in this case, the loss of range on slow speed would be somewhat limited.

However, in regards to the other torpedoes, the margine of error for the data on all the reports is larger than the current values, in other words, the cost to benefit both from the player perspective and the design perspective is simply not there, especially because I believe a slightly higher homing speed than reported is a reasonable compromise for not being able to have a genuine sprintout feature.

Cheers,
David

LuftWolf 06-16-06 02:53 AM

Ok, I've got the APR working the way everyone wants.

It's a pretty lethal torpedo, but can easily be outmaneovered if you are able to place a decoy and then clear the very small datum it is capable of attacking. After torpedo speed up on newtrack, it's not likely that it will be able to reattack anything but its first target, but if you remain dead in its path, your likelihood of being tagged again is good the torpedo is headed dead at you. In my testing, I saw a SW drop a decoy on a Stallion launch, the APR hit about 2500 yards in front of the decoy and helixed forward, after picking up the decoy the torpedo speed up to 69kts and moved in on the decoy. The SW was clearing the missile launch, not the torpedo itself, so it was not on a good position to when the torpedo finally hit the water and was somewhat behind the decoy on the torpedoes vector.

After burning through the decoy, it detected the submarine again (I haven't done the 3-d seekers yet or disabled the research functions yet for the APR, but the last one is easy work, I just have to restore the bug from the SC doctrine :p ) and although it had some time to go deep it wound up passing right over the SW at about 600ft.

Although, I've also seen other SW's that didn't react to the missile launch get totally blown away. :)

LuftWolf 06-16-06 03:52 AM

I also have the option of forcing the torpedo to ignore anything but its first track, which is plausible since it could possibly use a medium aspect seeking active sonar and a very high intensity yet very narrowly focused homing active sonar seeker, in which case it would stay deadlocked on the first target and totally ignore other targets, but the initial target could still out maneover the torpedo.

In this case, avoiding these torpedoes would simply be an issue of making sure there are some decoys between you and the torpedo, but on the other hand, if you get caught unaware with an on target shot, you are mostly likely dead.

It's up to you guys.

However, since I can't shutdown the sensor without having the torpedo lose its track and thus not work, right now the torpedo is too easy to decoy after it has gotten the correct target initially. So I'm going to make this change.

Keep in mind the torpedo is going to be limited in range and seeker, so it rewards very good shots, rather than spray and pray tactics.

Amizaur 06-16-06 05:38 AM

Hey LW

I have to read everything once again later, but few words now...

About limited APR range, that slow movement mode eats - well, it shouldn't as range in DW is range limited not time limited... so making 1nm at slow speed eats only 1nm, not more. Second thing is that best solution would be to set range in excess in db and control range limits from doctrine, by fuel calcs. Slow mode at start (10kts for example) would not use fuel at all, and would be noiseless too (by db thrust profile). Of course the slow descent while searching is useless when you are modelling it as straight running torp, then best option then is to run at max and search forward.... I doubt APR can use different speeds than max, after it ignites it's solid fuel engine, it can't reduce it or disable, it probably runs only at max after ignition.

Back to the real circling mode - the only problem I see to implement it in DW is that APR with 68kts max speed should have turn radius increased to ensure smooth running. With increased turn radius it would take it looong time to make full circle or few full circles at 10kts. On the other hand you wouldn't hear it... but it would take very long time to do the circle search. The solution would be to give it two sensors... in fact even more than two (like in SCX's ADCAP). Well take a look at SCX ADCAP and it's doctrine. First "sensor" would be all-around, divided into 6 separate 60deg sensors, each looking at different side, all together giving 360deg coverage. The weapon would be set to 10kts (it could be set that it's minimum speed with zero noise is 10kts in thrusts profile) and dive straight down (it already points down after drom). Sensors would be enabled in sequence to search all around in some time. When target is detected, torpedo sets full speed and uses last homing sensor (normal one, forward looking) to home at it. Complicated, but should work just like SCX's ADCAP worked - Thomas emulated beam forming and searching not instantly whole cone but narrow parts of it sequentially.

About active search speed limit - where is the problem ??? This function was already implemented in my doctrines. In various sources (some of them are in "recommended reads") I found suggestions that max range search is done at reduced speed, to reduce sensor washout. Modern torp sensors can work at max speed, but it's range then is always tradeoff, not as long than at slower speed. So sprint at max speed to enable point, slow down some to get good sonar pefrormance and search, and after lock, if you have no problem in keeping it, it may speed up again... can you check range to tgt from doctrine while homing ? I'm not sure... is target only valid when newtrack ? I forget that... Well if yes, then torpedo would speed up to max just when homing, not in last 1000yds or so. Only for active search it would slow to MaxActiveSpeed, after acquiring tgt it would again go max speed. Simple and shows that torp has something :-). And yes, the 63kts max speed would give some "margin" in achieving 55kts at depth, it would be capable of 55kts down to few hundred feets probably.

P.S. Hmm why can't I change object type from torp to depth charge in DWEdit ?? grr... I wondered if a torp worked still if I changed it's type to depth charge, it should have negative buoyancy then... :-)

P.S. Please don't change weapon parameters (range) to make it better for AI !! APR is very short-ranged weapon. I's very very fast in exchange. I hope you don't plan to make it torpedo-ranged rocket-speed object, because such thing don't exist in reality and there are good reasons (physics) for it... If it don't work for AI with real parameters, then it's only possible to return to UMGT-1 torpedo, only "upgrade" it a little...

LuftWolf 06-16-06 05:49 AM

Perhaps in the future, but the diminishing returns are rapidly approaching for work on AI doctrines.

I need to finish the AI changes in the database and move on to the player torpedoes and sensors.

Refinements such as these are definately possible in the future, but I am personally up against my limits in some regards without taking some distance from the work and seeing it in operation. From the perspect of a designer, I need to see the whole prototype machine in motion before there can be any further changes to the design, this is strictly my own limitation.

Cheers,
David

LuftWolf 06-16-06 06:04 AM

Quote:

About active search speed limit - where is the problem ??? This function was already implemented in my doctrines. In various sources (some of them are in "recommended reads") I found suggestions that max range search is done at reduced speed, to reduce sensor washout. Modern torp sensors can work at max speed, but it's range then is always tradeoff, not as long than at slower speed. So sprint at max speed to enable point, slow down some to get good sonar pefrormance and search, and after lock, if you have no problem in keeping it, it may speed up again... can you check range to tgt from doctrine while homing ? I'm not sure... is target only valid when newtrack ? I forget that... Well if yes, then torpedo would speed up to max just when homing, not in last 1000yds or so. Only for active search it would slow to MaxActiveSpeed, after acquiring tgt it would again go max speed. Simple and shows that torp has something :-). And yes, the 63kts max speed would give some "margin" in achieving 55kts at depth, it would be capable of 55kts down to few hundred feets probably.
The reason this cannot be done is the same reason torpedoes used to run straight after losing their track without a detonation: the torpedo doctrine does not properly reference LostTracks from the TorpHoming doctrine (as worked properly in SC), of this I am very sure.

The good news is that we can program whatever we want in the main torpedo doctrine because it will be overridden when there is a track that is following the torphoming doctrine, and the main torpedo doctrine automatically takes control again when the torpedo loses its track and the torphoming doctrine shuts down.

To get around this is a major issue I'm not prepared to tackle at this point, and like I said, I think a higher than reported search speed for the best torpedoes is acceptable because we cannot model their top speeds properly for "sprint out" attacks.

Cheers,
David

Amizaur 06-16-06 06:05 AM

Yes, I understand entirely. It's a lot of work for single object. But maybe like in SS-N-27 ASM case, I'll take it and make APR sensors and doctrine (because it's an interesting task) and you could add then to 4.1 or something...

LuftWolf 06-16-06 06:08 AM

Make sure you see my last post before your last reply. :)

LuftWolf 06-16-06 06:09 AM

Quote:

Originally Posted by Amizaur
Yes, I understand entirely. It's a lot of work for single object. But maybe like in SS-N-27 ASM case, I'll take it and make APR sensors and doctrine (because it's an interesting task) and you could add then to 4.1 or something...

Yes, that'd be good, you are really better than I am at making very advanced features. :know:

LuftWolf 06-16-06 06:08 PM

Ok, some good news. The turn radius for torpedoes with their maxspeed set at 61 or less can be left at 100.

So only the turn radius of the APR family has to be increased (to 170), which is perfect, because this torpedo is not suppose to be all that maneoverable at top speed, which means even if it tags you, you can still escape.

In fact, I saw an AI SW evade one of these weapons in a test by out turning it... so if the AI can do it, I know you guys can. :)

As a side note, I've changed the thrust profile of the Shkval so that it has a reasonably low PSL when it is launched and then does not get very loud until it fires its rocket engine. Also, the APR family is very loud as well, especially at top speed, almost as loud as the Shkval, so combined with the fact that the APR-3S on the Stallion runs its search along a set vector, you need to be sure there is no one at some distance away tracking your torpedo to fix a distance on the missile launch transient and the path of the torpedo. Also, you need to be very accurate with your range estimate or you won't hit anything. However, if you get your shot right, you've got a very good shot of killing your target.

Cheers,
David

SeaQueen 06-17-06 07:16 AM

Quote:

Originally Posted by Amizaur
ADCAP ...................... 45 ........................ 20-25
UGST ........................ 40 ........................ 20
Mk-50 ....................... 35 ........................ 15-20
the rest * .................. 30 ........................ 15

* (playable USET-80, TEST-71, UGMT-1, MPT-1UE)

I am under the impression that the the vertical pattern of signal excess for a torpedo's sonar depends less on the beam patterns of the torpedoes and more on the sound speed profile. Hence, a searching torpedo in a surface duct of appropriate cutoff frequency might potentially detect anything in the duct out to a certain distance, one set below the duct might have a shorter detection range against targets on the same depth or above it, and a longer detection range for targets underneath it.

LuftWolf 06-19-06 11:06 PM

SQ, I believe there are absolute aperature limits on the vertical dimensions of the torpedo seeker along the lines that Amizaur is presenting... however, within the depth band of the seeker, what you are saying is correct, I believe.

Two more quick things I wanted to run by you guys.

I am changing the loadout of the FFG AI MH60 as follows: ASW will load 3 Mk50's, this configuration is for use in deep water; ASuW will load two Mk54's and one Penguin ASM for use in the littorals, and Strike will load eight Hellfires for use as strike missiles or ASM's, and I am changing the parameters of the Hellfire to allow these missiles to be fired more than one at a time, since now the MH60 can only have one Hellfire in the air at once, since it makes more sense in the context of the mod for the Navy to have the true fire and forget version of the Hellfire, so that's what I am modding (rather than the lazerguided version modelled now).

Also, I am thinking of restoring the range hardcap on the SW WAA array... SQ or anyone else, do you know if there are absolute range limits on WAA arrays that are worth simulating in the context of DW?

LuftWolf 06-20-06 01:11 AM

And, of course, the whole issue of bearing errors on the user sonars...

Amizaur, what do you think about having all TA's have a bearing error set at 1, hull arrays set at 2, and sphere arrays set at 3? (with a lower number being more bearing error based on settings in the database)

Cheers,
David

Amizaur 06-20-06 01:59 AM

Don't know, didn't tested it in gameplay... You can start with 2 for all, or go for 1 TA, 2 SA, no change or 2 for hull and see what happens in playtest
(hull arrays are rarely used but some, like WAA, have rather good bearing angularity :-) reducing WAA would increase it's range prediction error...

LuftWolf 06-20-06 02:05 AM

http://www.navweaps.com/Weapons/WTUS_PostWWII.htm

Quote:

Lockheed Martin has recently won a contract to adapt their LongShot® Wing Adapter Kit to the Mark 54. This is a discardable wing assembly that allows the launch of various munitions including mines and torpedoes from high altitudes and at long standoff ranges. Currently, ASW aircraft such as the P-3 have to make a time-consuming descent from their surveillance altitudes of 30,000 feet (9,100 m) to a release altitude of 300 - 1,000 feet (90 - 300 m) in order to launch a torpedo. Quoting from a 13 June 2006 Lockheed Martin Press Release: "The LongShot is a low-cost, self-contained wing adaptor kit that provides range extension and autonomous guidance to a family of existing air-to-surface munitions, including sea mines, gravity bombs, laser-guided bombs and tactical munitions dispensers. No aircraft modification is required to deploy a LongShot equipped munition. The system is completely self-contained, including a flight control computer, a GPS-based navigation system and power sources and does not require an electrical interface with the aircraft."


I think this is a good reason not to put limits on the torpedo or buoy launch at this point. Especially given that there are other balancing factors in place now for the Air vs. Sub game.


@Amizaur, so you think 1 for the TA's is too much?


All times are GMT -5. The time now is 08:03 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.