| Table of Contents |
|---|
If you are experiencing any problems when running rFactor 2 on your system, it's obviously important to describe your problem as accurately as possible so we can try to reproduce it internally. A step by step explanation would be very helpful. If you have someone else that can validate those steps, that's even better. Apart from describing such steps, there are various different types of logs you can enable that help us diagnose problems in more detail. This page gives a brief overview of each, its purpose and how to enable and send them.
...
- A purple bar, representing physics, that should never be close to 100%. This bar indicates how much time is spent doing physics calculations (which are done on your CPU). If that bar behaves erratic and shoots up to 100%, go to the section on performance logging and try to capture the issue with that enabled.
- A green bar, representing graphics, that (unless you cap your framerate) should be close to 100%. This bar indicates how much time is spent rendering graphics (mostly done on your GPU). If the bar behaves erratic, or somehow your graphics don't appear to be smooth, go to graphics logging.
...
Trace Logging
The trace log contains a step by step overview of events that happen inside the code of rFactor 2. They tell us about series, cars and tracks that load, settings that get applied or saved and many other details. Typically they can help us figure out if anything out of the ordinary happened in the game code as they typically also record error conditions or other problems we can detect. They are useful in situations where the simulation does not do what you expect it to or even crashes. They are typically not useful for performance related issues.
...