Questons .txt    Questions about the  Move_Car package    Version 1.1 April 21, 2002
============================================
Installation Problem Troubleshooting is in the file "Problems.txt".
============================================
Q.  Why didn't you include a model with this package?  Why don't the wheels turn or
      steer? And where are the headlights, tail lights, wipers and blinkers?  Why don't the
      doors open, or flap around, the way they do in Grand Theft Auto III?  Why don't you
      lay down skid marks when the tires are squealing?  Or blow smoke out of the exhaust?
      Or morph the body to show damage, after it hits something?

A.  This script is designed to handle the motion physics for a lot of different types of 
      vehicles.  All of the things mentioned above require knowledge of the exact type and
      dimensions of the model you plan to use.  (I don't think everybody will want to
      use only the Rally Car!)  Headlights are attached to a particular vertex number.   
      Some models may not have a vertex point or number where I would have attached
      a headlight.  Therefore, model dependent features are not included in the script.  
      Model animation, morphing or deforming is not included for the same reasons.

      To make the wheels rotate, you probably would want to position, or attach, four
      models of wheels to the main model.  That is beyond what this script is trying to do.
      It might also consume more cpu cycles than other people have to spare. Some users 
      may not care about rotating wheels, since the provided camera views look only at the 
      back or top of the car.  If you want to add rotating wheels, the "axle_rpm" variable 
      provides you with the data you need, to know when, which direction, and how 
      fast to rotate your wheel models.  The "steer_force" or "steer_speed" variables should 
      give you the values you need to steer the front wheels, or turn the steering wheel.
      More information is available in the documentation file, "Other_Models.txt".
_________________________________________________
Q.  Your collision detection is really crummy! And your "rock-back" may lower the nose 
      of the car while you are stopping, but it also raises the rear wheels. 
      Your "wheelie" feature buries the rear wheel!

A.  All true.  Again, to do accurate collision detection, you have to know the shape 
      and dimensions of your model.  Since the script wasn't told those things about
      the model you decided to use, the script simply uses the default box-like hull and 
      bounding box of the model.  You might want to add a function to do better scanning
      for other objects.  You can place the call to that function either right after the
      "Car_Scan_Floor()" function, or at the end of all the function calls, whichever 
      works best for you.
      The tilt and roll of the model, for "rock back", wheelies, or having just one wheel 
      run over a curb or a bump, or over an edge, is not simulated as good as it could be.  
      Again, that is because the script uses the default box of the model, which rotates 
      around the origin of the model.  The model's height above ground (absdist.z) needs 
      to be adjusted by the tilt and roll of the model.  But how much (or if) depends on 
      the model you choose to use, and what you are trying to do with it.
      More information is available in the documentation file, "Other_Models.txt".
      Take a look at "Wheelies" in the Motorcycle section.
____________________________________
Q.  My keyboard, mouse or joystick moves faster/slower than I would like.  
      How do I fix that?

A.  Change the value of "car_tstrength" to change the amount of throttle strength, and 
      how quickly it reacts.  You can lower it, or make it faster, but you can't go above 
      100%, in forward, or below -20%, in reverse.  Works for keyboard, mouse and 
       joystick.  This strength value is normally set to 1.0, by default.

      Change the value of "car_sstrength" to change the amount of steering strength, and 
      how quickly it reacts.  You can lower it, or make it faster, but you can't have a
      "steer_force" of more than "6".  Works for keyboard, mouse and joystick.  
      This strength value is normally set to 1.0, by default.

      NOTE: You can change the maximum values, by changing the max/min instruction
                  in the "car_player_intentions()" function.  It's clearly marked.
_______________________________
Q.  Why didn't you include something that lowers the "health" of the vehicle, after it has a 
      hard landing, runs into something, or over-speeds the engine?

