Закрома Родины |
Здравствуйте, гость ( Авторизация | Регистрация )
Сайт S.T.A.L.K.E.R. Inside / [ЗП] Параметры командной строки / Распаковщик ресурсов
Закрома Родины |
17.09.2014, 16:27
Сообщение
#1821
|
|
И никаких няш-мяш! Репутация: 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 |
 
|
|
|
|
14.08.2014, 18:59
Сообщение
#1822
|
|
Продвинутый геймер Репутация: 15 Группа: Участник Сообщений: 322 Награды: 3 Регистрация: 01.05.2014 |
|
 
|
|
14.08.2014, 19:09
Сообщение
#1823
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
подумалось, что программисты GSC, глядя в этот самый профайлер, видели только плюсы в дергание нужных методов в нужное время вместо постоянного копирования всех свойств объекта во временный объект. сборщик мусора в луа ни разу не волшебный Вы меня пугаете! Покажите код, в котором копируются все свойства объектов. Да и бенчмарк, демонстрирующий дикие затраты тактов ЦП, на подход с интерфейсами... очень помог-бы По справедливости, требуется жестокое злоупотребление скриптами, чтобы эти все тормоза всплывать начали. Скажем обрабатывать за секунду свойства сотен тысяч объектов, будет по любому очень накладно. Не знали, но alife():object сделали. Умора! Функция alife_object всегда возвращает CSE_ALifeDynamicObject, и никакой другой. Так что, видимо все-таки не знали Shoker На моей практике, без дополнительного кода ничего не получится. Экспорт свойств через luabind требует "ручной работы", зачастую рутинного перечисления выдаваемых наружу свойств. Для актора уже большая часть свойств доступна. |
 
|
|
14.08.2014, 19:13
Сообщение
#1824
|
|
Игровой Эксперт Репутация: 407 Группа: Участник Сообщений: 2394 Награды: 5 Регистрация: 19.01.2009 |
Есть генераторы для луабинда
Liabindcxx |
 
|
|
14.08.2014, 19:23
Сообщение
#1825
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
Покажите код, в котором копируются все свойства объектов. второй раз покажу, это нетрудно — local box = level.object_by_id(id).ammo_box p.s. поправочка: во время создания ссылки на таблицу ammo_box (если у этой таблицы переопределен метаметод __index), либо еще раньше (для предварительного заполнения членов таблицы). использование методов же гарантирует отсутствие лишних действий. если у таблицы тысяча методов, то вызывать они будут по требования. если же там тысяча членов, то их нужно чем-то заполнить перед вызовом, даже если потребуется всего один из них. и да, box.curr = box.curr + 1 это не ООП. ООП это как минимум box.set_curr(box.get_curr + 1), особенно в Lua, где невозможно нативное создание приватных членов. Сообщение отредактировал HikeR - 14.08.2014, 19:47 |
 
|
|
14.08.2014, 20:12
Сообщение
#1826
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
1. второй раз покажу, это нетрудно — local box = level.object_by_id(id).ammo_box 2. и да, box.curr = box.curr + 1 это не ООП. ООП это как минимум box.set_curr(box.get_curr + 1), особенно в Lua, где невозможно нативное создание приватных членов. 1. Так мне надо увидеть код в исходниках luabind. Ничего подобного я не нашел, скажем в функции construct_lua_class_callback нет никаких намеков на копирование чего-либо. А метатаблица создается один раз. Расходы на создания враппера object_rep безусловно имеются, но они фиксированные и на современных процессорах могут считаться исчезающе малыми. Имхо некоторые COM-интерфейсы куда дороже обходятся, и ничего - используют люди. Если потребуется гоняться за экономией 1000 тактов ЦП на доступ к свойству, то уж лучше тяжелый код в движок сразу перетащить, разве не так? Кстати не исключаю возможности кэширования object_rep в часто используемых объектах, с отключением сборщика мусора. Тогда расходы будут совершенно ничтожными, сравнимыми с smart_cast. Если уж говорить об качественной оптимизации для скриптов, я за время своего знакомство с ТЧ обнаружил массу тормозов именно из-за некорректного использовании API, а не на реализации. Скажем чего стоит только перебор 65535 объектов, с вызовами level.object_by_id или alife():object. Особенно весело, когда сканирование ведется несколько раз подряд. Решил эту проблему только выделением поиска в двоичный код, для чего в перехватчике реализовал реестр игровых объектов. И там в самом деле приходится копировать указатели на всех объекты, и часть свойств регулярно копировать. Но результатом стала огромная оптимизация поиска. Поскольку появились исходники движка, это можно сделать и на С++, без использования копии списков объектов. 2. Хм, так ведь не обязательно использовать всегда .def_readwrite. Если требуется валидация значения при присвоении, куда правильнее использовать .property, а не редко без оного и вовсе не обойтись. Сообщение отредактировал alpet - 14.08.2014, 20:16 |
 
