Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[НаноБот 742]

Не знаю, но по мне не к чему всё валить в один класс. Проще отладить основной класс и добавлять новые возможности в наследниках.

Я ещё тут подумал, и пришёл к выводу что взрывные объекты не совсем правильно сделаны, хорошо объект взрыва поместить в пространство level как и пули, это надо для взрывных пуль, то есть снарядов. Создание CGameObject весьма ресурсоёмко, и  для взрывного предмета который взорвётся сразу после создания это не целесообразно.

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

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

 

Наверно стоит перечислить.

CWeaponMagazined Обычное оружие: стреляет пулями, одиночными и очередями. В этом классе стоит реализовать пару типов заряжания, нормальное и заряжание по одному патрону (револьвер НАГАН, подствольный магазин у дробовика). 

CWeaponMagazinedDual  Бинарное оружие: это оружие имеющие два разнотипных ствола (автомат с ПГ, автомат с подст. дробовиком, тройники).

CWeaponMagazinedRL Гранатомёты: оружие стреляющие ракетами, многозарядные, может стрелять очередями или залпом.

Дружественные классы - ракеты (хорошо бы сделать специальный класс объектов с ускоренным спавном, класс по определению не имеет серверного объекта, а не просто флажок):

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

Управляемые ракеты: алгоритм наведение помещён в скрипт, в движке только есть алгоритм лететь в определённую точку.

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

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

Изменено 19 Июля 2016 пользователем НаноБот

[mortan 143]

Может кто помочь - подключаю в xr_ioc_cmd.cpp файл actor.h и проект перестаёт собираться - компилятор жалуется что в каком-то файле, который подключен к актору, не может найти включаемые файлы, хотя если убрать включение то всё собирается). Насколько я понимаю то рушится последовательность сборки. Я прав?

Изменено 19 Июля 2016 пользователем mortan

[Malandrinus 615]

 

 

подключаю в xr_ioc_cmd.cpp файл actor.h и проект перестаёт собираться

Это файлы из разных проектов. xr_ioc_cmd.cpp из проекта экзешника, а actor.h - из xrGame. У проектов совершенно разные настройки по поиску включаемых файлов, да и вообще такое включение выглядит бессмыслицей, поскольку в проекте экзешника ничего и никому не известно о классах игровых объектов. Там максимум известны объекты сервера, клиента, ГУИ и т.п.

[mortan 143]

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

[Malandrinus 615]

Предлагаю поговорить на общую тему, которую можно сформулировать примерно так: "каким должен быть движок X-Ray". Или возможно так: "Что бы я там изменил/возможное направление для развития".

 

Для затравки предлагаю мысль. В текущем состоянии движок развитию не подлежит. Там что-то можно подкрутить, что-то поменять, но реально продвинуться невозможно. Тому есть несколько причин. Если попытаться их перечислить, то мне на ум приходят такие (уверен, что список далеко не полный):

• сетевая архитектура движка
• разные среды разработки (и в сущности разные языки) самого движка и SDK
• архитектура, основанная на dll, а не на статических библиотеках
• разные версии рендера
• абсолютная недокументированность кода

Соответственно, любые перспективы хоть какого-то развития на мой взгляд подразумевают в первую очередь искоренение указанных причин. Ну вот начать хотя бы с сетевой архитектуры. Сколько из-за неё бед! Клиент-серверное взаимодействие создаёт только проблемы: по паре объектов на каждый реальный игровой, асинхронное взаимодействие со всеми последствиями, использование нетпакетов для загрузки/сохранения и для передачи сообщений, масса кода, который реально ничего не делает в сингле, но засоряет почти каждый модуль.

 

