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

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


Сообщения - aleks926820

Страницы: [1] 2
1
На основе вышесказанного переписан код разблокировки .wft - секции ищутся строго по офсетам. Снова повторюсь, что на старых версиях 3ds max скрипт не будет работать, скрипт проверялся на 2024 версии 3ds max. Zlib библиотека - в сообщениях выше. dll закинуть в папку scripts.
Просьба пока что не выкладывать этот скрипт на других ресурсах - мне нужно кое-что еще дописать.

2
Здесь я собрал почти всю информацию,что была в сети + собственные раскопки:
0x00 0x52534205 RSC. //заголовок
0x04 0x700000 //тип ресурса 0x70 ModelFrag (.wft) (112)
0x08 FLAG //флаги
0x10 HeaderLength (предположительно)
0x1С центр X,Y,Z
0x28 радиус объекта?
0x2C центр масс Х,Y,Z
0x3C центр масс Х,Y,Z
0x4C unbrokenCGOffset  //X Y Z
0x5C 16b dampingLinearC  //X Y Z
0x6C 16b dampingLinearV  //X Y Z
0x7C 16b  dampingLinearV2  //X Y Z
0x8C 16b  dampingAngularC  //X Y Z
0x9C 16b  dampingAngularV  //X Y Z
0xAC 16b  dampingAngularV2 //X Y Z
0xBC 4b офсет на имя объекта (например pack:/.blista)
0xC0 4b офсет на структуру Drawable 0xDC326A00.
0xD8 4b офсет на коллекцию указателей фреймов с высоким уровнем детализации (High), указатели повторяются n раз. Местоположение числа n неизвестно. //возможно ошибочное предположение
0xDC 4b офсет на коллекцию указателей фреймов с средним уровнем детализации (Medium), указатели повторяются n раз. Местоположение числа n неизвестно. //возможно ошибочное предположение
0xE0 4b childListOffset //офсет на коллекцию офсетов к структурам Children 0xF43566A00
0x1F0 офсет на общее число фреймов?
0x1FF число офсетов childList
0x22C общее число фреймов?
0x23C офсет на фреймы иерархии, количество фреймов указано в 0x22C
В структуре Drawable как правило находятся офсеты на почти все структуры Model 0x34026B00.
Их может быть как 1, так и 3 офсета. Предположительно размер структуры Drawable 0xF0 (240 байт)
0x00 4b заголовок структуры 0xDC326A00 (VTable)
0x08 4b офсет на структуру ShaderGroupData 0x44166B00 //не всегда, могут быть нули
0x0C 4b SkeletonOffset
0x10 Center X,Y,Z,W
0x20 Bounding Box min X,Y,Z,W
0x30 Bounding Box max X,Y,Z,W
0x40 4b офсет на структуру Model 0x34026B00 //не всегда так, могут быть нули
0x44 4b офсет на структуру Model 0x34026B00 //не всегда так, могут быть нули
0x48 4b офсет на структуру Model 0x34026B00 //не всегда так, могут быть нули
0x4C 4b float 9999.0 //AbsoluteMax
0x50 4b float 9999.0 //AbsoluteMax
0x54 4b float 9999.0 //AbsoluteMax
0x70 радиус?
0x80 неизвестная матрица
0x90 неизвестная матрица
0xA0 неизвестная матрица
0xB0 неизвестная матрица
Остальные офсеты на Model нужно находить через Children, в которых лежат офсеты на структуру Drawable.
0xE0 4b childListOffset //офсет на коллекцию офсетов к структурам Children 0xF43566A00
0x1FF 1 байт число офсетов childList

ChildListOffset - офсеты к Children 0xF43566A00
размер: 4*число офсетов, указанное по адресу 0x1FF

