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

[XEPOMAHT007]

Deleted

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

[SILENT_Pavel]

То же самое что в читдевайсе - отредактировать или расставить дополнительный генерик. Если прокатит фишка со снижением количества WRLD в архиве, то можно "восстановить" CHK и MDL для карты города, что позволит дополнять игру новыми моделями и текстурами.

И тем не менее, это подобие маппинга интересно будет "портировать" на ps2... А возможно ли будет координаты спавненых объектов внутри псп с чит девайсом вписывать в "блокноты" которую прочитает версия пс2?

Сообщение отредактировал SILENT_Pavel: 18 September 2012 - 05:32

[Dageron]

XEPOMAHT007
Мои структуры с твоими не совпадают, возможно, потому, что я разбирал данные из VCS, а ты из LCS.

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

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

[solom]

понятное дело, что имён файлов в game.dtz не содержится,

Содержатся, только они хешированы.

[Lego]

> Содержатся, только они хешированы.
хешируются имена игровых моделей, текстур и т.д.
имя файла (или его хеш) типа "weapons.dat" там по своей идее не должно содержаться - в этом нет никакого смысла. файл уже отпарсен и, усоловно говоря, преобразован в массив структур.

> [ELF] Weapon name:
а можно поподробнее про ELF или ссылку какую-нибудь?

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

[Sergeanur]

Ну, судя по ELF Weapon names такие:

LCS: (ak47 нету почему-то)

Unarmed
Knife
Hammer
Cleaver
Machete
Katana
Grenade
TearGas
Molotov
Rocket
Colt45
Python
Shotgun
Tec9
Uzi
Mp5
m4
Ruger
M60
Minigun
Camera

BrassKnuckle
ScrewDriver
GolfClub
NightStick
BaseballBat
Chainsaw
DetonateGrenade
Spas12Shotgun
StubbyShotgun
SilencedIngram
SniperRifle
LaserScope
RocketLauncher
FlameThrower
Detonator
HeliCannon

VCS: (ak47 тоже нет)

Unarmed
BrassKnuckle
ScrewDriver
GolfClub
NightStick
Knife
BaseballBat
Hammer
Cleaver
Machete
Katana
Chainsaw
Grenade
DetonateGrenade
LandMine
SeaMine
TearGas
Molotov
Rocket
Colt45
Python
Shotgun
Spas12Shotgun
StubbyShotgun
Tec9
Uzi
SilencedIngram
Mp5
m4
Ruger
SniperRifle
LaserScope
RocketLauncher
FlameThrower
M60
Minigun
Detonator
HeliCannon
Camera
Binoculars

Fire type также имеются:

LCS:

MELEE
CAMERA

INSTANT_HIT
PROJECTILE
AREA_EFFECT

VCS:

MELEE
INSTANT_HIT
PROJECTILE
AREA_EFFECT
CAMERA
BINOCULARS   //похоже, не используется

Сообщение отредактировал Sergeanur: 13 August 2011 - 16:27

[XEPOMAHT007]

Deleted

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

[Lego]

> описание формата вообще не сделано, ну так распиши, чо > приведён список выдуманных dat-файлов список составлял не я, но идея была удобная. ну да чё там - ок, будем называть куски по оффсетам. оружие будет называться "кусок памяти по оффсету 4027696", чтобы не было разногласий.

Сообщение отредактировал Lego: 13 August 2011 - 19:21

[XEPOMAHT007]

Deleted

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

[Lego]

> CWeaponModelInfo э... ты хочешь восстановить оригинальную струтуру XML файлов сторисов? глядя на твою XML-структуру не понятно, это WORD или DWORD или вообще знаковый INT. вообще, сходу по твоей структруе сделать что-то довольно сложно без предварительного описания. в любом случае для начала нужно описать данные в том виде, в котором они хранятся в game.dtz, разве не так?

Сообщение отредактировал Lego: 13 August 2011 - 20:14

[XEPOMAHT007]

Deleted

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

[SILENT_Pavel]

del

Сообщение отредактировал SILENT_Pavel: 18 September 2012 - 05:32

[Lego]

мы по-моему, говорим про разные вещи.
я говорю про простое описание структуры, типа того что кидал Dageron, только не в виде структуры на Си, а что-то типа:

DWORD - 4 bytes - dwType (описание)
WORD  - 2 bytes - iFireType (описание)
...

которое потом можно заюзать где угодно и на базе его создать хоть XML, хоть JPG.

[XEPOMAHT007]

Deleted

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

[Lego]

если честно, не вижу совершенно ничего сложного, что бы могло помешать перевести такое описание в дельфи, кресты, обычный си и т.д. мне, например, интересно взглянуть на чьи-то готовые наработки, но я не знаю многих структур, алгоритмов и особенностей сторисов - я просто этим не занимаюсь. по твоему описанию совершенно нереально что-либо сделать, оно иллюстрирует лишь то, что из ELF ты взял названия оружия, названия классов и считал информацию из DTZ по структуре, скорее всего аналогичной той, о которой я говорю. из этой структуры и имён ты сделал XML и какое-то описание класса, потом привёл два плэйн-текста, которые почему-то обозвал WeaponInfo.xml и WeaponInfo2.xml (по идее обратно преобразованный XML в набор параметров по типу weapon.dat). Откуда взята инфа первого и второго файла неизвестно, но, теоретически, это можно проверить, используя структуру Dageron'a, но.... Это, по-твоему, более понятно чем то, о чём говорю я? :)

