Перейти к контенту

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


Halford

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

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

 

Вот примерно такая логика должна быть:

[logic]
active = camper

[camper]
path_look = agr_tower2_look
path_walk = agr_tower2_stand
radius = 1
sniper = true
def_state_campering = threat_na
def_state_campering_fire = threat_fire

[spawn]
wpn_ak74
ammo_5.45x39_fmj = 1

[smart_terrains]
none=true

 

  • Спасибо 1

Поделиться этим сообщением


Ссылка на сообщение

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

  • Спасибо 1

Поделиться этим сообщением


Ссылка на сообщение
(изменено)

Да не надо ничего распаковывать. В секции самого предмета путь до мировой модели поменяй и все.

 

@ed_rez, это ты с чего взял? В секцию уникального калаша вписываешь путь до мировой модели, какие проблемы?

 

@ed_rez, хм, да. Тем не менее можно пакетом переписать без распаковки all.spawn.

@Micha_Pulemiot, в таком случае бери универсальный acdc и декомпиль, стирай/изменяй строку визуала и пакуй обратно.
Вот так она выглядит у меня:

[b][2077]; cse_abstract propertiessection_name = wpn_ak74_m1name = kat_wpn_ak74_m1position = -73.2993087768555, -5.97463035583496, -75.3087844848633direction = -0.000921175756957382, -1.5696005821228, 1.51920056343079id = 65535version = 118script_version = 7; cse_alife_object propertiesgame_vertex_id = 703level_vertex_id = 172object_flags = 0xffffff0f; cse_visual propertiesvisual_name = weapons\ak74\wpn_ak74; cse_alife_inventory_item propertiescondition = 1; cse_alife_item_weapon propertiesammo_current = 90upd:condition = 1[/b]


 

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

Поделиться этим сообщением


Ссылка на сообщение

@stalker8509, нельзя. В оригинале можно прописывать цели только: актор, сид, поинт. Для группировок, монстров и всего чего нет в мною перечисленном списке нужно существенно переписывать схему.

  • Согласен 1

Поделиться этим сообщением


Ссылка на сообщение

, для физобъекта нельзя указать условие спавна в all.spawn без правок схемы. Скриптом зафиксировать объект можно с помощью классов physics_shell и physics_element, только фиксировать нужно будет при каждой загрузке.

Поделиться этим сообщением


Ссылка на сообщение

@UnLoaded, если не ошибаюсь, то remove_time на физ. объекты не действует, в отличии от, например, хрупких объектов. И это не удаление фиксации, а удаление самого объекта - срабатывание дестрой коллбека. Так что почему бы и нет :).

 

, я не знаю где это есть, но принцип прост: получаешь физическую оболочку, далее получаешь кость (например) и применяешь метод fix(). Касательно-же правок схемы - файл se_item.script, делай по аналогии с людьми/монстрами и будет работать секция spawner и у физ. объектов :).

Поделиться этим сообщением


Ссылка на сообщение

@UnLoaded

if data.custom_data:getString() == "" then
data.custom_data:setString("сюда пишешь свою кастом дату")
end

@Dennis_Chikin, она даже часто оказывается в такой позе. Особенно во всяких модах когда туда какой-нибудь левый чувак раньше положенного залетает :).

Поделиться этим сообщением


Ссылка на сообщение

@UnLoaded, точно так же как и любой другой параметр. Там "прозрачная" система на таблицах, все как на ладони, Artos к тому же подробное сопровождение написал.

Поделиться этим сообщением


Ссылка на сообщение

@Dennis_Chikin, loadstring работает медленнее стандартного доступа к полю модуля. В мануале было написано, что его вообще следует избегать. И если уж loadstring, то loadstring(тра-ля-ля)().

 

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

Поделиться этим сообщением


Ссылка на сообщение

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

Поделиться этим сообщением


Ссылка на сообщение
(изменено)

@Serge!, xml - не статика. Установите нормальные lua библиотеки и оперируйте ими (xml-файлами) как угодно, они динамически перезагружаются при обращении к ним.

Изменено пользователем Сталкер-Стрелок

Поделиться этим сообщением


Ссылка на сообщение

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

 

@Malandrinus, возможна-ли реализация динамической перезагрузки диалога? Внеся правки в движок разумеется. Вообще что из себя представляет диалог? Это объект чего?

Поделиться этим сообщением


Ссылка на сообщение
(изменено)

@Malandrinus, граф разговора, если объяснить строго, то например захотел я добавить в граф диалога еще фразу, либо переделать какую-то, и вот что-бы не ветвить огромными дополнениями эти вкрапления, можно было бы попросту обновить диалог в игре заменив нужные фразы и условия к ним. Т.е. по факту динамическое построение диалога. Предполагаю, что подобное будет сделать не просто, думаю нужно будет заводить массив, где хранить нужное нам время все эти созданные диалоги. Основной класс CPhraseDialog как я понимаю (а граф идет из CGraphAbstract), мне непонятно в какой момент происходит загрузка данных, и как трудно будет сделать перезагрузку всего диалога.

Изменено пользователем Сталкер-Стрелок

Поделиться этим сообщением


Ссылка на сообщение

@Malandrinus, да, я имею ввиду исходники. Кеширование имеешь ввиду выбрасывать из GamePersistent? Способ добавления диалогов НПС останется прежним в таком случае? Инклюды нужны все равно в таком деле.

Поделиться этим сообщением


Ссылка на сообщение
(изменено)
Так ведь диалогов может быть несколько. Можно начать с любого, да и внутри одного диалога как-то спланировать получше, получив примерно такой-же эффект. По-моему, это всё вопрос не принципа работы, а дизайна конкретного диалога.

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

 

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

 

Про xml это дело вкуса. Можно использовать Dialog Manager, в любом случае если сделать новую скриптовую обвязку, то можно будет само описание увести и на ltx и на script. Либо в общем уже писать какой-то модуль по обработке фраз (из каких-нибудь имен, описаний и т.д.) и составления предложений.

Изменено пользователем Сталкер-Стрелок

Поделиться этим сообщением


Ссылка на сообщение
(изменено)
Например, хоть одну назовите?

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

или "не-управляемых" это опять о классах, исходно выданных движком, а не собственными руками написанных.

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

Может потому что для 99% авторов сделать другие - не представляется возможным?

Я думаю речь была об оригинале. Да и в целом, зачем динамика спальному мешку, к примеру?

Изменено пользователем Сталкер-Стрелок

Поделиться этим сообщением


Ссылка на сообщение

@Zander_driver, я возможно не прав, но мне кажется ты как-раз возмущен тем, почему никто не сделал сложные интерфейсы, и агитируешь за то, что-бы всем чем-то подобным заняться. Цели я поддерживаю, но почему не нацелится на дополнения в движке? В скрипты же все это экспортировали явно не для того, что-бы писать сложные системы вроде инвентарей. Началось я так понимаю это все с багажника для машины.

Поделиться этим сообщением


Ссылка на сообщение
  • Недавно просматривали   0 пользователей

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

AMK-Team.ru

×
×
  • Создать...