twpol
commented
11 years ago Imported from https://bugs.launchpad.net/or/+bug/1092827/comments/1
| Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Sun, 23 Dec 2012 22:19:01 GMT |
Azimuth is not an X/Y/Z value, and neither is its cohort Elevation; both specify min/centre/max values for rotations about the Y and X axes. Open Rails currently only uses the centre value as it doesn't support glow lights following the camera, which is why you see the strange behaviour on the BKV_UV wagons - they specify 0/-180/0 and 0/0/180 for Azimuth so in OR you'll get the light facing directly forwards or backwards, but never outwards as might be more likable.
Imported from https://bugs.launchpad.net/bugs/1092827
This function in MSTS is interpreted as an angle from the light's original orientation, within the light always faces camera/viewer. While OR interprets this as a simple rotation angle just modifying the original orientation, but the light doesn't follow the camera dynamically by its facing.
Moreover the axes are also smashed somehow. The order of the axes depend on the Light( Conditions( Headlight() ) ) setting as well. E.g. in MSTS, when Headlight(1) is set, the Z(up) axis is the 3rd parameter of Azimuth() function; while when Headlight(3) is set, the Z(up) axis is the 2nd parameter of Azimuth() function. Strange, I don't quite understand it too, but OR handles this function in a different way than MSTS.
A good example of it is the following (already referenced in another bug) consist: http://vm15.hu/e107_files/downloads/msts/mozdony/BKV_UV_SE_2009_vegleges.rar You may check the blinking orange direction indicators and compare them how in MSTS behave. For playing with them please find their definition in eng after line "COMMENT ( indexek 4 feny )"