Lately ive been trying to create a realistic HMD system for my airplane, and i was quite bummed to find out its actually impossible. Ill just recount some things ive tried to make it work if it proves of any help with this report.

As i said in the description, the most logical solution would be to use the players camera vector (or rather offset vector between forward and wherever the player is free-looking) to calculate the bone positions in class MFD. So you could, for example, offset the planeW bone with a negative version of the camera vector to make the waterline symbol (plane nose direction marker) to point forward even when the player is using freelook.
After some research I found it was only possible to grab the camera direction using an sqf script (and even then it was complicated) and since there is no way to use script variables in configs, this plan didnt work.

Next i considered creating two seperate HUDS, one MFD and one conventional which is bound to points in the memory LOD as per usual. This would sort of fake a lot of features that MFD's have by allowing some HUD elements to be drawn on the forward pointing conventional HUD and having the rest on the MFD which follows the players camera. It still would not allow for more advanced functionality such as weapon cueing and proper situational awareness features (having the targeting boxes draw properly no matter which way you look).
Even though i would have lacked some exciting functionality, faking the mfd would have been satisfactory but this method was doomed to fail as well. There is no way of clipping out the conventional HUD when it is on the edge of the players vision. a HMD still has a limited FOV and when HUD elements move outside that FOV they should not be drawn. This would not have been possible for the conventional HUD.

I also tried toggling the enableParallax = 0/1 setting in class AirplaneHUD but that had no effect when helmetMountedDisplay was enabled. It does say in the documentation that the parallax effect does not take in to count freelook, and that makes sense since it wouldnt work for conventional HUDs, but i was grasping for straws at this point. Optimally i was hoping that with parallax disabled the HUD element would point forward at all times, and with enabled it would follow camera. This would have been yet another way of "faking" the visual functionality.

I suppose theres no way this feature could be implemented before the MANW deadline, but i might as well try rather than leave it as something that could have been but never was.