Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - aleks926820

Страницы: [1] 2
1
Собственно говоря для чего это все ковырял:
https://libertycity.ru/files/gta-4/193341--wft-file-unlocker-script.html
Написал скрипт для снятия ZModeler Lock с .wft файлов.
Пользоваться просто - снять компрессию с .wft с помощью RSC Manager, скормить скрипту распакованный .wft файл, запаковать .wft файл обратно RSC Manager'ом. Где-то полторы дюжины моделек попробовал - все нормально импортнулись потом в занозу кроме одной модельки. Какая-то кривая моделька походу была, она не импортнулась даже после обработки скриптом для 010 Editor. А так вполне рабочий скрипт я считаю.
P.S. Кто может закиньте скрипт на сайт, пусть тут тоже будет.
P.S.S. Добавлю, что маску 0xFFFFFFF нужно применять ко всем офсетам вида [** ** ** 50] и [** ** ** 60].Это касается всех типов файлов - wdr wft wdd.

2
Ответ найден.
К полученному значению смещения нужно применить операцию логического И с маской 0xFFFFFF. Тогда получится адекватное смещение к секции от начала файла.
На максскрипте это выглядит примерно так:
s=readlong wft #unsigned //читаем 4 байта смещения.
s = bit.and s (bit.hexasint "0xFFFFFFF") // применяем логическое И и получаем офсет в виде целого числа.
После чего смещаемся к полученному смещению от начала файла:
fseek wft s #seek_set //#seek_set означает, что смещаемся от начала файла.
fseek wft 0xC #seek_cur //затем смещаемся на 12 байт от текущего смещения, и следующие 4 байта будет заголовок нужной секции.
P.S. Инфа была раскопана в вебархиве с сайта gtamodding.ru, который уже несколько месяцев недоступен.

3
На днях появилось желание поковырять четверочные файлы моделей (.WFT .WDR). Наткнулся на одну несостыковку в секции Geometry (она одинакова как для .wdr так и для .wft файла).
Geometry (Размер блока 0x50)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор секции (0xF4486B00)
0x04 4b LONG Неизвестно 1 (Usually 0)
0x08 4b LONG Неизвестно 2 (Usually 0)
0x0C 4b Offset VertexBuffer             //4х байтовый офсет на секцию VertexBuffer (смещение указывается от начала файла)
0x10 4b LONG Неизвестно 3 (Usually 0)
0x14 4b LONG Неизвестно 4 (Usually 0)
0x18 4b LONG Неизвестноn 5 (Usually 0)
0x1C 4b Offset IndexBuffer          //4х байтовый офсет на секцию IndexBuffer (смещение указывается от начала файла)
0x20 4b LONG Неизвестно 6 (Usually 0)
0x24 4b LONG Неизвестно 7 (Usually 0)
0x28 4b LONG Неизвестно 8 (Usually 0)
0x2C 4b LONG IndexCount
0x30 4b LONG FaceCount
0x34 2b Short VertexCount
0x36 2b Short PrimitiveType
0x38 4b LONG Неизвестно 9 (Usually 0)
0x3C 2b Short VertexStride
0x3E 2b Short Неизвестно 10 (Usually 0)
0x40 4b LONG Неизвестно 11 (Usually 0)
0x44 4b LONG Неизвестно 12 (Usually 0)
0x48 4b LONG Неизвестно 13 (Usually 0)
0x4C 4b LONG Набивка                 (0xCDCDCDCD)

Здесь меня интересуют офсеты на VertexBuffer и IndexBuffer. 4х байтовый офсет указывает на местоположение секции (смещение секции указано от начала файла, т.е. допустим если указано смещение VertexBuffer 0x3E80 то смещаясь на него от начала файла мы натыкаемся на идентификатор секции VertexBuffer 0xD8BA6B00. (См. ниже)
--------------------------------------------------------------------
VertexBuffer (BlockSize 0x64)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор         (0xD8BA6B00)
0x04 2b Short VertexCount
0x06 2b Short Unknown 1 (Usually 0)
0x08 4b Offset DataOffset to VertexData
0x1C 4b LONG VertexStride (36 without normal map, 52 with normal map)
0x20 4b Offset VertexDeclarationOffset
0x24 4b LONG Unknown 2 (Usually 0)
0x28 4b Offset DataOffset to VertexData (Again)
0x2C 4b LONG Unknown 3 (Usually 0)
0x30 32b LONG    Padding                 (0xCD)
--------------------------------------------------------------------
IndexBuffer] (BlockSize 0x40)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор       (0x70B86B00)
0x04 4b LONG IndexCount
0x08 4b Offset DataOffset to IndexData
0x0C 4b LONG Unknown 1 (Usually 0)
0x10 32b LONG    Padding                 (0xCD)
--------------------------------------------------------------------
И в этих офсетах обнаружилась несостыковка. Я просмотрел .wdr, .wft (один из объектов карты), .wft (модель автомобиля).
В случае с .wdr и .wft (который представляет собой объект карты) офсеты на Vertex Buffer и Index Buffer действительно ведут к этим секциям.
В случае с .wdr файлом и .wft файлом объекта.
(Я просматривал файлы cj_int_plant_4.wdr из int_veg.img и gb_probox03.wft из clothes.img)