В качестве наглядного примера последствий можно привести последовательность загрузки/создания игры. В сущности концептуально простая последовательность действий - загрузить уровень, загрузить алайф, загрузить в него спавн/сейв, вывести в онлайн объекты уровня - превращается в предельно мистическое действо из пересылки кучи сообщений с сервера на клиент и обратно, выполнением по шажку за раз с пересылкой подтверждения туда-сюда, ожиданием ответа на каждой стороне и т.п. При этом в сингле масса кода, который задействован в сетевой игре, не работает, но понять, что работает, а что нет, нереально. Отладку этого дела невозможно описать цензурными словами.

 

Или использование нетпакетов для передачи сообщений. Понятно, что это исходно была сеть, и пакеты были собственно сетевыми пакетами. Но в сингле то сети нет, а пакеты остались, просто ходят через всякие очереди в памяти или даже во многих случаях (в частности от клиента к серверу) просто вызывается функция посылки сообщения, ей передаётся нетпакет с аргументами, этот нетпакет тут-же безо всяких очередей распаковывается и вызывается функция, которой эти аргументы передаются. Можно было бы для сингла просто вызвать оконечную функцию и передать ей эти аргументы, при этом было бы невозможно ошибиться с порядком распаковки. Даже для асинхронной передачи сообщений (как например от сервера к клиенту) в сингле можно было бы использовать нормальные очереди сообщений с типизированными параметрами.

 

Это просто пара моментов, а их можно назвать ещё много.

 

В общем, предлагаю высказаться на эту тему. 

[abramcumner 1 159]

@Malandrinus, нет-пакет - это просто буфер с удобными методами для записи в него. Какая разница как он называется.

Можно написать над ним обертки для паковки/распаковки конкретных сообщений.

Обмен сообщениями между объектами - это хорошо. Надо и дальше его развивать. Выкинуть g_actor.

 

Оффлайн/онлайн и два вида объектов нужны по-любому. Это очень здравая идея.

 

Ну и сначала, конечно надо определиться, что ты хочешь сделать в движке. Вон RoH пилят кооп в сталкере, им выбрасывание сетевой архитектуры совершенно не в кассу.

 

> сетевая архитектура движка

-

Все эти сообщения, объекты и все такое - это зародыш многоагентной системы. Это один из тех элементов, из-за которых мне нравится сталкер.

 

> разные среды разработки (и в сущности разные языки) самого движка и SDK

+

Вообще это не очень плохо. Луа, с++, шейдеры, конфиги, хмл как-то переживаются. Проблемы в билдере.

Сам пробую перенести СДК в студию, пока все печально.

 

> архитектура, основанная на dll, а не на статических библиотеках

+

Тут плохи не сами длл, а то, что движок по факту монолитен, но раскидан по разным длл.

Достаточно легко можно собрать один экзешник, но зачем?

 

> разные версии рендера

+

Но они по-любому будут. Уберешь р1, добавятся как минимум р5(дх12) и вулкан.

На гитхабе к примеру пилят опенгл рендер. Главное меню заводилось полгода назад.

 

> абсолютная недокументированность кода

+

Изменено 23 Августа 2016 пользователем abramcumner

[Expropriator 2 118]

@Malandrinus, почему же основатели GSC, решили писать новый двиг? Что им этот не понравился? Двиг хорош - в плане оптимизации, один из лучших, по сравнению с UDK (например). Качество картинки лучше, по сравнению с пластмассовой Унити. Физика даже лучше, чем в id Tech (Rage). Есть и минусы по сравнению с современными платными и закрытыми движками.

Я не могу давать оценку коду самого движка, так как не компетентен, нуб короче.

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

Считаю, что есть потенциал развития у X-ray, но при наличии кадров, способных его раскачать.

Изменено 23 Августа 2016 пользователем Дизель

[Malandrinus 615]

@abramcumner,
 

 

нет-пакет - это просто буфер с удобными методами для записи в него. Какая разница как он называется.

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

Можно написать над ним обертки для паковки/распаковки конкретных сообщений.

Это костыли, просто заметание проблемы под ковёр.

 

