Закрома Родины |
Здравствуйте, гость ( Авторизация | Регистрация )
Сайт S.T.A.L.K.E.R. Inside / [ЗП] Параметры командной строки / Распаковщик ресурсов
Закрома Родины |
17.09.2014, 16:27
Сообщение
#1801
|
|
И никаких няш-мяш! Репутация: 5029 Группа: Участник Сообщений: 28157 Регистрация: 04.02.2003 |
Сборка движка X-Ray 1.0007 RC1 Сборка движка ЗП от Shoker 0) Устанавливаем Visual Studio 2008 SP1 (Proffesional или Team, я собирал в первой), сервис пак из архива engine.vc2008.fixed.rar подходит только к английской версии студии, для русской нужно будет скачать отдельно. ______________________________________________ 1) Создаём на диске папку, в ней ещё одну папку. 2) В эту папку помещаем только папку engine.vc2008 из архива "engine.vc2008.fixed - фикшенный мною проект vs2008", папку SDK от туда не трогаем. 3) Папку SDK берём из архива "stasvn\sources\engine.vc2005-2008(~1.6.02 бенчмарк) - март 2010", из под-папки sources. Помещаем её в одну папку к engine.vc2008 4) Вот теперь поверх неё докладываем папку SDK из архива engine.vc2008.fixed.rar, соглашаемся на замену всех файлов 5) Качаем с сайта майкрософт два DirectX SDK - 2009 March и 2010 June. (Вес каждой около 500 мб), можно использовать только версию 2009, но тогда не сможете собрать xrRender_R4. (LINK : fatal error LNK1181: cannot open input file 'd3d11.lib'), а если будете использовать только 2010 - игра с R4 не запустится. После установки двух DX SDK убедитесь что они прописали свои пути в студию, файлы 2010-го СДК должны быть после 2009-го, как показано на рисунке: Аналогично для разделов Executable files и Include files. Если возникнут вопросы, ищите информацию в гугле по словам "подключение directx sdk visual studio 2008" При неправильных версиях СДК (или его не-подключении) в логе будет ругань на отсутствие файлов типа d3dXX.lib\.h) Перемещать папки из уже установленного DirectX SDK никуда не нужно. Достаточно прописать к ним пути глобально для студии (или для каждого проекта вручную) Комментарий от loxotron: достаточно скопировать и переименовать d3d11_beta.lib в d3d11.lib в папке с директовским сдк, а еще лучше скачать и поставить DX SDK August 2009 и не париться с неподходящими версиями. 6) На всякий случаи можно установить ещё SDK\OpenALwEAX.exe, но не уверен что он критически необходим. 7) Запускаем проект через ..\CoP\Project\engine.vc2008\engine.sln. Когда он загрузится, вверху студии режим сборки с Debug_Dedicated (или любой другой) меняем на Release. Далее слева\справа будет список папок с файлами движка, нам нужна, в первую очередь, папка 3rd_party - жмём на неё правой кнопкой мыши и выбираем Build\Построить. Если всё будет правильно, то в конце лог внизу напишет об 11 успешных проектах (или число будет меньше, если некоторые проекты уже были собраны до этого, лог об этом тоже сообщит "пропущены\up to date") Главное чтобы Ошибок\Fatal везде было 0 У меня собрались полностью все проекты без ошибок. (warning за полноценные ошибки не считаются) 8) По аналогии, сверху вниз, можно собрать другие Dll-ки, папки editor\dedicated\utils\plugins собирать не обязательно - к движку они не относятся. Дольше всего будет собираться xrGame.dll. Остальные достаточно быстро. Собирать все Dll-ки к слову не обязательно. Можно лишь нужные. Когда они будут готовы - создать чистую папку bin в папке с игрой. Закинуть туда все созданные dll файлы (можно вместе с .pdb). При необходимости, можно докинуть отсутствующие файлы из оригинальной bin ЗП (2-ой патч), если игра будет их требовать. (Навроде wrap_oal.dll) Игру я запускал с оригинального Stalker-COP.exe Если всё верно, то в логе\консоли игры в первых строчках будет указан билд игры и дата построения. Сообщение отредактировал RayTwitty - 22.01.2016, 17:03 |
 
