[SoC] Ковыряемся в файлах - Страница 133 - Скрипты / конфиги / движок - AMK Team
Перейти к контенту

[SoC] Ковыряемся в файлах


Рекомендуемые сообщения

malandrinus, Да знаем.

xr_logic.add_common_precondition() их держит.

Они ничо делать не будут постороннего,пока их держит схема.

Подскажите-это реально каким либо способом через скрипт заменить текстуру модели(задумка о худе рук)?

Костя.н.ы.ч, нет, скриптом даже модель рук не изменить, мне так кажется, если ты хочешь сделать худ рук в зависимости от брони то можно скриптом менять ствол, тоесть сделать на каждый ствол несколько копий с разными худами, но там возникнут проблемы с состоянием оружия, патронами в нем, но попробовать стоит. Изменено пользователем 8push5

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

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

DEL

xr_logic.add_common_precondition() их держит.

Они ничо делать не будут постороннего,пока их держит схема.

Поскольку логика - это механизм достаточно всокоуровневый, то это мне мало что объясняет. Меня интересует, что именно с точки зрения базовых вызовов не даёт им выполнять команды. Ведь что такое логика? Есть эвалуатор (условие) и экшин (действие) для него, так? Условие срабатывает и выполняется его действие. Внутри действия мы и прописываем те элементарные команды, которые заставляют непися бегать, стрелять, кричать и пр. Я посмотрел примеры экшинов и как-то не нашёл специальных действий, которые блокируют выполнение команд, а потом разрешают. Единственно, все реальные действия закопаны глубоко внутри state_mgr. Однако так и не понятно, что же мешает выполнить свои команды со стороны.

Опять же я исследовал очередь команд. Она не движется вообще. У меня появляется подозрение, что этот механизм просто не задействован. Я ведь писал, что там есть с одной стороны метод command и прилагающиеся к нему классы, а с другой стороны есть отдельные методы для отдельных частей состояния. Я сейчас пытаюсь найти концы и не могу найти, а где вообще применяется метод command. Зато нахожу применение тех методов из альтернативного набора.

 

DEL

Изменено пользователем malandrinus

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

А профессионал, этот человек который в совершенстве(лучше остального большинства) знает дело.... И не всегда этим зарабатывает этим на жизнь.

Разные у нас понятие, я оцениваю человека по знанием... А не по роду работы, и основному заработку.

Изменено пользователем Nekt

Nekt, вот ознакомься, это я из словаря выдернул:

профессионал 1. Тот, кто сделал какое-либо занятие своей профессией.
и

любитель I Тот, кто имеет склонность или пристрастие к чему-либо. II 1. Тот, кто занимается чем-либо в свободное от основной работы время, а не как профессионал.

здесь ни слова о мастерстве, опыте, знании этого дела, это просто профессиональная принадлежность, почитай словарь, там много интересного

И еще очень часто любителе бывают умнее, опытнее профессионалов.

Ну товарищи форумчане вас и понесло.

Спор начался с меня и Monnorochа и речь шла вовсе не о профессионализме или любительстве.

Не нужно пытаться подменять понятия "профессионал" - "опытный", "новичек" - "любитель".

Мы с вами регистрировались не на работу и не в кружок "Умелые руки" или "Очумелые ручки".

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

Ну не был мне интересен Сталкер в качестве творческого полотна в 2007 году, мне нравились другие игры. :rolleyes:

Если бы занялся я сталкером тогда возможно и уровень был бы повыше чем у любого гуру. А какой либо сложности в програмировании я для себя не нахожу. Может чего то не умею, так научусь. :big_boss:

 

Я вам так скажу, мы находимся в "Клубе", но не в "Клабе" и не забывайте об этом.

 

P.S. Почему на еще пяти форумах, где я зарегистрировался и беседую на тему скриптов не было такой проблемы? :mellow:

Важный вопрос к скриптерам-знатокам: существует ли способ очистить ПДА от выполненых и проваленых заданий в текущей игре?

Wlad777

 

Точно не знаю, но рискну предположить.

 

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

@ Kirag

 

Хммм... Надо будет порыться, поэкспериментировать.

 

Просто есть задумка для развития моей солянки. Начать игру с НС5 от Дана, чтоб потом ГГ пошёл на ЧАЭС, попал на закодирование и дальше под Супер-Выброс. В результате забывает всё, просыпается - пошла комбинация NLC5+НС3.

 

Но без очистки ПДА от заданий НС5 при начале другой линии будет коряво.

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

objt:disable_info_portion(sec)

Кажется команда удаление инфика... Есть ещё

objt:info_clear()

но её не пробовал.

Изменено пользователем Nekt
...Единственно, все реальные действия закопаны глубоко внутри state_mgr. Однако так и не понятно, что же мешает выполнить свои команды со стороны...

Возможно я понял не правильно, но не с подобной ли проблемой сталкивался Red75 в первоначальной версии "Напарников", когда НПС не подчинялись новой схеме? Если да, то причина ведь была в том, что нужно было установить состояние с помощью state_mgr.set_state(). И в этом случае, если сравнить статью на Wiki с окончательным вариантом, где эта проблема была решена, возможно понять как именно это было сделано.

Возможно я понял не правильно, но не с подобной ли проблемой сталкивался Red75 в первоначальной версии "Напарников", когда НПС не подчинялись новой схеме? Если да, то причина ведь была в том, что нужно было установить состояние с помощью state_mgr.set_state(). И в этом случае, если сравнить статью на Wiki с окончательным вариантом, где эта проблема была решена, возможно понять как именно это было сделано.

Мой вопрос в сущности примитивнее. Я здесь не пытаюсь сделать какой-либо мод или вообще решить какую-либо практическую задачу. Я хочу разобраться с API игры. Хочу понять, как работают классы "в чистом виде".

На данный момент по этому вопросу я всё больше убеждаюсь в том, что механизм управления неписями через метод command и прилагающиеся к нему классы в текущей версии игры просто не задействован. Это немного жаль, поскольку он единственный хоть как-то документирован в доках от билда 1935. Отключён ли этот механизм совершенно наглухо или просто требует каких-то специальных действий по включению - мне неведомо. В буквально нескольких найденных внятных примерах использования упоминаются ещё вызовы метода script, в который передаётся имя файла с чем-то вроде скриптовой схемы. Это именно в этих скриптах встречаются функции main. В релизе от этого и вовсе почти ничего не осталось, а в 1935 ещё таких много, но и там они походу уже не используются. Ещё возможно, что этот механизм (через command) использовался совместно с классом FSM (Finite State Machine), который в релизе остался, но опять же никак не задействован. Сейчас управление персонажами осуществляется через планировщик на основе GOAP (Goal-Oriented Action Planning), и возможно тот старый механизм управления не подходил для этого.

Короче, надо использовать отдельные методы, о которых я говорил:

set_item,

set_sight,

set_patrol_path, set_desired_position, set_desired_direction, set_dest_level_vertex_id, set_detail_path_type, set_movement_type, set_path_type,

clear_animations, add_animation,

play_sound, add_sound,

set_mental_state,

set_body_state

и другие в этом роде.

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

Люди.

Кто знает как с помощью ACDC в АллСпавне добавить на карту аномалию?

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

Приветствую всех, знающие подскажите, где изменить надпись и цвет подписей типо "прицепить глушитель" и т.д.

Nekt спасибо, а не знаешь как цвет поменять?

Изменено пользователем Ааз

Привет всем, подскажите как сделать вызов функции из меню, тоесть зашел в меню жмакул на опред. кнопку функция выполнилась. И еще при наличии предмета в инвертаре нужно вызвать функцию. Заранее СПАСИБО.

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

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

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...