The Email Contents are as Follows:
Please feel free to add comments, suggestions, and ideas relevant to the bug and it's resolution.from: Nodoka Hanamura <redacted>
to: [email protected][obfuscated for spam reasons]
date: Wed, Jun 22, 2016 at 10:45 AM
subject: YSFlight - Floating Point Scenery Issue
Hello, I don't believe i've introduced myself - I'm commonly known by my online Alias of Nodoka Hanamura. I am a long time user of YSFlight and member of it's community. For years i've seen nothing but potential from this program - and aspire to, through the projects of the YSFlight Organization "Grun Solutions", a Multi-prospect group based out of the YSFlight Community Forum "YSFHQ".
Recently - a question was posed by members of the site - namely how YSFlight Scenery is technically limited by the way it's programmed. You can read the thread if you wish:
This didn't take looking into the source code - Which as you should be aware - we respect your wishes to not involve ourselves with the source code until you officially release it - but those of us who have experience with Coding and CompSci (OfficerFlake (Who made OpenYS), mrmofumofu, waspe, and to a extreme, me - who has a basic understanding of Computer Science.) were able to decipher the issue.
YSFlight Scenery begins to have adverse effects on aircraft beyond a certain distance, with the effects worsening as aircraft deviate farther from the Point of Origin. This effect is seen as jitter of the aircraft, with faces and parts of aircraft moving out of place on more advanced aircraft.
This is of concern to the Grun, in regards to our newest project to expand Patrick31337's Japan Map to contain the entirity of Japan (save for the southern Island south of Kumamoto and Miyazaki Prefectures, but this is a current hard limit due to this bug, at least - it was. It is also of concern to the YSFlight Community as a whole.
The way we see it - and the community sees it, YSFlight's aircraft positioning system relies on a single value floating point system. A way that this could be rectified is through a floating cell system - something similar to how Bethesda Softworks (Creators of Fallout, The Elder Scrolls) utilize Cells in their games - which "cut up" a larger, massive open world into smaller, more reasonable parts, with each surrounding cell utilizing a seperate floating point value for these sells, and loading each "cell" of a scenery as it's own "scenery within scenery", allowing for this floating point problem to be mitigated.
I'm sorry if my explanation for this idea is a little.. confusing, I don't have a degree in CompSci or programming ( I don't even know a line of C# to save my life), but my knowledge of computing so far brought me to this conclusion.
Let me try and explain it in practical terms. Say for instance - an aircraft is in CELL A, and CELL A has dimensions of 100mi by 100mi,and around it are cells B, C, D, and E, with the same dimensions. The player leaves the boundaries of Cell A into Cell B. The game loads Cell B, and converts the old floating point value to the new value for where the player would end up.
Mr.Yamakawa, the Community has had many projects and dreams tarnished by this bug. I hope you will be able to rectify it, as you are the only one who can.
Other than that, It is a pleasure to write to you, and I await your response.