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

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


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

Сталкер-Стрелок, Капрал Хикс

То есть, нужно алл.спавн декомпиллировать? Бардаком?

Лучше умереть стоя, чем жить на коленях (Эрнесто Че Гевара).
Выживаю в NLC-7.
Кто не рискует - у того утром не болит голова от шампанского.

Micha_Pulemiot,
да, этим - http://www.amk-team.ru/forum/index.php?showtopic=11568

Распаковываешь all.spawn. Затем редактируешь alife_l03u_agr_underground.ltx.

 

Сталкер-Стрелок,
он уже это сделал! А АК Стрелка будет выглядеть так, как в спавне написано и никак иначе!

 

Сталкер-Стрелок,
да потому что информация о объекте АК Стрелка будет в данном случае браться с all.spawn и игнорируется все (я про модель), что ты напишешь в unique_items.ltx. А вот если в продажу загонишь этот ствол, то как раз будет информация об оружии будет браться с unique_items.ltx и никак иначе.

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

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

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

 

@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

Сталкер-Стрелок,

можно и пакетом. Но когда уже привык к "дедовскому" способу, то быстрее так, как я описал.

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Всем привет, Сталкеры! Решил было на досуге поковыряться с АМК и вот вопрос возник. В esc_blockpost_btr.ltx, target=actor - что по умолчанию огонь по гг. Вписывать туда nil (как в АМК-шпаргалке предлагается) и выключать бтр-а не хочу. Можно ли как-то сделать, чтобы бтр реалистично палил только по новичкам, бандюкам, монстрам ну и по Меченому конечно же? Благодарю за внимание!

 

нельзя

- э-эх жалко!

Спасибо за ответ! :)

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

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

  • Согласен 1

Существует ли возможность задать условие спавна физического объекта и желательно, его уничтожения через all.spawn по аналогии с НПС и мобами?

 

Если нет, то каким образом в заспавненном через скрипт объекте указать и логику и список костей которыми объект будет прекреплен (аналог fixed_bones из all.spawna).

aka Stalker_AleX333
 
Мои проекты  - ЯндексДиск   |   Я на Gamer-Mods.ru

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

 

 

и список костей которыми объект будет прекреплен

Секция в items.ltx:

[stol_esc]:identity_immunities
GroupControlSection = spawn_group
discovery_dependency = 
$spawn = "physics\stol_esc"
visual = physics\stol\stol_6.ogf
class = O_PHYS_S
cform = skeleton
remove_time = 10000
Ф-ция скриптового спавна(для работы с нет-пакетом использован модуль от Artos):
local ser_obj = alife():create("stol_esc",vector():set(-196.05,-19.49,-135.23),56184,36)
if ser_obj then
----- фиксируем объект после спауна -----
local pk = m_netpk.get(ser_obj) -- запрос нет-пакета
if pk and pk:isOk() then
local data = pk:get() -- читаем данные из нет-пакета
if data and data.upd then
data.fixed_bones = "link"
pk:set(data)
end
end
end
Стол спавнится, после сейв\лоад стоит как вкопаный. Есть сомнения насчет remove_time = 10000, но дольше одних игровых суток не проверял. Может быть есть какое-то значение, которое задает бесконечное время до удаления объекта? Я не знаю, может кто подскажет.

 

Насчет логики для скриптово заспавненных объектов - видимо то-же через нет-пакет править кастом_дату...

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

З.Ы. А касательно правок схемы для all.spawna, я не совсем понял. Что необходимо править? И связаны ли правки с ковырянием движка игры? Если да - такая задача мне явно не по силам. Во-всяком случае пока-что...

aka Stalker_AleX333
 
Мои проекты  - ЯндексДиск   |   Я на Gamer-Mods.ru

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

 

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

  - если для смарта не указана вместимость(capacity), емкость гулага будет определяться по кол-ву прописанных работ?

 

Dennis_Chikin: 

1. Да. Но лучше прописывать явно, и раскомментировать проверку ошибок в xr_gulag.script

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

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

