Special Aircraft Service

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2]   Go Down

Author Topic: More apparent weirdness in 4.12.2  (Read 704 times)

0 Members and 1 Guest are viewing this topic.

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #12 on: September 11, 2019, 01:28:52 PM »

I wonder if Team D (or whoever was at the helm for 4.10) altered the variable used to define the phase in the .dll, as returned by the new Moon phase.class. If so, someone didn't take the 30 seconds required to at least see that the selected .tga actually varied. It literally takes no longer than a minute to check this.

But I suppose it's no great loss. After all, has *anyone* beside me over the years noticed a thing? All would seem to be blissfully ignorant. Far more attention is given to such minutiae as the number of polygons making up a gun barrel for a plane's model.

This clusterfrack almost negates the whole purpose of utilizing a full date system (which itself has issues, as noted.)

The simple code I put in Sun.class obviates moonPhase.class. Because it can accurately enough for our purposes set the Moon phase, properly locating it in the sky and determine the relevant .tga--if the related 4.09 code was still present in the .dll. Well, I *presume* so. I should go back to 4.09 with this and see what results...

This is all rather discouraging. For me, anyway, because I view a halfway proper representation of the Moon in a flight sim (or any other sim where activity can occur in darkness) as *fundamental.* And it's so simple a thing to get basically correct. But apparently no one cares, preferring instead to wish for such things as the addition of some notional prototype plane that never even flew off the drafting table. ;)
Logged

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 17945
  • Failure is not an option.
    • What goes around comes around, you'll see
Re: More apparent weirdness in 4.12.2
« Reply #13 on: September 11, 2019, 11:03:50 PM »

Actually that dll (il2_core.dll) never changed, it's the same across all game versions.
I'd really be keen to know what causes the moonphase to be displayed statically and/or not correctly.

]cheers[
Mike
Logged
You've got no one to follow, and no one will follow you. Ain't that a relief?

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #14 on: September 12, 2019, 12:38:24 AM »

If indeed nothing has changed 'under the hood', would comparing 4.09 Sun.class with its later (4.10+) version yield an important clue as to what exactly is the relevant variable? Perhaps the variable "moonphase" is used only to define the Moon's longitude w.r.t. the Sun, and some other variable is used to choose the correct .tga.

If Sun.class is still all that's really needed for the Moon business (when a routine like mine is incorporated), with MoonPhase.class being only an interjected class to return a desired result, then the latter could effectively be ignored. We would in effect be going back to an earlier scheme, albeit improved upon in a way that could have been done from the start, before coming up with a dedicated MoonPhase.class.
Logged

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 17945
  • Failure is not an option.
    • What goes around comes around, you'll see
Re: More apparent weirdness in 4.12.2
« Reply #15 on: September 12, 2019, 01:20:37 AM »

would comparing 4.09 Sun.class with its later (4.10+) version yield an important clue as to what exactly is the relevant variable?
That comparison is available.
https://www.sas1946.com/main/index.php/topic,49806.0.html
...takes you to...
https://storebror.it.cx/sas/code_comparison/409-4101/BcFiles/117.html

]cheers[
Mike
Logged
You've got no one to follow, and no one will follow you. Ain't that a relief?

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #16 on: September 12, 2019, 01:47:51 AM »

Mike,
I've looked at that table, but didn't realize it could do this. Bloody marvelous!

So. It really looks like my suspicion *might* lead to a solution. That ad[0] variable from an array of 10 created in MoonPhase.class could be the culprit. We need to see what that array stores in each of those 10 slots. Or just try out a substitution of 1 to 9 in lieu of that 0, here in Sun.java. Unless my understanding of Java really is as deficient as I believe it is! ;)

Of course, we can simply bypass this entirely, calculating the phase in Sun.java.

Unless you dash ahead and beat me to it, I'll very soon undertake work on this.

Thanks for your attention to and assistance with this too long outstanding problem. Hopefully a much better Moon will result soon.

 ]cheers[

Glenn
Logged

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 17945
  • Failure is not an option.
    • What goes around comes around, you'll see
Re: More apparent weirdness in 4.12.2
« Reply #17 on: September 12, 2019, 02:37:54 AM »

Unless you dash ahead and beat me to it
Don't worry Glenn, I'm busy with getting the next Ultrapack version out of the door :)

]cheers[
Mike
Logged
You've got no one to follow, and no one will follow you. Ain't that a relief?

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #18 on: September 12, 2019, 03:48:49 AM »

Well, hopes are trending toward being dashed. I added some lines to Sun.class to send the contents of that array ad[10] to the console. Assuming 10 entries, I got an out of bounds error; turns out just 7 variables are stored.

Anyhoo, when loading different maps and setting different dates/times, those 7 values remain essentially unchanged. (They have a range among them of between less than 1 to more than 30,000, so they look 'legit', I suppose). It's like some other fixed calendar value is being used all the time. Weird.

Gotta get a couple hours sleep, in order to stay on my feet at work today. ;)
Logged

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #19 on: September 13, 2019, 02:02:08 PM »

