ADCAP has 10nm of wire measuring from the launch point, UGST has 13.5nm of wire. But as real submarines are saying, in real life engenament ranges between modern subs are much shorter than wire length :-) Only in game, because of long detection ranges, we can make so loong shots.
Wire length could be a factor probably when taking long shots against noisy surface units, probably slow and unaware (civilian?) because fast military ship could try to runout a torpedo at ranges outside 10nm if he got warning in time...
Molon - range is 15nm, torpedo tube doors are open. You try to shutdown torpedo. In stock game - you succeed. In mod - you succeed. What's the difference ? In both cases you have same situation. Only with mod it's litte more realistic, because you can't resteer your torpedo at that range, but the realism of shutdown possibility is EXACTLY the same.
I could say, stock game wire realism is 50% (torpedo tube doors cuts it, possible enable disable and course steering, wire length unlimited, shutdown possibility unlimited).
Mod wire realism is 80% (torpedo tube doors cuts it, enable, disable, sensor mode, course, some depth ansd speed steering possible, range of steering limited, shutdown possibility unlimited).
LW - I think the long range of wirewatch sensor is unneeded, as you only need to detect one target once - the ownship at 35yds. Later it's unneeded completly, and it would be even better if it WOULD NOT detect anything other till the end, right ? Rejecting of false targets probably should stay, but not having in game (especially MP) multiple sensors of great range, detecting nearly everything every few seconds, even if does nothing wrong for doctrine working, it's not very good for cPU cycles and net bandwith requirements probably... maybe not for fast computers and fast networks, but it's not an elegant solution from programmer's point of view
. Try to make it 50yds sensor and see if it works. If works, then I think it's better if it don't detects everything else ?
As for torpedos circling and not slowing down to 40kts. When something is going on on my computer ONLY, and no one else experiences it, then probably something with my comp or my game install is wrong. Not a game or doctrine bug.
But when for most people everything is fine, but for few some strange and same things happen, then it's something with the game or with the doctrine. And even if it's something with the game itself (and NOT a doctrine's fault - command is given, but game ignores it), I can't fix the game but try to redesign the doctrine to workaround the problem. For example if sometimes game ignores a command, I take care to repeat the command instead of giving it once. If game ignores command with proper syntax, but accepts command with something added (MANPAD missile fix) then I make it to workaround the problem. So I think, even if something is happening only for some people, and for the rest everything is fine, we should try to do something with it if we only can.... hunt down the problem, try to workaround it. BTW when you saw circling torps in stock game - if you see this once again, try to check what's the state of circlemode variable is ? Maybe something strange is happening with it, or it is ok but the command that checks it is working wrong. maybe there is one more game error showing up even for standard DW torpedo doctrine ? And maybe we could think of something to fix it :-).
edit: ok, I know what is cause of not slowing-down torps. A bit strange, I tested both ATC demo doctrine and Lw302wATC doctrine, only with line modified to exclude visual sensor detections, and seen all torpedos slowed down immediately at passive enable. Reverted to TorpedoADCAPWire doctrine - first try and torpedo continues at 55kts after passive enable...
Not always, but often. I can recreate it every time, launching Barents Sea Loiter, launching and ADCAP at a ship (show truth on) from NAV map, waiting for it to turn and stabilise, and enabling it by single click. It enables but don't slow down to 40kts and seems to be long while before it starts to snake too.
Maybe the WireWatch and target detections by visual sensor are causing this somehow... Couldn't the visual sensor be just disabled after the ownship is detected ?? And care taken to not enable it again ? Maybe it would STILL work, just like for reduced range sensor ?
edit2: decreasing visual sensor range to 60yds didn't resolve problem. Removing visual sensor completly... and the problem disappeared !!!
So it's connected with this sensor somehow, but not with it's detecttions (there were no new detections when range was reduced to 60yds)... or with WireWatch doctrine ? Now I'll try to disable the sensor at start, so sensor will be present, but wirewatch doctrine never initialised...
Yess. Disabling at init didn't work, so I just added visual sensor disable at the end of the doctrine (near the shutdown part). WireWatch never initialised. No problem with torpedo speed - slowed down to 40 after passive enable. So the problem is somehow connected with Wirewatch doctrine. But is fixable by either adding setspd commands just after preenablespeed=40 command, or changing setspd to one global command localises near the end of the doctrine (near shutdown part).
end of edit2 :-)
The original torpedo doctrine repeated setspd command every second for non-enabled torps. After enable, setspeed repeating stopped. we added only one speed change command at enable. well seems sometimes one is not enough.
Two solutions, first is to add SetSpd Preenablespeed command after each speed change, so after changing preenablespeed value, commanding it immediately, not waiting for later more global one. So in enable part, not:
IF ( AcousticMode == 0 ) THEN {
PASSIVEENABLE
DEBUGOUT "Torpedo Passive Enabled"
DebugOut "Speed set to 40kts"
PreEnableSpeed = 40
} ELSE {
but
IF ( AcousticMode == 0 ) THEN {
PASSIVEENABLE
DEBUGOUT "Torpedo Passive Enabled"
DebugOut "Speed set to 40kts"
PreEnableSpeed = 40
SetSpd PreenableSpeed
} ELSE {
Or the other, more perspective solution - the setspd command should be moved to general doctrine area near at the end of doctrine, to be evaluated each time regardless of torpedo state. Only special SetSpeed (or something like that) variable value will be changed when needed, and one SetSpd SetSpeed command will set speed globally every second at the end of the doctrine. This is how it worked in my new torpedo mods (Advanced Torp Physics as someone called them... for me it's Very Basic Torp Physics
), although I made setting speed this way for quite other reasons there.
Still have no idea what circling torpedos could cause... haven't seen that personally... if someone can recreate it at will, please say, we can arrange DbgView session :-). Maybe the IF - THEN condition not worked properly or CircleSearchPattern variable was set wrong but why...?
edit2: a though - well, if there were separate AI versions of playable subs, with own weapons, many torpedo doctrines would be much shorter, because the part of checking if it's human player or AI launched torpedo would be unneeded. But that would require to play against AI only specially created missions with AI subs, problem would be also with MP missions with controllable but AI-driven platforms... pros and cons...
The doctrine avoid-shooting-friendly-surface-and-civilians-by-AI mod was developed originally as strictly doctrine-only solution, so it can be used on stock game database. Database editing gives new ways of dealing with that... but everything at a cost. Doctrine only solution at a cost of doctrine complication (I'm not sure to this day how serious problem or problem at all is this, have to run someday a game on slow computer with simple and complicated doctrines and compare framerates), database solution (separate units for human players and AI) at a cost of not-global effect and working for dedicated missions only (forget mod effects for all original and pre-mod missions as long as someone doesn't redesign them... and then those redesigned missions would not work for stock game if someone wanted to play MP on pure DW...).
To SCS - the fact that doctrine commands are definitely IGNORED sometimes, makes me more and more p!@#$d with time, as more cases of it shows up. When, when someone will take a look at doctrine language (doctrine language interpreter?) and check WHAT's WRONG WITH IT ?? Some cases of command ignoring are happening randomly, but some are are easily observed and 100% repeatable !!
