View Full Version : Algebraic Firing Solution
An alternate method for torpedo firing solution:
I made the computations for this method some time ago when I was playing SHCE. I've used it quite a
lot in that game, but also in SH 3 and SH 4. It will work with any SH game and does not rely on any game
exploit. I became interested in this after reading the S class boats did not have any TDC, and had to make
use of other methods for obtaining a torpedo firing solution. I know others have made use of similar
solutions, so I thought I'd post my version.
For those who have only used the in-game TDC, this type of method is fundamentally different. It
involves calculating a firing solution for the target as it reaches a discrete point, whereas the TDC
allows continuous updates of the firing solution. This means with the USN TDC, one can launch at any point;
the sub can change course and wait until a more favorable track is obtained, increase speed, etc., etc.
None of this "breaks" the solution. Not so with this method. It is like the difference between methods of
lead in duck hunting; continuous tracking allows the shot to be made any time after proper lead is
established, whereas "trapping" (aiming at a point ahead) requires the shot to be made at the moment the
target reaches the calculated point.
So, if this method is more limited, why use it? This is a fair question. The main reason is
realism. The S class did not have any TDC and had to use some sort of calculation method, such as the Mk
VIII angle solver. Unfortunately, we don't have this in the game. [It should be noted here that the
difficulties involved in using the Mk VIII angle solver, lead to the development of the TDC, and was a big
step forward in fire control.] The other reason I use this method is just because it is both challenging
and interesting (at least to me), to do it this way. It gives one a deeper appreciation for the Torpedo Data
Computer.
This method requires the gyro mechanism be set to fire straight ahead (or behind), and a
longitudinal spread be used, if any.
The method is simply four equations for calculating the following:
1. Lead Angle
2. Time to Position
3. Track Range
4. Torpedo Run Time
Some would consider only the lead angle to be necessary, but I feel that the track range and
torpedo run time should be known in any proper method. The time to position is not necessary, but is
helpful in practice. Knowing this allows one to lower the periscope, instead of leaving it up waiting for
the target to reach the firing bearing. The track range not only provides a run time for the torpedos, but
also gives one an idea of the quality of the set-up, and allows a change in plan to obtain a better range,
if that is indicated. Of course, the torpedo run time provides an indication of whether the torpedos hit
the target, or just exploded somewhere out there. (It also tells you how good your plot and data were.)
Below are the equations used:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/Equations-1.png
To utilize the method, you must have all the usual elements of firing data, the range, the bearing
angle, the track angle, the target speed, and torpedo speed. Many will notice I didn't mention the angle on
the bow. This is because it is implicit in the track angle. If you know the track angle, you can get the
AoB. If you know the AoB, you can get the track angle. They are really two halves of the same coin. I
originally derived the equations in terms of the AoB, on the theory that I might want to make an attack
without plotting, in an emergency, but in practice, I did not use them this way. I played around with them,
trying to put them into a more intuitive or simpler form. Finally I altered them to use the track angle,
since USN documents use this more often. One form is not really better than the other, but I think using
the track angle is a little less confusing than using the AoB.
It doesn't matter how you obtain the data, as long as you have it. Naturally, the more accurate it
is, the better your firing solution will be. Garbage In Garbage Out, as they say.
Here is an example to illustrate:
[Note that the diagrams are not to scale, and are just to help illustrate the concept.]
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/Diagramfinal1-1.png
In this example, the final observation is made with the sub at U0 and the target at T0. The
calculations are made with the Range (T0 to U0), the Track Angle (Angle T3_T2_U0) and the Bearing Angle
(Angle T2_U0_T0). The torpedo(s) are launched when the sub is at U1 and the target at T1. They impact with
the target at T2.
Let's say you have been tracking a target and have good estimates of it's speed and course. You
have turned on to your attack approach course and do not intend to change speed. It is important to
understand that the calculated firing solution is rendered invalid if you change course or speed before you
launch your torpedos. The same goes, if the target should happen to change course or speed. You get from
your final observation:
Torpedo Track Angle__________________________ 135 deg.
Bearing Angle*________________________________ 94 deg.
Range to Target____________________________ 2,600 yds.
Target Speed___________________________________ 9.5 kts.
Sub Speed______________________________________ 2.0 kts.
Torpedo Speed_________________________________ 30.0 kts.
*I deliberately used the term Bearing Angle instead of relative target bearing. Relative Target
Bearing, 266 deg., Angle T2_U0_T0 (measured clockwise) cannot be used, instead the Bearing Angle, Angle
T2_U0_T0, (measured counter-clockwise) must be used, (i.e. 360 - 266 = 94). If in the above example, the
target was to starboard (right), the Relative Bearing 94 deg. could be used without alteration. But, when
the target is to port (left)
, the Relative Bearing of 266 deg. will not give correct answers. This is
because of the sine function. In this case the bearing angle is 360 - Relative Bearing, and the Firing
Bearing will be 360 - 16.1 deg. instead of 16.1 deg.
Doing the calculations yields:
Lead Angle____________________________________ 16.1 deg.
Time to Position_____________________________ 582 sec.
Track Range________________________________ 1,757 yds.
Torpedo Run Time_____________________________ 104 sec.
Using this solution for an attack, one would turn the scope to 343.9 or 344 deg. bearing and launch
on the target when it reaches that point. Spread the torpedos by launching on different sections of the
ship as they pass by. The time to position tells you it will take 582 sec. to reach that bearing. In
theory, you could submerge and fire at that time, without any visual observation, but I have never tried to
do it this way. Using the scope with a visual reference reduces the effects of errors which are likely to
be present in the data. If the time to position is significant, as in this case, one can make use of the
time by refining the estimates of speed and course, or plotting out alternate attack approaches, rechecking
calculations, etc. If the target reaches the firing bearing too early, or late, it is an indication that
either the calculations or firing data are in error.
Back to our example. Let's say you don't like the set-up and want to get closer. Using all the
above data, except the sub speed, which we increase to 11 kts., and doing the same calculations we get:
Lead Angle____________________________________ 16.1 deg.
Time to Position_____________________________ 858 sec.
Track Range________________________________-2,897 yds.
Torpedo Run Time_____________________________-172 sec.
What! Negative range? Negative time? I know what your thinking. What kind of torpedo voodoo is
this!? Before you turn off your computer in disgust, let me explain. It turns out that if the sub in
question goes on this track at 11 kts., it will cross the target's track in front of the target. In other
words, there is no bow shot in this set up. (If you were plotting this out in the game, you would probably
notice this before you did the calculations. If your just pulling numbers out of your hat, you probably
would not. Don't ask me how much time I wasted because of this.) However, this brings up another question.
What if we want to make a stern shot? Can the equations be used to do this? The answer is yes, but we must
make a few changes in our procedure.
First, we must cross the target's track before we can get the proper data. The geometry changes
when we cross the track, so the initial data will not give us the correct answers. We can make our final
observation the moment we cross the track, if we want to, or any time after. As a side note, I should point
out that the collision course speed in our example is 6.25 kts. Below this speed, the target will cross in
front of the sub, above this speed our sub will cross in front of the target. We should choose a speed
significantly above or below this value.
Collision Course Speed = Vt * [sin (alpha - theta)/ sin theta]
This is what the set will look like for a stern shot:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/Diagramfinal2-1.png
This is the same original course and target data, but with the tracks extended.
So, if we do the math, we find with our first example that at 11 kts we will cross the track after
390 seconds. As I said we can make our final observation now or anytime after. At 490 sec. after our
initial position we find:
Torpedo Track Angle____________________________ 45.0 deg.
Bearing Angle*_________________________________ 28.6 deg.
Range to Target_____________________________ 1,549.6 yds.
Sub Speed______________________________________ 11.0 kts.
*Relative target bearing is 208.6 deg., we must use 28.6, (208.6 - 180 = 28.6).
All other data is the same as before.
Here are the changes we must make in our procedure:
We must consider the geometry from the stern of the boat. (Pretend the stern is the bow here.)
1. torpedo track angle changes as we cross the track. The geometry is such that the track angle for
the stern shot is 45 deg.(angle T3-T2-U0). This is the supplementary angle to the original track angle,
(i.e. 180 - 135 = 45).
2. The bearing angle as taken from the stern. (Angle T2_U0_T0).
3. We must use the negative value of sub speed, - 11.0 kts. (We are moving away from the target's
track now.)
4. The lead angle obtained is also from the stern. (Angle T2_U1_T1, firing bearing = 180 +/- lead
angle.)
Here is the data for our calculations:
Torpedo Track Angle___________________________ 45.0 deg.
Bearing Angle*________________________________ 28.6 deg.
Range to Target____________________________ 1,549.6 yds.
Target Speed___________________________________ 9.5 kts.
Sub Speed_____________________________________-11.0 kts.
Torpedo Speed_________________________________ 30.0 kts.
Crunching the numbers, we obtain:
Lead Angle____________________________________ 10.4 deg.
Time to Position_____________________________ 117 sec.
Track Range________________________________ 1,342 yds.
Torpedo Run Time______________________________ 79 sec.
So, with this we rotate our scope or TBT to 190.4 deg (180 + 10.4) and wait for the target to cut
across our sight.
I tried to use precise figures in the examples so anyone who wishes to can make a scale drawing or
otherwise check the math. If there are any doubters (I suspect there will be a few), the easiest way to
check is to consider the length of the relevant triangles and use the Law of Sines to calculate the
numbers.
Some might consider a method which requires calculations or this sort to be cheating. But since we
have no Mk VIII angle solver, we are left with the choice of either using the game TDC (obviously not
ideal), or some method of our own. This method brings limitations which are, at least, somewhat comparable,
to what one would have using a Mk VIII angle solver.
Claves_Mortis
12-23-12, 06:08 PM
So gorgeous! :yeah:
A good explanation with neatly arranged pictures, thanks for your afford and time to share.
This is great. I enjoy playing this way as well. I have done all the math and created tracking spreadsheets in my iPad Numbers app to do similar things.
The first I have is a target tracking spreadsheet into which I feed observations on target and own sub position, and it tells me the target's course and speed. Only plotting own sub position is required.
The second spreadsheet I have calculates optimal (minimum time) intercept course for the target or any point I choose relative to the target, using only results calculated by the first spreadsheet and my chosen speed to intercept. It also tells me if an intercept is not possible at a given speed.
Using the two, you could actually intercept and sink a target in the least amount of time without ever plotting the target's position. I've never tried to intercept "blind" like that, but you could. Maybe I'll try it and record a video.
And with your equations you could also set up your firing solution.
I could try to figure out a way to share the spreadsheets, or even just the math. I could also put your equations into one of the tabs.
What would be extremely cool is to find a way to auto-plot the data entered into the first spreadsheet. I find the plotting to be tedious and it adds a fair bit of error into the solution.
Also: in a third spreadsheet I've attempted the math to solve for target's course using the "three bearing method", but with the advantage that you don't have to take the bearings at fixed time intervals which gives you the chance to be more precise and get a better solution. You do have to be stationary though, which I find is rarely practical. I'd like to do the "moving sub" version, and also add the fourth bearing to determine target position and speed as well, but I don't know the math for those yet.
Dorjun Driver
12-24-12, 05:50 AM
Very nice.
Onkel Neal
12-24-12, 09:49 AM
The time to position is not necessary, but is
helpful in practice. Knowing this allows one to lower the periscope, instead of leaving it up waiting for
the target to reach the firing bearing. The track range not only provides a run time for the torpedos, but
also gives one an idea of the quality of the set-up, and allows a change in plan to obtain a better range,
if that is indicated.
That's supremely important, and I always read accounts where the skipper would determine the initial setup and on subsequent observations, determine how true the solution was, and make adjustments to fine tune it in.
Very well done, I rated this thread as "Excellent" :salute:
Thank-you for the compliments. :sunny:
To be honest, I wasn't sure if this would interest anybody, or if it would be in the catagory of "we already knew this".
msumpsi
12-25-12, 06:44 PM
That is a beautifull piece of mathematical work done there, and sure that these were the kind of things the guys that worked on the TDC were doing.
But honestly, do you think the skippers had those equations in mind in the middle of a real patrol and playing with their lives? To start with, you need a calculator to solve the angle equations, which were non existence, or the TDC which was their calculator. It you want to be realistic and not use the TDC in the pigboats, then just use stadimeter, and guestimate angle on the bow and speed, or use the clock, the stadimeter and the nav map to get the measures (assuming playing with map updates off).
In any case, is a very good work of maths...hats off. I do appreciate your effort and mathematical skills.
Dorjun Driver
12-25-12, 08:10 PM
...
But honestly, do you think the skippers had those equations in mind in the middle of a real patrol and playing with their lives?
For some of us, the "equations" simply play out in our minds eye. No numbers, just pictures.
A bit of a drag, actually. :-j
That is a beautifull piece of mathematical work done there, and sure that these were the kind of things the guys that worked on the TDC were doing.
But honestly, do you think the skippers had those equations in mind in the middle of a real patrol and playing with their lives? To start with, you need a calculator to solve the angle equations, which were non existence, or the TDC which was their calculator. It you want to be realistic and not use the TDC in the pigboats, then just use stadimeter, and guestimate angle on the bow and speed, or use the clock, the stadimeter and the nav map to get the measures (assuming playing with map updates off).
In any case, is a very good work of maths...hats off. I do appreciate your effort and mathematical skills.
I would assume there were tables based on the math for quick lookup. Because it would be impossible to solve the equations by hand quickly enough to provide useful results.
There were also circular and linear slide rules for solving math problems, not as quickly as a calculator can. But in the hands of an expert not a lot slower.
But honestly, do you think the skippers had those equations in mind in the middle of a real patrol and playing with their lives? To start with, you need a calculator to solve the angle equations, which were non existence, or the TDC which was their calculator.
No, I certainly didn't mean to imply that RL skippers were doing geometry problems like this in the middle of an approach. But before they had the TDC, they had the Torpedo Angle Solver Mk VIII. (see link below) I'm sure the USN had instructors or mathematicians at the Naval Academy, who worked this out and used the knowledge to formulate attack procedures. I'm pretty sure they knew all this, and more, before the Mk VIII was developed. Otherwise, how could they have designed it?
Mk VIII Angle Solver:
http://www.hnsa.org/doc/banjo/index.htm
I don't know nearly as much about the details of USN torpedo attack procedures as I would like to, but I would guess that once they had the necessary data, they could calculate the lead angle and such in 1 to 2 minutes. Of course, if the target zigged in the meantime, they would have to start over, with no guarantee of success. With the TDC, the procedure would be much faster (obviously).
from jcope:
I would assume there were tables based on the math for quick lookup. Because it would be impossible to solve the equations by hand quickly enough to provide useful results.
I don't know what might have been used before the Torpedo Angle Solver Mk VIII. They might have used some sort of tables or the like. But you make a good point; the doctrine and procedures would have to allow an attack to be delivered in a reasonable time frame to be of any use. The limitations (or shortcomings of) the Mk VIII led to the development of the TDC.
troopie
12-27-12, 04:44 AM
It'd be interesting to know what methods were used in WWI.
Edit: Have copy 'n' pasted your OP to a word document for future personal referance, hope u don't mind. Thanks for the great post!
irish1958
12-27-12, 08:07 AM
It'd be interesting to know what methods were used in WWI.
Edit: Have copy 'n' pasted your OP to a word document for future personal referance, hope u don't mind. Thanks for the great post!
Check out: http://www.subsim.com/radioroom/showthread.php?t=156161
I think they just pointed the boat at the target, got as close as they could and hoped for the best.
It'd be interesting to know what methods were used in WWI.
Edit: Have copy 'n' pasted your OP to a word document for future personal referance, hope u don't mind. Thanks for the great post!
Anyone is welcome to copy, save, and make full use of all this.
As far as WWI (or earlier) fire control, I don't really know. I looked at some of the documents at Hansa.org about early USN torpedos. The first torpedo that had gyro guidance listed was the Whitehead Mk 3 which entered service ca. 1898. IMO, gyro guidance implies a certain level of sophistication in fire control. Really, the building of any auto-motive torpedo is something of an engineering feat. They were very complex pieces of ordnance. The Mk 10 could turn 90 degrees. I don't think they would've bothered with this if they had no way to compute a firing solution.
[I will note here that in the later 1800's, sophisticated methods were developed for controlling coast artillery, and computing trajectories of artillery in general. It was a period of rapid technical progress.]
Beautiful, going to play with this and see if I can add it to my bag of tricks.
twm47099
01-04-13, 11:15 AM
... To start with, you need a calculator to solve the angle equations, which were non existence, or the TDC which was their calculator.
An awful lot of scientific and engineering math and trig was done before calculators and computers.
Slide rules were invented in the 17th century. One of the first things we were taught in engineering school (1960's) was how to use a slide rule and how to develop nomographs and other graphical methods for specialized calculations. When I started work after high school as a CO-OP at a Navy lab much of what I worked on were graphical aids. Most of the older engineers working their used custom graphical aids instead of slide rules or mechanical calculators for their routine calculations. Specialized applications (like artillery) had special slide rules. After a few months using a slide rule, complex equations could be performed very quickly. Way-back-when there were some demonstrations where a very experienced user would perform a series of complex calculations faster than an experienced calculator user. His answer was only accurate to a few decimal places, while the calculator was accurate to 10 or more, but the slide rule accuracy was more than sufficient for a targeting solution. Tables of logs, and trig functions were common place and used for higher precision calculations where time wasn't as critical. One of the jobs of the Navy engineers and scientists was developing these mechanical/graphical "calculators" for their weapons systems.
The 'banjo' and is-was are examples of slide rule/graphical aid for doing vector analysis that worked, although if the setup wasn't steady state the results could be inaccurate. The TDC and PK allowed the automatic input of own-ship course and speed which in turn allowed accurate solutions while maneuvering (as long as the target remained steady state.)
A few years ago I bought a used copy of the Navy Basic Fire Control Mechanisms tech manual from 1944. The way the different calculator mechanisms (+-*/, integration and differentiation, trig functions, range rate, etc) were implemented is fascinating. One method for generating trig (and other) functions was a groove in the shape of the function cut into the surface of a disk. As the disk was rotated to the proper "x" value, a follower riding in the grove moved a rod proportional to the "y" value that was then used by some other components, essentially just replacing slide rules and dials with very precision mechanics and multiple simultaneous inputs.
One thing that does surprise me is that these worked in submarine operations, particularly after a depth charging. For example, some of the integrators are very complex with motions being transferred through balls rolling on other balls, rolling on a flat plate and a cylinder. It seems like one good shock would bend something or misalign something very easily and one spray of salt water would start corrosion that would put the precision components out of action pretty quickly. I assume maintenance of the TDC was a time consuming priority.
Tom
I hope at least a few people have been able to make some use of this. In order to make the calculations less objectionable and time consuming, I've come up with a program that will crunch the numbers and display the results in a pleasing way. (30 minutes to do the math and 30 hours to get it to display right, lol.)
I know Gamefront and others have had their issues and not everyone can access these sites. Does anyone have any advice about how/where I could upload this for public use?
CapnScurvy
02-24-13, 10:29 PM
What's the size of the download?
SubSim's "Downloads" server can handle about 40Mb or so. Anything larger Neil has an FTP site that's available for the asking. I've got two of my mods there (about 200 Mb each). The trouble with the FTP server is there seems to be a limit on how much your account holds. I've tried uploading a third mod of 200Mb+ with no luck. The upload freezes. I've attempted to get an answer from Neil about the FTP account limit but he's never got back to me.
Just a guess, but I'd think your mod could work on the regular SubSim's "Downloads" server.
Carrollsue
02-24-13, 10:32 PM
I hope at least a few people have been able to make some use of this. In order to make the calculations less objectionable and time consuming, I've come up with a program that will crunch the numbers and display the results in a pleasing way. (30 minutes to do the math and 30 hours to get it to display right, lol.)
I know Gamefront and others have had their issues and not everyone can access these sites. Does anyone have any advice about how/where I could upload this for public use?
I for one, have use it just to look at and understand what was going on, then altering it to see if I could come up with something I could use that faster. Bottom line, it shows everything about targeting, key for me SHOWS
What's the size of the download?
...
Just a guess, but I'd think your mod could work on the regular SubSim's "Downloads" server.
It will be less than 3Mb. However, I have in mind some projects afterwards that I would like to offer. They would probably be of similar size. Also, it might be necessary for me to make adjustments or improvements.
I for one, have use it just to look at and understand what was going on, then altering it to see if I could come up with something I could use that faster. Bottom line, it shows everything about targeting, key for me SHOWS
I'm glad it is of some value. It took some time for me to get the diagrams squared away, but I knew that outlining the method without some decent diagrams would only lead to confusion. It is very hard to learn anything about geometry and trig without drawing it out.
CapnScurvy
02-25-13, 08:45 AM
It will be less than 3Mb. However, I have in mind some projects afterwards that I would like to offer. They would probably be of similar size. Also, it might be necessary for me to make adjustments or improvements.
On the "Downloads" main page you'll find the link to PM Neil directly regarding getting access to upload your mod(s). Once done and approved, you'll be able to add as many as you like, or edit an existing one anytime.
Armistead
02-25-13, 11:50 AM
Great job Torpx.
Carrollsue
02-25-13, 09:00 PM
Check out the post Zero gyro shooting it is a high-quality effort to a hard subject.:yeah:
OK. I've PM'd Neal and while we're waiting to get word back, I'll give you all a peek:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/AFSCapture_zps15fbb263.jpg
So there is no confusion; this is not a mod, but rather a utility to calculate a firing solution using the method outlined at the beginning of the thread. It should work on any Windows machine. We'll have to see about Win. 7 and Win. 8, though.
Here are a few features:
has resizable window
can change display font
can use yards or meters
can calculate stern tube solution
also calculates collision course speed
It turns out, it is only about 1mb when compressed. Does anyone know if something like this can be sent by email or PM?
Carrollsue
02-26-13, 02:17 AM
So there is no confusion; this is not a mod, but rather a utility to calculate a firing solution using the method outlined at the beginning of the thread. It should work on any Windows machine. We'll have to see about Win. 7 and Win. 8, though. Here are a few features:has resizable window can change display font can use yards or meters can calculate stern tube solution also calculates collision course speed It turns out, it is only about 1mb when compressed. Does anyone know if something like this can be sent by email or PM?
Is that a handy-dandy MoBo??? WOW…WOW anyway, like what I see
Well, Neal has generously OK'd the uploading and I've got it all squared away. (I think it's ready, anyway.)
I haven't used MoBo, but I think that is intended to fulfill a different purpose.
This program will allow the user to manually calculate a zero-gyro angle firing solution, with a minimum of fuss. It uses the equations that I posted at the beginning of the thread. I have incorporated some changes and additions to make the process easier, however. I coded the angle inputs so the user can enter the relative target bearing 'as is'; there is no need to re-orient the angle. Likewise, there is no need to use a negative value for the sub speed when making a stern shot. Output angles are properly oriented and times are displayed in minutes and seconds. Also, one can easily change from yards to meters; so it is Kriegsmarine friendly. :)
The most difficult element I had to deal with (besides all the intricate never ending display changes), was putting in a series of logic checks to reject any sets of data that didn't allow a solution. It is probably not apparent why this would be needed, but I decided that it would be a substantial shortcoming if it were left undone. For example, if you are closing the target ship's track, bow on you can calculate the solution and it will give you the right answers. No sweat, right? But, at least in some cases, you could enter the same data and hit the "stern" button and get a false solution. Not good. Normally, this would be obvious from the plot, but if you weren't making the plot or were in a hectic and confused situation you might take it at face value. This bothered me, so I put in code which (I think) will catch all of these cases. One limitation remains from the original equations; you must still cross the target's track before you compute a solution for a stern shot. You can, of course, extrapolate your plot and compute a solution that way, but the program itself can't do it. I was going to put this capability in, but it would require another branch of code, and I decided to "keep it simple".
I added auxiliary calculations for collision course speed and optimum track angle. I had reservations about these. They aren't really required, but no extra data input is required and it wasn't difficult to add them. I think it is better to have capability in one utility, than maybe have to use another item/device.
I will probably present an example or two of it's use when I have more time, but it is fairly simple as long as you understand the definitions of track angle, etc., etc.
It can be found in the Utilities section of SubSim Downloads:
http://www.subsim.com/radioroom/downloads.php?do=file&id=3978
OK, no comments yet. I'm not sure whether that's good or bad.
In case anyone is having trouble with this, or readers are still a little unclear about AFS I, I've posted some examples, screen shots and explanations.
Here goes!
Target Track is in red
Sub Track is blue
Torpedo Track is orange (pink?)
bearing lines in black
angles in Gray
Case 1:
Target ship is on a closing track and will cross in front of Sub. At U0, Sub makes final observation before computing firing solution for BOW shot. Note in particular the Target bearing and Track angle. The bearing is obvious, but be careful about the Track angle. These two angles are all you have to worry about. The AoB is shown here only for reference, you don't use it in this method.
At U1, Sub launches torpedo, Target is at T1. Torpedo hits Target at T2.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case1_zps93d7facd.png
Here is the corresponding firing solution:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case1sol_zpsf16be767.png
Case 2:
Below is another BOW shot set-up. The main reason I am using this as an example is that this shows the Target is crossing from the opposite side and the Track angle is negative. This is important because the Track angle format is -180 to +180. If you use the wrong sign, you will not get the correct solution. Either you will get an error or wrong numbers. The program is designed to reject such cases.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case2_zpsc5478baa.png
And the solution:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case2sol_zps1c96b05e.png
Case 3, below:
Set-up for a STERN shot. I am assuming here that there is no option for a BOW shot for some reason. The Sub will cross in front of the Target ship, but has not done so, yet. There is nothing wrong with the set-up per se, only that the program wasn't designed to due this math.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case3_zps85472d86.png
And the screenie:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case3sol_zps9cbc4d66.png
Case 4, below:
This is the 3rd case after the Sub has crossed the Target's Track. Now the firing solution can be computed. Note how the geometry has changed.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case4_zps157dac8b.png
And the computed solution:
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20I/case4sol_zpsbe5e68e0.png
The computed information on the left, the optimum track angle and the collision course speed are not necessary, but I included them for reference since no additional data is required. The program actually uses the CCS to check if a solution is possible. The OTA is only for reference.
The program will not compute solutions for 0 or 180 degree Track/Bearing angles as this creates a divide by zero problem.
I would encourage people to get some scratch paper and sketch out a few set-ups just to see how it works and learn it. You don't have to go on patrol to do this.
Any feedback would be welcome. I am especially interested to hear what people like or dislike about the display. This is what I spent most of my time on and what proved to be most difficult.
TorpX
Dorjun Driver
03-02-13, 10:25 AM
TorpX,
It’s not clear to me why your application doesn’t generate at least a partial firing solution for Case 3, i.e. the lead angle, which is all one really needs. Ceteris paribus. Given the target speed (VShip) , the torpedo speed (VTorpedo), and the interception angle (θIntercept) (180°-track angle (θTrack)), the desired lead angle (θDeflection) drops into your lap. See my Zero gyro shooting (http://www.subsim.com/radioroom/showthread.php?t=202517).
I admire the work you’re putting in on this topic.:salute: Please keep it up.
Dorj
Beardmoresam
03-02-13, 01:03 PM
Doesn't the TDC do this for you?
Edit:
To clarify what I mean is: I do this with the TDC all the time? I just turn off the PK and enter the predicted variables for the target and it does all this anyway? I find you just have to feed it the right info and it can give you a very accurate static solution just as much as it can give you a dynamic one.
Any way you can make this an iphone app?
TorpX,
It’s not clear to me why your application doesn’t generate at least a partial firing solution for Case 3, i.e. the lead angle, which is all one really needs.
Well, it won't provide a solution by itself. If you extrapolate the plot and feed in the data corresponding to a point in time when the sub has crossed the Target Track, it will provide a solution.
Maybe I should have put this capability into the program, but I didn't think the situation would occur often enough to justify the effort. To get the numbers to work right, some account has to be made for the sub speed sign, because the sub is initially closing the Target Track , then moving away. Also, the angles change. The program rejects these cases. If I hadn't put code in to do it that way, you would get incorrect numbers which would be very confusing. If there is a big demand for this, I might revise it, but judging by the limited number of responses, not many people are going to use this.
...the lead angle, which is all one really needs.
I disagree that the Lead angle is all you need. I consider the other elements, Track Range, Run Time, and Time to Position to be of almost equal importance.
I did see your posting on zero-gyro shooting. Did you see the formulas in the OP? The first one in particular will give you equivalent results.
[I restored the images in the OP. I had reorganized them at Photobucket and broke the links. Sorry!]
Doesn't the TDC do this for you?
In terms of the "lead angle", yes. It doesn't give the track range, run time, or others. In any case, S-class boats didn't have them.
If you really mean to ask "Why bother with all this?", I'm not sure I can give you a easy answer. If you never depart from using the game TDC, you may very well sink a goodly number of ships, but it is unlikely you will ever develop a real understanding of the finer points of Fire Control. I guess someone who always plays in auto-targeting mode could ask why anyone bothers with manual targeting. To me, the game would not be half as enjoyable without these detailed elements.
Dorjun Driver
03-02-13, 06:10 PM
I disagree that the Lead angle is all you need. I consider the other elements, Track Range, Run Time, and Time to Position to be of almost equal importance.
I did see your posting on zero-gyro shooting. Did you see the formulas in the OP? The first one in particular will give you equivalent results.
[I restored the images in the OP. I had reorganized them at Photobucket and broke the links. Sorry!] I didn’t make myself clear. What I meant is that when the target takes an unexpected zig or zag at the last moment, given she maintains her speed, all that’s required is to plug in the new intercept angle given her new course. From that—and maybe a little stick and rudder work—the deflection/lead angle then drops into your lap. With seconds to spare, too!
As you may have gathered, human factors aren't my strong suit.:-?
Dorj
I didn't make myself clear. What I meant is that when the target takes an unexpected zig or zag at the last moment, given she maintains her speed, all that’s required is to plug in the new intercept angle given her new course. From that—and maybe a little stick and rudder work—the deflection/lead angle then drops into your lap. With seconds to spare, too!
Yes, if all you want at the last minute is the lead angle, you can simply change the track angle and recalculate (either in the program or manually). But, there are practical and RL considerations. If in case 1, the target ship takes a last minute zig, you will quite possibly be faced with a situation of either, "the target got by" (it has already gone past the new firing bearing), or the new track angle will be much less favorable (as well as the range being longer). In RL, it took an appreciable amount of time to calculate a firing solution without the TDC. It also takes some time to change course in a submerged submarine. The difficulty of quickly computing firing solutions, while making an approach on a zigging target lead the Navy to develop the the TDC.
From Dignan:
Any way you can make this an iphone app?
I don't own an iphone or any such device. I would think someone who knows how to make apps for these could do it without too much trouble.
Heretofore, I used my TI-85 for this sort of thing, but the display is very small and it's hard to see well in a dark room. Otherwise, it works very well, so I don't see why an i-phone couldn't handle it.
I was wondering whether anyone could run this on a tablet computer.
Any feedback would be welcome. I am especially interested to hear what people like or dislike about the display. This is what I spent most of my time on and what proved to be most difficult.
TorpX
http://img.xrmb2.net/images/180355.jpeg
Red squares because these data are critical.
Torpedo-Impact-Angle = TrackAngle ( if TrackAngle < 90)
TrackAngle - 90 (else)
Use AoB. TrackAngle should be computed from the program itself
TrackAngle = 360 - TargetBearing + AoB ( if TargetBearing > 180)
-TargetBearing - AoB (else)
Time input because for position data who were availeable in the past and has changed if one wants to input them in the program.
Also conversion date nautical miles for ranges would be a good idea.
For other changes see pic.
if the "time to position " < 1 minute then there is a problem with the minute display IMO.
OK, for those just tuning in, the preceding screen shot is NOT AFS I, but rather CaliEs's proposed version. If your confused, don't feel bad; I was too, when I first saw it.
if the "time to position " < 1 minute then there is a problem with the minute display IMO.
I'm not sure what you mean here. If you are getting a wrong/confusing answer post/PM me with the complete problem (all set-up data) and I will look at it, and see what's what.
I consider the space for HOURS to be totally superfluous. If you have that much time to burn, you don't need a quick firing solution, you need to tell your XO, your turning in to your bunk, and wake you in good time.
It is not the purpose of this utility to compute intercepts for distant contacts. That can be done easily in plotting, or with other apps.
Also conversion date nautical miles for ranges would be a good idea.
Fire control problems are usually done with yards or meters. See above.
Time input because for position data who were availeable in the past and has changed if one wants to input them in the program.
I am thinking you don't understand the way this is meant to be used. Every observation of the target you put on your plot should be associated with a time. (The game will not let you mark it on the charts, but you should write it down on paper so you have it.) The idea is not to use this as a no-plot method, but rather to use this with your plot. So, for example, if I make my final observation at 1408 hrs. , I will then update my plot and check the data. Then, after I am satisfied with the data and set-up, I put the data in the program and hit the calc. button at 1410 hrs. If the solution comes back with a time to position of 2' 30'', then I know I have less than 30 seconds to get the scope up and fire the torpedos. Nothing else is required. In your screen, you have 4 different times displayed! Why? It is confusing and unnecessary.
Torpedo-Impact-Angle = Track Angle ( if Track Angle < 90)
Track Angle - 90 (else)
This is not correct. In a zero-gyro angle set-up, the "impact angle" as you call it, is the Track Angle. It is called the Torpedo-Track angle, and since the Torpedo Track coincides with the Sub Track, The Torpedo Track angle is the same as the Track angle.
Use AoB. Track Angle should be computed from the program itself
Track Angle = 360 - Target Bearing + AoB ( if Target Bearing > 180)
-Target Bearing - AoB (else)
Simply put, No! I specifically configured the equations in terms of the Track angle. Using the AoB offers no advantage, and is often a source of confusion in learning manual targeting. Why do I say this? Because the Track angle is constant, while the AoB will be changing moment to moment. It is much easier to plan an approach using the Track angle, than trying to recalculate/check the plot relying on the AoB. If you are confused about the Track angle, study the examples, and consider this:
At the moment of Torpedo Impact, the Track angle, and the AoB are the same!
However, I might put in code so 0 speed Sub/Target situations do not halt the program. It didn't seem that important when I was working on it.
les green01
03-05-13, 06:35 PM
want to say thanks,it does work on windows 7 having the help function on the program is nice you done a really good job
Your most welcome. It is good to hear some positive feedback.
I must admit, I'm a little worried about how many are able to use this. Not just, will it run on Windows 'X', but can people use it without triggering the mysterious and annoying CO2 bug.
les green01
03-06-13, 07:37 AM
on my laptop i got a windows button right there by the alt button so i use that instead of alt f4 and hadnt had no problem
This post is just to let anyone know, I am aware of some problems with the program. Namely, sometimes extraneous results being returned in certain cases. I had intended these to be excluded and the "computation error!" window to pop up, but I didn't get the code right. It is easy to describe the conditions required for a solution in plain english, but not so easy to do it with boolean statements. :06:
I am working on a fix, and some minor improvements.
OK, version 2.1 has been uploaded to SS Downloads section.
New for v2.1:
Better filtering of extraneous results
Added capability for bow-on/stern-on solutions
Minor display tweaks
Most of the changes were made to eliminate the extraneous results that sometimes slipped through. This turned out to be harder than I thought it would be. I also added the "head-on" solution ability, more for completeness than any real need. I eliminated the Windows error tone that sounded for non-solution results. I found it to be very annoying.
Inside baseball math stuff:
Part of the problem, with the internal checks, is that the code will only do trig. functions in radians, and sine of pi doesn't return 0, exactly, though it should. (Another reason to hate radians.) This added another layer of difficulty to the boolean tests.
I thought that I could easily use a small angle of .01 or .001 deg. instead of 0 degrees, for a head on situation. This turned out not to work well, in practice. If the corresponding track angle is too sharp, the Tpos will distort the solution and result in ranges that are inaccurate. If the angle is too blunt you will have a non-solution result. Adding different equations for these situations was necessary to handle this sort of thing.
BigWalleye
03-23-13, 06:53 AM
Just out of curiosity, what language did you write it in?
Just out of curiosity, what language did you write it in?
Liberty Basic v4.04.
If anybody is interested, you can download the demo version free at www.libertybasic.com (http://www.libertybasic.com).
Aramike
04-02-13, 12:04 AM
I don't have anything intelligent to add, other than to point out that I love threads like this: intelligent posts regarding well thought-out concepts.
Well done!
Thank-you very much! :salute:
If you liked this, I think you will like my next project better.
I think I'll just post it in this thread...um...pretty soon, I hope. Anyway, it's a new (and more sophisticated) method for computing a firing solution. I have most of the underlying math worked out, but still have a great deal yet to do for the associated program. It's funny how computers were developed to do math, but seem to often make it more complicated. :)
AFS II (for curved fire)
Early attempts
Have you ever tried to figure out a way to calculate a firing solution with a non-zero gyro angle? Well, I have. If it's possible to calculate a firing solution for straight fire, why not do the same for curved fire? Years ago, after I had worked out the math for a straight shot, I tried to come up with something ... and got nowhere. A while later, I came back to it, and tried again. Again, I failed to find a way. (This was all in the SHCE era.)
Not wanting to give up I came back to it, recently, after touching up and getting the AFS I technique ready for presentation, I decided to have a more serious try at this. First, I tried to diagram a typical curved torpedo track to find a usable triangle so standard trigonometry could solve the problem. Of course, I got nowhere with this. Then, I tried to find a suitable trapezoid, or rhombus, or ... whatever. None of this proved fruitful. Seeing that there was really no "magic polygon" to fall into my lap, I then worked on a technique, where the turning part of the torpedo track, is approximated and the solution was to be calculated in parts. There would be a "preliminary" solution and then adjustments that would compensate for the deviation, etc. I considered this to be promising at first. However, as I got more into it, it became clear that the accuracy of the adjustments was likely to be a good deal less at large gyro angles. So, I decided to tear up this method and start over.
Cartesian Coordinates
I finally realized that the pursuit of clever geometry shortcuts, is a waste of time. There was no use going over that ground again. I decided to lay out the problem in terms of Cartesian coordinates and a defined x and y axis, and carefully define every known element. This approach, while involving a good deal of work, offered a sure result.
I defined the X-axis to be the axis along which the sub travels, the Y-axis as perpendicular to this. The sub's initial position is 0,0 and moves in a positive direction. The target can be anywhere, so it's coordinates can be positive or negative. The same is true for the torpedo gyro angles and coordinates.
Note, that we seek to find the correct launch bearing for a given gyro angle, not the gyro angle for a given launch bearing.
This shows the general geometry of the problem:
http://i1130.photobucket.com/albums/m526/TorpX/General_zpse2f46177.png
To obtain a solution, I have divided the attack phase into three parts. At the start of the first phase, the sub, U, and target, T, are at their initial positions, and the necessary data for a solution has been compiled. The target and the sub are moving into position for launch.
At the start of the second phase, the torpedo is launched, it runs out, turns, and completes it's turn. In the third phase, the torpedo runs straight ahead on it's final heading, until it impacts with the target. Note that while the target's position, and sub's position at ph2, and the sub position at ph3 (T2, U2, and U3) can be computed, I don't show them here as they don't have any particular tactical significance. The critical thing here is that the torpedo turning phase must be defined separately.
Here is what is known, in math terms:
R is the range to target, at start
Vt is target speed
Vu is sub speed
Vp is torpedo speed
theta is relative target bearing, at start
alpha is relative target course
t1 is time for first phase, (positioning)
t2 is time for second phase, (torpedo turn)
t3 is time for third phase, (torpedo final run)
http://i1130.photobucket.com/albums/m526/TorpX/Eq1_zpsc4bf1ab2.png
In order to define the torpedo movement, we must delve into the details of the geometry of the torpedo turn:
http://i1130.photobucket.com/albums/m526/TorpX/TorpTurn_zpsf0674f4e.png
Defining the movement of the torpedo caused me some anxiety until it occurred to me that we don't need to know the location of the torpedo moment to moment, only where it is, as it finishes the turn; an easier matter.
Along the X axis, I broke the turn into 3 segments: the tube distance, b, the torpedo reach, q, and the turn, k. k is easily seen to be equal to r*sin g.
For the displacement along the Y axis, we want to know m. m + n = r and n = r*cos g, so m = r – r*cos g = r(1 – cos g).
After adding some terms to account for the sign of g, we obtain:
http://i1130.photobucket.com/albums/m526/TorpX/Eq2_zps8665b68c.png
With the torpedo movement elements defined, we can get down to serious business.
By definition, in our firing solution, the position of the torpedo at P3 and the target at T3 will be the same.
Thus:
http://i1130.photobucket.com/albums/m526/TorpX/Eq3_zpsf733865b.png
We want to solve for the time variables, t1, t2, t3. Once we know those, we can calculate anything we need, but it appears we have two equations and three unknowns. What to do? Well, since we hammered out the torpedo turn, location and know it's speed, we can calculate t2 at the outset, and eliminate it as an unknown.
Success
From here on, it is a matter of algebra; lots and lots of algebra. As I doubt many here have a strong desire to wade through pages of equations, I won't torture you with a step by step replay. Instead, I'll just show you the highlights.
http://i1130.photobucket.com/albums/m526/TorpX/Eq4_zpsb9a4d55e.png
(Finished in next post)
Final Form:
After I got the basic solution equations, I spent some time checking the math by computing the answers to a few sample problems and plotting the results on graph paper to verify the the answers are correct, and not just a heaping pile of algebraic missteps. Then, I went back to the equations and multiplied out the terms to look for ways to simplify the equations, or at least, put them into a more pleasing form. I was able to use trig reduction formulas in a few areas, but could not really make any major simplifications. I also put the trig functions in terms of the track angle and added a factor, Lg for what I call “launch lag”, as experiments indicated that this was greater than I had expected.
http://i1130.photobucket.com/albums/m526/TorpX/Eq5_zps67eb33bf.png
Residual problems:
Most of my work now is on developing a program that will do these calculations and some other auxiliary tasks to make this method a practical proposition. As I said before, the equations for t1, t2, and t3 are the core of this method. It is not immediately obvious, but the denominators of the expressions for t1, and t3 can be zero, resulting in either or both of t1 and t3 being undefined. If these cases were all “no-solution” cases, this wouldn't be a problem, but I found this not to be the case. For example, if the sub is heading north and the target south, on tracks that coincide, go = 0, t1 is undefined, though clearly a solution exists! On the other hand, if sub and target are heading in opposite directions, as before, but on parallel tracks, t1 is undefined, and no solution exists. I spent quite a bit of effort trying to sort through these cases of “parallel tracks”, in an effort to separate the wheat from the chaff. Then it occurred to me that there was a much better way.
I arranged the program to calculate t1 and t3, if they are defined. If t1 is undefined, t1 is set to zero, and passed to the calculation of t3, to check if this will yield a solution. If t3 is undefined, the alternate equation is used. Then the provisional solution is checked by adding up the positions of target and torpedo through each phase, so that the final position coordinates can be compared. If they match up, the solution is considered valid, if not, it is rejected. Easy!
Still to do:
I still have quite a lot to do on the AFS II program. The basics are in place, but a lot of details and refinements are not done. I think I have the torpedo data for the Mk 10 pinned down pretty well, but haven't started on the Mk 14 yet. I might try to compile data for one or two German torpedoes, later.
I'll be posting some sample problems in the near future, to illustrate the method.
I'm sure there are some aspects of this that aren't entirely clear, but I'm not sure how far into the weeds people want to get. If anyone has any questions, I'll do my best to answer them.
Edit: I forget to mention that all these equations are for arbitrary units; that is distance in length units, time in time units, speed in length/time units. The reason for this is, that it is much easier to check the math this way.
TorpX
P.S. If anyone can give me some tips on getting equations and formulas display in a proper manner, I'd be grateful. Using the Paint program was not my first choice, but I couldn't get the math to display well in wordpad. :06:
Dorjun Driver
05-09-13, 12:49 PM
Oh, goody! :up:
Gilead Abyss
05-09-13, 05:05 PM
A very impressive exercise so far, and I've enjoyed (really!) following the thought process and problem-solving.
I hope you are able to code this together into a working tool, but even if that stumps you, this has really added to the sense of longhand pencil work needed to make these weapons at all effective.
Here's hoping this proves to be more than an exercise for you.
Well done
Thank-you for your kind words.
I can promise you that I will release a program that will do these calculations and put this concept into practice. It may not fulfill my ambitions 100%, but will get the job done. Someone on the forum said, it was customary for 80% of the coding to be done in 80% of the time alloted, with the remaining 20% being done in the other 80%. Based on my personal experience, I would go along with that. :)
One thing I decided to incorporate, is a "sketch" function where you can have a window pop up with a graphical representation, of the solution just computed. I have it working now, but would like to polish it some more. Anyway, I'm excited about it. I think people will find it worthwhile.
...longhand pencil work needed ...
And there was plenty of that, I can assure you.
My first attempt I threw out because I had the X-axis accross and half-way into it, I realised it was a mistake, and I needed to start over. The second attempt, I discarded because I was trying to make multiple algebra steps in each line and some mistakes had creeped in. I decided it was best to start over... I had to use blank paper turned sideways so I could fit the equations on one line. It made me wish I had some really large chalkboards to use. :arrgh!:
Gilead Abyss
05-10-13, 08:22 AM
to incorporate, is a "sketch" function
This is a great idea! A quick visual inspection to make sure I'm getting an answer to the question I think I'm asking.
Some folks can read equations and translate to "picture ideas" on the fly. For the rest of us, this is a brilliant way to provide a quick double-check.
Again, impressive work. Thanks for sharing.
Some folks can read equations and translate to "picture ideas" on the fly. For the rest of us, this is a brilliant way to provide a quick double-check.
Exactly. It is very easy to input a gyro angle of 85, when you needed to input -85, or use a track angle of 70, instead of -70.
I've put together a few examples so people can look at some specific numbers, and check the math if they so desire.
Ex. A1
track angle : -120
gyro angle : 40
sub speed : 2
target speed : 6
target range : 1200
target bearing: 55 deg.
torpedo config:
torpedo speed: 20
q : 120 'torpedo reach
r : 100 'turning radius
Lg : 4 'launch lag
bb : 30 'bow tube distance
Note that all figures are in coherent units; i.e. ranges in meters, times in seconds, and speeds in meters per second. This makes checking the math much easier. Of course, in the finished program, speeds will be in knots.
start readout
Kd 0.26146582 'sub functions
Kx 18.0519046
Ky 12.3208889
Kz -118.17693
Px 222.278761
Py 23.3955557
TT 1 'torpedo tube status, 1= bow, -1= stern
t1 22.1297521 'time intervals
t2 13.4906585
t3 42.90395
T0x 688.291724 'x and y coordinates of sub, target, and torpedo
T0y 982.982453
T1x 754.68098
T1y 867.992888
T2x 795.152955
T2y 797.89337
T3x 923.864805
T3y 574.957907
U1x 44.2595041
U1y 0
U2x 71.2408212
U2y 0
U3x 157.048721
U3y 0
P2x 266.538265
P2y 23.3955557
P3x 923.864915
P3y 574.958105
tgt bearing at launch: 50.7008883
tgt bearing at impact: 36.8625251
Torp Track 1047.89217
Error: 0.22621151e-3 'error between computed torp and target positions
Ath1: 5.23598776 'relative target heading, radians
in deg.: 300
Abg1: 0.95993109 'relative target bearing, radians
in deg.: 55
Agyo1: 0.6981317 'gyro angle, order, radians
in deg.: 40
At t = 0
target is at T0
sub is at U0
sub computes firing solution
At t = t1
target is at T1
sub is at U1
sub launches torpedos
At t = t1 + t2
target is at T2
sub is at U2
torpedo is at P2
torpedo has finished turn
At t = t1 + t2 + t3
target is at T3
sub is at U3
torpedo is at P3
torpedo impacts with target
see below
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/ExA1_zps8bd254e2.png
In Ex. 2, all initial sub, torp, and target data is the same except the gyro angle is 0.
start readout
Kd -10.9451942
Kx 5.19615242
Ky 17.0
Kz -103.923048
Px 158
Py 0
TT 1
t1 138.093638
t2 10
t3 41.0810475
T0x 688.291724
T0y 982.982453
T1x 1102.57264
T1y 265.426863
T2x 1132.57264
T2y 213.465339
T3x 1255.81578
T3y 0.1954525e-2
U1x 276.187275
U1y 0
U2x 296.187275
U2y 0
U3x 378.34937
U3y 0
P2x 434.187275
P2y 0
P3x 1255.80823
P3y 0
tgt bearing at launch: 17.8065083
tgt bearing at impact: 0.1276243e-3
Torp Track 941.62095
Error: 0.7802254e-2
Ath1: 5.23598776
in deg.: 300
Abg1: 0.95993109
in deg.: 55
Agyo1: 0
in deg.: 0
This shows the math works just as well for 0 gyro angle shots.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/ExA2_zps0d3e80fb.png
In Ex. 3, again, everything is the same except the gyro angle is -20. This gives a less favorable track, but might be necessary if you had to delay your launch for some reason.
start readout
Kd -13.8806698
Kx -1.64425044
Ky 15.7938524
Kz -77.1345132
Px 192.202014
Py -6.03073792
TT 1
t1 193.104632
t2 11.7453293
t3 45.8665896
T0x 688.291724
T0y 982.982453
T1x 1267.60562
T1y -20.4186501
T2x 1302.84161
T2y -81.4491711
T3x 1440.44138
T3y -319.778962
U1x 386.209265
U1y 0
U2x 409.699923
U2y 0
U3x 501.433102
U3y 0
P2x 578.411279
P2y -6.03073792
P3x 1440.42119
P3y -319.776689
tgt bearing at launch: 358.672909
tgt bearing at impact: 341.193741
Torp Track 1072.23838
Error: 0.20310576e-1
Ath1: 5.23598776
in deg.: 300
Abg1: 0.95993109
in deg.: 55
Agyo1: 5.93411946
in deg.: 340.0
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/ExA3_zps7efa2bd5.png
I'll post some examples which show the details of the torpedo turning better. The sketches don't really allow you to see the turning part very well, unless you are zoomed in pretty close.
TorpX
Here is a long overdue update on the program I'm working on.
I've mainly been working on the program itself, but just recently have started some actual firings against moving ships. Anyway, almost all the basic elements are in place, I have the "sketch" function all done, apart from last minute tweaks, and I hope to start making final math checks fairly soon.
The program will enable the user to produce "sketches" like these:
This first one shows how the torpedo track will look if you are zoomed in close enough. I've used a larger value for the turning radius so you can see it better. In most cases, you will be making shots at a longer range and not using a 180 degree gyro angle (I hope :)), so the curve of the track will appear abrupt. However, I wanted it to provide a good representation of the solution and have put in a lot of work on this aspect of the program. As you can guess, I've been having a little fun with it. You can compute solutions that your torpedoes cannot perform; there aren't any hard-coded limits built in.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/FS_Sketch011_zpsa934af64.png
The next shot shows what a more typical solution might look like. I used the same torpedo data with this set up. The curvature of the torpedo track is much less noticeable.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/FS_Sketch012_zps1b80f65b.png
This last shot shows how it can be used to create a graphical record of an attack. I had to redo much of the code for the drawing portion, so the orientation of the sub can be changed. Before, the sub was always shown to be headed straight up toward the top. I still think the default heading is best for guaging angles and such, but for making a record, or comparing it to the SH4 charts, it is nice to be able to reorient the sketch.
http://i1130.photobucket.com/albums/m526/TorpX/AFS%20II/FS_Sketch013_zpsf64c00c8.png
Note that everything shown here can be put on the chart without outside "post-production" tools like Paint or such. Of course, you can calculate the solution without using the sketch function at all. Originally, I had it in mind to do just that, but the more I thought about it, the more I wanted to implement it in some way. It required quite a bit of effort before I was satisfied with it.
I need to do some more of the shooting gallery stuff, but I do not plan to conduct a mind-numbing number of tests. I have a good deal of confidence in the underlying math; I only need to refine the values associated with the torpedo reach, turning radius, and such. Right now, this is my biggest problem. I know the values I'm trying now are close, but not exactly a match. I thought I could tease out the numbers with various tests, but there are limitations with this approach. The in-game TDC only reports gyro-angles to the nearest degree, and shooting at moving ships is not exact, since they try to dodge the torpedoes. I will probably have to settle for values that are "close", and not quite spot-on. In any case this is the last big hurdle to finish.
c13Garrison
07-23-13, 08:37 AM
After reading this thread, I am reminded of what I enjoy when reading about WWII hardware. Not just a rote repetition of facts, but rather the stories behind the engineering decisions that were being made. To wit, I would LOVE to read the original notes on the first hash-out round-table session over the design of the TDC. Real mechanical engineering.
But BTW- Awesome programming work. You clearly have a zeal for this sort of thing.
Thanks.
I have gotten better at this. (This isn't really saying much, though.) I'm sure someone who was really good at this sort of thing could have finished it in a quarter of the time it has taken me.
I'm getting anxious to finish it, and go on patrol and give it a "field test".
I just put together a small program that tabulates values of Gyro angle Vs. Bearing angle, so I could more easily check combinations of torpedo reach, turning radius, and such. I am hopeful of getting more accurate results now. I'll do some more testing tomarrow.
I did a little testing with the Mk. 14 torpedoes. As far as I can tell, they have the same reach and turning radius as the Mk. 10's. That makes things a little easier for me. They do have a greater lag; that is they take longer to exit the tube.
I also did some testing of torpedoes launched from deep submergence, up to 200 ft., and the results agree pretty well with the stated "max dive angle" listed the the game files. This isn't a major deal, but I wanted to put this into the solution model, so if anyone wants to try sonar only attacks, they can. I know the RL Mk. VIII Angle Solver had different plates for different depths.
Since the new firing solution program is nearly ready for release, I thought I'd show the math for some of the auxiliary functions/tasks.
This is the Gyro Angle Setting calculator. Since there is currently no way to set the torpedo gyro angles directly (at least in the USN side), it is necessary to calculate a bearing, whereby the TDC mechanism, will be forced to set the gyro angle you want. This is the most important of the Auxiliary functions in the program since it will be required for most launches.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/gyro-anglesetting_zps2d9b1e12.png
In the above diagram,
b is the distance from the periscope/TBT and the end of the torpedo tubes
q is the torpedo's reach, (distance traveled before turning)
r is the turning radius
n is the difference between b+q and the location of where the torpedo track, extended backwards, intersects the sub track
R is the range input
g is the gyro angle
theta is the bearing angle
B is the difference between g and theta
g0, in the last equation, is the gyro angle, order; the gyro angle indexed from 0 to 360 deg.
Note that the red 'X' is not a target ship, but an arbitrary point the the TDC is pointed to, to achieve the desired gyro angle.
Next up is the Torpedo Spread calculator:
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/TorpSpread_zps48005511.png
This enables the user to compute a divergent spread after the firing solution has been computed.
The linear displacement is the sum of three things:
the torpedo track displacement
target displacement
spread displacement
The 1st is due to the movement of the sub and the angles of the torpedo track intersecting the target track. In other words, the projection of the torpedo track along the target track, as the sub moves. If the sub was not moving or the gyro angle was zero, this quantity would be zero.
The 2nd is due to the movement of the target. It is the distance the target moves in the interval between the launch of the next torpedo.
The 3rd is simply the displacement along the length of the target. It depends on the length of the target and how much "coverage" is desired.
In the above diagram:
Dp is the torpedo track displacement
Dt is the target displacement
Ds is the spread displacement
Vu is sub speed
Vt is target speed
k is constant to convert knots to ft./sec.
ti is time interval
f is fractional coverage, expressed as a percent
ln is target length
D is the total displacement
g is the gyro angle
TTa is the torpedo track angle
Z is the adjusted track range (distance of straight run)
d is offset angle, or spread angle
Using this type of spread in a set-up like that shown above, the first torpedo would be aimed near the stern, and each successive launch would be given a larger offset angle going left.
Here is an illustration of the Aob from Aspect Ratio function:
I don't go into all the finer points of the math, but the diagram gives you a sense of the concept.
With the formula,
l is target length
h is target height
lo is observed length
ho is observed height
W is width
W' is adjusted width
J is a function which compensates for width (or beam) of target
If ships had no width, you could calculate the Aob without J, using the formula with the first term only. J was determined by using only 1 specific model. I considered trying to use different models where you could choose the most appropriate one for your situation, but decided this was more trouble than it's worth.
The ship model was based on the target having a beam equal to 1/8 of it's length. The stern having a radius of curvature equal to 1x the beam, and the bow having a radius of curvature equal to 3x the beam.
The difference between W and W' is zero at Aob's between 60 and 120 degrees, and is still very small between 30 and 150 deg. At Aob's close to 0 or 180 deg., it becomes important. The value of J is determined by using the formula
m * AR + b
where m and b are selected according to which of 4 zones the AR fall into.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/AobAR_zps5671c343.png
The Timing by Wire function:
Ordinarily, timing by wire is done with the periscope at 0 deg., and pointing the sub at a location just ahead of the target ship to time the transit across the scope reticle. This allows for a simple calculation where the projected "wire" does not move on the target's track.
However, if we apply some geometry to the problem we can obtain the same information at other angles.
With the formula shown,
Vt is the target's speed, kts.
Vu is the sub's speed, kts.
ln is the target's length, ft.
t is the transit time, sec.
Aob is the Angle on the bow, deg.
theta is the relative bearing, 0 to 360 deg.
k is a conversion factor, ft./sec. to knots
If theta or Vu are zero, the 2nd term, Vu * (sin theta/sin Aob), drops out leaving us with the simplified method mentioned earlier.
The formula is obtained by using the law of sines, and noting the wire's location projected on the target track moves n distance, as the sub moves m. The triangle gets smaller, but the angles do not change.
The form of the equation may seem odd, with the subtraction of the second term, but the signs will work out right, and give the correct answer, provided one is careful to input the bearing as read off the scope, 0 to 360 deg., and input the Aob from -180 (port) to +180 (starboard) degrees. [Either or both the sine of theta, or sine Aob can be negative.]
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/TimeWire_zps320d2b28.png
No replies yet. I'll just assume this means people are frozen in anticipation, lol.
Tracking Party 1.1 is released, and available in the downloads section under Utilities:
http://www.subsim.com/radioroom/downloads.php?do=file&id=4236
Here I'll provide a tutorial fully explaining the use of the program/method.
Installation:
When you unzip the file, you should have a folder with:
Tracking Party 1.1.exe
Tracking Party 1.1.tkn
3x .SLL files
5x .DLL files
2x .wav files
1x .ico icon
1x Save folder (empty)
1x images folder (17 .bmp files)
this help file
Simply move the folder, with the inside files/folders as-is, to the location of your choosing. I put mine in a folder named SH Auxiliary, but it doesn't really matter, as long as you know where it is, and can reach it. Then make shortcuts from the Tracking Party 1.1.exe, and this help file, and put those on your desktop, or wherever you want them. That's it, you're done! The first time you run Tracking Party, it will create a config. file that stores the display, unit system, and realism settings, and a torp cofig. file that stores the torpedo performance numbers. These can be edited from the menu dialog panels when the program is running.
Configuration:
There are 5 items at the top of the main window that can be accessed to change the various elements of the program.
Display - calls up a display config panel where you can change the main window size and color scheme. The auxiliary window's color can also be selected; the size will be proportional to the main window size. Also, a different font and size for type can be chosen. (This is necessary if, say, you want to have a smaller window.) The default font is Segoe_print 11, but this font is not very readable at the smaller sizes, so you might want to use something else if you want a small window. Don't be afraid to play around with the display; you can always easily restore the default configuration, if the display gets messed up. The colors of the main and auxiliary windows can also be changed.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Display_zps8acf027e.png
Unit System - changes displayed units of length from english to metric. Defaults to english.
Difficulty - allows selection of either "Training Mode" or "High Realism Mode". There is a selectable crew skill level, delay factor. These are only relevent in the High Realism Mode. The program defaults to Training Mode. The details of the High Realism Mode are explaned below. Defaults to Training Mode.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Difficulty_zps4c124e9f.png
Torpedo Configuration - allows torpedo performance parameters to be edited. These include speed, reach, turning radius, bow and stern tube distance, maximum dive angle, and launch lag. The max. dive angle only comes into play if torpedoes are launched from deep submergence. The stern tube distance for the default S-18/Mk. 10 torpedo combination is an untested guess, as the SH4 version of the S - class has no stern tube.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Torp_zps35d6e6c3.png
About - self explanitory.
The program stores any changes made to a file, so it remembers your selections and there is no need to configure it each time you start it up. If the files are deleted, or corrupted, the program recreates them.
Main Window:
Here is the core of the program where the torpedo firing solution is calculated and displayed. The 8 textboxes in the top half of the window are where the firing data is entered into the program. The bottom half is where the computed firing solution is displayed. The 5 buttons at the top right control the flow of the program.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Main_zps0720b55b.png
Data boxes:
1. torpedo tubes - bow or stern. If nothing is entered will default to bow.
2. adjusted tube depth - the distance the torpedo must climb to reach set depth. Defaults to 0. Not normally important.
3. sub speed - self explanitory.
4. target speed - self explanitory.
5. target range - self explanitory.
6. track angle - the angle formed from the target's path ahead, to where the sub's path intersects. Can be either negative (port) or positive (starboard).
7. gyro angle - the angle set on the torpedoes; i.e. how much the torpedoes turn. Can be either negative (left) or positive (right).
8. target bearing - self explanitory.
Solution spaces:
1. gyro angle - restatement of gyro angle entered.
2. gyro angle, order - gyro angle indexed from 0 to 360 degrees.
3. track angle - restatement of track angle entered.
4. torpedo track angle - the angle formed by the target's track ahead measured to the torpedo track. Can be either negative (port) or positive (starboard).
5. time to position - the time in seconds for the sub and target to reach the computed firing position.
6. launch bearing - the relative bearing the target should reach for torpedo launch. This is the most critical element of the solution.
7. torpedo run time - the time required for the torpedo to reach the target from launch to impact.
8. impact bearing - the relative bearing the target will reach when torpedoes impact, assuming the sub does not change course.
9. torpedo track - the length the torpedo actually must travel.
10. target advance - the distance the target travels from the plotted refrence point to launch. Displayed mainly to aid plotting.
11. sub advance - the distance the sub travels from the plotted refrence point to launch. Displayed mainly to aid plotting.
12. calculation time - the time required for the "crew" to compute firing solution.
Only relevent in High Realism Mode.
Buttons:
Slide rule (upper left of group) - calculates firing solution.
Eraser (lower left of group) - clears data and results.
Devider/Chart (upper middle of group) - opens up window where sketch of firing is made. Allows user to edit and save sketch of attack approach.
Red cross (lower middle of group) - shuts down program and all windows.
Pencil and worksheet (upper right of group) - opens up window for auxiliary calculations.
Large button - flips image from Mk. VIII Angle Solver (in box) to functional diagram. Has no effect on program execution.
Auxiliary Window:
The auxiliary window allows different calculations to be made in one window. On the right there are 5 textboxes for the input of data, 1 or 2 boxes for output and a single button for run the calculations.
The left side has a list box with the different types of calculation options. Below this is a large button that has a diagram which changes when different calculation options are selected. The small button at the bottom left closes the window.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Auxiliary_zps86017c60.png
Setting Gyro angle - This is the most important aux. function. It allows you to set the torpedo gyros to an arbitrary value. The tubes used (bow or stern) are input in the first box, the gyro angle desired in the second. The third box isn't used for input, but only displays the gyro angle, order (not really required). The fourth box is the range setting. This is not the range to target, but the range on the TDC dial when the bearing is transmitted to the TDC. The fifth box is a place holder to remind the user that the calculation also uses the torpedo parameters stored in the Torp config. file. If there was some way to set the torpedo gyro angle directly, this function would not be needed, but alas, there doesn't seem to be one in SH4. In stock SH4 the longest range one can input into the TDC without a target selected is 1,241 yds. It is porbably best to use the longest range possible. If you desire to make a zero angle gyro shot, this process is unneccessary.
For example: if you desire to use a -40 degree gyro angle with a Mk. 10 torpedo (S- class) and input a range of 1241 yd. , the program returns a bearing of 325.4 degrees. So after putting 1,241 yds. on the TDC dial, (target speed should be zero), turn the periscope/TBT to 325.4 deg. and hit the red button. This forces the unit to change the gyro angle to -40 deg.
Timing by Wire - This allows you to estimate the target's speed by measuring the time it takes to cross the periscope reticle. Target length, time, sub speed, bearing, and Aob are input. Note that Aob can be either positive (starboard) or negative (port).
Example: a 375 ft. ship takes 22 sec. to cross the wire. It has a -75 deg. Aob at bearing 55 deg. and the sub is moving at 2.5 kts. The target is estimated to be traveling at 12.2 knots.
Aob from Aspect Ratio - The program uses actual target length, height, and observed length and height. The observed length and height can be the reticle marks on the periscope/TBT or any arbitrary unit as long as they are the same value (degrees or milliradians, for example). The program uses a mathematical model that takes into account target width making Aob estimates near 0 or 180 degrees more accurate.
Example: A target of 375 ft. length and 95 ft. height, has an observed length of 8.0 milliradians and an observed height of 3.5 milliradians. An Aob estimate of +/- 35 or +/- 145 degrees is returned. (One cannot determine which is correct by aspect ratio alone; by seeing which end is the bow and observing the direction of travel, the correct value can be selected.)
Torpedo Spread calculation - The program uses target length, spread fraction (expressed as a percentage) and the launch interval to calculate a divergent angular spread. As the program requires solution data, the calculation must be done after a firing solution is computed. The number returned is the angular spread (positive or negative) to be used between each torpedo. This is more fully explained in a comprehensive example later.
Optimum Track angle - Uses target speed and torpedo speed to calculate optimum track angle as defined by USN. This is more for player information than any specific requirement.
Sketch Function:
After you enter all the appropriate firing data, and calculate a firing solution, you may want to sketch out the approach and solution to see what it looks like, and verify that the angles and data are what you intended. This is easily done just by hitting the sketch button. The program will automatically draw out the target track, the sub track, and the torpedo track from the input reference point. The signal points, T0, T1, T3, U0, U1, U3, and P3 are indicated, as are the bearing lines between them. Additionally, the firing data and solution are written on a "notepad", and comments or changes can be made by the user. The whole drawing, with any writing or drawing made by the user, can be saved into a file for a permanent record. The window has a legend and scale in yards (or meters). Grid lines are in 1,000 yds. or m.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Sketch_zps69c488ad.png
Here are the controls used in the sketch window:
Ctrl + R Redraws sketch so orientation can be changed. Default sketch will always have sub heading north.
Ctrl + T Text boxes activated. Allows user to write in space provided in notepad. After typing out whatever one wants to write Ctrl W
must be used to finish task.
Ctrl + W Writes what user input into text boxes. Must put cursor outside text box to shift focus back to window first.
Ctrl + Z Undo for drawing items in window.
Ctrl + S Saves drawing to bitmap file.
Mouse left button Draws line on sketch.
Mouse right click Allows typing characters at location of cursor. Good for labeling of drawn items for clarity.
Note that the limitations of the programing language make for less than ideal spacing of characters when written on drawing. It is best to write out comments and such in the text boxes where the font is properly spaced.
Sometimes the points where the torpedo impacts and where the target ship are supposed to meet, do not match up exactly. There is no need to be concerned about this. It is merely a limitation in the way the language measures and draws angles. I had to compromise between getting the display in the style I wanted, and drawing precision. It is important to understand that the solution numbers are used to make the drawing, not the other way around. In other words, the numerical solution is much more precise than the drawing.
When you save a sketch, it will be in the Save folder of your installation (in bitmap form). You can, of course alter it later and/or convert it to another file format. I added a "RESTRICTED" stamp and sound effect, so you know the file has been saved.
General Issues:
Probably the most likely area for confusion in entering data would be the gyro angle or track angle. The mathematics behind this method can compute a solution for any gyro angle, but the torpedoes themselves were limited to +/- 90 degrees in the case of the Mk. 10, and +/- 135 for the Mk. 14. It is important to remember that you need to enter the values as negative for left turning torpedoes, and positive for right turning torpedoes. Similerly, the track angle must be entered as negative for port angles, and positive for starboard angles. Looking over the solution in the sketch window will usually catch these mistakes.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/General1_zpsf807e42d.png
Also, it is important to remember that the solution math/geometry is based on the relative positions at T0 and U0, the last observation before calculations are started. While later observations can be made to confirm data, or monitor the situation, the results of the calculations use this as the reference point. The time to position, target/sub advance and such are calculated from this point.
Comprehensive Example:
Step 1:
Target data is obtained by observation and plotting. Note the +141 deg. track angle
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/Plot_zpsb6cda114.png
Step 2:
Calculate firing solution.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/ExSolution_zpsd5e4115d.png
You will probably write down the most important information here. Note that the time to position is 946 sec., thats almost 16 minutes. I don't usually advise computing a final solution this far in advance, but one can compute a preliminary solution, and if it appears satisfactory, and nothing changes to disrupt you plans, you can go with it. You should always allow at least a couple minutes to set gyros, open torpedo tube doors, and perform any other last minute tasks.
Of course, it doesn't hurt to look over the sketch to verify the solution is correct, and conforms to the approach plan. If you made any mistakes in entering the approach data, you should be able to spot it here. It also makes a handy record of the attack.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/ExSketch_zps52fcb7aa.png
Step 3:
Compute gyro setting bearing.
Since it isn't possible to set the torpedo gyro angles directly, we must compute the bearing needed for obtaining the desired angle. This step is not neccessary if we want to make a 0 deg. gyro shot.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/ExAuxGS_zps4dbd86b4.png
Now we know we must turn the periscope or TBT to 308.1 deg. to set the gyro angles.
Step 4:
Set torpedo gyros
With the correct range, speed set to 0, and the periscope pointed to the calculated bearing, the red button is pushed, and you're set. After this, the slideout panels can be put back out of the way. Notice the P/S head is below the surface of the water. It is not required to do this with the target in sight, or wait until the last minute.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/ExGyroset_zpsd4729a41.png
Step 5:
Launch torpedoes as target reaches bearing.
The torpedoes are launched at desired points (from bow going toward stern) as the target passes the P/S reticle. A longitudinal spread is obtained this way. If it was desired to use a divergent angle spread, the auxiliary window would be used to calculate a spread for a given time interval, say 6 or 8 seconds. In this case, the first torpedo would be aimed near the stern (or even behind it), and the following shots advanced in the direction of the ship's travel. With this technique, only the first torpedo need be aimed visually, the remainder being launched at the prescribed interval and offset angle to obtain the spread.
For example, with the above set-up, and a 350 ft. long target, 25% coverage, and an 8 sec. launch interval, the calculator returns a 3.0 degree angle. So, the 1st torp would be launched at the stern, the 2nd 8 seconds later with a 3.0 deg. offset, and the 3rd 16 sec. after the 1st, with a 6 deg. offset., etc., etc. The 25% coverage is, of course, per torpedo. Three torpedoes would give you 75% coverage total.
Step 6:
Observe results.
Here, all three torpedoes hit the target. If no course or speed changes have been made (by either sub or target), the torpedoes will hit at the calculated impact bearing.
http://i1130.photobucket.com/albums/m526/TorpX/Tracking%20Party%20tutorial/ExResults_zps3100ca9e.png
High Realism Mode:
If you have mastered the basic technique, and wish to have a more realistic (and challanging) game, there is the High Realism Mode. In the HR mode the program computes a "calculation time" and checks for possible errors. After all, human crewmen make mistakes, and cannot complete complicated calculations in a snap.
To implement the HR mode, pull down the Realism Configuration panel by clicking on the "Difficulty" part of the menu at the top of the main window. Select the High Realism Mode of the radio buttons.
Then chose whether you want an actual delay or not. If you check the actual delay box, the calculation results will actually be delayed for a few minutes, otherwise you can implement the delay in a manor of your own choosing. This is to provide compatability for different styles of play. Some like to play with very few, if any, pauses in the game, some will often pause the game. You can use whichever option works best for you.
Finally, chose an appropriate skill level for your "tracking party". You can use any number you like (including fractional levels), but I suggest staying in the range of 1 to 5, for realistic play. Use the following as a guideline:
skill level_____________ description
1.0 .................marginal, frequently makes mistakes, substandard
2.0 ................ fair ability, but makes mistakes sometimes
3.0 .................above average ability
4.0 .................good ability, makes few mistakes
5.0 + ..............superior ability, seldom makes mistakes
I would suggest an inexperienced (but competent) crew would rate 2.0 +/- .5 on the first patrol, and if you use the technique successfully, raise it by a full point for the second patrol. For a third patrol, an increase by .5 to 1.0, and after a level of 4.0 it should not increase by more than .5 each patrol.
If the random check indicates a mistake, one of about ten quantities used in the calculations is picked randomly, and one of the digits to the left of the decimal point is changed by 1. This could result in a very large error (242 degrees changed to 342), or a small error (7350 yds. changed to 7340, a rounding error almost), or something in between. Sometimes it is possible to see the error by looking over the numbers or sketch, sometimes not. It is entirely possible for your crew to make an error, and the attack to go through and get hits anyway, and you be none the wiser. If a mistake is suspected in High Realism Mode, checking the same problem later (in Training Mode), will reveal if any mistakes were made.
Note that the solution results are displayed differently in HR mode. Angles are rounded to the nearest 1/4 degree, and distances to nearest 50.
The skill level also affects the computation time, but the change is not linear. The time it takes will never go below 1 minute no matter how high the skill level. Generally, you should try to plan your approaches so you have at least 3 minutes between obtaining the data from your last observation, and launch. It will usually take about 2 or so for the calculations, and you might need to do some other last minute tasks or checks, before launching. Note that you do not need to complete the firing solution calculation before setting the torpedo gyros or using the Setting Gyro angle task. However, the Torpedo Spread task, and the Sketch functions require a finished solution for their inputs. The main window calculation will produce a sound (of crumpled paper) when finished, to tell you it's done; the idea here is that you can set the "crew" to working on the solution, and go back to the game, and will hear when their finished.
Using this technique with the High Realism Mode, forces you to think ahead, just as it did in real life. Note that the difficulties with this sort of technique, being used to attack fast moving and zigging targets, lead to the development of the Torpedo Data Computer.
Happy Hunting! :subsim:
I was going to post this before, but it slipped my mind. I've tested this method with the Mk. 10 torpedo with the S-18 class, and the Mk. 14 with the Porpoise class. Most of the testing was done with the S-18, but, as the torpedo turning radius and reach seem to be the same, I didn't have to start from scratch. I may calculate the relevent figures for other torpedo combinations down the road.
Mk. 10 torpedo and S-18 (default):
tube distance_______85 ft.
torpedo reach______343 ft.
turning radius______310 ft.
luanch lag_________ 2.8 sec.
Mk. 14 torpedo and Porpoise:
tube distance_______112 ft. (bow)______136 ft. (stern)
torpedo reach_______343 ft.
turning radius_______310 ft.
luanch lag__________ 4.0 sec.
Arriving at these figures involved a great deal of time consuming, tedius work. It wasn't hard to obtain approximate values, but I wanted to get the most accurate figures possible.
Unfortunately, the different methods I was using didn't seem to agree. After much fruitless effort, I decided to toss out the provisional values I was using and start over. This time, I first took the trouble to tabulate the actual bearing angle that the periscope is pointed to. This was necessary because the angle indicated on the index ring is not the true angle. The number of pixels between the degree marks is not the same. On most of the dial, there are 3 pixels between marks, but on some there are only 2. Anyway, I tabulated the number of pixels from 0 to 360 so I could make my computations on the basis of the true angle. [I assume that the number of pixels and the accuracy of the index bearing ring will depend on the mods you have and your display resolution. I was using RFB here as I wanted to make use of the individual degree marks, and the stock game only has marks every 5 degrees.] After all this, the different methods used to estimate the torp performance values agreed pretty well.
My intuitive estimate of the error is that the torp turning radius is probably within 5 or 6 ft. of the true value, and the torp reach is within about 10 or 15 ft. If someone happens to know what values the game uses; please don't hesitate to speak up. :)
This is worthy of a big bump! A sticky even imo.
merc4ulfate
03-14-15, 11:30 PM
I just lead the target enough in my head and never do the math. 10 degrees is usually good enough at the ranges I fire from.
sublynx
03-21-15, 06:27 AM
I was thinking about using about using the program in SH3 and would need to find out the torpedo distance, reach and radius values for the G7e and G7a torpedoes. Measuring the distances in Attack Map F6 I got these following values.
http://i.imgur.com/XJGpQHj.png
http://i.imgur.com/cVGEylZ.png
They're pretty close to the values for the SH4 torpedoes.
Has anybody figured out working values for SH3?
AFAIK, nobody has tabulated these factors for SH3 torpedoes.
Since the US Mk. 10 and Mk. 14 seemed have identical radii and reach, I thought there was a good chance Ubi made them all the same.
About the reach; you use the expression "distance forward until fully turned". You need to know the distance the torpedo travels before it starts to turn. You also want to know the time lag (what I call the launch lag). This is the time lag for the torpedo to be ejected, and the time lost while the torpedo accelerates to speed.
I didn't have a perfect, or completely satisfactory, method for computing these values. However, you don't need them to be absolutely accurate to get hits.
sublynx
03-23-15, 11:24 AM
I see. Thanks :salute:
I'll experiment with the values. It might be that the values are identical in SH3 and SH4. No real reason for the devs to have changed them.
BigWalleye
03-23-15, 11:38 AM
My measured values for SH3 are:
Reach - 52 m
Turning radius - 97 m
Launch lag - 2.6 sec
Tube distance (from attack scope)
forward tubes - 25.8 m
aft tube - 36.1 m
Data for the Ti (Typ G7a) torpedo at 44 kts speed setting, firing platform Typ VIIb.
Using these data in Tracking Party 1.1 seems to give good results.
But these are measured data using just the in-game tools for measurement. YMMV!
sublynx
03-31-15, 10:19 AM
I found this mention:
A torpedo after leaving the tube and before starting its turn, covered a distance called reach (Germ. gerade Vorlauf), which depended on the torpedo type (types C/06 and G/6 - 10 m, type G/7 - 15 m, type G7a and G7e – 9.5 m). Then it started its turn with a radius that also depended on the torpedo type (type C/06 - 145 m, type G/6 - 100 m, type G/7 - 105 m, type G7a and G7e - 95 m).
from here:
http://www.tvre.org/en/gyro-angled-torpedoes
(I haven't had an opportunity to start using the program yet, so I don't know if the real life values are any good.)
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.