[REL] Multiple UIs for SH5 with TDC

[Vanilla]

Originally Posted by TheDarkWraith

calculated based on distance travelled from last fix. Doesn't matter if it's celestial or dead-reckoning. That way error is retained and compounded.

That is exactly as we wanted it. Here is what stroke me recently however: imagine you do DR fix with 5% error. You do a celestial fix and it gives X: +100m, Y: -50m error. Your relative coords then are: x = 100m, y = -50m. Next you travel exactly due north. After 10km run you do a DR fix again. This time you have 10km * 5% = 500m error. Imagine the error is x = 200m, y = -150m. What we get at the end is:
1st point. Real coords: (0, 0). Fixed coords: (100, -50)
2nd point. Real coords: (0, 10000). Fixed coords: (200, 9850).

However in RL with errors compounded it would be:
2nd point. Fixed coords: (100 + 200 = 300, -50 + 10000 -150 = 9800m).

Or am I wrong?

[TheDarkWraith]

Originally Posted by Vanilla

That is exactly as we wanted it. Here is what stroke me recently however: imagine you do DR fix with 5% error. You do a celestial fix and it gives X: +100m, Y: -50m error. Your relative coords then are: x = 100m, y = -50m. Next you travel exactly due north. After 10km run you do a DR fix again. This time you have 10km * 5% = 500m error. Imagine the error is x = 200m, y = -150m. What we get at the end is:
1st point. Real coords: (0, 0). Fixed coords: (100, -50)
2nd point. Real coords: (0, 10000). Fixed coords: (200, 9850).

However in RL with errors compounded it would be:
2nd point. Fixed coords: (100 + 200 = 300, -50 + 10000 -150 = 9800m).

Or am I wrong?

