Good bug report :up: Actually that's not the only thing not dropping TC to 1. Anytime I'm adding any messages to the messagebox it's not dropping to TC1. If the game adds them it does. Problem fixed now :DL

Revamped the user options regarding real navigation:

######################################### Real Navigation ############################################
# the error (expressed as decimal) for the Navigator's calculation of current position (fix) using celestial navigation (used in real navigation only). This is the max error in meters. It will be used as the -min value and max value of a random function
# below is an float value only! (in meters)
NavCelestialMaxCalcFixError = 5000.0

# the minimum time it takes the Navigator to calculate the current position (fix)
# below is in seconds
NavCelestialCalcFixMinTime = 900.0

# the maximum time it takes the Navigator to calculate the current position (fix)
# below is in seconds
NavCelestialCalcFixMaxTime = 2700.0

# does navigator show position on the maps after he calculates current position (plots a new navigation fix)?
# change below to either True or False
NavShowPositionOnMapsAfterCalc = True

# if NavShowPositionOnMapsAfterCalc enabled, how long does the navigator show the calculated position on the map?
# below in seconds
NavShowPositionOnMapsAfterCalcTime = 20.0

# the error (expressed as decimal) for the Navigator's calculation of current position (fix) using dead-reckoning (used in real navigation only). This is the max error in meters. It will be used as the -min value and max value of a random function
# below is an float value only! (in meters)
NavDeadReckoningMaxCalcFixError = 1000.0

# minimum time it takes Navigator to plot position based on dead-reckoning
# below is a float value only! (in seconds)
NavDeadReckoningMinCalcTime = 15.0

# maximum time it takes Navigator to plot position based on dead-reckoning
# below is a float value only! (in seconds)
NavDeadReckoningMaxCalcTime = 60.0

How do those look :06:

Lookin' good mate :up: one thing though, re yellow highlight above, how is the max error scaled, 0% at 0hr(since last fix), 50% at 12hrs etc? If it was scaled with distance travelled instead I.e. 0% @ 0km, 50% @ 50km etc it would make more sense. If you don't move then your next dead reckoning error should be 0. Of course I realise this involves more math to find the distance between fixes (or more correctly between real locations at time of fixes) and may be more trouble than it is worth. Also, can the scale exend the maximum error? - 500% @ 500km :06:

I have no problem making it based on distance travelled vice time. In order to do so we must define all the variables. The variables that come to mind to me are:

- max error %
- max error % based on distance travelled or fixed value?

Let's say we do it by distance travelled. We define the max error % to be 0.15 (15%). We feed this max error % into a random function with the minimum value of -max error % and max value of max error % (so we can get a + or - error %) to get a random error % to simulate real life conditions (sometimes navigator is extremely accurate sometimes he's not - human nature of error). We then take that random error % and apply it to the total distance travelled between fixes. Take the result of that and add it to total distance travelled to get new fix position. How does that sound? :06:

Enable...
 

Dear TDW...

I can`t figure out how to enable this hotkey... Could you retype? This is for me a bit complicated:oops:

# what is the most fuel efficient speed?
MostFuelEfficientSpeed = 7.5

# the hotkey used to order most fuel efficient speed
# Format:
#
# MostFuelEfficientSpeedHotKey = [ False, None, False ] should be None?
# False = disabled
# None = key used
# False = shift required
#
# if you wanted to enable this without shift required:
# MostFuelEfficientSpeedHotKey = [ True, MenuKeyManagerWrapper.Keys.M, False ] True... and MenuKeyManagerWrapper.Keys.G?
#
# if you wanted to disable this:
# MostFuelEfficientSpeedHotKey = [ False, MenuKeyManagerWrapper.Keys.M, False ]True... and MenuKeyManagerWrapper.Keys.G? again?

I`d like without Shift.

@ TDW

Right, bear with me I'm wishing I was more articulate...

Say the default max dead reckoning error (set in useroptions.py) = 1000.0 (meters float) as it is currently.

