It almost sounds as if that dreaded thing finally works! In the original thread, didn't someone mention that the sunset was at the wrong time? Did you check this out? I think they simply took their readings at sunrise and that's it! But if the sun position is correct all the time, we can do running sunline fixes and stuff like that!

http://www.dc3airways.com/TechEd/te_nav_lr_nav.html

While still somewhat simplified compared to the real thing, this mod really adds a lot of value to the game! :up:

This work is absolutely beautiful!

Both of you deserve the credits! When I had fiddled with the files myself, especially the cameras.dat issue, I quickly gave up on it because I thought that it is hopeless! But now you have proven me wrong! And I am so happy about it! :) ;)

Oh, BTW, does it still apply that "sunrise" and "sunset" in game are when the sun is halfway above the horizon?

And what I still don't understand.....is the clock setting actually locked to the nearest meridian of the starting location all of the time (so it has to be figured out only once), or does it change when reaching the next "big" meridian?

Next job for you: SH4! :lol: :lol: :lol:

If you can get accurate readings of other stars, navigation in the southern hemisphere should work as well. I truly believe that moon and stars are accurate as well. I had serious doubts regarding the simulation of the celestial system in SH, but now I am confident!

While you are on patrol, you may try out if running sunline fixes actually work now! I can't test it myself, yet. Too busy with modelling stuff.

Mikhayl:
"I think that's all for the moment, so far I have tested the mod with a GWX 2.0 + OLC 1.1.5 combination. It would probably work as well with OLC 1.1.4, I'm not sure, have to try it. But it sure won't work on any combination like "stock SH3 + OLC" or "NYGM/WAC/anything + OLC", BUT I have a 2nd SH3 install with these two supermods, so I guess if some of you guys are interested, I could make it compatible with not too much work."

YES PLEASE!!. Release for as many combinations as posible. Or a stock sh3 with directions on how to add it.

THANKS:D

This problem is known for quite some time now! I doubt that there is anything you can do about it. Without the plotting tool, the helmsman cannot stay on course. In fact, he's doing permanent corrections when you have plotted a course, but not when under manual control. It becomes even worse in storm. I think this is the only real problem that cannot be solved for real nav (hardcoded). The half finished cel nav features of SH3 lead me to believe that realistic navigation was a planned feature, but it was dropped due to time constraints. Perhaps Dan can tell us something about it. I'd suggest that you release it "as is".

The problem is as follows: When the player plots a course, the game engine uses the world coordinate system to determine the position of the waypoint, as opposed to the local coordinate system. That means, when you set a waypoint with the plotting tool, you tell the game to steer the boat to world coordinates xx°N XX°W or so. With local coordinates, you'd tell the game to steer 300° magnetic for 200 nm, then turn to 270° for another 100 miles or so. But changing plotting from world to local coordinate systems is certainly hardcoded and well beyond the scope of modding!

I feel your pain! :D Just after the release of SH3, I was one of the many guys who had to do the fundamental research of modding the game. It was a lot of work with little progress. No fancy editors and stuff. Just notepad. Teams formed up and fell apart again, many modders burned out and lost all interest. We have come a long way since then, I tell ya! Even though I stopped modding SH3 after the X1 debacle, I still enjoy following the progress of mod development.

As for the wind, I think it is worth a closer look! It might be a good workaround.

What's that? :o

Awesome! :rock:

I missed that being released. Thanks for the link :up:

Sorry for going OT...

Howdy gents,

I'm not a modder, I'm a navigator that still uses cel nav with sextant and nautical almanac to pinpoint my location on spaceship earth.
I've been subsimming since C64 days and my fondest wish was to someday be able to reinact navigation via virtual sextant and nautical almanac within a subsim before I made my final voyage.

Like many of you, I've tried to measure the angle of celestial bodies above the horizon with all sorts of gimmics and gadgets using SH1 to SH4.
I've used Virtual Sailor 7 (VS7) as it has the most realistic sextant to date, (it measures the angle of elevation to 4 decimal places) and it too is not accurate. VS7 has the stars on a separate transparent sphere from the separate transparent spheres that depict the sun, and the moon, and the planets. Each sphere is revolving around the users position, supposedly, on their rightful jouneys throughout any year or time period the "user" decides to sail.

The designer of VS7, alas, has paid more attention to the GPS configuration than that of Celestial Navigation's adherence to Nautical Almanac predictions.

