This article will guide you on steps needed to log data into Statoscope.
Enabling Data groups does impact performance, especially if you enable everything at once.
Select only the data groups you want to display to reduce the impact of logging the data to Statoscope.
Two CVars need to be set in the Launcher or Editor to enable logging: e_StatoscopeLogDestination and e_StatoscopeDataGroups.
This controls where to log to:
0 - File - saves a log to the root/statoscope folder. On 360 this will be on your dev/testkit.
1 - Socket - the tool connects directly to the game.
This controls what data to log. It's an upper and lower case bitfield CVar, so you can do things like e_StatoscopeDataGroups fg, e_StatoscopeDataGroups A+, e_StatoscopeDataGroups g- to get the equivalent of e_StatoscopeDataGroups fA.
Obviously adding and removing groups like this is most useful at run time in the console.
To add data groups at run-time, use the + sign:
To remove data groups at run-time, use the – sign:
For the list of available data groups see Statoscope - Data Groups or search in Visual Studio for "public IStatoscopeDataGroup" you should be able to find them all.
The defaults are set to upload some basic data, which is useful for QA play-throughs and net tests.
If you just want to record some data to see how your game is performing, the best setup is usually socket logging. This gives you a live update in the tool and avoids the hassle of managing log files.
If you want to log QA sessions or compare time demo runs, file logging is the thing to go for.
These are collections of stats. So for instance, the streaming audio data group ('a') records both actual and requested audio bandwidth. It's not possible to split data groups - in this case you get both stats or neither.
Which data groups you enable will of course depend on what data you're after. Many are self explanatory, but it's probably still worth looking at the implementation of the appropriate IStatoscopeDataGroup class to be sure.
See Creating new data groups below for more details on how data groups work in code.
The 'r' data group records function profiler data, the same stats that "profile 1" displays. It was initially implemented to find large single frame spikes. To keep log size down, a few cvars were added that control which functions are recorded:
Now that streamed binary logging has been implemented, it's probably ok to have e_StatoscopeDumpAll enabled all the time.
If you're after more than just the main thread, don't forget profile_allthreads 1. You can of course filter by thread and module in Statoscope, but if you'd rather do it at logging time, consider using profile_filter and profile_filter_thread. These 3 CVars are just pre-existing profile system functionality.