Base Time 2018 [Archive] - SUBSIM Radio Room Forums

Front Runner

11-19-18, 11:43 AM

UPDATE Base Time 2022

Base Time is as drifty as a Seaman Recruit on their first day at Great Lakes Naval Training Center!
Many of us have difficulty in making our Base Time adjustments from Zone to Zone when traveling east-west. Sometimes, the Sun or Moon Rise/Set times are so out of whack with our observations, even when making careful adjustments to our Base Time, that we just give up on it all. The following may explain why and what is happening. [EDIT] It appears that Careers starting in Pearl Harbor are using the Midway Base time. Midway is 11 hours west of GMT (UTC). Pearl Harbor Time is 10 hours west of GMT (UTC) but is physically 11 hours west of GMT (UTC). I checked Sunset and Sunrise times using the Almanac link below. I'm looking for verification. Thanks.

I've made many observations while remaining in the Brisbane Base Time Zone. My subs Base Time clock indicates what the local time is in the Brisbane Time Zone, 10 hours east of Zulu time. For my observations I did not transit east-west, outside the Brisbane Zone. I transited only from Brisbane north to the Bismarck Sea. I used the US Navy Sun or Moon Rise/Set Table for One Year as my Almanac times. (1944)

NOTE !!! Sept. 23, 2022 - GOOD NEWS! The below link is now back in operation. US Naval Astronomical Applications Department Data Services
https://aa.usno.navy.mil/data/index

NOTE: The NEW US Naval Astronomical Applications Department page allows adjusting time within a zone. So you may choose between 11 hours west, 11.25, 11.50, 11.75 incrementally refining your Sunrise/Sunset predictability while on station.

NOTE: Alternate Sunrise/Sunset Calendar. - https://www.sunrisesunset.com/custom.asp - You may create your own custom calendar using Lat/Long, Sunrise/Sunset, Moonrise/Moonset for a particular Month and Year.

I use the US Naval Astronomical Applications Department Sunrise/Sunset, Moonrise/Moonset Almanac to check my celestial sphere during gameplay.

I'm releasing my findings and observations about 1x play and how it affects the synchronization of the celestial sphere when using 2018 computer hardware.
It takes a long time to make observations at 1x, but I have nearly completed a series of observations which reveal some interesting side effects which absolutely affects gameplay, even when using typical time compression. After all, we have to go to 1x when making or avoiding attacks, sometimes for hours at a time. Typically though, players will constantly use a combination of 1x and time compression during these times.

Simply put....
When playing at 1x to 1024x time compression, the game is REMARKABLY accurate when rendering sunset and sunrise! (Compared to Almanac times.) A bit less accurate when rendering moonset and moonrise. However, when playing ONLY at 1x, a cumulative error occurs which offsets the synchronization of the celestial sphere so that the sunrise, sunset, moonset, moonrise times are out of sync with the Base Time clock, even when not traveling outside (east-west) of the Base Time zone.

