makdm

В спавне нужно к имени пути добавить имя смарта.

Биндер в файле xr_motivator.script обрабатывает только онлайновые объекты. При смерти НПС, который находится оффлайн, метод death_callback не вызывается и соответственно не вызывается метод create_release_item класса drop_manager. Соответственно применить метод character_community() к серверному классу объекта просто не получится ( так как его смерть не обрабатывается скриптом ). По идее NIL не должен быть никогда, если только вы сами не передали nil, как аргумент в функцию.

Это я зачем написал? Но вы ведь это не видите. А видите только то, что хотите видеть. В любом случае вы меня не убедили. Я применяю все доступные способы( в том числе и перепаковку нет-пакета ) и методы спавна объектов, в зависимости от поставленной задачи на игровом поле. Вы же пытаетесь доказать что, только через скрипт с перепаковкой нет-пакета и никак по другому. Удачи в модинге!

И что ну-ну. Поучитесь аргументированно доказывать вашу правоту. Я вам про спавн без перепаковки нет пакета талдычу, а вы упорно лезете в нет пакет. И ещё приводите это как весомый аргумент. А теперь посмотрите на всю "портянку", связанную с перепаковкой. Вот зачем она, если я могу любую секцию из all.spawn проспавнить скриптом без перепаковки?

Это смотря что. Если спавн требует перепаковки нет-пакета ( аномалии, вертолёты, рестрикторы те же лестницы), то лучше это делать через all.spawn с меткой spawn_story_id. Есть ещё куча моментов. Попробуйте во время игры проспавнить на крыше рюкзак с хабаром. Его там не будет, потому что скрипт его тут же привяжет к АИ сетке и ваш рюкзак будет валяться внутри помещения, а не на крыше. Или проспавните объект скриптом с различными углами поворота вокруг всех трёх осей. Ну-ну. Так что нужен разумный подход в зависимости от той задачи, которую вы решаете.

Ну не знаю как у вас, а у меня скрипт спавна вертушки по метке spawn_story_id выглядит так: function spawn_ids_objects( actor, npc, p ) if p then local ini = ini_file( "game_spawn_story_ids.ltx" ) for k,v in pairs( p ) do local spawn_story = ini:r_string( "spawn_story_ids" , v ) local section_number = alife():spawn_id( tonumber( spawn_story ) ) alife():create( section_number ) end end end А теперь посмотрите на свою "портянку" под спойлером и ещё раз всем расскажите про 3 гига.

Делается всё проще. Через sdk или ac\dc ставим объект вертолёт с меткой spawn_story_id. При старте игры объект удаляем. А в нужное время спавним по этой метке прямо из all.spawn Никакие перепаковки пакетов не нужны.

@tatarinrafa, работой детектора управляет движок сталкера. В конфигах можно прописать, что конкретно "видит" детектор.

Бтр поддерживает spawner Что мешает через SDK или acdc поставить БТР на локации, прописать ему логику, и в нужный момент игры по условию перевести его в он-лайн?

@zSCORPz, значит НПС находится в рестрикторе, в котором запрещено включение фонаря. Логика sr_light

Каких границ? Полтергейстам пишешь логику mob_home На точку path_home ставишь OUT рестриктор. В логике прописываешь out_restr = имя_рестриктора И никуда он за радиус рестриктора не улетит.

Так попробуй: function check_barret() local rifle_in_slot=db.actor:item_in_slot(2) if rifle_in_slot and rifle_in_slot:section() == "wpn_vintorez" then db.actor:give_info_portion("barret_on") news_manager.send_tip(db.actor, "%c[25,240,25,25]wpn_vintorez ON", nil, nil, 20000) else db.actor:disable_info_portion("barret_on") news_manager.send_tip(db.actor, "%c[25,240,25,25]wpn_vintorez OFF", nil, nil, 20000) end end

