[Urukhay]

Проблема заключалась в том, что во "вставке" 1 не было ссылки на функцию для второй "вставки".

[cm666]

Меня плющит, или часть форумов с другими языками пропадают ?

[DartfoL]

Quote:

Originally Posted by cm666 Меня плющит, или часть форумов с другими языками пропадают ?

их закрывают из-за неактивности, скорее всего

[S4D]

Вроде только ссылку на немецкий форум убрали

[Stepashka]

Quote:

Originally Posted by S4D Вроде только ссылку на немецкий форум убрали

Убрали почти половину разделов.

[DartfoL]

Quote:

Originally Posted by S4D Вроде только ссылку на немецкий форум убрали

плюс удалили голландский и французский

[cm666]

И загрузка клиента вроде как было с 3 сайтов, сейчас 2

[Urukhay]

Можно ли как-то определить, что игрок врезался в машину другого игрока?

OnVehicleDamageStatusUpdate вызывается когда машине наносятся только визуальные повреждения.

[Romz]

Quote:

Originally Posted by cm666 И загрузка клиента вроде как было с 3 сайтов, сейчас 2

Последняя версия была с двух, точно помню. 0.3z и прошлые было 3.

[OKStyle]

Quote:

Originally Posted by Urukhay Можно ли как-то определить, что игрок врезался в машину другого игрока? OnVehicleDamageStatusUpdate вызывается когда машине наносятся только визуальные повреждения.

А разве машина визуально не повреждается, когда врезается в другую? о_0

[prineside]

Quote:

Originally Posted by Bombo Доброе время суток! Вопрос у меня такой: в каких версиях удалялись модели из SAMP.img (интересует весь ряд от 0.3c до 0.3.7)

18846 удален в 0.3d RC3-3
19300 - 19307 удалены в 0.3d

Скорее всего, это все

[themakar]

Для ежесекундных операций с игроками лучше будет для каждого игрока создавать отдельный таймер или один таймер и пробегаться по всем игрокам?

[XemyL]

Quote:

Originally Posted by themakar Для ежесекундных операций с игроками лучше будет для каждого игрока создавать отдельный таймер или один таймер и пробегаться по всем игрокам?

Лучше группами, человек так по 8.

[cm666]

Quote:

Originally Posted by XemyL Лучше группами, человек так по 8.

Разница ?

[OstGot]

Quote:

Originally Posted by themakar Для ежесекундных операций с игроками лучше будет для каждого игрока создавать отдельный таймер или один таймер и пробегаться по всем игрокам?

У каждого из вариантов как свои плюсы, так и свои минусы.

1 вариант: Цикл
Из плюсов то, что таймер всего один, но есть цикл, присутствие которого уже не есть хорошо, особенно если много слотов. Пробегаться он будет всегда по всем слотам (а если на сервере 1000 слотов, а игроков всего 8 человек? Итераций 1000, а нужно-то всего 8). Конечно можно это обойти через GetPlayerPoolSize или лучше foreach - это сократит количество итераций до минимума в ситуации с 8 игроками, но на полном сервере это уже абсолютно никак не поможет.

2 вариант: Индивидуальный таймер для каждого
В этом случае никакие циклы уже мешать не будут, но, предположим, у нас есть популярный сервер с 1000 игроков онлайн - тут уже выгода от них, по моему, не очень большая. Вызываться они будут с очень частой периодичностью, и лучше ли они цикла в данной ситуации, над этим ещё можно поспорить.
С другой стороны, каждый игрок играет в среднем от 15 до 30 минут например. И для каждого при входе таймер создаётся, при выходе удаляется. Иды таймеров становятся всё больше, и если долго не делать рестарт, то возможно значения идов таймеров могут достигнуть какого-то порога (хотя в этом я не уверен).

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

[prineside]

Обрабатывать частями лучше, соглашусь, но по другим причинам, и не всегда.

