Стало немного скучно, и я по наводке Вирусмана решил сделать сабжевую хрень Заодно сделаю топик на тему нвн, каких тут почти не осталось

Суть работы сабжа проста. Обычно на коммонеров вешают что-то типа рандомволка, и они тупо слоняются туда-сюда, втыкаясь во все углы. Либо просто вырубают им ИИ, чтобы они как буратины стояли на месте (ммо-стайл). Мне было предложено искусственному интеллекту добавить немного... интеллекту Заставлю неписей заниматься делами: кто-то утром пойдёт на работу (а вечером - домой), кто-то - молиться, кто-то - бухать и т.п. Всё без индивидуальных маршрутов и скриптов.

Что уже сделано: самое скучное - поиск кратчайшего пути по дереву вейпоинтов, ходьба из пункта А в пункт Б хоть через 10 локаций.
Что предстоит сделать: самое весёлое - запрограммировать болванчиков на свободу выбора жизненных приоритетов.
Нафига: а хз, для разминки мозгов. Ну и мб Экзису всё-таки пригодится.

В любом случае, все наработки я выложу в общий доступ.

Ах да. Есть хитрые идеи творческого плана?

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

драки в баре и разговоры на разные темы, аля слухи в обливион

Ссылочку?
Это в планах изначально. Помимо базовой цели типа работы стоит придумать аффиксы (в стиле дьяблы) - алкаш имеет +Х% шанс пойти в кабак после или вместо работы и т.п.
Запишу.
А в скайриме есть ещё клёвые барды. Сама игра довольно быстро наскучила, но вот бардов запомнил хорошо.

Тык!
Насколько я помню, эти. Я тестил с плащами - большинство работает нормально, но есть анимации, где плащи выглядят странно, например, лежание на боку.

Мне кажется большее внимание стоит уделять реакции на окружающий мир, как уже сказали выше на дождь например. Ведь реалиях сколько-либо PW-шного модуля окружающий мир меняется довольно прилично.. И как будет смотреться например нпс, по вечерам отправляющийся в таверну побухать, когда например днем город осадили скажем орки. Понаубивали кучу народу, да и таверну собственно подожгли.
Вообще мне видится успешный ИИ именно в "прокачке" реакционного интелекта (тип ситуации > равнозначные_варианты_решения), вопрос в том как это с точки зрения "программирования(наращивания этого списка реакций)" удобнее организовать..
Универсальный "механизм принятия решений" для выполнения того или иного действия НПС , хз.. мне кажется это вообще несбыточная мечта .

Я вот пытался сделать кастомный АИ для мобов (не для гражданских, а вообще – в плане для каждого типа криттеров свой отдельный индивидуальный АИ). Тут мне кажется делать универсальный скрипт будет слишком громоздко и в итоге не выйдет ничего хорошего. Лучше для каждого типа криттеров делать индивидуальный с учетом минимума базовых задач (деревенский пьянчуга отдельно, деревенский плотник отдельно и т.п.). Так оно будет смотреться в игре более ярко и соответствующе ролям НПС.
Например из готовых АИ класса «бродилки» у меня есть летучие мыши (практически чистый рендумволк со стилизацией и минимумом повадок) + куропатки (тоже практически чистый рендумволк с закосом под повадки голубей). Из более продвинутого АИ готов крысиный (тут уже использовалась индивидуальная блок-схема поведения и повадок делающая из криттеров действительно нечто похожее на мелких хищных стайных животных, ориентирующихся в игре самостоятельно в соответствии с обстоятельствами). Вот к примеру как выглядит обобщенно их система поведения. Так же на деле все это можно посмотреть при желании и в модуле.

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

Вообще я думаю задача в пределе - собрать такой суперпупер "фреймворк" используя наиболее рационально все возможности тулсета (не только NWScript), а возможно и НВНХ - чтобы:
-можно было писать(программировать человеку) "поведение НПС" максимально высокоуровнево, с максимальной контекстностью. Возможно стоило обратить внимание на какие-то реально разрабатываемые языки для "обучения " ИИ в мире, там наверное обозначают основные проблемы в этой сфере программирования.

Биовары пошли по пути вейпойнтов и локальных переменных заданных при создании существа, но тут уже только в этом 2 параметра которые нужно регулировать в разных местах вместо одного - уже плохо.

+1, но так или иначе все упирается в создание "леса стратегий поведения" т.е. множества древовидных последовательностей скриптов с АИ

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

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

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

Ден, это скорее проблема реализации Джасперовский АИ очень хорош с точки зрения учёта всего-чего-изволите, но реализован крайне топорно. Пример: функция, отвечающая за каст боевых заклинаний, пробегает почти все их с проверкой вида if(GetHasSpell(SPELL_FREAKING_SOMETHING))ActionCas
tSpell(SPELL_FREAKING_SOMETHING, GlobalTarget), а правильный подход в данном случае - кэшировать в онспавне/онресте существующие заклинания и кастовать их уже из таблицы. С использованием в сомнительных местах NWNX для быстрого доступа к содержимому слотов.

Как вариант, вынести наиболее требовательные к времени исполнения части в NWNX (2.8 API не идеален, но им в отличии от предыдущих версий можно пользоваться без непрерывного потока нецензурных мыслей).

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

С коммонерами этой проблемы быть не должно - у них нет 500 спеллов

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

Вспомнилась одна строчка из песни, которая иногда как нельзя лучше отражает поведение АИ в НВН:

-Если друг оказался вдруг и не друг и не враг - attack!

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

А про высокоуровневость я с тобой не согласен, я имею ввиду что средство в котором можно будет разрабатывать "реакции для ИИ"(программировать этот самый ИИ) должно иметь наиболее оторванность от аппаратной/cпец(в нашем случае можно сказать от NWScript) части и ближе к человеческому языку и построению "логики решений" самого человека, это позволило бы програмировать поведение в общем случае быстрее(за день допустим ты запрограмлишь 20 вариантов ИИ, вместо 10, при равном конечном качестве) чем ковыряясь в дебрях различных событий NWScript и проблемах его применимости.. Мне показалось чтот-то похожее что я имею ввиду http://ru.wikipedia.org/wiki/CLIPS , язык для экспертных систем.

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

Ну тут уже зависит какова ваша цель: создать качественную программу, или качественную игровую среду. Можно использовать гибкий и легко податливый изменениям код, можно поступить еще профессиональнее и сделать его через инклюды… Но как правило для отличного результата в игре не понадобится 100 разных крич – половина от силы, а то и треть; с развитым АИ – единицы. Чтоб получилось хорошо, нужно делать не универсально, а специализированно. Естественно придется много работать, чтобы это сделать.

Вейпоинты – это такой же «якорь», как и нефеншуйно скомпилированные скрипты. Я прибегал к вейпоинтам только в самом крайнем случае и только в порядке прописывания конкретного эвента. Например если у вас есть страж патрулирующий улицы города в определенные часы – проще накидать ему оригинальных вейпоинтов и не морочиться; а если это АИ разбойника который может спавниться в n-различных местах – нужно выбирать: делать ли целый комплекс спавна для этого криттера, включающий ряд однотипных служебных вейпоинтов расставляемых на каждой локации вручную, или написать по большей части казуальный рендумволк с множеством «if» подразумевающих обобщенные событийные триггеры которые могут произойти в этих локациях.
Естественно последний вариант более универсальный; но с другой стороны страж при исполнении тыкающийся по бордюрам клумб, стенам домов и заборам – довольно жалкое зрелище. Вывод – все должно опираться на чувство меры разработчика.

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

А зачем 40 штук в одной локации?
Помниться, на геме1, я ставила 30 мобов и тут же начинались лаги и аи просто не работал. Мне кажется, что на это и не расчитан сервер. В локации 12х12 тайлов (рекомендовано не больше 150 тайлов), оптимально работают 10 мобов, при 15 уже хуже - дык больше и не надо + еще игроки. Для того и существуют экаунтеры (не только стандартные), чтобы спавнить встречи 1-6 мобов.

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