Ну вот плохо он следит. 8( Кстати, не движок, а скрипт.

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

 

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

Так что от греха - всегда явно указывать емкость по гарантированным работам во всех состояниях.

 

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

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

Вона как... Значит так и будем действовать, а упрощенный вариант - для простых гулагов...

 

Кстати, к вопросу от Stalker_AleX333 и моему предположению по правке кастом_даты: а как правильно заполнить содержимое кастом_даты в случае использования модуля от Artos ? Простой пример от знающих, если можно ?

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

@UnLoaded, 

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

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

"сюда пишешь свою кастом дату"

Символы переноса строки(\n) - легитимны ?

 

Раз уж пошло такое хорошо по работе с нет-пакетом, спрошу: как правильно прописать StoryID неписю(при скриптовом спавне) с использованием того-же модуля Artos'а ?

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

@UnLoaded, для переноса строки в назначаемой скриптом кастом дате следует использовать "\n".

Да, ты уже и сам догадался. :)

 

Для изменения story_id необходимо поработать с абстрактной частью нет-пакета, которая доступна только в момент выхода объекта в онлайн или при сохранении.

За инструкцией лучше всего обратиться к руководству от автора:

Про специальный нет-пакет 'abstract':


Библиотека может работать с абстрактной частью пакета, которая доступна ТОЛЬКО в момент выхода объекта в онлайн или сохранении.
Поэтому напрямую (методами set и get) прочитать и записать такие данные нельзя.
Для чтения и/или изменения используется специальный пакет 'net_abstract'.
Хотя принцип работы отличается от работы остальных классов, но все же очень похож. Исключение составляет то, как изменять данные в пакете.
Рассмотрим сразу на примере:
а) создаем объект в игре:
local obj = alife():create("exo_outfit", pos, lv, gv)

б) получаем служебный пакет, которым будем менять свойства:

local pk = m_netpk.get(obj,0) -- или m_netpk.net_cse_abstract(obj)

в)

вариант-1: используем функцию:

pk:setCallback( function(data)
  data.direction = vector():set(1,1,1)
end )

вариант-2: задаем желаемые изменения таблицей:

pk:setCallback( {direction = vector():set(1,1,1)} )

Здесь мы создали объект и захотели изменить его абстрактную часть.
Мы указали пакету коллбек, который будет передан основному коллбэку, будучи вызванам как только станет доступна абстрактная часть объекта.
В колбек передается таблица с параметрами пакета, мы можем смело их менять, в примере мы наклонили объект по всем осям на 1 радиану.
При спавне нового игрового объекта:
изменения вступят в силу, как только мы выйдем из текущей скриптовой работы и управление вернется движку - он создаст объект и начнет записывать в него параметры.
Для уже существующих объектов в игре:
требуется после задания изменений свойст объекта, перевести объект в оффлайн и обратно в онлайн, что модулем делается автоматически.
Изменения вступят в силу в момент выхода объекта в онлайн.

Как получить возможность менять абстрактную часть пакетов?

1) этот тип объектов должен иметь класс, который представляет такой тип объектов в игре (можно назвать биндером, а можно никак не называть)
(то есть то, что будет вызвано, когда объект появится в игре)
Завязка из class_registrator.script:

cs_register (object_factory, "CStalkerOutfit", "se_item.se_outfit", "E_STLK", "equ_stalker_s")

2) обязательно добавить (если таковой отсутствует) метод биндера 'STATE_Write' (см. скрипты типа: 'se_XXX.script')
Для примера с костюмом:

function se_outfit:STATE_Write(packet)
  cse_alife_item_custom_outfit.STATE_Write(self, packet)
end

3) В метод STATE_Write (см. выше) добавить строку:

function se_outfit:STATE_Write(packet)
  if self.cb_netpk then self.cb_netpk(self, packet) end -- коллбэк для изменения свойств пакета
  cse_alife_item_custom_outfit.STATE_Write(self, packet)
end

Выполнение этих действий ОБЯЗАТЕЛЬНО.

Зачем это нужно? Ну, например, можно поменять дирекшн или позишн, так как это read_only свойства объектов.
А позишн при спавне смещается так, чтобы объект находился на ИИ сетке.
То есть, можем спавнить всякие там лампочки, физические объкты так, чтоб они оказывались повернутыми в пространстве.
Так же можно менять те свойства, которые, обычно, только для чтения. Например story_id, или position.

 