your first fix had error of 100m x, -50m y. The next fix is based on the last fix and thus since it was a DR fix we compound the error: 100m + 200m = total of 300m for x, -50m + -150m = -200m for y (that's how the code is going to calculate it). If the second fix was a celestial fix then error resets because a celestial fix marks a new position that all DR fixes work from.

so 2nd point fixed coords is then (300, 9800) vice actual of (0, 10000)

[brandtryan]

after reading a few pages back--it seems the sextant is still not working--but that TDW is working on it (.dds file) for next release?

[Sammi79]

Originally Posted by brandtryan

I'm having trouble figuring out exactly where to place the sextant. Assuming the Universe is configured correctly (ha, like that line) in the game, I should be able to just put the sextant next to the star (Alioth) where it should be, which my handy dandy iphone "Star Pilot" app tells me for that time and date, with a HE of 10ft. That puts the sextant so that the horizon appears at 10 degree mark. I could never figure out what the above quote from manual means--about the two checked lines at top and bottom of sextant.

You'd have to wonder though--if I come down from the bridge and walk out to bow of boat--what is my HE then? Maybe I should do that--and set HE to 0 feet in Star Pilot? Better yet, what is the exact HE in the "default" bridge view?

I'm going to review the post about not moving the sextant a few pages back--but have a feeling I'll still be confused.

Using a 'Sextant' image overlay is a troublesome and innacurate workaround for simulating a real one. The scale is derived from angular values projected onto a flat screen - which as they are represented on a flat screen are stretched the further you go from the centre of the screen. The problem is exacerbated by larger fields of view (compressing more degrees into the same space) It is hard to explain without diagrams, so to get you to see the effect for yourself :-

1. start a nightime mission in the northern hemisphere.

2. Find Polaris (last star in the tail of constellation 'Ursa Minor'

3. move your view until you can see Polaris in the centre top of your screen and the horizon at the bottom.

4. Note the actual distance between Polaris and the horizon (or Polaris and the top of your screen)

5. Pan your view left or right, keeping the horizon at the same level, until Polaris is close to either side of the screen.

6. Note the new distance between Polaris and the horizon (or Polaris and the top of your screen)

You can also see the effect by panning your view until either the sun or moon are in one corner of your display. The circular sun (or moon) will appear elliptical. It is a fundamental part of displaying 3D images on a 2D screen, and the sextant image overlay marks are calculated for 1 position only. When I use TDWs navigator sextant order button, the image pops up dead centre, top to bottom (it will do this no matter of the resolution of the sextant image, it will be scaled to fit top to bottom) which is exactly where the marks are calculated for. If you wanted a moveable sextant image, this would have to scale itself as you moved it around the screen to adjust to the differences in angular degrees over the display.

The trick for making a good sextant image, is to know exactly how many angular degrees there are displayed on your screen in the exact centre from top to bottom (a distance in pixels), then using trigonometry, calculating the position of every single mark. I sent TDW a sextant image that works on 65.84 degrees as opposed to the original 60 degrees and it is better but still not spot on.

If anyone can tell me exactly what the number should be I can make a sextant image as good/accurate as it can possibly be. The trouble is in cameras.cam the angular values for the exterior views are set at 75 degrees, which no matter how you look at it, is larger than the displayed screen (top to bottom). To make the image I need to know what the angular value of the displayed screen (top to bottom dead centre) is - I suspect between 65 and 67 degrees, Unfortunately with no means of working it out from the cameras.cam 75 degree value, It means lots of trial and error using very well known celestial objects.

Then we get down to how realistic are the celestial objects in SH5? Is polaris in game the actual celestial pole or is it shifted slightly as in real life? Height of eye calculations are important if you are standing on a sphere, however if the sea in game is rendered flat, HE is irrelevant. There is much to work out before being able to even test a sextant overlay properly. This is why if possible it would be better to implement a sort of upside down stadimeter, with a large field of view, and an angle readout. (keeping the horizon in view you move the image with polaris or other celestial body down until it is in line with the horizon, then read the angle.)

If you want to use the sextant overlay for angular measurement, It must stay dead centre top to bottom. You will find if you measure an object this way, then move the sextant image left or right and try to measure the same object, you will have a different result.

[Sea_Phantom]

So, is the stadimeter fixed in TDW's mod? I haven't been able to find that out yet

[brandtryan]

Originally Posted by Sammi79

Using a 'Sextant' image overlay is a troublesome and innacurate workaround for simulating a real one. The scale is derived from angular values projected onto a flat screen - which as they are represented on a flat screen are stretched the further you go from the centre of the screen. The problem is exacerbated by larger fields of view (compressing more degrees into the same space) It is hard to explain without diagrams, so to get you to see the effect for yourself :-

1. start a nightime mission in the northern hemisphere.

2. Find Polaris (last star in the tail of constellation 'Ursa Minor'

3. move your view until you can see Polaris in the centre top of your screen and the horizon at the bottom.

4. Note the actual distance between Polaris and the horizon (or Polaris and the top of your screen)

5. Pan your view left or right, keeping the horizon at the same level, until Polaris is close to either side of the screen.

6. Note the new distance between Polaris and the horizon (or Polaris and the top of your screen)

You can also see the effect by panning your view until either the sun or moon are in one corner of your display. The circular sun (or moon) will appear elliptical. It is a fundamental part of displaying 3D images on a 2D screen, and the sextant image overlay marks are calculated for 1 position only. When I use TDWs navigator sextant order button, the image pops up dead centre, top to bottom (it will do this no matter of the resolution of the sextant image, it will be scaled to fit top to bottom) which is exactly where the marks are calculated for. If you wanted a moveable sextant image, this would have to scale itself as you moved it around the screen to adjust to the differences in angular degrees over the display.

The trick for making a good sextant image, is to know exactly how many angular degrees there are displayed on your screen in the exact centre from top to bottom (a distance in pixels), then using trigonometry, calculating the position of every single mark. I sent TDW a sextant image that works on 65.84 degrees as opposed to the original 60 degrees and it is better but still not spot on.

If anyone can tell me exactly what the number should be I can make a sextant image as good/accurate as it can possibly be. The trouble is in cameras.cam the angular values for the exterior views are set at 75 degrees, which no matter how you look at it, is larger than the displayed screen (top to bottom). To make the image I need to know what the angular value of the displayed screen (top to bottom dead centre) is - I suspect between 65 and 67 degrees, Unfortunately with no means of working it out from the cameras.cam 75 degree value, It means lots of trial and error using very well known celestial objects.

Then we get down to how realistic are the celestial objects in SH5? Is polaris in game the actual celestial pole or is it shifted slightly as in real life? Height of eye calculations are important if you are standing on a sphere, however if the sea in game is rendered flat, HE is irrelevant. There is much to work out before being able to even test a sextant overlay properly. This is why if possible it would be better to implement a sort of upside down stadimeter, with a large field of view, and an angle readout. (keeping the horizon in view you move the image with polaris or other celestial body down until it is in line with the horizon, then read the angle.)

If you want to use the sextant overlay for angular measurement, It must stay dead centre top to bottom. You will find if you measure an object this way, then move the sextant image left or right and try to measure the same object, you will have a different result.

Thanks for the explanation! I'll have to curb my enthusiasm for doing celestial fixes for now. I'd offer a hand, but admit it's a bit over my head (by how much, I don't know)

[Jaeger]

Originally Posted by Vanilla

Another question I would like to ask is it possible to automate nav fixes?
Here is the idea:
The game simulates what captain should be doing so removing navigator almost completely making him just providing fixes is putting to much burden on the captain. Why don't we make it this way:
1. During normal travel the navigator makes dead-reckoning fixes automatically at predefined periods (say, every hour) and when some events happen: dive / battle-stations ordered, turn or speed change ordered or when Kaleun requests a fix. Error is compounded directly (as in my prev. post).
2. When the navigator makes a new fix - draw a line from the last fix to the new one - so you can actually see your path.
3. At some points of the day: sunset, sunrise, noon, midnight - automatically make a celestial fix putting it on the map following the rules as above.
3. When on battle stations - radically shorten fixes period: make it every 1 or 5 minutes or when course/speed/depth change ordered. So you can check your posit under DC attack etc.
4. Disable celestial fix when on battle stations (I cannot imagine navigator going up with sextant and shouting 'Mark!!!' during deck gun action or manoeuvring into position for surface torpedo attack).

By the way is it possible to order battle stations simultaneously with crash dive?

very good input here, i was thinking about this too! good point mate!

[Sammi79]

Originally Posted by brandtryan

Thanks for the explanation! I'll have to curb my enthusiasm for doing celestial fixes for now. I'd offer a hand, but admit it's a bit over my head (by how much, I don't know)

Nevermind I have a particular knack of not being able to explain things succesfully. Someone else out there must have an idea what I'm talking about though, And if you follow my instructions 1-6 you will see the described effects. I think I might have found a way to measure the angular values of the displayed screen. TBC...

[TheDarkWraith]

Originally Posted by Vanilla

Another question I would like to ask is it possible to automate nav fixes?
Here is the idea:
The game simulates what captain should be doing so removing navigator almost completely making him just providing fixes is putting to much burden on the captain. Why don't we make it this way:
1. During normal travel the navigator makes dead-reckoning fixes automatically at predefined periods (say, every hour) and when some events happen: dive / battle-stations ordered, turn or speed change ordered or when Kaleun requests a fix. Error is compounded directly (as in my prev. post).
2. When the navigator makes a new fix - draw a line from the last fix to the new one - so you can actually see your path.
3. At some points of the day: sunset, sunrise, noon, midnight - automatically make a celestial fix putting it on the map following the rules as above.
3. When on battle stations - radically shorten fixes period: make it every 1 or 5 minutes or when course/speed/depth change ordered. So you can check your posit under DC attack etc.
4. Disable celestial fix when on battle stations (I cannot imagine navigator going up with sextant and shouting 'Mark!!!' during deck gun action or manoeuvring into position for surface torpedo attack).

By the way is it possible to order battle stations simultaneously with crash dive?

With Patch 3 for v5.9.0 I added two new Automation commands that allow you to script the navigator taking a dead-reckoning fix or a celestial fix. It appears that I need to add another command to Automation - Wait_for_time. This command would allow you to specify a time (either GMT or local) and when the command is executed will put the script in 'pause' until the time specified is reached. After time is reached script will resume with next command. This would allow you to script the morning, noon, and nighttime fixes.

4 above is a good point and I need to make changes in the files to accomodate this

[col_Kurtz]

Originally Posted by TheDarkWraith

find this line:

MostFuelEfficientSpeedHotKey = [ False, MenuKeyManagerWrapper.Keys.M, False ] # change the M to whatever you want. You can't use M!

and change it to:

MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.G, False ] # change the M to whatever you want. You can't use M!

