*\cROTATE spawnflag

The model_train viper (if it hasn't already crashed) uses the ROTATE spawnflag to
turn towards the next path_corner in its sequence. It also rolls towards the next
path_corner's roll value at the model_train's roll_speed value. If the train's path
seems a bit too linear, you can add additional path_corners and/or play with the
train's yaw_speed and roll_speed values.

After 3 circuits of the map, a target_change changes one of the train's path_corners
to point toward a different route. A subsequent path_corner targets ANOTHER
target_change which changes the train from ROTATE to ROTATE_CONSTANT, at which time
the model_train goes into an uh-oh uncontrollable yaw spin.

The forklift func_train has the ROTATE spawnflag set. It will turn towards the next
path_corner in its sequence at its current yaw_speed. Both the func_train's speed
and yaw_speed may be changed at every path_corner by setting the corresponding values
for that path_corner. You'll see this in effect at the halfway point around the
path_corner circuit.

The red beacons in this map are just a sanity check to prove to yourself how the train
is placed in the map relative to the path_corners. You'll notice in the map file that
the beacons are all at the same offset from the path_corners.

You'll notice that the forklift is placed with it's center near x=y=0 in the map file.
This allows us to use rotation without adding an origin brush to the func_train. The
lack of an origin brush does 2 things for us:

1) It doesn't foul up the lighting as brush_models with origin brushes normally do, and

2) It allows us to place the wheel textures exactly, without a lot of trial and error. 
Aligning those wheel textures would have been incredibly frustrating if an origin brush 
were used.

NOTE: It's next to impossible to make a believable smooth curved path with this func_train,
unless you use a LOT of path_corners. Slow yaw_speeds will cause the func_train to very
obviously slide rather than turn.