# Hex Data With Incorrect Offsets?

This topic is 3620 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey there. I really was hoping to get this resolved without having to make a post on gamedev but this is really stumping me. I'm looking through Call of Duty 4's .d3dbsp format in a hex editor to figure out how to extract lightmap data for an experiment I have in mind but something doesn't add up (or does it?) The very beginning of the file is arranged the following way: string[4] bsp type int bsp version int # of bsp lumps (a block of data) direntry[# of lumps] Direntry contains two 4 byte ints. It looks like: 49 42 53 50 16 00 00 00 22 00 00 00 which tells me that it's an IBSP file, version 22 with 34 blocks of data (lumps) This is then followed by 34 pairs of 4 byte ints that declare offset and length of each lump. Here's where I'm confused. The offset of the very first lump is at 00 00 01 1C but the list of offsets/lengths doesn't have that offset listed at all. In fact, the int that should be the 1st lump's offset is 00 00 00 00. The next int after that, the length of the 1st lump, matches exactly though. The file is read in little-endian. I'm wondering if anybody else would be able to make sense of this? Do the offsets ignore the beginning of the file and start at some other point perhaps?
(49 42 53 50 16 00 00 00 22 00 00 00)
[00 00 00 00 88 02 00 00] Lump 1
[01 00 00 00 00 00 30 00] Lump 2
[2C 00 00 00 7A 00 00 00] Lump 3
[2D 00 00 00 30 03 00 00] Lump 4
[02 00 00 00 90 A2 00 00] Lump 5
[03 00 00 00 60 12 00 00] Lump 6
[04 00 00 00 60 15 00 00] Lump 7
[05 00 00 00 78 20 00 00] Lump 8
[06 00 00 00 0F 04 00 00] Lump 9
[07 00 00 00 4F 08 00 00] Lump 10
[08 00 00 00 78 01 00 00] Lump 11
[09 00 00 00 20 01 00 00] Lump 12
[0A 00 00 00 18 1B 00 00] Lump 13
[0B 00 00 00 50 01 00 00] Lump 14
[18 00 00 00 0C 00 00 00] Lump 15
[19 00 00 00 70 00 00 00] Lump 16
[1B 00 00 00 94 08 00 00] Lump 17
[1C 00 00 00 E8 05 00 00] Lump 18
[1D 00 00 00 D4 02 00 00] Lump 19
[1F 00 00 00 18 06 00 00] Lump 20
[20 00 00 00 70 05 00 00] Lump 21
[21 00 00 00 58 00 00 00] Lump 22
[22 00 00 00 B0 05 00 00] Lump 23
[23 00 00 00 6C 00 00 00] Lump 24
[24 00 00 00 C0 01 00 00] Lump 25
[25 00 00 00 30 00 00 00] Lump 26
[27 00 00 00 DD 08 00 00] Lump 27
[2B 00 00 00 00 01 00 00] Lump 28
[34 00 00 00 02 00 00 00] Lump 29
[2F 00 00 00 20 01 00 00] Lump 30
[30 00 00 00 18 1B 00 00] Lump 31
[31 00 00 00 50 01 00 00] Lump 32
[33 00 00 00 0C 00 00 00] Lump 33
[29 00 00 00 10 01 08 00] Lump 34


I used parentheses to mark the very first part that doesn't matter and brackets to mark offset/length pairs. Thanks for the help :)

##### Share on other sites
This seems like it would get better attention over in General Programming, so I'll move it there.

My quick Googling of the subject seems to indicate that other people share your confusion over the offsets, since the length values can be used to compute the offsets indirectly. I have no idea why this would be done in such a way, but there you go [smile]

##### Share on other sites
heh thanks. I wasn't sure where to put this.

I found that using the lengths was a better way to find the lumps I want. No idea what's up with the offsets but it seems to start after the header of the file instead of at the very beginning.

##### Share on other sites
Well, after some research, it turns out that the offsets in this version of the bsp file are wrong.

I guess the compiler mangles the offsets and the game just figures out the real offsets during runtime by taking each data block's length and going from there.

1. 1
2. 2
3. 3
Rutin
23
4. 4
5. 5
khawk
14

• 9
• 11
• 11
• 23
• 10
• ### Forum Statistics

• Total Topics
633653
• Total Posts
3013153
×