Back to question...
Something is wrong... with me? TDW look at this command lines. Now it`s look like that:
# the hotkey used to order most fuel efficient speed
# Format:
#
# MostFuelEfficientSpeedHotKey = [ False, None, False ] here False or True?
# False = disabled
# None = key used
# False = shift required
#
# if you wanted to enable this without shift required:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.N, False ]
#
# if you wanted to disable this:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.N, False ]
#
# Note: Keys.M is used by the Navigation Map in the stock game! It was used only as example here. Also the hotkey will only be recognized if the sub is surfaced

And after start Harbour Pilot in Kiel, hit the button N U-boot increase the speed to 10kts:/ I got next question. Brackets still required?

[TheDarkWraith]

Originally Posted by col_Kurtz

Back to question...
Something is wrong... with me? TDW look at this command lines. Now it`s look like that:
# the hotkey used to order most fuel efficient speed
# Format:
#
# MostFuelEfficientSpeedHotKey = [ False, None, False ] here False or True?
# False = disabled
# None = key used
# False = shift required
#
# if you wanted to enable this without shift required:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.N, False ]
#
# if you wanted to disable this:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.N, False ]
#
# Note: Keys.M is used by the Navigation Map in the stock game! It was used only as example here. Also the hotkey will only be recognized if the sub is surfaced

