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)

Status of Sextant
 

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?

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.

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

:doh: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) :damn:

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

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. :ping: I think I might have found a way to measure the angular values of the displayed screen. TBC...

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 :yep:

MostFuelEfficientSpeed hotkey...
 

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!

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.

Thanks TDW:up:

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:06:

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).

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:up:

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

:hmmm: how to offset:06:

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