Celestial Navigation Revisited [Archive] - SUBSIM Radio Room Forums

11Bravo

04-02-12, 03:00 PM

Returning to Silent Hunter 3 after a long absence...happy to see many of the old Kaleuns...:arrgh!:

I am interested in the old problem of celestial navigation within Silent Hunter. I am familiar with the important work done by vanjast on RealNav and the excellent Stellarium workaround advocated by don1reed. I am familiar with the old problems...with the clock, the sun, the moon, the lazy helmsman, and the tantalizing accuracy of the stars...

What I want to know is if the state of the art has been advanced since then? Have any of the old problems been solved in SH3 or SH4 or SH5?

I have a special interest in knowing this, because before I left back in 2009, I was working on my own celestial navigation mod. I focused only on understanding navigation by the stars since others seemed to be working on the sun, dead reckoning, hiding the boat on the map. It was very difficult, but I was finally able to fix a position by the stars to within 120 km...or was it 30 km :doh:...nearly all the time...and at the time that seemed pretty good to me.

I never finished my mod because it was more work than I was capable of accomplishing at the time. Anyway, I don't have my old files anymore :x but I remember what I did. And I feel like doing it again. But not if someone has already done better.

postalbyke

04-03-12, 12:03 AM

I haven't read anything really exciting recently, all I remember is getting good latitude but no longitude :O: I'm interested in another celestial navigation mod!

TheDarkWraith

04-03-12, 07:05 AM

What I want to know is if the state of the art has been advanced since then? Have any of the old problems been solved in SH3 or SH4 or SH5?

For SH5 you'll want to look into my Real Nav mod for my UIs mod :up: Being that SH5 let's you use Python to extend the game we can do many things that the other series only dream of.

TorpLos

04-05-12, 04:33 PM

vanjanst created a RealNavMod some time ago. It was pretty great. However it interferred with my MagUI and other mods because it changed the map so much. So i did not end up using it,

However now that ive started again and swore to myself to keep my Sh3 Modification simple im definately going to give this mod another whirl. Great for realism.

http://www.subsim.com/radioroom/showthread.php?t=113975&highlight=RealNav+Mod

There is the link and OG post.

Ack i forgot the damn RealNavMod baiscally only works with vanilla SH3. NYGM cant run it and i know GWX cant run it either. Lot of MENU ID xxxxx errors come up. However the game still loads after you close all the errors, but a few things are wrong and im sure its not running at full efficiency. Wish there was a way to get it to work. Its such a wonderful mod and the tutorials are great.

11Bravo

04-06-12, 05:48 AM

@TorpLos

I mentioned vanjast's RealNav in my first post. I think it was the best in-game effort at navigation. All mods risk interfering with each other because they try to modify the same game element or affect something the other mod relies on. I will try to show all my work so somebody can create their customized version that works with their soup of mods.

@postalbyke

It seems the state of the art hasn't advanced much and the old problems have not been solved. I will be solving a few of them which will improve things quite a bit.

@TheDarkWraith

:o Cool, huge, mod. SH5 does seem a different beast. I don't own SH4 or SH5 so I will be working here on SH3. I would appreciate your feedback if I find something that benefits the SH5 users. I read some of the threads, and my impression was that the star shots are performed out-of-game with Stellarium?

TorpLos

04-06-12, 04:10 PM

:rock:Good luck Bravo im excited for a good NaVmod that works well with MegaMods!

Wolfstriked

04-06-12, 04:21 PM

11Bravo

04-06-12, 04:47 PM

@ TorpLos

"Some assembly required." I will be releasing my findings and tools in pieces so others can use as they see fit. Hopefully there will be enough success to make it worthwhile for the megamod authors to do the work for me...:har:.

@ Wolfstriked

I will do my best, but RealNav should already have that. My early work will require all the stock tools to help in testing and development. We will see where it leads...:ping:

11Bravo

04-07-12, 12:57 PM

I am proud to share with you the previously unknown voyages of U-boat U-13 "der Seeesel" captained by Herman Engel and his navigation challenged officers. These prewar voyages were to develop Navigation techniques and this first voyage was to test out the super secret SH3 clocks...

Voyage 1

Here are some observations about the two clocks in SH3. I call them "Screen Time" and "Mouse Time", but most of us think of them as Greenwich Mean Time and Local Time. There is also a "Mouse Date". There is no mention of what these really are in the manual. The game seems to think "Mouse Time" is the local time, though.

It's important to have a clear understanding of time and position if we are going to navigate. So I made a mod that would show the time zone lines and the Lat/Lon coordinates. Then I made some missions that took me to known locations so I could check things out. Let's take a look at what I am talking about...

http://img442.imageshack.us/img442/37/mission1.png

The mod uses Nautical Time Zones, which are the negative of Civil Time Zones. You can read more about it here http://en.wikipedia.org/wiki/Nautical_time. The important thing to remember is that GMT=T+TZ where T is the local time (Zone Time) in the time zone, and TZ is the nautical time zone description (a number from -12 to +12). Time Zones are 15° wide of course and TZ 00 straddles the Greenwich Meridian.

Here's what we can see already by looking at some screen shots of the clocks when I loaded the missions. The mission editor determines the Screen Time and the Mouse Date. Right off the bat it looks like Mouse Time is the Zone Time (Local Time in the zone) and that the Screen Time is the GMT. And the mouse shows us the Date as well...but which date?

11Bravo

04-07-12, 01:10 PM

First we will sit and wait a day at a fixed location and observe how the times and date change.

http://img840.imageshack.us/img840/4438/mission1a.png

Notice that the Mouse Date did not increment when the Mouse Time rolled over. If Mouse Time is the Local Time, then the Mouse Date is not the local date.

The Mouse Date does increment when the Screen Time rolls over. So the Mouse Date belongs to the same Time Zone as the Screen Time. If the Screen Time is the GMT, then the Mouse Date is the Date of TZ 00.

So the current theory is that the screen gives us the GMT and the mouse gives us the local time and the GMT date.

11Bravo

04-07-12, 01:32 PM

Now lets cross over the Time Zone lines and observe how the clocks change. We can also do some time-speed-distance calculations to see if we believe the clocks are accurate.

http://img835.imageshack.us/img835/53/mission1c.png

http://img542.imageshack.us/img542/8116/mission1b.png

If you squint you can see the 1° grid dots on the map. The spacing is 120 km and the Screen Time measures the same in both directions and is unaffected by the Time Zone line located midjourney. TSD gives 14.2 knots consistent with the screen shots.

The Mouse Time jumped +1 hours when crossing East and jumped -1 hours when crossing West. It is behaving like a local time should. And it matches what we observe above when the game loads the missions.

So far our best theory is the Screen Time is the GMT and the Mouse Time is the Zone Time and the Mouse Date is the Date of GMT. We can use Time-Speed-Distance and perform Dead Reckoning. Most of us know that the SH3 world is flat and 1° is 120 km and the shortest distance between two points is a line.

There seems to be nothing wrong with this theory of the game clocks...until you attempt celestial navigation.

11Bravo

04-07-12, 02:09 PM

We are going to compare some calculated and observed sunrise times. The calculated times came from some software, but you can get similar results from this website http://aa.usno.navy.mil/data/docs/RS_OneDay.php. The values are calculated for the positions shown, and are expressed as GMT and as the local Zone Time. Also shown are screen shots of the sub's clocks at each position so you can compare GMT, Zone Time, Mouse Time, and Screen Time.

The sun appears to come from the East of course, so the GMT when it arrives becomes later as your location is chosen further to the West. The calculated GMT's show that nicely in the Table. So we should also expect one of the sub's clocks to show this same trend. ALLLLLLLLAAAAAAAAARRRRRRRMMMMMM!!!

http://img339.imageshack.us/img339/6493/mission1d.png

The Screen Time was our hope for being the GMT, but it doesn't show the right trend and it gives plainly wrong answers outside of TZ 00. The Mouse time is even worse.

Now look at the calculated Zone Times for the sunrises. These Zone Times are the local times at the observing positions. The times are simply the GMT - TZ as you would expect from the equation I have plastered over every screen shot.

Looking again at the screenshots of the sub's clocks, we see that the Screen Time now appears to be the local Zone Time! What seemed so certain from before now appears to be completely wrong! How could the Screen Time be the GMT of the sea and the local Zone Time of the sky?

Let's check the sunset times to be sure...

http://img35.imageshack.us/img35/4692/mission1e.png

Ugh...same story.

Again, because the sun appears to come from the East, the GMT of a sunset becomes later as the observing position moves to the West. Again, we see this trend nicely in the calculated sunsets. And again, the screen shots of the clocks from our sub show that neither one is the GMT we seek. Instead, the Screen Time is actually the local Zone Time as before.

It is nice that we get good agreement between one of our clock's and the local sunrise and sunsets. It is nice that one of the clocks matches closely with observed celestial evens. But we need the GMT if we are to calculate the positions of stars used for celestial navigation.

Let's see if we can figure this out...

11Bravo

04-07-12, 03:12 PM

To recap, we had a perfectly good theory of how the game clocks work that is consistent with stuff happening on the sea. The Screen Time played the role of GMT that stays constant across Time Zone lines. The Mouse Time jumped around like a good local time should.

But the theory fell apart when we tried to use if for stuff happening in the sky. So we need a new theory for the sky. This time the Screen Time plays the role of Local Time because it agrees with the observations. But the Mouse Time isn't the GMT either, and appears worse than useless at first glance.

But look back at the observations of how the Mouse Time jumps when we cross a Time Zone Line. Take a good look at the Time Zone, the Mouse Hour, and the Screen Hour. There is a relationship there.

Let the Mouse Time be hhmm
Let the Screen Time be HHMM

In each instance the known TZ is equal to HH-hh. If you get a TZ outside of +/- 12 just add or subtract 24.

That means if we didn't know the TZ, we could look at the time difference between the two clocks and calculate it. And that means we could add it to the Screen Time and get the GMT necessary for celestial navigation.

Let's see what that new theory might look like for some observations in the 3 time zones. First the sunrises, and then the sunsets.

http://img215.imageshack.us/img215/9527/mission1h.png

http://img16.imageshack.us/img16/2591/mission1g.png

Let's check the observation at 0°N 8°W first.

At sunrise you see 05:39 on your Screen Clock, so you call this the local Zone Time T. You note that the TZ is HH-04 which means 05-04=+01. So you are West of the Greenwich Meridian. You add the Time and the Time Zone to get the GMT of 06:39 which compares with the calculated SR of 06:36 GMT.

At sunset you have T= 17:39 and TZ = 17-16 = +01 and GMT = 17:39 + 01 = 18:39, which compares with 18:43.

Now let's check the observation at 0°N 8°E.

At sunrise you get T= 06:35 and TZ = 06-07 = -01. This gives the GMT = 06:35 - 01 = 05:35 which compares favorably with the 05:32 of the table. At sunset we get a T=18:34 and TZ = 18-19 = -01 and GMT = 17:34 compared to 17:39.

The theory seems to be working, but only time will tell :har:

11Bravo

04-07-12, 03:22 PM

What does it all mean?

It means the SH3 Gods Must Be Crazy. It seems that the developers created one time system for the sea and one for the sky. Hopefully I'm wrong and this is all just a terrible mistake.

There is no reason not to continue using the Screen Time as the GMT for all the usual time non celestial navigation duties. In fact, there is no way that the Screen Time could really be a local Zone Time because the Screen Time doesn't change when you cross Time Zone boundaries. It isn't realistic, but it seems to work for the observations of the sky above, and might hold up to more observations by interested Kaleuns. Those who do so should report their observations here. I am interested in hearing your experiences.

I will post links to the tools I used in this first voyage after U-13 returns to port. :arrgh!:

TorpLos

04-07-12, 10:14 PM

Have you tested the compatibility with the mega mods?

11Bravo

04-08-12, 03:57 AM

The first time I tried to create this mod, I ran out of time and energy before I completed it. I left SH3 and then the files were lost. I had something to contribute to the community but I waited until it was perfect and ended up contributing nothing. This time I will show my work as it is performed so the successes and failures have some value to those interested. Feel free to use my work in your own mods.

I have a link in my signature to the files I am using. All of the mini mods will come with instructions for how I did my modding. I used GWX for the first voyage but might use a different GUI for one of the next voyages.

Here is what is available for download now. All JSGME compatible and documented. If you want to know how I did something, ask me and I will update the documentation.

Utility/Testing Mini Mods
11Bravo - Blank Campaign {Empty campaign files for fast loading during testing}
11Bravo - No Movies {Empty movie folders for fast loading during testing}
11Bravo - Navigation Missions {Pre-War missions used to understand the SH3 world, time, and sky models}

The first voyage was to understand how SH3 handles latitude, longitude, time, time zones. So the important mini mods are the chart and the clock.

Navigation Mini Mods
11Bravo - Nautical Chart {replaces your Map1 and Map2 files to give you accurate latitudes, longitudes, and nautical time zone lines }
11Bravo - Nautical Clock {modifies the xx_menu.txt file}

The megamods make heavy use of a few core files. Any small mod that comes along must learn to coexist. The two most common files are the menu_1024_768.ini and the xx_menu.txt. So here is the documentation for the Nautical Clock mod that allows you to manually mod your custom installation.

Modifies:

\data\Menu\en_menu.txt (existing file)

