Привет всем. хочу сообщить о планируемом выпуске билда античита для юзеров который будет просто и понятно показывать что было использовано в записанной демки.
принцип работы вы: запускаете античит - он записывает результат своей работы в демофайл. любой кто смотрит демку видит что нелегетимное там юзалось.
планируется включить таймскел детектор. пока ещё неяно что будет считаться разрешенным, но думаю бинд из 2 действий очень подходит под правила честной игры.
Вариант с рж скриптом ещё под вопросом, стоит ли, но раз многие рубают на онлайн серверах без него можно будет включить его в список not allowed.

Сообщение отредактировал M10_ScOut_By - 9.07.2011 - 17:09

а смысл?

Античит - это хорошо, но это очень сложно. Как, скажем, ты планируешь бороться со склеиванием прохождения из кусков и другими частными случаями генерации событий типа движения указателя и нажатия клавиш вне движка? Я, например, могу сделать себе скрипт на рдж в настройках драйвера мыши.

И да, концепция античита, требуемого при игре, не слишком удачна. Во-первых, надо поддерживать корректную работу под разными осями, во-вторых, надо заставлять игроков его использовать. К тому же, эффективные средства для извлечения действий игрока из демки уже есть, так что можно проверять прохождение на читы задним числом.

А сообщения о найденном чите прямо в демке результируют в то, что ни один читер не будет пойман, потому что не пошлёт никуда демку, по которой будет явно видно, что он читерил.

Сообщение отредактировал Nt.jud4s - 9.07.2011 - 18:39

ну тем более хорошо)

- fixed wall bug.
- checkdemo / checkdemos (шифрованы тексты, защита от склейки).
- при попытке использования скриптов, печатается script [текст скрипта] detected.
- при попытке выполнения exec, пишет execing имя_файла.cfg - т.е. это уже подозрительное действие, если выполняется в игре.
- при попытке выполнения vstr, пишет vstr [текст скрипта] detected.
- при использовании параметров info , df_chs1_info1..8 , df_chs2_info1..8 со значениями 110 или 113, происходит замена на значение 0 (сокрытие информации о FPS).
- запрещены: com_timescale и com_fixedtime, cg_drawfps.
- запрещен: com_maxfps (залочен на 118).
- запрещен: sv_fps (залочен на 125).
- запрещены: cl_yawspeed и cl_pitchspeed (залочены на 140).
- запрещены команды: centerview, +/-left, +/-right, +/-lookup, +/-lookdown.
- запрещено использование DLL, только QVM.
- запрещено колесо мыши.
- cl_freelook работает всегда, вне зависимости от значения.

вот что нас ожидает

что именно пофиксено в волбагах?
почему com_maxfps 118 а не 125 ?
Знать фпс это чит?

Как это реализовано, видимо через отдельный движок?
Что с онлайном? Почему такие ограничения связанные с фпс, может я что-то пропустил?

А тут речь не о том что читеров не будет, а о том что они будут читерить так, что этот античит их не поймает.

Менять физику это не дело, или о чём тут речь?
В общем пока всё это выглядит довольно бесполезной штукой.

Сообщение отредактировал Nt.run - 18.07.2011 - 18:37

Подозреваю, что под "воллбагом" здесь имеется в виду известнейший псевдо-баг dfengine, про который довольно много было разговоров (грубо говоря, возможность прыжков от рамп как от пола, при том эти рампы в чистом QIII якобы не позволяют такого).


Хорошая работа.

- запрещено колесо мыши.
что теперь оружие не попереключать?

Имхо, потеря времени. Единственный античит - видео из реала.

почему com_maxfps 118 а не 125 ? - подсчеты агрессора вместе с берсом.
знать фпс это не чит. а оно тебе надо?

верная мысля гдето тема была. алиен показывал

значит будем работать над этим. есть дыры будут апдейты.

Подробнее можно? Во всех модах ку3 и в QL всегда юзали 125 и тут вдруг подсчитано 118, каким образом? Не измениться ли физика. На сколько я знаю, фпс меняет физику, при чем давно пробовал, убеждался в этом.

Вдруг на карте фпс падает, я сразу увижу и уменьшу графику, Падение фпс на 10-20 глазу не заметно, но бывает не приятно сказывается, легче ориентироваться на фпс в углу экрана. Не зря же некоторые юзают отображение фпс. Если юзают значит кому-то надо, поэтому и прошу объяснить зачем его отключать.

Сообщение отредактировал uN*DeaD!HOX - 18.07.2011 - 20:59

Вот две страницы с вольным переводом статьи одного чела, который приводил математику и расчеты влияния FPS на возможный разгон и скорость.

http://forum.doom55.ru/lofiversion/index.php/t3298.html
http://www.cyberfight.ru/offline/articles/7932

Исходя из этой теории, существует несколько (набор) значений FPS оптимальных с точки зрения ускорения. Одно из этих значений - 125.
Жаль, но оригинальная статья уже недоступна, хотя там были внятные картинки и довольно понятное объяснение.

по поводу влияния фпс на физику: http://www.funender.com/quake/articles/fps.html читать всю страницу+там есть калькулятор
http://www.funender.com/quake/articles/strafing_theory.html strafe theory

Это всё относится к sv_fps, кадры отрисовки в секунду на физику не влияют, максимум что может быть от низкого значения - некоторая нестабильность в вводе, пропущенные/смазанные нажатия например - редкие фреймовые нажатия _ (+speed) в демках именно оттуда.
И да, 118 фпс работает точно так же как 125. Так почему такие ограничения?
И ещё раз повторю два вопроса, на которые не было ответа: