Malandrinus

Касательно прикручивания аддонов к стволу скриптами. Поэкспериментировал и выяснил следующее: когда устанавливаешь/снимаешь аддон, то ID ствола не меняется, а после снятия аддона его ID становится другим. Т.е. ствол с гарантией не спавнится заново, а только меняются его свойства, а вот аддон наоборот почти наверняка на время установки просто исчезает, а при снятии спавнится в инвентарь заново. Чтобы решить проблему с несоответствием клиентского и серверного объекта можно попытаться сначала перевести объект в офлайн, затем перепаковать, а затем перевести обратно в онлайн. Где-то, мне кажется, я видел примерно такую последовательность действий.

Не обязательно пользоваться функциями АМК. Можно использовать функцию give_game_news из движка игры прямо в колбеке на смерть непися. Прописать там время задержки нулевое и всё. Я подробно описывал эту функцию в старом топике. Вот оттуда информация:

Файл amk_mod.script. Там функция test_for_need_sleep_matras (примерно строка 409). Там во второй части есть такой фрагмент: else if amk.load_variable("block_sleep_menu",0)==0 then if amk.load_variable("gg_need_sleep",0)>20 then local spwn=ui_cheat.cheat(get_hud()) level.start_stop_menu(spwn,true) else amk.send_tip(game.translate_string("not_need_sleep"),nil,nil,5) end else amk.send_tip(game.translate_string("not_need_sleep_nrg"),nil,nil,5) end end Это основные проверки, которые мешают заснуть, и собственно вызов диалога сна. Между else и end Надо закомментировать всё, кроме: local spwn=ui_cheat.cheat(get_hud()) level.start_stop_menu(spwn,true)

Ну если иметь в виду древнюю технологию микрософта для субклассинга контролов, то да, похоже. Однако весь остальной мир называет этим словом как раз таки наследование. Так что лучше этого слова избегать. Хотя какая в сущности разница?! Можно даже миллисекунды: local y,m,d,h,min,sec,ms = game.get_game_time():get() К слову сказать, экспериментировал сейчас с level.set_time_factor и выяснил забавную вещь. Можно установить фактор времени отрицательный, и часики начнут тикать в обратном направлении. Вот сижу и думаю: а не можно ли здесь нарыть решение проблемы с таймером в ТЧ.

Поправлюсь. Не перегруженная, а переопределённая (хотя как перевести "overrided" до сих пор нет точной договорённости). Здесь же как-бы происходит наследование от класса "se_stalker". И se_stalker:on_spawn - это метод этого класса, который переопределяет (замещает) дефолтовый метод, в принципе меняя при этом поведение объекта. Если надо задействовать дефолтовую реализацию метода, то надо вызывать его явно. Т.е. переопределил ты метод on_death, непись сдох и вместо дефолтового метода вызовется твой. А коллбек - это как сделано для онлайновых объектов с помощью класса биндера. Там есть собственно объект (класса game_object) и мы с помощью другого класса object_binder цепляем к его событиям свои функции. Теперь, если непись сдох, то впридачу к происходящим действиям вызывается и твоя функция.

Проверять состояние объекта в update - не самая лучшая метода. Колбек на смерть ГГ можно сделать в bind_stalker.script. Вот только зачем он нужен? function actor_binder:reinit() ... self.object:set_callback(callback.death, self.death_callback, self) -- добавить эту строку end --и добавить собственно обработчик function actor_binder:death_callback(box, item) ... end -- не забыть снять обработчик function actor_binder:net_destroy() ... self.object:set_callback(callback.death, nil) ... end Коллбек на спавн неписей (точнее, перегруженная функция класса se_stalker). Файл se_stalker.script function se_stalker:on_spawn() ... end

Несколько текстур нельзя. А насчёт растягивания - хочу нескромно напомнить о своём творении "STALKER Icon Editor". Живёт здесь. В частности решает и упомянутую проблему - раздвигает текстуру. Хоть до посинения. З.Ы.: ссылка на последнюю версию там не в шапке, а в этом сообщении. Кстати, скоро новая версия.

Ты не всё описал из того, что надо сделать. Иконку верно в XML файле создал? Дал ей уникальное имя, верные координаты? А неписю её прописал?

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