The xx_menu.txt files are often changed by the supermods. It would be best to manually edit the xx_menu.txt file of the supermod of your choice.
Comment out entry 2703, and replace as shown below.

2703=|T: HHMM TZ: HH-%02d GMT: T+TZ|
;2703=|Local time: %02d:%02d

11Bravo

04-08-12, 04:06 AM

@TorpLos (http://www.subsim.com/radioroom/member.php?u=291963)

I am sure the clock mod will interfere with any megamod, so instructions for how to manually mod the en_ment.txt file are included.

The chart mod is a simple replacment of the two files that make up your navigation maps.

The quickest way to test anything out is to use JSGME to disable all your old mods, fire up the new one, and then begin your testing to see if it is incompatible. The utility mods I included make loading a lot faster during the testing process. If you hit an incompatibility, then you resort to manual editting of the megamod files...:doh:

11Bravo

04-08-12, 04:47 AM

Here is the celestial navigation checklist

Nautical chart -- Mostly Done. The SH3 world is a cylinder with a grid spacing of 1° = 120 km. The mission editor outputs a simple text file that allows lat/lon to be entered in meters. This means simple time-speed-distance calculations should work at any latitude or heading and are easily tested with the tools on board. Current version of the chart is available for testing.

Nautical clocks -- In Testing. Accurate GMT/Local Time necessary for calculation of positions of stars. Looks like SH3 uses a separate time models for the sea and the sky. Sky GMT = T + TZ. TZ = HH - hh. Screen Clock gives T=HHMM. Mouse Clock gives hhmm. Available now.

Sextant -- In Development. Accurate elevation measurements are required for celestial navigation. Current sextants in SH3 are less accurate than necessary. My next project.

Celestial Data -- Not Started. SH3 might not calculate and display the proper positions of the stars, sun, and moon. The consensus is the stars look right, the sunrise/sunsets are close, and the moon is wrong. Will need to make many observations with accurate tools.

So the U-13 departs the Gulf von Guinea with orders to return to Kiel for a secret sextant development project. Nervous of a channel crossing in even these pre-war years, Bernard steers a heading of SW for the long way around...besides, it gives a chance to test the new clocks.

TorpLos

04-08-12, 12:02 PM

Glad your deciding to go all in on this project Bravo! I cant wait to chart my uboot with only the guide of the stars and sun!

And i hope i can get it working with my megamod and any other little mods i have. I always thought that it shouldnt be so difficult since its mostly the maps and a few options changing...

11Bravo

04-13-12, 04:51 PM

What does it all mean?

It means the SH3 Gods Must Be Crazy. It seems that the developers created one time system for the sea and one for the sky. Hopefully I'm wrong and this is all just a terrible mistake.

I was wrong and that is a good thing, because now I understand the SH3 clocks.

When you start a mission or a campaign, SH3 remembers the starting time zone, lets call that Base Time Zone, or BTZ. The two clocks are then offset from the correct time by the BTZ.

The theory I originally developed was based by studying the sunrise and sunsets after loading single missions with the mission editor. I tested the theory by cruising to different time zones and was getting the wrong results. I went back to the drawing board and made some new observations.

11Bravo

04-13-12, 05:03 PM

http://img29.imageshack.us/img29/9360/mission1i.png

I started this mission at 0°N 45°W in nautical time zone +03, which is now my base time zone, or BTZ. SH3 attempts to display the local time as the mouse time and the GMT as the screen time, but they are wrong. They are both offset from the correct time by the BTZ. I cruised from the starting position East making observations of sunrise and sunset.

Displayed above are the sunrise and sunsets together with the almanac data for the positions on those dates. If you add the BTZ to the dates SH3 displays, you will match the almanac times of sunrise and sunset.

Below are the results when I started at 0°N 45°E with BTZ -03 and cruised West.

http://img26.imageshack.us/img26/4324/mission1j.png

11Bravo

04-13-12, 05:20 PM

What does all of this mean?

It means that the clocks in SH3 work when you correct them for an offset I will call Base Time Zone. Simply know the starting nautical time zone of the campaign or mission and subtract that number of hours from the two clocks and you will know the correct local or GMT time.

Thus ends the first voyage of the U-13. The purpose was to develop a nautical chart and nautical clocks necessary for celestial navigation. BDU is satisfied with the results. They decide that further testing of the clocks will require higher precision measurements than simple sunrise and sunset. We will need to make accurate measurements of the star positions.

Next up will be an accurate sextant. That will be the work of the second voyage. Here is a preview of the result using the prototype...

http://img838.imageshack.us/img838/8374/prototypesextant.png

11Bravo

04-13-12, 08:13 PM

Now we are back at port let us talk about accuracy of positional measurement. Let us assume for now that SH3 displays the positions of the stars correctly. We can't determine that without an accurate sextant, so we will have to assume it for now. What type of measurement errors could we expect?

We need to think about the resolution of time and position. We need to think about what is possible. And what is necessary.

If we have a 8km or 16km environment for micro scale work like hydrophones or visual, then I think we can agree that 30km or 120km accuracy is good enough for macro scale work like rough positioning. Is that possible in SH3?

We should consider time first. SH3 has a stop watch that allows seconds to be added to the two clocks. My testing shows that the seconds are good to about 5 seconds for normal use. Heavy time compression and extended use will actually cause the second hand to stop working on 1X TC. Let the stopwatch run for 24 hours and it keeps accurate to about 5 seconds. Reset it when necessary and it is definitely good to 5 seconds and probably 1 second accuracy.

What does that mean?

If we assume 24 hours = 360 degrees for a celestial body, 5 seconds would indicate time errors of 0.02° or 2.5 km on planet SH3. Clearly, time will not be the limiting factor in positional accuracy. Even if we ignored seconds, 1 minute accuracy would allow 0.25° accuracy or 30 km.

Now let us consider position. SH3 is based on a 1024x768 pixel interface. Celestial navigation depends on the measurement of the altitude of the heavenly body from the horizon. The maximum altitude is 90°. If we try to measure 90° with 768 pixels to 1 pixel accuracy, we will have a minimum error of 0.12° or 14 km. We could cut this in half if we used 2 fields of view. But with eyeball measurements we shouldn't expect it better than about 14 km.

If the celestial model is not correct, we will have to create our own model that accurately predicts the SH3 displays.

I can tell you right now (but will show you later) that the star positions in SH3 are more accurate than can be displayed in the SH3 design.

What does it mean?

It means that SH3 is capable of more accuracy than the user interface is possible of allowing. My estimate is that the theoretical accuracy is 15 km because of the resolution of the gui. (See the picture above) My goal is to create a method good to 30 km. I will accept an accuracy of 120 km as useful for game purposes. Most of the time. Assuming a sober kaleun.

vanjast

04-20-12, 01:34 PM

reaper7

04-20-12, 02:33 PM

@11Bravo check your email - first piece of the solution solved. :up:

Edit: 2nd piece of the Solution solved - check mail.

11Bravo

04-20-12, 05:14 PM

A word on the clocks... It's a long time since I played with this so I'm a bit 'rusty'

The 'Ship Clock' is the one that jumps forward or backward an hour whenever you cross a timezones 'halfway mark'. This I think is true to real life, where one of the ships navigators duties is to check/set the ships clock everyday, to the correct timezone.

The other clock was either set for GMT time or your Base's time zone. I think there was a problem when you loaded a saved game and this time was now swopped around or set to your current timezone. So each time you saved you must keep a record of the timezones

This of course would throw a navigator into a 'didley'...
:)

vanjast!! Your mod was my inspiration to study navigation in SH3. Thank you for your remarks. I will test the effect of saved games after I get the accurate sextant built. I will be posting today some measurements of the distortion with the SH3 cameras that have prevented accurate star altitudes from being measured.

11Bravo

04-20-12, 05:21 PM

@11Bravo check your email - first piece of the solution solved. :up:

Edit: 2nd piece of the Solution solved - check mail.

Got your email and will reply with the answer tonight.:yeah:

11Bravo

04-20-12, 06:28 PM

The U-13 has returned to port to assist a Kriegsmarine research project into optics. The aim is to understand distortions present in the "cameras" used at various stations. The immediate goal will be accurate altitude measurement of stars for celestial navigation, but there might be implications for Weapons Officers as well as these distortions could affect measuring accurate bearings and range.

There are two distortions present in the SH3 cameras which must be accounted for if we are to measure the altitude above the horizon of a heavenly body. The first is well known and encountered frequently in the game. This picture shows it well.

http://img851.imageshack.us/img851/3609/mission2a.png

Even though the horizon displays as a flat line, the altitude to the sun or star appears to increase as bearing changes from the correct azimuth. Obviously we must center the object if we are to measure the altitude consistently and perhaps accurately.

11Bravo

04-20-12, 07:03 PM

The second type of distortion depends on the altitude, not the bearing. To understand and measure it, we must first discuss the cameras.dat file, and the important parameters of the cameras for the stations we will use.

Veteran Kaleuns know of the awesome work by skwas on his Silent 3ditor and have used this tool to explore the inner workings of their u-boats and the SH3 environment. Every captain owes it to himself to download and use this tool to better understand the game, the work of the developers, and the modders. :salute: skwas!!

http://img823.imageshack.us/img823/8615/mission2f.png

First we have to understand the vertical field of view (FOV) of the camera. There is a parameter called AngularAngle that I believe controls the horizontal field of view (untested). I have found that the vertical field of view is 0.8 of the AngularAngle. In other words the aspect ratio of the cameras is 5:4 horizontal to vertical. This was interesting to me because the aspect ratio of the GUI is 4:3 horizontal to vertical (1024x768).

Second we have to define two angular scales for the vertical. The first is Screen Altitude. It defines the vertical position of an object on the screen or viewport of the camera. It ranges from 0° at the bottom to the FOV° at the top. So if the AngularAngle of your camera is 75°, the vertical FOV is 0.8*75=60° and the Screen Altitude ranges from 0° to 60°. The second scale is Sky Altitude. It is the vertical position of an object in the game relative to the horizon. This is what we want to measure for celestial navigation. The horizon defines 0° of Sky Altitude. Other parameters control the link between these two scales.

Based on early measurements with linear sextants and reading the Subsim forums, it was clear to me that the star positions were tantalizingly close to accurate. It didn't make sense that they would be so close, but not correct. So I assumed they were correct, and that it was the game engine rendering that was "wrong", not the star positions. This implies that the game engine displays correct information incorrectly. And I can show you that it does just that.

There are two parameters in the cameras.dat that control the position of the horizon in external views. This is the Elevation Min and Max. Lets talk only of the Min for now. The Elevation Min is the Sky Altitude of the middle of the vertical FOV when the camera is tilted down all the way. In other words, it is the angle of the middle of the screen from the horizon. When the Elevation Min is 0°, the horizon displays in the middle of the screen. The purpose of the Elevation Min and Max is just that...to control where the horizon appears in external views. But if you carefully measure the position of the horizon, you will find it displays incorrectly.

The error is the second type of distortion present in SH3. It can be measured and a calibration curve created to allow correction of altitude measurements. This will be the basis of our accurate sextant.

11Bravo

04-20-12, 07:18 PM

http://img217.imageshack.us/img217/5352/mission2b.png

Look very closely at the image above. Here, my camera is the GWX Gold F11 Flak Station, with AngularAngle = 75° and hence VFOV = 60°. I ask the game engine to render the horizon in the middle of the screen at 30° up and it almost succeeds. I ask it to display at 50° up by setting Elevation Min to -20° and it displays too low by more than a degree. Asking it to display at 10° up by setting Elevation Min to +20° and it displays too high this time by about a degree.

The game rendering engine is displaying correct information incorrectly.

This is the second type of distortion in SH3. Objects in the upper half of the screen display too low, while objects in the lower half display too high. The errors are only on the order of a degree or so, but it is enough to make celestial navigation difficult. Together with the strange interpretation of local Zone Time and Greenwich Mean Time by the game clocks, it is no surprise that celestial navigation has eluded us within the SH3 world. Together with the lack of a proper navigation map with latitude, longitude, and time zone lines, it seems that they didn't quite implement what was possible.

The good news is that this can be measured and corrected for in the usual way of correcting sextant measurements for altitude. It is similar to a refraction correction (but quite different).

11Bravo

04-20-12, 07:32 PM

By manipulating the Elevation Min and taking screenshots and counting pixels, a calibration curve can be developed for the cameras. This is necessary if an accurate sextant is to be developed.

http://img40.imageshack.us/img40/6896/mission2c.png

http://img72.imageshack.us/img72/456/mission2d.png

Notice that both curves are the same shape, but differ slightly in the magnitude of the correction. This seems to be a feature of how the rendering engine displays external views in SH3. Very interesting...It makes you wonder if a similar distortion exists in the horizontal direction for bearings.

That is all for today. Next up will be the actual sextants and measuring the position of some navigation stars.

Good hunting. :arrgh!:

<Edit> Reposted calibration curves after correcting a math error. Sorry.

reaper7

04-21-12, 04:49 AM

Hi mate, can you check your email. Regarding the above, cheers.

11Bravo

04-21-12, 06:37 AM

Thanks!

11Bravo

04-21-12, 02:24 PM

I have completed the two sextants and tested one of them. The star positions in SH3 are accurate to my ability to measure them. The camera calibration curve appears to be accurate enough for our purposes.

I am showing a linear sextant here, where you have to apply the altitude correction manually, similar to a standard sextant.

http://img209.imageshack.us/img209/6295/mission2e.png

