Сообщений в теме: 783

[XEPOMAHT007]

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

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

[Rockets]

может с чит девайсом можно машины поменять? Ведь там можно заменить главного перса на любого персонажа.

[SILENT_Pavel]

Rockets
Ну перса можно менять и обычным кодом

Random Ped Outfit	L1, L1, LEFT, L1, L1, RIGHT, SQUARE, TRIANGLE

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

Сообщение отредактировал SILENT_Pavel: 21 June 2012 - 07:53

[Rockets]

Рандом есть рандом. В читдевайсе номер перса выбирается. Я так понимаю, что на псп просто кусок в память грузиться, один в один. Читдевайс просто может менять значения на лету. Вот пример кода: # Cheat BLOOD! Advance setchar (0x0967C5B1, 0xFF); setchar (0x0967C5B2, 0xFF); setchar (0x0967C5B5, 0xFF); setchar (0x0967C5B6, 0xFF); setchar (0x0967C5B7, 0x3D); setchar (0x0967C603, 0xA3); setchar (0x0967C5F3, 0x3D); setchar (0x0967C5E2, 0x00); setchar (0x0967C522, 0xFF); setchar (0x0967C523, 0x3E); setchar (0x0967C55B, 0x00); setchar (0x0967C56F, 0x00); setchar (0x0967C624, 0x10); setchar (0x0967C590, 0x10); setchar (0x0967C608, 0x50, 0xFF, 0x00); setchar (0x0967C574, 0x50, 0xFF, 0x00); Получается тогда можно на лету менять значения и смотреть что меняется (это я про машины и их замену местами). Зависаних наверное целый вагон будет. После экзаменов попробую разобраться.

Сообщение отредактировал Rockets: 21 June 2012 - 20:48

[Rockets]

Машины тюнингуют используя также десятичную систему: setshort(0x992FD0C, 0x46, 0x42, 0x49, 0x20, 0x48, 0x69, 0x52, 0x69, 0x64, 0x65, 0x72); setshort(0x9441300, 250); setfloat(0x94412fc, 0.775); setfloat(0x945a6d4, -0.7875); setfloat(0x945a69c, 1.25); setfloat(0x945a6a0, 1.25); setfloat(0x945a694, 0.00388); sethex(0x945a6e0, 0x83, 0x81, 0x00, 0x01); setchar(0x967E6FC, 0x00, 0x00, 0xFF); sethex(0x944fb3c, 0xFF, 0xFF, 0x00); sethex(0x944fb0c, 0xFF, 0x00, 0xFF); setint(0x8E38A38, 148); sethex(0x8E38A5E, 0x01, 0x00); teleport(292.22, -440.37, 26.02); setchar(pplayer + 0xB84, 0x00);

[Dageron]

Вот уже тридцать страниц обсуждения - и никакого, увы, конструктивного консенсуса. Конечно, общими усилиями удалось разорбрать достаточно много, но в итоге информация разрознена до невозможности. Статья, конечно, сильно устарела. Ее надо переделывать, при чем основательно, но ситуацию это не сильно исправит. Возможно, стоит обсуждать все в несколько ином формате, как минимум, разделив на разные темы обсуждение карты c моделями, текстур и скриптинга (а все "общие" вопросы, в том числе касательно PSP-шного cheat device, обсуждать в данной)?

[XEPOMAHT007]

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

Сообщение отредактировал XEPOMAHT007: 28 July 2012 - 01:49

[LEX SAFONOV]

Чего то много циферок там у авто. Если ориентироваться на вайсишный аналог, то больше половины чисто мусор, хотя в ЛСС немного своя структура, мб там ещё для чего намутили...

[SILENT_Pavel]

XEPOMAHT007
Организовать бы рабочий обмен машинами между сториесами, было бы здорово. тобишь достать все остальные "блокноты" которые так или иначе отвечают за эти параметры.

Сообщение отредактировал SILENT_Pavel: 28 July 2012 - 13:09

[tram73]

XEPOMAHT007, а где сам файл не понял?

[SILENT_Pavel]

tram73
тут

[Lego]