OK, now here is the interesting part. The error seems to be directly related to the Vertical Sync setting in the Graphics Options. When Vertical Sync is selected on, there is a cumulative and noticeable error of the offset of sunrise, sunset, etc. (when played at 1x speed. I'm observing 60 fps with Vertical Sync clicked on.)
When Vertical Sync is un-selected, (I'm averaging 240 fps), the error offset is very much greater (when played at 1x speed). The difference is in many hours over a period of a few days.
That is why I posted my original message in the FOTRSU thread inquiring why my sunset, sunrise was off by many, many hours even though I was still in my Base Time meridian range. It was dark, but should have been daylight.

http://www.subsim.com/radioroom/showpost.php?p=2576383&postcount=6716

I'm arriving at the conclusion that with our modern computing hardware running balls out fps, a celestial sphere synchronization error is introduced (and cumulative) that affects the timing of certain events and may answer questions about strange behaviors. When it is visually midnight, but the Base Time clock says it should be daylight, you may think you are making a night attack, but, from the enemy's perspective, it is broad daylight and they can actually see you. (Even aircraft.)

I have repeated my series of tests and my observations are repeatable.

Try this, select Vertical Sync on (requires game restart), start at Brisbane, Jan. 3, 1944, outside the harbor. Steam (15 knots) directly to the 154 deg. 0 min meridian at 1x and thence directly north on the meridian until sunset (remain at 1x the entire transit). You start at about 1300 hours and sunset will occur approximately at the predicted almanac time of 1840 at 154 deg. 0 min E, 26 deg. 0 min. S.

I've observed sunset at 1824 (middle of sunset) 1827 (upper limb set). So, slightly early. (The next morning sunrise is 30 min. late, and the following sunset is 37 min. late at 1x (15 knots, proceeding north along the meridian.))

Now do the same thing, only with Vertical Sync off (requires game restart). I'm observing sunset on 01/03/44 at the same lat. long. quite a bit later (37 minutes) at 1904 (upper limb set). This is after only about 5 hours of 1x play! After 24 hours at 1x play the error becomes significantly greater!

Now do the same thing, Vertical Sync on (requires game restart), using typical time compression (1x-1024x) and you will see that the sunset occurs within a few minutes of the predicted Almanac time. After several cycles of testing this observation, day after day, sunrise and sunset, as I proceed to my Patrol Area (Bismarck Sea), I have to offer kudos to the Original SH4 devs. Essentially, they got this right! Sunset, sunrise, moonset and moonrise are within minutes of the Almanac predictions for each different lat. long.

When I play at 1x to 1024x with Vertical Sync on, the sunset/sunrise times are remarkably accurate, sometimes exactly at almanac predicted times! I've made these observations over a period of days from Jan. 3, 1944 to Jan. 10, 1944. I have yet to run a test with Vertical Sync off and 1x to 1024x play for comparison.

So, my conclusion, so far, is that it is best to play with Vertical Sync on, which minimizes the celestial sphere synchronization error when the game is played using 1x to 1024x (I have not tested anything more than 1024x because I saw no difference between 512x and 1024x observations. I'm assuming there is very little difference when using time compression above 1024x.) The error is very apparent when the game is played only at 1x speed. The error is greater when Vertical Sync is off.

This may explain why, after a long patrol, in and out of 1x play, we see such great discrepancies from what time we observe it should be, to what time the Base Time clock aboard our boat indicates it is, especially when playing with Vertical Sync selected off.

I have a few more observations to make and then I will post my results in a somewhat orderly sequence.

I am making four discrete observational tests.
(1) Playing at 1x with Vertical Sync on making observations at 1/3/44 Sunset, 1/4/44 Moonset, 1/4/44 Sunrise and 1/4/44 Sunset.

(2) Playing at 1x with Vertical Sync off making the same observations as in (1) above.

(3) Playing at 1x-1024x with Vertical Sync on making the same observations as in (1) above.

(4)Playing at 1x-1024x with Vertical Sync off making the same observations as in (1) above.

I would appreciate any others who wish to duplicate this series of tests in order to see if my observations can be duplicated.

Thanks!

[EDIT] See linked post....
http://www.subsim.com/radioroom/showpost.php?p=2581567&postcount=8

[EDIT] When using the US Navy Complete Sun and Moon Data Almanac, or, the Sun or Moon Altitude/Azimuth Table, when you are based out of Pearl Harbor, use ""11 hours west" of Greenwich"" to obtain the correct Base time (ie Sunset), and, when you are based out of Midway, use ""12 hours west" of Greenwich"" (ie Sunset) to obtain correct Base time.

See top of message for US Navy Link

propbeanie

11-19-18, 04:58 PM

Front Runner

11-20-18, 07:15 AM

Just for kicks, through a Game Save in there... When you restore from the save, you may or may not be on "local" time still. This effect is more pronounced when traveling East / West, instead of North / South. You start on base time, but after a save, we assumed you were on local time. Now you make me wonder :hmmm: :salute:

I save my test points frequently and I haven’t noticed any difference in Base Time when going from a test play-through that has been running for over 24 hours, then reloading that play-through.

propbeanie

11-20-18, 08:41 AM

I do know that you can get "different" results when traveling East / West across the "time zones" and Saving the game. Thanks for that Front Runner - and you also passed the "typo test" with "Through" thrown in there for "Throw"... :O: sorry 'bout that... It makes one wonder how the computer's clock and maybe multi-cores affects the game's "time" routines. :salute:

Edit: Now, I know this is easier to accomplish on a Win 8 or 10 machine, but on my Win7-64, you have to jump through hoops to run the Window Program Compatibility applet. You can get to it easiest from a "Search" on "Program Compatibility" or by right-clicking on the SH4.exe file, and choosing "Troubleshoot compatibility" about the middle of the top section of the context menu. Or you can go the long way and choose Properties, then the Compatibility tab, then the "Help me choose the settings" link, which brings up a dialog that then won't find SH4.exe, so you then have to "Browse" and choose it. Windows will then come up with a "solution" with settings for "Windows XP (Service Pack 2)". Since I've got multiple installs of Fall of the Rising Sun on my computer, I'll try and let my sub run North all night, beginning tonight, and see what I get with a WinXP SP2 setting on my computer, and get back with you Front Runner... :salute:

Front Runner

11-20-18, 05:57 PM

......It makes one wonder how the computer's clock and maybe multi-cores affects the game's "time" routines.
......I'll try and let my sub run North all night, beginning tonight, and see what I get with a WinXP SP2 setting on my computer, and get back with you Front Runner... :salute:

Sounds good. I’m trying the same thing. I had not thought of “compatibility mode” for WinXP SP2.

propbeanie

11-20-18, 10:21 PM

Front Runner

11-21-18, 10:55 AM

Some how or other, I forgot about my surgery tomorrow morning, so it would be Friday evening before I try that... It's a bear gettin' old...

DiectX v9 has been around since 2002, and Silent Hunter III since 2005. SH4 has a lot of 3 in it, and I wonder about the differences in the DirectX versions that over-write the game's v9... :salute:

Good points. OK. I think we may be tilting at windmills. I'm intrigued though.
By the way, I am using the time that the upper limb of the sun, or moon, is on the horizon as my sunset/moonset, Base Time. The object is completely gone over the horizon.

So, here is what I am currently going to try. I have downloaded and installed the DX9 2010 Runtimes from Microsoft.

https://www.microsoft.com/en-us/download/details.aspx?id=8109

This is a two step process. First download the file to any folder you wish and then run the installer (as administrator). Some say that this is unnecessary as Windows 10 (probably other older versions of Windows, after XP) install all variations of Direct X for backward compatibility. None the less, I installed it. You can probably check by searching for "d3d9.dll". I use the App "EVERYTHING" as my computer file search engine.

https://www.voidtools.com/downloads/

Next step is to create a shortcut to desktop from the executable you are using to start SH4 (in my case I renamed SH4.exe to FOTRSUv71.exe)
Right click on the shortcut and in the target field add "-force-d3d9" (without the quotes) For example my installation is on Drive D in the Subsims subfolder, so mine reads
"D:\Subsims\SH4FOTRSU\FOTRSUv71.exe -force-d3d9"

Run SH4 from the shortcut. I don't know how you can tell if it works or not but I believe the research I did to get there. (see EDIT 1) Follow the instructions for GOG on the following link.

[EDIT 1] Yes, I have found the way to check to see what version of DirectX that SH4 is currently using. Download Process Explorer from Microsoft. I put it in my Utilities folder. Run it as administrator. In the "View" tab, select "Show Lower Pane" and then "Lower Pane Views", select "DLLs". I can verify that my FOTRSUv71.exe is using d3d9.dll. :)

[EDIT 2] This track appears to be a red herring. Even with compatibility settings off, SH4 will (automatically?) use the d3d9.dll. I found this out by removing compatibility settings, running the game directly from the executable, (no shortcut) and checking Process Explorer. :(
I'm still proceeding with my 1x test, as described, just in case I'm missing something. #TiltingAtWindmills

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

https://inxile.zendesk.com/hc/en-us/articles/115004658428-Force-DirectX-9-Windows-

Test the game to make sure it still works. In my current test I am going with 1x play with Vertical Sync on to see if there is a difference in my previous test points, 01/03/1944 Sunset (1840 Almanac time, 1827 Base Time) and the 01/04/1944 Moonset (0016 Almanac time, 0029 Base Time).
I am also using the WinXP SP2 compatibility mode and running as Administrator and forcing DX9.

In addition, I have found the extension for the nVidia control panel, "nVidia Inspector", which allows you to create a profile using your SH4.exe and then limiting the frame rate to whatever you choose.

I'm not sure if this will actually have any effect on SH4 at all, even with frame rate limited. I tested it to make sure it actually limits the frame rate, it does, but I have yet to do a 1x test with it activated in order to observe whether or not it has any effect at all.

https://www.guru3d.com/files-details/nvidia-inspector-download.html

I'm going to try the 1x with Vertical Sync on plus the XP SP2 compatibility and forcing DX9 before I introduce frame rate limiting.

[EDIT 3] I ran the test (1x, VS on, XP SP2 compatibility, forced DX9, admin) and got a slightly different result. Hmmm. Gained 2 to 3 minutes of accuracy in favor of the Almanac time. Base time on earlier runs for the 1/3/1944 sunset were consistently 1827. On this run, Base time indicated 1/3/1944 sunset 1830. Almanac sunset is 1840. I'll need to run this test again to be sure.

I'm trying frame rate limiting next to either rule it out or verify the error is directly related to fps.

[EDIT 4] OK. I ran the test (1x, VS on, XP SP2 compatibility, forced DX9, admin and frame rate limited to ~54-55 fps. There is definitely a difference in my arrival at the 1/3/44 sunset point (154 deg. 0 min. east, 25 deg. 52 min S) Base time for sunset (upper limb setting below horizon) was 1847 which is 7 minutes later than the Almanac prediction (1840). My first test runs had sunset occurring consistently at 1827, 13 minutes early with VS on and 60 fps. My next test run with XP SP2 compat. and forced DX9 was 1830, ten minutes early. It looks like fps definitely has an effect on the celestial sphere synchronization issue. Wow, I was not expecting that because the frame rate limiter is external to the game. This is now beyond my pay grade. I don't understand the timing issues in game from way back in 2007 when SH4 was being developed. All I can do now is tweak my nVidia Inspector settings until I've minimized the sync issue. Time to just PLAY THE GAME which, BTW, is still great after all these years! FOTRSU makes it even greater! My solution may vary widely with your solution if you even dare take this long road to perdition. :)

Simply put, set VS on and play at 1x to 2048x time compression and ignore the errors.

I've got coffee!!! And, the next few days off.

Oh, one thing that gets me through the 1x play is listening to Fred's Radio Stations, I have many, while interacting with the game. I love vintage radio.

Propbeanie, Good luck with your surgery. Getting old is, well, challenging. I just turned 70 myself. Egad!

Front Runner

12-14-18, 10:28 AM

(Note: This is mainly for those interested in 1X (no time compression) play and/or how 1X play between time compression play affects the timing of the celestial sphere.)

I've been doing some more 1X play experimentation. I currently have my graphics card vertical sync settings set to 1/2 refresh rate of my 60 hz monitor (using nVidia Inspector), so I'm getting 30 fps on my 60 hz display. The 1X accuracy over time appears to be very acceptable. The graphics are just fine at 30 fps. Remember, that this is a 2007 game and some of us were struggling, at the time, to even get up to 30 fps. I have no idea why the developers chose to use celestial sphere timing that appears to be frame rate critical. I think of it like this, the sea is, more or less, a fixed screen display, while the celestial sphere plays somewhat like a "movie" in the background. If there are excess frames per second displayed it appears that the movie plays too fast. Think of it as if the video portion and the soundtrack are out of sync. I've been tracking (1X) sunset, moonset, sunrise, sunset, moonset and so far, all have been within single digit minutes early or late compared to very large (30 to 90 minute to 120 minute) differentials when playing without vertical sync enabled at full frame rate capacity. In my case about average 240 fps (balls-out).
As I've stated before, that high fps differential accumulated during 1X play can affect the day/night, sunrise/sunset, moonrise/moonset cycles so that, theoretically, your own ship appears to be under way in the darkest of night, while the BT clock indicates it should be daylight hours (I'm on a north-south track and I haven't changed BT time zones east-west,) and to your enemies in the game, it IS daylight hours and they can see you! It is out of sync to you, but not to them.

propbeanie

12-14-18, 11:17 AM

I can confirm the "error" with sync off on my computer. I definitely find it interesting that limiting the frame rate of the game also helps "correct" the problem... Thanks for all of your testing of this Front Runner. As a side note, CapnScurvy has the FotRSU mod now set to a default of "Sync On" in the graphics settings area. :salute:

Front Runner

12-15-18, 08:27 AM

I did a bit of research on 30 FPS games and found that UBIsoft actually recommends setting many of “their” games to 30 FPS..
Here is a link to UBIsoft customer support post about FPS. Interesting.
https://support.ubi.com/en-US/faqs/000031917

Also, here is a discussion about adaptive v-sync and 1/2 refresh rate.

https://steamcommunity.com/app/234670/discussions/0/810939350992635448/?l=turkish

I’m finding that SH4 runs very smoothly using adaptive v-sync and 1/2 refresh rate. I’m getting 30fps and very few “micro-pauses”.
I’m not having any noticeable “input lag.”
These settings, so far, nearly eliminate the “No V-sync, “balls out FPS” synchronization error that I previously reported.
I’m well into my third day underway at 1x play and my last sunrise was off by only 2 minutes! I believe that SH4 runs best, all around, at 30 fps.
I’m now wondering if the synchronization error also applies to SH3!

KaleunMarco

12-15-18, 10:33 AM

propbeanie

12-15-18, 12:38 PM

Front Runner

12-18-18, 09:10 AM

If you have an nVidia card, the Steam link in Front Runner's post is the one to follow:

https://steamcommunity.com/app/234670/discussions/0/810939350992635448/?l=turkish

You open the nVidia control panel and do what the guy has in his imgur picture. If you're like me, and have multiple installs of Silent Hunter for various mods, then it's best to use the "Add" and "Browse" buttons to be sure you are using the correct SH4.exe file. Only the two settings for "Vertical Sync (Adaptive - half refresh rate)" and "Maximum Pre-Rendered Frames (2)". The game does look a ~lot~ smoother on my quad-core with the 560. I have not done much other than play the game. I'll try to do my Single Mission from the Amazon River mouth towards Greenland at 1x TC all day today and night, and see what it does as far as the celestial cycles.

The laptop I have has Intel HD graphics, and does not have any control over the frame rate or buffering at all. I no longer have an ATI / AMD card installed in my computers (well, an AIW 9600XT in the XP box for vid cap), so I don't remember if there's any user-definable settings for 3D or not... profiles maybe, for individual games?? :salute:

Have you tried using nVidia Inspector? It gives additional options to control settings over and above the simple nVidia Control Panel, and allows you to set up a profile and than add all the executables that you wish to run under that profile's settings.

https://www.guru3d.com/files-details/nvidia-inspector-download.html

Here is the guide on how to use it. This link also contains the link to download the most current version from Guru3D

https://forums.guru3d.com/threads/nvidia-inspector-introduction-and-guide.403676/

propbeanie

12-18-18, 12:02 PM

Them fellers are into that kind of stuff big-time. Makes it easier for us, eh?

Front Runner

12-22-18, 09:35 AM

Them fellers are into that kind of stuff big-time. Makes it easier for us, eh?

Here is another TWEAK GUIDE for nVidia GPUs. It explains each setting and why/why not.

http://www.tweakguides.com/NVFORCE_1.html

KaleunMarco

12-22-18, 10:13 AM

Them fellers are into that kind of stuff big-time. Makes it easier for us, eh?

yes, they are. don't give a hoot about frame rates. BUT (notice the big but) i think it is perfectly fine if others want to pursue that aspect of the game.;)

Front Runner

01-05-19, 09:38 AM

Them fellers are into that kind of stuff big-time. Makes it easier for us, eh?

I just discovered a BIGGY. I'm not sure if this has ever been isolated or reported before.
It happened like this. I was starting up SH4 FOTRSUv80 RS2 this morning and I loaded up the save game that I saved last night. As sometimes happens, the RADIO is already playing when the scene opens in the control room. Other than that, nothing seems out of whack. Normally, I would either back out to the Main Menu, or back out to Windows and try again.

This time, I decided to try, as I sometimes do, loading an earlier save. I did, and when the scene opened in the control room the RADIO was NOT playing. OK, good, now I'll load up the save game where I left off last night.
One save game was made right at SUNSET. The other save game was a NOON save game. I am playing at a combination of 1x and 512x time compression.

NOW, here is the discovery. When I loaded up the NOON save game and it opened to the Control Room scene and the RADIO was off, I immediately loaded up the SUNSET save game and when it loaded, I started playing from the MAP (F5) and set TC at 512x. Shortly thereafter I get a RADAR CONTACT. So I order a Crash Dive and then go to external view. That is when I noticed that it was broad daylight! I mean like NOON broad daylight.
OK, when I had loaded up the SUNSET save game (the second time), and it started, I neglected to notice that, one, the lighting in the control room was daytime, and, the lighting on the MAP was also daytime.

What I had inadvertently discovered is the source of the very whacked out Base Time differentials. Propbeanie, I remember you mentioning this before that you also noticed some Base Time shifts when loading and/or reloading previous save games.

Had I continued to play, Base Time would've lost ALL meaning because, by loading the NOON save game, then upon opening the control room scene and immediately loading the SUNSET save, (and not noticing that Base Time vs Celestial Sphere was WAY out of whack,) then ALL of my subsequent save games would've been based on the whacked out Base Time vs Celestial Sphere.

I was able to repeat this several times and every single time, the error occurred. I have the save games that I used in case you are interested in trying, but I think you can test this yourselves by,

1. Starting SH4 and loading a save game that you know was made near SUNSET or at NIGHT. Notice that the CONTROL ROOM lights are red. (Night)
Note your Base Time. (Mine was 2036 which was correct according to my Lat. Long position referenced to my Midway Base.)

2. When the (Step 1) CONTROL ROOM scene opens, before you do anything else, load a save game that you know was made near NOON or during DAYLIGHT hours. Notice that the CONTROL ROOM lights are white. (Daylight) Note your Base Time. (Mine was 1215 which was NOON at my Midway Base.)
I don't care what my local noon is/was. That Base Time is where I make my save games when playing. For example, I make saves at SR, SS, NOON, MR, MS, and MIDNIGHT.

3. When the (Step 2) CONTROL ROOM scene opens, before you do anything else, load the save game from Step 1. When the CONTROL ROOM scene opens, the CONTROL ROOM lights are still white. (Daylight) Note your Base Time. (Mine was 2036 just as it was in Step 1.)

4. Go to external view and see the sun high in the sky even though your Base Time is indicating sunset or night time (for you.)

Now, I tried to correct the error by backing out to the MAIN menu and again loading my Sunset Save. Nope, that didn't get ride of the Celestial Sphere displacement caused by the above steps.
Then, I closed SH4 to Windows. I did not restart the computer nor did I log out of being the current user. I restarted SH4 and reloaded my SUNSET save and all was right with the world. My Base Time was correct and my Celestial Sphere was in sync with my save game.

I hope that you have all been able to follow this. If you have, then you can begin to see the implications and how it absolutely affects game play.
If I had continued on my Patrol without restarting SH4, my combined Celestial Sphere displacement caused by Steps 1 -4 above, and, the typical (and CORRECT) Base Time displacement from Midway, would've made it completely and utterly impossible to calculate Base Time and know whether it is DAY or NIGHT for the ENEMY. Nor would I be able to predict SR, SS, MR, or MS.

I was able to duplicate this error several times before I decided to post my observations.

Propbeanie, this explains your observations. I don't believe this is a FOTRSUv80 RS2 issue. I believe that it is a VANILLA Game issue. I'll try to verify this soon.

All because of the RADIO playing on LOAD game, which happens from time to time.

propbeanie

01-05-19, 10:43 AM

I just discovered a BIGGY. I'm not sure if this has ever been isolated or reported before.
It happened like this. I was starting up SH4 FOTRSUv80 RS2 this morning and I loaded up the save game that I saved last night. As sometimes happens, the RADIO is already playing when the scene opens in the control room. Other than that, nothing seems out of whack. Normally, I would either back out to the Main Menu, or back out to Windows and try again.

This time, I decided to try, as I sometimes do, loading an earlier save. I did, and when the scene opened in the control room the RADIO was NOT playing. OK, good, now I'll load up the save game where I left off last night.
One save game was made right at SUNSET. The other save game was a NOON save game. I am playing at a combination of 1x and 512x time compression.

NOW, here is the discovery. When I loaded up the NOON save game and it opened to the Control Room scene and the RADIO was off, I immediately loaded up the SUNSET save game and when it loaded, I started playing from the MAP (F5) and set TC at 512x. Shortly thereafter I get a RADAR CONTACT. So I order a Crash Dive and then go to external view. That is when I noticed that it was broad daylight! I mean like NOON broad daylight.
OK, when I had loaded up the SUNSET save game (the second time), and it started, I neglected to notice that, one, the lighting in the control room was daytime, and, the lighting on the MAP was also daytime.

What I had inadvertently discovered is the source of the very whacked out Base Time differentials. Propbeanie, I remember you mentioning this before that you also noticed some Base Time shifts when loading and/or reloading previous save games.

Had I continued to play, Base Time would've lost ALL meaning because, by loading the NOON save game, then upon opening the control room scene and immediately loading the SUNSET save, (and not noticing that Base Time vs Celestial Sphere was WAY out of whack,) then ALL of my subsequent save games would've been based on the whacked out Base Time vs Celestial Sphere.

I was able to repeat this several times and every single time, the error occurred. I have the save games that I used in case you are interested in trying, but I think you can test this yourselves by,

1. Starting SH4 and loading a save game that you know was made near SUNSET or at NIGHT. Notice that the CONTROL ROOM lights are red. (Night)
Note your Base Time. (Mine was 2036 which was correct according to my Lat. Long position referenced to my Midway Base.)

2. When the (Step 1) CONTROL ROOM scene opens, before you do anything else, load a save game that you know was made near NOON or during DAYLIGHT hours. Notice that the CONTROL ROOM lights are white. (Daylight) Note your Base Time. (Mine was 1215 which was NOON at my Midway Base.)
I don't care what my local noon is/was. That Base Time is where I make my save games when playing. For example, I make saves at SR, SS, NOON, MR, MS, and MIDNIGHT.

3. When the (Step 2) CONTROL ROOM scene opens, before you do anything else, load the save game from Step 1. When the CONTROL ROOM scene opens, the CONTROL ROOM lights are still white. (Daylight) Note your Base Time. (Mine was 2036 just as it was in Step 1.)

4. Go to external view and see the sun high in the sky even though your Base Time is indicating sunset or night time (for you.)

Now, I tried to correct the error by backing out to the MAIN menu and again loading my Sunset Save. Nope, that didn't get ride of the Celestial Sphere displacement caused by the above steps.
Then, I closed SH4 to Windows. I did not restart the computer nor did I log out of being the current user. I restarted SH4 and reloaded my SUNSET save and all was right with the world. My Base Time was correct and my Celestial Sphere was in sync with my save game.

I hope that you have all been able to follow this. If you have, then you can begin to see the implications and how it absolutely affects game play.
If I had continued on my Patrol without restarting SH4, my combined Celestial Sphere displacement caused by Steps 1 -4 above, and, the typical (and CORRECT) Base Time displacement from Midway, would've made it completely and utterly impossible to calculate Base Time and know whether it is DAY or NIGHT for the ENEMY. Nor would I be able to predict SR, SS, MR, or MS.

I was able to duplicate this error several times before I decided to post my observations.

Propbeanie, this explains your observations. I don't believe this is a FOTRSUv80 RS2 issue. I believe that it is a VANILLA Game issue. I'll try to verify this soon.

All because of the RADIO playing on LOAD game, which happens from time to time.
That can happen with or without anything else going on, from what I remember. I've encountered that before without opening a 2nd Save. The game just gets confused sometimes. Thankfully, not real often. You especially have to be careful with add-in radio & grammafone mods. There is a little "mod" app to check them... now, where did I have that?...

If you want to try this - copy your Save folder before you do though - but do like you did with Step 1, Step 2, & Step 3, but Save sometime after Step 3, and that Save is borked* for the duration. Your clock will be off until you end patrol. Talk about messing with your head. "Let's see, it's 2230, nothing on sonar. I should be safe to surface. 'Surface the boat' - 'Incoming aircraft!' - 'We're under attack, sir!' Boom! Boom! 'We're taking damage, Sir!' - 'Medic!'"... :salute:

* For you youngsters, look up Robert Bork...

KaleunMarco

01-05-19, 11:01 AM

If you want to try this - copy your Save folder before you do though - but do like you did with Step 1, Step 2, & Step 3, but Save sometime after Step 3, and that Save is borked* for the duration.

* For you youngsters, look up Robert Bork...
sorry, PB, wrong application of that word.
maybe you need to look it up. :D

what you might of said was: but Save sometime after Step 3, and that Save is FUBARed* for the duration.

Front Runner

01-05-19, 11:02 AM

You especially have to be careful with add-in radio & grammafone mods. There is a little "mod" app to check them... now, where did I have that?...

If you want to try this - copy your Save folder before you do though - but do like you did with Step 1, Step 2, & Step 3, but Save sometime after Step 3, and that Save is borked* for the duration. Your clock will be off until you end patrol. Talk about messing with your head. "Let's see, it's 2230, nothing on sonar. I should be safe to surface. 'Surface the boat' - 'Incoming aircraft!' - 'We're under attack, sir!' Boom! Boom! 'We're taking damage, Sir!' - 'Medic!'"... :salute:

* For you youngsters, look up Robert Bork...

For the "mod" app, do you mean Radio Manager?

Anyway, I have just performed several tests. I could not get the error to occur in WOTP or TMO/RSRD/OTC/IP. I tried to keep everything the same as possible, compatibility settings, running as admin, etc. In each iteration, I started a new career , 1944, Pearl Harbor command, Balao, etc. etc.
I started a new career in FOTRSUv80 RC2 and made three saves, daylight, SS and midnight. The error happened.
I'm still trying to isolate the issue. So stand by for more information.

The thing is, I could get it to replicate in FOTRSUv80 RC2, but using the same procedures, I could not get it to replicate in WOTP, or TMO/RSRD/OTC/IP, at least, not yet.

This is a weird one. I'll try what you suggest and report back again.

KaleunMarco

01-05-19, 11:04 AM

I just discovered a BIGGY. I'm not sure if this has ever been isolated or reported before.
It happened like this. I was starting up SH4 FOTRSUv80 RS2 this morning and I loaded up the save game that I saved last night. As sometimes happens, the RADIO is already playing when the scene opens in the control room. Other than that, nothing seems out of whack. Normally, I would either back out to the Main Menu, or back out to Windows and try again.

This time, I decided to try, as I sometimes do, loading an earlier save. I did, and when the scene opened in the control room the RADIO was NOT playing. OK, good, now I'll load up the save game where I left off last night.
One save game was made right at SUNSET. The other save game was a NOON save game. I am playing at a combination of 1x and 512x time compression.

NOW, here is the discovery. When I loaded up the NOON save game and it opened to the Control Room scene and the RADIO was off, I immediately loaded up the SUNSET save game and when it loaded, I started playing from the MAP (F5) and set TC at 512x. Shortly thereafter I get a RADAR CONTACT. So I order a Crash Dive and then go to external view. That is when I noticed that it was broad daylight! I mean like NOON broad daylight.
OK, when I had loaded up the SUNSET save game (the second time), and it started, I neglected to notice that, one, the lighting in the control room was daytime, and, the lighting on the MAP was also daytime.

What I had inadvertently discovered is the source of the very whacked out Base Time differentials. Propbeanie, I remember you mentioning this before that you also noticed some Base Time shifts when loading and/or reloading previous save games.

Had I continued to play, Base Time would've lost ALL meaning because, by loading the NOON save game, then upon opening the control room scene and immediately loading the SUNSET save, (and not noticing that Base Time vs Celestial Sphere was WAY out of whack,) then ALL of my subsequent save games would've been based on the whacked out Base Time vs Celestial Sphere.

I was able to repeat this several times and every single time, the error occurred. I have the save games that I used in case you are interested in trying, but I think you can test this yourselves by,

1. Starting SH4 and loading a save game that you know was made near SUNSET or at NIGHT. Notice that the CONTROL ROOM lights are red. (Night)
Note your Base Time. (Mine was 2036 which was correct according to my Lat. Long position referenced to my Midway Base.)

2. When the (Step 1) CONTROL ROOM scene opens, before you do anything else, load a save game that you know was made near NOON or during DAYLIGHT hours. Notice that the CONTROL ROOM lights are white. (Daylight) Note your Base Time. (Mine was 1215 which was NOON at my Midway Base.)
I don't care what my local noon is/was. That Base Time is where I make my save games when playing. For example, I make saves at SR, SS, NOON, MR, MS, and MIDNIGHT.

3. When the (Step 2) CONTROL ROOM scene opens, before you do anything else, load the save game from Step 1. When the CONTROL ROOM scene opens, the CONTROL ROOM lights are still white. (Daylight) Note your Base Time. (Mine was 2036 just as it was in Step 1.)

4. Go to external view and see the sun high in the sky even though your Base Time is indicating sunset or night time (for you.)

Now, I tried to correct the error by backing out to the MAIN menu and again loading my Sunset Save. Nope, that didn't get ride of the Celestial Sphere displacement caused by the above steps.
Then, I closed SH4 to Windows. I did not restart the computer nor did I log out of being the current user. I restarted SH4 and reloaded my SUNSET save and all was right with the world. My Base Time was correct and my Celestial Sphere was in sync with my save game.

I hope that you have all been able to follow this. If you have, then you can begin to see the implications and how it absolutely affects game play.
If I had continued on my Patrol without restarting SH4, my combined Celestial Sphere displacement caused by Steps 1 -4 above, and, the typical (and CORRECT) Base Time displacement from Midway, would've made it completely and utterly impossible to calculate Base Time and know whether it is DAY or NIGHT for the ENEMY. Nor would I be able to predict SR, SS, MR, or MS.

I was able to duplicate this error several times before I decided to post my observations.

Propbeanie, this explains your observations. I don't believe this is a FOTRSUv80 RS2 issue. I believe that it is a VANILLA Game issue. I'll try to verify this soon.

All because of the RADIO playing on LOAD game, which happens from time to time.
Runner...
so you are saying that, under certain circumstances, the main application will carryover celestial time from one game instance to another? so the ubisoft programmers forgot to reset game-time from one save to the next save? morons.

that is an amazing discovery.:salute::salute::salute:

Front Runner

01-05-19, 11:56 AM

Runner...
so you are saying that, under certain circumstances, the main application will carryover celestial time from one game instance to another? so the ubisoft programmers forgot to reset game-time from one save to the next save? morons.

that is an amazing discovery.:salute::salute::salute:

I'm not ready to blame Ubisoft programmers. I could not reproduce this in Vanilla WOTP. This appears to happen under certain circumstances. I am deleting everything except PRISTINE installation. I am deleting all of my SH4 folders in Documents. I'm going to install and test each iteration of the game carefully.

Stand by.....

propbeanie

01-05-19, 12:17 PM

Replies inside "quote" are in blue - Orange for emphasis of FrontRunner's text:
For the "mod" app, do you mean Radio Manager? - Yes!

Anyway, I have just performed several tests. I could not get the error to occur in WOTP or TMO/RSRD/OTC/IP. - velly intellesting... I tried to keep everything the same as possible, compatibility settings, running as admin, etc. In each iteration, I started a new career , 1944, Pearl Harbor command, Balao, etc. etc.
I started a new career in FOTRSUv80 RC2 and made three saves, daylight, SS and midnight. The error happened.
I'm still trying to isolate the issue. So stand by for more information.

The thing is, I could get it to replicate in FOTRSUv80 RC2, but using the same procedures, I could not get it to replicate in WOTP, or TMO/RSRD/OTC/IP, at least, not yet.

This is a weird one. I'll try what you suggest and report back again.
I have seen this outside of FotRSU, but not very often - but it may have been FOTRS years ago... (A clue! A clue!) Thanks for all your testing FrontRunner. :salute:

Front Runner

01-05-19, 02:53 PM

Replies inside "quote" are in blue - Orange for emphasis of FrontRunner's text:

I have seen this outside of FotRSU, but not very often - but it may have been FOTRS years ago... (A clue! A clue!) Thanks for all your testing FrontRunner. :salute:

OK. Update......
After deleting and/or archiving all of my Document/Save Folders for all iterations of SH4, deleting all copies of the game, then reinstalling a pristine copy of SH4 v1.5 and applying only the FOTRSUv80 RC2, I was able to replicate the error described above by starting a new career, 1944 Pearl Harbor Command, Balao Class boat, outside the harbor. I then played at 512x time compression until I had made 4 saves. Outside the harbor (daylight), at Sunset, at Midnight and at Sunrise. When I close FOTRSUv80 and then start the game again, any one of the individual save games load correctly only if I load them from the Main Menu and only that one time.
If I then try to load any other save game from either the "Esc" key menu while in game, or, selecting Main Menu from the "Esc" key menu and loading from there, the loaded game Celestial Sphere is now seriously out of sync with Base Time. (i.e. Broad daylight at midnight.)

If I Exit to Windows and then start the game again, each individual save game loads correctly but only that once. So, I only get one shot to load the game I am playing. If I decide to load any other save game, while in game, or from the Main Menu, the second one loads with the Celestial Sphere FUBAR!

The only way to get the correct save game to load is to close the game, restart, and load that one game only!

I was unable to reproduce this error in a fresh install of Wolves of the Pacific (Vanilla) using the same parameters.

Next stop......I'll try FOTRSUv71 as I don't remember this happening while I was saving and loading my games while 1x testing.

This does appear to be an FOTRSU issue though. I am looking for someone else to confirm.

For now, I'm done testing for the day.....

:Kaleun_Cheers:

propbeanie

01-05-19, 03:35 PM

If I can out of the knee-deep weeds, briars and brambles we're stuck in right now, I'll give similar a whirl FrontRunner... I'm trying to imagine what would do that "time shift"... we've had issues with the AI settings, to the point that it almost seems "backwards", like day is night, and night is day, as far as enemy AI is concerned... is it related?... is it Area 51?... maybe only The Shadow knows... :salute:

Front Runner

01-06-19, 08:04 AM

OK.

Next stop......I'll try FOTRSUv71 as I don't remember this happening while I was saving and loading my games while 1x testing.

This does appear to be an FOTRSU issue though. I am looking for someone else to confirm.

Update.....I just tested it in FORTSUv71 and I got the same results as in FOTRSUv80 RC2. I guess that shows how infrequently I rely on a previously saved game while in game.

As long as you make serial saves along the way, you can always quit the game, start again and load the save game you wish.

However, as Propbeanie said, if you are playing, and go back, (or forward), to any other save game, and make subsequent save games, ALL of those subsequent save games will be erroneous. You can still go back to a save game previous to that time and THOSE save games will still be OK.

So far, this issue seems to be isolated to FOTRSU supermod.

Propbeanie, which FOTRSU team member might I PM with to assist in finding and fixing this particular issue?

Next stop......I'll try TMO/RSRD.

Front Runner

01-06-19, 09:34 AM

Next stop......I'll try TMO/RSRD.

OK.....I've tested this issue in TMO/RSRD and TMO/RSRD/OTC/ISP and I have been unable to reproduce the issue using these supermods.

I have discovered another clue!

When loading a previous (or later) save game, using supermod FOTRSUv.*, from within the game, using either the "Esc" key menu or choosing the Main Menu from the "Esc" key menu, the loaded game forgets all of the navigation routing, and probably all of the Celestial Sphere data, that was saved in the original save game. The navigation routing comes up blank and I have to set new waypoints. This does not occur when using WOTP Vanilla or in the TMO/RSRD/OTC/ISP. The information is definitely within the save game, but is not included when loading that save game from within FOTRSU.v*
I have also tried re-loading the same save game over itself. That does not fix the issue. When loading a previous (or later) save game, as close as I can tell, the Celestial Sphere defaults to the time of day when the Career started. I possibly can take a "Sun-Sight" with the Observation Scope to verify this, at least for the azimuth, maybe not the elevation. Hmmmm....
[UPDATE] OK, I've looked at this and as soon as the previous or later save game loads, the AZIMUTH and ELEVATION of the Sun in the misplaced Celestial Sphere are approximately the same in each instance. I have some screenshots using the Observation Periscope at max elevation on the azimuth of the sun and the halo looks about the same in each screenshot.

I can exit the game, start again, load the save game and the navigation routing is intact. I believe this is a big clue that, hopefully, may lead to a solution to this issue. The issue is an incomplete loading of a saved game file from within the game. This issue appears to affect only FOTRSU.v*
I'm thinking that there is a missing ";" ":" "," "." "/" or someother modifier somewhere, most likely contained within the original FOTRSU.

I don't know where to start looking as I assumed that the "Save game/Load game" functions were hard coded in the sh4.exe. Now, I think not. Some modification has prevented a full and accurate loading of a save game from within the FOTRSU.v* supermod.

Front Runner

01-06-19, 12:38 PM

I don't know where to start looking as I assumed that the "Save game/Load game" functions were hard coded in the sh4.exe. Now, I think not. Some modification has prevented a full and accurate loading of a save game from within the FOTRSU.v* supermod.

My testing shows that this issue does not effect War Patrols, Single Missions or Training.

So, I designed a test. Starting Career at Pearl Harbor, January 1944, Balao Class boat (although I don't believe this matters, then again, everything matters....) [EDIT] It turns out that January 1944 matters. Everything matters!

Start Career. Set course 270. Speed 1/3. Draw your course on the map a good long distance and then make waypoints every 10 degrees of Longitude. This will make sure that there are enough waypoints so that when you load the save game you will see that the waypoints have been saved as well. Note the azimuth of the sun. On course 270 @ 1304 on Jan. 3, 1944, I am reading an azimuth of 299 degrees relative bearing.
Save the game. I saved it as "1304 C270 S299 Daylight".

Then, Ahead Standard and Time Compression 512x until 1501. You are now out of range of Pearl Harbor traffic and you can Time Compress in place at Latitude 21D 14' N Longitude 158D 24' W. ALL STOP @ 0 knots. From here on we will stay in position. Note the azimuth of the sun. I am reading 321 at 1501. Save the game. I saved it as "1501 C270 S321 Daylight".

Then, Time Compression until Sunset (1704). Note the azimuth of the sun, 337. Save the game. "1704 C270 S337SS Sunset"

Then, Time Compression until Midnight. Save the game. "0001 C270 MIDNIGHT".

Then, Time Compression until Sunrise (0615). Note the azimuth of the sun, 204. Save the game. "0615 C270 S204SR Sunrise".

Now, close the game, start again and load any of the above save games and verify that the azimuth of the sun is as you originally recorded it and that all of your waypoints are there.

I loaded the "1501....Daylight" save and verified it as good.

Then, I loaded "1304.....Daylight". Make sure you are on course 270. I used Ahead 1/3 and made sure my rudder was 0. The sun azimuth has changed ever so slightly to 297. (2 degrees less than the 299 originally recorded.) Also, all of my waypoints have disappeared.

Then, I re-loaded the "1501.....Daylight". Sun azimuth 296. No waypoints.

Then, I loaded "1706.....Sunset". C270 Ahead 1/3. The sun azimuth is 296. There are no waypoints.

Then, I loaded "0001.....Midnight". C270 Ahead 1/3. The sun azimuth is 296.
There are no waypoints.

Then, I loaded "0615......Sunrise". C270 Ahead 1/3. The sun azimuth is 296.
There are no waypoints.

Then, I went back to "1304.....Daylight". C270 Ahead 1/3. Sun azimuth is 297. Still 2 degrees less than the original 299. There are no waypoints.

I did several more combinations of tests with the same results including loading "1304.....Daylight" Sun azimuth 299. Verified waypoints OK.
Then reloading the exact same "1304.....Daylight". Sun azimuth 297 and NO waypoints.

My conclusion is that whenever you load a second save game within a single session of Career play, that second save game's Celestial Sphere will revert to nearly the same position it was in at the start of your career upon leaving base, even though all of your save games, individually, load correctly the first time. My reloads were all sun azimuth of 296 - 297 regardless of the time of day that I had made the original save games. Sunrise, Sunset, Midday, Noon, Midnight etc. The missing waypoints upon reloading a save game is a BIG indicator that this is happening.

I really hope that you are all following this. It is important for FOTRSU.

Once again, as long as you are playing and making serial saves without loading a previous (or later) save game while in game, then all of your save games are probably OK. The best practice I can recommend until this problem is solved, is that whenever you wish to load a save game while playing FOTRSU.v* is to close SH4, reopen it, then load the save game.

I'm now going to check Single Mission play to see if this happens there as well.

Front Runner

01-06-19, 04:18 PM

As far as my testing goes, this issue only affects Career Mode in FOTRSU.v* (Maybe FOTRS original but I don't have a copy that I can test.)
I have been UNABLE to replicate the issue in WOTP Vanilla, TMO/RSRD, TMO/RSRD/OTC/ISP, and in FOTRSU.v* Single Missions including Sub School and War Patrol. It only affects Career Mode in FOTRSU.

It comes down to this, when in Career Mode in FOTRSU.v*, the save games "write" the correct data, and, "read" the correct data only the first time it is loaded, after that, loading or re-loading any subsequent "load game", it seems that there occurs an "incomplete reading" of the data. I've tried using an old archived copy of FileManager.dll. The game worked but the same issue persisted. I made sure that MultiSH4 was running as administrator. That didn't solve the issue.
Anyone have any suggestions?

Meanwhile, I can still play Career Mode FOTRSU.v80 making sure that I don't load one save game over another without first quitting and re-starting the game.

propbeanie

01-06-19, 07:08 PM

Front Runner

01-06-19, 10:25 PM

I'm following closely, and trying to think of something that would load in the Campaign, that does not load otherwise, that could influence what you're seeing... there are certain files called in Campaign.cfg that load in the campaign only, others that load in some or all of the game, but again, nothing that would directly affect 'time'... :hmmm: - This might be some deep divin' 'vestigatin'...

A couple of thoughts: 1. FotRSU is based on FOTRS, and v1.2 & 1.3 are available on Subsim.com 2. FOTRS is based on TMO v1.7... I've got v1.6x somthing or other for SH4 v1.4, so I'll try your Test Mission on those... :salute:
It’s not really affecting time at all. It’s affecting the background that’s loaded. The base time of the backup and the load are the same. The water is probably the same. The celestial sphere that loads appears to be the default from starting the career from “in base” rather than the one in the save game. The waypoints are also missing. It’s like it loads parts of the save game along with whatever happens when you start the career from “in base.”. All the data in the save game is correct as can be seen by quitting and restarting. Some of it is either not being read properly or is being overwritten when loading a save game over an already loaded save game. It’s almost like a double exposure. What is key here is that upon opening the second save game, the program thinks you are just starting your career from in base and provides no waypoints and the default celestial sphere from 1300 hours the day you start your first patrol. It seems like it's combining two data sets, one from the save came and one from the career start.

propbeanie

01-07-19, 07:51 AM

That was why I used 'time', in the apostrophes, was that it is the appearance of a time passage, or time and space not synchronizing properly. It could be an error of commission, or more likely, and error of omission, maybe an invalid portion of data that overwrites something that it shouldn't... dunno. I won't have time to set things up to try out my old TMO until this evening, mostly because I haven't found the mod files yet... surprise surprise... I do have FOTRS v1.2 on a computer though, and hope to get to testing it this afternoon. I'll let you know what I find with it... :salute:

Front Runner

01-07-19, 08:53 AM

merc4ulfate

01-07-19, 01:07 PM

Base Time is as drifty as a Seaman Recruit on their first day at Great Lakes Naval Training Center!

I do not even pay attention to time as a scale in this game. Most of it is a hard coded issue that will never be resolved. Is it visibly day or night is all I care about. The only reason I find time to be any value at all is if one is modding and you need to set it inside the mod for entrance and exits.

I was taught early on in this game to never save over a save . It has a name and it is called ... pain.

Do not do that.

Front Runner

01-07-19, 02:32 PM

Here is the issue.....
(1) In FOTRSU.v* Career Mode, BALAO class boat, (TAMBOR sometimes does not exhibit this issue), when you save game at midnight, with all of your navigational waypoints set, and it's dark.....

(2)......and then quit the game and load that save game again on game restart, and it is midnight, with all of your navigational waypoints set, and it's dark, in EXACTLY the same game state as it was in when you first saved it.....

(3).....and then you reload that very same save game that you just loaded, without quitting the game first, and it's midnight, BUT now, all of your waypoints are missing, and, instead it's, broad daylight, then this issue has serious AI Friendly and Enemy timing issues if you continue to play the erroneous, FUBAR load, not to mention that your Base time is now even more out of whack than "normal."

Is it daylight for you and dark of night for them? Or vice-versa?

(4)......and then you quit the game and reload that very same save game and everything is EXACTLY as it was when you saved it the first time. Midnight, waypoints, dark.

In other words, you only get one accurate save game load per game session. Any subsequent loads are FUBAR. IFAIK, it does not appear to be a WRITE issue (or an over-write issue.) It is a READ issue which occurs on any subsequent save game load made after the FIRST save game load.

You must quit the game and restart and load that save game to get the game into the same state as it was when you first saved it. The save game file is fine. There is nothing wrong with it. It reloads to the same game state, but ONLY the first time on game startup.

This is NOT the old "hey, why is it light out when my (base time) (onboard) clock says it's night time."

This issue affects ONLY FOTRSU.v* Career Mode (AFAIK). It does not affect WOTP Vanilla, nor does it affect TMO, TMO/RSRD, RFB, Ralles Mod Pack, nor many other variations of Vanilla, and Mod files I have tested. I don't believe it to be hard coded. If it were, all of the aforementioned games and mods would have the same issue. They don't!

propbeanie

01-07-19, 02:49 PM

mikesn9

01-08-19, 06:51 AM

I do not even pay attention to time as a scale in this game. Most of it is a hard coded issue that will never be resolved. Is it visibly day or night is all I care about. The only reason I find time to be any value at all is if one is modding and you need to set it inside the mod for entrance and exits.

I was taught early on in this game to never save over a save . It has a name and it is called ... pain.

Do not do that.

Thanks Merc, I've been contemplating saying the same thing.. what matters in the game: Is it dark or light out? and: What is the weather?

Front Runner

01-08-19, 08:22 AM

Thanks Merc, I've been contemplating saying the same thing.. what matters in the game: Is it dark or light out? and: What is the weather?

Please try to understand this particular issue. AFAIK, it affects only FOTRSU.v* and only in Career Mode BALAO, sometimes TAMBOR (boat testing continues.) See my simplified description of this issue here......

http://www.subsim.com/radioroom/showpost.php?p=2585408&postcount=35

Front Runner

01-08-19, 08:35 AM

I'm wondering about scene.dat, which has sun & moon phases (and the terns), but I haven't gone through the whole thing yet... surely it's not "backwards" with night is day and day is night?... :roll: - a quick comparison on one computer is that there is not difference between it and several other modded games, but I have not been on my computer with a "pristine" stock... If it does match "stock", why have it in the mod?... :salute:

Propbeanie - I looked at scene.dat from the PRISTINE folder and from the FOTRSU.v80 RC2 folder. There are significant differences. I don't think the scene.dat is the issue though. If it were, I'd be unable to load ANY accurate save games.

For those of you interested and following this issue, The first save game load is OK. The second, third, fourth, etc. save game load, without first quitting the game and restarting is FUBAR. The data contained in the save game(s) are correct. The reading of the data is correct only on the first loading of that save game. The reading of the data is FUBAR if you re-load that "EXACTLY the same" save game. There is something very weird happening and we are trying to track it down.

You might not care whether or not the AI elements of this game are timed correctly to the day/night cycle, but I sure do! Especially with all of the detailed work that the FOTRSU team is doing! I'm not going to speak for Propbeanie, but I believe he cares as well.

If you are playing any versions or combinations of mods other than FOTRSU, then this issue is not affecting you (AFAIK).

merc4ulfate

01-08-19, 10:15 AM

Propbeanie - I looked at scene.dat from the PRISTINE folder and from the FOTRSU.v80 RC2 folder. There are significant differences. I don't think the scene.dat is the issue though. If it were, I'd be unable to load ANY accurate save games.

For those of you interested and following this issue, The first save game load is OK. The second, third, fourth, etc. save game load, without first quitting the game and restarting is FUBAR. The data contained in the save game(s) are correct. The reading of the data is correct only on the first loading of that save game. The reading of the data is FUBAR if you re-load that "EXACTLY the same" save game. There is something very weird happening and we are trying to track it down.

You might not care whether or not the AI elements of this game are timed correctly to the day/night cycle, but I sure do! Especially with all of the detailed work that the FOTRSU team is doing! I'm not going to speak for Propbeanie, but I believe he cares as well.

If you are playing any versions or combinations of mods other than FOTRSU, then this issue is not affecting you (AFAIK).

Perhaps I will try to save a game and then replicate it. I never used saved games. My only save points are entering and exiting port so they are my only load points. If I die on patrol then I start over. I use the old dead is dead scheme when I play.

propbeanie

01-08-19, 11:18 AM

Propbeanie - I looked at scene.dat from the PRISTINE folder and from the FOTRSU.v80 RC2 folder. There are significant differences. I don't think the scene.dat is the issue though. If it were, I'd be unable to load ANY accurate save games...
I found an interesting post:

leovampire's post in "A Question about the moon" (http://www.subsim.com/radioroom/showthread.php?p=657052#post657052). Note the date. As for not thinking it's Scene.dat, I don't know what else it could be. FotRSU does not replace the Stock sim & dsd. There are some changes in the Shaders folder "TerrainMapPS.fx", but the files in the "Sky" folder below that are Stock files, like maybe someone was going to edit them at one point in time, but never did. I don't comprehend those script files, but they look like color / texture stuff... ?? I do remember though, getting a similar "time warp" effect in other mods, but I do not recall the circumstances. I have not had a chance to do the old FOTRS yet, but I did used to play that quite a bit... :salute:

propbeanie

01-08-19, 12:48 PM

Now, here's some more interesting notes... I was able to replicate losing time-track of my "celestial bodies" the other day, in v0.80. However, that was while testing a Balao, but for other things. I have come back into the game before, after days on patrol, several sinkings, etc., and have had this. I did a wipe of the Save folder though, to clear the data, and I have not been able to replicate it since, using your methodology FrontRunner. I've now tried several submarines besides the Balao. Here is a shot from a Tambor, done on June 3 / 4 1943:

https://i.imgur.com/UhuzIVm.jpg

I have a dual-monitor set-up, so the right screen is the screen grab from the 3rd, the left screen is the restored Save of same, after many re-loads of it and other Saves. Part of the problem of course, is the "rock" of the boat. I have not lost my waypoints, though I do remember getting that before, but I do not recall the mod(s) used then. I do not know if I would have lost waypoints the other day when my celestial bodies went "off-the-clock", since I don't often use waypoints, and I don't recall having any set then anyway. I have lost track of how many times I've tried FotRSUv0.80. I have done FOTRSv1.3 at least a half-dozen times, and have not found any issues. I'm still wanting to do Stock and FOTRSv2.0 in SH4 v1.4, and see what happens there. I do not recall which version of FOTRS we took the scene.dat and other files from... I'll ask around about that. :salute:

Front Runner

01-08-19, 01:50 PM

Now, here's some more interesting notes... I was able to replicate losing time-track of my "celestial bodies" the other day, in v0.80. However, that was while testing a Balao, but for other things. I have come back into the game before, after days on patrol, several sinkings, etc., and have had this. I did a wipe of the Save folder though, to clear the data, and I have not been able to replicate it since, using your methodology FrontRunner. I've now tried several submarines besides the Balao.

I have not lost my waypoints, though I do remember getting that before, but I do not recall the mod(s) used then. I do not know if I would have lost waypoints the other day when my celestial bodies went "off-the-clock", since I don't often use waypoints, and I don't recall having any set then anyway. I have lost track of how many times I've tried FotRSUv0.80. I have done FOTRSv1.3 at least a half-dozen times, and have not found any issues. I'm still wanting to do Stock and FOTRSv2.0 in SH4 v1.4, and see what happens there. I do not recall which version of FOTRS we took the scene.dat and other files from... I'll ask around about that. :salute:

Propbeanie! - You may be on to something sir! I've just tested a TAMBOR in FORTRSU.v* and I'll be danged, I'm not getting the "BALAO" problem. How could this problem affect only the BALAO? I'm intrigued. I'll have to do some more testing. Of course, I'll be thorough and test ALL boats. Sometimes I think I'm smart by keeping my testing parameters the same. In other words, not trying to change too many variables at once. Sometimes that ends up biting me in the ass! It did not occur to me that this issue could be related to a particular type of submarine, the BALAO.

Front Runner

01-08-19, 01:52 PM

Perhaps I will try to save a game and then replicate it. I never used saved games. My only save points are entering and exiting port so they are my only load points. If I die on patrol then I start over. I use the old dead is dead scheme when I play.

Recent testing reveals that this issue is affecting the BALAO, but not the TAMBOR class. I'm about to test ALL boats to see if there are any other boats which exhibit this issue.
Thanks to Propbeanie for giving me the heads up on his observations!

The main reason that I save games is because I like to play, mostly, at 1x, and not use Time Compression. I like to leave the game running and listen to Fred's Radio stations while I attend to household chores, routines and duties. After running the game for 6 straight hours, I sure want to save the game when I go to bed just in case there is a power outage or my cat jumps on the keyboard while I'm sleeping.

My penchant for 1x play led to starting this thread in the first place when I discovered the high-frame rate Celestial Cycle issue. I'm using 1/2 refresh rate (30fps) to keep my Sunset, Sunrise, Moonset, and Moonrise cycles reasonably close to Almanac times. That's the way I roll. If you play using mostly Time Compression, then the frame rate issue is of no major concern.

Front Runner

01-08-19, 03:37 PM

Well, that went well, (NOT). It seems to have made things all the more complicated.
So, I created a new save folder and tested the TENCH, GATO, GAR and TAMBOR. The issue persisted in each case.
So, I went back to my original save folder and retested the results I noted in the above (Happy) post. The TAMBOR is OK in that save folder but NOT in the newly created save folder. The BALAO is not OK in the save folder that the TAMBOR is OK in, (the original save folder.)
Why does the TAMBOR save/load work in the one save folder but not the other?

Yeah, I'm dizzy.......there are too many moving parts.

I'm thinking.....

propbeanie

01-08-19, 04:55 PM

It is indeed, very strange... I ~know~ I've gotten this in other mods and / or Stock, yet I cannot replicate it. I'm attempting to transfer an SH4v1.4 folder to my big computer, since a person cannot install v1.4 after it has been updated to v1.5, though I do have v1.3, v1.4 & v1.5 all residing happily on my old duo-core dual core E-whatever computer with 2gig and a tired, old, ATI AIW 9600XT AGP video card. The frame rate is horrendous anymore, so I'm attempting to get v1.4 onto the newer quad-core, so it'd be comparable to the Stock and FotRSU installs. We'll see how far I get with this idea...

Does anyone watching this happen to know if a v1.4 environmental mod can run OK on v1.5, and vice versa? Or were there other files involved with v1.5? I'm speaking specifically of W_clear & kriller's environmental mods, which is what both TMO & FOTRS (and by virtue of inheritance, FotRSU) use... ?? I haven't a clue when it comes to environmental stuff (or 3D... :roll: ) :salute:

Edit: A thought just occurred to me FrontRunner: what kind of hard drives do you have? Where are you writing your Saves, and with what interface? Any write-caching involved? ie: 7200rpm Sata drives, or an SSD drive?... ?? My one computer is mixed IDE and SATA (old beast). The other is all SATA. I have no SSD drives. :salute:

Front Runner

01-08-19, 07:58 PM

Edit: A thought just occurred to me FrontRunner: what kind of hard drives do you have? Where are you writing your Saves, and with what interface? Any write-caching involved? ie: 7200rpm Sata drives, or an SSD drive?... ?? My one computer is mixed IDE and SATA (old beast). The other is all SATA. I have no SSD drives. :salute:

I’m thinking the same thing about the hard drives. My C-Drive is RAID 0 SSD, the drive the SH4 and mods are D-Drive 3TB. The Documents Folder/SH4 is on the C-Drive. I believe I have enabled write caching on all of my drives. Should I disable write caching?

I had SH4 installed on the C-Drive when I first noticed this issue. Since it occurs on reload of already loaded games, something may be getting stuck in the cache or perhaps WINDOWS 10 doesn’t like the way I play the piano.

I’m thinking of moving my Documents Folder to the D-Drive.

merc4ulfate

01-08-19, 08:30 PM

Recent testing reveals that this issue is affecting the BALAO, but not the TAMBOR class. I'm about to test ALL boats to see if there are any other boats which exhibit this issue.
Thanks to Propbeanie for giving me the heads up on his observations!

The main reason that I save games is because I like to play, mostly, at 1x, and not use Time Compression. I like to leave the game running and listen to Fred's Radio stations while I attend to household chores, routines and duties. After running the game for 6 straight hours, I sure want to save the game when I go to bed just in case there is a power outage or my cat jumps on the keyboard while I'm sleeping.

My penchant for 1x play led to starting this thread in the first place when I discovered the high-frame rate Celestial Cycle issue. I'm using 1/2 refresh rate (30fps) to keep my Sunset, Sunrise, Moonset, and Moonrise cycles reasonably close to Almanac times. That's the way I roll. If you play using mostly Time Compression, then the frame rate issue is of no major concern.

Very Nice!!

propbeanie

01-08-19, 10:01 PM

If it was 1994, I could tell you all about cache configuration with an IDE interface and why you would never use write caching, especially if you also had an ATAPI drive... :har: Windows 3.1 is no longer with us, and neither is DOS 4.5 or whatever it was... my 3 1/2 inch game boot disk is no longer working either, and I no longer have to worry about properly configuring my Soundblaster 16 whatever it was... :har: Oh!, and let's not forget about PIO Modes etc... :roll:

But I never have trusted write caching. The computer OS decides when it's a good time to write to the drive, and an old game does not know that. However, if something goes wrong with a write like that, then ~all~ the loads would be corrupt. This is a re-load thang. What it reminds me of is similar to when a person runs the Museum, you cannot trust the game to run properly, and vice versa, if you run the game first, you will not be able to run the Museum. Something in SH4 is not "cleared" when swapping "modes", or whatever it is.

But then again, this is not that. We're not swapping "modes" (or whatever it is). All I can figure is that maybe FotRSU just has a lot of data to Save for the game, and when you do that 2nd load, it acts similar to changing modes??... I dunno. If that was the case though, it would happen every time, and it doesn't. I just got finished with FOTRS v2.0 (GE) for SH4 v1.4, and had no issues with the Balao on Jan 2, 1944 several times, so I went no further with it. Tomorrow, I'll do similar with Stock and GFO. :salute:

Front Runner

01-09-19, 11:02 AM

Moving my Documents Folder from C-Drive to D-Drive didn’t change anything. Starting Silent Hunter from C-Drive or D-Drive didn’t change anything even with Document Folder on same drive as SH4.exe .
Tambor save/quit/start/load/reload works with one set of save game files but not with another when creating them within each folder. I'm using MultiSH4 to create the different SH4 save folders.
Hmmmm......

OK, so I moved the TAMBOR save game files from the Documents/"V80" folder to the Documents/"000" folder. They work in BOTH folder sets! However, the TAMBOR Career test savegames I newly made in the Documents/"000" folder, do NOT work, that is save/quit/start/load/reload. I could even go back and forth using different save games without quitting the game and I was able to continue to get the TAMBOR saves that work in both folders to re-load correctly, a number of times, even after I was unsuccessful in getting the TAMBOR saves that don't work loaded in between. I am either on the verge of a break through or a break-down. Observation, if the "savegame/load/reload" works within one Documents/(Silent Hunter Save Folder) i.e."V80", it also works in another Documents/(Silent Hunter Save Folder) i.e."000".

In other words, even though I was unsuccessful in getting one set of saves to work, the other set worked every time. I did not have to quit to get them to load properly. I could even reproduce the unsuccessful attempts and I was still able to load the set that works without quitting.

Now, I will have to test loading one of the TAMBOR saves that work, making a new "save" and seeing if THAT one, newly minted within the 000 folder works or not......stand by.....
OK, the serial save that I made from the set of TAMBOR saves that work, continue to work. Going from a good TAMBOR save to a bad TAMBOR save results in the bad TAMBOR save coming up correct, the one time, and after that reverting to what to me appears to me to be a "1300 Daylight scene". I can then go back to the good TAMBOR saves and they ALL work correctly no matter which order I re-load them. If I then return to the bad TAMBOR save that came up good, the one time, it now comes up bad. This test was done without quitting the game and re-starting.

Front Runner

01-09-19, 12:54 PM

Using two sets of save game files. Set A is the good TAMBOR saves. Set B is the bad TAMBOR saves.
By good, I mean that the files successfully loaded using "quit/start/load/reload" and by bad, I mean that the files did not load properly using "quit/start/load/reload."

Here are my observations. These were done serially, without quit/restart.
1.Load Set A-Midnite-OK
2.Load Set A-Noon-OK
3.Load Set A-Midnite-OK
4.Load Set B-Sunset-OK
5.Load Set B-Midnite-Not OK
6.Load Set A-Midnite-OK
7.Load Set A-Noon-OK
8.Load Set A-Midnite-OK
9.Load Set B-Sunset-Not OK

Whatever happens between #4 and #5 does not affect Set A but does affect Set B as 9.Load Set B-Sunset fails to reload successfully as it did in #4.

The A set stays OK throughout the test. The B set works the one time only and then reverts to what appears to me to be "1300 Daylight scene". Note that this is the also time and daylight scene when the Career starts.

What are the differences between the Set A and the Set B saves?
Is there a way to compare the two sets to see what the difference is?

Front Runner

01-09-19, 01:50 PM

Propbeanie - Where in the Career Save games does it save the Date and Time that you are at when you make the save? I can't seem to find it in the save files.

propbeanie

01-09-19, 04:16 PM

I've been looking for that... there is a "SaveData.map" file which holds the waypoints, so next time you lose the waypoints, see if that file is still in your Save folder, and a valid text document - "X:\Users\ UserName\ Documents\ SH4SaveFolder\ data\ cfg\ SaveGames\ xxxxxxxx\ SaveData.map", where "X" = drive letter and "x" = numbers in folder name.

I have not found a date and / or time holder yet, but I have not searched very deeply in the binary files. I don't understand why a Load Save would not bring in all of the files. Maybe the "SaveData.map" is just a "back-up" of the true data that's in a binary file instead... ?? I sure do wish aanker would get well and re-join us. He knows a lot about the save folders. :salute:

Front Runner

01-09-19, 04:46 PM

I sure do wish aanker would get well and re-join us. He knows a lot about the save folders. :salute:

Latest testing results. I created a new "pristine game" folder using CMS for testing FOTRSUv80 with a Documents Folder dedicated to this test. I've reset all of my hard drives and SSD to disable write caching. I also have the Documents Folder on the same drive as the game test. I made 5 save games for each individual boat. The first save game was made 2.25 hours from the starting time, 1300. The 5 saves were made at these Base times; 1515, Sunset, 0015, Sunrise, and 1215. After each test I saved all the games to separate folders and Classified them either Set A if they worked or Set B if they did not. I also deleted them from the Documents folder. Each new test was made with a clean save game folder. By "worked", I mean that they successfully passed the "quit/start/load/reload/" test. By "BAD" I mean that they passed the "quit/start/load" test, but NOT the "quit/start/load/reload" test.

1. Asiatic Fleet S-18 January 1942 - All saves worked. Classified Set A.
2. Pearl Harbor Porpoise January 1942 - All saves worked. Classified Set A.
3. Pearl Harbor Tench January 1945 - All saves BAD. Classified Set B-1.
4. Pearl Harbor Tambor January 1942 - All saves worked. Classified Set A.
5. Pearl Harbor Narwhal January 1945 - All saves BAD. Classified Set B.
.......testing continues.
[EDIT] What if it's not the boat but one of the options associated with the boat. Both failures were in 1945. All good saves were in 1942.
6. Pearl Harbor Narwhal January 1942 - All saves worked. Classified Set A. This is significant as it indicates that it may not be the "boat" but one or more of the options attached to the "boat."
7. Pearl Harbor Balao June 1943 - All saves worked. Classified Set A. I may be on to something here. Torpedos mix of 14s & 23, Twin 20mm fore & aft, 4" 50 Bow, SJ-I, ISD, JP, WCA
8. Pearl Harbor Tench January 1945 - All saves BAD. Classified Set B-2. Torps mix of 14s & 23, Twin 40mm fore & aft, 5" 25 Bow, SJ-I, ISD, JP, WCA. Maybe it's the twin 40s, or the 5" 25 Bow which I could not change out.
9. Pearl Harbor Balao January 1944 - All saves BAD. Classified Set B. Torps mix of 14s & 23, Single 40mm fore & Aft, 5" 25 Stern, SJ-I, ISD, JP, WCA.

The difference between the (#7) 1943 Balao using the 4" 50 and Twin 20mm, and, which worked vs this 1944 Balao (#9) which uses the 5" 25 gun, but single 40mm fore and aft. The Tench (#3 and #8) use the 5" 25 Bow gun and Twin 40mm fore and aft. The 1945 Narwhal (#5) use the bow and stern 4" 50 gun and twin 40mm fore and aft. The 1942 Narwhal (#6) uses the bow and stern 4" 50 and a single 50 cal machine gun. FOTRSUv80 took away our ability to upgrade/downgrade certain items so I cannot check what would happen if I were able to downgrade the 1944 Balao to the 4" 50 and Twin 20mm fore and aft.

Well, I've gone as far as I can go today. I feel like I'm getting closer to an answer. There is more testing yet to be done.........

[EDIT] Well, if it isn't the "boat" and it isn't the weaponry, torpedoes and sensors etc attached with the "boat" then maybe it's the date. My latest testing reveals that the issue starts with Campaigns beginning in January 1944. A Career with the same boat begun in Mid-1943 (June) does not have the issue.

10. Pearl Harbor Gato January 1944 - All saves BAD. Classified Set B. Torps mix of 14s and 23. Single 40mm fore & aft, 5" 25 gun stern, SJ-I, ISD, JP, WCA.
11. Pearl Harbor Gato June 1943 - All saves worked. Classified Set A. Torps mix of 14s and 23. Twin 20mm fore & aft, 4" 50 gun, SJ-I, ISD, JP, WCA.
12. Pearl Harbor Gar January 1944 - All saves BAD. Classified Set B. Torps mix of 14s &23. Single 40mm fore & aft, 5"25 gun stern, SJ-I, ISD, JP, WCA.
13. Pearl Harbor Gar June 1943 - All saves worked. Classified Set A. Torps mix 14s & 23. Twin 20mm fore & aft, 4"50 gun, SJ-I, ISD, WCA.
By "worked", I mean that they successfully passed the "quit/start/load/reload/" test. By "BAD" I mean that they passed the "quit/start/load" test, but NOT the "quit/start/load/reload" test.

I have all of the save game files, saved and sorted to individual folders if anyone would like to dive in.

Now to start looking at the FOTRSU Campaign generation files beginning in January 1944.

For good measure, and for comparison, I started a Campaign in TMO/RSRD/OTC/ISP, Tench, Feb 1945 and all saves worked.

Front Runner

01-09-19, 04:59 PM

propbeanie

01-09-19, 09:12 PM

Well, I'm having more fun than any poor man should be allowed to have with vehicle issues, so my day has been spent with a broken car - again, and it will eat up a goodly portion of tomorrow.

In the meantime, the Tench and Narwhal are not Stock boats, of course. The Tench is based on the Balao, which comes into the game near 1943, and has caused us issues in that regard, being given to the player too early. Another thing to keep in mind is the different conning towers that are available for the boats, and those influence which AA configurations can be used. FotRSU took away the players' choice of where to place their deck gun, because of the Stock game issue of losing the gun and / or the gun crew.

thank you for all of your detailed testing FrontRunner! :salute:

Front Runner

01-10-19, 09:58 AM

In the meantime, the Tench and Narwhal are not Stock boats, of course. The Tench is based on the Balao, which comes into the game near 1943, and has caused us issues in that regard, being given to the player too early. Another thing to keep in mind is the different conning towers that are available for the boats, and those influence which AA configurations can be used. FotRSU took away the players' choice of where to place their deck gun, because of the Stock game issue of losing the gun and / or the gun crew.

thank you for all of your detailed testing FrontRunner! :salute:
FOTRSU also took away the players choice as to what AA weaponry may be assigned and where. I understand the reasoning behind the Deck Gun, but not the AA. Maybe they are inseparable.

Sorry to hear about your vehicle problems. I've had my share this past few months.

You mentioned "computering" way back in the early 90s. That's about when I got started with "IBM PC compatible". I had a network of computers, all using different versions of DOS, and then different versions of Windows, to keep our radio station up and running.

Before that I had the VIC 20 and Commodore 64. I remember chasing bugs in "Darklands" and "Daggerfall". Both of them were great games but full of bugs.

Please read my [EDIT] to my testing post above. I'm thinking, start looking at the Campaign Generation files related to and beginning in January 1944.
http://www.subsim.com/radioroom/showpost.php?p=2585730&postcount=54

propbeanie

01-10-19, 01:03 PM

I've been reading on some of the real navigation mods, and the issue they had with celestial bodies and the game's use of "local time". What I've experienced before with that is a loaded Save will sometimes take on the local "local time", in place of the 'Home time'. ie: Sunrise near Pearl might be 6:15a, but near Honshu, it's more like 11:15a. You play the game in your first sitting, traveling from Pearl to Midway to Honshu, and night is night, day is day for Pearl time, but might not be for Honshu time. You save the game, exit & come back the next day, and day is day now in Honshu, and you notice that you're on Honshu time, not Pearl time. Not always, but sometimes. Then, you've found that TC can influence how accurately the clock runs, with the game apparently not "locking" the 'earth' cylinder of the game with the 'sky' sphere of the game, apparently relying on 29.97 (30) fps to keep things synced. Seemingly related issues.

I have seen the loss of waypoints before on the navmap also, and got the game to do that the other day. Now I cannot replicate that. I've been shooting all over the firing range though, and have not been consistent with my "testing" targets. You seeing a possible link to the passage of time, as it relates to equipment availability, or something in the campaign is interesting. During the early phases of FotRSU development, we kept running into massive "convoys" of DD, groups of 18-30 in various places of the Pacific. We came to discover that they were improperly set Random Generated Groups (RGG) that were coninually spawning and joining their brethren as they mathematically looped the 'world', until the player got close enough to them, and they spawned into life. The game would stutter, drop frames terribly, worse than when near a large harbor area, and sometimes CTD. The further the calendar advanced, the worse it got. Resource hog. You made a point earlier about the 5" .25 cal., or maybe the AA, 'course, it could be a conning tower...

I'm going to concentrate all my testing near January 1, 1944, based upon what you've found, adding and subtracting one month at a time from a CareerStart, and see if I can get closer to a date when the time and equipment changes things. The 43a files load about 19430901, while the 44a files load about 19440601. Maybe the first "test target" would be a September 1, 1943 start... I'll add another "test" start to FotRSU, and PM you a link for that... :salute:

Front Runner

01-10-19, 04:03 PM

I've been reading on some of the real navigation mods, and the issue they had with celestial bodies and the game's use of "local time". What I've experienced before with that is a loaded Save will sometimes take on the local "local time", in place of the 'Home time'. ie: Sunrise near Pearl might be 6:15a, but near Honshu, it's more like 11:15a. You play the game in your first sitting, traveling from Pearl to Midway to Honshu, and night is night, day is day for Pearl time, but might not be for Honshu time. You save the game, exit & come back the next day, and day is day now in Honshu, and you notice that you're on Honshu time, not Pearl time. Not always, but sometimes. Then, you've found that TC can influence how accurately the clock runs, with the game apparently not "locking" the 'earth' cylinder of the game with the 'sky' sphere of the game, apparently relying on 29.97 (30) fps to keep things synced. Seemingly related issues.
:salute:

To be clear, If you are playing mostly in Time Compression, the game stays in sync much better than if you are playing at 1x with high frame rates. 30fps is recommended to keep the game in sync while in 1x. If you are playing in Time Compression, high frame rates affect the sync only while you are in 1x, such as making attacks or defending. Although the error can accumulate while you are playing at 1x, it seems to be insignificant overall when you are playing Time Compression.
I just completed a transit from Pearl to Midway to Honshu and kept track of my sunsets, sunrises, and some moon-rises and moon-sets. I used 512x time compression for the transit and some short 1x play sequences. I recorded incredibly accurate times for all the sunset, surnrise, moonset, moonrise. The SH4 team did a remarkable job making this work so well in Time Compression.

I have discovered that even when you are based out of Pearl, you are using Midway Base time, 11 hours west of GMT (UTC). I just arrived off the coast of Bungo Suido on an Insertion Mission. The Celestial Sphere has tracked perfectly all along the way.
I am playing FOTRSUv80 in a Balao out of Pearl, January 1944 and the quit/start/load/reload does NOT work. I have to quit/start/load to come back into the game. Sometimes when there is a load glitch, such as the Radio is already playing and I can't turn it off, I have to do a lot of quit/restart/load-ing to finally get one of the saves to load properly. It's a PITA, but it works and anyway I'm having fun! (Aren't I?)

propbeanie

01-11-19, 10:57 AM

Recent discovery fellers... I was crashing with a mini-mod I had made for Front Runner with a few different Start dates to try and narrow-down the time frame involved in the "undesired change", and I started crashing when trying to load Saves when using the Balao - everytime. I have changed the "UnitTypeCommonality=" of the Balao, and lo and behold, no more crashes when trying to re-load. However, I now lose my GamePlay Settings, and my WayPoints when loading the Save... :hmmm: :salute:

Armistead

01-11-19, 12:12 PM

Eclipses happen on time too...

propbeanie

01-11-19, 01:43 PM

Yes. If everything stays in time, the "stage" is set...

https://www.youtube.com/watch?v=8b0Q_xCopZY

The file I sent Front Runner seems to "magnify" this issue he has discovered. I made a change in a slightly related file, and I can now get a similar trouble very consistently. The only difference I can see in what my game does is that sometimes it remembers the periscope was up in a Save, and other times it does not. The game may also forget what my Game Play Settings were... But I can "lose" the waypoints everytime I reload a Save the 2nd time.

It is definitely NOT recommended that a person does that. Similar to using The Museum and then exiting before you play the game, if you happen to have loaded an incorrect Save, do NOT reload another. Exit the game and try again - unless, of course, you're trying to participate in tracing this down. Be warned though, it may trash your install...

propbeanie

01-14-19, 05:32 PM

Front Runner

01-15-19, 12:32 PM

OK, Front Runner, here's a post from Fifi in the SHIII threads I find rather interesting:
What can be this graphical problem? (http://www.subsim.com/radioroom/showthread.php?p=2586590#post2586590)

The move from his SSD to his regular HD...

Interesting. I have moved my install from SSD to Hard Drive. Right now, all my testing is done on my D-Drive HDD with the Documents/SH4 "game" folder all on D-Drive. I've also disabled write-caching.

I have moved one copy of FOTRSUv80 to the SSD and I'm actually playing my career from that install. Except for the Q/S/L/R issue, I'm having a really good career happening.

As you know, sometimes when we make changes, such as he did, we just go ahead and un-install, then, re-install without making careful notes of the settings before and after. SH4 has its own set of bugs that can never be solved without reverse engineering the SH4.exe (Oh! what a can of worms that would very likely be!!) The one we are pursuing may just be one of those type bugs and we have stumbled on the combinations necessary in order to trigger that bug.

propbeanie

01-15-19, 12:55 PM

Front Runner

01-15-19, 02:48 PM

Another point I keep forgetting to clarify is your nVidia Inspector settings. Are you running that 1/2 frame limit, for 30 fps, and / or the "Vertical Sync" check-boxed? I had forgotten to check those settings on my install, so now I've got one with the nVidia Inspector set with 1/2 frame, and the other with Vertical Sync set - but I think that computer (the Win10 laptop) just died... They aren't playing taps just yet, but it is DOA on the surgery table right now... :wah: - of course, it has done this before... shtinking Windows updates:salute:

I'm running with nVidia Inspector settings at 1/2 refresh rate (30 fps) AND I have the Vertical Sync Box checkmarked ON within the in-game settings.

nVidia Inspector settings

Frame Rate Limiter = OFF
(I do not have or use GSYNC settings.)
Maximum pre-rendered frames = 2
Preferred refresh rate = Use the 3D application settings
Triple Buffering = OFF
Vertical Sync = 1/2 refresh rate
Vertical Sync Smooth AR Behavior = ON
Vertical Sync Tear Control = Adaptive

Jeff-Groves

01-15-19, 03:57 PM

Swap the stock scene.dat into FotRSU and test it again.
That would eliminate the scene.dat or prove it's the problem.

Front Runner

01-15-19, 06:34 PM

Swap the stock scene.dat into FotRSU and test it again.
That would eliminate the scene.dat or prove it's the problem.

I did a quick test using Set B save games that had previously failed the Q/S/L/R test with a stock scene.dat. The issue remains.

I'll do another test using the stock scene.dat starting a new career Jan. 1944 out of Pearl which will be more definitive.

propbeanie

01-15-19, 10:11 PM

Front Runner

01-16-19, 12:49 PM

Yeah, new career, since the Save data has the old stuff. My laptop's hard drive is gone... nothing, except the heads hitting the stop (or the platter). It's not even recognized in the BIOS - er UEFI, or whatever... :wah:

OK. I have replaced the scene.dat in FOTRSUv80 with the "Pristine" copy of scene.dat and started a New Career out of Pearl Harbor, Jan 1, 1944. It failed the Q/S/L/R test. I don't think that scene.dat is the source of this issue.

After finishing my series of tests for Propbeanie, starting many, many, careers out of Pearl Harbor, I decided to test careers out of Fremantle, Midway and Brisbane starting Jan. 1, 1944. All of those Career Starts worked just fine!

So, here is where we are right now in FOTRSUv80.
Any boat, out of Pearl Harbor, Campaign Career starting Mid 1943 ALL work fine.
Any boat, out of Pearl Harbor, Campaign Career starting Jan 1, 1944 Do NOT work.
Propbeanie's testing strategy (modified start files) revealed that Campaign Careers starting;
August 31, 1943= NO, does not work.
Oct 1, 1943 = YES, it works.
Nov 5, 1943 = YES, it works.
Dec. 1, 1943 = NO, does not work.
Dec. 15, 1943 = YES, it works.
Dec. 24, 1943 = NO, does not work.

Further, My continued testing reveals that Campaign Careers Starting Jan. 1, 1944 out of Fremantle, Midway or Brisbane ALL work just fine.

The issue seems to affect only Campaign Careers out of Pearl Harbor, starting Jan. 1, 1944, and later, in "stock" FOTRSUv80.

Front Runner

01-16-19, 01:17 PM

I have started a new thread about the "Q/S/L/R" issue as it really has little to do with "Base time", although because of it, your "Base time" is FUBAR.

http://www.subsim.com/radioroom/showthread.php?t=239689

A "Fix" has been discovered!

Front Runner

01-25-19, 12:09 PM

Throughout my testing, I have discovered that Pearl Harbor career starts use Midway Base time. That is 11 hours West of GMT (even in STOCK SH4.)

I had previously believed that Pearl Harbor career starts were 10 hours West of GMT and I could never quite reconcile the differences I was observing in Sunset, Moonset, Moonrise, Sunrise times while in different "time zones". It was because I used the 10 hours West of GMT (when based out of PH) in the Almanac instead of 11 hours West of GMT to determine my "local" SS, MS, MR, SR Base times adjusted to current Lat/Long. So, PH and Midway career starts both use the same 11 hours West of GMT.

It appears that Career starts in some mods that use Mare Island and San Diego are using Mare Island and San Diego Base time and not Midway.

My question is if anyone knows how the game assigns the Base time of the location of the career start, PH, Midway, Brisbane, Fremantle etc and whether or not it can be changed. How can I change the Pearl Harbor career start time to 10 hours West of GMT instead of 11 hours West of GMT.

Jeff-Groves

01-25-19, 06:07 PM

I wonder if your suffering from Day Light savings time.

Front Runner

01-26-19, 07:12 AM

I wonder if your suffering from Day Light savings time.

[EDIT] In effect, yes. Because the time zones that Midway and Pearl are assigned to in real life are 1 hour ahead of their actual longitudinal "nautical" time zones.

The SH4 developers built into the game an incredibly accurate day to day sunrise, sunset, moonrise, moonset simulation. For some reason they assigned Hawaii 11 hours west instead of 10.
[EDIT] They made a CORRECT decision. Hawaii, longitudinally, is 11 hours west of GMT.

I'm asking again, does anyone know where this variable is set in the Campaign? Is it derived from the Campaign Mission files or from the Patrol Objectives? Can it be changed?

propbeanie

01-26-19, 10:03 AM

Front Runner

01-26-19, 01:00 PM

There are no settings in the missions nor in the CareerStart, Flotillas or PatrolObjectives. I also cannot find anything in the cfg folder. You would think there is something somewhere, but I haven't found anything. I'm going to do some Fremantle versus Brisbane starts later this evening, and see what happens with time West of the IDL... :salute:

OK, I understand what is going on when using the US Navy Almanac vs the SH4 game world. Looking at this (interactive) World Time Zone map.......

http://www.geoastro.de/astro/astroJS/timezone/worldmap.htm

(Navy Almanac for reference)
https://aa.usno.navy.mil/data/index

......you will notice that both Midway (X) and Pearl Harbor (W) are designated one time zone to the east of their actual, longitudinal, time zones!!
Longitudinally, Midway is actually in the (Y) time zone and Pearl Harbor is actually in the (X) time zone.

So, here we go again..... Midway is longitudinally -12 hours (or 12 hours West of GMT.) Pearl Harbor is longitudinally -11 hours (or 11 hours West of GMT.) This is why the US Navy Almanac works when you use the 11 hours West of GMT variable to verify your sunset time when leaving Pearl.

To determine Sunset time when based at Midway using the US Navy Almanac, you must use the variable 12 hours West of GMT. Even though Midway is listed as being in the 11 hours West of GMT for "official" time keeping purposes. That's why this is so confusing to us SH4 sailors. The SH4 game world is properly simulated longitudinally as far as celestial events are concerned as opposed to the somewhat arbitrary "time zones" assigned by "man".

In fact, when within 7.5 degrees longitude of 180 degrees (East or West of the Prime Meridian), you can use + or - 12 hours and arrive at the same time. For Instance, Fiji is 12 hours East (+12) at 178 degrees east longitude and Midway is 12 hours West (-12) at 177 degrees west. On the Midway side of the line it is today, on the Fiji side of the line, it is tomorrow.

Just remember, when you are based out of Pearl, or Midway, and you travel West of the IDL, your Base time is what time it is at Midway, or Pearl, and the date is yesterday.

I know this has been discussed at length many times before. It has always confused me. :timeout::06:

Now I understand the math behind it. The SH4 team made very good decisions concerning "Base time." It is up to us, the player, to understand the mechanics behind it all.

From Wikipedia.....

"Since the 1920s a nautical standard time (https://en.wikipedia.org/wiki/Nautical_time) system has been in operation for ships on the high seas (https://en.wikipedia.org/wiki/International_waters). Nautical time zones are an ideal form of the terrestrial time zone system. Under the system, a time change of one hour is required for each change of longitude by 15°. The 15° gore (https://en.wikipedia.org/wiki/Gore_(segment)) that is offset from GMT or UT1 (not UTC (https://en.wikipedia.org/wiki/Coordinated_Universal_Time)) by twelve hours is bisected by the nautical date line into two 7.5° gores that differ from GMT by ±12 hours. A nautical date line is implied but not explicitly drawn on time zone maps. It follows the 180th meridian except where it is interrupted by territorial waters (https://en.wikipedia.org/wiki/Territorial_waters) adjacent to land, forming gaps: it is a pole-to-pole dashed line."

propbeanie

01-26-19, 01:55 PM

Front Runner

01-26-19, 03:05 PM

Funny thing is, in all of the books I've been reading, at the beginning of the war, Pearl Harbor was 30 minutes behind (or ahead - take your almanac pick), of everybody else. Trying to be precise I guess with their sunrise & sunset times... :salute:

So, Florida has passed legislation, that would make Florida, the first and only State to go on permanent Daylight Savings Time. Congress has to approve before it can go into effect. We would always be -6 hours West of GMT no matter winter or summer which would mean that although our winter solstice sunset would occur an hour later, 1842 instead of 1742, our winter solstice sunrise would also occur an hour later, 0817 instead of 0717. Everyone will be driving to work and going to school, waiting for the bus, in the dark. Can you imagine the wintertime airline schedule confusion? :haha::haha:

I'm against it!

Permanent Standard time (-5) hours is preferable IMHO.

https://www.orlandosentinel.com/news/politics/political-pulse/os-daylight-saving-law-20180703-story.html

propbeanie

01-26-19, 03:40 PM

We used to have permanent Eastern Standard Time in most of Indiana, which I liked. We're mostly in the middle of the Eastern and Central zones anyway, so why not? You always knew when sunrise and sunset were, and the day seemed "normal", as far as daylight went. But they had to meddle with Mother Nature, and now we have "Daylight Savings Time" (what is "Saved", I'd like to know). Now an old man can't get to sleep during the summer for the sunlight at 2200 hours... I'm moving to Alaska!... :har:

BigWalleye

01-26-19, 07:59 PM

...what is "Saved", I'd like to know....

What is saved? Why daylight, of course. (But only a bureaucrat could explain how this is done.)

Jeff-Groves

01-26-19, 08:30 PM

I'd like to know where all that daylight I saved went when Spring comes around!
:hmmm:

Is someone stealing it and putting it in a daylight savings account somewhere?

BigWalleye

01-26-19, 09:09 PM

I'd like to know where all that daylight I saved went when Spring comes around!
:hmmm:

Is someone stealing it and putting it in a daylight savings account somewhere?

It is being distributed to people who don't have as much daylight as you do.

Front Runner

01-26-19, 09:13 PM

YellowFin

07-26-19, 08:06 AM

So what are the practical results of this impressive investigation?

Don't load save games from in-game
Enable vertical synchronization
Limit refresh rate to 30 FPS

Am I missing anything?

Front Runner

08-01-19, 07:04 AM

So what are the practical results of this impressive investigation?

Don't load save games from in-game
Enable vertical synchronization
Limit refresh rate to 30 FPS

Am I missing anything?

The save/load game issue was isolated to FOTRSU and has mostly been solved. It was in game patrol start date related. I could not produce the error in TMO and Vanilla. Best practice is to not save game over a previous save game.

V-Sync = ON

Using Nvidia Profile Inpspector, set the Vertical Sync to "1/2 Refresh Rate" to preserve celestial sphere synchronization with gameplay at 1x. This is not a major issue if you mostly play at accelerated game speeds, this issue only affects the game while you are in 1x time, so, to some minor degree it affects everyone who plays it. I discovered it because I was using the game as a "screen saver" and played at 1x for "days" at a time. I also like listening to Fred's Radios.

propbeanie

08-01-19, 09:15 AM

... One way to somewhat control non-nVidia cards is to use sober's antilag (https://www.subsim.com/radioroom/downloads.php?do=file&id=2871) utility. I just started experimenting with it yesterday (again). You'll have to noodle with the antilag.cfg file in it, the game's v-sync on or off (as noted by Front Runner above) and the game's resolution re-fresh rate, which isn't always available for a given resolution. For my particular laptop, if I use the 1600x900 @ 40Hz (which is the laptop's "recommended" rate) setting in-game (there is also a 60Hz choice available for that resolution), with v-sync on, and then restrict the framerate in the antilag.cfg file to 30fps, I actually end up with a max figure of 25fps in the game, using the <Ctrl><F8> keystroke combination. I have not completed experimenting to find a relatively "accurate" 30fps rate just yet...

Quoting the ReadMe with "antilag":
The antilag.cfg contains two configuration parameters:
RenderAheadLimit: This is the amount of frames that D3D9
is allowed to 'render ahead'. A value of 1 means that the
render queue is flushed immediately when a frame is ready.
This provides minimal latency, but can cause a significant
performance drop. A value of 2 allows one frame to be in
the queue, which provides a good compromise between low
latency and good performance. Setting of 0 will disable
the feature.
FPSlimit: This setting will limit the framerate to the
rate set. In cases where the framerate is fluctuating alot
limiting the framerate to a lower value (ie. 35) can provide
smoother gameplay feel. It can also be used to reduce the
cpu/gpu usage, which is helpful for laptop users.
I am experimenting with my antilag.cfg set to:
RenderAheadLimit=2
FPSlimit=30
... I have not adjusted to 60Hz yet to see what happens with the Frame Per Second figure, nor have I tried with V-Sync off yet. The game was written to run at 30fps - from what we've been able to surmise - and anything above that rate (probably below it also) seems to affect the "world" clocks. ymmv :salute:

Front Runner

08-10-19, 06:23 AM

OK. I recently upgraded my graphics adapter from a GTX 780 to a GTX 1660.
With the GTX 780 and FOTRSUv.90, I was able to set the Nvidia Profile Inspector setting to 1/2 refresh rate using the SH4 in game graphics setting to 1920x1080@60HZ, using my new monitor. It worked and I had the 30fps.

However, after upgrading to the GTX 1660 and trying all sorts of settings in Nvidia Profile Inspector, I was unable to get the refresh rate to matter at all.
I did some research and found a post somewhere that mentioned this issue. Their solution was to do a re-boot of the machine before starting their game.
I tried that as well with no change in my situation.

Now, the goal is to get to approximately 30 fps in order to have the Celestial Sphere stay somewhat accurate during 1x play. If you do not spend a lot of time at 1x, then this issue is not applicable. I spend hours, sometimes days at 1x play.

The way I've solved this for the time being is to set my GTX 1660 to my native monitor settings, 1920x1080@144HZ and then setting Nvidia Profile Inspector settings to limit frame rate to ~36 fps, that is 1/4 of the native monitor refresh rate. These settings work for me as I have very good game play and it's close enough to 30 fps so as to not screw up my day/night cycles too much over days of 1x play.

Formerly, with the GTX 780 and the very old Dell Monitor 2407 WFP, I played at 1920x1200@60HZ using 1/2 refresh rate for the 30 fps.
Now, I'm using the GTX 1660 and my new ASUS VG248 (144HZ 1ms) with frame rate limited to ~36 fps.

I hope this helps the very few of us that play at 1x for extended time.

propbeanie

08-10-19, 10:41 AM

I find that interesting and I'm sure anyone attempting celestial navigation will also, since that does affect them also... sadly, the days of the DirectX v9.0c games are coming to an end... everybody wants an FPS instead of fps... sorry, bad pun... :har:

From what you describe with your new card though, it seems that the anti-lag utility and the nVidia inspector both use a "multiplier" instead of actually limiting the frame rate. On this laptop I'm on right now, a 40Hz driver, with anti-lag set to "30fps" actually yields about 24-25fps, whereas with it set to 60Hz, I do get 30fps... :hmmm: - math... sheesh! Not my strong suite.

Front Runner

11-25-19, 03:02 PM

This only affects 1X play.
So, I used my Nvidia Control Panel to reset my monitor's refresh rate to 120 Hz (native 144 Hz). I then set my in game Vertical Sync to ON and in game graphics card to match 120 Hz. I then set my Nvidia Profile Inspector Profile for SH4 Vertical Sync to 1/4 Refresh Rate and I have 30 fps in game.
I am running some tests to see if there is any real differences between the 36.5 fps rate at 144 Hz @ 1/4 refresh rate; the Frame Rate Limiter setting of 30.5 fps (which does not require resetting the Nvidia Control Panel refresh rate at all, I can leave it at 144 Hz,); and my current set up which gives me a monitor refresh rate of 120 Hz divided by 4 which results in the 30 fps.

For information on my setup previous to this post see post #87 above. https://www.subsim.com/radioroom/showpost.php?p=2622262&postcount=87

AGAIN! This only affects 1X play. So, if you are using Time Compression to make your patrol transits, then my experiments do not affect game play significantly at all. As I have previously explained, I like to play at 1X so that I can listen to Fred's Radio stations and read WW2 newspapers and Magazines as I proceed to my Patrol Area while maintaining decent celestial sphere accuracy over days at a time at 1x play.

I also play the game "normally" from time to time using Time Compression.

Front Runner

12-01-19, 11:44 AM

Well, I've been testing and I have found that Frame Rate Limiting does not give the same results as Vertical Sync Rate limiting as it relates to the In-Game Celestial Sphere synchronization.

My initial results show that when I have my Nvidia Control Panel settings set to my monitors' native resolution of 1920x1080 @ 144 HZ with the Nvidia Profile Inspector set to Frame Rate Limit of 30.5 HZ and In-Game V Sync ON, and CNTRL/F8 shows a In-Game frame rate of ~30, I am getting 1X play differences which are very large compared to setting my Nvidia Control Panel to 1920x1080 @120 HZ and using the Nvidia Profile Inspector Vertical Sync @ 1/4 refresh rate (30 fps in game.)
I am still drilling down on it but it appears to me that Frame Rate Limiting does not help synchronize the Celestial Sphere.

My current setup is as follows-
1. My ASUS monitor is set using Nvidia Control Panel to 1920x1080 @ 120HZ
2. My Nvidia Profile Inspector Vertical Sync Rate is set to 1/4 Refresh Rate
3. My Nvidia Profile Inspector Frame Rate Limiter is OFF
4. My In-Game Graphics settings match 1920x1080@120HZ
5. My In-Game Vertical Sync is ON.
6. In-Game FPS = 30
After 1X for more than 96 hours my Sunset is only a few minutes off of the Almanac prediction. It is tracking more or less perfectly.

My previous set up was as follows-
1. My ASUS monitor was set using Nvidia Control Panel to 1920x1080@144HZ
2. My Nvidia Profile Inpector Vertical Sync was set to "Use the 3D application setting."
3. My Nvidia Profile Inspector Frame Rate Limiter was set to 30.5 fps
4. My In-Game Graphics setting matched 1920x1080@144HZ
5. My In-Game Vertical Sync was ON.
6. In-Game FPS = ~30
After 1X for more than 72 hours my sunset was 40 minutes later than the Almanac prediction. Not good.

*NOTE - In-Game Graphics settings take control so it appears to be unnecessary to pre-set the Graphics using Nvidia Control Panel. Whatever you set In-Game takes precedence over Out-Of-Game settings. In other words, I can just leave my Nvidia Control Panel set to 1920x1080@144HZ and the In-Game settings will override. I can set my In-Game Graphics to any of the highlighted options. In this case I chose 1920x1080@120HZ so that 1/4 Refresh Rate = 30 fps.

I know, what does this matter in standard game play? Well, the reason I bring it up is because I'm not sure that the Anti-Lag Mod for non-Nvidia cards is actually syncing the Celestial Sphere as it limits the Frame Rate to 30 as compared to limiting the V-Sync rate to 30 by other means. In my case, forcing V-Sync to 1/4 refresh rate by using 3rd party Nvidia tools.

I'm well into my 4th day at sea at 1X play and the Celestial Sphere is tracking damn near perfect! Especially the Sunsets. Sunrise, Moonrise and Moonset are within acceptable ranges of Almanac predictions.

Useful information Frame Rate Limiting vs Vertical Sync Limiting.
https://forums.tomshardware.com/threads/v-sync-vs-frame-limiter-explained.2272294/

Since the US Navy Sunset/Sunrise website is off-line until late next spring,(now indefinite due to COVID-19) I've discovered another Sunset/Sunrise Moonset/Moonrise Calendar which fills the need. Here.....

https://www.sunrisesunset.com/custom.asp

NOTE: Sept. 23, 2022 - See FIRST POST for the NEW US Navy Sunrise/Sunset LINK