Если вам нужно производить какие-то простые задачи каждую секунду (например, уменьшать сытость игроков), лучшим вариантом будет foreach и один цикл в одном таймере. Это проще, а значит, лучше.

Если речь идет о каких-то комплексных задачах (например, античит, проверяющий игроков по всей строгости), тут дела обстоят иначе. Если вы хотите знать, какой вариант потребует меньше всего процессорного времени, я без колебаний отвечу - с одним циклом и одним таймером, но это еще ничего не значит.

Представим ситуацию, когда на обработку одного игрока уходит 1мс, игроков на сервере 200, один добавленный таймер отнимает 1мс (не будем говорить о количестве итераций в циклах, это практически не скажется на результатах). Обратите внимание, что цифры я взял для примера, на самом деле они могут быть больше (на обработку игроков) или меньше (таймеры обычно кушают меньше времени).
Если мы используем вариант с одним таймером и циклом по всем игрокам, вот сколько времени это займет в секунду:
200 игроков * 1мс + 1мс на таймер = 201мс работы процессора в секунду (грубо говоря, 20.1%)
А если будем давать каждому игроку отдельный таймер:
200 игроков * 1мс + 200 игроков * 1мс на таймер = 400мс процессорного времени в секунду (также грубо говоря 40%) (это НЕ значит, что вариант у 2 раза медленнее, так как числа взяты для примера)

Теперь рассмотрим с другой стороны все это.

В первом варианте сервер будет "висеть" 201мс до тех пор, пока все игроки не будут обработаны, и в это время больше ничего обрабатываться не будет. Грубо говоря, это самый натуральный лаг на 0.2 секунды каждую секунду (и, если не ошибаюсь, такие операции дурно сказываются на точности таймеров сервера). На многопользовательском игровом сервере типа SA-MP я бы это считал недопустимым. Например потому, что параллельно может работать второй таймер с интервалом в 300мс, и из-за первого таймера его интервал будет "прыгать" между 300 и 500+ (это я тоже для примера, но такое возможно).

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

Третий вариант с обработкой игроков небольшими пачками в этом случае подойдет лучше (имхо), и я объясню, почему, на примере.
Допустим, обработка одного игрока все так же требует 1мс, таймер кушает 1мс, и вызывается это все раз в секунду для 200 игроков. Также предположим, что на сервере 300 слотов.
Создадим 1 таймер с интервалом запуска в 200мс, в отдельной переменной будем хранить текущий "указатель" на слот игрока. Функция, которая будет вызываться в таймере, будет обрабатывать следующих 60 игроков после указателя, либо начинать остчет с 0, если прошлась по всем игрокам, и каждый раз сохранять указатель.
Таким образом, функция будет вызвана примерно 5 раз в секунду для 60 слотов - в идеале, 300 слотов в секунду, при этом
В секунду будет потреблять (в идеале) 5 вызовов * ( 60 слотов * 1мс на слот (или меньше, если игрок оффлайн) ) + 1мс на таймер = 301мс (в случае прямого перебора всех слотов, т.е. не самый оптимизированный вариант), но со стороны это будет что-то вроде [60мс работает] [140мс делает что-то другое] [60мс работает] [140мс делает что-то другое]...
Как видно, "время лагания" по сравнению с 1 вариантом (200мс) больше чем у 3 раза короче, а значит, лаги менее заметны и нагрузка лучше распределена.

Чтобы еще больше уменьшить лаги, можно сделать интервал меньше - например, 50мс (15 игроков за раз) будут вызывать практически незаметные лаги длительностью 15мс (+время на более частый вызов функции) и почти равномерно распределять нагрузку, но не стоит забывать, что вызов функции и запуск цикла тоже потребляют процессорное время - нужно найти золотую средину.