|
|
14.08.2014, 20:38
Сообщение
#1827
|
|
Геймер Репутация: 15 Группа: Участник Сообщений: 137 Награды: 2 Регистрация: 11.01.2014 |
Снова своими кривыми руками пытаюсь скомпилировать сорсы ЧН 10 патч. Сейчас собираю xrEngine, но никак не могу собрать. Папки вроде бы прописал все, что нужны. Если компилировать на Mixed-конфигурации, то получается вот такой
Сообщение отредактировал User_X.A.R26 - 14.08.2014, 20:51 |
 
|
|
14.08.2014, 21:02
Сообщение
#1828
|
|
Продвинутый геймер Репутация: 15 Группа: Участник Сообщений: 322 Награды: 3 Регистрация: 01.05.2014 |
User_X.A.R26, можно логи по нормальному прикрепить, а то как-то скачивать или куда-то переходит не охото, ну или выдержку из них?
Сообщение отредактировал MegaNub - 14.08.2014, 21:04 |
 
|
|
14.08.2014, 21:38
Сообщение
#1829
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
Так мне надо увидеть код в исходниках luabind. luabind — всего лишь обертка над Lua C API, с огромным геморроидальным пластырем в виде boost-а. а луашное апи это набор функций для работы со стеком, lua_pushXXX добавляет в стек, lua_toXXX достает из стека (XXX = integer, string, function и прочие поддерживаемые типы), плюс двусторонний вызов ф-ий. никакой самостоятельностью luabind не занимается, тупо генерит тонны шаблонного кода из пары строчек. но вот сейчас я посмотрел внимательнее на пример и хочется уточнить один момент прежде чем продолжить. Код ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1 что вы хотели сказать присваивая методу (т.е. обычной функции) значение??? |
 
|
|
14.08.2014, 21:41
Сообщение
#1830
|
|
Опытный Игрок Репутация: 15 Группа: Участник Сообщений: 62 Награды: 2 Регистрация: 20.04.2010 |
User_X.A.R26, в логе же сказано, что oalibmt.lib скомпилена более старой студией нежели ваша. Как вариант нужно пересобрать либу oalibmt.lib вашей версией студии.
-------------------- «Если я знаю, что знаю мало, я добьюсь того, чтобы знать больше... В.И. Ленин»
|
 
|
|
14.08.2014, 21:41
Сообщение
#1831
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
|
 
|
|
14.08.2014, 22:05
Сообщение
#1832
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
что вы хотели сказать присваивая методу (т.е. обычной функции) значение??? Увлекся копипастой, вот и написал ерунду. Надеюсь понятно, что я на самом деле имел в виду. знаете, лучше продолжайте плодить двойников имеющихся ф-ий. Это не справедливо. Свойства актора кроме как моими методами ещё не достаются в движке, по крайней мере большая часть. Сообщение отредактировал alpet - 14.08.2014, 22:06 |
 
|
|
14.08.2014, 22:24
Сообщение
#1833
|
|
Ветеран Репутация: 5 Группа: Участник Сообщений: 82 Награды: 2 Регистрация: 11.07.2014 |
Это не справедливо. Свойства актора кроме как моими методами ещё не достаются в движке, по крайней мере большая часть. Этой действительно так, но главное, чтобы в любой момент можно было использовать "старые" методы оригинала. Иначе тяжелая адаптация может просто отпугнуть от патча модмейкеров) -------------------- |
 
|
|
14.08.2014, 22:31
Сообщение
#1834
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
все равно не понимаю. хочется больше ООП, но стандартные геттеры/сеттеры заменяются на небезопасный прямой доступ. вместо быстрого вызова по ссылке db.actor создается его двойник get_actor_obj().
помимо актора есть еще туча объектов. натравите toLua++ на заголовки нужных классов — получите доступ из луа ко всем классам/членам/чему угодно, без необходимости ручками прописывать биндинги каждому классу/члену/чему угодно (с оговорками, ессно). вот будет раздолье... вот банальный вопрос: почему разработчики постоянно юзают "страшную" скриптовую функцию типа isMonster/isStalker вместо того чтобы для каждого объекта хранить дополнительный тип? ответьте на него и вам сразу станет понятна безперспективность в развитии выбранного вами способа облегчения жизни скриптописателя. |
 