|
|
|
|
13.08.2014, 16:46
Сообщение
#1802
|
|
Ветеран Репутация: 5 Группа: Участник Сообщений: 82 Награды: 2 Регистрация: 11.07.2014 |
Цитата А это вообще ужас-ужас Мне лично вполне удобно) -------------------- |
 
|
|
13.08.2014, 17:45
Сообщение
#1803
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
1. get_actor(), с какой стороны ни глянь, совсем не полиморфизм 2. Раньше, например, было элегантно: ГГ и НПЦ обрабатывались единообразно, а сейчас get_actor, get_npc 3. А это вообще ужас-ужас 1. В 111 добавил ещё более вандальную функцию get_actor_obj() чтобы более не трогать db.actor в скриптах 2. Вам никто не мешает пользоваться API как было раньше. Кстати свойство inventory так-же добавлено в game_object. С иммунитетами скоро переделаю в свойство-объект immunities, которое будет присутствовать у всех мобов. 3. Ну что там можно улучшить? |
 
|
|
13.08.2014, 18:19
Сообщение
#1804
|
|
Ветеран Репутация: 5 Группа: Участник Сообщений: 82 Награды: 2 Регистрация: 11.07.2014 |
Цитата Вам никто не мешает пользоваться API как было раньше. Вот это наверное даже лучше) все таки если переносить на новый патч какие-то моды, пришлось бы долго и нудно переделывать код) а так использовать привычный способ или же новый) классно) -------------------- |
 
|
|
13.08.2014, 19:05
Сообщение
#1805
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
|
 
|
|
13.08.2014, 22:21
Сообщение
#1806
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
А к чему тогда разговоры про полиморфизм и прочее, если делается прямо противоположное Давайте тут разберемся. Мне хочется избежать неявных указаний классов в методах и свойствах game_object. Например, думаю что следующий код: Код local ammo = level.object_by_id(id) if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1 end Несколько менее изящен, чем такой: Код local box = level.object_by_id(id).ammo_box if box.curr < box.size then box.curr = box.curr + 1 end Хотя не буду спорить, кому что нравиться. В плане реализации game_object это контейнер для произвольных объектов движка. Пока не ясно, как для него осуществить динамический экспорт свойств/методов хранимых объектов. Поэтому остается для каждого типа объекта, делать возвратную функцию (можно и свойство). К примеру код: Код local a = db.actor:get_actor() Может быть представлен и так, при небольшой доработке: Код local a = db.actor.obj Однако определив перед компиляцией свойство obj с типом CActor, его уже никак не изменить для остальных объектов. Можно сделать экспорт общего для многих объектов класса CEntity, который не будет экспортировать свойства характерные для наследников. Так например сделано для свойства immunities, поскольку класс CHitImmunity для большинства объектов является предком. Так-же в новой ревизии класс game_object предлагает следующие объекты-свойства: Код CInventory inventory CEntityCondition conditions Однако, из-за известных ограничений получается, что свойство db.actor.conditions != get_actor_obj().condition, поскольку у первого класс CEntityCondition, а у второго CActorCondition с большим числом свойств. Пока не выяснится, как лучше осуществлять динамический экспорт классов... других вариантов просто нет. Надежда что это удастся реализовать, ещё есть ) P.S.: Свойство condition.health не равноценно game_object.health, как может показаться. Shadows приметил, что следуя туманной логике разработчиков, CScriptGameObject::SetHealth занимается зачем-то приращением, вместо присвоения. Сообщение отредактировал alpet - 13.08.2014, 22:22 |
 