Ну... найти дохлых неписей в радиусе не проблема. А вот воскресить вроде нельзя. Похоже, что смерть непися - необратимый процесс, и необратимость эта заложена в движок игры. Видел как-то функцию, которая вроде как пытается оживить непися. Выглядит так: function set_npc_health(obj, health) if (obj and health <=2) then if (_g.IsStalker(obj)) then local tbl = amk.read_stalker_params(obj) tbl.health = health tbl.updhealth = health amk.write_stalker_params(tbl, obj) end end end Но у меня ни разу не сработала. Если вызвать её на объекте первый раз, то он (дохляк) на мгновение скрывается и появляется вновь (дохлый, как был). При повторном вызове игра вылетает. Можно имитировать воскрешение, просто респаунив персонажа. Даже есть такой мод. Хотя было бы здорово сделать воскрешение. Причём, было бы здорово сделать именно воскрешение конкретного тела из того положения, в котором оно лежит. Типа лежит жмур, а потом раз, и встал, ну скажем зомби. Но такого я не видел.

Вот цитата из файла \config\creatures\game_relations.ltx ; отношение персонажа к актеру (или другому NPC) вычисляется по формуле ; attitude = personal_goodwill + //личное отношение персонажа к актеру (если раньше не встречались, то 0) ; community_goodwill + //отношение группировки персонажа лично к актеру (если раньше контактов не было, то 0) ; community_to_community + //отношение группировки персонажа к группировке актера из [communities_relations] ; reputation_goodwill + //отношение репутации персонажа к репутации актера из [reputation_relations] ; rank_goodwill //отношение ранга персонажа к рангу актера из [rank_relations] Скорее всего set_relation() устанавливает только personal_goodwill, а всё остальное эту часть перевешивает. Мне смутно вспоминается, что при этом set_relation() не может сделать добавку больше определённой. Так что в конце концов никак не сделать принципиально враждебных неписей дружественными. В своё время я с этим столкнулся, когда чинил ручных крыс из одной солянки под CS. Из положения удалось выйти только заведя новую группировку и прописав её крысам.

Господа, кто-нибудь может поподробнее прокомментировать следующие функции для проигрывания постэфффектов? level.add_pp_effector("yantar_underground_psi.ppe", 999, true) level.set_pp_effector_factor(999, 5.0) level.remove_pp_effector(999) Я так предполагаю, что в функции level.add_pp_effector(<1>, <2>, <3>) <1> - строка. Это очевидно имя файла постэффекта, здесь всё понятно <2> - это возможно идентификатор, который дальше можно использовать для обращения к этому постэффекту (но я в этом не уверен) <3> - некое логическое значение, зачем нужно - не знаю. В функции level.set_pp_effector_factor(<1>, <2>) <1> - это вероятно ранее назначенный ID постэффекта <2> - некое число с плавающей точкой. Какой-то коэффициент. Что он означает? level.remove_pp_effector() по всей видимости удаление заведённого ранее постэффекта. Кроме этих есть и ещё функции вероятно служащих для работы с постэффектами: level.set_pp_effector_factor(number, number, number); --имеет три аргумента, зачем третий? remove_complex_effector(number); --имеет ли отношение к предыдущим?

Тогда уж лучше Wiki завести на сервере.

=) - Видишь файл? - Нет. - И я не вижу. А он есть... Есть он конечно, только запакованный в игровом архиве. Если распаковать и поместить в каталог gamedata\config\text\rus\, то игра возмёт его, а не тот, что в архиве. Ну как собственно и все прочие файлы, заменяемые модами.

Вряд ли это возможно. А чем ui_icon_equipment не угодил?

А что надо было? Знать, что именно там происходит внутри, из-за чего сейв портится? Щас! Почти уверен, что этого даже разрабы толком не знают. Знали бы - исправили бы, поскольку это одна из самых неприятных "фишек" игры. IMHO это может происходить из-за несогласованной работы нескольких потоков: кто-то что-то не успевает дописать или пишут в одно место. В любом случае, что в ТЧ, что в ЧН битых сейвов у меня не было с тех пор, как перестал пользоваться быстрыми сохранениями.

Чаще всего из-за quick save.

В АМК о спавне тоже есть сообщение. Когда говорят "такой-то видел таких-то" - это и есть сообщение о спавне. Если коротко: в файле xr_motivator.script есть коллбэк на создание непися motivator_binder:net_spawn из него вызывается функция amk.on_npc_spawn из неё вызывается news_main.on_spawn из неё там-же находящаяся add_spawned_object, в которой информация о заспавленных объектах добавляется в таблицу table_spawned. Эта таблица проверяется в функции check_news, которая вызывается по таймеру (в сущности из апдейта актора). Для каждого элемента вызывается функция on_spawn_group, которая в конце-концов вызывает функцию do_news, которая уже и отображает сообщение через случайный интервал времени (чтобы не всю пачку сразу вываливать).

Все вероятно знают способ послать сообщение в консоль (и соответственно в лог) с помощью функции get_console():execute(<строка>). А не известно ли кому-нибудь какого-либо иного способа? Всё-таки вышеприведённый способ - это так-сказать побочный эффект от попытки выполнить на консоли команду. При этом <строка> не должна содержать пробелов (ибо пробелом отделяются аргументы) и не должна оказаться одной из всамделишных команд. Да ещё выводимое "сообщение" - это на самом деле сообщение об ошибке выполнения команды. В общем - этот способ нарушает мою внутреннюю гармонию и веру во вселенскую справедливость. Вот я и думаю, может таки существует способ сделать это (вывести сообщение на консоль) легально, и все этот способ знают, а только я отстал от жизни =)

return - это оператор возврата из функции. return <value> - передаёт управление в вызывающую функцию и возвращает значение <value> return <value1>, <value2>, <value3>, и т.д. - возвращает несколько значений return - просто выход из функции amk.load_variable - используется для получения значения, сохранённого в объекте actor. вызов: obj = amk.load_variable(<имя переменной>, <значение по умолчанию>) где <имя переменной> - текстовое значение <значение по умолчанию> - что вернёт функция, если такого значения не будет найдено load_variable, объявленная в модуле amk, вызывает более общую функцию xr_logic_new.pstor_retrieve(npc, name, def_value), которая позволяет получить сохранённое значение из любого объекта npc (типа game_object, т.е. онлайнового), если таковое в нём конечно сохранено.

В самом деле, это я как-то упустил из виду. Надо будет попробовать собрать на GCC.

Программе НЕ нужна вообще никакая установка, в реестр не пишет ничего, никаких особенных административных прав тоже не требует. все компоненты подлинкованы статически, так что и от хитрых DLL тоже вроде никаких зависимостей нет. .NET тоже не используется. Может вирус?

obj:explode(0) obj - это должен быть онлайновый (клиентский) объект Я так подрывал динамит, гранаты и баллоны с газом. Число не знаю что означает, на результат по-моему не влияет никак.

ui_icon_equipment.dds разбит условной сеткой 50х50. Клетки нумеруются начиная с нуля. Размеры иконок также указываются "в клетках". Теперь в файлах ltx в описании каждого предмета (который может показаться в инвентаре) имеются такие строки: inv_grid_width = 3; это ширина иконки inv_grid_height = 1; и высота "в квадратах" inv_grid_x = 5; это координаты иконки, inv_grid_y = 11; измеренные опять же "в квадратах" Прочие файлы в каталоге \gamedata\textures\ui\ организованы иначе. Для каждого файла текстуры есть свой файл xml в каталоге \gamedata\configs\ui\. Там прописано имя файла текстуры, и есть секции для отдельных текстурок с именами и размерами/положением в пикселях. Например в файле ui_npc_unique.xml это выглядит так: <w> <file name="ui\ui_npc_unique"> <texture id="ui_npc_u_nebo_2_face_1" x="0" y="0" width="165" height="108" /> <texture id="ui_npc_u_nebo_2_face_2" x="165" y="0" width="165" height="108" /> ... <texture id="ui_npc_u_nebo_2_face_3" x="330" y="0" width="165" height="108" /> </file> </w> Теперь по этим именам к отдельным текстурам можно обращаться из скриптов и ссылаться на них в файлах конфигурации.

Только что перечитывал пожелания и обратил внимание. Эта фишка есть и уже давно. Из меню "Правка" доступны две команды: "Расширить по вертикали" - текстура станет в два раза выше "Расширить по горизонтали" - текстура станет в два раза шире. С этим пока придётся подождать. Увы, должен расставлять приоритеты, поскольку на всё времени не хватает.