I noticed an aiw file anomaly the other day regarding the wp_oriantation parameters for fast lines. If you make your aiw file 'from scratch' in Dev Mode ('driving' it in), the wpOriantation params for the fast line are 180 degrees out of phase (upside-down) to those created by starting Dev Mode with an rF1 aiw file, and letting rF2 convert the rf1 file to rF2 format. A quick way to notice this is by looking at the last floating point value at the end of wp_oriantation=(0,x.xx, x.xxx, HERE). It is the 'Roll' param of the fast oriantation's 'pitch, yaw, roll'. If it's absolute value is close to zero, it was done by 'driving' in a more recent Dev Mode Build. If it's abs is close to pi, then the aiw file was made via rF1 --> rF2 conversion... or by Dev Mode 'driving' in an earlier build of rF2. However.... if you were to do a conversion from an rF1 aiw file to an rF2 aiw file (start dev with rf1 aiw file, and save corridors), and then later 'drive' in a new fast line (using the same rF2 build), the wp_oriantation for the Pits will be 'upside-down' with respect to that of the new fast line. In this case, you would be operating a single track, with 2 opposing varieties of wp_oriantation. I use wp_oriantation for a max viewport camera in a script I am giving away (aiCam) in the track modding part of the forum, and have had to adapt the script to auto accommodate either variety. Not sure what you (ISI) use wp_oriantation for... so I can't say how this may affect rF2 operation. edit: Sorry... initially had description (above) flipped. It is correct now. I actually test for an abs value < (pi/2) for new build orientation.