|
|
13.08.2014, 22:32
Сообщение
#1807
|
|
Новичок Репутация: 0 Группа: Участник Сообщений: 4 Регистрация: 18.02.2014 |
Доброго времени суток. Хотел бы спросить по поводу одного известного бага.
Вопрос с подтекстом. В оригинальном Stalker Shadow of Chernobyl нередко встречалась ситуация, когда при разрушении разбиваемых ящиков в случае, когда ящик находился на наклонной поверхности, предметы могли провалиться под карту. Это было связано с тем, что шейп главной кости предмета пересекался с террейном/материалом зданий. Из-за этого же бага в Stalker Clear sky артефакты при попытке взятия из аномалии частенько проваливались "под землю" при "подсветке" детектором. Баг можно обойти, разместив шейп главной кости значительно выше самой кости(как на примере в скриншоте), в этом случае предмет не провалится под карту, но в случае с артефактами начинается "ахтунг" : дело в том, что движок отыгрывает источник света и партиклы строго по положению главной кости артефакта и если главная кость ниже шейпа то источник света и точка отыгрывания партиклов оказываются "под землёй". Ещё хуже обстоит дело, если артефакт имеет свою анимацию и дочерние кости движутся относительно главной - выглядит, как будто артефакт "здесь", а партиклы "где-то там". Было бы замечательно, если бы можно было задавать через .ltx - конфиг кость, из которой "появятся" предметы при разрушении разбиваемого ящика. Пример Содержимое файла models\objects\box_metall_01.ltx, сам файл подключается к модели в actor editor'е много знаков CODE ;--- destroyed sections -------------------------------------------------------- ;------------------------------------------------------------------------------- ;--- disable ------------------------------------------------------------------- ;------------------------------------------------------------------------------- [disable] linear_factor = 0.5 angular_factor = 0.5 ;------------------------------------------------------------------------------- ;--- collide ------------------------------------------------------------------- ;------------------------------------------------------------------------------- [collide] not_collide_parts = 0 ;------------------------------------------------------------------------------- ;--- destroyed part ------------------------------------------------------------ ;------------------------------------------------------------------------------- [destroyed] physics\box\prt\box_metall_01_prt1 physics\box\prt\box_metall_01_prt2 [autoremove_parts] time = 60 ;------------------------------------------------------------------------------- ;--- damage params ------------------------------------------------------------- ;------------------------------------------------------------------------------- [collision_damage] link = 0.1 ;------------------------------------------------------------------------------- ;--- particles ----------------------------------------------------------------- ;------------------------------------------------------------------------------- [particles] destroy_particles = destroy_fx\destroy_wood_00 ;------------------------------------------------------------------------------- ;--- particle_bones ------------------------------------------------------------ ;------------------------------------------------------------------------------- [particle_bones] link = 0.0, 0.15, 0.0 ;------------------------------------------------------------------------------- ;--- sound --------------------------------------------------------------------- ;------------------------------------------------------------------------------- [sound] break_sound = material\wood\wood_crash1_hl2 ;------------------------------------------------------------------------------- ;--- damage_bones -------------------------------------------------------------- ;------------------------------------------------------------------------------- ;bone_name = <hit_scale>,<-1>,<wound_scale> ;<hit_scale> - коэфф. изменения хита (уменьшения здоровья) ;<wound_scale> - коэфф. изменения величины открытой раны - незадействован ;------------------------------------------------------------------------------- default = 1.0, -1, 0.0 [immunities] burn_immunity = 0.5 ;коэффициенты иммунитета strike_immunity = 0.5 shock_immunity = 0.5 wound_immunity = 0.5 radiation_immunity = 0.0 telepatic_immunity = 0.0 chemical_burn_immunity = 0.0 explosion_immunity = 0.5 fire_wound_immunity = 0.5 ;------------------------------------------------------------------------------- ;--- impulse_transition -------------------------------------------------------- ;------------------------------------------------------------------------------- [impulse_transition_to_parts] random_min = 0.2 ; величина случайно направленного импульса пропорционально массе нового объекта random_hit_imp = 0.2 ; величина случайно направленного импульса пропорционально разрушающему хиту ;ref_bone ; кость из по которой определяется скорость для частей у который связь не задана, по умолчанию рут imp_transition_factor = 1.0 ; фактор с которым прикладывается хит по исходному объекту ко всем частям lv_transition_factor = 0.2 ; коэффициент передачи линейной скорости av_transition_factor = 0.2 ; коэффициент передачи угловой скорости ;------------------------------------------------------------------------------- ;------ End params ------------------------------------------------------------- ;------------------------------------------------------------------------------- код CODE [item_spawn] item_spawn_bone = bone_01 Пример Кусок кода из misc\artefacts.ltx Код CODE [af_vyvert]:af_base GroupControlSection = spawn_group $spawn = "artifacts\gravy vyvert" $prefetch = 64 cform = skeleton class = ARTEFACT visual = physics\anomaly\artefact_gravy1.ogf description = enc_zone_artifact_af-vyvert inv_name = af-vyvert inv_name_short = inv_weight = 0.5 inv_grid_x = 14 inv_grid_y = 0 cost = 1000 jump_height = .3 particles = anomaly2\artefact\artefact_gravi lights_enabled = false ;true ;???? ? artefact_activation_seq = af_activation_gravi ;скорости увеличения (уменьшения) health_restore_speed = 0.0 radiation_restore_speed = 0.0005 satiety_restore_speed = 0.0 power_restore_speed = 0.0 bleeding_restore_speed = 0.0 hit_absorbation_sect = af_vyvert_absorbation [af_vyvert_absorbation] burn_immunity = 1.0 ;коэффициенты иммунитета strike_immunity = 1.0 shock_immunity = 1.0 wound_immunity = 0.98 radiation_immunity = 1.0 telepatic_immunity = 1.0 chemical_burn_immunity = 1.0 explosion_immunity = 1.0 fire_wound_immunity = 1.0 -------------------- Ничто общее из частного не следует.
|
 