The chart on the left is an altitude correction that needs to be applied to the sextant measurement Hs. It was developed from the calibration curve, and the screen altitude corrections mapped to sextant altitudes. The Elevation Max and Min of the cameras.dat file were selected in a way that tilting the camera to a hard stop at Min or Max allows you to measure sky altitudes directly. If you are tilted all the way down, you use the left side scale. If you are tilted all the way up, you use the right side scale.

Here we have tilted all the way up and put Alioth in the center of the sextant. Alioth is one of the 58 navigation stars commonly used in celestial navigation. It is easily recognized as the 3rd star in the handle of the Big Dipper constellation. Our linear sextant reads 78°30' to the nearest 10' after some squinting at SH3's low resolution interface. :dead:

You might want to zoom in on the image above. Try holding down your CTRL key and hitting + a few times. When you are done, use CTRL and 0 to return to normal. Works with many browsers.

The altitude correction factor is 41' from the table. You might notice that this sky altitude of 78° is actually a screen altitude of 36°. Tilting the camera doesn't change the screen altitude, only the sky altitude. That is why we developed the calibration curve for screen altitude.

Also shown are almanac values for the navigation stars visible from the location at the time shown by the clock. Alioth should have an altitude of 79°04' and our observed value is 79°11' after the altitude correction is applied. The difference in this case is a mere '7, or 0.117°, or 14 km in position on planet SH3. :woot: Way to go SH3!!!

brett25

04-21-12, 02:26 PM

wow pretty awesome, ive always toyed with the idea of trying real navigation is sh3 and i think i will do it now in earnest using your new tools, good job, mate:yeah:

11Bravo

04-21-12, 02:27 PM

Thanks, Kaleun! :DL

11Bravo

04-21-12, 02:39 PM

http://img851.imageshack.us/img851/8615/mission2f.png

23 navigation stars later...:doh: and here are the results.

The Diff column is after the Altitude correction is applied. I have noticed that all the differences are positive. Usually an accurate sextant would give small errors distributed around zero, but ours is distributed around 13'. This qualifies as an index correction that can be subtracted from all measurements with this sextant to make it more accurate. Real sextants have index measurements arising from their mechanical construction. I'm guessing mine might be a function of my calibration system, sextant construction, and measurement bias when estimating Hs. Your mileage might vary, but I will consider using it going forward.

I have included a sample calculation that shows how to apply the Index correction if you choose to do so. Note that the average error is now less than 5' or 10 km. Well within my specification of 30 km so far. Time for something to go horribly wrong. :har:

11Bravo

04-21-12, 03:07 PM

Where are we?

A good question to ask in a thread about navigation. :haha:

I guess the big news is that the stars are accurately modeled in SH3. It would have been nice if the developers had told us that, instead of finding out 7 years later. It would have been noticed earlier except for two things...the clocks are not easily understood and the external camera views have a distortion that introduces errors in the vertical (and perhaps horizontal) angles. Also the navigation map doesn't make locating your latitude, longitude, or time zone easy. I will continue to try to overcome these unnecessary barriers in the game.

(Another reason is that I didn't have the courage to report my incomplete results of several years ago. :nope::oops: I have resolved now to report my results and my ideas as I go forward to atone for my poor judgement on this matter in the past)

It took a lot of testing to find this. And further testing is needed to find the limits of this method. I have no doubt there will be some serious limitations to this method. My immediate plan is to qualify the flak gun sextant in the same way I showed above. After that I will demonstrate the method of celestial navigation to yield an error triangle and measured position. (I showed one earlier in the thread) Then I will fix up the previously released mini mods and release what I have so far as another download. That will conclude the second voyage of U-13 "der Seeesel".

After that, I want to tackle the sun. And then the moon. And continue to test the nautical chart, nautical clock, the sextants, time speed distance measurements, study some morse code, learn the enigma machine, and if I find some time, I might even attempt to sink a ship.

If anyone is interested in hundreds of loading test missions, making detailed measurements, and reporting the results privately, feel free to PM me. :har:

reaper7

04-21-12, 04:09 PM

Brilliant, the Devs created a proper star system. Well done on proving this.
Not that we know that, I shall move forward with coding the clocks.
Did you get to test my external code for time zones?

11Bravo

04-21-12, 05:04 PM

In process, I got your email. Thanks again for all the hard work. :)

Wolfstriked

04-21-12, 06:28 PM

Thank You 11Bravo:up::up:

reaper7

04-22-12, 02:17 AM

Hi 11bravo, just a quick question on the star positions. Are they appearing at the correct positions for the actual date, years etc or are they offset and a conversion is required to there positions to calculate where they should be from almac data?

Even if offset does the sky model in sh3 reflect real world position and dates?
I guess what I'm asking is would the stars in the sky on a certain date and position in the globe look the same to the player as it would to a person if they were looking at the sky at that time in real-life, that would be amazing for sh3 if it were the case.

EDIT
Well some good news I've now got the code in place and working that automatically changes the Screen Clock to the Correct GMT time.
That is the BZT is now taken from the Time:

Stock SH3:
GMT = T+TZ+BTZ

Coded SH3:
GMT = T+TZ

Unfortunately I haven't found a way yet to change the Mouse-over Local Time as it is not a Numerical Value like most values but is in fact the Text entry from the en_menu.txt ;2703=|Local time: %02d:%02d

where %02d:%02d updates the text values.

Will see if I can do a workaround, if not the Modded Map that 11Bravo made can be used to see the timezone for localtime.

vanjast

04-22-12, 01:03 PM

Hi 11bravo, just a quick question on the star positions. Are they appearing at the correct positions for the actual date, years etc or are they offset and a conversion is required to there positions to calculate where they should be from almac data?

Even if offset does the sky model in sh3 reflect real world position and dates?
I guess what I'm asking is would the stars in the sky on a certain date and position in the globe look the same to the player as it would to a person if they were looking at the sky at that time in real-life, that would be amazing for sh3 if it were the case.

From what I remember the stars were accurate 'enough'... To which date I'm not sure, but this shouldn't be a problem as you use the almanac for that year.

The optics of the cameras were difficult to work with but it looks like it was a SIN (COS) function of sorts. If you play with the camera magnifications you'll fook the POV angles. I looked at trying to extract and display the elevation angle of the scopes, but this didn't happen. If you can do this you'll should get good accuracy.
:)

postalbyke

04-22-12, 11:08 PM

This is totally sweet! I usually get too wrapped up in playing the game to "seriously" mod :P
I'm still working on completing my first mod lol

I did some work on celnav a while ago, and my sky always seemed to show up at GMT=local (I haven't followed what all has been said about the clocks, I hope that Reaper has "fixed" that little oversight)
I shot all my elevations using the observation periscope after discovering that I couldn't get my MaGui sextant to work (I think my screen buggers the angularity somehow...)(or it's just that pesky 5:4 v 4:3 problem)

Either way, I'm really stoked about your inventiveness and investment of time on this project! :yeah::salute::rock:

reaper7

04-23-12, 10:11 AM

From what I remember the stars were accurate 'enough'... To which date I'm not sure, but this shouldn't be a problem as you use the almanac for that year.
:)

Good, good so the stars are pretty accurate for a certain date/year.
Cheers.

I did some work on celnav a while ago, and my sky always seemed to show up at GMT=local (I haven't followed what all has been said about the clocks, I hope that Reaper has "fixed" that little oversight)

Hi mate, I can send you a test file since your fimilar with the GMT=GMT+local time issue in sh3. You can test to see if my fix is working as intended.
Cheers mate.

11Bravo

04-23-12, 04:15 PM

I'm back after reinstalling SH3...my game computer is old and it crashed during testing and it corrupted the install. Took a while but everything is back up. Then I worked 15 hours today at my real job, so I will have to answer questions tomorrow.

Star positions seem to be accurate to the day and year, but I need the accurate sextant completed to confirm that. This weekend I want to complete this "voyage" and have the sextant finished and ready for download.

The next "voyage" will test the star positions in the game, and maybe some sun and moon positions.

Reaper7 I had your app up and running! Nice. I need to spend some time testing it though.

vanjast

04-23-12, 05:22 PM

This weekend I want to complete this "voyage" and have the sextant finished and ready for download.Curious :)

The next "voyage" will test the star positions in the game, and maybe some sun and moon positions. Ah.. the Sun.. the Moon ??... AFAIK.. they (developers) fooked this up completely.

If you can correct this.. great stuff

vanjast

04-23-12, 05:31 PM

They (developers) fooked this up completely.

Longitude is not too much a problem... but it's Latitude that's way off - correcting this to USNO's almanac will be interesting.

Maybe the developers forgot that the world shape is an orange and not a perfect sphere
:)

postalbyke

04-23-12, 08:01 PM

@Reaper: That would be totally sweet.

I did get some "relatively" reliable lats out of polaris as measured by obs. peri, but I don't know how close I was cause I didn't like the map that came with the prior mod (sorry, guys). The lines were too coarse for my liking, I like a nice fine line or a grid of dots. I tried to modify the map myself, but I don't think I came up with a satisfactory solution for myself.
Also, I decided that the Nav had my back since I couldn't read the map :P .

11Bravo

04-24-12, 03:30 AM

Longitude is not too much a problem... but it's Latitude that's way off - correcting this to USNO's almanac will be interesting.

Maybe the developers forgot that the world shape is an orange and not a perfect sphere
:)

I agree that sun and moon seemed wrong when I looked at them years ago. And I suspect it is the "shape" of the SH3 world.

11Bravo

04-24-12, 06:43 AM

Brilliant, the Devs created a proper star system. Well done on proving this.
Not that we know that, I shall move forward with coding the clocks.
Did you get to test my external code for time zones?

Still testing but it is very slooooowwwww because my system resources shoot up to 100% and the windowed SH3 runs jerky and slow. At least it runs now that I maxed out the RAM. :damn:

reaper7

04-24-12, 09:54 AM

I agree that sun and moon seemed wrong when I looked at them years ago. And I suspect it is the "shape" of the SH3 world.

Hi mate, forgot to mention that the last version I sent you can be run fullscreen.
As its not displaying any messages for debugging.

Myxale

04-24-12, 12:06 PM

Wolfstriked

04-24-12, 02:05 PM

Since its 1Bravo is now a HAHD member,will this be exclusive to HAHD?

11Bravo

04-24-12, 03:55 PM

Hi mate, forgot to mention that the last version I sent you can be run fullscreen.
As its not displaying any messages for debugging.

Great.

11Bravo

04-24-12, 04:00 PM

Since its 1Bravo is now a HAHD member,will this be exclusive to HAHD?

This thread is open to all and I will continue to post my personal work on navigation here. My work with HAHD will be for HAHD only and will be released or discussed as they see fit. :up:

11Bravo

04-24-12, 04:06 PM

I finally took the time and read tru the whole thread, and I = mindblown. :salute:

It was great reading tru all the research and notes. I really got excited to see this baby hitting my sub as soon as it's done!

Bravo, maestro! :rock:

Thanks. Every modder likes to hear that his efforts are appreciated. It makes the difference sometimes at 3 AM on whether to sleep in or get up early to do some work on SH3...

I decided to operate in the open, showing my thinking and and my mistakes and my learning from my mistakes. Every week I will post my findings, and make available for downloading the mini mods I used to conduct my research. Eventually, like minded Kaleuns can make their own observations and together we can push this already excellent game to new heights. This weekend I will release my ugly sextants and the all important correction factors that make them accurate. I will include a SH3 star chart for the test mission so you can shoot some stars and plot your position.

Part of the fun of this game is learning new skills that were necessary for the submarine forces to be successful. Even if you don't plan on hardcore navigation and even if everything can't get implemented in 100% realistic version, there will be value in even the most casual player to give it a try. I have tremendous respect for those who challenge the forces of nature, let alone the forces of man during war.

:arrgh!:

postalbyke

04-26-12, 11:22 PM

11Bravo

04-27-12, 05:41 PM

I just tried the application, my only complaint so far is excessive lag put on my computer, which is admittedly very old :P I'll try it again another night with vanilla and load up my old "known location" missions and see how well it all goes off!

edit: old computer running gwx/magui/typeIIatuneup/typeIIinterior2.2 fps without is ~30 at 512 TC, with is ~1 at 256 TC or above.

You are probably replying to reaper7. His latest app runs full screen without the diagnostic information and is supposed to take fewer resources. Ask him for it.

If you downloaded my minimods, I have some navigation missions from known positions and some utility mods that help create a lighter setup for testing. I also have an old computer ... :doh:

11Bravo

04-27-12, 05:51 PM

The crew of U-13 finished testing the flak station sextant with good results. Here is the shot of Alioth along with the Altitude correction factors determined from the camera calibration described earlier. The error from my know position was 14 minutes of arc which works out 28 km on planet SH3.

Finding the stars is bit more difficult because you can't use the bearing information available at the observation scope. But with some star charts and with experience it becomes easier. I made some star charts that will be available for download.

http://img21.imageshack.us/img21/4722/mission2g.png

11Bravo

04-27-12, 05:57 PM

Here are the results of all 23 navigation stars that I shot from my position at N50° W0° in the English Channel. Most of the differences from Almanac data were positive which made me suspect another Index error, just like a real sextant. Applying this new correction drove the errors down to an average of 6 minutes of arc or 12 km. The largest error was 12.4', or just over a tenth of a degree. My tired eyes and SH3's low resolution seem to be good for about 10' or so...:O:

The picture shows Procyon in the sights with a particularly good measurement!

Now we have two accurate sextants.

http://img534.imageshack.us/img534/5929/mission2h.png

11Bravo

04-27-12, 06:07 PM

Here are some examples of the star charts that I made. They are screen shots from the flak station with the navigation stars labeled. I took them every 120° of bearing with one shot tilted down and the other tilted up. I didn't check my work here, so there could be an error. Comparison with bearing information in the almanac data will reveal any error.

There are 12 pictures in all showing all 23 navigation stars visible at the time and also Polaris.

http://img208.imageshack.us/img208/6352/000low.png

http://img338.imageshack.us/img338/1803/000high.png

11Bravo

04-27-12, 06:14 PM

Next I am going to post some screen shots giving an example of fixing your position using the sextant and 3 star shots. This will take a little while. Then I will upload all the minimods and the other materials that will allow you to do the same. And that will conclude the second prewar voyage of the U-13 in its secret mission to develop navigation tools for the upcoming war...

11Bravo

04-28-12, 04:19 AM

When you decide to shoot the stars, click on the stopwatch immediately after the minute on the clock changes. This allows you to know Greenwich Mean Time to about 5 second accuracy in game. Earlier in the thread is a discussion on how the game clocks work, and how to get GMT from your local time and the nautical time zone. Here I am using my nautical chart with 1° grid spacing. SH3 world is a cylinder with 120 km between latitudes and longitudes. We will eventually need to correct our result for this map projection.

Select navigation stars with bearings roughly 120° apart, so you will get a nice shaped error triangle when you are done. I chose the first star on the list, Alioth, and then used its bearing to help choose the other 2 stars. You will need a minimum of 2 stars, but everyone uses 3. When you shoot a star, you measure its altitude or height above the horizon. This is called Hs. You then make the reading more accurate by applying correction factors. We have identified two corrections for measurements done with the in-game sextant. The index correction adjusts for a the sextant not being zeroed. It gives us the Ha, or apparent altitude of the star. The second corrects for the distortion in the SH3 camera. I am calling that the Altitude correction. You look it up on the table I created based on the calibration curve I measured. Now you know the observed altitude or height above the horizon Ho. You don't need to record the bearing to the star. But you do need the time of measurement. My measurements were taken 2 minutes apart.

Our position is shown on the map, so we can judge the result.

http://img651.imageshack.us/img651/4337/celnav1.png

11Bravo

04-28-12, 04:33 AM

Since we don't know where we are, we need to assume a position. Since Bernard was the helmsman, we chose a nearby position on land. My nautical chart has 1° grid spacing with latitude/longitude labels on the edges, so I know the assumed position is 51° N 001° W. You need to know the latitude and longitude of the assumed position and its precise location on the chart for the method to work.

A nautical almanac will tell you the altitude of a navigation star from the assumed position at the time of your observation. Those heights above the horizon are called Hc. The almanac will also tell you the bearing from the assumed position to the star. If your boat was at the assumed position, your observed altitudes Ho would match the calculated altitudes Hc. Comparison of Ho and Hc determines which location is closer to the given star, your observing location O or the assumed position AP. Think of it this way...if the star stood still and you sailed toward it, it would appear to rise higher in the sky. So whatever position is closer to the star yields the higher altitude for the star.

For each star shot, subtract the Hc from the Ho and note the difference and its sign. Multiply the arc minutes by 2 km to turn them into distances. Use the sign to determine whether you are closer or further than AP from the star. Here is what we can say right now based on our measurements...

Our unknown position is nearly the same distance away from Alioth as the known assumed position.
Our unknown position is much closer to Gienah than the known assumed position.
Our unknown position is much further from Elnath than the known assumed position.

Let's put that information on the chart using the in-game mapping tools.

http://img17.imageshack.us/img17/8858/celnav2.png

I have a typo in the picture above. The second blue line should read Hc > Ho...I wil fix it later...

11Bravo

04-28-12, 04:58 AM

We start with Alioth. Construct a bearing line from AP in Alioth's direction. Advance along the bearing toward Alioth 2 km because our Ho was 1 arcminute greater than the Hc. Construct a line at a right angle to the star's bearing. This is called the Line of Position for Alioth. All points on this line are 2 km closer to Alioth than is AP. If we have done everything right, our unknown position would be somewhere on the Alioth LOP...

If we were charting on a sphere. But we are charting on a cylinder. And that causes an error we will have to deal with later.

The Alioth LOP is the first side of our error triangle.

http://img33.imageshack.us/img33/913/celnav3.png

11Bravo

04-28-12, 05:09 AM

Now we handle Elnath.

Plot a bearing to Elnath from the AP. Retreat in the opposite direction 108 km because our Ho was 54 arcminutes lower than the Hc. Construct a right angle line of position on the star bearing. This is the Elnath LOP. All positions on this line are 108 km further from Elnath than is AP. If we have done everything right, our unknown position is also on this line.

The Elnath LOP is the second leg of our error triangle.

The intersection of the Alioth LOP and the Elnath LOP is our emerging determined position...on a sphere, but not on this cylinder yet.

http://img854.imageshack.us/img854/7641/celnav4.png

11Bravo

04-28-12, 05:25 AM

Now we close the error triangle with Gienah. Construct a bearing to Gienah from AP. Advance along this bearing 108 km because our Ho was 54' greater than the Hc. Construct a right angle Line of Position for Gienah. All points on this line are 108 km closer to Gienah than is AP. If we have done everything right, we are also on the Gienah LOP.

The Gienah LOP closes the error triangle. The size of the triangle gives us an estimate of the error of our methods. The triangle is very small. 3 independent measurements of star altitudes in game have yielded the same position to within about 2 km. It might not be the correct position yet, but it is remarkably consistent.

This error triangle was produced using almanac values calculated with spherical trigonometry. Our best measurement of our position says we are in that error triangle. And we would be pretty close if we had charted the result on a sphere.

So we need to correct the position of this error triangle to determine where it would chart on a cylinder. Like our navigation chart.

http://img406.imageshack.us/img406/4225/celnav5.png

11Bravo

04-28-12, 05:50 AM

Let's compare our earth to planet SH3.

Earth is approximately a sphere. We plot our position using latitude lines and longitude lines. Latitudes are parallel to the equator. The distance between 1° of latitude on earth is the same everywhere, and is about 111 km.

Planet SH3 is a cylinder. We can plot our position using latitude and longitudes. The latitude lines are also parallel to the equator. The game editor reveals that 1° = 120 km everywhere.

So the distance between 50° N and 51° N is 111 km on earth.
And the distance between 50° N and 51° N in SH3 is 120 km.
There is no problem charting latitudes in the game.

Now we examine longitudes.

On earth the longitude lines converge at the poles. This causes the spacing between longitude lines to decrease as latitudes increase away from the equator.

So the distance between 0° W and 1°W is 111 km on earth at the equator.
And is 71.3 km at 50°N
And is 19.3 km at 80°N
And converges to zero at the poles.

On planet SH3 the distance between 0°W and 1°W is 120 km at the equator.
And is 120 km at 50°N
And is 120 km at 80°N
And stays constant at the poles.

We need to account for this difference in behavior between the two different shaped worlds.

11Bravo

04-28-12, 06:07 AM

Celestial navigation depends on the mathematical principles of spherical trigonometry. All the inputs and outputs are angles. Latitude is an angle. Longitude is an angle. The altitudes of the heavenly bodies are angles. Only the final result is converted to a linear distance using the scale factor of that spherical world.

We have been working in km using the SH3 scale factor of 1°=120km, but we were always really working with angles...minutes of arc. And we plotted our error triangle using the arcminute difference between Ho and Hc.

Our error triangle is located a certain distance from a longitude line. That means it is located a certain angle from that line. And that angle was calculated with the assumption the world was a sphere. So we need to distort that angle onto the surface of a cylinder.

The mathematical function that causes earth's longitude lines to converge at the poles is the cosine of the latitude.

The cosine of 0° is 1
The cosine of 50° is 0.6428
And the cosine of 80° is 0.1736

Recall the 1° distances between longitudes on earth.

111 km at 0° = 111 cosine 0°
71.3 km at 50° = 111 cosine 50°
19.3 km at 80° = 111 cosine 80°

So when spherical trigonometry gives you an angle between longitudes, the distances get shrunk according to the cosine of the latitude.

So it stands to reason we need to stretch them back so we can chart them on a cylinder. Since spherical trigonometry has already multiplied the angle by the cosine of the latitude, we are going to undo that by dividing by the cosine of the latitude.

Our scale factor will depend on latitude and the function will be 1/cos(latitude).

The 1/cosine of 0° is 1
The 1/cosine of 50° is 1.556
And the 1/cosine of 80° is 5.759

11Bravo

04-28-12, 06:24 AM

Our error triangle was computed on the basis of spherical trigonometry because that is the how celestial navigation was developed on earth. Here is what we need to do to get the result to plot on a cylinder that SH3 plays on.

We need to measure the distance between the error triangle and the longitude of the assumed position. That distance is 73 km. At a scale of 1 arcminute = 2 km, that suggests our error triangle is 36.5 arcminutes East of the AP longitude.

We need to divide that number by the cosine of the latitude. The result is 56.8 arcminutes. East of the AP longitude. Then we convert back to km and get 114 km East of the AP longitude.

Or just look up the value in the chart. We need to multiply by 1.556. So our 73 km is really 114 km.

Just a little painful, but necessary to maintain accuracy, especially at higher latitudes.

http://img171.imageshack.us/img171/356/celnav6.png

11Bravo

04-28-12, 06:33 AM

Here we see the our determined position after shifting the error triangle to compensate for the cylinder map projection. Also shown is our actual position, and the actual error of 18.6 km. My original goal was to develop the method of celestial navigation in-game with an accuracy of 30 km.

http://img62.imageshack.us/img62/8610/celnav7.png

11Bravo

04-28-12, 06:35 AM

http://img651.imageshack.us/img651/2002/celnav8.png

11Bravo

04-28-12, 06:38 AM

BDU is cautiously optimistic about the results and not amused at the money back guarantee. This will require testing. I am uploading the files in a few minutes. That ends this voyage of the U-13. :arrgh!:

11Bravo

04-28-12, 07:49 AM

The file you are looking for seems to be missing. Please contact an administrator if you feel this is an error. :damn:

The file you are looking for seems to be unavailable at the moment. Please come back later. :damn:

Third times the charm...:ping:

OK, someone go out there and blow this thing up!

reaper7

04-28-12, 11:43 AM

Brilliant Posts 11Bravo, some great learning ahead :D

Did the GMT Fix I sent you work ok :hmmm:

11Bravo

04-28-12, 02:14 PM

Did the GMT Fix I sent you work ok :hmmm:

I tested the last 2 of the 3 you mailed me. The first one I could never run because my old computer can't handle the windowed mode. The other 2 I ran full screen and they run but a bit jerky, but I can still test them.

I fire up the app, then the game, then I load my Nav390321_N00W45 test mission. But I get the same results for sunrise and sunset times that I posted above in this thread. The clocks still have the base time zone offset.

N00 W45
Nautical Time Zone +3

Game clocks read
SR Mouse Time 0307
SR Screen Time 0607

Almanac
SR Zone Time 0604
SR GMT 0904

SR=Sunrise time

Are you seeing something different?

reaper7

04-29-12, 09:26 AM

I tested the last 2 of the 3 you mailed me. The first one I could never run because my old computer can't handle the windowed mode. The other 2 I ran full screen and they run but a bit jerky, but I can still test them.

I fire up the app, then the game, then I load my Nav390321_N00W45 test mission. But I get the same results for sunrise and sunset times that I posted above in this thread. The clocks still have the base time zone offset.

N00 W45
Nautical Time Zone +3

Game clocks read
SR Mouse Time 0307
SR Screen Time 0607

Almanac
SR Zone Time 0604
SR GMT 0904

SR=Sunrise time

Are you seeing something different?

Sent you 2 new files, that hopefully get it working for you.

Can you send me all your test missions.

There are only Nav390321_N00W08 to Nav390321_N00E07 in the downloaded pack. :up:

11Bravo

04-29-12, 10:09 AM

Great. Sent you the files. I also updated my download to include the new navigation missions.

Cheers.

reaper7

04-29-12, 01:03 PM

Great. Sent you the files. I also updated my download to include the new navigation missions.

Cheers.

Cheers Mate, also re-sent those previous 2 files (I forgot to compile them :oops:) so they had no chance of working.

11Bravo

05-02-12, 05:25 AM

@reaper7

I was able to test both apps, but in a limited way, as the performance of my old computer is not very good. My max time compression was 256 which prevents me from cruising very far. Here is what I found...

TimeZones app worked perfectly. The Mouse Time read the correct local Zone Time and the Screen Time read the correct GMT. Matched almanac sunrise and sunset times. Clocks changed crossing time zone lines and continuted to match almanac SR/SS times. :rock:

However, this deserves to be tested by someone with more horsepower under the computer case. I can recommend a proper testing regimen, based on my work in this thread, but improved with some other observations to make. If you want me to write it up, let me know.

Navigation app didn't seem to work as designed? Stock behavior only.

Fixing the clocks would be quite a coup. I will concentrate on understanding the stock behavior of the clocks to support your fix and educate those who wondered how those damn things worked all these years. :hmmm:

Great work reaper7! :salute:

P_Funk

05-02-12, 08:44 AM

This is so thrilling. I haven't been this excited by an SH3 project since the first Open Hatch mod thread surfaced.

I was always interested in real navigation but the limitations really kept me from wanting to go all in with it. This has now really piqued my interest.

I gotta commend you on making some of the most exciting mod work in a long time, and completing your second stage in time for my birthday no less!

I will be watching this closely as you move forward.

EDIT. Btw I found randomly in a download in the SH3 section on this site amongst some of Carnovaro's misc files a sun and moon chart for the lat and long of London for the duration of the war. I don't know if its just taken from the actual almanac or if its actually observed from the game. Not sure if that would help you at all. The moon stuff is only for the different phases of the moon but the sun chart is for rise and set.

http://www.subsim.com/radioroom/downloads.php?do=file&id=1487

11Bravo

05-02-12, 12:06 PM

@P_Funk

Thank you very much for the kind words. They give me the strength to continue when I hit the dead ends or sometimes feel like I'm out of options. I am enjoying the challenge of learning how navigation works in real life, and also how it can be implemented in this game. It is amazing how much detail the developers put into this old game, and it is amazing what modders keep discovering about what they can do with it. SH3 is proving hard to kill.

I downloaded those documents and am reading with interest. I will be posting soon on the plan for the 3rd voyage of U-13. I can tell you now that it will focus on the sunrise and sunset times, and that I will drive the accuracy of predicted SR/SS times from the current many minutes of error to a more than reasonable few seconds of error. :arrgh!:

P_Funk

05-02-12, 12:19 PM

I can't wait to see whats next. I especially like how clear your presentation is. Very often when someone presents a mod its with very little detail of whats happening and you have to kind of fill in the blanks. I'm very pleased when I see you frequently say "So where are we?" or "So what does that mean?" etc. You give us the raw data and THEN you explain it so that it has some value and all along I'm learning bits and pieces of how it works so that when it comes time to try this I don't just stare blankly at one tutorial.

You give it an excellent frame of reference. More mods should be developed and released with this kind of expository commentary.

reaper7

05-02-12, 01:29 PM

@reaper7

Navigation app didn't seem to work as designed? Stock behavior only.

Great work reaper7! :salute:

Have you tested it with the latest file I sent Navigation2, I sent this to you and Makman after some code changes.
This has been confirmed by Makman to be working on his machine, should be in you u-boot-hahd email to give it a try. :salute:

reaper7

05-03-12, 02:52 PM

Hi Mate,

I've sent you a new version for testing :yeah: Working better now.

vanjast

05-03-12, 05:39 PM

11Bravo

05-04-12, 02:09 AM

Hi Mate,

I've sent you a new version for testing :yeah: Working better now.

OK, I will have time to test tonight.

11Bravo

05-04-12, 02:23 AM

The night sky is OK.

This projection (http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system) is an interesting choice :)

Have you tested the local and global clocks when reloading the game ?

vanjast...I have done some limited testing and the the base time zone stuck. I need to do a whole sweep from West to East and East to West before I post the results.

The stars are definitely OK. The clocks can be fixed and made useful, either manually or through code à la reaper7. The sun will be covered in my next series of posts, after the clock tests, and the save game tests, and a demonstration of the map projection oddities.

I considered that map projection above, but rejected it. That one is still a Mercator and SH3 has none of the Mercator stretching of latitude at the poles. The devs gave us longitude stretching instead. Our map projection seems to be the most simple one of all.

http://mathworld.wolfram.com/CylindricalEquidistantProjection.html

This one in particular

http://mathworld.wolfram.com/EquirectangularProjection.html

That is why we need the "longitude shift" as Step 4 when plotting the 3 star fix, except when you are at latitude 0°. And the shift (actually a stretch) is the 1/cos or sec term. All will be revealed in the next voyage...hopefully. :arrgh!:

11Bravo

05-04-12, 04:53 AM

The crew of U-13 is enjoying some well deserved leave ashore. BdU is mulling over the results of the first 2 voyages while planning the third.

Now would be a good time to mull over where we have been so we can determine where we should go next.

The goal is in-game celestial navigation. At a minimum that requires working knowledge of how the game handles:

1. Nautical Chart for positions.
2. Time at position and at Greenwich Meridian.
3. Sextant measurement of altitude of heavenly bodies.
4. Almanac Data of those bodies at known assumed positions.

In our previous 2 voyages we have made a dent in all four areas.

1. We used the game editor to explore how lat and lon are actually positions in meters from the intersection of the equator and prime meridian. That knowledge allows one to modify the game map to put in a 1° grid and time zone lines.

2. We used the nautical chart and some rough sunrise/sunset data from almanacs to learn how the clocks behave. One of the clocks seems to track absolute time from a prime meridian. The other clock seems to track relative time within a time zone. Both are offset from Greenwich Mean Time by a base time zone created by starting a mission or campaign.

3. We created an accurate sextant by determining a camera calibration curve to account for how the rendering subsystem displays information on the screen. We learned how to manipulate where the horizon should display on the screen and then measure where it actually does appear, and used that knowledge to determine where a measured star should have appeared.

4. We used an accurate nautical almanac to find the altitudes of stars from an assumed position and compared them to measured altitudes from our actual position. The 3 star fix gave a tight error triangle, but it had to be shifted from the assumed longitude because of the cylindrical map projection for the game.

Each of the topics above required knowing something or assuming something about the other topics first. The reason for that is because that is how celestial navigation works. Your position, the time, and the star positions are all linked together and affect each other. The heavenly bodies are both a clock and a map. We live in a four dimensional world of position and time.

We have the minimum requirements right now for in-game celestial navigation. I have made available for download the minimum tools for doing so and I have openly shared my knowledge of how this works. Anybody could take this and make a cool mod right now and you are free to do so.

But I am going to take the slow boat on this one. I am sure many Kaleuns have an interest in this subject and in the subject of how SH3 works and would like to know more. Most of us are not experts on this but are interested observers. Many of us might not want to do this but are curious how it is done and was done.

BdU has determined they are cautiously optimistic about the results and recommend further testing. In particular they want to see a rigorous testing of the clocks, the timezones, the chart. They want this longitude shift/stretch matter investigated and demonstrated further. They want training materials and documentation developed. And they want another mystery solved. The one about inaccurate sunrise and sunset times in SH3...

P_Funk

05-04-12, 10:01 AM

Madox58

05-04-12, 03:23 PM

So far I've seen you do your tests near the equator as far as I can recall, so I'm curious to know how this disparity between SH3's Longitude and the real world's, ie. the set width in SH3 versus the narrowing one as you move towards the poles, affects navigation for us. If I'm near the north pole in SH3 will this pose problems for us using existing almanac data? If so, how do you propose overcoming this, and if not... well why doesn't that change what the almanac says for our purposes?

Is everything just simply solved by converting from the spherical world to the cylindrical one as you did in your 3 point plotting demonstration?

I saw from a thread in SH5 Mods Workshop a new figure never mentioned.
When I started chaseing down the numbers involved?
First? My head started hurting.
:nope:
Then I noticed a possible scaleing number appear!
:o

SH is a flat or tube World for the most part, correct?
Now how do you scale that to create a virtual 'round' World?

Create a Test Mission in the Northern parts.
Go from point A to point B and measure the times and distances.
Do another Test mission at the Equator and measure the same.
Compare the results and see if they workout to nearly real life figures.
:hmmm:

I'm thinking I know the answer.

P_Funk

05-04-12, 09:48 PM

Create a Test Mission in the Northern parts.
Go from point A to point B and measure the times and distances.
Do another Test mission at the Equator and measure the same.
Compare the results and see if they workout to nearly real life figures.
I believe they've already confirmed that every point of longitude is exactly 120km apart at every part of the map, whereas in the real world its actually far less at the poles meaning that it actually takes longer to go anywhere in SH3 cause you can't use the shortened circle by going around the 'curve' to the north on the globe when you're for instance sailing from Europe the NY.

Its like a used up toilet paper roll of a world.

11Bravo

05-05-12, 04:31 AM

So far I've seen you do your tests near the equator as far as I can recall, so I'm curious to know how this disparity between SH3's Longitude and the real world's, ie. the set width in SH3 versus the narrowing one as you move towards the poles, affects navigation for us. If I'm near the north pole in SH3 will this pose problems for us using existing almanac data? If so, how do you propose overcoming this, and if not... well why doesn't that change what the almanac says for our purposes?

Is everything just simply solved by converting from the spherical world to the cylindrical one as you did in your 3 point plotting demonstration?

My demonstration was at 50°N and it revealed to me the need to shift the longitude in order to find the correct position. I went on blathering for two posts (talking to myself helps me think) and convinced myself that the shift/stretch needs to be proportional to the inverse of the cosine of the latitude. I tried it and it worked.

Then I studied cylindrical map projections and found one that had the exact same term in the transformation equations...an inverse cosine or secant which is the same thing.

Come back in a few hours and I will show you a series of 3 star shots at different latitudes that graphically demonstrates this stretching of longitude that is required when taking a spherical result and plotting it on a cylinder.

11Bravo

05-05-12, 04:39 AM

Create a Test Mission in the Northern parts.
Go from point A to point B and measure the times and distances.
Do another Test mission at the Equator and measure the same.
Compare the results and see if they workout to nearly real life figures.
:hmmm:

I'm thinking I know the answer.

I've done this and the world is flat for time speed distance, cylindrical for navigation off the map edges, and spherical for astronomical data when assumed position is on your local meridian, and cylindrical again when your assumed position is not. :har:

It really is just a cylinder and I will post some stuff with the equations. I already posted the links to the map projection page in my reply to vanjast above if you want to study it.

I am building the time speed distance stuff at the same time as the sunrise/sunset almanac. 1° = 120 km at any latitude E-W or N-S. Probably a week away...

11Bravo

05-05-12, 10:35 AM

The U-13 is on its 3rd pre-war voyage to develop navigation tools for the war. This mission is to better understand the Nautical Chart, especially the map projection and how how it relates to Celestial Navigation.

The demonstration of the 3-star shoot at the end of the last voyage revealed that a correction factor to longitude was necessary. This mission tests that concept by conducting several 3-star shoots at varying latitudes.

I will choose assumed positions on either side of the observing position. One assumed position will be 1° West and North of the observing position, while the other will be 1° East and South of the observing position. We will plot the error triangles for both assumed positions. We will also correct the longitude of the error triangles using the 1/cos or sec of the assumed latitude.

If the assumed map transformation is correct, we should see the error triangles diverge from the observing position as we increase latitude. If the correction factor is correct, we should see the corrected positions move back to where we know they should be.

I think the map transformation is this cylindrical equidistant projection. The equations are shown on the figure.

You can read more about it at the following links

http://mathworld.wolfram.com/CylindricalEquidistantProjection.html
http://mathworld.wolfram.com/EquirectangularProjection.html
http://en.wikipedia.org/wiki/Equirectangular_projection

http://img215.imageshack.us/img215/6039/mission3a1.png

11Bravo

05-05-12, 10:47 AM

http://img837.imageshack.us/img837/8028/mission3a2.png

We started on the Equator and shot 3 navigation stars separated by about 120° in bearing to get a nice shaped error triangle. All the site reductions are shown together with the almanac data from the two assumed positions. The error triangles nearly coincide and the correction at these latitudes are almost nonexistant. Also shown is a 30 km circle for reference.

I should say something about the clocks. These shots were done with the screen time at 0001, 0002, and 0003. Since I started the mission in nautical time zone +2, my base time is +2 and I need to add that to the screen clock to get GMT. The excellent results shown give us confidence in several things...the clocks, the sextant, the almanac, and the method of graphing the result.

Now we move to 45°N.

11Bravo

05-05-12, 10:53 AM

http://img718.imageshack.us/img718/4824/mission3a3.png

Now we see the error triangles are closer to the assumed position longitudes. The correction factors near 45° are substantial, and move the plotted position in the right directions and amounts to give us a good estimate of our position. Note that I am applying the sec LAT correction factor to each assumed LAT separately. This is a new discovery that further increases accuracy over what I demonstrated in the previous voyage.

Now we move to 60° N latitude.

11Bravo

05-05-12, 11:01 AM

http://img42.imageshack.us/img42/756/mission3a4.png

At this latitude the correction factors are on the order of 2. The error triangles are clearly graphing closer to their assumed longitude lines than they should. And the correction to the longitude is taking care of the map transformation distortion.

Now we move to 75°N latitude.

11Bravo

05-05-12, 11:12 AM

http://img85.imageshack.us/img85/6039/mission3a5.png

The same trend is observed. At this very high latitude, the sec LAT correction factor is about 4. The error triangles are hugging their assumed longitudes and the large correction factor moves them close to the correct position. This is the largest error we have seen so far, and is probably magnified by the large correction factor at the distorted extremes of the map.

I should also point out for this position, we are in TZ +00 with a BTZ of +00, and therefore the screen clock reads GMT directly.

11Bravo

05-05-12, 11:26 AM

What do the results of this mission tell us.

Several things.

First, we would not be this accurate unless the sextant, clocks, and almanac were not very close. In celestial navigation, everything is linked together, and the result can not be right without everything else in the tool box being right also.

The error triangle behavior where it drifts toward the assumed longitude at higher latitudes is exactly what should happen on a sphere. Since we are using spherical trigonometry to find our position, the results should be plotted on a sphere. The results don't know how we are plotting them, so the error triangles go where they are supposed to on a sphere. The method works...but needs the correction because of the map projection.