Преобразовал статью по DTZ в более адекватный вид. Теперь видна настоящая ценность статьи: одна (!) структура и один(!) оффсет. остальныет данные, по сути, нафиг никому не нужны без структур и оффсетов.
Имена-аналоги "в будущем" точно также нафиг никому не нужны (тем более - фантазии на эту тему а-ля menu.chk), ибо данные больше никто не считывает fscanf'ами из текстовых файлов - данные уже считаны и писать что-то про текстовые файлы нет смысла. Предлагаю указать их один раз в таблице и далее опираться на настоящие факты.
Мифические WRLD тулзы тоже как-то не радуют. Точно также можно было бы написать, что эти файлы открываются хекс-редактором, а толку-то?

Декомпилированный хандлинг из ЛСС.

могу поспорить, что handling не содержит ни байта исполняемого кода. какая, блин, декомпиляция O_o? Грубо говоря, это просто дамп данных в текстовой формат, не?

а чем можно отредактить формат TM2? фотошоп не открывает, паинт тоже

Есть еще плагин к фш, но я не встречал и как-то не пользуюсь.

имхо как раз лучше плагин к фш  tm2xFormat.rar   24.52К   56 загрузок - он уже мелькал в этой теме.

[XEPOMAHT007]

Теперь видна настоящая ценность статьи: одна (!) структура и один(!) оффсет. остальныет данные, по сути, нафиг никому не нужны без структур и оффсетов.

А ты что хотел? Те, кому нужны были данные из GTAGAME от сториесов, наверняка давно уже написали структуры со всеми оффсетами и держат их при себе. Статья даёт абстрактное преставление о DTZ, больше от неё не требуется (т.к. моддить DTZ без пересборки фактически нереально, разве только можно менять растры и переставлять местами всякие данные в аналогах DAT-файлов). На буржуйском гтамоддинг.ком вообще по сториесам ничерта нету, кроме ссылок на посты продвинутых юзеров гтафорумса.

Имена-аналоги "в будущем" точно также нафиг никому не нужны (тем более - эротические фантазии на эту тему а-ля menu.chk), ибо данные больше никто не считывает fscanf'ами из текстовых файлов - данные уже считаны и писать что-то про текстовые файлы нет смысла. Предлагаю указать их один раз в таблице и далее опираться на настоящие факты.

Факты фактам рознь. GTAGAME в сториесах основано на GTA VC, где например все коллекции текстур проименованы, соответственно, перед компиляцией данных в DTZ, ресурсы сториесов тоже не были безымянными. Пускай моддеры придумают им новые имена, например что-то нибудь типа TombRider.chk, авось и угадают оригинальные.

Мифические WRLD тулзы тоже как-то не радуют. Точно также можно было бы написать, что эти файлы открываются хекс-редактором, а толку-то?

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

могу поспорить, что handling не содержит ни байта исполняемого кода. какая, блин, декомпиляция O_o? Грубо говоря, это просто дамп данных в текстовой формат, не?

А как ещё можно это обозвать? Порча имущества Рокстаргеймз?

Если по сути, то в статью про DTZ просто свалили что-то непонятное, твои изменения сделали её для меня ещё менее понятной.

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

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

В третьих, таким типом структуры, которым описано например weapons data, описать весь DTZ очень сложно. Да, огрызки ресурсов (а каждый ресурс в DTZ представлен множеством вложенных друг в друга таблиц в иерархическом порядке) так представлять можно, но что-то модифицировать в ней так просто не получится - отредактировав одну таблицу, без редактирования оставшихся связанных с ней успехов не принесёт. Сториесы сделаны по-консольному, а вы их пытаетесь воспринимать как будто они мультиплатформенные.

В четвёртых, это уже не актуально - как никак гта-моддинг уже отжил своё, спасибо скажем RAGE, который совершенно не привлекателен и довольно затруднителен к использованию в качестве основы для мода. Ну а сториесы тем более никуда не годятся - консоли есть консоли - очень мало человек ими интересуется в качестве платформы для моддинга + зубодробительные консольные форматы моментально отталкивают почти всех, кто с ними сталкивался вслепую.

[solom]

http://www.gtamoddin...?title=Game.dtz
Перевёл нашу статью на англ. язык, правда не до конца.

Added:
Решил посмотреть файл handling.cfg из LCS. Структура там действительно отличается, а также там добавлен какой то порядковый номер. Вот набросал кое какую структуру:

a - Имя машины
b - Вес машины
c,d,e - Неизвестно
f - Порядковый номер строки машины в handling.cfg.
g -

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

Кстати, ради наглядности можно сравнить handling GTA 3 с LCSшным.
GTA 3:

YAKUZA 1400.0 1.9 4.7 1.6 0.0 0.25 -0.3 -1 0.95 0.9 0.5 5 200.0 30.0 4 P 11.0 0.45 0 30.0 2.6 0.1 0.25 0.7 35000 0.28 -0.14 0.5 180 1 1

LCS:

YAKUZA 1400.00, 2800.00, 0.80, 0.86, 49, 0.00, 2.40, 0.00, 0.00, -0.20, -0.25, 0.00, 75, 14.93, -0.20, -0.01, -0.20, 0.28, 0.19, -0.01, 0.46, 0.40, 0.12, 0.65, 0.59, 0.36, 0.83, 0.77, 0.54, 1.01, 1.01, 0.72, 4, P, 5, 0.00, 5.00, 1.01, 0.84, -0.20, 0.00, 0.00, 0.50, 0.00, 30.00, 0.80, 0.53, 0.00, 1.40, 0.10, 0.28, -0.15, 0.50, 0.30, 10000000, 0.25, 35000, 1, 1

Кстати у лссшного формата используется функция общего хэндлинга (я её бы так и назвал бы). Можно присвоить в одной строке три имени транспорта, которые будут иметь одинаковые характеристики. Например вот как тут:

FAGGIO/PIZZABOY/NOODLEBOY 350.00, 119.60, 1.80, 0.63, 66, 0.00, 5.00, 0.00, 0.00, 0.05, -0.10, 0.00, 103, 2.72, -0.05, -0.01, -0.05, 0.30, 0.20, -0.01, 0.49, 0.43, 0.13, 0.68, 0.68, 0.38, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, R, P, 3, 0.00, 5.00, 0.68, 0.57, -0.05, 0.00, 0.01, 0.50, 0.00, 35.00, 0.90, 0.48, 0.00, 1.00, 0.15, 0.12, -0.17, 0.50, 0.00, 00010003, 0.00, 10000, 1, 1

Сообщение отредактировал solom: 31 July 2012 - 03:58

[Lego]

> Во вторых, почему-то структуру DTZ зачем-то разбили на таблицы по категориям, как будто это какой-нибудь IMG-архив с набором файлов внутри.
> Такой подход к формату на мой взгляд не верен.
это был твой старый подход, он неудобен. никаких файлов там нет, там вот именно, что дамп памяти. информация сгруппирована по типу (лучше группировать по оффсету, но ГДЕ он?), чтобы проще было искать.

> Сториесы сделаны по-консольному, а вы их пытаетесь воспринимать как будто они мультиплатформенные.
и кто тут что воспринимает? и что значит "по-консольному"?
данные на консоли всего лишь более оптимизированы под целевую платформу и не более того. ничто не мешает написать алгоритм де-swizzling'а, распаковки zlib и т.д.
тут даже сжатия нет как на икс-боксе.
всё модифицируется, да и не сказал бы что запредельно сложно, а форматы проще чем в 4ке.
нет просто толковых людей, которые бы занимались этим, как занимались пк-шными форматами. (согласен, так всегда было с консолями).

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

>Пускай моддеры придумают им новые имена
не, ну я не спорю, что при разборе ресурсов зачастую имена классов берутся с потолка, но в этом есть необходимость. аналогично можно выдумывать имена не для файлов, а для структур.
использовать имена неверно в корне, listener об этом уже говорил. имхо за год удобства никакого не прибавилось, поэтому я предлагаю отказаться от этой затеи. в разговори ещё можно использовать, но уж не в готовой статье.

> компиляция, декомпиляция
википедия в помощь. компиляция, грубо говоря есть преобразования некоего исполняемого кода (например, компиляция кода миссий в СБ). здесь же имеет место просто чтение ресурсов с диска и сохранение в памяти в виде структур (и дамп этой памяти на диск).
возможно, в DTZ и есть какие-то скомпилированные данные, но не в данном случае.

> Толк в том, что они таким образом "восстанавливаются" до читаемого, например в блокноте, вида.
я имею ввиду, что если прогу не скачать - смысл о ней писать? для себя что ли?

