- Сообщения
- 328
- Реакции
- 93
- Помог
- 2 раз(а)
Иконка ресурса
[fork] Lite Bans 2.3
- Автор темы BlackSignature
- Дата начала
)потому-что штука прикольная Noob_with_cheats,
- Сообщения
- 328
- Реакции
- 93
- Помог
- 2 раз(а)
dimaplay, могу fork amxbans gm дать. Что-то похожее на freshbans, но не полностью.
Различные фиксы; есть offban, oldban; условное разделение на Vip, Moderator, Admin, SuperAdmin, Immunity, Steam, GsClient; Warnmenu; банить, кикать, варнить, открывать их менюшки через чат; меню подтверждения, где можно изменить выбор игрока, времени, причины и т.д.. Обновление по запросу т.к. делаю новую модульную систему, а данная пока 'затычка'.
Различные фиксы; есть offban, oldban; условное разделение на Vip, Moderator, Admin, SuperAdmin, Immunity, Steam, GsClient; Warnmenu; банить, кикать, варнить, открывать их менюшки через чат; меню подтверждения, где можно изменить выбор игрока, времени, причины и т.д.. Обновление по запросу т.к. делаю новую модульную систему, а данная пока 'затычка'.
Noob_with_cheats, fork Lite Bans 2.3 Что в ней нового?
поподробнее никак да? Сказал А, говори Б.
- Сообщения
- 1,030
- Реакции
- 826
- Помог
- 10 раз(а)
BiZaJe, в plugin_init он устанавливает кварам дефолтные значения, следом тут же идет LoadCvars который выполнится в этом же кадре, но в нем он отправляет на загрузку конфиг методом server_cmd("exec %s", szConfig); что выполнится только в следующем кадре, а в текущем кадре выполнится попытка коннекта к базе данных. В теории можем схлопотать ошибку, что коннект к базе не доступен, так-как коннект все еще будет идти на 127.0.0.1, Факт не проверен, но уверен так иногда будет случаться.
Зачем вообще проверять тут коннект к базе и фейлить(set_fail_state) целиком плагин я хз, на всю карту можно остаться без банов. Срочно нужно убирать это. К тому же можно фризнуть сервак, так-как запрос синхронный. Да и при коннекте игрока все ровно тут идет отдельный запрос, подключение-отключение коннекта. Если бд будет недоступна он так и так выбьет ошибку. Но хотя бы плагин целиком не стопорнем.
Далее в plugin_cfg он шлет запросы на получение сервака, удаление, обновление каких то данных, что значит будет задержка на получение ответа. Я не знаю, как работает модуль sql, может там несколько потоков. Но эти данные категорически должны обработаться наперед, чем игрок подключится к базе, просто на всякий случай, иначе можем сначала получить данные и забанить игрока а затем их удалить мол бан у него истекший. Факт не проверен, просто предположение.
тут же в plugin_cfg он делает LoadConfigs, как бе хер с ним, просто нарушена логика последовательности я считаю, хотя в данном этапе это не критично.
в client_putinserver он шлет отдельный запрос на каждого игрока зачем то с задержкой в 3сек, может быть, что бы избежать бага plugin_cfg когда мы сначала отправляем запросы на очистку базы. Но при выходе не вижу удаление таска - если игрок вышел еще до истечении 3сек. За это время другой игрок с этим же id может зайти и старый таск выполнится на этот же id, получим два одинаковых запроса на 1 человека. Вероятность маленькая, но она есть я считаю. Успеть выйти и подключится за 3 секунды в теории это возможно.
Когда он отправляет запрос на проверку бана, то указывает в массиве всего лишь один g_Data[1] = id; его в коллбэке и проверяет, что является ошибкой исходя из сообщения выше. Один игрок может выйти другой прийти и можно случайно забанить невиновного игрока, просто тупа из задержки запрос-время-ответ. Тут надо проверять по userid как минимум, что бы убедиться, что мы баним именно того игрока.
Пока это все, что нашел визуально.
Зачем вообще проверять тут коннект к базе и фейлить(set_fail_state) целиком плагин я хз, на всю карту можно остаться без банов. Срочно нужно убирать это. К тому же можно фризнуть сервак, так-как запрос синхронный. Да и при коннекте игрока все ровно тут идет отдельный запрос, подключение-отключение коннекта. Если бд будет недоступна он так и так выбьет ошибку. Но хотя бы плагин целиком не стопорнем.
Далее в plugin_cfg он шлет запросы на получение сервака, удаление, обновление каких то данных, что значит будет задержка на получение ответа. Я не знаю, как работает модуль sql, может там несколько потоков. Но эти данные категорически должны обработаться наперед, чем игрок подключится к базе, просто на всякий случай, иначе можем сначала получить данные и забанить игрока а затем их удалить мол бан у него истекший. Факт не проверен, просто предположение.
тут же в plugin_cfg он делает LoadConfigs, как бе хер с ним, просто нарушена логика последовательности я считаю, хотя в данном этапе это не критично.
в client_putinserver он шлет отдельный запрос на каждого игрока зачем то с задержкой в 3сек, может быть, что бы избежать бага plugin_cfg когда мы сначала отправляем запросы на очистку базы. Но при выходе не вижу удаление таска - если игрок вышел еще до истечении 3сек. За это время другой игрок с этим же id может зайти и старый таск выполнится на этот же id, получим два одинаковых запроса на 1 человека. Вероятность маленькая, но она есть я считаю. Успеть выйти и подключится за 3 секунды в теории это возможно.
Когда он отправляет запрос на проверку бана, то указывает в массиве всего лишь один g_Data[1] = id; его в коллбэке и проверяет, что является ошибкой исходя из сообщения выше. Один игрок может выйти другой прийти и можно случайно забанить невиновного игрока, просто тупа из задержки запрос-время-ответ. Тут надо проверять по userid как минимум, что бы убедиться, что мы баним именно того игрока.
Пока это все, что нашел визуально.
- Сообщения
- 313
- Реакции
- 21
- Помог
- 7 раз(а)