В локациях компании - в городе по 50 нпс стоит и нормально.
я про джаспероский аи, при некоторой настройке он вполне нормальный и не лагает, да при большом кол-ве.

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

По-моему нет необходимости выводить это в отдельно настраиваемую категорию, обычные реакции на событийные триггеры:
- время послеобеденное, погода замечательная – НПС рад и весел, шатается праздно по улочкам, периодами ненадолго вспоминая, куда он шел;
- уже темнеет или вдруг начался дождь/снег – НПС торопится сделать то, что хотел и вернуться под какой-либо кров согреваться;
- «в Богдаде все спокойно» - НПС-страж мерно меряет мостовую шагами от вейпоинта к вейпоинту;
- кто-то кого-то атаковал или другие НПС подняли крик – НПС-стражник спешит на помощь, громко бряцая латными сапогами по мостовой на бегу…
…Ненужно никакого уровня, просто детально запрограммированные события индивидуальные для каждого АИ – смотреться будет намного красивее, чем универсальный переключатель.

Оставлю пока ваши споры, займусь реализацией выбора целей. Просто захардкодить цели и сделать вилку из if-elseif не хочу, ща думаю над реализацией через бд и sql, пока выглядит довольно здраво.

БД и SQL - это само собой, только я, как правило, подобные данные сразу кэширую в локальных переменных (с возможностью их обновления по требованию) и дальше уже работаю с ними. Всякие AI и прочие штуки постоянно используют свои данные, а лезть каждый раз в базу за ними - слишком дорого.
Пиши в аську, если что. Я всё-таки продумывал эту тему в своё время.

Вот ещё что нужно реализовать:

Если НПС видит валяющийся бесхозный шмот, он его осматирвает.
Если вещь неотайдентифаеная, пытается отайдентифаить. Если не получается, говорит "Я понятия не имею, что это", иначе "О, это же то-то!"
Далее решает брать или не брать. Если взял, решает надеть или не надеть. Если перегруз, то жалуется и выбрасывает что-нибудь (не обязательно это же).
Продолжает свои дела.

Если он видит бесхозный сундук\сумку\шкаф, то подходит.
В зависимости от того, закрыт он или нет, и наличия или отсутствия оупен лока, открывает. Далее с содержимым контейнера вышеописаный порядок.

И естественно в зависимости от степени гуманоидности все реакции.

Отредактировано: Да, кстати, сделал только что у себя подбор вещей. Только вот проверку на перегруз не сделал. Есть какая-нибудь функция, которая это проверяет?

Я крыс научил находить и подбирать на локации в пределах «видимости» брошенное мясо/приготовленное мясо/оккупировать трупы.

Можно через GetWeight() посчитать вес инвенторя и сравнивать с вычисляемым текущим грузоподъемом НПС от мода силы.

P.S.: Только тут можно переборщить и будет куча ненужных багов и несуразностей (типа как в Аркануме открыть запертую дверь? – выложить перед ней монетку: НПС увидит ее и подойдет чтоб взять, открыв перед собой запертую дверь).

Всё, вставил проверку на силу. Правда теперь после выбрасывания от перегруза тяжелого айтема пнс начинает идти по делам, потом вдруг замечает выброшенный (им же) айтем и с радостным криком "Ой, что я нашел!" бежит к нему. Подбирает его, перегружается, выбрасывает, и всё заново.

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

Забавно. Клёвый алгоритм сложности O(n^2) вызывает стопроцентный тми, хотя выполняется за полсекунды Элементов немного (пока 60, по-хорошему надо 200+), но в скрипте парочка O(n) и один O(n^2) - вылетает на 20й итерации внешнего цикла последнего Расчёты действительно немаленькие (расстояния, массивы через строковые операции, возведение в степень), но выглядит смешно даже для 2002го.

Завтра перепишу под sql, выкину часть алгоритмов наружу, на трёх O(n) надеюсь заработает и при 200 элементах.