> моддить DTZ без пересборки фактически нереально, разве только можно менять растры и переставлять местами всякие данные в аналогах DAT-файлов).
более чем реально, с учётом того что почти все эти файлы модифицируются заменой старых данных, а не добавлением новых.

[XEPOMAHT007]

лучше группировать по оффсету, но ГДЕ он?

А смысл, если в каждой версии LCS или VCS он будет разный? Во вторых теблица с ресурсом (например аналог IDE) может собираться из нескольких структур. В третьих, оффсеты на все ресурсы в DTZ свалены в одну большую таблицу, которую я называю глобалсекцией (она есть во всех файлах) - сами рокстары уже об этом позаботились. Но и по оффсетам из глобалсекции читать файл тоже неккоректно - он наверное используется для проверки, т.к. если его повредить, то часть содержимого в DTZ уже игрой не воспринимается, т.е. на неё просто не выделяется память в консоли.

[Lego]

у меня иногда такое ощущение что у вас есть все данные, но вы то ли не знаете что, то ли не хотите что-либо делать с ними ты мне пытаешься опять сказать "Лего, вообще-то там уже есть структура для этого, но я не знаю как её расписать... поэтому ну её фтопку" я-то сторисы не разбирал, мне их моддинг не особо интересен - я могу не знать текущее положение дел по разбору ресурсов, так что вам и карты в руки. если есть какие-то структуры, то лучше расписывайте их на вики - она для этого и нужна. > А смысл, если в каждой версии LCS или VCS он будет разный? так всего 4 основных версии, можно и указать. да что там, оффсеты только для PS2 версий уже были бы неплохим началом. но, раз ты говоришь, что... > оффсеты на все ресурсы в DTZ свалены в одну большую таблицу, которую я называю глобалсекцией (она есть во всех файлах) её наличие вполне логично. эту таблицу в идеале и нужно было расписать!

[XEPOMAHT007]

её наличие вполне логично. эту таблицу в идеале и нужно было расписать!

Не нужно её расписывать. Эта таблица не является специфической для DTZ. Я повторю, что она присутствует во ВСЕХ файлах сториесов и манхунта 2. Да, по ней можно прочитать все ресурсы, но сама игра по ней ресурсы не читает. Это как шкаф с миллионом полок, чтобы что-то конкретное достать с полки, нужно открыть в шкафу нужную дверцу, т.е. прочитать список группы ресурсов с оффсетами на подсписки и т.д., пока не дойдёшь до последней "веточки", содержащим сам ресурс - текстуру, модельку или что-нибудь ещё. Понятно, что файл преставляет собой сложную древовидную структуру - в ВИКИ такую штуку как можно реализовать? Конечно, можно создать миллион страничек с гиперссылками, но это очень не удобно. Если бы можно было бы в ВИКИ нарисовать такую штуку, то структуру DTZ показать можно было бы без проблем: http://ru.wikipedia....yTreeSample.png

[Lego]

> Это как шкаф с миллионом полок
интересная аналогия на тему деревьев

а RW Stream, по-твоему, как выглядит? Правилно, в виде дерева. Только не двоичного. И ничего, расписали без особых проблем. Вообще,

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

[Dageron]

Успокойтесь вы, ну что за спор?)
Видно как раз яркий случай того, что тридцать страниц разговоров, - и никакого конструктивного консенсуса.

таким типом структуры, которым описано например weapons data, описать весь DTZ очень сложно. Да, огрызки ресурсов (а каждый ресурс в DTZ представлен множеством вложенных друг в друга таблиц в иерархическом порядке) так представлять можно, но что-то модифицировать в ней так просто не получится - отредактировав одну таблицу, без редактирования оставшихся связанных с ней успехов не принесёт. Сториесы сделаны по-консольному, а вы их пытаетесь воспринимать как будто они мультиплатформенные.

