🐛 Moon Phase handling incorrectly assumes symmetrical ascent/descent.

[Rosienaikanaro]

I affirm:

• [x] I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• [x] I have read and understood the Contributing Guide and the Code of Conduct.
• [x] I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

OS / platform the server is running (if known)

Windows 11

Branch affected by issue

base

Steps to reproduce

VanadielMoonPhase() returns a number, but the usage of its handling results in flawed logic in nearly all cases where it is called.

Expected behavior

Waxing and Waning moon phase percentages are asymmetrical. This means that the current calls to its use in places like Lunar Cry being handled as raw numbers will create situations where a 7% Waxing Crescent will result in New Moon potency. This has a similar issue at the top end where Full Moon starts at 90% as the moon is waxing but ends at 95% as it is waning.

This likely means that either VanadielMoonPhase() needs to be altered to return one of the 12 phases listed in the BG article below or a new method needs to be created that returns the correct phase instead of raw fullness percentage. Then either way afterwards we should enum the 12 phases then that method and enum will need to be applied to all current and future MoonPhase calls to correct the handling logic.

https://www.bg-wiki.com/ffxi/Category:Moon_Phase

[Xaver-DaRed]

The % is literally what the client uses/returns when requesting the time.

In my eyes, the issue here isnt with the function, but with using it when it really shouldnt be used. I think the correct path forward is a different function altoguether that returns the actual cycle, similar to what you suggested, but without touching the existing function.

TL;DR the existing function isnt at blame here. we are for using it when we shouldnt