Обмен сообщениями между объектами - это хорошо. Надо и дальше его развивать.

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

Выкинуть g_actor.

Ну в сингле всё вертится вокруг актора, так что не видно большого зла в том, что мы храним на него указатель.
 

Оффлайн/онлайн и два вида объектов нужны по-любому. Это очень здравая идея.

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

Вон RoH пилят кооп в сталкере, им выбрасывание сетевой архитектуры совершенно не в кассу.

Моё сугубо личное мнение, что это достаточно бесперспективное занятие. Как там кстати дела у Сурвариума? Они уже запилили монстров в свою игру?
 

Луа, с++, шейдеры, конфиги, хмл как-то переживаются.

Про Lua и его роль вообще отдельный разговор. В свете работы с открытой архитектурой я бы эту роль очень сильно пересмотрел в сторону урезания.
 

Проблемы в билдере.
Сам пробую перенести СДК в студию, пока все печально.

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

Достаточно легко можно собрать один экзешник, но зачем?

Во-первых, не легко. Во-вторых, dll в каком-то смысле "заразная" архитектура. Если два модуля сделаны в виде dll и оба использую третий, то его тоже надо делать в виде dll. Пример - идиотский модуль xrAPI, содержащий что-то вроде десятка переменных, но который обязан быть в виде dll, поскольку используется всеми остальными модулями. Это всё крайне затрудняет реорганизацию кода.
 

движок по факту монолитен

Ну не совсем так. Даже сейчас вполне просматривается структура: ядро, GUI, AI, звук, физика и т.д. Вообще конечно разбивка на модули - ещё один масштабный разговор, но вот хотя бы экзешник и xrGame - это на самом деле один модуль. Если и выносить что-то оттуда, то по совершенно иным критериям, нежели как это сделано сейчас. Ну вот скажем GUI и AI я бы вынес в отдельные проекты и ещё завёл бы отдельный проект под глобальные абстрактные интерфейсы. В xrGame же на самом деле жуткая смесь из половинки ядра, AI, GUI, каких-то интерфейсов, части сетевого кода и т.п.
 

Но они по-любому будут. Уберешь р1, добавятся как минимум р5(дх12) и вулкан.

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

На гитхабе к примеру пилят опенгл рендер. Главное меню заводилось полгода назад.

Можно поинтересоваться, а зачем? Перенести движок на какую угодно иную платформу, где мог бы потребоваться OpenGL, - совершенно нереальная затея.

 

@Дизель,

почему же основатели GSC, решили писать новый двиг? Что им этот не понравился?

Полагаю потому, что тоже сочли потенциал его развития исчерпанным в его нынешнем виде. Впрочем, идея "переписать всё с нуля" на мой взгляд тоже неправильная. Это никогда не заканчивалось хорошо =)

 

Двиг хорош

 

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

 

 

Про очереди сообщений и нетпакеты могу добавить ещё немного лирики. Я насчитал в движке что-то около четырёх или пяти очередей сообщений разного типа и бесчисленное множество разномастных самопальных систем для организации колбеков. Это к разговору об организации полноценной многоагентной системы и всего такого прочего. В первую очередь нужна унификация обмена информацией. Если уж использовать асинхронный обмен сообщениями, то на основе строго одного механизма (и это ни коем случае не должно быть уродство в духе нетпакетов!). Тоже самое касается системы колбеков (делегатов/ивентов/событий).

Изменено 23 Августа 2016 пользователем Malandrinus

[abramcumner 1 159]

Как там кстати дела у Сурвариума? Они уже запилили монстров в свою игру?

По-моему нет. Но я за ним не слежу. Пока там не будет условно говоря ПВЕ, он мне не интересен.

 

Можно поинтересоваться, а зачем? Перенести движок на какую угодно иную платформу, где мог бы потребоваться OpenGL, - совершенно нереальная затея.

Моё сугубо личное мнение, что это достаточно бесперспективное занятие.