На самом деле там все не совсем так. В *.dtz/*.lvz использовались многоуровневые C++ шаблоны (не путать с 010 "шаблонами", где таких шаблонов как раз и нет) и коллекции, которые можно использовать где угодно (хоть на консолях, хоть на ПК); ибо их основное назначение - экономия памяти, ускорение загрузки и сохранения. Это мощное ООП, которое можно реализовать только в C++ (в Delphi, правда, тоже можно, но с заметными нетривиальными манипуляциями). Изначально загрузка "ресурса" занимает всего пару строк, а при сохранении компилятор сам (грубо говоря) "раскладывет все структуры внутри файла" (в исходниках предусматривалось, что структуры ссылаются друг на друга; при сохранении, соответственно, указатели заменяются смещениями и т.д).

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

Отсюда следует два варианта.

Вариант первый. Постараться расписать все структуры так, как они выглядели в оригинале, использовать многоуровневые шаблоны. Тогда действительно и загрузка будет занимать пару строк, и сохранение (так что не только пересборку можно будет делать, но и свое что-то новое добавлять). Но самый большой нюанс - для этого game.dtz должен быть разобран досконально, т.е. не по фрагментам, а именно иерархией классов и структур один-в-один как было у R*. Сделать это, так скажем, непросто.

Вариант второй. Добираться до нужных данных внутри *.dtz/*.lvz опытным путем, запомнить оффсеты основных структур и прочего содержимого. Работать с этим содержимым в определенных рамках (например, в пределах размера всего оригинального).

Оба варианта целесообразны в разных ситуациях, все зависит от поставленной задачи.

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

Задача XEPOMAHT007, очевидно, извлечь максимум с консолей чтобы перенести Stories на ПК. Тут конечно был бы больше рационален первый путь, но, во-первых, действовать в его рамках очень непросто, и, во-вторых, тогда надо вообще весь подход к переносу Stories на ПК кардинально менять. Вот и приходится пробиваться через hex по всем перекликающимся таблицам внутри *.img/*.lvz практически вручную.

Есть и другая задача - создать некую площадку для моддинга, пусть даже небольшого. Поменять weapondata, handling и переделать пару текстур - согласитесь, многим всегда приятно. Только вот надо ли для этого тратить силы и время, досконально разбирать game.dtz? Очевидно, нет.

Вывод напрашивается один, - чтобы что-то сдвинулось в плане создания площадки под моддинг, надо выкладывать наработки и описания. Пусть неоконченные, но чтобы был общий источник информации. Об этом и я, и SILENT_Pavel, писали уже неоднократно (и, что самое интересное, Lego тоже это же самое уже не в первый раз повторяет).

Вот, скажем, описания timecyc у меня нет, а у XEPOMAHT007 и его команды есть, но когда и я, и SILENT_Pavel спрашивали (тут и тут) про timecyc, это было проигнорировано. Когда в 2010 я разобрал текстуры внутри game.dtz и разрабатывались первые версии Texture Explorer-а, почему-то делился даже непубличными build-ами (не говоря уже о том, как удалось в 2009 и про zlib все понять, и откопать запакованные menu/fonts, что пригодилось всем интересовавшимся), так что же сейчас?

Оффсеты структур и сами структуры, которые расписаны у меня, конечно постепенно буду выкладывать.
Раз начали говорить про handling - начну с него, VCS и LCS (там они, кстати, разные).
Сейчас доведу до ума редактор, чтобы была хоть полноценная программа для работы с параметрами автотранспорта.
Будет программа - будет проще поэкспериментировать и расписать неизвестные поля.

И на самом деле Lego прав по поводу того, что нет смысла указывать в статье программы, которые есть только у авторов (и почти наверняка еще и сильно недоработаны), с таким же успехом можно было бы указать какой-нибудь абстрактный "R* SDK". А вот на счет имен имен не соглашусь - раз имен файлов нет, то для большего понимания они как раз нужны (menu.chk/fonts.chk как было в первой версии DTZ Editor и т.д.).

оффсеты на все ресурсы в DTZ свалены в одну большую таблицу, которую я называю глобалсекцией (она есть во всех файлах)

Эта таблица не является специфической для DTZ. Я повторю, что она присутствует во ВСЕХ файлах сториесов

Если это та таблица про которую я подумал (у aru в исходниках GTA Stories Texture Viewer она называлась relocation table), то предназначается она для для распределения памяти. Так, в *.chk/*.xtx некоторые содержащиеся в этой таблице оффсеты ведут на начало графики, поля width/height и тому подобные; в *.dtz (и *.wrld) - на другие таблицы и на конкретные части этих таблиц.