@AndrewMor, я хоть и не работаю на ТЧ, но респавнер я бы сделал немного по другому. Я бы спавнил прямо секцию из all.spawn. Для этого в секции полтергейста я бы добавил после END метку секции, например так: [logic] cfg = scripts\logic\zaton\poltergeist9.ltx END spawn_story_id = 8 В файле game_spawn_story_ids.ltx прописал бы: [spawn_story_ids] zaton_poltergeist_09 = 8 Вызов респавна: spawn_ids_object( "zaton_poltergeist_09" ) Функция: function spawn_ids_object( name_object ) local ini = ini_file( "game_spawn_story_ids.ltx" ) local spawn_story = ini:r_string( "spawn_story_ids" , name_object ) local section_number = alife():spawn_id( tonumber( spawn_story ) ) alife():create( section_number ) end Никаких перепаковок пакета с помощью функций АМК не нужно.

Использовать нужно схему remark Сначала анимация - целится в заложника. Выдача поршня - переключение анимации на стреляет в заложника. Конец анимации - переход в walker

ID того, кто "шлёпнул" НПС хранится в его же нет-пакете. Всегда можно прочитать пакет НПС-трупа и получить ID киллера. Единственное неудобство - это нужно заранее позаботиться о получении серверного класса объекта НПС-трупа удобным для скриптёра способом. Как-то так.

Мне всегда нравились такие ответы на вопрос. Код ничего не возвращает.

В ЗП не нужно это делать. Движку вообще "по барабану" прописаны поршни или нет.

У меня всё работает. Ищите ошибку у себя.

@Mododel15, так попробуй:

Спасибо за ответы! По-ржал от души! Знаете, чем отличаются американские форумы от русских? На американском форуме задаёшь вопрос - все пытаются тебе помочь. На русском - при ответе на вопрос, все начинаются мериться своими .... познаниями. Вообще-то вопросы были не про хранение переменных, а немного о другом: 1.Почему при обработке 62 объектов игра идёт стабильно без вылетов и всё в игре работает так, как задумано разработчиком? 2.Почему при спавне 63-го объекта - движок "не видит" отдельный файл в папке Scripts???

В том, что нет-пакет ГГ не вмещает в себя все сохраняемые таблицы переменных, используемых в моде. А в чём тут извращение? Есть другой способ? Тогда зачем разрабы Сталкера всё это проделывают в методах save и load в биндере актора? @UnLoaded, если ты про то, что зачем нужен спавн и удаление, то это привычка защиты "от дурака". Вдруг, кому-то ( например мне ), где-то в середине игры придёт в голову добавить скрипт и пройтись по всем объектам и отделить нужное от мусора, а сам мусор отправить "в топку". Вот чтобы объект не оказался в "мусорке" я , таким образом его и защитил. Хотя, можно в начале игры добавить объект и работать с ним постоянно. Возможно перестраховка, но мне так спится лучше.

Раскопал я этот "парадокс". Вообщем дело было так: При сохранении игры происходит спавн объекта и в его STATE часть нет-пакета сохраняются данные. При загрузке, данные считываются из STATE части нет-пакета объекта, а сам объект удаляется. Это я так думал. Но удаление объекта не происходило, т.к. я пытался сделать вот такой финт ушами: function se_store_obj:STATE_Read(packet, size) cse_alife_dynamic_object.STATE_Read(self, packet, size) -- Вынесено в объект из пакета ГГ release_body_manager.get_release_body_manager():load(packet) sr_psy_antenna.load(packet) sim_board.load(packet) xr_sound.actor_load(packet) xr_statistic.load(packet) alife():release( self, true ) end Т.е. пытался удалить сам объект прямо внутри метода STATE_Read Таким образом в игре накопилось 62 объекта, в которые записывались данные при сохранении и считывались 62 раза при загрузке. При 63-м сейв\лоад движок начал терять файл в папке scripts Я удалил вот это безобразие alife():release( self, true ) и всё пошло как по маслу ( за исключением того, что при загрузке и сохранке движок писал/считывал 63 раза одно и то же в пакеты разных объектов ) Ладно это поправимо. Вынес айдишники объектов в таблицу и затем удалил. Но почему движок делал 62 попытки удалить объекты и это "проскакивало", а на 63 объекте "стал запинаться" и терять файл в папке scripts, вот это пока для меня осталось непонятным.

Не у меня одного. Ещё у тестера такая же проблема. Движок просто не видит файл в папке scripts

Всем привет! Не знаю куда написать, поэтому пишу сюда.( В случае чего модераторы меня поправят )

Оверрайд им пропишите: combat_ignore_cond = {=fighting_dist_ge(30)} true, false Будут "шмалять" с 30 метров.