Scaling the error depends on distance travelled since last fix. So say 1km travelled = 0.01 (1%) of default error = 10 meters. 10km travelled = 0.10 (10%) of default error = 100 meters. Using this scale, at 100km travelled, error = 1000 meters (1.0 or 100% of default error)

can it then extend the error? I.e. 500km travelled = 1000.0 x 5.00 (500%) = 5000.0 meter.

This is how I think it should work, the default error does not need to change as the scale does the work. maybe instead of setting the default error in useroptions.py the scale (per km) would be a more usefull value - 0.01 per km to start with then maybe increased a little if after 100km, 1km error seems too small.

[Edit : Having reread your previous post regarding the variables :

(default max error float) = 1000.0 - unchangeable only used by game.
(scale per km %) = 0.01 - configurable in options.

As I look at it now there would be no true maximum error for dead reckoning, the further you travel, the bigger the possible error will be. Until that is you get a new celestial fix to start from.]

Is this making sense or am I just confusing the issue?

Regards,
Sam.

Hi TheDarkWraith. At me such question. What for to use such big Card (WorldMap)? Probably, to Australia, India or Japan nobody will float. There "is empty"... Can use only region "Atlantic"?:hmmm: (It is difficult for making?):06:

http://www.subsim.com/radioroom/pict...pictureid=3463

The way you propose doesn't give any randomness to the error. It's always a fixed value based on distance. That doesn't simulate human error.

The way I'm calculating it doesn't need scaling. Scaling is taken care of via the distance travelled.

i.e.: the random error % is applied to distance travelled. If random error % is say 0.1 and:
- distance travelled is 100m then error is 10m
- distance travelled is 1000m then error is 100m
- distance travelled is 10000m then error is 1000m

As you can see the error automatically scales to the total distance between fixes. I like the random error % because sometimes navigator can be accurate, sometimes inaccurate (tired, stressed, etc.). This more simulates real life.

The only snag in this whole distance travelled is I don't record every movement of the sub. i.e. I don't record every turn, every speed up, slow down, etc. Thus the error distance calculated will be applied to a random function to determine the x component of the error distance and another random function to determine the y component of the error distance. i.e.: error distance comes out to be 1000m. 1000m will be passed into two random functions as -1000 and 1000 to detemine the final x and y components to add to the current fix to determine final fix position.

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!

I had requests for the ability to start out anywhere in the world and to be able to choose that from the mission settings box. What I've done allows you to do so.
Is there a problem with this? :06:

Edit : Disregard I think you have it covered in your last post. the random error % thing sounds perfect.

No problem.:)
Make maps of convoys in the style "IO_StrategicMap". Intended to use it twice as "MapConvoy" and "WorldMap". (at the same time to verify the correctness of markings Convoys on the map)...

http://www.subsim.com/radioroom/pict...pictureid=3464

So far it appears to be working much better than error based on time between fixes :D I'll release patch 1 here soon with these changes and other bug fixes.

cool it would be:rock::arrgh!::woot:

results of testing error based on distance (dead reckoning):

errorX and errorY are the distances to add (or subtract) from calculated position fix to account for error

test #1:
distance travelled = 68128m
error% = 0.1058
errorX = 5468m
errory = 4712m

test #2:
distance travelled = 48891m
error% = 0.025
errorX = 240m
errory = 1018m

test #3:
distance travelled = 54852m
error% = 0.158
errorX = 1276m
errory = 128m

test #4:
distance travelled = 24146m
error% = 0.025
errorX = -44m
errory = 518m

test #5:
distance travelled = 24420m
error% = 0.1365
errorX = -622m
errory = -863m

test #6:
distance travelled = 1830m
error% = 0.0334
errorX = -49m
errory = 30m

Results look very good :rock: Good randomness in the actual plotted position based on error. It makes it appear that Navigator is trying to account for waves, wind, and human error.

v5.9.0 patch 1 released. See post #1 for details :|\\