Page MenuHomeFeedback Tracker

"eyeDirection" command is inconsistent [VIDEO]
Closed, ResolvedPublic


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.

Can of redbull indicates where you supposedly look. As you can see it only sometimes corresponds with where you actually look on your screen


Legacy ID
Steps To Reproduce

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

Event Timeline

Killzone_Kid edited Additional Information. (Show Details)
Killzone_Kid set Category to Scripting.
Killzone_Kid set Reproducibility to Always.
Killzone_Kid set Severity to None.
Killzone_Kid set Resolution to Fixed.
Killzone_Kid set Legacy ID to 2047991717.May 7 2016, 5:12 PM

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.

Nou added a subscriber: Nou.May 7 2016, 5:12 PM
Nou added a comment.May 25 2014, 7:18 PM

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.

neokika added a subscriber: neokika.May 7 2016, 5:12 PM

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.

Nou added a comment.May 26 2014, 9:44 AM

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 this ticket could be closed as resolved, thanks to neokika's explanation.

Nou added a comment.May 26 2014, 9:16 PM

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.

Closing as neokikka explained this very well so this is not a bug