Коль пошла такая пьянка, похвастаюсь и я идеями!
-НПС если находится рядом с плесаблами допускающими собирательство (куст Фенберри, грибы и т.д.) подходит к ним, ставит корзинку и собирает грибки!
-Если на пути НПС встречается какой-то из уличных светильников - он подходит и зажигает или тушит свет в них соответственно ночью и днем.
-Стражник, если рядом с ним "вскрывают" общественный контейнер начинает пристально наблюдать за вскрывающим (как в Леворе вообщемто)
-Если нпс бард - то он иногда может играть музыку, другие персонажи пока поисходит эта игра, проходя мимо могут остановится, сесть и послушать баладу.
-Если рядом с персонажем есть стул и официантка - то он может сесть и заказать какую-то еду, при этом официантка тоже участвует в этой анимации.

хотя конечно это все частные веселушки восновном.



в НВНХ еще нету конструкции подобной "Eval" или "Execute"? Расскажи как имено ты используешь SQL?

Следующая итерация - заставляю воров нормально воровать, как у ПС так и у НПС. Хотя алгоритм прописал, пока воруют очень неохотно.

Нет. Зато есть плагин, увеличивающий лимит инструкций на скрипт или убирающий ограничение вовсе. На волте даже рекомендуют в 2-4 раза лимит поднимать (дефолт ~130к). Но не очень хочется его привлекать, т.к. сервер однопоточный до мозга костей и подобные скрипты будут его тупо тормозить. Если играл на старых серверах, то мб помнишь, как одновременный сейв 30+ чаров на винт вызывал лаги на пару секунд

Раз уж так выходит, что в кап не влезаю, постараюсь скрипты упростить. Иначе в будущем может быть лагодром.
В данном случае немалую нагрузку вызывают 2 вещи - массивы и поиск внутри них во вложенном цикле. Массивов в нвн нет, приходится делать через строку и извлечение/замену подстрок Я хочу попробовать выкинуть массивы наружу (они и нужны только на расчёт пути, раз в полгода то есть) и заодно организовать поиск минимума внутри за счёт субд.

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

Перемудрил – зачем локалки вешать? Просто надо было добавить проверку вещи перед подъемом на массу: если масса содержимого инвентаря + масса обнаруженной на полу близлежащей вещи > максимальной переносимой массы == вещь не трогать, проверять n+1 ближайшую вещь, если она существует; иначе подобрать.
Только тогда проще сделать проверки на «нужность» вещей: если вещь на полу лучше того что одето на НПС – подобрать и надеть; если ее можно использовать (бутылки, свитки, палочки и т.д.) – подобрать и использовать в дальнейшем; если соотношение массы вещи и ее цены выгодное и НПС не перегружен – подобрать и сохранить; если вещь дешевая или НПС уже перегружен – подобрать и отнести выкинуть в ближайшую урну/продать торговцу и т.п..
Только все это ненужный перегруз модуля скриптами – если прям так уж хочется собирать с полу вещи, можно создать специальных неписей-сталкеров которые скажем в какую-то часть дня бродят по городу и подбирают всякий хлам, отправляя его сразу в свой магазин, который открывают для игрока осев на своей торговой точке другую часть дня. Или что-то вроде.

Смысл локалок в том, что НПС не знают изначально массу вещи, поэтому подходят и смотрят каждую и либо подбирают, либо вешают локалку.
Учти ещё, что у них не бывает перегруза и GetWeight на них всегда возвращает 0.
А про магазин - это хорошая идея.

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

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

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

NWNX System

А я просто поискал по "tmi" на волте и взял первое попавшееся среди свежего Там в названии тми есть.
Это как бы его профиль

Это ты что такое там считаешь? - баллистическую траекторию 50 НПС в стратосфере?

Как с контейнерами быть? НПС замечают их, подходят, осматривают и открывают. Действие ActionTakeItem не выполняют. Пришлось на контейнеры на OnOpen вешать скрипт на проверку

Melisse:
Алгоритм Дейкстры для поиска кратчайшего пути по дереву вейпоинтов. При реализации на простых линейных массивах там именно два больших вложенных цикла. Это можно оптимизировать, но нужные структуры данных в нвн просто не сделать (двоичные кучи, фибоначчиевы кучи и т.п.).

