.rec file

From SA-MP Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 15:10, 3 July 2012
Mauzen (Talk | contribs)
(Vehicle data)
← Previous diff
Revision as of 15:10, 3 July 2012
Mauzen (Talk | contribs)
(Vehicle data)
Next diff →
Line 76: Line 76:
{{rec.header|52-55|float|Vehicle health}} {{rec.header|52-55|float|Vehicle health}}
{{rec.header|56|byte|Driver health}} {{rec.header|56|byte|Driver health}}
-{{rec.header|56|byte|Driver armour}}+{{rec.header|57|byte|Driver armour}}
{{rec.header|58|byte|Currently hold weaponID }} {{rec.header|58|byte|Currently hold weaponID }}
{{rec.header|59|byte|Siren state}} {{rec.header|59|byte|Siren state}}

Revision as of 15:10, 3 July 2012

Image:32px-Ambox_warning_orange.png Note: This article is based on the file structure as it is in version 0.3d. It might be different for previous or later releases.


Image:32px-Ambox_warning_orange.png Note: All the data was just collected by one person (User:Mauzen), and might be incorrect in some points. For more accurate and detailed results this needs confirmation by other people.


Contents

.rec files

The .rec files are SA-MP's files for recorded NPC movements and actions. Normally the files are created ingame by recording a player's actions. Then they can be used by NPC scripts to be played back, so the NPC exactly repeats the recorded actions. Only files in the npcmodes/recordings/ directory can be accessed by NPC scripts, while ingame recorded files are stored to the scriptfiles directory.

General structure

The .rec file format consists of a header, followed by a non-separated sequence of data blocks. Every data block completely describes the player state at a specific moment, and so the NPC's actions are stored fluently. The data is stored as bytes in little endian order. Single data values can be 1, 2 or 4 bytes long, and so either are bytes, shorts, integers or floats in IEEE-754 format. Some should be signed and others unsigned, but it depends on how you are using them and isnt important for the structure itself (the listed signed/unsigned are oriented on their common PAWN usage). Also, to work with .rec files, a hex editor is necessary of course.

HEADER[8]DATABLOCK[72]DATABLOCK[72]...

File header

The .rec file header got the same structure for both vehicle and on-foot recordings. It is 8 bytes long, where the first 4 bytes are an integer. As it seems it always has the value 1000, probably as a identifier so SA-MP knows it is a NPC recording. The other 4 bytes are another integer, either "1" for vehicle recordings, or "2" for on-foot recordings, so only the lowest bytes of it are in use, the rest is always 0.


Offset*
type
meaning
0-3
integer
File identifier, always 0xE8030000 / 0d1000
4-7
integer
1 for vehicle recordings, 2 for on-foot recordings

[*] Offset is relative to the file's beginning


Data blocks

On-foot data

The data blocks of on-foot recordings are 72 bytes long, so offset +72 would refer to the beginning of the next data block. It contains about everything a normal player can do, I just didnt figure out if setting his aimvector is possible, maybe it is done via the quaternions.

Offset*
type
meaning
0-3
unsigned integer
time when to apply this blocks attributes [ms]
4-5
signed short
left/right key code (e.g. 0x00FF left, 0xFF00 right)
6-7
signed short
up/down key code
8-9
unsigned short
Additional key code (KEY_HANDBRAKE etc codes)
10-13
float
x position
14-17
float
y position
18-21
float
z position
22-25
float
Quaternion component 1 for facing angles**
26-29
float
Quaternion component 2 for facing angles**
30-33
float
Quaternion component 3 for facing angles**
34-37
float
Quaternion component 4 for facing angles**
38
1 byte
Health
39
1 byte
Armour
40
unsigned byte
ID of the current hold weapon
41
unsigned byte
Currently applied special action, not all are working with NPCs
42-45
float
Current x velocity
46-49
float
Current y velocity
50-53
float
Current z velocity
54-67
-
Unknown, probably just placeholders without use
68-69
unsigned short
Currently applied animation index
70-71
short
Some animation parameters, needs some more investigation

[*] Offset relative to the beginning of the data block.
[**] Im not sure why and how quaternions are used here yet.


Vehicle data

Data blocks for vehicle records are slightly shorter, and just 68 bytes long. I didnt analyize them as much as I analyzed the on-foot data, but already got the most important attributes. All in all the structure is quite similar to the on-foot data.

Offset*
type
meaning
0-3
unsigned integer
time when to apply this blocks attributes [ms]
4-5
short
Yet unknown
6-7
unsigned short
left/right key code
8-9
unsigned short
up/down key code**
10-11
signed short
Additional key code**
12-15
float
Vehicle rotation quaternion component 1
16-19
float
Vehicle rotation quaternion component 2
20-23
float
Vehicle rotation quaternion component 3
24-27
float
Vehicle rotation quaternion component 4
28-31
float
x position
32-35
float
y position
36-39
float
z position
40-43
float
x velocity
44-47
float
y velocity
48-51
float
z velocity
52-55
float
Vehicle health
56
byte
Driver health
57
byte
Driver armour
58
byte
Currently hold weaponID
59
byte
Siren state
60-67
-
Unknown, probably not used

[*] Offset relative to the beginning of the data block.
[**] The keys got a strange behaviour, probably this isnt the right order.

Personal tools