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

[Cast]

 

 

 

 

В аргумент condition я писал "player distance ammobox < 50". Все работало, но нужно смотреть на ящик, чтобы действие появилось. А вот этого я хочу избежать

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

 

 

Точно!) не догадался. ну уже из принципа надо сделать такой триггер. Однажды все равно пригодится

Сообщение отредактировал Cast: 08 October 2015 - 12:48

[vlad333000]

Schatten, насчёт всего этого бисы в своей Вики написали очень хорошую фразу: "Focus on getting a working product first." А я пока что не виду этого у автора + мощность (код-во команд которое успевает выполнить за секунду) ЦП распространяется на всю секунду, а учитывая то что триггер это сущий адд в плане того что он делает, то покадрова проверка дистанции выигрывает в производительности

Сообщение отредактировал vlad333000: 08 October 2015 - 13:05

[Schatten]

Schatten, насчёт всего этого бисы в своей Вики написали очень хорошую фразу: "Focus on getting a working product first." А я пока что не виду этого у автора

Это не значит, что как только достигнута работоспособность, можно закидывать проект, мол, работает - не трогай. Нужно улучшать проект!
Да, автор пока не достиг работоспособного решения, но это вопрос времени.
К тому же, я использую такой подход, и, насколько я помню, как только я перешёл на его, FPS у меня немного поднялся.
 

триггер это сущий адд в плане того что он делает, то покадрова проверка дистанции выигрывает в производительности

Очень сомневаюсь.

Сообщение отредактировал Schatten: 08 October 2015 - 13:13

[vlad333000]

Schatten, тоесть по твоему мнение, поиск всех объектов в трехмерном пространстве отвечающих определенным условиям и входящих в определённую фигуру (Зона триггера) + различные формулы для оптимизации - это пара строчек даже языке программирования высоко уровня, не говоря уже о машинном коде?

[Schatten]

Schatten, тоесть по твоему мнение, поиск всех объектов в трехмерном пространстве отвечающих определенным условиям и входящих в определённую фигуру (Зона триггера) + различные формулы для оптимизации - это пара строчек даже языке программирования высоко уровня, не говоря уже о машинном коде?

Причём здесь это малопонятное из-за ошибок высказывание? Дело в частоте проверки условия! А частота проверки условия отображения действия на порядки выше частоты проверки условия активации триггера. Или по вашему 100 проверок менее затратные чем 2 (будем считать, что они одни и те же)?

Сообщение отредактировал Schatten: 08 October 2015 - 13:34

[vlad333000]

Schatten, много проверок (а учитывая движок армы ~30 в мп в лучшем случае), но невъ**ически легких значительно легче, чем 2, которые вбирают в себя десятки проверок (ведь нужно найти ВСЕ объекты входящие в зону триггера) с формулами, которые сложнее в несколько раз чем простая проверка растояния.
Если речь зашла про полную оптимизацию, то цикл while с частотой 1 герц и загруженый в память еще меньше ресурсов требовует

Сообщение отредактировал vlad333000: 08 October 2015 - 13:58

[Schatten]

Schatten, много проверок, но невъ**ически легких значительно легче, чем 2, которые вбирают в себя десятки проверок (ведь нужно найти ВСЕ объекты входящие в зону триггера) с формулами, которые сложнее в несколько раз чем простая проверка растояния.

О каких "десятках проверок" идёт речь, если триггер "следит" (или будет "следить") только за игроком? О каких сложных формулах идёт речь, если в обоих случаях решается геометрическая задача - игрок в зоне или нет, причём в случае с триггером эта задача решается по двум координатам?
 

Если речь зашла про оптимизацию, то цикл while с той же частотой, что и у трггера будет еще меньше ресурсов требовать

Возьму на заметку.

[vlad333000]

Schatten, ой, вам кажется нужно напомнить, что триггер в волшебную переменную thisList возвращает... о чудо! Все объекты входящие в зону триггера (независимо от условия написанного в поле "условие" и, в лучше случае, отвечающим условию "Активация кем") - а что бы получить эту переменную, что нужно?... Правильно! Пройтись по всем существующим объектам (Там есть еще куча формул и условий оптимизации, но все равно объектов много для проверки) и определить: входят ли они в зону триггера, а это десятки раз проверка условий по сложным формулам (Еллипс - загуглите его уравнение)
PS distance проверка по 3-ем координатам, distance2d - 2-ум

Сообщение отредактировал vlad333000: 08 October 2015 - 14:13

[Schatten]

Schatten, ой, вам кажется нужно напомнить, что триггер в волшебную переменную thisList возвращает... о чудо! Все объекты входящие в зону триггера (независимо от условия написанного в поле "условие" и, в лучше случае, отвечающим условию "Активация кем")

Вы это серьёзно?! Если да, то я, мягко говоря, в шоке. Нет, я конечно знаю про разные "косяки" BIS, но это...

Что скажете на счёт этого:

 