А в случае с .wft файлом автомобиля офсет приводит в какую-то другую секцию (admiral.wft из vehicles.img).
Вот собсна несостыковка, о которой идет речь. Офсет приводит в какое-то другое место, а не в секцию Vertex buffer с идентификатором 0xD8BA6B.

При этом реальное местоположение секции VertexBuffer так скажем на смещении 69580 байт, а не на 29184, как указано в Geometry.

Вопрос - почему офсет на секцию Vertex buffer (и аналогично на секцию Index buffer) в .wft файле автомобиля приводит в какую-то другую секцию, а не в эту секцию (Vertex\Index buffer)? Может надо смещаться откуда-то из другого места? Кто в курсе?
Повторюсь, что в случае с .wdr и с .wft, представляющие собой элементы карты\интерьера, все в порядке. Данная ерунда наблюдается только моделями авто.

4
0x6954A8 float - скорость вращения облаков. По умолчанию значение 60.0. Для отключения вращения можно прописать 0.0.
0x6954AC float - высота облаков над уровнем моря. По умолчанию значение 40.0.
0x6958A4 float - отвечает за пульсации солнца. По умолчанию 0.0049.
0x6954C8 float - размер всех облаков. По умолчанию 55.0.
0x6954B0 float  - отвечает за прозрачность облаков. По умолчанию  320.0.
0x6954B4 float  - отвечает за прозрачность облаков.  По умолчанию  160.0.
0x6954AC float - тоже влияет на размер больших белых облаков.  По умолчанию  40.0.

5
Не знаю может уже кто это знает, но на всякий случай скину сюда.
Нашел способ отключения короны и света практически у всех пикапов.
Прошерстил функцию CPickups::DoPickUpEffects в IDA.
Эти три адреса влияют на размер короны:
0x688308 float
0x688334 float
0x688300 float
Пишем в них 0.0 для отключения короны.
Далее адреса с байтовым значением влияют на свет от некоторых пикапов.
По умолчанию значения в адресах 1. Для отключения света пишем в них 0.
0x43F21F BYTE - отключает свет у пикапа сохранения.
0x43F14F BYTE - отключает свет у пикапа взятки.
0x43F1C1 BYTE - отключает свет у пикапа недоступной недвижимости.
0x43F1DF BYTE - отключает свет у пикапа wMIDBigdollar (пикап вырученных с недвижимости денег?).
0x43f243 BYTE - отключает свет у пикапа одежды.
Эти адреса вроде как тоже отключают свет (но толком не понял где именно) :
0x43f1ac BYTE. ?
0x43F17A BYTE. ?
0x43F11C BYTE. ?
https://sun9-13.userapi.com/impf/wF6081-x17ArfRiNJtBQULTTbfOF2jtu7JQkOA/nmdA8NL0Qz4.jpg?size=1280x1024&quality=96&sign=79e977ad43945502551d7c91f0326d73&type=album
https://sun9-20.userapi.com/impf/RYV5x2lHZG7RgvuWcVGTLciw2fs_fmpP7uJFgw/v7E_uOrX9ag.jpg?size=1280x1024&quality=96&sign=9cea2049f7c8a42af5bd5f699ff544cd&type=album

6
Общие вопросы / Re: GTA Re:Liberty City Stories ошибка
« : Декабрь 25, 2020, 02:31:53 pm »
Всегда было интересно каким образом DEP может влиять на работоспособность игр.

7
Тут человек один интересуется (DMITRY_R) некоторыми вопросами касательно San Andreas, но не может зарегистрироваться на форуме.
Попросил за меня создать тему.
"
Доброго времени суток.

Первая задача такова, нужно увеличить дистанцию рендринга короны созданной опкодом  04D5.
Я уверен что существует какой-то адрес памяти хранящий значение дальности.

И вторая, есть адрес памяти 0xBA6797 который отвечает за громкость звуков в игре, со значениями от 0 до 64, но соль в том что он меняет значение громкости звука только в меню, а по факту в игре звук не меняется.
"

8
Скриптинг / Re: Описание структуры объекта
« : Август 16, 2020, 11:06:36 pm »
Shagg_E, спасибо. Попытался сделать динамическую дверь в вайсе: https://youtu.be/lr-4obAvf6w

выглядит круто, что за мод?
Криминальная Россия