|
|
13.08.2014, 23:38
Сообщение
#1808
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
P.S.: Свойство condition.health не равноценно game_object.health, как может показаться. Shadows приметил, что следуя туманной логике разработчиков, CScriptGameObject::SetHealth занимается зачем-то приращением, вместо присвоения. Это порочная практика тащить в скрипты кишки движка. Цитата local ammo = level.object_by_id(id) if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1 end Цитата local box = level.object_by_id(id).ammo_box if box.curr < box.size then box.curr = box.curr + 1 end Еще круче: Код local obj = level.object_by_id(id) obj.ammo_cur = 1 Проверка на переполнение в движке, работает как health; с патронами и оружием единообразно Ну и уже есть set_ammo_elapsed заюзайте его и для пачки патронов. Сообщение отредактировал abramcumner - 13.08.2014, 23:50 |
 
|
|
14.08.2014, 08:46
Сообщение
#1809
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
Еще круче: Код local obj = level.object_by_id(id) obj.ammo_cur = 1 В моем понимании это уже не совсем тру ООП, т.к. свойство ammo_cur присутствует у всех объектов, а в самом его названии имеется детализация класса Этот-же код может выглядеть элегантно, при соответствующем конструкторе и выделенном классе ammo_box: Код local box = ammo_box(id) box.curr = 1 Однако это все лирика, я просто надеюсь что свое видение API передал |
 
|
|
14.08.2014, 09:51
Сообщение
#1810
|
|
Продвинутый геймер Репутация: 15 Группа: Участник Сообщений: 322 Награды: 3 Регистрация: 01.05.2014 |
Кто-нибудь пробывал собирать редактор погоды?
|
 
|
|
14.08.2014, 11:29
Сообщение
#1811
|
|
Ветеран Репутация: 5 Группа: Участник Сообщений: 82 Награды: 2 Регистрация: 11.07.2014 |
Alpet, а почему такая конструкция в 111 ревизии стала вызывать вылет?
Код db.actor:item_in_slot(9):torch_enabled() ругается на неизвестный метод torch_enabled, как я понимаю дело в том что клиентский объект фонаря теперь надо определять как-то по-другому. Сразу же два вопроса: как определять, и будет ли это работать для разных фонарей?
Сообщение отредактировал Vampir35 - 14.08.2014, 11:29 -------------------- |
 
|
|
14.08.2014, 12:56
Сообщение
#1812
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
Alpet, а почему такая конструкция в 111 ревизии стала вызывать вылет? Код db.actor:item_in_slot(9):torch_enabled() ругается на неизвестный метод torch_enabled, как я понимаю дело в том что клиентский объект фонаря теперь надо определять как-то по-другому. Сразу же два вопроса: как определять, и будет ли это работать для разных фонарей?Переделано, для [code] local torch_on = db.actor:get_torch().on -- или, что равноценно: torch_on = db.actor:item_in_slot(9):get_torch().on [code] Сообщение отредактировал alpet - 14.08.2014, 13:17 |
 
|
|
14.08.2014, 14:36
Сообщение
#1813
|
|
. Репутация: 750 Группа: Участник Сообщений: 7072 Награды: 4 Регистрация: 30.07.2010 |
Скомпилил сорцы за январь 2007, даже запустилось не смотря на все мои правки Правда с шейдерами там косяк какой-то, ни от одного билда не подходят. Разобрался в чём проблема была, оказывается directx sdk из архива от Diablo не подходит туда. А версия за апрель 2006 отлично подходит. |
 
