Просмотр полной версии : [Вопрос] Плагины
Доброе утро.
Возник вот такой вот вопрос, какие плагины стоит поставить сразу?
Те, которые нужны для работы мода? Сами по себе плагины, в большинстве своём, ничего не дают, если не использовать их функционал в коде.
Те, которые нужны для работы мода? Сами по себе плагины, в большинстве своём, ничего не дают, если не использовать их функционал в коде.
Я в том плане, вот допустим тот же Fix Timer, что-то вроде фиксов, может каких нибудь полезных функций.
Jake_Bat
10.04.2019, 14:12
Да, вопрос интересный, что стоит поставить необходимого, для нормальной работы сервера?
Даже Timer Fix - плагин сугубо индивидуальный.
Во-первых, по-настоящему точные таймеры на деле нужны лишь в малом проценте случаев, которые бы оправдали все те затраты на реализацию точности в этих самых таймерах.
Во-вторых, даже проблемы таймеров (http://wiki.pro-pawn.ru/wiki/SetTimerEx) актуальны далеко не для всех (собственно, достаточно погуглить упоминание этих проблем, чтоб убедиться, что очень мало людей сталкивались с ними).
И если плагин не будет в полную силу использоваться, он лишь в пустую будет жрать оперативу и дополнительно забивать поток, который и без того не резиновый. Конечно, один плагин ничего не забьёт и не создаст проблем. Но если так и дальше подключать плагины просто для того, чтоб они были, то часть ресурсов, которые можно было бы потратить на что-то полезное, вы будете тратить впустую. Так что я не советовал бы его ставить, если вы не нуждаетесь в точных таймерах (а если вы не понимаете в какие именно моменты они нужны, то они вам пока не нужны) или если вы не столкнулись с проблемами обычных таймеров.
Я бы лишь советовал держать в памяти существование инклуда "fixes (http://pro-pawn.ru/showthread.php?14040-fixes-inc-%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B1%D0%B0%D0%B3%D0%BE%D0%B2-SA-MP)", заранее изучив всё, что он исправляет. Вот его подключить можно. Каких-то других плагинов/инклудов посоветовать не могу.
Daniel_Cortez
11.04.2019, 19:36
Во-первых, по-настоящему точные таймеры на деле нужны лишь в малом проценте случаев, которые бы оправдали все те затраты на реализацию точности в этих самых таймерах.
А с чего ты взял, что там есть какие-то дополнительные "затраты"? Насколько знаю, в плагине не используются какие-то сложные или высокоточные расчёты. Просто принцип подсчёта времени следующего срабатывания не такой ущербный, как в SA-MP.
Во-вторых, даже проблемы таймеров (http://wiki.pro-pawn.ru/wiki/SetTimerEx) актуальны далеко не для всех (собственно, достаточно погуглить упоминание этих проблем, чтоб убедиться, что очень мало людей сталкивались с ними).
Частота упоминаний проблемы - отнюдь не показатель. Вот ты сам веришь, что кто-то хотя бы подумает про таймеры, возникни у них проблема с исчерпанием памяти? Я как-то в этом очень сомневаюсь.
И если плагин не будет в полную силу использоваться, он лишь в пустую будет жрать оперативу и дополнительно забивать поток, который и без того не резиновый.
По поводу "забивания потоков" - см. ответ на 1-ю цитату. Касаемо оперативы - плагин не сильно сложный и едва ли его можно назвать требовательным. Мало того, со стандартных таймеров может утечь куда больше памяти (не говоря уже о том, что это потребует проводить время от времени рестарт сервера, дабы перестраховаться от исчерпания памяти).
Я бы лишь советовал держать в памяти существование инклуда "fixes (http://pro-pawn.ru/showthread.php?14040-fixes-inc-%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B1%D0%B0%D0%B3%D0%BE%D0%B2-SA-MP)", заранее изучив всё, что он исправляет. Вот его подключить можно.
Так TimerFix к той же категории фиксов и относится (даже API не какой-то свой, а полностью совместимый со стандартным - подключил и забыл), разве нет?
А с чего ты взял, что там есть какие-то дополнительные "затраты"? Насколько знаю, в плагине не используются какие-то сложные или высокоточные расчёты. Просто принцип подсчёта времени следующего срабатывания не такой ущербный, как в SA-MP.
Так я и не говорил про сложные расчёты. Речь о том, что плагин в любом случае будет жрать ресурсы, а не о том, что он будет жрать их неоправданно много. Как по мне, странно растрачивать какие-либо ресурсы на то, что никакой фактической пользы приносить не будет. А уж если однажды появится нужда в точных таймерах или баги сампа дадут о себе знать - подключить плагин не составит труда.
Частота упоминаний проблемы - отнюдь не показатель. Вот ты сам веришь, что кто-то хотя бы подумает про таймеры, возникни у них проблема с исчерпанием памяти? Я как-то в этом очень сомневаюсь.
Да даже если загуглить темы с крашами сервера, всё равно упоминаний проблем с таймерами практически не найдёшь (если вообще найдёшь). Не думаешь же ты, что те, кто сталкивался с крашами из-за таймеров, просто не могли определить причину и забрасывали разработку поголовно. Уж за 10+ лет эта проблема явно всплыла бы, если бы была такой актуальной. Это явно не баг последних версий SA-MP.
Да и я опираюсь больше на свой опыт работы на разные проекты + на опыт помощи людям с решением разнообразных проблем. И проблемы с таймерами встречал только в синтетических тестах, специально создавая кучу таймеров и пытаясь посмотреть как они себя поведут при исчерпании лимита ID таймеров. Сейчас, например, уже второй год работаю над модом проекта с онлайном 300+, у которых мод, мягко говоря, не самый хороший, но даже в том случае нет никаких проблем с таймерами, хоть используются они там во многих системах. И в прошлом таких проектов было не меньше.
По поводу "забивания потоков" - см. ответ на 1-ю цитату. Касаемо оперативы - плагин не сильно сложный и едва ли его можно назвать требовательным. Мало того, со стандартных таймеров может утечь куда больше памяти (не говоря уже о том, что это потребует проводить время от времени рестарт сервера, дабы перестраховаться от исчерпания памяти).
Так TimerFix к той же категории фиксов и относится (даже API не какой-то свой, а полностью совместимый со стандартным - подключил и забыл), разве нет?
Собственно, выше я ответил. Имхо, но в данном случае это попытка исправить ещё не существующую проблему. Как выше писал, с учётом того, что для применения фиксов достаточно подключить плагин, не вижу какого-либо смысла держать его без явных на то причин.
Daniel_Cortez
11.04.2019, 22:42
Так я и не говорил про сложные расчёты. Речь о том, что плагин в любом случае будет жрать ресурсы, а не о том, что он будет жрать их неоправданно много. Как по мне, странно растрачивать какие-либо ресурсы на то, что никакой фактической пользы приносить не будет.
В плане ресурсов CPU - плагин тратит на обработку таймеров те такты, которые не тратит сервер на обновление стандартных таймеров. Логично же, нет?
Про потребление оперативы, повторюсь, плагин не сильно сложен. Что может занимать много места - так это стандартная библиотека C/C++, но она используется и другими плагинами, т.е. по идее должна быть для них общей.
Вообще слово "жрать" - это точно не про TimerFix. К примеру, в тех же стандартных таймерах под название вызываемой функции отводится массив на 255 символов, в то время как достаточно всего 32 - вот к такого вида расточительству слово "жрать" применимо.
Да даже если загуглить темы с крашами сервера, всё равно упоминаний проблем с таймерами практически не найдёшь (если вообще найдёшь).
Опять же, как люди вообще должны понять, что это связано именно с таймерами? Речь не конкретно о тебе, а о других скриптерах, которые не читают Pro-Pawn Wiki и едва ли знают о наличии утечек в таймерах :)
Краш возникает при длительной работе сервера при абсолютно рандомных условиях. Единтственная мизерная зацепка, которая может помочь - это если в логах окажется адрес SetTimer/SetTimerEx, но это ещё если у сервера ещё хватит памяти под составление лога. Да и сам по себе адрес SetTimer говорит только о том, что в этой функции провалилась аллокация, но не о том, что это источник утечки памяти - это просто совпадение, которое может натолкнуть на мысль (если скриптер в курсе про утечки в таймерах - иначе и это может показаться случайностью, не связанной с крашем напрямую).
ИМХО, владелец сервера, скорее, просто забьёт на эту проблему (возможно, ассоциировав её с каким-то сложным/требовательным к памяти плагином) и по возможности сделает автоматический перезапуск сервера при падении, если такового ещё нет.
Собственно, выше я ответил. Имхо, но в данном случае это попытка исправить ещё не существующую проблему.
В разработке неточность в работе чего-либо и уж тем более потенциал для краша обычно считаются проблемами, которые стоит если не исправлять, то хотя бы искать обходные решения и хоть как-то подстраховываться. Но то такое. Не впервой приходится замечать, что в сообществе SA-MP любая "несмертельная" проблема воспринимается как норма.
В любом случае, если сама по себе неточность таймеров для тебя по умолчанию не проблема - это ещё не значит, что это не проблема для других, кто читает эту тему. Собственно, из-за этого я и начал сие обсуждение.
Ну если сама по себе неточность таймеров для тебя по умолчанию не проблема - это ещё не значит, что это не проблема для других, кто читает эту тему. Собственно, из-за этого я и начал сие обсуждение.
Таки я ещё во втором своём сообщении написал, что Timer Fix есть смысл ставить только если нужны точные таймеры или если баги сампа, связанные с таймерами, дали о себе знать :) Я не отрицаю, что кому-то это может быть полезным. Я сам использовал этот плагин для реализации нескольких заказов. Но в теме-то речь о списке обязательных для установки плагинов. И мой основной посыл в том, что если нет конкретной востребованности в функционале плагина, то и особого смысла в его установке нет.
Касаемо твоего обсуждения по поводу потребления ресурсов. Опять же, я нигде не утверждал, что плагин потребляет слишком много ресурсов. Основная мысль в моих сообщениях - зачем выделять ресурсы на то, от чего профита никакого нет?
Касаемо отслеживания причин - опять же, речь о том, что на деле проблема таймеров крайне не актуальна.
Если бы проблема действительно была актуальна, то мы бы, с учётом количества серверов и постоянного притока новых скриптеров, хоть раз в месяц видели на форумах людей, сообщающих о непонятных крашах сервера. Но таких людей даже за год не особо-то и появляется, хотя люди, как видно, и с более простыми проблемами предпочитают бежать на форум, даже если о том, как исправить ошибку, написано в самом сообщении ошибки. Поэтому глупо, спустя 13 лет существования SA-MP, вдруг бить тревогу о том, что таймеры способны создать утечку памяти при определённых обстоятельствах, делая из этого какую-то невероятно актуальную проблему, которая обязательно коснётся каждого. Время уже показало, что не коснётся. Собственно, сам помнишь как мы с тобой узнали об этой проблеме.
Да и ты говоришь про тех, кто "не читает Pro-Pawn Wiki и едва ли знает о наличии утечек в таймерах". Эти люди вряд ли и о существовании Timer Fix знают :) И даже если мы сейчас каким-то образом заставим всех посетителей данного форума поставить себе данный плагин, вряд ли те, о ком ты говоришь, узнают про утечки или про плагин.
Ну и, опять же, подытожу то, что я не призываю всех отказываться от данного плагина и не говорю, что он потребляет слишком много ресурсов. Мой основной посыл в том, что точные таймеры нужны далеко не всегда, а проблемы стандартных таймеров довольно специфичны (а я напомню, что речь в данной теме о том, какие плагины нужно обязательно ставить). И ставить плагин стоит только тогда, когда вам нужно реализовать систему, которая так или иначе будет упираться в проблемы стандартных таймеров (http://wiki.pro-pawn.ru/wiki/SetTimerEx) (неточность/утечки памяти). В противном случае от того, что вы поставите плагин на сервер, никакого профита вы не получите, но определённую часть ресурсов плагин всё же сожрёт. Да, будет затрачено несущественное количество ресурсов, но эти ресурсы всё равно будут потрачены впустую и могли бы быть потрачены на что-то более полезное. Такой подход безосновательной растраты ресурсов рано или поздно приведёт к тому, что все эти незначительные растраты в совокупности станут очень заметны... Но это уже лирика.
В общем, я лишь советую решать проблемы по мере их поступления, а не бороться с ветряными мельницами.
Daniel_Cortez
12.04.2019, 20:01
Но в теме-то речь о списке обязательных для установки плагинов.
Странно, я думал, что спрашивали о плагинах и фиксах, "необходимых для нормальной работы" и о TimerFix в частности.
Да, вопрос интересный, что стоит поставить необходимого, для нормальной работы сервера?
Я в том плане, вот допустим тот же Fix Timer, что-то вроде фиксов, может каких нибудь полезных функций.
И, к слову, если стандартные таймеры срабатывают не через то время, что указал пользователь, а через то, которое вздумается серверу - ИМХО, сложно назвать это "нормальной работой", особенно когда за каждые 60 секунд накапливается ~10(!) секунд погрешности.
#include <a_samp>
const TIMER_INTERVAL = 1000;
new next_time;
public TimerFunc();
public TimerFunc()
{
new t = GetTickCount();
next_time += TIMER_INTERVAL;
printf("Time: %12d\tExpected: %12d\tDifference: %d", t, next_time, t - next_time);
}
main()
{
next_time = GetTickCount();
SetTimer("TimerFunc", TIMER_INTERVAL, 1);
}
http://ihost.pro-pawn.ru/image.php?di=Q5LZ
Нет, ну может быть по меркам SA-MP это нормально (может быть даже слишком хорошо) на фоне десятков других багов, но с точки зрения здравого смысла - едва ли.
Справедливости ради, в TimerFix тоже аккумулируется погрешность, но для плагина она гораздо меньше (у меня получилось всего ~200 мс на минуту), и полностью отсутствуют отклонение только в fixes2 (вернее, оно варьируется в пределах ~20 мс, но не накапливается при каждом срабатывании таймера).
Странно, я думал, что спрашивали о плагинах и фиксах, "необходимых для нормальной работы" и о TimerFix в частности.
Ну а разве "необходимые" это не то же, что и "обязательные"?) Обязательность для установки и подразумевает, что без плагинов/фисков сервер не будет нормально работать.
Да и речь о том, что даже практика большинства работающих серверов показывает, что TimerFix не обязателен "для нормальной работы". Проблем с таймерами ещё нужно постараться добиться, о чём я писал в предыдущих сообщениях.
Касаемо погрешности - 99% всех систем, требующих той или иной точности, реализуются через таймер с маленьким промежутком срабатывания (секундный таймер, например) + gettime. Очень редки системы, в которых даже минутная погрешность будет существенно влиять на игру. Как, собственно, редки таймеры, частота обновлений которых больше минуты (обычно подобные вещи как раз через секундный таймер+gettime и реализуют, ибо можно легко настроить то, в какую именно минуту часа должна срабатывать та или иная система. Что, например, хорошо для всяких оповещений, которые с обычным таймером могут сработать в одно время и зафлудить чат).
В общем, как я уже которое сообщение говорю - TimerFix не является каким-то обязательным плагином, не установив который вы обязательно столкнётесь с какими-либо проблемами. Он призван решить конкретные проблемы и, как по мне, смысл его ставить есть только тогда, когда вы с этими проблемами встречаетесь, а не пытаться решить проблему, которой ещё нет. Особенно с учётом того, что для применения плагина достаточно просто его подключить. Даже код переписывать не придётся.
Daniel_Cortez
13.04.2019, 16:36
Проблем с таймерами ещё нужно постараться добиться, о чём я писал в предыдущих сообщениях.
Для некритичных задач, как к примеру, обновление ТД - да, это будет незаметно. Если же потребуется, к примеру, сделать таймер на mute/unmute в чате для игрока, обойтись простым декрементом счётчика секунд в таймерной функции уже не выйдет (нет, при желании, конечно, можно, но время будет отсчитываться дольше задуманного), для точности придётся впихивать лишний вызов gettime().
Касаемо погрешности - 99% всех систем, требующих той или иной точности, реализуются через таймер с маленьким промежутком срабатывания (секундный таймер, например) + gettime.
Собственно, как я и упомянул выше, это всего лишь способ обхода проблемы, который совсем не факт что проще обычного декремента переменной, как в упомянутом выше примере.
Хотя стоит признать, когда привыкаешь не полагаться на точность таймеров (или даже учишься этому по чужому коду с самого начала, не зная альтернативы) и считаешь костыль нормой, то перестаёшь и осознавать, что это проблема и что без бага можно было написать код проще. Поэтому нет абсолютно ничего удивительного в том, что никто не жалуется на неточные таймеры.
Как, собственно, редки таймеры, частота обновлений которых больше минуты (обычно подобные вещи как раз через секундный таймер+gettime и реализуют, ибо можно легко настроить то, в какую именно минуту часа должна срабатывать та или иная система. Что, например, хорошо для всяких оповещений, которые с обычным таймером могут сработать в одно время и зафлудить чат)
Это уже немного другая проблема, хотя и её, по идее, можно решить без gettime(), с помощью доп. функций, предоставляемых в fixes2, указав в таймере время до первого срабатывания и интервал по отдельности.
native SetTimer_(const func[], const delay, const interval, const count);
native SetTimerEx_(const func[], const delay, const interval, const count, const format[], {Float, _}:...);
В общем, как я уже которое сообщение говорю - TimerFix не является каким-то обязательным плагином, не установив который вы обязательно столкнётесь с какими-либо проблемами.
Во-первых, нельзя внезапно "столкнуться" с проблемой, с которой уже живёшь с самого начала и которую привык не замечать.
Во-вторых, я разве где-то говорил, что TimerFix - это обязательный плагин? Многие баги можно обойти, в том числе и в таймерах.
Кстати про TimerFix,
Я в том плане, вот допустим тот же Fix Timer, что-то вроде фиксов, может каких нибудь полезных функций.
Я бы скорее посоветовал fixes2 - в этом плагине тоже реализованы точные таймеры. В отличие от TimerFix, он больше проверен временем и не подвержен накоплению погрешностей при каждом срабатывании таймера, не говоря уже о доп. функциях (см. цитатой выше).
Спасибо большое за ответы, очень кстати.
Для некритичных задач, как к примеру, обновление ТД - да, это будет незаметно. Если же потребуется, к примеру, сделать таймер на mute/unmute в чате для игрока, обойтись простым декрементом счётчика секунд в таймерной функции уже не выйдет (нет, при желании, конечно, можно, но время будет отсчитываться дольше задуманного), для точности придётся впихивать лишний вызов gettime().
Мут игрока давно делают через запись "gettime()+время_мута" и сверкой этих значений везде, где нужно запретить использовать код игроку с мутом.
В остальных случаях (тюрьма и т.п.) используется либо такая же схема, как с мутом, либо секундный таймер и вычитание единицы из переменной, хранящей количество секунд, которое нужно отсчитать, либо секундный таймер+метод с мутом, только проверка уже в самом таймере. Таймерами никто не выдаёт подобные вещи, как минимум, потому что игроку как-то нужно сообщать сколько времени осталось до конца.
А даже если бы и выдавали, игрок особо не заметит разницы даже в +40 секунд (которые обычно набегают только для таймеров с совсем уж большими интервалами, равными десяткам минут или даже часам).
Собственно, как я и упомянул выше, это всего лишь способ обхода проблемы, который совсем не факт что проще обычного декремента переменной, как в упомянутом выше примере.
Хотя стоит признать, когда привыкаешь не полагаться на точность таймеров (или даже учишься этому по чужому коду с самого начала, не зная альтернативы) и считаешь костыль нормой, то перестаёшь и осознавать, что это проблема и что без бага можно было написать код проще. Поэтому нет абсолютно ничего удивительного в том, что никто не жалуется на неточные таймеры.
Нет, это просто приемлемая реализация, ибо в большинстве случаев даже самая большая погрешность таймеров не сыграет большой роли на фоне того, что SA-MP сам по себе имеет кучу проблем с производительностью и синхронизацией. Даже если игроки заметят задержку, для них это будет очередной лёгкий лаг сервера, коих в SA-MP полно при большом онлайне даже без участия какого-то дополнительного кода. Не говоря уже о том, что многие игроки играют на компьютерах, которые редко и 30 FPS в GTA выдают стабильно.
Да и, как ниже будет подмечено мной, есть многие системы, для которых подобная реализация либо создаёт дополнительные удобства при поддержке кода, либо вообще необходима.
Это уже немного другая проблема, хотя и её, кстати, можно решить без gettime(), с помощью доп. функций, предоставляемых в fixes2, указав в таймере время до первого срабатывания и интервал по отдельности.
native SetTimer_(const func[], const delay, const interval, const count);
native SetTimerEx_(const func[], const delay, const interval, const count, const format[], {Float, _}:...);
И потом высматривать все таймеры, выискивая когда же появляется свободное окно, в котором можно будет воспроизвести тот или иной код, вместо того, чтоб иметь один простой switch с поминутным разделением вызовов функций с нужным кодом.
И я напомню, что без gettime не обойтись в таймере, ибо есть много систем, требующих обработки кода в конкретное время, а не через конкретный интервал (тот же PayDay).
Во-первых, нельзя внезапно "столкнуться" с проблемой, с которой уже живёшь с самого начала и которую привык не замечать.
Опять же, ты сейчас намеренно преувеличиваешь :) Ты почему-то забываешь о том, что вообще такое SA-MP и как он работает. Даже задержки в 25%, которых получится добиться, разве что, делая таймеры по часу, на фоне общей нестабильности будут выглядеть вполне естественно со стороны игроков. Так какая же это тогда проблема, если никакого негатива в большинстве случаев она не создаёт?
Первые фиксы таймеров, призванные сократить задержку, создавались исключительно для реализации конкретных систем, требующих максимальной точности. А в оставшемся большинстве систем эта точность никак на игру ровным счётом не повлияет и игроки ощутимой разницы не заметят.
Во-вторых, я разве где-то говорил, что TimerFix - это обязательный плагин? Многие баги можно обойти, в том числе и в таймерах.
То ты говоришь, что мы тут обсуждаем плагины, которые "необходимых для нормальной работы и о TimerFix в частности", то теперь TimerFix не обязателен.
Если он не обязателен, то к чему весь этот диалог? Повторюсь в очередной раз: я нигде не призывал всецело отказываться от этого плагина. Я лишь говорил, что он не решает каких-то актуальных проблем, которые коснуться обязательно каждого. И говорил, что использовать его есть смысл только тогда, когда "баги таймеров" коснуться лично вас.
То бишь, то же самое, что и говоришь ты (только я более трезво смотрю на проблему таймеров).
UPD: Ах да, так же хочу заострить внимание на том, что в реальности все твои аргументы насчёт задержек не работают, ибо эти задержки просто не заметны из игры. Даже для таймеров без gettime и прочих ухищрений. Просто потому что игроки не сидят с секундомерами и не замеряют то, как точно в пиратском мультиплеере, собранном на коленке, срабатывают те или иные действия. Перфекционизм, конечно, можно подключить, но проку от него не будет ровным счётом никакого (наоборот мы лишь часть ресурсов сольём в трубу), ибо игра не начнёт вдруг в 7 раз быстрее работать и тот же пинг, из-за которого происходит большая часть задержек в игре, вдруг не исчезнет.
Daniel_Cortez
13.04.2019, 20:04
Мут игрока давно делают через запись "gettime()+время_мута" и сверкой этих значений везде, где нужно запретить использовать код игроку с мутом.
В остальных случаях (тюрьма и т.п.) используется либо такая же схема, как с мутом, либо секундный таймер и вычитание единицы из переменной, хранящей количество секунд, которое нужно отсчитать, либо секундный таймер+метод с мутом, только проверка уже в самом таймере. Таймерами никто не выдаёт подобные вещи, как минимум, потому что игроку как-то нужно сообщать сколько времени осталось до конца.
А даже если бы и выдавали, игрок особо не заметит разницы даже в +40 секунд (которые обычно набегают только для таймеров с совсем уж большими интервалами, равными десяткам минут или даже часам).
Да, уже вспомнил. Возможно, начинать писать ответ в 3 часа ночи было не самой лучшей идеей :)
Нет, это просто приемлемая реализация, ибо в большинстве случаев даже самая большая погрешность таймеров не сыграет большой роли на фоне того, что SA-MP сам по себе имеет кучу проблем с производительностью и синхронизацией. Даже если игроки заметят задержку, для них это будет очередной лёгкий лаг сервера, коих в SA-MP полно при большом онлайне даже без участия какого-то дополнительного кода. Не говоря уже о том, что многие игроки играют на компьютерах, которые редко и 30 FPS в GTA выдают стабильно.
Обилие других проблем - такое себе оправдание, на самом деле...
Да и, как ниже будет подмечено мной, есть многие системы, для которых подобная реализация либо создаёт дополнительные удобства при поддержке кода, либо вообще необходима.
Так я разве говорил, что подход с gettime() во всех случаях плох? Наоборот, в предыдущем посте я отмечал, что в отдельных кейсах этот подход как раз таки нужен (но не во всех).
И потом высматривать все таймеры, выискивая когда же появляется свободное окно, в котором можно будет воспроизвести тот или иной код, вместо того, чтоб иметь один простой switch с поминутным разделением вызовов функций с нужным кодом.
Завести константы под временные смещения (или даже enum, чтобы присваивать значения автоматически), которые потом указывать при создании таймеров (в варианте из fixes2) - не вариант?
И я напомню, что без gettime не обойтись в таймере, ибо есть много систем, требующих обработки кода в конкретное время, а не через конкретный интервал (тот же PayDay).
При запуске сервера рассчитать время до следующего payday и его указать при создании таймера. Дальше в таймерной функции вызов gettime() по идее должен быть необходим только если нужно рассчитать ещё какой-то временной промежуток.
Опять же, ты сейчас намеренно преувеличиваешь :) Ты почему-то забываешь о том, что вообще такое SA-MP и как он работает. Даже задержки в 25%, которых получится добиться, разве что, делая таймеры по часу, на фоне общей нестабильности будут выглядеть вполне естественно со стороны игроков.
Не факт. Если посадить игрока в тюрьму на час (полагаясь именно на таймеры, без gettime()), он может посмотреть на время и отойти от ПК по своим делам примерно на час, а как вернётся - сюрприз, откуда ни возьмись, ещё 10 минут, что, естественно, вызовет недовольство у игрока. Сужу по собственному игровому опыту восьмилетней давности, когда приходилось и самому натыкаться на несоответствии времени в тюрьме, и слышать жалобы на это от других игроков.
То ты говоришь, что мы тут обсуждаем плагины, которые "необходимых для нормальной работы и о TimerFix в частности", то теперь TimerFix не обязателен.
Не вижу в этом никакого противоречия. Все перечисленные в этой теме фиксы в принципе не обязательны и не факт, что скриптер может наткнуться на исправляемые ими проблемы.
Если он не обязателен, то к чему весь этот диалог?
Изначально претензия была к тому, что ты рекомендуешь fixes.inc, но не согласен с актуальностью TimerFix, после чего из поста в пост копились и другие вопросы. И, как видишь, даже сейчас остаются вопросы, на которые хотелось бы услышать твоё или чьё-либо ещё мнение (если кто-то ещё пожелает ответить).
Я лишь говорил, что он не решает каких-то актуальных проблем, которые коснуться обязательно каждого.
Как вариант, владелец сервера или скриптер может и не знать о наличии той или иной проблемы (как в приведённом мной выше примере с тюрьмой), но сама проблема от этого никуда не пропадёт :)
Повторюсь, мой посыл в том, что цель использования TimerFix или fixes2 не столько решить существующие проблемы, сколько перестраховаться от возможных проблем в будущем, о которых потом можешь и не узнать.
Обилие других проблем - такое себе оправдание, на самом деле...
Это не оправдание, а принятие реальности :) С тем же успехом ты можешь уйти сейчас в лес и начать строить там убежище на случай нападения динозавров. А что, ведь факт того, что динозавры вымерли - такое себе оправдание. Надо заранее просчитывать все варианты, независимо от их актуальности!
Завести константы под временные смещения (или даже enum, чтобы присваивать значения автоматически), которые потом указывать при создании таймеров (в варианте из fixes2) - не вариант?
А в чём существенное отличие, если у нас уже есть секундный таймер, в котором в любом случае будет вызов gettime и сверка минут? Зачем забивать оперативу дополнительными таймерами?
Ты предлагаешь шило на мыло поменять)
При запуске сервера рассчитать время до следующего payday и его указать при создании таймера. Дальше в таймерной функции вызов gettime() по идее должен быть необходим только если нужно рассчитать ещё какой-то временной промежуток.
И вместо одного таймера + gettime, данные которой будут использоваться в куче других случаев (даже не связанных с вызовом кода в определённое время. Например, gettime пригодится для текстдрава часов), ты создашь кучу отдельных таймеров, продумав для них альтернативную реализацию всего того, что решалось через switch и, в итоге, лишь усложнив код + выделив лишнюю оперативную память.
Собственно, главный вопрос, который я задаю уже который пост подряд: зачем? Зачем, если и без того всё работает вполне нормально?
Не факт. Если посадить игрока в тюрьму на час (полагаясь именно на таймеры, без gettime()), он может посмотреть на время и отойти от ПК по своим делам примерно на час, а как вернётся - сюрприз, откуда ни возьмись, ещё 10 минут, что, естественно, вызовет недовольство у игрока. Сужу по собственному игровому опыту восьмилетней давности, когда приходилось и самому натыкаться на несоответствии времени в тюрьме, и слышать жалобы на это от других игроков.
Почему ты опять используешь такие нерелевантные примеры? Никто в здравом уме не будет делать какое-либо наказание или любое подобное действие на таймерах (даже сверхточных), ибо, как минимум, нужно иметь возможность сообщать игроку то, сколько времени осталось до окончания отсчёта. Можно, конечно, сейчас найти или написать плагин, который не только таймеры будет создавать, но и возвращать остаток времени до следующего срабатывания, но зачем, когда есть более простой и проверенный временем вариант?
Да и нужно так же вспомнить о том, что то же время наказания в тюрьме нужно сохранять на случай выхода. Даже если реализовывать всё через таймер с возможностью просмотра остатка времени, получится ненужное дублирование информации, ибо эту самую информацию нужно где-то хранить до создания таймера. Хотя, опять же, можно и тут извратиться, сделав работоспособную систему, но зачем всё усложнять, если всё и так работает хорошо?
Вся эта ситуация похожа на ситуацию оптимизаторов, которые задрачивают на миллисекунды, прогоняя код, который будет раз в десяток минут вызываться, через цикл на миллиарды итераций. Что в том случае от такой оптимизации игровой процесс никак не изменится, что в этом. Собственно, как и какая-либо нагрузка на сервер (скорее, наоборот мы потреяем больше оперативы на дополнительные таймеры для разных действий, которые раньше либо вообще без таймеров обходились, либо срабатывали через switch, на вызов которого уходило мизерное количество времени).
Не вижу в этом никакого противоречия. Все перечисленные в этой теме фиксы в принципе не обязательны и не факт, что скриптер может наткнуться на исправляемые ими проблемы.
Ну а теперь возвращаемся к вопросу автора темы и видим, что он спрашивает какие плагины стоит ставить сразу (то бишь, обязательно). А потом находим моё первое сообщение в этой теме и видим ответ: нет обязательных плагинов, ибо всё нужно использовать по случаю. Потом видим как автор темы упоминает TimerFix, а я отвечаю, что и этот плагин далеко не обязателен, а решает конкретные задачи. Собственно, ты сейчас говоришь то же самое :)
Изначально претензия была к тому, что ты рекомендуешь fixes.inc, но не согласен с актуальностью TimerFix, после чего из поста в пост копились и другие вопросы. И, как видишь, даже сейчас остаются вопросы, на которые хотелось бы услышать твоё или чьё-либо ещё мнение (если кто-то ещё пожелает ответить).
Я изначально и насчёт fixes.inc хотел сказать, что его просто стоит держать у себя в памяти и знать какие баги он правит, дабы использовать его для исправления этих багов, когда понадобиться. Но если fixes.inc во многих случаях решает действительно актуальные проблемы (например, правит кривости синхронизации во время смерти в разных случаях и т.п.), с которыми практически каждый скриптер сталкивается, кто хотя бы пытался писать мод с нуля, то в случае с TimerFix ситуация совершенно противоположная.
Ну и ещё я был уверен, что если против fixes.inc что-то скажу, то кто-то обязательно влезет в полемику на этот счёт, чего я не хотел. Но прилетело оттуда, откуда не ждали (со стороны TimerFix) :D
Собственно, я ещё в первом своём сообщении в этой теме озвучил свою позицию - любые сторонние разработки нужно применять только тогда, когда требуется функционал этих разработок. Не существует каких-то обязательных плагинов, без которых сервер не сможет существовать.
Как вариант, владелец сервера или скриптер может и не знать о наличии той или иной проблемы (как в приведённом мной выше примере с тюрьмой), но сама проблема от этого никуда не пропадёт :)
Повторюсь, мой посыл в том, что цель использования TimerFix или fixes2 не столько решить существующие проблемы, сколько перестраховаться от возможных проблем в будущем, о которых потом можешь и не узнать.
Опять же, если ты посмотришь на описание всех этих плагинов, то авторы не пишут там о каких-то утечках памяти или чём-то ещё, что было найдено тобой для wiki. Речь идёт о решении вполне известных проблем с неточностью таймеров. И логично, что актуальна она только для тех, кому эта самая неточность создаёт проблемы (ну или тех, кто столкнётся с утечкой памяти). Правильнее будет рассказать людям о существующих проблемах и учить эти проблемы определять, а не пытаться втюхать им исправление на все случаи жизни. Ибо всё равно все проблемы не решить заранее, а количество серверных ресурсов ограничено.
UPD: В общем, как я вижу, мы уже сошлись во мнении о том, что TimerFix - это далеко не обязательный, хоть и полезный плагин. Предлагаю вопрос с важностью этого плагина закрыть и озвучить лишь те вопросы, которые тебя интересуют, дабы не разводить ещё больший разговор об одном и том же)
Daniel_Cortez
14.04.2019, 03:21
С тем же успехом ты можешь уйти сейчас в лес и начать строить там убежище на случай нападения динозавров. А что, ведь факт того, что динозавры вымерли - такое себе оправдание. Надо заранее просчитывать все варианты, независимо от их актуальности!
И снова в ход идут откровенно преувеличенные аналогии, причём преувеличенные на грани вырывания из контекста. В который раз приходится повторять, что установка fixes2 или TimerFix - это не что-то сложное и сверхзатратное, это делается буквально за минуту.
И вместо одного таймера + gettime, данные которой будут использоваться в куче других случаев (даже не связанных с вызовом кода в определённое время. Например, gettime пригодится для текстдрава часов), ты создашь кучу отдельных таймеров, продумав для них альтернативную реализацию всего того, что решалось через switch и, в итоге, лишь усложнив код + выделив лишнюю оперативную память.
Собственно, главный вопрос, который я задаю уже который пост подряд: зачем? Зачем, если и без того всё работает вполне нормально?
Я где-то говорил, что нужно менять и без того рабочий код? Нет, это, как минимум, нецелесообразно. Тот подход, который я предлагаю, есть смысл использовать в моде с 0, но никак не комбинировать с применением другого, более распространённого подхода. И, касаемо текстдрава часов, повторюсь, что да, для отдельных случаев gettime() тоже понадобится.
Почему ты опять используешь такие нерелевантные примеры? Никто в здравом уме не будет делать какое-либо наказание или любое подобное действие на таймерах (даже сверхточных), ибо, как минимум, нужно иметь возможность сообщать игроку то, сколько времени осталось до окончания отсчёта.
А с чего ты решил, что это должен быть таймер с периодом именно на час? Речь была об односекундном таймере (сам в этом удостоверился, копаясь в паблик-моде, который, как оказалось, и послужил основой для того сервера), в котором, среди других задач, производился декремент переменной-счётчика (вернее, элементов массива), если она не равна нулю. Как следствие, можно было узнать время до выхода на свободу, это время сохранялось при перезаходе на сервер, но присутствовала свойственная всем таймерам погрешность, на которую жаловались игроки в описанном мной случае. Что в этом "не релевантного"?
Вся эта ситуация похожа на ситуацию оптимизаторов, которые задрачивают на миллисекунды, прогоняя код, который будет раз в десяток минут вызываться, через цикл на миллиарды итераций. Что в том случае от такой оптимизации игровой процесс никак не изменится, что в этом. Собственно, как и какая-либо нагрузка на сервер (скорее, наоборот мы потреяем больше оперативы на дополнительные таймеры для разных действий, которые раньше либо вообще без таймеров обходились, либо срабатывали через switch, на вызов которого уходило мизерное количество времени).
Примерно то же самое можно сказать про твой взгляд относительно "отжирания ресурсов": при нормальной своей реализации таймеры настолько легковесны, что их ничтожно малой нагрузкой (как на ЦП, так и по потреблению памяти) можно приберечь и сконцентрироваться на том подходе, который в первую очередь удобен тебе самому.
Ну а теперь возвращаемся к вопросу автора темы и видим, что он спрашивает какие плагины стоит ставить сразу (то бишь, обязательно). А потом находим моё первое сообщение в этой теме и видим ответ: нет обязательных плагинов, ибо всё нужно использовать по случаю. Потом видим как автор темы упоминает TimerFix, а я отвечаю, что и этот плагин далеко не обязателен, а решает конкретные задачи. Собственно, ты сейчас говоришь то же самое :)
Раз так, то, скорее всего, это было банальное недопонимание с моей стороны, каюсь :)
В любом случае, я не жалею об участии в сей дискуссии, ибо подвернулся замечательный повод получше изучить, что находится "под капотом" у таймеров (как стандартных, так и из сторонних реализаций) и причины, почему таймеры в SA-MP - отстой. При желании материала может на целый урок хватить.
Опять же, если ты посмотришь на описание всех этих плагинов, то авторы не пишут там о каких-то утечках памяти или чём-то ещё, что было найдено тобой для wiki.
Так я и не раз упоминал, что краша ещё нужно добиться - т.е. создавать много таймеров, для чего, скорее всего, понадобится много игроков и значительное время без рестарта мода. Либо в SetTimer(Ex) использовать спецификаторы "a" или "s" - тогда смерть будет быстрой :) Но похоже, что, к счастью, ими никто и не пользуется, раз нет жалоб.
UPD: В общем, как я вижу, мы уже сошлись во мнении о том, что TimerFix - это далеко не обязательный, хоть и полезный плагин. Предлагаю вопрос с важностью этого плагина закрыть и озвучить лишь те вопросы, которые тебя интересуют, дабы не разводить ещё больший разговор об одном и том же)
Согласен, хотя вполне возможно, что есть смысл создать список инклудов и плагинов из разряда "must have", по возможности с обоснованием их выбора (по крайней мере, судя по вопросам в этой теме, для подобного списка должен быть спрос). Впрочем, это уже тема для отдельного обсуждения.
И снова в ход идут откровенно преувеличенные аналогии, причём преувеличенные на грани вырывания из контекста.
Она такая преднамеренно, ибо я уже которое сообщение подряд пытался донести одну и ту же мысль, а ты отвечал на это одним и тем же образом :) Уже не знаю как ещё донести то, что с проблемой таймеров никто осознанно не сталкивается из тех, кому не требуются точные таймеры.
В который раз приходится повторять, что установка fixes2 или TimerFix - это не что-то сложное и сверхзатратное, это делается буквально за минуту.
И смысла в этом тоже никакого нет, если тебе не требуются точные таймеры или у тебя нет проблем с крашами от переполнения, о чём я уже не раз говорил.
А с чего ты решил, что это должен быть таймер с периодом именно на час? Речь была об односекундном таймере (сам в этом удостоверился, копаясь в паблик-моде, который, как оказалось, и послужил основой для того сервера), в котором, среди других задач, производился декремент переменной-счётчика (вернее, элементов массива), если она не равна нулю. Как следствие, можно было узнать время до выхода на свободу, это время сохранялось при перезаходе на сервер, но присутствовала свойственная всем таймерам погрешность, на которую жаловались игроки в описанном мной случае. Что в этом "не релевантного"?
Мой косяк. Ну стоило тогда более конкретизировать пример. Твоё "полагаясь только на таймеры" меня и ввело в заблуждение :)
Опять же, в этом случае гораздо разумнее использовать gettime, ибо и действий гораздо меньше будет лишних, и точнее. Даже при использовании точных таймеров лучше сделать упор на gettime.
Я понимаю, что это лишь пример того, как кто-то реализовывал это в своих скриптах, но странно в качестве примера приводить заведомо плохой вариант реализации, когда есть более лучший, исправляющий все проблемы своего предшественника.
Хотя ещё можно совместить оба метода, записав время gettime в переменную для отображения остатка времени, а таймер запустить не секундный, а с интервалом, равным времени наказания (чтоб это самое наказание снять в конце). Это позволит избавиться от посекундных проверок, но нужно будет и с остановкой таймера заморочиться, и ещё некоторые вопросы решить, немного усложнив, в итоге, код (ну и памяти чуть больше потратить придётся, ибо нужно будет, как минимум, ID таймера хранить). Такой вариант тоже имеет право на существование. И не совсем уверен,что все эти танцы с бубном стоят того, чтоб убрать одно простое условие со сверкой значения двух переменных.
Примерно то же самое можно сказать про твой взгляд относительно "отжирания ресурсов": при нормальной своей реализации таймеры настолько легковесны, что их ничтожно малой нагрузкой (как на ЦП, так и по потреблению памяти) можно приберечь и сконцентрироваться на том подходе, который в первую очередь удобен тебе самому.
Напомню, что мы говорим тут про плагины, которые обязательно стоит ставить при разработке :) Именно в этом ключе я говорю о том, что прикручивать точные таймеры просто для того, чтоб они были, а не потому что они нужны - глупая затея. Точнее, я не стал бы называть такие плагины обязательными для использования, ибо всю свою суть они раскрывают только там, где действительно нужны точные таймеры (не секундный таймер с декрементом переменной, а таймеры, которые иначе никак нормально не реализовать).
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot