proper70

Всем привет! Подскажите что может быть: плагин для ТС вдруг перестал читать DBшки. Архиваторный работает а вот explorer - вдруг перестал. Ничего не переустанавливал не делал не правил. На ноуте - все работает, а на основном компе - перестало. Видно что читает, пауза есть, а потом пустой список. Все фильтры отключены, все очевидные вещи проверил. В чем может быть дело? win 7 TC 8.01 Все, разобрался) файл thumbs.db затесался в папку с игрой) еще и скрытый, зараза) Удалил и все прошло)

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

В дополнение к таблице _G: Если через кейлоггер или еще как-то вызвать команду _G[имя скрипта] = nil, то движок вновь перекомпилирует указанный скрипт при первом к нему обращении. Что это дает? Это дает то, что если вы отлаживаете какой-либо код, то нет необходимости делать сейв/лоад после каждой правки. Если мы, допустим, правим файл amk.script, то достаточно после сохранения правок через кейлоггер вызвать _G.amk = nil и все - движок перекомпилирует его по новой и все изменения тут же вступят в силу без очередного сейв/лоада. Жаль, что эту фичу я для себя открыл только сейчас. Сколько времени можно было бы сэкономить. Это работает для всех файлов кроме биндеров. Дело в том, что для каждого объекта биндер зачем-то компилируется отдельно, поэтому чтобы увидеть изменения, например в bind_monster.script, то нужно написать _G.bind_monster = nil и заспавнить нового монстра. И на новом объекте изменения уже будут применены.

Это из мастераддона. Я вводил этот поршень, чтобы нормально сдавались по хомячеству особые предметы. Для чистой Соли - не нужен. В ОП-1 он стоит везде, где надо, только про Гавра я забыл) в ОП-2 также будет стоять везде где надо. Без него при отбирании контейнеров, спальников и маячков будут выскакивать соответствующие меню, при отбирании энергетиков ГГ не будет хотеть спать и т.д. Это поршень на время его активности отключает срабатываение калбеков на потерю особых предметов) Почему у одних вылетает, а у других - нет, я не знаю. Видимо разные сборки. Только что глянул чистую соль от Архары из шапки темы, на которой собирался ОП-1 - там этой правки нет)

По замкам: только что проверил сапсановскую правку - вылетает точно с тем же логом, что и без нее. В данном случае эта доп проверка, что именно убрали замок из рюкзака, не имеет смысла, потому что сама функция zamok.remove() вызывается из калбека на взятие предмета из invbox, в котором эта проверка уже стоит в движке. То есть этот калбек, а следовательно и функция, не вызывается, если box:clsid() не будет равно clsid.inventory_box. Поэтому эта правка ничего не меняет. Далее: вылет происходит не в функции remove(), в которой дописана проверка, а в функции add(), котора вызывается из калбека на потерю предмета. Вот и получается, что замок удалился из игры при отравлении Гавром, а здесь мы пытаемся получить его серверный объект, которго уже нет, отсюда и вылет с руганью на nil. А вот как раз таки моя правка, добавляющая проверку поршня, и закрывает этот вылет. Я когда делал хомячество, долго пытался понять, что же в этом скрипте делается с замком, и почему функция с именем add вызывается из калбека на потерю, и тоже пытался что-то тут выправить) но в итоге остановился на универсальном варианте, который закрывает не только этот вылет, но и все другие проблемы при удалении из инвентаря всех других предметов, обрабатывающихся особым образом: контейренов для артов, спальников, маячков и т.д. Просто перед удалением выдаем поршень biznes_remove_special_item а после - снимаем. И во всех калбеках, как и в замке, дописываем проверку этого поршня. И тогда особый предмет удаляется корректно - без вылетов и срабатываения калбеков на его потерю) Поэтому в ОП-2 функция удаления предметов при отравлении Гавром выклядит вот так: т.е. все удаляется между поршнем) а в ОП-1 я забыл сюда этот поршень поставить) поэтому по хомячеству замки сдаются нормально - без вылетов, а по Гавру - вылетает)) То есть если в скрипт ОП-1 поставить выдачу и снятие этого поршня, как выше - то вылетов у Гавра по замкам не будет) Или, вариант для чистой Солянки, где нет этого поршня: дописать после строки local sitem = alife():object(item:id()) -- получаем серверный объект строку if not sitem then return end и все - вылетов также не будет) Этот вариант также подойдет и для ОП-1)

