Сообщений в теме: 5

[Sledo]

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

 

Вопрос 1 - можно ли как то настроить триггер так, что бы он активировался всякий раз, когда в его зону попадает какое то ГО, даже если первый ГО еще в триггере?

 

Вопрос 2 - если нельзя, то есть ли какая то быстрая команда для подобной фичи?

 

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

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

[Schatten]

А можно узнать подробнее, для чего это нужно? И что должно произойти, если ГО войдёт и выйдет из зоны действия триггера?
Если ГО перемещаются, то, по-моему, триггеры здесь неуместны.
Вместо nearestObjects можно воспользоваться

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

- существенно быстрее, однако возвращает только "живые" объекты.

Сообщение отредактировал Schatten: 18 September 2015 - 09:24

[SteelRat]

 

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

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

С чего вы взяли что триггер не измеряет дистанции, тогда как он, по вашему разумению, функционирует в принципе!? Триггеру надо тоже вычислять условия активации и деактивации, и производить арифметические операции в том числе и с дистанциями. И да, nearestObjects, на больших площадях не очень изящно), я не сильно ошибусь если скажу что отмерить дистанции будет дешевле.

[Sledo]

А можно узнать подробнее, для чего это нужно? И что должно произойти, если ГО войдёт и выйдет из зоны действия триггера?
Если ГО перемещаются, то, по-моему, триггеры здесь неуместны.
Вместо nearestObjects можно воспользоваться

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

- существенно бустрее, однако возвращает только "живые" объекты.

Да она просто как комета по сравнению с nearestObjects! То что надо, спс) Хочу сделать РЛС.

 

 

 

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

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

С чего вы взяли что триггер не измеряет дистанции, тогда как он, по вашему разумению, функционирует в принципе!? Триггеру надо тоже вычислять условия активации и деактивации, и производить арифметические операции в том числе и с дистанциями. И да, nearestObjects, на больших площадях не очень изящно), я не сильно ошибусь если скажу что отмерить дистанции будет дешевле.

 

Сложность состоит в том, что нужен очень четкий контроль за ГО которые есть на сцене, уже нет на сцене и которые будут на сцене.

И да, вы абсолютно правы - измерять дистанцию, точнее ее не корневое представление (забыл как это называется), намного, намного дешевле. Я бы даже сказал, это практически вообще ничего не стоит даже для овер 10 000 ГО. Поэтому использование триггеров, это есть очень хорошая практика и крайне широко используемая. Но зачем изобретать велосипед, когда есть более изящные решения?)

Сообщение отредактировал Sledo: 18 September 2015 - 04:08

[SteelRat]

Согласен, изобретать велосипеды это не наш метод.

 

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

http://arma3.ru/foru...lennom-servere/

[SteelRat]

PS

Не радующий комментарий к скриптовой команде nearEntities )

 

Posted on February 3, 2015 - 21:30 (UTC)

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

This kind of functions remains FPS killer if you can't manage conditions in order to reduce operations for each entity or, to reduce the number of entities. One of the most demanding CPU/GPU resource is probably a DrawIcon3D treatment for these entities. Don't stay with a simple radius condition (disk selecting entities). Each time you can treat visible entities, as icons displaying, try to restrict this function to your screen. For example: if (((worldToScreen (visiblePosition _x)) select 0 > (0 * safezoneW + safezoneX)) && ((worldToScreen (visiblePosition _x)) select 0 <(1 * safezoneW + safezoneX))) then {...} foreach _pos nearEntities _radius