Alternative would be to add a loop to check player proximity for dead animals which could be quite expensive. Or to add permanent action to player to “gut” animal with condition, which would be even more expensive, since action condition is checked every frame.

этого:

 

addAction Condition Check – tries to run code on each frame and cannot and will not be suspended, but as with FSM condition check it would also skip frames when overloaded.

и этого:

 

Trigger Vehicle Condition Check – runs on each frame and cannot and will not be suspended. Does not skip frames under load.

Всё за авторством Killzone_Kid.
 

distance проверка по 3-ем координатам, distance2d - 2-ум

Про последнюю команду не все ещё знают. )

Сообщение отредактировал Schatten: 08 October 2015 - 15:22

[vlad333000]

Вы это серьёзно?!

Да, я серьезно. Я это заметил, когда через скрипты искал технику, которая должна была входить в зону.
Создал триггер с активацией "ANY" (Кто-угодно в редакторе) и в листе триггера я не только эту технику нашел, а еще кроликов, змей, бабочек, всяких частиц эффектов, игроков, ботов, остальную технику... у меня тогда игра зависла от того, что гиганский hint мне вывела, когда я хотел понять, можно ли найти объект стороны EMPTY через триггер

[Schatten]

триггер с активацией "ANY"

А, ну тогда всё ясно...
Я имел ввиду "присобаченную" к триггеру "машину" (vehicle):

_trigger triggerAttachVehicle [player];

В этом случае триггер тоже будет проверять все "машины" или только игрока?

Сообщение отредактировал Schatten: 08 October 2015 - 15:28

[vlad333000]

Schatten, я думаю что бисы все же не настолько тупы, и если синхронизировать триггер с объектами, то только их и будет проверять. Все же какие-то методы оптимизации присутствуют, да и если подумать то без них как то жестко было бы

[Schatten]

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

Ну вот и отлично, а то я так перепугался...

Т. о., что мы имеем для триггеров:

- Если "прикрепить" к триггеру "машину", то триггер будет следить только за ней.

- Проверка условия активации триггера происходит 2 раза в секунду и "не влияет" на FPS.

Что мы имеем для условия отображения действия:

- По возможности запускается каждый кадр.

- "Просаживает" FPS в случае сложного условия.

Вывод для себя я уже сделал.

[vlad333000]

Schatten, прогнал сейчас с десяток тестов с триггерами, результаты таковы (за 100% бралась нагрузка игры на ЦП при пустой карте в ВР и отключенным окружение (disableEnviroment)):

100 триггеров на присутствие в них синих - 1 игрок = +5%
100 триггеров на присутствие в них синих - 1 игрок + 25 ботов (Отключен ИИ и симуляция) = +10%
100 триггеров на присутствие в них кого-угодно - 1 игрок + 25 ботов (Отключен ИИ и симуляция) = +15%
100 триггеров на присутствие в них синих - 1 игрок + 25 красных ботов (Отключен ИИ и симуляция) = +8%
100 триггеров на присутствие в них синих - 1 игрок + 25 ботов (Включен ИИ и симуляция) = +20%
100 простых действий на игроке = +5%
100 простых действий на игроке + 25 ботов = +12%
100 простых действий + доп. условие на дистанцию на игроке = +5%
1000 простых действий на игроке = +30%;
1000 триггеров = +30% + увеличено значительно время загрузки миссии (В 2D-редакторе был стоп кадр)

Выводы моих тестов:
1. Чем больше объектов, которые принадлежат стороне которая активирует триггер, тем больше нагрузку дает каждый триггер
2. 100 простых действий дают в среднем такую же нагрузку как и 100 триггеров на присутствие стороны
3. 1000 действий или триггеров лучше не ставить
4. 100 триггеров = большое падение производительности в 2D-редакторе
5. 100 действий у которых не выполняется какое-либо из условий на отображение -1-2%, по сравнению с ситуацией, когда все условия сработали

PS Тесты проводились в 3-4 раза на одном ядре слабом ЦП (Дефолтно арма его нагружала на 40-45%), с убитой в 0 графикой и фоновыми процессами, для наглядности увеличения нагрузки

Сообщение отредактировал vlad333000: 08 October 2015 - 20:02

[vlad333000]

PSPS 100 циклов while с проверкой двух условий раз в 1 секунду давали близкий к 1-2% нагрузку

[Schatten]

vlad333000, спасибо за тесты!

Кстати, каким образом запускались циклы while? Если в scheduled-окружении, то нагрузку некорректно сравнивать с той, которая происходит при триггерах и проверках условий отображения действий, поскольку там это всё "крутится" в non-scheduled-окружении.

 

Cast, вот рабочая миссия:  Action.VR.zip   1.21К   2 Количество загрузок:.

Правда, там я создавал и настраивал триггер с помощью команд, а не в редакторе.

Сообщение отредактировал Schatten: 08 October 2015 - 20:29