9
Скриптинг / Re: Описание структуры объекта
« : Август 15, 2020, 09:58:49 pm »
Ограничители - либо добавлять сферы в коллизию, чтобы от статики отталкивалось; либо условиями ограничить максимальный угол раствора двери. Вообще данная затея с дверьми через скрипт не очень то удачно получается, у меня он работает только с ближайшей к игроку дверью поскольку все идет через опкод 05F1: random_object_near_point. Сам понимаешь, что скрипт не успевает отрабатывать тот случай, когда у тебя грубо говоря помещение 20х5 метров с дюжиной дверей вдоль стены: https://sun9-36.userapi.com/c856132/v856132057/22d627/5OoKWj63uVQ.jpg
На каких-то скрипт успел отработать, а какие-то двери просто провалились при контакте с игроком. Для таких дел лучше писать плагин.

10
Скриптинг / Re: Описание структуры объекта
« : Август 15, 2020, 07:58:12 pm »
Shagg_E, спасибо. Попытался сделать динамическую дверь в вайсе: https://youtu.be/lr-4obAvf6w

11
Скриптинг / Описание структуры объекта
« : Август 13, 2020, 01:07:56 am »
Кто-нибудь знает полное описание структуры объекта, которую можно получить опкодом
05E8=2,%2d% = object %1h% struct ?
Единственное знаю, что по смещению 0x5C находится номер модели, то бишь ID -  в структуре занимает 2 байта.

12
Давненько хотелось видеть в игре другую траекторию движения солнца - в частности захотелось в вайсовской криминалке реализовать траекторию движения солнца как в GTA SA .
Поковырявшись в памяти удалось её немного "изменить" - солнце восходит теперь не на севере а на юге (почти как в СА).
https://www.youtube.com/watch?v=64ig3PsuJ7s
Вылез "косяк" с освещением - свет от солнца по-прежнему идет,так скажем, с севера.
Но потом посмотрев повнимательнее функцию CCoronas::DoSunAndMoon, понял что движение спрайта солнца никак не зависит от движения направленного источника света. Так вот у меня вопрос - есть ли у directional light какая-то траектория ? Где её искать ? Хотелось бы исправить этот "косяк" с освещением.

13
Если имеется ввиду контур вокруг альфы, то его можно уменьшить увеличением размера и качества самой текстуры, но убрать совсем не получится. На хороших деревьях его почти не заметно.


У тебя похоже контур слишком толстый из-за низкого разрешения текстуры кустов

Иногда спасает прогон альфа канала через пеинт путем сохранения как "монохромный рисунок". Альфа читается гораздо лучше, но при этом теряются ч\б оттенки.

14
А вот в col-моделях лимит ~2200 трианглов.

Не совсем. Хоть 3000, хоть 3500 полей - главное чтоб вес кола не превышал 64 КБ.

15
Скриптинг / Re: Прицепить звук к объекту.
« : Август 05, 2018, 05:10:46 pm »
Попробовал прицепить звуки к тепловозу.
Вот что вышло:
https://www.youtube.com/watch?v=0WTh7ragHQg
Звук идет с какими-то перерывами, это хреново.
Без unload_wav звук циклиться не хочет.

:RAILWAV
03CF: load_wav 'MOB_02B' as 1
03CF: load_wav 'MOB_02A' as 2
03CF: load_wav 'MOB_01A' as 3
03CF: load_wav 'MOB_01B' as 4
03CF: load_wav 'MOB_01C' as 5

:RAIL2
wait 0
if and
03D0:   wav 1 loaded
03D0:   wav 2 loaded
03D0:   wav 3 loaded
03D0:   wav 4 loaded
03D0:   wav 5 loaded
jf @RAILWAV

0400: create_coordinate $wavX $wavY $wavZ from_object $OBJECT_TEPLOVOZ offset 0.0 0.0 0.0
03D7: set_wav 1 location $wavX $wavY $wavZ
03D7: set_wav 2 location $wavX $wavY $wavZ
03D7: set_wav 3 location $wavX $wavY $wavZ
03D7: set_wav 4 location $wavX $wavY $wavZ
03D7: set_wav 5 location $wavX $wavY $wavZ

03D1: play_wav 1
03D1: play_wav 2
03D1: play_wav 3
03D1: play_wav 4
03D1: play_wav 5

if
03D2:   wav 1 ended
jf @RAIL2
040D: unload_wav 1

if
03D2:   wav 2 ended
jf @RAIL2
040D: unload_wav 2

if
03D2:   wav 3 ended
jf @RAIL2
040D: unload_wav 3

if
03D2:   wav 4 ended
jf @RAIL2
040D: unload_wav 4


if
03D2:   wav 5 ended
jf @RAIL2
040D: unload_wav 5



jump @RAIL2

Страницы: [1] 2