This game from the outset determined the Moon phase based on it being New on Jan 1.0. (No specific year considered; the year is 'generic' and unchanging). The mean synodic month of 29.53 days is applied from this point to find the subsequent phase.

I wonder if something in the .dll is staying with this premise. And so my next experiment is to calculate both the real phase based on the actual date and this earlier 'simplistic' phase, and apply the difference to see if I get the right result.

But one thing still concerns me. And that's the demonstrated inability to change the phase graphic, after the initial calculation, when adjusting the date thereafter. Now, the fact that a different starting phase graphic is indeed presented initially when loading a new map/mission that is based on a different date suggests that it's not something being utterly broken in the .dll regarding this graphic selection. Rather, it seems to point to some particular variable not being updated in the date/time values that are sent to that routine in the .dll.

Just my latest thoughts and suspicions...
Logged

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #20 on: September 13, 2019, 03:44:53 PM »

In the 4.09 Sun.java, if I simply add a phase angle correction I get the *correct* Moon phase graphic. So we know that's working! The 4.09 and earlier scheme...

For summer months the stock phase is a fat gibbous, just after full Moon. That's because the game always uses the 15th of the month, and every game month has 30 days. And so by July 15, 195 game days have elapsed. Divide this by the synodic month of 29.53 days, we get a phase angle of 195 / 29.53 = 6.603. From the Jan 1 new Moon, the Moon has completed 6.603 phase cycles. The remainder 0.603 is the current phase.

The phase angle is 0 to 1, with new=0, first quarter=0.25, full=0.5, last quarter=0.75, and back to new at 1.

The phase of 0.603 is therefore just past the full phase of 0.5. If I subtract 0.103 from the Sun.java calculation for phase, and open a map having the month of July (month number 6, because Jan is 0), I get a nice and round full Moon graphic. If I subtract about 0.36, I get a first quarter Moon graphic because the phase angle used is now about 0.25.

In my new treatment, then, I should calculate this old, simplistic phase as well, using the original algorithm. Then I determine the *real* Moon phase angle on Jan 1.0 of the current game year. This gives me a phase offset between the old Jan 1 and the proper Jan 1 Moon phase. This offset is propagated to the current game date and applied to a new MoonPhase value to be returned to the .dll.

Well, that's my provisional approach thus far. Assuming the .dll is independently determining all over again the old phase. Geez, how I'd love to peer inside the source code for the .dll's!
Logged

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #21 on: September 14, 2019, 04:58:08 AM »

After several more hours, no joy on getting the Moon phase graphic to change. Back to hopes fading. So annoying that a simple alteration in 4.09 could do this, but not now.

The date numbers in the FMB dialog are definitely out of step by 1, at least as far as the Sun's position goes. It's weird to have "12" apply to January, and not December as one would naturally assume. The Summer solstice occurs in month "5" (not 6), and the Winter solstice is in month "11" (not 12.) This really should be fixed.
Logged

whistler

  • Modder
  • member
  • Offline Offline
  • Posts: 1702
Re: More apparent weirdness in 4.12.2
« Reply #22 on: September 25, 2019, 05:50:15 AM »

This is a very interesting topic. It would be great to have an historically accurate moon in the game.

I always wondered about the [APPENDIX] "Moon = Moon\Moon00XX.tga" entries in map's load.ini... isn't this what sets a static moon phase in a map?
Logged
NG-HUD v3.2 | NG-MAP v3.0 | NG-CAM v1.6: https://www.sas1946.com/main/index.php/board,93.0.html

WxTech

  • Modder
  • member
  • Offline Offline
  • Posts: 1317
Re: More apparent weirdness in 4.12.2
« Reply #23 on: September 25, 2019, 08:35:56 AM »

Even now, depending on the date, a different Moon graphic is selected. This tells us that the map's Moon00xx".tga is not what's actually selected. This seems to do no more than set a start point; New moon on Jan 1.0.

Moon0000.tga is basically New moon, and the pre-4.10 code had this occur on Jan 1, with the phase cycle taking 29.53 days. With the old code having each month last 30 days, by the end of the year the Moon would have gone through 12 phase cycles plus nearly 6 days of the 13th cycle. And so if the years were properly handled in the old game, by the next Jan. 1, instead of the New moon that was always the case, the Moon would be nearly at first quarter phase.
Logged
Pages: 1 [2]   Go Up
 

Page created in 0.013 seconds with 26 queries.