Программирование под UT2004 ?

[Gildor]

Привет!
Спасибо за отзыв - я не был уверен, что люди разберутся, как пользоваться тулзой (а gui делать как-то лень) 
Программа была написана тогда, когда мне по месту работы было необходимо реализовать скелетную анимацию - я решил за что-то зацепиться, и выбрал UT.
Для получения алгоритмов/форматов провёл неделю в IDA (interactive disassembler). Очень помогли публичные хидеры от UT1.
Для реализации, конечно, пришлось пере-реализовать часть движка unreal engine (самая сложная часть - формат package-файла).
Исходники обязательно выложу - но чуть позже. Хочу сначала немного доработать программу (в частности, сейчас планирую среверсить StaticMesh, когда время будет).
К нативным функциям вполне можно получить доступ (сам, правда, я этого не делал - не было нужды). Для этого надо реализовать native package - тут поможет unreal tournament public source. Эти исходники, скорее всего, придётся доработать - это зависит от того, какие классы понадобятся. ОЧЕНЬ много информации по этим классам (структуры данных) доступно в .uc файлах, которые также находятся в публичном доступе. Также у меня есть прототипы всех функций движка (втупую выдрал из дизассемблера).

[Gildor]

Дизассемблер нужен в основном для того, чтобы понять, как работает программа. Для того, чтобы получить какие-то внутренние интерфейсы он нужен по-минимуму. Пример.
1) нужны структуры данных - их в UT легко выдрать из скриптов (.uc) - за исключением всяких потоков, массивов и т.п. (классы, имена которых начинаются на "F" не дублируются в скриптах) - это нужно ковырять public headers и asm
2) таблицы виртуальных методов (если хочется такие вызывать) - их достаточно легко выдрать дизассемблером, основной труд - найти такую таблицу (используется в конструкторе)
3) прототипы невиртуальных методов - это можно получить более-менее продвинутым дамперов экспортов dll - нужно сдампить экспорты, раздекорировать имена (поможет UnDecorateSymbolName()), и собрать вместе в виде структуры.
Если не секрет - задачи какого рода вы планируете решать в UT2004 нативным кодом?

[Gildor]

2) В демку, скорее всего, записаны GUIDы всех package-ей. Сделано из соображений совместимости - ведь в демку записывается сетевой трафик, а он содержит вызовы процедур и т.п. - через GUID движок проверяет совместимость вызова функции. Если есть уверенность, что новый package полностью совместим - можно попробовать руками подправить его GUID (заменить на старый). Из native package это, скорее всего, не исправить - это код ядра движка.

3) Если это поправлено в dll (редактирование объектного кода, как я понял) - то есть вероятность, что это можно поправить своим package-ем. Но только если можно подменить класс, отвечающий за savegame своим, и весь изменённый функционал лежит в виртуальных методах.

4) Бамп есть в UE2 (есть поддержка hardware shaders), но его не включили в UT2004. Я сам помню сообщение на эпиковском форуме от Daniel Voguel (сейчас он в epic ведущий программист, а в те времена - рендером занимался). Так вот, он написал - "добавил в движок поддержку аппаратных шейдеров, но в UT решили это не добавлять". Моддингом такое не добавить, нужно рендер дорабатывать Увы, epic никогда не выложит исходники даже 1го Unreal - у них его кодовая база до сих пор используется в движке (это вам не id software, которые несколько раз полностью переписывали движок из-за невозможности двигаться вперёд, ну и выкладывали ненужный более код в свободный доступ).

1) и 5) скорее всего можно исправить скриптами, просто ковыряться нужно дольше. Или вообще никак не исправить (ну, разве что опять бинарники править).

Увы, поковыряться в исходниках unreal engine можно только устроившись программистов в компанию, разрабарывающую какую-нибудь игру на этом движке - а таких в России мало (а у нас в Питере - вроде вообще нет).