The correction term certainly seems to be the sec LAT or 1/cos LAT. And this equidistant cylindrical projection is the one that provides it. It even looks right. :cool:

I think this strong evidence that we know what map projection the developers used. And I think it is strong evidence that we are on the right track here.

The greater error at higher latitudes might be a warning though of the limits of plotting positions on cylinders.

Next mission of this voyage will be a closer look at the clocks...radio messages from reaper7 and vanjast need to be answered. :arrgh!:

reaper7

05-05-12, 11:35 AM

Next mission of this voyage will be a closer look at the clocks...radio messages from reaper7 and vanjast need to be answered. :arrgh!:

:hmmm: Haven't received a mail, can you send it again - or PM me here. :up:

11Bravo

05-05-12, 12:14 PM

No rest for the wicked...still working on it. :doh:

CaliEs

05-05-12, 09:52 PM

We started on the Equator and shot 3 navigation stars separated by about 120° in bearing to get a nice shaped error triangle. All the site reductions are shown together with the almanac data from the two assumed positions. The error triangles nearly coincide and the correction at these latitudes are almost nonexistant. Also shown is a 30 km circle for reference.

I should say something about the clocks. These shots were done with the screen time at 0001, 0002, and 0003. Since I started the mission in nautical time zone +2, my base time is +2 and I need to add that to the screen clock to get GMT. The excellent results shown give us confidence in several things...
I dont see "excellent results". What i see are posts of ambiguity and questions.
I look at your first calculation with the stars Alioth, Antares and Sirius
My result with your given data is this: 3StarFIX = 000-41.1'S 030-28.3'W, means 50.7nm (= 101.4km) from your real position 000N 031W.
http://img.xrmb2.net/images/330890.jpeg
Show us the concret calculation steps from the sighted position to the calculated Hc.
Also give us evidence of the taken shots of the stars. For example Sirius at 12°20 at 0203 GMT.
Why do you put in an index-error of 0.6' to the calculation?

11Bravo

05-06-12, 04:08 AM

I dont see "excellent results". What i see are posts of ambiguity and questions.

Thank you for joining us. You certainly came to the right place for ambiguity and questions. :haha: Seeing "excellent results" comes from understanding the long challenging history of implementing in-game real navigation within SH3. :damn: Usually I just see stars though...

I look at your first calculation with the stars Alioth, Antares and Sirius
My result with your given data is this: 3StarFIX = 000-41.1'S 030-28.3'W, means 50.7nm (= 101.4km) from your real position 000N 031W.
http://img.xrmb2.net/images/330890.jpeg

It looks like you took my observations and dumped them into a program that spits out a position on earth. Without having the program and understanding what assumptions it is making, I can't tell you why it gives a different result. But I can clearly explain how I am getting my results.

Show us the concret calculation steps from the sighted position to the calculated Hc.
Also give us evidence of the taken shots of the stars. For example Sirius at 12°20 at 0203 GMT.
Why do you put in an index-error of 0.6' to the calculation?

Most of what you ask for has been covered in this thread.

Hs is the measured altitude of the star using a linear sextant with certain parameters set in the cameras.dat file of the game. Screenshots are available in earlier posts.

Index is a correction based on observing the error in 23 navigation stars from a known position with the sextant. The results are available in an earlier post. I notice that my errors largely are positive, so I subtract their average in an attempt to improve accuracy. For the flak station sextant, that is 6'.

Ha is what I am calling the apparent altitude after the index correction.

Alt is my main correction to the measured altitude. It was based on a camera calibration curve I developed for the external view at the station where the sextant is used. It depends strongly on the screen position, and therefor sextant position. Covered in earlier posts above.

And that brings us to my Ho. Let me dig out and post that Sirius screenshot. I will put the Alt correction chart on it also. Here we go.

http://img11.imageshack.us/img11/710/mission3a6.png

SH3's Sirius displayed in my sextant together with the corresponding Alt correction based on in-game measurements of the display error of the horizon. Take a look at the horizon. That is a feature of how information is displayed in the game, and my Alt correction puts it in the right place after you measure Hs and optionally apply an Index correction. I squint and measure the star to the nearest 10'. Go ahead and hit "CTRL" + "+" a few times and stick your nose on the screen. How did I do?

Also notice how the SH3 clocks are handled. When you start a mission, SH3 remembers your starting nautical time zone and applies that as an offset to the "local time" and the "screen time". I determined how to handle that by making observations of sunrise/sunset data. Also covered in detail in this thread. I have a few more hours of testing ahead of me for that though. That will be the next post.

Now we have everything we need to plot the Sirius line of position on the nautical chart. Here is my result.

http://img526.imageshack.us/img526/2333/mission3a7.png

Celestial navigation works by comparing the altitude or height above horizon of a body from your unknown position to a value calculated from an assumed position nearby. Here I have created a test mission that puts me at 0°N 30°W. I shot the star. I consult an almanac for an assumed position AP of 1°N 31°W.

Here is what I know.

1. If my boat was at the assumed position AP, the star Sirius would be observed to be 12°19' above the horizon at a bearing of 253°.

2. From my real position, I observe the star Sirius to be 11°40' above the horizon which is lower by 39'.

3. Things further away look smaller and lower in the sky.

4. My position must be further away from Sirius than the AP at 1°N 31°W is from Sirius.

5. Planet SH3 has 1° = 120 km so that 39' difference in altitude would be 78 km is distance.

6. There are an infinite number of positions on planet SH3 that are 78 km further away from Sirius than is the AP. But the ones near my boat run on an almost straight line at right angle to the Sirius bearing.

7. I must be on that line.

Using the ingame mapping tools, this is what I do.

I plot the bearing from AP to the star. I advance or retreat with the ruler the distance toward or away from the star. I draw a right angle and call it the Line of Position for the star.

Repeat two more times and I get the error triangle that should contain my position if everything was done right and everything was right.

Read the whole thread. I went into this thing with my eyes open. I am attempting to quantify the errors. I am stating my assumptions and I am showing my results, including the errors.

My mods are available for download, link in my signature.

CaliEs

05-06-12, 08:11 PM

We started on the Equator and shot 3 navigation stars separated by about 120° in bearing to get a nice shaped error triangle. ...

Another question...
http://img.xrmb2.net/images/913275.jpeg
Is this a typing error?

11Bravo

05-07-12, 02:57 AM

:oops: Yep, that was a typo.

Here is the corrected plot. :)
http://img571.imageshack.us/img571/8028/mission3a2.png

vanjast

05-08-12, 04:44 PM

Remember that you want to simplify it as far as possible.
If you make it complicated (ie: exit game run other proggy), kinda destroys the immersion.

PDFs, charts and in-game stuff work better
:)

P_Funk

05-08-12, 08:34 PM

I much prefer in game methods. I'd rather plot a dead reckoned course on a piece of paper in my lap than have to alt tab and use another program (I consider pen and paper on my computer desk as being in game :cool:).

I honestly think it would be a really cool thing to have a bunch of track charts from previous patrols just kicking around my stack of papers.

Speaking of which, how would I go about drawing my own track chart? I suppose it means having a scale set up to measure nautical miles in centimeters or something as you plot it on your paper. All the track charts of actual U-boat patrols I've seen were mostly on blank paper or grid maps with no subgrids so it was very bare looking.

Anyone have any suggestions on websites for this? I'm gonna go do my own googling but since there are people here who are well deeper into this maybe you have some insights for me. I may just make my own track chart for my next patrol on a whim to see if I can suffer keeping up the level of detail necessary to pull off a full Real Nav patrol.

LemonA

05-08-12, 10:44 PM

I honestly think it would be a really cool thing to have a bunch of track charts from previous patrols just kicking around my stack of papers.

Speaking of which, how would I go about drawing my own track chart.

Try using google.maps, if you have an google-email-account. Collect Lat/Long + Time at every DR-position and put it in the maps. Connect the DR-positions. Then you get the route. Save it. Make it available to the public.
http://img.xrmb2.net/images/827199.jpeg

11Bravo

05-09-12, 02:27 AM

@vanjast
@P_Funk

:yeah:

In-game + pencil/paper + simple as possible = my goal.

The biggest challenge to this will be the almanac I suspect. I am using a computer program currently for convenience. But I also went to the other extreme of solving the nautical triangle directly using only a table of logarithms, no calculator. Using presolved almanacs is the middle path, and probably historically accurate. Hopefully we can use an existing publication and not have to make a custom one from scratch.

@LemonA

That is pretty cool. I will have to check that out. Does it accept degree minute format?

That reminds me that we need a ruler to better measure lat lon coordinates for reporting or plotting on paper. I made one once and I will do that next.

P_Funk

05-09-12, 03:21 AM

Try using google.maps, if you have an google-email-account. Collect Lat/Long + Time at every DR-position and put it in the maps. Connect the DR-positions. Then you get the route. Save it. Make it available to the public.
http://img.xrmb2.net/images/827199.jpeg
Thats a cool idea. My goal longterm is to make at least one full patrol that has a proper KTB in the real format used including all attachments. This means the main KTB with full descriptions of everything that happens along with grid references, firing reports, and track charts, maybe even a radio log since GWX adds a butt load of those and I can easily write my own and send update reports to BDU to simulate this and record them in my log. I already made some templates for typing them up in photoshop so that they appear like captured documents preserved, stamped, and microfilmed for archives by the British, and I can easily I figure scan any track charts I make too since I have a scanner.

I am a bit of a role player. :cool:

@vanjast
@P_Funk

:yeah:

In-game + pencil/paper + simple as possible = my goal.

The biggest challenge to this will be the almanac I suspect. I am using a computer program currently for convenience. But I also went to the other extreme of solving the nautical triangle directly using only a table of logarithms, no calculator. Using presolved almanacs is the middle path, and probably historically accurate. Hopefully we can use an existing publication and not have to make a custom one from scratch.
Well I imagine it would be pretty ridiculous to try and print out a copy of the almanac given how many possible locations and days and times over the 6 years of the war there would be. Also, there probably isn't an easy way to find a real almanac from that time period anymore in print.

I do agree that the simple and authentic pencil/paper method is most appealing. The more I have to plug something into a modern apparatus the more it detracts from the fun of it. I already use a calculator for some of my TDC calculations and I don't want to go much past that for anachronistic affectations.

I'm not only excited by your work Bravo, but also by your attitude about it. A project that appeals to me on multiple levels. :up:

11Bravo

05-09-12, 04:41 AM

http://img51.imageshack.us/img51/7792/mission3a8.png

Does anyone know the authentic way to report latitude and longitude?

Is it latitude first or longitude?
Do you put the N/S and the E/W in front of or behind the value?
And any spaces between anything?

@P_Funk

Thanks!

11Bravo

05-09-12, 04:48 AM

:hmmm: Haven't received a mail, can you send it again - or PM me here. :up:

Sent you mail a few days ago. Your app seems to work fine. It is a little strange to see the clocks work correctly in SH3. :haha:

Only problem is running a second app along with SH3 makes testing sloooowww on my old computer.

:salute:

urfisch

05-09-12, 04:54 AM

extremly interesting topic!!! great work so far!

:yeah:

LemonA

05-10-12, 11:50 AM

Most nav charts have first Lat then N or S then space then Long then W/E:
54°34.897'N 011°16.063'E

The "Nautical Char Ruler" would be extremely usefull. Any chance to release it?

Nautical almanacs '39-'45, SightReducTables etc. already exists and as far as I know for celestial calculation useable.

162 pages for year 39
http://img.xrmb2.net/images/484554.jpeg

400 pages for Part "Lat 40-60"
http://img.xrmb2.net/images/934780.jpeg

11Bravo

05-11-12, 06:16 AM

@LemonA

Thanks for that information. Yes, I will release the chart ruler tonight after work.

P_Funk

05-12-12, 01:30 AM

400 pages for Part "Lat 40-60"
Yikes. That'd be a mammoth printer undertaking to get every book we need.

palatum

05-12-12, 04:21 AM

Could the nautical almanac be integrated ingame? Like the ship recognition manual? Or would it be to big?

-Pal

11Bravo

05-12-12, 06:22 AM

@urfish

Thanks Kaleun! It has been very challenging and fun for me.

@LemonA

I uploaded the chart ruler even though voyage 3 is far from complete.

@palatum and P_Funk

There would be no practical way of presenting the very precise information found in a nautical almanac as in-game graphics. There might be a way to create a condensed version of low precision data that would cut down on printing. There might even be a way to put something useful in-game, like a perpetual almanac or sunrise/sunset table in-game. It all depends on how much accuracy is necessary. If the method is limited to 30 km, we only need celestial data good to 10 arc minutes, not 1 arc minute or arc seconds.

Most likely the final solution will involve pdf's that the player would print out, although the actual books should work better.

11Bravo

05-12-12, 06:43 AM

Weekly update

Nothing worth posting this week. Lot's of testing trying to break the clocks per vanjast's suggestion a while back. His observation was that sometimes saving and loading a game can change the clocks. After a week of testing I finally got the game to display the wrong sky data for the displayed time. :o

Since synchronized sky and time is the basis of celestial navigation, this will be an important game bug or feature to understand. :rotfl2: So I am going to focus on that for a while. :damn:

Wolfstriked

05-13-12, 09:02 AM