And after start Harbour Pilot in Kiel, hit the button N U-boot increase the speed to 10kts:/ I got next question. Brackets still required?

The '#' symbol means a comment and is ignored by the game (used for adding documentation in the .py files)
Note: if the key you are defining (in this case N) is defined in the commands.cfg file then the commands.cfg file will override it and you'll never see it work

copy and paste the following into your options file (overwriting the original):

# the hotkey used to order most fuel efficient speed
# Format:
#
# MostFuelEfficientSpeedHotKey = [ False, None, False ]
# False = disabled
# None = key used
# False = shift required
#
# if you wanted to enable this without shift required:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.M, False ]
#
# if you wanted to disable this:
# MostFuelEfficientSpeedHotKey = [ False, MenuKeyManagerWrapper.Keys.M, False ]
#
# Note: Keys.M is used by the Navigation Map in the stock game! It was used only as example here. Also the hotkey will only be recognized if the sub is surfaced
#
MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.N, False ] # change the M to whatever you want. You can't use M!

[TheDarkWraith]

Originally Posted by Trevally.

An automation script could plot the celestial fix and dead-reckoning fixes as you discribe.
I think there would need to be a second auto script for battle staations.
This would mean you would have to stop normal fixes and start the dead reckoning one when you need it.

I added a new Automation command - Wait_for_time. Does what it says and it can also print a message to the messagebox when the time has been reached.

I also updated the Automation command Report_position_celestial. If Battlestations are activated then he will take a dead-reckoning fix instead.

The Navigator's order of Report Position Celestially is unavailable (greyed out) when Battlestations are set.

Changes will be seen in v6.0.0.

I sent Trevally v6.0.0 as of now so he can play with the Automation changes.

[Trevally.]

Thanks TDW

For "Wait_for_time,x,y,a,b,0,0,t" if I set script to check at local time-

1200 noon
2000
0000
0600

user loads game and runs script (local time 1300) then it will be 23hrs before first fix

[TheDarkWraith]

Originally Posted by Trevally.

Thanks TDW

For "Wait_for_time,x,y,a,b,0,0,t" if I set script to check at local time-

1200 noon
2000
0000
0600

user loads game and runs script (local time 1300) then it will be 23hrs before first fix

it would be 7 hrs before first fix (2000 - 1300 = 7 hours). I would recommend using GMT time though. There is a chance you could cross a nautical time zone and thus miss a fix using local time (it's a rat race as to whether the Wait_for_time command would catch the time before the nautical time zone kicked in. Something to be aware of).

[Trevally.]

Here is the test I ran :-

[AS]
Real Nav Auto Fix timed GMT
[DESCRIPTION]
test fix by GMT
[DESCRIPTION_END]
[CATEGORY]
Real Navigation
[SUBCATEGORY]
Position on patrol
[COMMANDS]
Report_position_celestial,0,0,0,0,0,0,0
Wait_for_time,12,00,0,Noon Fix,0,0,0;(1200GMT)
Report_position_celestial,0,0,0,0,0,0,0
Wait_for_time,19,00,0,Post Meridian Fix,0,0,0;(1900GMT)
Report_position_celestial,0,0,0,0,0,0,0
Wait_for_time,00,00,0,Post Sunset Fix,0,0,0;(0000GMT)
Report_position_celestial,0,0,0,0,0,0,0
Wait_for_time,05,00,0,Pre-dawn Fix,0,0,0;(0500GMT)
Report_position_celestial,0,0,0,0,0,0,0
Wait_for_time,07,00,0,Ante Meridian Fix,0,0,0;(0700GMT)
Report_position_celestial,0,0,0,0,0,0,0
Loop,-1,0,0,0,0,0,0
[COMMANDS_END]

Worked very well

Using GMT to avoid missing a fix if crossing a time zone means-
To get nav officer to call noon fix it must be noon local time.
most of the game is played :-

GMT 0 +/- 3

how to offset

Also does anyone have suggestions as to the correct time to hit sunset etc during North/South and seasonal changes