[Незначительный] flyhack

[PVEMYTANT]

В последнее время, особенно после открытия x4 и массового перехода игроков на VPN из-за проблем с провайдерами и ограничениями интернета, очень часто начали появляться ложные автобаны за flyhack. Сценарий в целом уже давно известный для TrinityCore и AzerothCore 3.3.5a, игрок летит на маунте, в момент лагов, packet loss, высокого пинга или просто кривого маршрута слезает с маунта, а сервер из-за задержки movement packet'ов еще какое-то время видит персонажа в воздухе без fly aura и сразу триггерит flyhack detection. По факту это не чит, а обычный desync из-за плохого обмена пакетами, особенно сейчас когда половина игроков сидит через VPN и нестабильные маршруты.

Самое странное в этой ситуации то, что и TrinityCore и AzerothCore уже имеют доступ к latency игрока, movement history и всей необходимой информации чтобы подобные кейсы нормально фильтровать. Сейчас античит по сути реагирует слишком агрессивно на единичное событие, из-за чего люди спокойно могут получить автобан просто из-за потери пакетов. Да, если это разовый случай бан обычно снимают, но проблема в том что некоторые уже успевают улететь на месяц, а скорость обработки заявок на форуме при текущей нагрузке оставляет желать лучшего.

Как по мне логичнее было бы использовать накопительную систему проверки, как это сделано во многих современных античитах, когда сервер не банит игрока моментально после одного подозрительного movement update, а какое-то время проверяет ситуацию повторно. Например если игрок оказался в воздухе без fly flags, сервер может несколько секунд продолжать проверку, действительно ли аномалия сохраняется или это просто lag/desync. Если позиция нормализовалась, suspicion сбрасывается, если нет - тогда уже накапливаются violation points. Плюс можно учитывать ping игрока и давать небольшой grace period после dismount, taxi, worldport и прочих состояний где movement packets часто рассинхронизируются.

Сейчас проблема выглядит именно как overly aggressive detection без учета реального качества соединения игрока. Особенно на 3.3.5a, где movement система сама по себе далеко не идеальна и всегда была чувствительна к packet loss и jitter. В итоге страдают обычные игроки, форум забивается заявками на разбан, а администрация тратит время на ручную проверку очевидных false positive, хотя технически это вполне решаемо даже без серьезной переработки античита.

[Bubuzyaka]

Сценарий типичный: dismount во время лагов - задержка movement packet - сервер временно видит персонажа в воздухе без fly flags - моментальный триггер. По логике детекта это корректно, но по факту это обычный desync.

Возможно, стоит рассмотреть не мгновенную реакцию на одно событие, а накопительную модель с кратковременной перепроверкой состояния. Даже 1–2 секунды дополнительноц валидации могли бы существенно сократить число false positive без ослабления реального античита.

- - - Updated - - -

В последнее время, особенно после открытия x4 и массового перехода игроков на VPN из-за проблем с провайдерами и ограничениями интернета, очень часто начали появляться ложные автобаны за flyhack. Сценарий в целом уже давно известный для TrinityCore и AzerothCore 3.3.5a, игрок летит на маунте, в момент лагов, packet loss, высокого пинга или просто кривого маршрута слезает с маунта, а сервер из-за задержки movement packet'ов еще какое-то время видит персонажа в воздухе без fly aura и сразу триггерит flyhack detection. По факту это не чит, а обычный desync из-за плохого обмена пакетами, особенно сейчас когда половина игроков сидит через VPN и нестабильные маршруты.

Самое странное в этой ситуации то, что и TrinityCore и AzerothCore уже имеют доступ к latency игрока, movement history и всей необходимой информации чтобы подобные кейсы нормально фильтровать. Сейчас античит по сути реагирует слишком агрессивно на единичное событие, из-за чего люди спокойно могут получить автобан просто из-за потери пакетов. Да, если это разовый случай бан обычно снимают, но проблема в том что некоторые уже успевают улететь на месяц, а скорость обработки заявок на форуме при текущей нагрузке оставляет желать лучшего.

Как по мне логичнее было бы использовать накопительную систему проверки, как это сделано во многих современных античитах, когда сервер не банит игрока моментально после одного подозрительного movement update, а какое-то время проверяет ситуацию повторно. Например если игрок оказался в воздухе без fly flags, сервер может несколько секунд продолжать проверку, действительно ли аномалия сохраняется или это просто lag/desync. Если позиция нормализовалась, suspicion сбрасывается, если нет - тогда уже накапливаются violation points. Плюс можно учитывать ping игрока и давать небольшой grace period после dismount, taxi, worldport и прочих состояний где movement packets часто рассинхронизируются.

Сейчас проблема выглядит именно как overly aggressive detection без учета реального качества соединения игрока. Особенно на 3.3.5a, где movement система сама по себе далеко не идеальна и всегда была чувствительна к packet loss и jitter. В итоге страдают обычные игроки, форум забивается заявками на разбан, а администрация тратит время на ручную проверку очевидных false positive, хотя технически это вполне решаемо даже без серьезной переработки античита.

Проблема выглядит как отсутствие temporal validation в flyhack check. Детект реагирует на single state violation без учёта:

latency spike
packet reordering
packet loss
недавнего state transition (dismount/taxi/worldport)

При текущих условиях сети это создаёт ложные positive на чистом movement desync