Структура Children 0xF43566A00
0x0 0xF43566A00 VTable Children
0x90 офсет на вышеописанную структуру Drawable
Смещение к ZModeler2LockID 0x486F803F: размер SystemMemorySegment - 0x100
Размер SystemMemorySegment рассчитывается так: bit.shift (bit.and flags 2047)  ((bit.and (bit.shift flags -11) 15)+8)
Паззл наконец-то сложился.
Ниже информация про .wdr  а также про секции, что есть и в .wdr и в .wft. Информация взята с gtamods.com.
WDR Header (BlockSize 0x2A0)
-------------------------------------------------------------------
Offset Size Type Data Description
-------------------------------------------------------------------
0x00 4b LONG VTable         (Usually 0x00695254)
0x04 4b Offset HeaderLength (Usually 0x90)
0x08 4b Offset ShaderGroup (0 = no Shaders)
0x0C 4b Offset SkeletonData (0 = no Skeleton)
0x10 4b FLOAT Center x
0x14 4b FLOAT Center y
0x18 4b FLOAT Center z
0x1C 4b FLOAT Center w
0x20 4b FLOAT BoundsMin x
0x24 4b FLOAT BoundsMin y
0x28 4b FLOAT BoundsMin z
0x2C 4b FLOAT BoundsMin w
0x30 4b FLOAT BoundsMax x
0x34 4b FLOAT BoundsMax y
0x38 4b FLOAT BoundsMax z
0x3C 4b FLOAT BoundsMax w
0x40 4b Offset Pointer ModelCollection (0=Non existing)
0x44 4b Offset Pointer LOD models (0=Non existing)
0x48 4b Offset Pointer LOD models (0=Non existing)
0x4C 4b Offset Pointer LOD models (0=Non existing)
0x50 4b FLOAT Max Vectorx (Usually 9999.0)
0x54 4b FLOAT Max Vectory (Usually 9999.0)
0x58 4b FLOAT Max Vectorz (Usually 9999.0)
0x5C 4b FLOAT Max Vectorw (Usually 9999.0)
0x60 4b LONG ObjectCount
0x64 4b LONG Unknown (Usually 0xFFFFFFFF)
0x68 4b LONG Unknown (Usually 0xFFFFFFFF)
0x6C 4b LONG Unknown (Usually 0xFFFFFFFF)
0x70 4b FLOAT Unknown
0x74 12b LONG Unknown (Usually all zeros)
0x80 4b Offset 2DFX Array offset (Zero if no 2dfx section)
0x84 2b Short 2DFX Count
0x86 2b Short 2DFX Size
0x88 8b LONG Unassigned data (0xCDCDCDCDCDCDCDCD)
0x90 4b LONG End of Header (Usually 0x00000000)
Model Collection
ModelCollection (BlockSize 0x08)
--------------------------------------------------------------------
0x00 4b Offset Pointer to Model Pointer
0x04 2b Short Number of Pointers
0x06 2b Short Number of Pointers
0x08 4b LONG Padding                 (0xCDCDCDCD)
0x0C 4b LONG Padding                 (0xCDCDCDCD)
Model
Model (BlockSize 0x20)
--------------------------------------------------------------------
0x00 4b LONG VTable         (0x34026B00)
0x04 8b Offset  PointerCollection<Geometrys>
0x0C 4b Offset SimpleArray<Vector4>    (Unknown Vectors)
0x10 4b Offset SimpleArray<Integer>    (Material Mappings)
0x14 2b Short Unknown1                (Usually 0)
0x16 2b Short Unknown2
0x18 2b Short Unknown3
0x1A 2b Short GeometryCount
0x1C 4b LONG Padding                 (0xCDCDCDCD)
Geometry
Geometry (BlockSize 0x50)
--------------------------------------------------------------------
0x00 4b LONG VTable         (0xF4486B00)
0x04 4b LONG Unknown 1 (Usually 0)
0x08 4b LONG Unknown 2 (Usually 0)
0x0C 4b Offset VertexBuffer
0x10 4b LONG Unknown 3 (Usually 0)
0x14 4b LONG Unknown 4 (Usually 0)
0x18 4b LONG Unknown 5 (Usually 0)
0x1C 4b Offset IndexBuffer
0x20 4b LONG Unknown 6 (Usually 0)
0x24 4b LONG Unknown 7 (Usually 0)
0x28 4b LONG Unknown 8 (Usually 0)
0x2C 4b LONG IndexCount
0x30 4b LONG FaceCount
0x34 2b Short VertexCount
0x36 2b Short PrimitiveType
0x38 4b LONG Unknown 9 (Usually 0)
0x3C 2b Short VertexStride (36 without normal map, 52 with normal map)
0x3E 2b Short Unknown 10 (Usually 0)
0x40 4b LONG Unknown 11 (Usually 0)
0x44 4b LONG Unknown 12 (Usually 0)
0x48 4b LONG Unknown 13 (Usually 0)
0x4C 4b LONG Padding                 (0xCDCDCDCD)
VertexBuffer
VertexBuffer (BlockSize 0x64)
--------------------------------------------------------------------
0x00 4b LONG VTable         (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
IndexBuffer (BlockSize 0x40)
--------------------------------------------------------------------
0x00 4b LONG VTable         (0x70B86B00)
0x04 4b LONG IndexCount
0x08 4b Offset DataOffset to IndexData
0x0C 4b LONG Unknown 1 (Usually 0)
0x10 32b LONG    Padding                 (0xCD)
ShaderGroupData
ShaderGroupData (offset remarked in Header at 0x08) (BlockSize 0x50)
--------------------------------------------------------------------
0x00 4b LONG VTable         (0x44166B00)
0x04 4b Offset TextureDictionary       (0 = no Embedded textures)
0x08 4b Offset Pointer to a Pointer for ShaderFX PointerCollection
0x0C    2b      Short Number of Pointers at Pointer for ShaderFX PointerCollection
0x0E    2b      Short Number of Pointers at Pointer for ShaderFX PointerCollection 
0x10 48b Zeros
0x40 4b Offset  Pointer to SimpleCollection VertexDeclarationUsageFlags
0x44    2b      Short   Number of SimpleCollection VertexDeclarationUsageFlag entries
0x46    2b      Short   Number of SimpleCollection VertexDeclarationUsageFlag entries
0x48 4b Offset  Pointer to SimpleCollection UnknownInts
0x4C    2b      Short   Number of SimpleCollection UnknownInt entries
0x4E    2b      Short   Number of SimpleCollection UnknownInt entries
ShaderFX
ShaderFX (offset remarked in ShaderGroupData in the Pointer to ShaderFX PointerCollection 0x08) (BlockSize 0x50)
-----------------------------------------------------------------------------------------------------
0x00 4b LONG VTable         (0x3C226B00)
0x04 4b LONG BlockMapAdress
0x08 2b Short Unknown 1
0x0A 1b Byte Unknown 2
0x0B 1b Byte Unknown 3
0x0C 2b Short Unknown 4
0x0E 2b Short Unknown 4_1
0x10 4b LONG Unknown 5
0x14 4b Offset ShaderParamsOffsetsOffset
0x18 4b LONG Unknown 6
0x1C 4b LONG ShaderParamCount
0x20 4b LONG Unknown 8
0x24 4b Offset ShaderParamTypesOffset
0x28 4b Hash Unknown Hash
0x2C 4b LONG Unknown 9
0x30 4b LONG Unknown 10
0x34 4b Offset ShaderParamNameOffset
0x38 4b LONG Unknown 11
0x3C 4b LONG Unknown 12
0x40 4b LONG Unknown 13
0x44 4b Offset ShaderName Pointer (Pointer to null terminated String)
0x48 4b Offset ShaderSPS Pointer (Pointer to null terminated String)
0x4C 4b LONG Unknown 14
0x50 4b LONG Unknown 15
0x54 4b LONG Unknown 16
0x58 4b LONG Unknown 17
0x5C 4b      LONG Padding                 (0xCDCDCDCD)
PointerCollection
PointerCollection (BlockSize 0x08)
Contains pointers to the data of the given type
--------------------------------------------------------------------
0x00 4b Offset Offset to the Pointers
0x04 2b Short Number of Pointers
0x06 2b Short
SimpleCollection
SimpleCollection (BlockSize 0x08)
Contains data of the given type
--------------------------------------------------------------------
0x00 4b Offset Offset to the Data
0x04 2b Short Data Count
0x06 2b Short Data Size
GRAPHICS section (Size found from the flags @ 0x08 of RSC file header)
VertexData
VertexData (BlockSize VertexCount*0x24 or 0x34 when the Geometry is using a normal map)
---------------------------------------------------------------------------------------
0x00 4b FLOAT Position x
0x04 4b FLOAT Position y
0x08 4b FLOAT Position z
0x0C 4b FLOAT Normal x
0x10 4b FLOAT Normal y
0x14 4b FLOAT Normal z
0x18 4b DWORD Color (RGBA)
0x1C 4b FLOAT Texcoord u
0x20 4b FLOAT Texcoord v
0x24 4b FLOAT Tangent/Bi-Normal x   // Only when there is a normal map applied to the Geometry
0x28 4b FLOAT Tangent/Bi-Normal y   // Only when there is a normal map applied to the Geometry
0x2C 4b FLOAT Tangent/Bi-Normal z   // Only when there is a normal map applied to the Geometry
0x30 4b FLOAT Tangent/Bi-Normal w   // Only when there is a normal map applied to the Geometry
IndexData
IndexData (BlockSize IndexCount*0x06)
---------------------------------------------------------------------------------
0x00 2b Short Vertex A
0x02 2b Short Vertex B
0x04 2b Short Vertex C
SkeletonData
SkeletonData (BlockSize 64 bytes)
-------------------------------------------------------------------
0x00 4b Offset Pointer to a Pointer for Model Name        
0x04 4b Offset Pointer to a Pointer for VertexData
0x08 4b Offset Pointer to unknown 64b data block (not always used, 0 if not used)
0x0C 4b Offset Pointer to unknown 64b data block (not always used, 0 if not used)
0x10 4b Offset Pointer to unknown 64b data block (not always used, 0 if not used)
0x14 4b Long Geometry Count ?
0x18 4b Long (Usually 0)
0x1C 4b Long Unknown Integer
0x20 4b Long (Usually 0)
0x24 4b Long (Usually 0)
0x28 4b Long Geometry Count ?
0x2C 4b Long Uint32 (Usually 2305907972)
0x30 4b Long (Usually 0)
0x34 4b Long (0x6B2778) VTable ? 
0x38 4b Long (Usually 0)
0x3C 4b Long (Usually 0)
Texture Definition
Texture definition (for externally defined textures)(BlockSize 0x1C)
--------------------------------------------------------------------
0x00 4b LONG VTable         (0x5C676B)
0x04 4b LONG Unknown1
0x08 4b LONG Unknown2
0x0C 4b LONG Unknown3
0x10 4b LONG Unknown4
0x14 4b Offset Offset Pointer to Texture name
0x18 4b LONG Unknown5
0x1C 4b LONG Padding                 (0xCDCDCDCD)
В заключение информация про .WDD - а-ля контейнер для .WDR.
WDD Header
-------------------------------------------------------------------
Offset Size Type Data Description
-------------------------------------------------------------------
0x00 4b LONG VTable 0xA4536900
0x04 4b Offset BlockMapAdress Marks end of Header
0x08 4b LONG ParentDictionary (Usually 0)
0x0C 4b LONG UsageCount (Usually 1)
0x10 8b SimpleCollection<Hashes> Contains hashes of the models
0x18 8b PointerCollection<WDR> Contains Pointers to WDR files
0x1C 4b LONG Unknown
0x20 12b 0xCD Padding till 0x0F
--------------------------------------------------------------------
PointerCollection (BlockSize 0x08)
Contains pointers to the data of the given type
--------------------------------------------------------------------
0x00 4b Offset Offset to the Pointers
0x04 2b Short Number of Pointers
0x06 2b Short
--------------------------------------------------------------------
SimpleCollection (BlockSize 0x08)
Contains data of the given type
--------------------------------------------------------------------
0x00 4b Offset Offset to the Data
0x04 2b Short Data Count
0x06 2b Short Data Size

3
Продолжу тему. Недавно получилось подружить MaxScript с библиотекой zlib через великий и могучий DotNet. Таким образом наладил процесс разблокировки минуя распаковку и запаковку через RSC Manager. Заодно прикрутил разблокировку .wdr файлов - снимает ZModeler2 lock. Здесь в плане .wdr сделано по нормальному, переход к секции Model и далее к секции Geometry делается через офсеты, а не просто поиском заголовка секции Model. Структура .wdr уже давно описана на некоторых сайтах, а вот в плане .wft про структуру мало что известно, в .wft также есть секции Model Geometry ShaderGroupData VertexBuffer IndexBuffer (и еще какие-то, уж не припомню), но поскольку нет описанной структуры, то и не понятно где находятся офсеты к этим секциям, сам пытаюсь найти все эти смещения; проблема в том, что в оригинальных .wft моделях (на примере одной из модели авто) офсеты к секции Model лежат рядом, офсеты к ним нашлись практически сразу, а если рассматривать модель, экспортированную из ZModeler2, то там офсеты на секцию Model раскиданы в разных местах, например их 5, мне удалось найти всего 3, а путь к оставшимся двум секциям пока что отследить не смог. Пока что алгоритм разблокировки .wft реализован некорректно, ищется секция Model по заголовку (который опытные модмейкеры могут попросту занулить), далее из этой секции происходит переход в секцию Geometry и далее из нее в секции VertexBuffer и IndexBuffer, далее из этих двух секций Index Count и Vertex Count прописываются в секции Geometry, сносится ZModelerLock и таким образом модель становится пригодной для импорта в ZModeler.
Скрипт и библиотеку zlib прикладываю, сразу скажу, что писал и тестировал на 2024 3dsMax, на старых 3dsMax не заработает, у меня на 2010м не работает почему-то, создается пустой файл.
ZLib.net.dll положить в папку *директория 3dsMax*/Scripts/, дальше можно запустить скрипт и работать.
Работа со скриптом еще не закончена.

4
Собственно говоря для чего это все ковырял:
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.
P.S.S.S. 05/01/2025 - удалил старый скрипт во вложении

5
Ответ найден.
К полученному значению смещения нужно применить операцию логического И с маской 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, который уже несколько месяцев недоступен.

6
На днях появилось желание поковырять четверочные файлы моделей (.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, представляющие собой элементы карты\интерьера, все в порядке. Данная ерунда наблюдается только моделями авто.

7
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.

8
Не знаю может уже кто это знает, но на всякий случай скину сюда.
Нашел способ отключения короны и света практически у всех пикапов.
Прошерстил функцию 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

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

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

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

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

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

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

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

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

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

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

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