Совершенно случайно нашел истинную причину, почему бьются сейвы в Лиманске, если сохраниться рядом зомби и изломами, бились сейвы в ОП-1 в Путепроводе, бьются сейвы если не зачистить территорию после взятия некоторых тайников Кости, когда спавнятся зомбированные сталкеры и зомби одновременно. Вот цитата со stalkerwiki: так и сделал) оставил у всех сталкеров species = zombie а всем зомби и изломам поставил species = zombi завел эту новую группу в game_relations.ltx и поставил ей такие же параметры друг-враг, как и у zombie загрузил имевшийся у меня сейв в Лиманске, и сохранился у фонтана, где бегали и неписи и моснтры зомби, и загрузил этот сейв. И - о чудо - сейв загрузился!!! То есть бились сейвы, где зомби-неписи и зомби-монстры были рядом. Подобное есть по тайникам Кости, где идет спавн при взятии тайника - там была такая же проблема) теперь и она решена)) По этой же причине в солянке не работали изломы в x-16 и Архара был вынужден их убрать оттуда из спавна - потому что там терлись неписи/зомби, и они вместе приходили в онлайн. На Янтаре нет битья сейвов потому, что там нет монстров зомби и изломов, а иначе была бы та же проблема)) Здорово, только вот пост не совсем в тему... ColR_iT

Наконец-то победил причину автозавершения квестов на защиту барьера и им подобным после сейв/лоада) Найдена и вырвана с корнем глубоко сидевшая в скриптах ошибка еще от ПЫСов, что в сейве не сохранялся ИД смарта, от которого надо защищать другой смарт) Этот ИД задавался при выдаче таска, но при сейв/лоаде он терялся, и после лоада это ИД было = nil. Но ее легко было бы выловить, если бы при запросе состояния несуществующего гулага возвращалось заведомо несуществующее значение, например -1. Но xr_gulag.getGulagState() при несуществующем гулаге возвращает 0, или состояние неактивного, пустого гулага. Вот проверка и срабатывала, что гулаг зачищен, и задание выполнялось)) Это, конечно, досадная оплошность со стороны того, кто делал скрипты гулагов, и, если бы не она, то это все было бы выявлено и поправлено еще в далеком 2007 году) а так эта проблема дожила аж до 2014 года)) И, наконец, она вылечена)) Правка этой ошибки в общем случае требует НИ, так как в нетпакет пишется новое значение и меняется его размер. Но можно использовать технологию двухэтапного подключения этой и подобных ей правок, без начала НИ. Для этого нужно в методе save выдать поршень, и в методе load его проверять при чтении нетпакета. Тогда на старых сейвах до правки будет читаться старый нетпакет, а на новых - новый) Вот правка автозавершения на task_manager от Народной Солянки на версии 1.0006:

Привет! Добрый человек прислал мне вот эту прогу:http://rusfolder.com/39246424 Эта прога позволяет просматиривать и, что самое главное, редактировать настройки дальностей сиышимости звуков в Сталкере без использования СДК. Крайне удобно, когда нужно подобрать дальности слышимости или громкость без необходимости после каждой правки каждый раз прогонять звук через СДК. Один раз прогнал - и дальше настраиваешь уже в этой проге. Прога импортная, поэтому все на инглише. Но там все просто - разберетесь. Чтобы открылись ссылки на форум и тему в ридми на сайте gsc-game.com, переключите сайт на английский режим перед открытием ссылок) Думаю, имеет смысл вынести этот пост в шапку этой темы, ибо многим она будет полезна) Ссылку поправил. Была нечитаема. BFG

Людмила, есть запрет)) вот его логика: То, что запрет стоит не в алспауне а вынесен в cfg файл, ничего не меняет - все работает в обоих вариантах. Вот скрипт из xr_logic, обрабатывающий этот момент: тут просто рекурсивно вызывается чтение схем уже из другого ini файла. И запрет по смартам также читается) проблема именно в том, что я написал) Если ему поставить walker - то сразу вылет по путям. И я спавнил его, находясь в туннеле рядом с ним, т.е. он сразу был в онлайне. А в гулаги объект с логикой движок затягивает, мне думается, только если он находится в оффлайне. Сам лично с этим столкнулся, когда начинал спавнить неписей, и забыл прописать запрет на смарт) Непись четко был на месте и отыгрывал логику, пока он был в онлайне. Но стоило мне уйти с локи и вернуться, как он пропадал) А здесь контрик сразу выходил из-под логики home, сразу после спавна, находясь в онлайне. И вылет по путям сразу после спавна при прописывании схемы walker также говорит об этом, ибо ему просто некуда идти - все пути отрезаны рестрикторами) А если бы не было запрета на смарт, то ничего бы не вылетало - он просто уходил бы в гулаг и все. А когда я прописал ему этот рестриктор, то все - и вылет по walkery пропал - он стоял в точке, и home заработал - он никуда не уходит) Так что проблема была именно в этом) ЗЫ: а насчет прописывания запрета на смарты в алспауне, а не в конфигурационном файле я тоже сначала думал, что не будет работать) но потом покопался в алспауне и увидел, что так (запрет стоит в cfg) стоит в Соли у Молнии в МГ - dead_city_molniy. А также у некоторых ООПшных персонажей. И никто ни разу не жаловался, что они куда-то пропадают)

