Actually it is borderline useless at the moment as if you look at the enclosed video, it gives you correct vector direction only at certain range and only when in freeview and when not in freeview then it gets limited to horizontal data change only.
http://www.youtube.com/watch?v=6g3A1jl1Otg
Can of redbull indicates where you supposedly look. As you can see it only sometimes corresponds with where you actually look on your screen
execute this in editor
can = "Land_Can_V3_F" createVehicle position player;
oneachframe {
can setPosASL [
(eyePos player select 0) + (eyeDirection player select 0), (eyePos player select 1) + (eyeDirection player select 1), (eyePos player select 2) + (eyeDirection player select 2)
]
}
now look around and play with Alt key
If you look down rangefinder and press alt, the can will not move at all when you look around.
I ran into the exact same issue a while back, and ended up using camera direction instead of eye direction:
can = "Land_Can_V3_F" createVehicle position player;
#define cameraDir ([(positionCameraToWorld [0,0,0]), (positionCameraToWorld [0,0,1])] call BIS_fnc_vectorDiff)
onEachFrame {
can setPosASL ([(eyePos player), cameraDir] call BIS_fnc_vectorAdd);
}
Yes, this is very annoying. Ran into the same thing a while ago but figured it was covered partially with #5878.
It also changes when you are unarmed.
@micovery Are you a wizard? Thanks a lot, this sorted my problem. I was looking for a way to determine perceived distance rather than actual distance, i.e. when using optics. I ended up using weaponDirection "throw" but it is limiting. positionCameraToWorld is much better. Though we do need eyeDirection fixed ASAP.
This might explain some things with ACRE2 that people are experiencing. As far as I know this bug came up rather recently because I had tested this command for positioning sound sources before and it worked fine.
You have to use camera and not the eyes of a unit to achieve what you want.
EyeDirection command is returning correct values, because EyePos/EyeDirection is a socket attached to the model's head that has a certain location and rotation. The head rotation is more limited then the player's camera view, meaning, the player can actually turn his view further then his head in the model will.
EyeDirection/EyePos is limited by this.
A easy way to see this in effect is to switch to 3th person camera and using free head movement turn around to the sides, you will see your head reaching it's rotation limit although, you can still rotate the camera a little further.
Apparently there might be some bugs with eyeDirection though. ACRE2 is going through testing right now and some people said they were experiencing issues with sound location relative to their view. I changed the head vector output to use the camera commands and they are now claiming to get the correct positioning of audio.
That was the only change made in the two releases where the problem was identified and the problem was fixed.
@neokkika appreciate your explanation, however even considering what you said the command is still buggy. If you watch the video looking up or down has no effect unless it is in freeview mode. Surely this cannot be right?
Yes, because when you have a weapon, looking up/down changes torso rotation, not the head rotation.
If you would do it while unarmed, it will work, because looking up/down in that situation changes the head rotation, not torso rotation.
@neokika, ok makes sense. The command should have been called headDirection not eyeDirection.
OK BIKI updated https://community.bistudio.com/wiki/eyeDirection this ticket could be closed as resolved, thanks to neokika's explanation.
Yea, looked like the bug report I had was mistaken from the reporter. Though there is still some other positional bugs related to head direction vs. body direction reported by other users. If they end up being a result of eyeDirection I'll make a new ticket.