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

[LuftWolf]

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

Here is the readme:

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

[LuftWolf]

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

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

Cheers,
David

[Bill Nichols]

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

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

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

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

Complicated, ain't it?

[Amizaur]

Originally Posted by LuftWolf

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

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

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

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

or if the range between ownship and the torpedo exceeds that distance, the wire will break.

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

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

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

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

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

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

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

[Bellman]

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

Well done ! :|\

[Amizaur]

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

Cheers!

[Bellman]

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

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

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

[LuftWolf]

My pleasure to work with you Amizaur.

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

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

[LuftWolf]

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

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

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

Cheers,
David

[LuftWolf]

Bill, thanks for the information.

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

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

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

Cheers,
David

[LuftWolf]

Tony:

I think the "phantom" contact is actually ownship.

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

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

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

So, that means you guys.

Cheers,
David

[LuftWolf]

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

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

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

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

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

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

Cheers,
David

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

[Bellman]

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

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

[LuftWolf]

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

This is present with the stock game as well.

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

Cheers,
David

[Molon Labe]

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