|
|
14.08.2014, 23:12
Сообщение
#1835
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
Этой действительно так, но главное, чтобы в любой момент можно было использовать "старые" методы оригинала. Иначе тяжелая адаптация может просто отпугнуть от патча модмейкеров) Согласен, методы оригинала абсолютно неприкосновенны. 1. все равно не понимаю. хочется больше ООП, но стандартные геттеры/сеттеры заменяются на небезопасный прямой доступ. 2. вместо быстрого вызова по ссылке db.actor создается его двойник get_actor_obj(). 3. помимо актора есть еще туча объектов. натравите toLua++ на заголовки нужных классов — получите доступ из луа ко всем классам/членам/чему угодно, без необходимости ручками прописывать биндинги каждому классу/члену/чему угодно (с оговорками, ессно). вот будет раздолье... 4. вот банальный вопрос: почему разработчики постоянно юзают "страшную" скриптовую функцию типа isMonster/isStalker вместо того чтобы для каждого объекта хранить дополнительный тип? ответьте на него и вам сразу станет понятна безперспективность в развитии выбранного вами способа облегчения жизни скриптописателя. 1. Luabind сам генерит геттеры и сеттеры для свойств. Если где-то отдельно нужны проверки на диапазон, можно без проблем использовать движковые геттеры и сеттеры через .property. 2. А как ещё-то? db.actor это переменная класса object_rep с отсылкой на обертку CScriptGameObject для объекта актора. В то время как get_actor_obj() возвращает object_rep с ссылкой на CActor и соответственно другой метатаблицей. Мне никакого интереса загрязнять CScriptGameObject всеми свойствами актора нет. 3. Это только кажется просто. А на самом деле отдельные свойства надо конвертировать, выводить из глухой приватности класса - автоматика тут не поможет. 4. Сильно сомневаюсь, что они это по требованиям высокой производительности сделали. Скорее ради большей багоустойчивости скриптового API. Алаверды: почему разработчики сделали выдачу интерфейсов get_car, get_hanging_lamp, они же могли и эти свойства засыпать в game_object по идее? |
 
|
|
14.08.2014, 23:27
Сообщение
#1836
|
|
Почти Игроман Репутация: 127 Группа: Участник Сообщений: 643 Награды: 3 Регистрация: 29.09.2012 |
|
 
|
|
15.08.2014, 00:14
Сообщение
#1837
|
|
Магистр Игры Репутация: 270 Группа: Участник Сообщений: 2620 Награды: 4 Регистрация: 26.03.2007 |
1. lua-скрипту совершенно фиолетово что там генерит luabind, он (luabind) работает для си-программиста, а не для скриптописателя.
2. поэтому вы решили загрязнить глобальное пространство имен в Lua? странный подход. 3. приватные члены на то и приватные, чтобы их не трогали и никуда не выводили. и toLua в корне отличается от luabind-а, корпеть над каждым "свойством" не нужно. 4. нет связи с багоусточивостью, скорее наоборот, нужно отслеживать все такие ф-ии и своевременно добавлять в них новые проверки (по мере разработки). p.s. уточняющий вопрос, от экспорта в скрипты абсолютно всех классов/переменных вас останавливает только трудоемкость и рутинность этой операции и ничего более? Сообщение отредактировал HikeR - 15.08.2014, 00:34 |
 
|
|
15.08.2014, 00:45
Сообщение
#1838
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
2. поэтому вы решили загрязнить глобальное пространство имен в Lua? странный подход. 3. приватные члены на то и приватные, чтобы их не трогали и никуда не выводили. и toLua в корне отличается от luabind-а, корпеть над каждым "свойством" не нужно. 4. нет связи с багоусточивостью, скорее наоборот, нужно отслеживать все такие ф-ии и своевременно добавлять в них новые проверки (по мере разработки). 5. уточняющий вопрос, от экспорта в скрипты абсолютно всех классов/переменных вас останавливает только трудоемкость и рутинность этой операции и ничего более? 2. Уж лучше добавить 1 функцию в _G, чем пару десятков в game_object. 3. И что-же поделать, если по замыслу разработчиков класса они приватные, а мне нужен доступ RW? 4. Так что-же, они просто хотели сэкономить 100 мс процессорного времени за час работы движка? 5. Целесообразность, вот чем я руководствуюсь. То что я сейчас вытаскиваю наружу, уже давно и успешно используется в моде NLC, только там приходится тупо напрямую с памятью работать. По мне так, это пока один из немногих модов, где исчезает статичный мир оригиналки - и все становиться более-менее изменчивым. |
 
|
|
15.08.2014, 07:44
Сообщение
#1839
|
|
Продвинутый геймер Репутация: 15 Группа: Участник Сообщений: 322 Награды: 3 Регистрация: 01.05.2014 |
|
 
|
|
15.08.2014, 11:15
Сообщение
#1840
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
|
 
|
|
15.08.2014, 12:17
Сообщение
#1841
|
|
Геймер Репутация: 19 Группа: Участник Сообщений: 130 Награды: 2 Регистрация: 24.05.2008 |
alife():object возвращает конкретный серверный класс. Если был зарегистрирован скриптовый, то возвращает скриптовый серверный класс. Ок. Тогда предскажите выполнение следующего кода: Код local sa = alife():object(0)
if sa then if sa.reputation then printf(" actor reputation %s ", sa:reputation()) else printf(" object 0 is not cse_alife_creature_actor ") end end |
 
|
|
Текстовая версия | Сейчас: 05.05.2024, 04:35 |