Gildor's Forums

C другой стороны, кто решится редактировать написанную Вами статью в Википедии?
Вам, как автору, виднее что писать и что не писать о программе.

Ладно - оставил в обсуждении отзыв, посмотрим, может не удалят.

Консольные утилиты в загоне, как предназначенные для узкого круга специалистов.

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

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

Ок!
Всё ясно, спасибо огромное!

Ок. Ясно.
(Извините за то, что я неясно сформулировал вопрос в первой теме -
оговорка по Фрейду - интересовал, конечно же, не UCC.exe, а Extract.exe)

А какие ещё аргументы командной строки имеет Extract.exe?
Возможно ли с его помощью извлечение только указанного вида ресурсов?

Здравствуйте, Gildor!
Возникло несколько вопросов:

1)Extract.exe имеет какие-нибудь ключи запуска?
Например, только извлечение указанного вида ресурсов?

2)Или только листинг ресурсов, а не их извлечение?

3)Просматривая таблицы импорта/экспорта, обнаружил, что они имеют формат Class'Package.Name', хотя должно быть Class'Package.Group.Name'. Хотелось бы понять логику такого упрощения.

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

Из замеченных глюков - в играх на движке UnrealEngine2 не подгружаются при просмотре текстуры.
Будем надеяться, что автор разберется с проблемами.

Gildor, хочу спросить, пользуясь случаем - исходники будут, или вы отказались от мысли о их публикации?

Спасибо.
Если текстуры будут нормально накладываться - я не вижу причин возражать против использования PSK.

Все ранее существовавшие экспортеры статик-мешей отличало то, что при экспорте искажалось наложение текстур.
Будем надеяться, что с UnrealModelViewer-ом всё будет ОК.

Для написания DLL этого оказалось достаточно.

Скачал в интернете исходники UT3, с их помощью частично решил проблему.
(на удивление, код оказался довольно вменяемым, хотя и не полным).

Интересно, а исходников Unreal Engine 2 нигде в интернете не завалялось?
А то несправедливо получается: UT1 есть, UT3 есть, а для UT2 ничего нету....

Длину параметров, передаваемых при вызове функции.
Имея эту длину, можно создать Lib-файл.

Ок. Буду пробовать.

Вопрос ко всем, но в первую очередь к Гилдору:

Я пытаюсь скомпиллировать тестовую DLL для UT2004 (3369), но достиг лишь частичного результата:

Dll компилируется, нативный актер ставится на уровень и работает правильно, но при вызове к нему одного из нативных эвентов игра падает.

Подозриваю, что причина заключается в том, что я неправильно определил длину одной или нескольких вызываемых в DLL функций.

В связи с этим вопрос:
1) Как можно определить длину вызываемых в DLL функций?
2) Реально ли получить Header-файлы для Engine.dll и Core.dll (интересует только Ut2004 версии 3369)?
3) Реально ли получить "правильные" Lib-файлы для Engine.dll и Core.dll (интересует только Ut2004 версии 3369)?
4) Если последнее нереально, можно ли получить хотя бы список вызываемых в DLL функций с указанием их длины? (типа _autoclassUArrayProperty@2235) ?

Буду очень благодарен, если кто-нибудь даст ответы...

Cheiser:
Те скрипты, которые можно экспортировать из эдитора, практически никак не влияют на анимацию, поскольку вся анимация определяется файлами Core.dll и Engine.dll, код которых доступен только купившим лицензию на движок.

Собственно говоря, "Актор" классы, и объекты анимации вызываются ядром движка независимо друг от друга, и могут обращаться друг к другу лишь по названиям.
Анимация состоит не из актеров, а из нескольких С++ объектов, которые из эдитора не экспортируются.

Купив лицензию, разработчики получают от Эпиков некий "начальный" С++ код, который дальше могут менять как хотят. Достаточно поменять одну переменную в С++ коде, чтобы модель перестала открываться (полностью или частично).

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

Обладая соответствующим опытом, можно искусственно подогнать длину параметров, либо затереть их, передав в DLL "пустышку", но в этом случае модель откроется с глюками (или не откроется вообще).

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

Единственный правильный вариант - расшифровать все хранящиеся в Ukx-файле параметры, и редактитровать их либо в ukx-файле, либо в dll (насколько я понимаю, именно так сделал Gildor в своей утилите), но для этого нужна соответствуюшая база знаний, а её нету.

Разумеется. поэтому я и не советовал этого делать.

Приведу простейший пример: открывать текстуры Unreal1 в UT2004 можно, но при этом они теряют детализацию, поскольку соответствующее свойство в U1 называлось DetailTexture, а в UT2004 - просто Detail.
Заменяем HEX-редактором DetailTexture на Detail0000000 - и вау - детализация появляется.

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

Как раз есть чего: движок Unreal открывает пакет, считывая находящуюся в начале него таблицу имен. Именно на таблице имен редактор/игра и падают: когда находят в таблице ссылку на несуществующий пакет, или на свойства, которых нет в данном классе.

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

В определенных условиях, пакет одной версии можно открыть "чужим" редактором (или в "чужой" игре), нахимичив с таблицей имен, но геморроя столько, что лучше и не пытаться.

Увы, "полностью дезассемблировать" их можно за 5 минут.
А вот декомпилировать полностью - действительно не один год работы :-)

Однако, насколько я понимаю ситуацию, DLL содержит кучу "экспортных функций", вызываемых независимо друг от друга.

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

Пока что этот вопрос интересует меня лишь теоретически.
Я довольно плотно работал с Unrealscript, и знаю, что есть некоторые твики, для "обхода" нативных функций и классов. Можно "отключить" нативную функцию, можно её выполнить, но затем полностью изменть результаты её работы, можно, если извратиться, выполнить вместо нативной левую DLL.
Однако сами DLL изменить я не могу, и наличие неразрешимых задач меня раздражает.