Не желая рубить с плеча, я перекинул все "массивы" в мускл (заменив 4 массива одной таблицей) и переложил на него же функцию поиска минимального значения по заданным условиям. Результат - никаких тми, скрипт выполняется за 150мс. Для единичного запуска (для каждого нпс раз в несколько игровых часов) это немного.

Потестирую эту систему на бОльшем количестве точек и мб перепишу на нвнх без мускла, будет ещё быстрее. Сейчас у меня 2 внешних локации и 1 внутренняя, 63 вейпоинта с 1-6 связями. В городе обычно 2-3 связи, в таверне - паутина из точек

Зачем это нужно? Представь город из 10+ локаций. Берём непися, ставим где угодно и указываем идти куда угодно, хоть через 10 локаций. И он пойдёт Причём не лбом в стену, а по дорогам, как все нормальные люди. Причём по кратчайшему пути. Нужны лишь вейпоинты, олицетворяющие сеть дорог, и скрипт.

Anakondar:
Давай всю техническую фигню унесём в соответствующие топики?

denis0k: Главное, чтоб ответ появился, а где - не важно.

MySQL и такое умеет?
Я не совсем понимаю... эти страшные названия алгоритмов и куч, ибо у мня образование другой направленности, но мне интересно.
Тебе мускл сразу возвращает все необходимые данные одним запросом, сам поискав - и так для каждого НПС, но запуск всех спавнов при старте модуля = одновременный запрос n-го числа НПС, он справляется?

там наверное такое извращение многоэтажное получается в запросе . еще поди фильтровать запросы для безопасности.
Почему бы стразу не писать плагин, он же всяко будет быстрее работать, мне кажется, чем связка НВН-НВНХ-MySQL-сервер :?

Плагин писать сложнее и дольше.

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

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

А как решается проблема хербита в локация, где нет игрока - он там либо отрубается,либо запускается с большими задержками. Помнится, нпс заходят в дом и все - пока туда не пришел игрок, он не выйдет.

Ага, следующий не запускается, пока не выполнится предыдущий. Благодаря этому можно устроить нумерацию мобов: модульную локалку-счётчик, инкрементирующуюся при каждом спауне и кричерскую локалку-номер с текущим значением счётчика. Гарантировано все номера будут разные.

«Гет вейт» не работает на криттеров как определялка массы всего их инвентаря – он как раз нужен в тех случаях, когда требуется узнать массу вещи.

Действие «ActionTakeItem» по умолчанию изымает, а не переносит вещь – чтоб описать его в виде транзакции, его нужно использовать через оператор «AssignCommand» для осуществителя транзакции; при этом если осуществитель транзакции не способен взаимодействовать с вещами, использовать вместо него действие «ActionGiveItem» привзянное на объект транзакции с получателем на осуществителе транзакции (конечно при условии что объект транзакции в этом случае может взаимодействовать с вещами):
AssignCommand(oTarget, ActionTakeItem(oItem, oObject));
AssignCommand(oObject, ActionGiveItem(oItem, oTarget)).

P.S.: Кстати у НПС есть 2 слоя инвенторя: обычный (доступный всем) и служебный (доступный только НПС) – я это не отслеживал, но вполне может так случиться что вещь по умолчанию попадает в служебный и далее существует в игре только для НПС. Однако при транзакции вещей (НПС взял вещь – НПС отдал вещь) это не имеет значения.

Просто поставить условие по времени или событийный триггер которые выгоняет НПС из дома. У меня стоят в АИ криттеров аналогичные системы на хеартбите – вроде они работают даже в «свернутом» режиме без игроков в модуле, и криттеры оказываются при появлении игрока там, где им прописано.

Просто - он не используется.

Как определить отсутствие игрока в локации?

Берем дверь, ставим на триггер OnOpen:

и на OnUnLock:

…в результате получаем дверь, которая будучи однажды открыта кем-либо раз в 5 минут проверяет свое состояние, и в случае если она открыта и игрока нет поблизости – затворяет (при необходимости и запирает) себя и прекращает проверки. Система из моего модуля «антиполтергейст» - всегда раздражали самозакрывающиеся двери на шардах…