Great stuff Bravo:salute: I wonder is there a way to fix the game so that when you get near land you get the pop up screen that springs up when an aircraft is spotted?I ask this because one has to set the land spotted TC speed to low so you have time to change course but this causes the terrible TC when traversing the Kiel canal issue.I have my near land TC speed set to 128 and its worlds better but I have also finished patrols only to crash into land.:nope:With manual navigation this will become very apparent.

P_Funk

05-14-12, 12:25 AM

@palatum and P_Funk

There would be no practical way of presenting the very precise information found in a nautical almanac as in-game graphics. There might be a way to create a condensed version of low precision data that would cut down on printing. There might even be a way to put something useful in-game, like a perpetual almanac or sunrise/sunset table in-game. It all depends on how much accuracy is necessary. If the method is limited to 30 km, we only need celestial data good to 10 arc minutes, not 1 arc minute or arc seconds.

Most likely the final solution will involve pdf's that the player would print out, although the actual books should work better.
Well a way to create a compromize on the massive volume of information would be to create modules of the relevant information that could be displayed somehow in game like the recog manual is through SH3 Commander. With SH3Cmdr you can create folders that copy information into the game based on your active patrol date. I'm not sure if its possible if we can create a limitation that copies it based on patrol area as well. Since we'd only need a very small portion of the total available almanac given the known area you'd be patrolling this seems like the best alternative. Even without SH3Cmdr we could create different sets of information for month/year based on broad geographic areas. Add that to a trimmed down accuracy as you've suggested, it may be possible to create modules you activate before patrol through JSGME much the same way the Merchant Fleet Mod has different folders for skins based on month/year.

Ultimately having a pdf of everything is preferable but having a shortened version in game would be nice since alt-tabbing or having a stand by laptop isn't as nice, not to mention alt-tabbing is known to create its own issues with SH3.

vanjast

05-17-12, 04:09 PM

Weekly update
After a week of testing I finally got the game to display the wrong sky data for the displayed time. :o

Ah.. the jaw breaker has arrived..
If I remember correctly, when you load the game the GMT time (or your base time) is set to the ship's clock (your current position time).. or visa versa, until you cross a time zone. This of course makes your navigator pace up and down the deck muttering obscenities to himself (which one cannot mention on the forum.. of course :) ).

This is why I mention that you have to write down the real times each time you save/load the game... i didn't look to far into this as i had RL things to attend to.

vanjast

05-21-12, 05:27 PM

Just curious on your progress about this point ?
:)

I've been thinking about this problem lately, and it might be within the save/load structures where the time parameters are f.. (whoops careful - SailorSteve is watching) Ahemm! messed up
Maybe Hsie might be able to look into this, if not he can contact me :-)

mikey117us

05-23-12, 12:59 PM

In the early war to mid war, the clocks are set to German legal time, GMT+1 Mitteleuropische time. Mid-war they changed german legal time to GMT+2. This makes sense from the KW (wireless) point of view, keeping the clocks set to command control communications and intelligence time to receive orders and important comm. Navigators placed sunrise high noon sunset and weather data in in the KTB. What hell it must be to resume your bridge watch on german time + as you reach the East Coast of the U. S. and your watch has moved from daylight to the graveyard shift, sleep patterns are altered crew gets grumpy morale is affected. U-Boat Archive has several KTB's with the sunrise sunset data for the month/year. I've always been amazed when surfaced to see my friend Orion Rising over the horizon and wondered if thats where it was in june of 1942? Now I am mostly in the late war where U-Boat Navigation changed. Dead Reckoning, soundings, known landmarks and Elektre-Sonne beacons were used to get a fix. So I drag and drop on the map my course and leave it at that, remove the Sub Icon on the map and Navigate across the sea? Would be awesome!

11Bravo

06-02-12, 05:18 AM

Real life has robbed me of my game time, so I have done nothing on this. Back at it in a week or so when I get some time off. :arrgh!:

vanjast

06-03-12, 02:01 PM

Real life has robbed me of my game time...
It's so annoying that ... I mean there's a war to be won, does the world not realise this :)

palatum

06-03-12, 02:39 PM

Real life has robbed me of my game time, so I have done nothing on this. Back at it in a week or so when I get some time off. :arrgh!:

Just set 128 TC in Real Life, that should be about 80 minutes :haha:

Sartoris

08-06-12, 05:38 PM

Hopefully this is still being worked on, I really liked the idea!:up:

Let us know if there's any progress.

CommanderU

03-04-13, 04:00 AM

What an excellent thread, i´ve learned much so far. What a pity it broke off. Is there somebody out there, who knows if these thread-results were enhanced or used by other projects? And question #2... : Does anyone still have the files released by 11Bravo? His gamefront-page is empty.

I`m really no modding-pro at all, but i would spend some time to come a bit closer to Bravo`s goal, the celestial navigation in sh3. Having his files would help for there are some questions left, despite Bravos clear presentation.

CaliEs

03-04-13, 01:41 PM

goto http://www.subsim.com/radioroom/showpost.php?p=1418782&postcount=4

The other day i had trouble to open 11Bravo's files. Maybe a glitch, maybe not.

CommanderU

03-04-13, 03:52 PM

goto http://www.subsim.com/radioroom/showpost.php?p=1418782&postcount=4

The other day i had trouble to open 11Bravo's files. Maybe a glitch, maybe not.

Thanks a lot, mate! :up: Voyage Two is not available, but the other files were successfully transmitted.

CaliEs

03-04-13, 04:30 PM

http://www28.zippyshare.com/v/10817307/file.html (2.8 MB) 11Bravo CelNav Second Voyage (link valid for some days)

Pisces

03-04-13, 06:38 PM

The 11BRAVO files will be mirrored on my site (http://ricojansen.nl/downloads) in a few minutes from now.

CommanderU

03-05-13, 03:12 PM

Cheers, this helped a lot. :Kaleun_Salute:

JeromeHeretic

04-23-13, 01:38 PM

I did some sun measuring today and it looks, that sun in SH3 world goes every year exactly in the same way (and leap year day is ignored and simply sun is setting and rising in the same time as day before). It's cool, because there's no need sun almanac for all years of war, byt only one for whole age. :-)
Stay tuned, more to come, now i must read Bravo's text about this fuzzy clocks in SH3, because i measured the same sunset and sunrise in the same time on 0N 0W and on 0N 30W, which is not possible. So where is f*cking GMT?

JeromeHeretic

04-23-13, 02:07 PM

BTW: I found one interesting rule. When sunrise is for example in 5:56, so sunset will be in 17:56. Rule is simple, sunset is in exactly the same minute as sunrise, so we have sunrisehour:X sunsethour:X.

Edit: This rule failed. Works only on equator and only sometimes. :-)

JeromeHeretic

04-23-13, 04:00 PM

[...]
where %02d:%02d updates the text values.

Will see if I can do a workaround, if not the Modded Map that 11Bravo made can be used to see the timezone for localtime.

IMHO it's not important. I can easily live without local time, but hardly need GMT. Will be nice to see GMT on interior watch in my uboat...
Did you do any progres with this problem?

JeromeHeretic

04-23-13, 04:23 PM

Longitude is not too much a problem... but it's Latitude that's way off - correcting this to USNO's almanac will be interesting.

Yes, i must to do a bit more tests, but it looks like there is possibility to create a funcional almanac for SH3 Sun, which will be fake in the same way as sun in game.

JeromeHeretic

04-23-13, 05:15 PM

I ask this because one has to set the land spotted TC speed to low so you have time to change course but this causes the terrible TC when traversing the Kiel canal issue.I have my near land TC speed set to 128 and its worlds better but I have also finished patrols only to crash into land.:nope:With manual navigation this will become very apparent.

I did my own tuning of vajnast's real nav mod, so NO can plot search patterns (me not). It's needed let enabled commands for ploting patterns and one "return to course" one, because NO is not returning to course automaticaly after ploting of the pattern. For me is boring drive uboat in patrol grid and drive search pattern by myself and traveling through Kiel kanal too. So i have near land TC set to 1024 and using NO autopilot patterns for Kiel kanal route. For real nav friendly people i want prepare buoy way at the Brunsbuttel side of canal which will navigate you to right position from where to let plot NO route back to Kiel. I think it's good compromise between reality and fun in game. In fact, captain is not working all work alone, for this boring jobs have his officier, isn't it? :-)

JeromeHeretic

04-23-13, 05:20 PM

Maybe Hsie might be able to look into this, if not he can contact me :-)

It could be nice if Hsie will be able patch engine for GMT on screen clock!

JeromeHeretic

08-09-13, 10:37 AM

Well, here it is. The sun almanak for north hemisphere.
This is a time of the moment when the red light turn on/off.
I did it like this, because different settings of grafic card (and different mods too) may cause a different view of the sun. So when you want to measure moment of sunrise/set respectively moment of redlight turn on/off, you must measure time when lower limb touch horizon, then measure time when upper limb touch the horizon and difference between this two number divide by two.
Like this when sunset: ( uppertime - lowertime )/2 + lowertime = redlight_on_time
Like this when sunrise: ( lowertime - uppertime )/2 + lowertime = redlight_off_time

rise set
0N
1.1 0602 1803
1.2 0613 1813
1.3 0612 1812
1.4 0603 1803
1.5 0556 1756
1.6 0557 1757
21.6 0601 1801
1.7 0803 1803
1.8 0606 1805
1.9 0559 1759
1.10 0549 1749
1.11 0543 1743
1.12 0548 1748
21.12 0557 1757

10N
1.1 0619 1746
1.2 0625 1801
1.3 0617 1806
1.4 0600 1806
1.5 0546 1807
1.6 0541 1813
21.6 0544 1818
1.7 0546 1820
1.8 0553 1818
1.9 0553 1805
1.10 0551 1746
1.11 0553 1733
1.12 0604 1733
21.12 0615 1741

20N
1.1 0637 1728
1.2 0639 1747
1.3 0623 1801
1.4 0557 1810
1.5 0534 1819
1.6 0524 1830
21.6 0526 1836
1.7 0528 1838
1.8 0539 1832
1.9 0547 1811
1.10 0554 1744
1.11 0604 1721
1.12 0621 1716
21.12 0632 1722

30N
1.1 0658 1707
1.2 0654 1732
1.3 0629 1754
1.4 0553 1814
1.5 0521 1832
1.6 0504 1850
21.6 0505 1857
1.7 0507 1858
1.8 0523 1848
1.9 0540 1818
1.10 0556 1741
1.11 0617 1709
1.12 0640 1656
21.12 0653 1701

40N
1.1 0724 1642
1.2 0713 1713
1.3 0637 1747
1.4 0548 1819
1.5 0505 1848
1.6 0440 1914
21.6 0438 1923
1.7 0442 1924
1.8 0503 1907
1.9 0531 1826
1.10 0600 1738
1.11 0632 1653
1.12 0705 1632
21.12 0720 1635

50N
1.1 0800 1605
1.2 0739 1647
1.3 0648 1736
1.4 0542 1826
1.5 0442 1911
1.6 0405 1949
21.6 0400 2001
1.7 0404 2001
1.8 0436 1934
1.9 0519 1838
1.10 0604 1733
1.11 0653 1632
1.12 0739 1557
21.12 0757 1557

60N
1.1 0905 1500
1.2 0822 1605
1.3 0705 1719
1.4 0532 1836
1.5 0407 1947
1.6 0305 2050
21.6 0254 2108
1.7 0259 2106
1.8 0350 2019
1.9 0501 1856
1.10 0611 1726
1.11 0727 1557
1.12 0838 1458
21.12 0904 1450

70N
1.1 0 0
1.2 1003 1423
1.3 0737 1648
1.4 0513 1855
1.5 0249 2107
1.6 0 0
21.6 0 0
1.7 0 0
1.8 0158 2208
1.9 0425 1931
1.10 0624 1712
1.11 0841 1444
1.12 0 0
21.12 0 0

80N
1.1 0 0
1.2 0 0
1.3 0927 1500
1.4 0418 1955
1.5 0 0
1.6 0 0
21.6 0 0
1.7 0 0
1.8 0 0
1.9 0213 2133
1.10 0702 1632
1.11 0 0
1.12 0 0
21.12 0 0

complutum

08-09-13, 08:16 PM

I have read the hole thread and find it awesome.

Is there any news on it?

I have noticed the author has been away so long.

I hope he is still developing this.

Karl Heinrich

12-08-13, 05:28 PM

Having been considering working on something similar, including a fictional almanac as it were, I am absolutely blown away by the work here. Again some greater progress towards real celestial navigation. If only that pesky save game drama can be fixed...

I hope there's still a future for this project as its very very promising indeed. Staggeringly impressive work 11Bravo.

JeromeHeretic

12-11-13, 01:58 PM

Don't be afraid, now i'm working on coastal navigation. I got a list of 23779 lighthouses and lightboats, now i'm working on cleaning it, remove duplicity, reducing to relevant only (there is a lot of river lighthouses which are irelevant for SH3) and so... It's a lot of work about it and cost a lot of time, so progress is slow.

Karl Heinrich

12-11-13, 04:48 PM

That sounds fantastic Jerome... something that had been on my to do list. I'm actually working on a slightly secret SH3 nav project myself at the moment and that would be MASSIVELY useful, would you mind if I sent you a PM?

Similarly I've been working on my project for a long time and it's a lot of hard work, but wel all know these projects and the love we put into them are always worth it :)

JeromeHeretic

12-12-13, 04:03 AM

Well, about PM, go on!
BTW: If you have some (not secret) TODO list, write it there, can be usefull tell who will do what and avoid paralel work on the same problem.

About lighthouses - My idea is, that at the end there will be list of relevant lighthouses and program which will be able import this list to any locations file. Like this import of lighthouses will not depend on certain configuration (or supermod).
(Of course by this way is not problem to "precook" instant location file for all well known megamods, with usable generator it's trivial...)

Now i'm searching for solution how to import lighthouses to map. Only method, which i can do at this moment is append lighthouse list to save file visible as "X" marks in map. (The same X what you can point in map by map tools.) Usable, but not the best solution IMHO.

Karl Heinrich

12-12-13, 05:20 AM

That sounds great. Nope, I don't have a non-secret todo list right now, so there should be no doubling up of work - but good suggestion, I think it's always best to share what you're working while working on it.

Your work sounds superb for coastal navigation, I don't know if you saw my thread from earlier this year - http://www.subsim.com/radioroom/showthread.php?t=205416

Hmm to make it so it would work with all supermods sounds tricky, as you say using the X would be very useful even if not the most elegant approach - but I would be very happy to see it with just the X.

Will send you a PM later today sir (just headed off to work now... :shifty:)

JeromeHeretic

12-18-13, 11:50 AM

areo16

12-18-13, 03:20 PM

FYI, there is table with all lighthouses, which i have: http://www.ucw.cz/~jerome/lighthouses.html (it's BIG, so be prepared for slow load of page!)

Now it's raw data, without any modifications, later there will be visible changes what my scripts and me do for SH3 implementation.

Lighthouses show on the map from Locations.cfg and the LocationName= field.

It would be easy for me to write a script that converts your table to real lighthouses in Locations.cfg so they show in game as models of lighthouses and show on the nav map.

JeromeHeretic

12-18-13, 04:30 PM

For me it's easy too. But at first is needed clean this horrible mess to relevant only.
And except it, it's not so easy. There are lightboats too, there are groups of lighthouses in ports which are not in SH3. And lighthouses in table are not coresponding to piers in ports in SH3. Piers in SH3 are defined by model, location and orientation. Is needed to write script, which is counting everything this... And there is much more about it - underground lighthouses, flying lighthouses, lighthouses which are in game now, i must write script for extracting ingame lighthouses, and so on...
Take time... is needed to continue step by step. The worst job was creating of this list (two months of work). Rest is "only" a few of data sorting and a bit of programing.

areo16

12-18-13, 04:39 PM

areo16

12-18-13, 04:46 PM

If I were you I would create script to place all lighthouses in emply locations.cf file. Then look to see if all are placed on land, correctly. If so, then move on to the piers.

Have you tried scripting this: http://www.ucw.cz/~jerome/lighthouses.html

into locations.cfg?

JeromeHeretic

12-18-13, 05:22 PM

1. I already have a script, which can put X marks to map, where lighthouses are located.

2. "Then look to see if all are placed on land, correctly." - It means not only generate locations file, it means generate single mission for every lighthouse, load this mission and check if lighthouse is realy OK. And no, i will do not manual check of 23779 lighthouses, i'm not crazy and life is too short for it. :-)

3. There's no ingame lightboats, but user AG124 (http://www.subsim.com/radioroom/member.php?u=220201) create this:
http://www.subsim.com/radioroom/downloads.php?do=file&id=805
http://www.subsim.com/radioroom/downloads.php?do=file&id=129

4. Why it's so important? Because after a week of long storm, when coming near to land, you have error in location where you think where you are and where you realy are about 100 km. And coast is everywhere the same... you see a land, but you realy don't know, where you exactly are.
And (depend on mods you have) when you travel in dark, stormy night, lighthouses are only point of navigation. In some mods you have no chance to see a land. You detect it only by crash. God bless to lighthouses in this situation. :-)

areo16

12-18-13, 05:46 PM

1. I already have a script, which can put X marks to map, where lighthouses are located.

The lighthouse script you have doesn't place the lighthouses in the save game .map files, does it? Because that is not a good idea.

2. "Then look to see if all are placed on land, correctly." - It means not only generate locations file, it means generate single mission for every lighthouse, load this mission and check if lighthouse is realy OK. And no, i will do not manual check of 23779 lighthouses, i'm not crazy and life is too short for it. :-)

Then how are you going to check every lighthouse?

JeromeHeretic

12-18-13, 06:33 PM

Then how are you going to check every lighthouse?

I don't know. And not solving this problem at this moment. As i wrote before - is needed to continue step by step. Now I'm selecting good data.

Write to .map file is good enough for now. And what's the best is, that by this method i can correct position of some lighthouses in game by moving it with mouse click and SH3 engine recalculate coordinates for me automaticaly. After new save i can read corrected coordinates from .map file (or i hope so..).

areo16

12-18-13, 07:29 PM

I don't know. And not solving this problem at this moment. As i wrote before - is needed to continue step by step. Now I'm selecting good data.

Write to .map file is good enough for now. And what's the best is, that by this method i can correct position of some lighthouses in game by moving it with mouse click and SH3 engine recalculate coordinates for me automaticaly. After new save i can read corrected coordinates from .map file (or i hope so..).

It is good idea during development to use .map for locations but you should not release it using .map. Because there are other mods out there that need .map and use it, like SH3 Dynamic Campaign.

JeromeHeretic

12-18-13, 07:34 PM

But i don't know better solution. Any ideas?

areo16

12-18-13, 07:44 PM

But i don't know better solution. Any ideas?

Use .map for development and adjusting coordinates, but just before release create script to grab coordinates from .map file and put the units in Locations.cfg.

JeromeHeretic

12-18-13, 08:40 PM

Of course. If it's not in location file, it's not in game. But still i need to see lighthouse location in map, without it are lighthouses completely useless.
And i don't know any other method how can do it visible in map. That's what i'm asking for.

JeromeHeretic

12-18-13, 10:02 PM

Well, duplications are disabled (not all are realy duplications, usualy are close enough), next step will be sorting to groups port by port and reducing groups to single lighthouses.
lighthouses.html regenerated. Actual statistics:

All: 23779 Enabled: 13037 Disabled: 10742

Im tired, now go to sleep. I think it was enough for one day. :-)

areo16

12-18-13, 10:13 PM

areo16

12-18-13, 10:24 PM

You mean on the nav map? Not the scenario editor.

That would be unrealistic! A navigator isn't going to mark the spot of all lighthouses on his nav map at the start of every patrol!

JeromeHeretic

12-19-13, 01:15 AM

BigWalleye

12-19-13, 07:42 AM

Lighthouses are common in navy map of course. With height over the sea level for triangulation of distance (not possible in SH3, because height can be measured only on locked object and is possibly lock only boat).
In reality are almanac of lighthouses, with specifications about lighting (lighthouses are flashing in different colors and patterns).
So in reality navigator is not marking lighthouses to the map. In reality they are allready printed on the map...

JH is correct. Any good nautical CHART (they're not MAPS!) would have all prewar navaids printed on it. Of course, that prewar data might not be accurate any more....

As for determining the height of an object other than a ship, the R/L sub crews used the graticle markings of the 'scope or UZO. That's what they're there for. According to Hitman, there never was a stadimeter in U-boats built during the war. If you use one of his "Hitman Optics" mods, you will quickly get used to estimating heights with the graticle. It works well enough to give good firing solutions, is quicker than the stadimeter, and doesn't require a positive ID of the target. AND, it's the way the prototypical U-boat crews did it.

areo16

12-20-13, 03:09 AM

I've attached a picture of my nav map in game. It shows lighthouses as large circles. Not sure if this is a mod or not.

JeromeHeretic

12-20-13, 03:58 AM

Surely it's some mode. (And it's very ugly BTW)
Can you write here your mod list?
Particular design of this solution is realy horrible, but i can have a look how it's realized.

areo16

12-20-13, 05:42 AM

Surely it's some mode. (And it's very ugly BTW)
Can you write here your mod list?
Particular design of this solution is realy horrible, but i can have a look how it's realized.

I like it. It's much better then an "X" on the map with no data. This shows information about the lighthouse, and it doesn't conflict with other mods using .map file. :nope:

I don't have a mods list. I manually installed all mods over 6 years of playing this game.

I'll let you know what the files are and upload them when I get some time.

JeromeHeretic

12-25-13, 09:06 PM

Well, a bit of progress. I create groups of lighthouses in circle 1km and disable them exept one. Disabled all lighthouses from west coast of America.
Next i disabled all river lights, lights in big bays and deep firths. Number of lighthouses by this method was reduced to 10710. At morning will continue to do one lighthouse per port and sort for lighthouses, lightboats and buoys.
Result visible here: http://www.ucw.cz/~jerome/lighthouses.html (be patient, table is realy huge)

mikey117us

12-25-13, 11:43 PM

Starting in Autumn 1941 OberSteuermann ( Chief Quartermaster / Navigation Officer Not an Officer but could keep watch as one = to StabOberFeldwebel highest ranking enlisted man )began Navigation by Dead Reckoning (Gekoppelter Standort Koppelnavigation) for Test Purposes and comparing to Celestial Navigation (Astronomische Navigation) Sun and Moon Data for Accuracy (Morgenbesteck Mittagsbesteck Abendbesteck )then correcting ( Besteckunterschied ) . Eventually as Training Time was reduced for OberSteuerMann and the dawning of the Schnorkel Boats began Total Submerged Warfare Limited Celestial Navigation and gave rise to Elektra/Sonne Bearings ( Eigenpeilung ) when Radio could Receive well Other Radio Bearings, Soundings ( Behmlot and x-m-Linie ), and for the Inland Shore Campaign Pre-War Navigational Charts. The Following Excerpt is from the Unternehman Kriegstagebuch of OberLeutnant zur See Karl Jobst U-2326 a Type XXIII ( simply put they were unable on the 6th of May 1945 to receive Elektra/Sonne and the following day in heavy fog and mist surfaced their boat to figure out their position by using Nautical charts and visual bearings )

Place

Incidents
Day
Time
Weather

6.5.45 0000 Sq. AN 4561 SCHNORCHEL depth.
No reception of W/T routine.

0005 All-round listening, and battery charging by SCHNORCHEL.

0105 All-round listening.
Food eaten at A - 40.

0158 Battery charging by SCHNORCHEL.

0300 Battery charging concluded.

0305 No "Elecktra Sonne" picked up.

0317 At A - 30.

0400 Sq. AN 4555 A - 30.

0432 Dawn begins.

0800 Sq. AN 4549 A - 30.

1200 Sq. AN 4574 Day's run:
Wind: 1-2 Surfaced: -
Sea: 1 Submerged: 87.8 s.m.
Cloudy, C5 Total: 87.8 s.m.
Visibility 5 s.m.

1600 Sq. AN 4498 A - 30.

1759 Boat ventilated through SCHNORCHEL.

2000 Sq. AN 4723

2153 Twilight begins.

2246 Battery charged through SCHNORCHEL.

2348 All-round listening.

2352 All-round listening concluded, battery charged.

Place

Incidents
Day
Time
Weather

7.5.45 1600 Sq. AN 0123 Went to 30 m, and swept ((ablaufen)) in the
Wind: 0 direction of the bearing on course of 2800.
Sea: 0 - 1
Visibility: 6000 m.

1702 Boat touched bottom.

1716 Went to 195, headed for GIRDLE NESS, in order to obtain a fix.
Position calculated in AN 0126.
Bearings:
GIRDLE NESS = true
BANNER MILL = true
SOUTH BREAKWATER LIGHT = true
MIDDLE BUOY = true.
So The Pre-War Charts for the Coastal Shipping Lanes Off Scotland were still accurate and usable throughout the war.

JeromeHeretic

01-01-14, 10:25 AM

Well, big progress. I:
- remove duplicities from data
- reduce value of lighthouses to number about 2000.
- sort all as lighthouses or lightboats
- Added some lighthouses in "hic sunt leones" area (a didn't have data for whole world as i seen, there was places, where i didn't see any lighthouse)
- removed all river lights, which are not useful for game
- removed all lighthouses in deep firths and bays
- remove all lighthouses from west coast of America - they are not usefull for game
- added one lighthouse in every port in map (in GWX world). This feature is very usefull, because even concrete piers of ports have their own lighthouses, this concrete piers respawn to game much later as lighthouse defined in Locations.cfg. When someone is using 16km, or 20km environment mod as me, can see this lighthouses from 20km distance, the pier lighthouses are seen when sub comes closer to port...
- disable some GWX specific locations, which are buggy and lighthouses are not rendered in game.
- modify slightly coordinates of almost all lighthouses to fit perfectly to SH3 world. (In table link to google maps shows original coordinates, but SH3 coordinates may be differ. For seeing of exact location in SH3 you must get SH3 lat and long and count like this: SH3coordinate/2000/60 - this gives you real coordinate)

I have done script, which generate Locations.cfg.
I have done script, which generate X marks in map file.
Rest work is to do script, which generate data for Camaign_SCR.mis file (Lightboats and buoys are defined in this file)

Original data file can be seen here: http://www.ucw.cz/~jerome/lighthouses.html (i'm not using it anymore)
Reduced data file, which i use from now is visible here: http://www.ucw.cz/~jerome/reduced.html

Now i go to do some test and observations with new Locations.cfg...