|
|
14.08.2014, 15:34
Сообщение
#1814
|
|
Ветеран Репутация: 5 Группа: Участник Сообщений: 82 Награды: 2 Регистрация: 11.07.2014 |
Alpet, в предыдущих ревизиях фонарик можно было отключить так:
Код db.actor:item_in_slot(9):enable_torch(false) Как это теперь сделать?) Сообщение отредактировал Vampir35 - 14.08.2014, 15:35 -------------------- |
 
|
|
14.08.2014, 15:59
Сообщение
#1815
|
|
Продвинутый геймер Репутация: 15 Группа: Участник Сообщений: 322 Награды: 3 Регистрация: 01.05.2014 |
|
 
|
|
14.08.2014, 16:42
Сообщение
#1816
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
Alpet, в предыдущих ревизиях фонарик можно было отключить так: Код db.actor:item_in_slot(9):enable_torch(false) Как это теперь сделать?) Много способов: Код db.actor:item_in_slot(9):get_torch():enable(false) -- или db.actor:get_torch():enable(false) -- или get_torch_obj(0):enable(false) -- получить фонарь гг Кстати, сделал в 113 ревизии и получение объекта с произвольными классом. Для этого можно использовать свойство interface объекта game_object или глобальную функцию engine_object( id or game_object ): Код -- выключение фонаря db.actor:item_in_slot(9).interface:enable(false) -- interface выдает объект CTorch -- причинить вред здоровью db.actor.interface.condition.health = 0.3 -- interface выдает объект CActor Мне думается, что программисты GSC об таких возможностях luabind не знали, поэтому и свалили все классы в один game_object. Сообщение отредактировал alpet - 14.08.2014, 16:46 |
 
|
|
14.08.2014, 17:12
Сообщение
#1817
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
а мне думается, что программисты GSC хотя бы знали что такое профайлер.
посмотрел на "изящную замену" Код local ammo = level.object_by_id(id) if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then[/i] -- local box = level.object_by_id(id).ammo_box if box.curr < box.size then подумалось, что программисты GSC, глядя в этот самый профайлер, видели только плюсы в дергание нужных методов в нужное время вместо постоянного копирования всех свойств объекта во временный объект. сборщик мусора в луа ни разу не волшебный. впрочем, даже без профайлера "тяжесть" подобного изящества описана в мануалах и Lua и luajit-а (даже древней первой версии). |
 
|
|
14.08.2014, 17:16
Сообщение
#1818
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
|
 
|
|
14.08.2014, 18:00
Сообщение
#1819
|
|
Игроман Репутация: 386 Группа: Участник Сообщений: 847 Награды: 7 Регистрация: 22.07.2009 |
|
 
|
|
14.08.2014, 18:49
Сообщение
#1820
|
|
Игровой Эксперт Репутация: 407 Группа: Участник Сообщений: 2394 Награды: 5 Регистрация: 19.01.2009 |
Реалтайм-реалтайм.под Зовом не заведется
|
 
|
|
14.08.2014, 18:55
Сообщение
#1821
|
|
Кандидат Игровых Наук Репутация: 2153 Группа: Участник Сообщений: 3488 Награды: 4 Регистрация: 27.07.2009 |
По поводу этих интерфейсов интересно насколько технически возможно в рамках С++ и ресурсоёмкости возможность просто создать и экспортировать универсальный С++ метод, который автоматом экспортировал бы (хотя бы) все свойства класса и привязывал бы их к имени класса, чтобы например в lua получать\изменять свойства объекта так:
db.actor:Engine("CActor").fCurAVelocity db.actor:Engine("CActor").m_fWalkAccel db.actor:Engine("CInventoryOwner").m_money И т.д и т.п То-есть кастовать для lua-объекта нужный движковый класс (предком которого является lua-объект) и вычитывать любое его свойство. Упор делается именно на автоматизацию - возможность работать с любым классом движка без предварительной его подготовки и экспорта в Lua. Или же такое решение потребует серьёзного переписывания движковых классов? Я сейчас используй нечто подобное, но оно требует зарание описать структуру класса и смещения, а хочется в будущем добиться возможности переложить это на плечи движка\компилятора. Сообщение отредактировал Shoкer - 14.08.2014, 19:01 -------------------- Мне просто нравятся синие буквы под сообщением.
|
 
|
|
Текстовая версия | Сейчас: 05.05.2024, 06:48 |