Ну примерно как возиться с движком сталкера. Тоже непонятно зачем и бесперспективное занятие при куче открытых развивающихся движков.

Глобально если смотреть, переносу на другие платформы мешает только ДХ. Если осилить рендер, то остальное по сравнению с ним ерунда.

Кооп - мне кажется, все хотели бы пройти сталкер в коопе

 

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

Skyloader делает что-то похожее(на скрине видна сетка и вейпоинты???) на базе встроенного ЗПшного редактора погоды.

 

Как-то все в куче неудобно обсуждать. Надо или отдельные темы завести или вообще проект на гитхабе и там обсуждать каждую идею по отдельности.

 

В OpenXray сделали отдельные xrAICore, xrScriptEngine. Читал кстати обсуждения там?

 

Статические либы и единый экзешник вообще технический вопрос. Должно собраться без сильных правок.

Изменено 23 Августа 2016 пользователем abramcumner

[Malandrinus 615]

@abramcumner,

 

По-моему нет.

Это я пытался намекнуть на перспективы запиливания полноценного кооператива.
 

Кооп - мне кажется, все хотели бы пройти сталкер в коопе

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

Ну примерно как возиться с движком сталкера. Тоже непонятно зачем и бесперспективное занятие при куче открытых развивающихся движков.

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

Skyloader делает что-то похожее(на скрине видна сетка и вейпоинты???) на базе встроенного ЗПшного редактора погоды.

В моём воображении это выглядит как отдельное окно с редактором. Чтобы можно было на два монитора разнести.
 

Про ДЛЛ. Мне кажется только в рендерах есть проблемы с переносом в статические библиотеки. Если оставить один рендер, то соберется.

=) По факту моих экспериментов как раз рендер пришивается относительно без проблем (он практически независим от всего остального). Больше всего проблем при сборке экзешника и xrGame. Короче, "легким допиливанием" там не обойдётся. Идут проблемы линковки, конфликтующих общих данных и функций, разделяемых между проектами модулей и т.п. Проблема в размере проекта. Количество этих конфликтов просто зашкаливает.
 

Чем проект с вариантами сборки, отличается от четырех проектов с общими частями?

 
Я ведь уже сказал. Многочисленные общие файлы между всеми проектами. Это делает общую структуру уязвимой к изменениям. Тронул там - полетело здесь.

Про pipes ответ снят? Я веду речь о чём-то вроде делегатов или слотов из boost (идея у колбеков/евентов и очередей сообщений на самом деле одна и та же). Не знаю, как можно не видеть проблемы в использовании нетапкета как контейнера для аргументов сообщения. Меня они напрягают. Когда при отладке в обработчике я вижу безликий буфер, то совершенно невозможно понять, что там на самом деле находится. А то, что прочиталось, - это на самом деле то, что туда было записано? А я не сместился на байт? А что там за ещё данные вслед за теми, что я уже прочитал? А если пакет пересылается дальше с установленной позицией чтения? Я никаким чудом не догадаюсь, что там дальше за данные, пока не поймаю его в очередном обработчике (который ещё найти надо) и не разберу досконально последовательность чтения. Это же мерзость!

[Expropriator 2 118]

Можно обратится к богу? Господи, да помоги же Юбисофту бесплатно приобрести права на Сталкер, желательно бы компанией разработчикофф Фар Края.

А вся беда то в АИ-сетке и хвалёном интеллекте и симуляции жизни ботов, который-которая тупой-тупая до безобразия. Сейчас будет критика.

 

Вообще этот двигатель не рассчитан на серию игр Сталкера. Этот двиг, как раз бы ништяк, подошел под проект Казаки. Потому его и забросили разрабы Сталкера, морально и физически устарел.

Изменено 23 Августа 2016 пользователем Дизель

[HellRatz 2 892]

 

 

А вся беда то в АИ-сетке

