items.sav - 75% Reversed Engineered
Posted: Sun Sep 28, 2008 7:15 am
Hello,
First to answer a few questions that I found answers to in reverse engineering the file format of, and moddifying, the items.sav file, I will describe what I've observed items.sav to do for Hidden and Dangerous 2.
Description:
The file, items.sav, is used by Hidden and Dangerous 2 to work out which models have what ItemIDs, how much they weigh, which gun uses which ammunition, and what unifom has what headwear. It should also be noted that it looks to also includes the data to say that a model of an radio can in airstrikes and another record entry describes the same model, but this one has the abillity to call in artillery.
Put another way, the items.sav file litterly descibes the models and model aliases (other records that use the same model but have a different ItemID, like the Airstrike Radio and the Artillery Radio) to Hidden and Dangerous 2. It stores each description in what I call an Record, because I'm from the old BASIC and PASCAL period, when Object Orientated was defined by Databases and Data files with Records.
items.sav is also the file responsable for those hackers (one including myself, see below for my UGF disclaimer) who run arround with headwear like the Black Beret, but those who run arround with weapons when cheats are disabled and the maplist.txt file hasn't been edited, I would say thats probably hacking done though a WinSock or DirectPlay hacking program, thus being out of the scope of items.sav.
And I think the crashing errors caused by using the knitted cap and civilian clothes is caused by missing or mis-typed data in the items.sav file by the original development team (no disrespect meant), I might look into this.
items.sav File Format Description with Notes:
These notes and structures assumes that all arrays have
a base of zero not one, therefore, an array that has a
bound of 19 really has 20 elements, eg. char a[19];
sizeof(a) = 20
Summarized Description:
No file header.
Records are read straight from the start
of the file.
The number of bytes per record varies by
the two types defined in each record's
header, if the SizeType = 1 then the
record is 508 bytes long (including
header), if the SizeType = 0 and
RecordType DOES NOT equal 0 then the
record is 512 bytes long, and if the
SizeType = 0 and RecordType = 0 then
the record is 516 bytes long, see below
for the currently revealed format of
the record data.
Record Header Structure:
DWORD dwRecordSizeType; /* 0 = Long Record, 1 = Short Record */
DWORD dwRecordType;
Short Record Structure (note: sizeof(RECORD_HEADER) + (SHORT_RECORD) = 508):
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
Long Record Structure (note: sizeof(RECORD_HEADER) + (LONG_RECORD) = 512):
DWORD dwFlag;
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
Long Ammunition Record Structure (note: sizeof(RECORD_HEADER) + (LONG_AMMO_RECORD) = 516):
DWORD dwFlag[1];
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
This data translated to Visual Basic 4.0/5.0/6.0:
Type RECORD_HEADER
dwRecordSizeType As Long
dwRecordType As Long
End Type
Type SHORT_RECORD
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
Type LS3D_LONG_RECORD
dwFlag As Long
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
Type LS3D_LONG_AMMO_RECORD
dwFlag1 As Long
dwFlag2 As Long
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
United Gamers Federation Hacking Disclaimer:
It should be noted that hacking to gain an gaming advantage goes against the core beliefs of the gaming society of which I created and belong to, but this was not hacking to gain an gaming advantage, it was reverse engineering in which required experimental hacking, and the reason for this reverse engineering was to help the H&D2 modders, the few that are out there.
Also having a Black Beret instead of an Red one, is almost like swapping skins in IL-2 Sturmovik, and provides no real gain, except that of the vanity of the user which in my case was me.
First to answer a few questions that I found answers to in reverse engineering the file format of, and moddifying, the items.sav file, I will describe what I've observed items.sav to do for Hidden and Dangerous 2.
Description:
The file, items.sav, is used by Hidden and Dangerous 2 to work out which models have what ItemIDs, how much they weigh, which gun uses which ammunition, and what unifom has what headwear. It should also be noted that it looks to also includes the data to say that a model of an radio can in airstrikes and another record entry describes the same model, but this one has the abillity to call in artillery.
Put another way, the items.sav file litterly descibes the models and model aliases (other records that use the same model but have a different ItemID, like the Airstrike Radio and the Artillery Radio) to Hidden and Dangerous 2. It stores each description in what I call an Record, because I'm from the old BASIC and PASCAL period, when Object Orientated was defined by Databases and Data files with Records.
items.sav is also the file responsable for those hackers (one including myself, see below for my UGF disclaimer) who run arround with headwear like the Black Beret, but those who run arround with weapons when cheats are disabled and the maplist.txt file hasn't been edited, I would say thats probably hacking done though a WinSock or DirectPlay hacking program, thus being out of the scope of items.sav.
And I think the crashing errors caused by using the knitted cap and civilian clothes is caused by missing or mis-typed data in the items.sav file by the original development team (no disrespect meant), I might look into this.
items.sav File Format Description with Notes:
These notes and structures assumes that all arrays have
a base of zero not one, therefore, an array that has a
bound of 19 really has 20 elements, eg. char a[19];
sizeof(a) = 20
Summarized Description:
No file header.
Records are read straight from the start
of the file.
The number of bytes per record varies by
the two types defined in each record's
header, if the SizeType = 1 then the
record is 508 bytes long (including
header), if the SizeType = 0 and
RecordType DOES NOT equal 0 then the
record is 512 bytes long, and if the
SizeType = 0 and RecordType = 0 then
the record is 516 bytes long, see below
for the currently revealed format of
the record data.
Record Header Structure:
DWORD dwRecordSizeType; /* 0 = Long Record, 1 = Short Record */
DWORD dwRecordType;
Short Record Structure (note: sizeof(RECORD_HEADER) + (SHORT_RECORD) = 508):
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
Long Record Structure (note: sizeof(RECORD_HEADER) + (LONG_RECORD) = 512):
DWORD dwFlag;
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
Long Ammunition Record Structure (note: sizeof(RECORD_HEADER) + (LONG_AMMO_RECORD) = 516):
DWORD dwFlag[1];
char strName[19];
char strImage[19];
char strModel[19];
char strUnknown[19];
char strExpressedName[19];
DWORD dwItemID;
char bUnknownData[103];
char strShortName[7];
char bRecordData[283];
This data translated to Visual Basic 4.0/5.0/6.0:
Type RECORD_HEADER
dwRecordSizeType As Long
dwRecordType As Long
End Type
Type SHORT_RECORD
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
Type LS3D_LONG_RECORD
dwFlag As Long
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
Type LS3D_LONG_AMMO_RECORD
dwFlag1 As Long
dwFlag2 As Long
strName As String * 20
strImage As String * 20
strModel As String * 20
strUnknown As String * 20
strExpressedName As String * 20
dwItemID As Long
bHeaderData(103) As Byte ' 104 - 1 = 103
strShortName As String * 8
bRecordData(283) As Byte ' 284 - 1 = 283
End Type
United Gamers Federation Hacking Disclaimer:
It should be noted that hacking to gain an gaming advantage goes against the core beliefs of the gaming society of which I created and belong to, but this was not hacking to gain an gaming advantage, it was reverse engineering in which required experimental hacking, and the reason for this reverse engineering was to help the H&D2 modders, the few that are out there.
Also having a Black Beret instead of an Red one, is almost like swapping skins in IL-2 Sturmovik, and provides no real gain, except that of the vanity of the user which in my case was me.