Решил поделиться, как мне думается, полезной информацией для мододелов, т.к. поиском особо ничего не находится, а с подобной проблемой я уже сталкивался не раз) Суть в том, что мы спавним непися/монстра с конкретной логикой и путями, и при спавне спустя несколько секунд получаем вылет any vertex in patrol path... И ничего не понятно: АИ сетка есть, причем сплошная, никого и ничего рядом, но вылетает стабильно. Как я выяснил опытным путем, проблема в том, что непися/монстра удерживают или не пускают in или out рестрикторы. Т.е., чтобы этот вылет ушел, нужно в алспауне прописать объекту строку base_out_restrictors = [имя ограничивающего рестриктора] или base_in_restrictors = [имя ограничивающего рестриктора] Причем эта проблема есть не на всех локах, а только на тех, где ПЫСы зачем-то понаставили этих ограничивающих рестрикторов. Назначение их мне не совсем понятно, ведь зону нахождения любого монстра/непися можно ограничить его логикой mob_home, walker и т.д - зачем еще эти дополнительные ограничения в виде зон? Я сталкивался с этой проблемой на Янтаре, Х-16 и на ЧАЭС-2. Причем, если у монстра прописана логика mob_home, но не задана указанная выше строка, то монстр молча выходит из-под этой логики и передается под управление движком, т.е. затягивается в любой свободный гулаг. Эта проблема до сегодняшнего дня имела место с Соляночным квестом на фото контролера в туннеле на Янтаре, когда он, находясь под логикой mob_home, тем не менее постоянно уходил в разные гулаги Зоны, и квест выполнить было очень проблематично. Я для пробы прописал ему логику walker с одной точкой walk и look, и сразу получил указанный выше вылет. Тогда я прописал ему в алспауне вот эту строку: ; cse_alife_monster_abstract properties base_out_restrictors = yantar_tunnel_restrictor_4 И все - и вылеты пропали, и контрик никуда не уходит) т.е. злосчастная проблема с ним наконец решена) рестриктор я выбрал по координатам, ближайший, который был прописан одному из снорков, которые спавнятся в туннеле) Может, эта информация пригодится мододелам в их нелегком труде))

Еще вопрос возник: Можно ли как-то отследить, что гг погиб именно от аномалии? Неважно какой, просто от аномалии? Я вижу пока только вариант проверки по расстоянию до ближайшей аномалии, но он чреват ложнгыми срабатываниями, когда гг застрелили рядом с аномалией) Есть ли какой надежный способ определить это в ТЧ?

Artos, последний вопрос: как может быть хит "пустой" (amount=0), если непись погиб от одного-единственного выстрела в голову? Из ствола актора. При этом он стоял на абсолютно ровной открытой местности, т.е. ни за что не цеплялся, и погиб именно от пули актора? А у меня во вчерашнем, более полном тесте, также, как и у тебя, amount практически везде = 0, и это при том, что я зачистил весь АТП - более 15 бандитов? Они все что, погибли, споткнувшись об ветки?) Или я все ещё чего-то не понимаю, а в ТЧ хит калбек работает правильно, и amount=0 в момент, когда непись погибает - это именно так и должно быть?

Господа! Всё, что вы написали выше, про умное выпадение и прочее - это всё относится к монстрам. А я спрашивал про неписей. То, что для монстров кость передается, я даже проверять не буду - по скриптам видно, что она обрабатывается и работает. А вот для неписей - она всегда = 0. Убедиться в этом очень просто: в мотиваторе в самом начале hit_callback напишите вот это: get_console():execute("load ~~~ npc: "..self.object:name().." bone_index:"..bone_index) и постреляйте по неписям по разным частям их тела. Сами всё увидите) Вот вырезка из моего лога, когда я воевал с бандитами на АТП: Как видно из лога - кость не работает. Я стрелял по разным частям тела, рукам, ногам, туловищу, взрывал неписей гранатами - результат один) Ну да ладно) я могу обойтись без этого, просто хотел кое-что сделать по неписям, но обойдусь без него))

Artos, попробовал. Да, так работает, только у неписей bone_index при любом хите всегда = 0. Похоже в ТЧ этот параметр просто не обрабатывается. И я не нашел ни одного использования этого параметра в чистом ТЧ и в Солянке. Этот параметр просто передается из функции в функцию, гуляя по логике и калбекам, но нигде не проверяется на значение...