A.  There is no way of knowing what kind of "health" problems you want the vehicle
      to have, or how much it should affect the performance of the vehicle.  However, there
      are some built-in variables that can help you.  "Hang_Time" gives you the amount of
      time the vehicle was in the air.  "Drop_Time" will tell you how long it actually spent
      falling.  "Impact_Speed" will tell you how fast it was falling when it hit the ground.
      "Impact_Angle" tells you the angle it struck the ground.  These variables are all reset
      during each fall.  When the "Was_Airborne" variable gets set to one, you just finished 
      falling, and should grab the numbers you are interested in.  (Check out the "Drop_Hang"
      function.)
      The RPM variable is always available.  Set up a function which checks to see if the
      RPM is in the "red zone" (greater than 6000, or whatever) and add a number to a 
      counter each time you loop through the action.  (Multiply it by the variable "time" to 
      compensate for faster or slower computers.)
      Horsepower is only used to calculate "Max_Torq" during the "car_init()" function.
      If you start reducing the value of Max_Torq, you will reduce the amount of power
      available to the vehicle.  Or you can lower the value of "car_tstrength" 
      (throttle strength) to reduce how far the throttle travels.
      After a collision, you can gradually reduce the value of "car_sstrength" 
      (steering strength) to make it harder to steer the car.  (It won't turn as quickly.)  
      Or multiply "steer_damage" by a random number, (between .6 and 1.4) to mess up 
      the variable steering ratio.  The amount of turning will become unpredictable, and may
      not steer at some speeds! (or work backwards)  Check out the "Steering" function.  
____________________________________
Q.  Your script looks inefficient.  There are better ways of writing scripts.

A.  I agree.  But remember, the script was also written as a learning tool, and not as a
      packaged game.  There are several places where two or three lines of script 
      could have been compressed to a single line.  But that would be harder for 
      someone to learn and understand.  And less room for comments.

      Also, putting control values in a table requires more variables than simply making 
      multiple uses of "temp", or pre-calculating some results.  For example, the
      multiplication of "gear_efficiency" and "differential_ratio" happens every time.  Those
      values do not change after the script starts running.  The multiplication could be done
      once, in the "Car_Init()" function, and would run (very slightly) faster.  However, 
      keeping both variables in the Drive Train calculation makes it easier for someone 
      else to understand what is being calculated, and how.
      If you understand the script, and are experienced enough to see ways to make the 
      script run better in your appliction, then by all means, please do so!
      But don't forget that since C-Script is compiled, the amount of comments, or the length
      of the name of a variable, does not make the script any more or less efficient!
____________________________________
Q.  You could have written this with less than half of the number of functions you used.

A.  True.  But I don't think the number of functions causes any real efficiency problems.
      But they do make it a lot easier for someone else to extract a function, and use it in
      some other script.  Having the script organized by functions, makes it a lot
      easier for people to understand the script, or to help understand where they need
      to make modifications to change, create (or add) a different effect.
_____________________________________
Q.  You don't have a really accurate physics simulation.
Q.  Your script takes more cpu power than I have in my slow PC!

A.  The more complex (and accurate) the physics simulation, the more cpu power
      (and memory) it takes to process and hold all the variables.  This scrip is an attempt
      to provide a balance between hard core, mathematically perfect calculations, and a
      desire to provide a fun experience for people who don't have super computers.

      If you know the advanced math that I have simplified, then use this script as a 
      "cook book" or building block, and add the more complex and demanding math.

      If your PC is struggling with trying to keep up with the calculations, you can easily turn 
      off many of the effects you may not care about, such as the on-screen displays, the
      vehicle leaning, rock back, tires squealing, tuned engine sounds, rear-view mirror, etc.

      Both interest extremes have the option to make it either more, or less, demanding or 
      mathematiclly accurate.
_______________________________________
Q.  Why did you make Car_Cam a separate .wdl file?

A.  Just to make it easier for someone to "borrow" that code.  You just have to "include"
      the Car_Cam.wdl file, and put only one line in another script, to use those camera 
      views and view switching controls:
        [  car_view();         // Update the main camera view (Car Cam)  ]
      And, you don't have to worry about any function or variable definitions. Kinda neat, huh?
      (Actually, that's not completely true.)  The "Follow" view needs some kind of input to know
      how far to fall behind, and when to zoom in.   (See line 80 in the Car_Cam.wdl script.)
      Change "Car_Velocity" to any other variable you want to use.  A good range is 0 to 300,
      which is the internal value of "Car_Velocity".  ("Car_Speed" goes from 0 to 140+)
________________________________________
Q.  I'm irritated that you are using the "V" key to switch camera Views.  Why couldn't you
      have stayed with the standard F7 key, just like all the standard templates use?

A.  The intent of this script is to "play nice" with all of the standard templates.  Since the 
      movement.wdl file also "includes" the camera.wdl file, the F7 key is still active
      within the standard template camera.wdl file.   Maybe it won't cause a problem - and
      maybe it will.  I don't know what else you are going to be doing in your scripts when 
      you include the Move_Car package.   I just played it safe, to avoid possible problems.
      In fact, I tried to avoid using any key or button that is used by the standard templates.
      
      You can very easily change Car_Cam to work with the F7 key, instead of the "V" key.
      Open the Car_Cam.wdl file, and go to the very end of it.  In that one place, you will find
      all of the assignments to switch camera views by the keyboard, mouse and joystick.
      Simply change the line "on_v  cycle_car_view;"    to    "on_f7  cycle_car_view;".
      (That  "should"  work just fine.  But don't call me if you have a problem.....)
__________________________________________________
Q.  I tried entering table values with numbers right out of the owner's manual for my
      '57 Chevy, and now everything is really screwed up!  What's wrong with your script?

A.  Maybe nothing!  I seriously doubt your owner's manual provided numbers for things
      like Engine Resistance, Air Drag, Rolling Resistance, Acceleration factor, RPM shift
      points, etc.  
      All of those variables have to be balanced.  The script is written in such a way that if you
      change the Horsepower, it will automatically re-calculate Max_Torque, Engine Resistance,
      Drive Torque, etc.  But don't forget there is a feedback loop from the wheels that 
      controls the engine RPM, which then determines the engine look-up torque, and ultimately
      determines how much power the engine is really generating.  Some of these variables
      may need a little tweaking to compensate for other variables you have changed.

      The testing I did indicates the script will usually compensate for different input values.
      The biggest problem I found was when you change the number of gears, or the gear ratios, 
      and the car tries to automatically upshift, below where it automatically tries to downshift.
      So if you change the number of gears, or the gear ratios, you will very likely also have to 
      modify the RPM values where it automatically upshifts, or downshifts. Otherwise, they will
      fight against each other.
      The script is designed to be flexible enough to handle a one gear army tank, or a twelve
      speed mountain bike.  (You will have to increase the size of the gear array, and add more
      numbers to the on-screen gear indicator. Instead of a "Differential_Ratio", you will need
      to enter the gear ratio of the pedal gear, chain and rear wheel gear.)  Obviously, the tank
      has a lot more horsepower than a bicycle, but accelerates a whole lot slower.  Those 
      differences can be accommodated just by changing table entry values.  (Weight, acceleration
      factor, gear ratios, etc.)  And the tank will probably lean a lot less in the turns.  But again,
      that can be adjusted just by changing one value in a table entry: "Corner_Lean".

      The script could have been more intelligent for self adjustments.  But it wouldn't have been
      as flexible.   Bottom line?  Try changing table values that look like they might be causing a
      problem, until you get it to work the way you want it to work, for your particular vehicle.
      Also take a look at the documentation file "Changes.txt" for suggestions on changing values.
_________________________________________________________