И не только в аи-сетке (Вообще про маппинг, СДК нужно капитально фиксить). Честно говоря, не самый лучший метод управления ботами на карте, на мой взгляд. Просчеты укрытий, вот это вот все. Но что есть то есть.

 

 

 

Вообще этот двигатель не рассчитан на серию игр Сталкера.

Он на что угодно, хоть на гонки сгодится, имхо.

[abramcumner 1 159]

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

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

И не должно быть делегатов/сигналов скрывающих такие прямые вызовы.

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

 

Запросто в движке могут быть такие места, где вместо отправки нет-пакета можно вызвать функцию. А может нет-пакет там и не просто так.

 

У нет-пакетов простая абстракция: создаю сообщение, записываю все что надо, отсылаю. Ничего ужасного в ней нет.

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

[Expropriator 2 118]

 

 

хоть на гонки сгодится

Не лучший вариант. Вообще физика ODE не популярна почему то. А возможно из-за кривых рук создателей техники? 1602 поддерживает массу более 10 тонн, так вот там модели, если увеличить массу в три раза, то ведут себя нормально.

[abramcumner 1 159]

@Дизель,@HellRatz, а что не так с аи-сеткой, укрытиями и управлением ботами?

[Expropriator 2 118]

@abramcumner, да просто, не везде можно аи сетку воткнуть, там где ГГ лазит. Тупят что то боты. Про укрытия, это костылями можно делать, как в Фаркрае, применив точки для укрытий, можно даже вейпоинтами, а к динамике, то костями специальными. Нужно только знать, чего я как раз и не знаю.

[HellRatz 2 892]

@abramcumner, ну на данный момент аи-сетка ограничена сама по себе - большие уровни не сделать. Так же она строго привязывает мобов к ней, и они не могут залезть везде, где пролезает ГГ. Ее создание - это целая куча времени, а затем ее еще и править нужно в большинстве случаев, удаляя нулевые ноды и проч., что тоже капитально отнимает время, в противном случае проблемные места будут вызывать затупы мобов. Ну и наконец компиляция аи-сеток, приличная сетка может компилироваться часов по 5 на мощном ПК.

[abramcumner 1 159]

@abramcumner, ну на данный момент аи-сетка ограничена сама по себе - большие уровни не сделать.

Это правится. Хотя особого смысла нет.

 

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

Логично. Вся аи-навигация такая.

 

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

Ну это не недостаток аи-сетки, а недочеты алгоритма генерации или редактирования.

 

Ну и наконец компиляция аи-сеток, приличная сетка может компилироваться часов по 5 на мощном ПК.

Долго просчитываются укрытия. На драфте сетка мгновенно же считается. А просчет укрытия наверное можно и пооптмизировать.

@abramcumner, да просто, не везде можно аи сетку воткнуть, там где ГГ лазит.

А там и альтернативы не пролезут.

 

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

То есть руками расставлять? Ручное редактирование же и не нравится в аи-сетке

[HellRatz 2 892]

Хотя особого смысла нет

В плане? Не будут использовать это по назначению? Или это приведет к поломке иных аспектов игры?

Вся аи-навигация такая.

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

это не недостаток аи-сетки, а недочеты алгоритма генерации

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

А просчет укрытия наверное можно и пооптмизировать

Вот это было бы не плохо.

Изменено 23 Августа 2016 пользователем HellRatz

[Expropriator 2 118]

А там и альтернативы не пролезут.

? Я про то что генерация нодов аи сетки не происходит на подъёмах, в узких местах. Даже в помещении бывают у стен пустые места, где боты стоя в полметре не видят у стены ГГ.

 

 

То есть руками расставлять?

Я разбирал Фаркрай и точно скажу, что к динамическим объектам боты атачатся в боевой схеме. А вот для статики я не в курсе, возможно там есть просчёт укрытий, но там нет аи-сетки точно.

Изменено 23 Августа 2016 пользователем Дизель