Но такие вопросы больше относятся к теме «Скриптование».

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

Свои работы и совместные проекты: Инструмент, OGSM CS, Final Stroke, HARDWARMOD

Полезное: модули Артоса, XML парсер

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

Здравствуйте ВАМ. Кто может подсказать, как заспавнить монолитовцев в саркофаг вторично. По ходу нароботки, ГГ дважды идет в саркофаг. Сопротивления НОЛЬ, нет ни одного монолитовца после первой бойни.

Одна голова хорошо, а две лучше. А вот три, это уже змей Горыныч.

Я конечно в скриптах полное днище, но почему не происходит спавна объекта понять не могу (на другой функции проверил - работает):

 

Сам спавн вызывается из логики выключателя:

 

 

[logic]
active = ph_button@air_conditioning_system_off

[ph_button@air_conditioning_system_off]
on_info     = {+lab_x7_air_conditioning_system_turned_on} ph_idle@nil
anim        = lab_primary_switcher_idle
tooltip     = tips_lab_x7_air_conditioning_system_switcher
on_press    = ph_button@air_conditioning_system_on %=lab_x7_air_conditioning_system_turned_on%

[ph_button@air_conditioning_system_on]
anim        = lab_primary_switcher_off

[ph_idle@nil] 

 

 

 

Дальше, стандартная переброска вызова функции из xr_effects.script в свой скрипт:

 

 

function lab_x7_air_conditioning_system_turned_on()
	db.actor:db.actor:give_info_portion("lab_x7_air_conditioning_system_turned_on") 
	this.remove_all_lab_x7_static_ventilators()
	this.create_lab_x7_animated_ventilators()
end

function remove_all_lab_x7_static_ventilators()
	local id, obj
	for id=0, 65535 do
		obj = level.object_by_id(id)
		if obj ~= nil and obj:section() == "lab_x7_static_ventilators" then
			alife():release(alife():object(id), true)
		end
	end
end

function create_lab_x7_animated_ventilators() 
local ser_obj = alife():create("lab_x7_animated_ventilator",vector():set(-99.62,-18.25,73.64),2889,802) -- пока один, для тестов
	if ser_obj then
		local pk = m_netpk.get(ser_obj) 
			if pk and pk:isOk() then
		local data = pk:get() 
			if data and data.upd then
				data.fixed_bones = "link"
				pk:set(data)
			if data.custom_data:getString() == "lab_x7_animated_ventilator" then
				data.custom_data:setString("alex_mod\lab_x7_ventilators.ltx")
				end
			end
		end
	end
end 

 

 

 

Ну и секция предметов для спавна:

 

 

[lab_x7_static_ventilator]:identity_immunities
GroupControlSection 		= spawn_group
discovery_dependency 		= 
$spawn 				= "alex_mod\devices\lab_x7_static_ventilator"
class				= O_PHYS_S
cform				= skeleton
visual				= alex_mod\objects\ventilator_lab_static.ogf
custom_data			= scripts\alex_mod\lab_x7_ventilators.ltx
script_binding      		= bind_physic_object.init

[lab_x7_animated_ventilator]:identity_immunities
GroupControlSection 		= spawn_group
discovery_dependency 		= 
$spawn 				= "alex_mod\devices\lab_x7_animated_ventilator"
class				= O_PHYS_S
cform				= skeleton
visual				= physics\decor\ventilator_mike.ogf
custom_data			= scripts\alex_mod\lab_x7_ventilators.ltx
script_binding      		= bind_physic_object.init 

 

 

 

Может чего прописал не так, или не зарегестрировал?

 

З.Ы. Вспомнил, что помимо спавна и удаления объектов с логикой и прикрепленными костями, необходимо еще иметь возможность их разворота, аналогично all.spawn-ому. Надеюсь для этого тоже чего-нибудь придумали?

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

aka Stalker_AleX333
 
Мои проекты  - ЯндексДиск   |   Я на Gamer-Mods.ru

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

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

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

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

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

Войти

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

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

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