Сообщение отредактировал Lego: 14 August 2011 - 01:29

[XEPOMAHT007]

Deleted

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

[Sergeanur]

Кстати, значение на 0xB8 (4 байта) ссылается на particle.cfg.

[Lego]

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

[Dageron]

SILENT_Pavel
Можно сначала посмотреть, например, вот этот классический мод.

XEPOMAHT007

Тем более в статье про dtz (http://gtamodding.ru/wiki/DTZ) описание формата вообще не сделано, вместо этого зачем то приведён список выдуманных dat-файлов, которых в сториесах нету и не может быть. По сути оно является тупиковым, т.к. его авторы не понимают, как загружается и функционирует структура GTAGAME.

Ну так и кто же их туда написал? Сильно удивлюсь, если материал был взят не с ваших ресурсов LCS Team. Смотрим историю правок. И Lego верно дописал - "аналоги следующих файлов"...

Как загружается game.dtz я представляю в достаточной степени хорошо, другое дело, реализовывать все сходным образом на мой взгляд попросту нерационально. Все равно расписывать все структуры в виде C++ templates и делать загрузчик на C++, ориентируясь на то, "как это было у R*", совершенно малополезно. Сверхзадача - отыскать нужные параметры характеристик, понять их назначение, и, если надо, то отредактировать или извлечь в каком-либо виде (любом удобном для конкретной задачи).

Структура Дагерона не совпадает с моей, он это сам написал несколькими постами выше. Точнее, он просто не разобрал её до начала.

Интересно, каким же образом? В твоих "описаниях" есть некое поле "END" (в игре принимающее значение $AAAAAAAA - у меня это dwPadding), после которого почему-то вдруг следуют три вектора подряд, Этого не может быть, там float-ы расположены совсем по-другому, проверь сам по значениям параметров. В приведенном коде на Delphi тоже что-то несуразное, интресно, как же ты читаешь следующие векторы ("ну и так далее"), если вслед за первым идет несколько DWORD-ов?

Вот моя преобразованная структура:

typedef struct vFireOffset{
	float	   f1;
	float	   f2;  
	float	   f3;		
};

typedef struct weapondata{
	DWORD	   dwType; 
	int		 iFireType;
	float	   fRange;
	int		 iFiringRate;
	int		 iReload;
	int		 iAmountOfAmmunition;
	int		 iDamage;
	float	   fSpeed;
	float	   fRadius;
	float	   fLifeSpan;
	float	   fSpread;
	DWORD	   dwPadding;  //padding (0xAA)
	//до этого момента все совпадает, далее - расхождения
	vFireOffset m_vFireOffset;  //вектор   
	DWORD	   _f3C;   //всегда нуль
	DWORD	   _f40;   //целочисленное значение
	DWORD	   _f44;   //DWORD ? unknown
	vFireOffset m_vFireOffset;  //вектор
	vFireOffset m_vFireOffset;  //вектор
	DWORD	   _f60; 
	DWORD	   _f64;
	DWORD	   _f68; //предположительно, слот оружия
	DWORD	   _f6C; //padding (0xAA)	  
};

Последние четыре поля - никак не float, а DWORD.

Очень не удобно пользоваться описаниями программистов - без комментариев тяжело разбираться. Тем более самому такое описание точно не сделать - для этого нужно иметь специальные знания, программу по чтению данных dtz можно написать и без них на формальном языке, который можно потом перевести в delphi. По weapon.xml это можно сделать в любой момент - там всё очень просто.

Это не "описания программистов", это обычные структуры. Вроде все лежит на поверхности, если что-то не понятно, то лучше спрашивай... И раз ты начал говорить про то, "как загружается и функционирует структура", то как раз целесообразнее бы все оформить в видe struct, которые можно удобно использовать как в 010, так и потом, при желании, перетащить в C++ классы (CWeaponModelInfo, верно? из *.elf, да "как у R*").

И, кстати, Lego прав, попробуй лучше в Delphi оформить описание в виде структуры, так ведь гораздо удобнее, не надо читать все по одному параметру, когда можно представить все в виде полей одной record-записи.

[Lego]

только тогда уж не int, а WORD, т.к. int может быть по умолчанию два байта (как, например, в Borland C++) или 4 байта, как в Visual Studio
вообщем-то, соответствие типов такое (WinDef.h), думаю, логично бы его придерживаться:

typedef unsigned long	   DWORD;
typedef int				 BOOL;
typedef unsigned char	   BYTE;
typedef unsigned short	  WORD;
typedef float			   FLOAT;

> так ведь гораздо удобнее,
к тому же так получается быстрее: как я помню с моего институтского опыта, 1000 раз считать 1 байт дольше, чем 1 раз считать 1000 байт.