1486 replies to this topic

[Schatten]

ReXcOr, причина довольно простая -- лень (обновлять код).

[lopster102]

{
 _done = _x spawn{
  uisleep 1;
  if(!isnull _this)then{
    deletevehicle _this
   };
  };
  waitUntil {scriptDone _done};
    }foreach _deleteobjs

Уберите отсюда uisleep его функцию здесь исполняет waitUntil, до тех пор пока не закончит исполняться код в spawn следующий цикл в foreach не будет исполнен.

uisleep в данном исполнении абсолютно лишнее и не несёт в себе ни какого смысла.

 

да хоть как фпс все равно падает хоть через колл хоть через спавн хоть через ремотеекзек роли не играет тут это во все..тут уже все пробовал менять! я же  не могу сюда скинуть все варианты которые я писал..смысл в самой buildingpos то что эта функция снижает производительность это факт! а по поводу uisleep  это имеет смысл так как скорость исполнения и скорость задежрки вроде разные вещи

Edited by lopster102, 29 January 2018 - 13:40.

[NoNameUltima]

lopster102,

 

нет смысла, т.к. в цикл forEach не войдет, если он пустой.
if((count _deleteobjs) != 0 )then{

зачем spawn - если в скрипте все равно можно использовать задержки?
_done    =    _x spawn{

это зачем?
uisleep 1;

как итог достаточно такого -

{
    if(!isnull _x)then
        {deletevehicle _x;};
} forEach _deleteObjs;

да и то -
if(!isnull _this)then
тоже лишнее, т.к. ситуация, когда после
_deleteobjs = nearestObjects [_pos,_array,300];
с каким то объектом успеет что то произойти - крайне низкая.

=>

{
    deleteVehicle _x;
} forEach _deleteObjs;

этого более чем...

{
    deleteVehicle _x;
} forEach (nearestObjects [_pos,_array,300]);

даже так. без лишнего.

далее разбирать в таком форматировании лень, но кол-во вызовов (на мой взгляд не лепых) зашкаливает - зачем они?

ну и то что бросается в глаза -

  if(_classname isKindOf "Bag_Base" or _classname isKindOf ["Rifle", configFile >> "CfgWeapons"] or
             (((_classname splitString "_")select 0)== "optic"))then{
            
суть - создать холдер, если этот объект не вехайсл, или - в противном случае - создать вехайсл
ну так и упрости проверку -

if (_x isKindOf "AllVehicles") then
    {...}
else
    {...};

Edited by NoNameUltima, 29 January 2018 - 14:22.

[lopster102]

lopster102,

 

нет смысла, т.к. в цикл forEach не войдет, если он пустой.
if((count _deleteobjs) != 0 )then{

зачем spawn - если в скрипте все равно можно использовать задержки?
_done    =    _x spawn{

это зачем?
uisleep 1;

как итог достаточно такого -

{
    if(!isnull _x)then
        {deletevehicle _x;};
} forEach _deleteObjs;

да и то -
if(!isnull _this)then
тоже лишнее, т.к. ситуация, когда после
_deleteobjs = nearestObjects [_pos,_array,300];
с каким то объектом успеет что то произойти - крайне низкая.

=>

{
    deleteVehicle _x;
} forEach _deleteObjs;

этого более чем...

{
    deleteVehicle _x;
} forEach (nearestObjects [_pos,_array,300]);

даже так. без лишнего.

далее разбирать в таком форматировании лень, но кол-во вызовов (на мой взгляд не лепых) зашкаливает - зачем они?

ну и то что бросается в глаза -

  if(_classname isKindOf "Bag_Base" or _classname isKindOf ["Rifle", configFile >> "CfgWeapons"] or
             (((_classname splitString "_")select 0)== "optic"))then{
            
суть - создать холдер, если этот объект не вехайсл, или - в противном случае - создать вехайсл
ну так и упрости проверку -

if (_x isKindOf "AllVehicles") then
    {...}
else
    {...};

ok

[Schatten]

NoNameUltima, ну, до такого варианта упрощать не стоит:

{
    deleteVehicle _x;
} forEach (nearestObjects [_pos,_array,300]);

Стоит сделать так:

{
	_scriptHandle = _x spawn {deleteVehicle _this;};

	waitUntil {scriptDone _scriptHandle};
} forEach (nearestObjects [_pos,_array,300]);

Чтобы не "положить" соединение между серваком и игроками.

 

Уж сколько раз об этом писали, включая lopster102, да бестолку.

[SteelRat]

{
    deleteVehicle _x;
} forEach (nearestObjects [_pos,_array,300]);

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

[SteelRat]

Кстати, автор просмотрел, да и мы тоже достаточно грубое упущение.

 

Автор понимает что цикл очистки в его коде не учитывает эти объекты?

GroundWeaponHolder_Scripted

и они остаются.

 

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

[ReXcOr]

Так и есть
А если holder будет simulated, то 50-100 таких няшек кританут арму, через 3-7 минут к чертям собачьим, вчера проверял)

Edited by ReXcOr, 30 January 2018 - 02:20.

[NoNameUltima]

Чтобы не "положить" соединение между серваком и игроками.

кто это тестил?

сколько объектов удалялось?

скрипт от куда вызывался и как - spawn\call?

 

ЗЫ - замкнутый, или длинный цикл(под длинным - подразумевается реально длинный) без sleep может положить сеть эт да. - но вряд ли это актуально.

я хз что там за массив и действия с ним должен сервак проводить, чтоб серв подвис и udp упал.

{
    _scriptHandle = _x spawn {deleteVehicle _this;};

    waitUntil {scriptDone _scriptHandle};
} forEach (nearestObjects [_pos,_array,300]);

суть этого кода - нативный sleep благодаря иyструкции spawn

по факту, если объектов реально ОООЧЕНЬ много, и есть страх, что цикл может подвесить машинку, можно сделать так -

_i = 0;
{
  deleteVehicle _this;
_i=_i+1;
if(_i>50) then
{sleep 0.5; _i=0;};
} forEach (nearestObjects [_pos,_array,300]);

ну или просто и банально делать sleep 0.001 после каждого удаленного объекта, - это не даст потоку отожрать все ресурсы.

Edited by NoNameUltima, 30 January 2018 - 17:33.

[Schatten]

кто это тестил?

Думаю,

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

.
 

сколько объектов удалялось?

По сути, без разницы.
 

скрипт от куда вызывался и как - spawn\call?

Аналогично.
 

замкнутый, или длинный цикл(под длинным - подразумевается реально длинный) без sleep может положить сеть эт да. - но вряд ли это актуально.

Подстраховка не помешает.
 

по факту, если объектов реально ОООЧЕНЬ много, и есть страх, что цикл может подвесить машинку, можно сделать так -

_i = 0;
{
  deleteVehicle _this;
_i=_i+1;
if(_i>50) then
{sleep 0.5; _i=0;};
} forEach (nearestObjects [_pos,_array,300]);

ну или просто и банально делать sleep 0.001 после каждого удаленного объекта, - это не даст потоку отожрать все ресурсы.

А если 0,001 с окажется мало, а 0,5 с -- много? А может лучше задержка 0,1, 0,25, 1 или 2 с? Зачем гадать, если можно использовать waitUntil?

Edited by Schatten, 30 January 2018 - 21:41.

[lopster102]

уважаемые все это очень познавательно конечно  кто куда ставит запятую в скрипте но как быть  все таки с buildingpos есть что то реально полезное кроме обычного тролинга безосновательного причем.......

[Schatten]

но как быть все таки с buildingpos

Тебе как минимум 3 чела сказали, что у них всё нормально с buildingPos.
 

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

Безосновательного "троллинга"?! Чувак, тебе тут скинули ссылок и другой полезной инфы. Да вот только я не заметил, чтобы это как-то отразилось на твоём коде.

Edited by Schatten, 30 January 2018 - 21:55.

[lopster102]

 

но как быть все таки с buildingpos

Тебе как минимум 3 чела сказали, что у них всё нормально с buildingPos.
 

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

Безосновательного "троллинга"?! Чувак, тебе тут скинули ссылок и другой полезной инфы. Да вот только я не заметил, чтобы это как-то отразилось на твоём коде.

 

ok=)

[NoNameUltima]

А если 0,001 с окажется мало, а 0,5 с -- много? А может лучше задержка 0,1, 0,25, 1 или 2 с? Зачем гадать, если можно использовать waitUntil?

 

При чем тут много, или мало? - Суть задержки - на некоторое время освобождать ресурсы для работы других потоков. - Не дать зависнуть. Достаточно любой приемлимой. - плевать там на успешное завершение команды. - Может у кого то deleteVehicle за 10 сек отрабатывает? - так это уже мертвый сервер.

 

 

 

Зачем гадать, если можно использовать waitUntil?

А никто и не гадает.

было бы хорошо использовать waitUntil, если бы в данном контексте для нее не приходилось делать spawn.

а по ситуации со spawn - 2 варианта -

1. имеем небольшой массив - в таком случае вообще наплевать на задержку, - ничего там не ляжет.

2. имеем огромный массив - и начинаем спавнить потоки, без конца. - Ну и нафига оно надо? - Вопрос производительности. - На одно создание spawn, убьется времени в 10 раз больше чем на deleteVehicle, внутри.

 

P.S. Само по себе написание то корректное... Но если все писать таким образом, - думаю серв начнет реально притормаживать.

Edited by NoNameUltima, 30 January 2018 - 22:27.

[Schatten]

Суть задержки - на некоторое время освобождать ресурсы для работы других потоков. - Не дать зависнуть. Достаточно любой приемлимой. - плевать там на успешное завершение команды.

Ещё раз задаю вопрос: приемлемая задержка -- это сколько? Меня интересует конкретное число (и почему именно столько), раз уж waitUntil не хорошо использовать в данном контексте.
Насчёт "плевать", то есть ты предлагаешь до завершения выполнения сценария запускать новый? То есть увеличивать этот "снежный ком" работающих потоков? Серьёзно?
 

было бы хорошо использовать waitUntil, если бы в данном контексте для нее не приходилось делать spawn.
а по ситуации со spawn - 2 варианта -
1. имеем небольшой массив - в таком случае вообще наплевать на задержку, - ничего там не ляжет.
2. имеем огромный массив - и начинаем спавнить потоки, без конца. - Ну и нафига оно надо?

В любом случае хорошо использовать spawn и waitUntil -- меньше нагрузка на сеть и меньшая заметность для игроков.
Это же и ответ на вопрос "нафига?"
 

Вопрос производительности. - На одно создание spawn, убьется времени в 10 раз больше чем на deleteVehicle, внутри.

А дело не в том, чтобы быстрее всё удалить (игрок же не заметит, удалился объект за 0,01 или 0,1 с), а в снижении нагрузки на сеть и игроков.
 

Само по себе написание то корректное... Но если все писать таким образом, - думаю серв начнет реально притормаживать.

Не начнёт.

Edited by Schatten, 30 January 2018 - 23:05.

[SteelRat]

Не ссорьтесь)

 

Я попытаюсь объяснить в чём прелесть связки spawn и waitUntil.

 

Действительно, тут суть не скоростях, быстрее удалить или отспавнить, если нужно быстро, то это нужно делать при инициализации миссии, когда не то что просадка фпс будет но и пофигу даже на конкретный фриз когда даже интерфейс не отзывается, в данном контексте это не важно, ибо игровой процесс ещё не начался.

 

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

 

Вот при таких обстоятельствах и познаётся вся прелесть связки spawn и waitUntil.

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

 

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

 

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

[SteelRat]

Качество записи говёное, но в чате можно понаблюдать собственно как это работает, и что самое важное ни как не отражается на комфорте.

[NoNameUltima]

Ещё раз задаю вопрос: приемлемая задержка -- это сколько?

Ну раз ты конкретное число просишь -

Основываясь на написании многопоточных приложений(хоть опыт и не богатый) в C\Delphi - для потока требуется задержка, дабы не сожрать весь проц. Как показала практика, - задержка менее 0.001 не имеет смысла. Отсюда => Для любого потока, минимум 0.001.

Большая величина, зависит от конкретной задачи.

увеличивать этот "снежный ком" работающих потоков?

Странное утверждение, - разве deleteVehicle пораждает поток? - вроде нет.

А если нет, то этот код выполняется в основном потоке.

то есть ты предлагаешь до завершения выполнения сценария запускать новый?

Ты явно передергиваешь, - я предлагаю основываться на реалиях, и условиях задачи.

А дело не в том, чтобы быстрее всё удалить (игрок же не заметит, удалился объект за 0,01 или 0,1 с), а в снижении нагрузки на сеть и игроков.

Я уже спрашивал по поводу тестов - как они проводились?

Это не риторические были вопросы.

Напомню:

1. Откуда инфа, что нагрузка на сеть при удалении объектов возрастает настолько, что может положить соединение? - Я же писал, что реально длинный массив - вполне может. Но мы же про реалии - радиус 300 - ну сколько там объектов?

2. В контексте данной задачи, не имеет смысл удалять по 1 объекту, каждый раз создавая поток. Эдак мы докатимся до того, что в любых циклах, будем юзать такую конструкцию => синхронизация игроков с БД, синхронизация техники с БД, ... да вообще любые циклы, по данному утверждению должны все делать через spawn и waitUntil - отсюда мое утверждение,

 

Само по себе написание то корректное... Но если все писать таким образом, - думаю серв начнет реально притормаживать.

 

Ну и в довесок - нагрузка на сеть и так постоянная - передача координат игроков, векторов их направления, координаты лута валяющегося на земле, и многое другое - с чего вдруг, удаление объекта (передача пары байт - ИД объекта+ пара байт - команда - удалить)будет нагружать сеть больше чем передача координат?

 

По ссылке которую ты оставил, пример с 1000 объектов, и использование spawn\waitUntil - но нет примера альтернативы, например - с использованием банальной задержки скажем после каждого 50того объекта. И в рамках данной задачи, - указан раздиус 300 - там не то, что 1000 объектов, там сотней то не пахнет - зачем же в таком ключе спавнить и ждать по каждой мелочи?

 

то это нужно делать при инициализации миссии

Да это то понятно, но мы то, то реал-тайм говорим, - синхронизация, спавн лута по мере приближения\удаления игрока, и т.п.

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

Плюсану. - О том, и речь.- все зависит от задачи.

 

но как быть все таки с buildingpos

Так ты покажи выкладку рпт\видео, где у тебя цикл с использованием данной команды, + какие задержки ты используешь, и на сколько проседает ФПС.

Я например тоже не заметил никаких просадок.

[lopster102]

но как быть все таки с buildingpos

Так ты покажи выкладку рпт\видео, где у тебя цикл с использованием данной команды, + какие задержки ты используешь, и на сколько проседает ФПС.

Я например тоже не заметил никаких просадок.

 

 

дык эт самое в том и смысл что сажается локлаьный фпс клиента словно после расковырки конфига здания  что то у клиента загружается и уже остается навсегда до рестарта((((((сервеный фпс у меня всегда 50 даже через  несколько часов только единственное растет загрузка памяти

Edited by lopster102, 01 February 2018 - 10:43.

[NoNameUltima]

lopster102,

Ты скрипт покажи, и как ты его запускаешь, - короткий скрипт, для теста, с использованием данной команды. - полностью.

например такой скрипт повесь на кнопку, прогрузи миссию, а потом запусти.

Private ["_house"];
_house    =    ....;
player setPosATL (_house buildingPos 1);

_house - сам там найдешь... любым способом.

а потом скажи сколько ФПС на клиенте, было ДО выполнения скрипта, и сколько ПОСЛЕ.

Просел ли ФПС, и осталась ли просадка после отработки.

 

P.S. И зачем нам серверный ФПС, если ты утверждаешь, что проседает клиентский?

Сделай вывод клиентского-

while {true} do
{hint str(round diag_fps); uiSleep 1;};

Edited by NoNameUltima, 31 January 2018 - 18:17.