Касательно того, как в третьем варианте не обрабатывать ненужные слоты (в случае с онлайном 200/300 речь идет о последних 100 слотах, 200-299).
В простом подходе с прямым перебором слотов будет тратиться лишнее время на проверку пустых слотов и циклы, что тоже не есть хорошо. Навскидку я бы предложил решить эту проблему ценой оперативной памяти:
1. Создать глобально массив из n итераторов (не помню, как правильно, в общем iterable из foreach), где n - количество "пачек" игроков (при n=10 мы будем вызывать функцию в цикле с интервалом в 100мс, 10 раз в секунду, при 20 - с интервалом в 50мс)
2. Равномерно распихивать игроков по всем итераторам при входе на сервер (особо не скажется на производительности, так как выполняется единожды)
3. В обработчике, который запускается таймером каждых 1/n секунд, по очереди брать следующий итератор из массива и обрабатывать находящихся там игроков.
4. При выходе игрока из сервера, убирать его ID из итератора.

Я не проверял, что писал, поэтому дико извиняюсь, если есть ошибки или перепутал что, но идею старался объяснить. Если у вас есть подходы получше - с удовольствием послушаю

[Urukhay]

Сколько игроков должно быть в стриме игрока(ов), чтобы сервер/клиент начал "лагать"?
И может ли быть такое, что 1000 игроков находятся в одной точке, и сервер ни чуть ни "лагает"?

[S4D]

Quote:

Originally Posted by Urukhay Сколько игроков должно быть в стриме игрока(ов), чтобы сервер/клиент начал "лагать"? И может ли быть такое, что 1000 игроков находятся в одной точке, и сервер ни чуть ни "лагает"?

Тут, наверное, от пропускной способности канала больше зависит

[themakar]

Quote:

Originally Posted by prineside Обрабатывать частями лучше, соглашусь, но по другим причинам, и не всегда. Если вам нужно производить какие-то простые задачи каждую секунду (например, уменьшать сытость игроков), лучшим вариантом будет foreach и один цикл в одном таймере. Это проще, а значит, лучше. Если речь идет о каких-то комплексных задачах (например, античит, проверяющий игроков по всей строгости), тут дела обстоят иначе. Если вы хотите знать, какой вариант потребует меньше всего процессорного времени, я без колебаний отвечу - с одним циклом и одним таймером, но это еще ничего не значит. Представим ситуацию, когда на обработку одного игрока уходит 1мс, игроков на сервере 200, один добавленный таймер отнимает 1мс (не будем говорить о количестве итераций в циклах, это практически не скажется на результатах). Обратите внимание, что цифры я взял для примера, на самом деле они могут быть больше (на обработку игроков) или меньше (таймеры обычно кушают меньше времени). Если мы используем вариант с одним таймером и циклом по всем игрокам, вот сколько времени это займет в секунду: 200 игроков * 1мс + 1мс на таймер = 201мс работы процессора в секунду (грубо говоря, 20.1%) А если будем давать каждому игроку отдельный таймер: 200 игроков * 1мс + 200 игроков * 1мс на таймер = 400мс процессорного времени в секунду (также грубо говоря 40%) (это НЕ значит, что вариант у 2 раза медленнее, так как числа взяты для примера) Теперь рассмотрим с другой стороны все это. В первом варианте сервер будет "висеть" 201мс до тех пор, пока все игроки не будут обработаны, и в это время больше ничего обрабатываться не будет. Грубо говоря, это самый натуральный лаг на 0.2 секунды каждую секунду (и, если не ошибаюсь, такие операции дурно сказываются на точности таймеров сервера). На многопользовательском игровом сервере типа SA-MP я бы это считал недопустимым. Например потому, что параллельно может работать второй таймер с интервалом в 300мс, и из-за первого таймера его интервал будет "прыгать" между 300 и 500+ (это я тоже для примера, но такое возможно). Второй вариант не отбирает все внимание на себя, поэтому лаги могут быть менее заметны, а прыжки менее значительны, потому что в таком случае нагрузка на сервер будет распределена (практически случайно, ведь таймеры добавляются игрокам при входе, а игроки имеют свойство входить в разные доли секунды). Но минус этого варианта в том, что таймеры не бесплатны (каждый таймер, как я это представляю, добавляет как минимум одну операцию сравнения, чтобы сервер узнал, когда стоит его вызывать). Так как таймеров много, процессор будет больше работать (я не затрагиваю темы использования памяти или выделения ресурсов, только производительность). Третий вариант с обработкой игроков небольшими пачками в этом случае подойдет лучше (имхо), и я объясню, почему, на примере. Допустим, обработка одного игрока все так же требует 1мс, таймер кушает 1мс, и вызывается это все раз в секунду для 200 игроков. Также предположим, что на сервере 300 слотов. Создадим 1 таймер с интервалом запуска в 200мс, в отдельной переменной будем хранить текущий "указатель" на слот игрока. Функция, которая будет вызываться в таймере, будет обрабатывать следующих 60 игроков после указателя, либо начинать остчет с 0, если прошлась по всем игрокам, и каждый раз сохранять указатель. Таким образом, функция будет вызвана примерно 5 раз в секунду для 60 слотов - в идеале, 300 слотов в секунду, при этом В секунду будет потреблять (в идеале) 5 вызовов * ( 60 слотов * 1мс на слот (или меньше, если игрок оффлайн) ) + 1мс на таймер = 301мс (в случае прямого перебора всех слотов, т.е. не самый оптимизированный вариант), но со стороны это будет что-то вроде [60мс работает] [140мс делает что-то другое] [60мс работает] [140мс делает что-то другое]... Как видно, "время лагания" по сравнению с 1 вариантом (200мс) больше чем у 3 раза короче, а значит, лаги менее заметны и нагрузка лучше распределена. Чтобы еще больше уменьшить лаги, можно сделать интервал меньше - например, 50мс (15 игроков за раз) будут вызывать практически незаметные лаги длительностью 15мс (+время на более частый вызов функции) и почти равномерно распределять нагрузку, но не стоит забывать, что вызов функции и запуск цикла тоже потребляют процессорное время - нужно найти золотую средину. Касательно того, как в третьем варианте не обрабатывать ненужные слоты (в случае с онлайном 200/300 речь идет о последних 100 слотах, 200-299). В простом подходе с прямым перебором слотов будет тратиться лишнее время на проверку пустых слотов и циклы, что тоже не есть хорошо. Навскидку я бы предложил решить эту проблему ценой оперативной памяти: 1. Создать глобально массив из n итераторов (не помню, как правильно, в общем iterable из foreach), где n - количество "пачек" игроков (при n=10 мы будем вызывать функцию в цикле с интервалом в 100мс, 10 раз в секунду, при 20 - с интервалом в 50мс) 2. Равномерно распихивать игроков по всем итераторам при входе на сервер (особо не скажется на производительности, так как выполняется единожды) 3. В обработчике, который запускается таймером каждых 1/n секунд, по очереди брать следующий итератор из массива и обрабатывать находящихся там игроков. 4. При выходе игрока из сервера, убирать его ID из итератора. Я не проверял, что писал, поэтому дико извиняюсь, если есть ошибки или перепутал что, но идею старался объяснить. Если у вас есть подходы получше - с удовольствием послушаю

Спасибо за такую большую расстыковку, буду использовать один таймер и foreach.

[themakar]

Такое вопрос:
Если лимит TD для игрока 256, а я хочу использовать гораздо больше в будущем, сейчас пока около 100, тестировал только с одним игроком онлайн.

Я создаю их только тогда когда они используется, и удаляю когда не используются.
Например инвентарь, игрок открыл инвентарь я создаю 80 TD и показываю их игроку, игрок закрывает инвентарь TD удаляются.

Будет ли такой алгоритм постепенно отнимать память и нагружать систему?