I can only take my hat off to anyone of you modders who can get the job done; but, all we users are interested in is the War years between Sep 1939 to Aug 1945. The celestial ephemeris doesn't have to be compiled for a century.

As I have mentioned in other threads concerning this topic, navigating to within 30 nm is not nearly accurate enough. The Kreigsmarine and Allied Navies of the period were able to navigate within 0.5 MOA (1/2 nm)using the navigational instruments of the time.

Best wishes to you all. Your efforts are being followed closely and with great interest.

Tnx,

@don1reed

I'm thinking about getting a copy of VS myself, but I'm not really convinced, yet.

Did you try cel nav in MSFS already?

http://www.swiremariners.com/sextant/index.html

Hallo Nico,

No, I've not tried it yet; however, what you've provdided looks very promising. :up:

The sextant in VS is extremely well made and the concept is good; but, the celestial spheres are out of sync with reality and sometime will put the mariner 200 nm off. It would be wonderful if the sextant in VS could be adapted for use with SH3 & 4.

Cheers,

If you want to try out FS9, make sure that you install a better night sky set, like this one:

http://www.elbiah.de/flusi/MyFsStars/MyFsStars.htm

Regarding VS, it's too bad to hear that even a simulator dedicated to realistic navigation doesn't get it right. I think if we can achieve 30nm precision in SH3, it is certainly not that bad. Search areas will still be quite manageable, I think. I mean, more often than not the u-boats had to rely on dead reckoning for days, sometimes even weeks. It's certainly no showstopper for me.

*SNIP!* I think I got it! The solution for a sextant, I mean! All we need is a way to measure the amount of mouse movement in y-axis, from the horizon up to the object of interest! I recommend using the stabilized obs scope on high power for this. I think an external application could handle this. This application runs in the background, and when the user aligns the scope with the horizon, he presses a key combo that starts the measurement. The keys remain pressed until the scope is aligned with the object of interest and are then released. The application now reads the mouse movement in y-axis in the moment of pressing and releasing and converts this into degrees of elevation.

The benefits: a relatively high level of accuracy, in the range of 0,1° I think. No 60° limit, no swaying field of view.

There are two problems, though: 1. we need a coder! 2. Initial calibration by the user is required.

What do you guys think?

Excellent idea Nico!

Calibration is always required in RL, as you know.

The mariner/navigator must perform three tests with the sextant before using:
1)Test for perpendicularity of the Index mirror.
2)Test for perpendicularity of the Horizon glass.
3)Test for parallelism of the Index mirror and Horizon glass.

These test are not performed each time a sextant is used but at least on a scheduled basis for preventative matenance.

Index Correction (+/- IC) however, must be determined with each use. It is usually accomplished by viewing the horizon with zero degrees on the arc to see if the horizon is on or off the arc when viewed through the horizon glass.

An upper limb (UL) sight is less often used with the Sun but is often necessary with the Moon since the lower limb (LL) may not actually be a circular one, depending on the phase.

Good idea. Could be problems, though. For example, some mice have an acceleration feature which can be configured to the users taste, and which would mess up the readings. Also FPS/lag may have an impact, depending on how the game is coded.

Sounds like a minefield to me but maybe I'm just a half-empty kinda guy. :hmm:

OLC,

Would those mouse problems still exist if the player were viewing through the Obs/Nav scope? In other words, when viewing through the Obs/Nav scope
view the horizon...calibrate
rotate the scope upward to the celestial body
then measure the altitude
?

I am aware that there might be problems. But without a coder this discussion is moot anyway. Personally, I never got past "Hello World!", despite the excellent literature that is collecting dust on the shelf (i.e. SAMS C++ Primer Plus 5. Edition - what a tome!).

As for mouse acceleration, I think it can be handeled with a log scale instead of linear coordinates. In fact, the different mouse settings (acceleration, resolution, etc) are the main reason why I said that it requires calibration!

I think so, yeah. Unless SH3 ignores the mouse settings, which it might for all I know. Or alternatively, if this new tool takes account of the settings that'd do the trick too. I'm just trying to give a heads up.

Mouse acceleration makes the mouse move further when you move it faster. So if I move it 2cm slowly, the cursor doesn't go as fars as if I move it 2cm quickly.

And of course there's the normal mouse speed setting to consider.

Also in many games the resolution of the screen actually has an impact - something to consider if you want this tool to work with the high res fix.

As long as such things are taken into account I see no reason why it shouldn't work. Like I said, just trying to be helpful. :)