23.12.2018, 10:11
The submitted vectors go through a lot of stages.
stages of data flow:
- must use a M4/AK47/MP5 (other weapons are disabled because of their unreliability)
- the victim must be moving
- and many more
If a shot fails any of these conditions, the entire running pool is rejected and starts afresh.
After pooling many shots together, it goes through another filter. The filter decides if there is enough information that can be extracted from the pool; if not, it continues to collect more shot. Once there is enough useful information, it checks for reliability and estimates the use of aimbot, for example, by checking the pool's ratio (required to be high for last X number of shots where X is between 7 and 20).
It's only after this step the sample is said to be fully complete. This is when `submit_vector` returns 1. This sample is put in a queue for processing. The detectors are running in different threads. They pick a sample from the input queue, investigate it, dump it to the output queue. In the server's next tick cycle, results are pulled out of the output queue and the callback is triggered for each sample.
Hence, the callback is triggered only when there was enough suspicion and after it was processed by the AI machinery.
TL;DR:
- callback is triggered only when there is some suspicion, i.e. when the empirical methods suggest the use of aimbot
* however, the AI machinery can reverse the decision and say this may not have been an aimbot
- it's difficult to get the callback triggered without using an aimbot because most samples are rejected empirical methods
- callback is triggered every minute or so when an aimbot is used
* the callback being triggered does not imply that aimbot was used; you need to check the probabilities
stages of data flow:
- data collection: a script collects shot vectors
- pre-filter: carries out checks to eliminate unreliable shot vectors
- transform: transforms shot vectors to a form suitable for feature extraction
- pooling: pool together a variable number of transformed vectors to form a complete sample
- extract features: extract features from the vector pool
- post-filter: carry out basic empirical checks on the sample to check reliability and possible use of aim-assist; if suspicious, forward it to the AI machinery
- detectors: run through different detectors and average the result
- must use a M4/AK47/MP5 (other weapons are disabled because of their unreliability)
- the victim must be moving
- and many more
If a shot fails any of these conditions, the entire running pool is rejected and starts afresh.
After pooling many shots together, it goes through another filter. The filter decides if there is enough information that can be extracted from the pool; if not, it continues to collect more shot. Once there is enough useful information, it checks for reliability and estimates the use of aimbot, for example, by checking the pool's ratio (required to be high for last X number of shots where X is between 7 and 20).
It's only after this step the sample is said to be fully complete. This is when `submit_vector` returns 1. This sample is put in a queue for processing. The detectors are running in different threads. They pick a sample from the input queue, investigate it, dump it to the output queue. In the server's next tick cycle, results are pulled out of the output queue and the callback is triggered for each sample.
Hence, the callback is triggered only when there was enough suspicion and after it was processed by the AI machinery.
TL;DR:
- callback is triggered only when there is some suspicion, i.e. when the empirical methods suggest the use of aimbot
* however, the AI machinery can reverse the decision and say this may not have been an aimbot
- it's difficult to get the callback triggered without using an aimbot because most samples are rejected empirical methods
- callback is triggered every minute or so when an aimbot is used
* the callback being triggered does not imply that aimbot was used; you need to check the probabilities