Wrp File Format - OPRWv17 to 24 – Talk

For the TextureIndices block I found out that it is organized in 8x4 blocks. If the block starts with 0x00 you just read in 32 short values describing the block. Otherwise you mostly see 2 identical short values describing one 8x4 block filled just with this value. Sometimes instead of the 0x00 value or the 2 identical short values, other values occur probably describing what sort of data follows and what position the next 8x4 block in the whole texX x texZ block has. But I am still not sure what order these 8x4 blocks follow. The TextureIndices block also seems to start with some "header" data which I couldnt identify so far. --T_D 12:11, 13 October 2008 (CEST)

The unknown int in the the TextureGridRoads block is the checksum of the packed data before so it does not belong to the TextureGridRoads block --T_D 14:54, 17 October 2008 (CEST)

Agreed, yeah... saw that, also, maxObjectID isn't part of the TextureGridRoads structure and it will probably end up really being NoOfObjects.

No it is not NoOfObjects. Already checked that by reading objects from 8WVR and comparing readed objects with this value --T_D 04:33, 18 October 2008 (CEST)

Experience has taught me that one can never be to certain about these things until one is certain, if you know what I mean... :)

It maybe MaxObjectId it maybe not... time will tell.

Building the standard SampleMap.pew into a 8wvr.wrp yeilds 5134 obejcts, then into a oprw18.wrp yeilds 5132 in the MaxOjectId/NoOfObjects field. If you add 1 to this value this is the number of obejcts that happens to be in the array of objects in this particular file.

However, this senario doesn't hold true for a certain 'ca' mod oprw18.wrp. That value (as I mentioned earlier) is 637,876 and the number of actual objects in the list array is 602,481.

This may be because there is a prior structure in the file that denotes out of the 637,876 objects ones that are not specified in the Objects array... dunno, well see if that pans out.

The most logical senario is that this is the NoOfObjects less some other structure count = ObejctList count.

If this isn't the senario then there maybe another ObjectCount item lying around the file somewhere that does indicate how many objects are in the objects list array.

this block ushort[gridZ][gridX] unknown //packed seems to consist of random numbers. So my guess is, that these random values are used to calculate the positions of the clutter models, so that the island is always looking the same without saving the pos of every grass model. Could this be the case? --T_D 13:50, 19 October 2008 (CEST)

structTextureGridMaterials MaterialIndices

I have kept the names below as simply indices and blocks, rather than MaterialIndicesBlockFlags and blah

I also refer to A and B rather than X and Y, since i don't know what the really do.

The Indices block extend from the end of the peaks structure, to beginning of the compressed data block. There's nothing else 'there'

The Indices block is partitioned into chunks via the first two entries in the structure.

peaks {....};

Blocks Struct {

byte   nFlags;  // generally always 1
ushort ChunksFlags[nFlags]; //0x3333 eg

The ChunksFlag is a 16 bit bitmask (lsb first) a bit=1 == block present a bit=0 == no block present In the latter case (bit=0) the area where the chunk should be is filled with 8 zeroes (two ulongs)

16 chunks can therefore be defined per ChunkFlag. (I have only ever seen a single chunkflag) and a maximum of 8 chunks

Every chunk structure appears thus;

Chunk1
{
 ABPacket[1];
}
.......
ChunkN
{
 ABPacket[1];
}

An ABpacket is defined thus:

ABPacket
{
  ushort      flagbits;
  Array[16];   Mixtures of 16 ABpairs and/or more ABPackets
}

The atomic unit of each indices block is a ushort pair A,B

ABPair
{
 ushort AB[2];
}

A and B are mostly the same value. They are index values into god-knows what, but are regressively linear (9,9,9,9,8,8,8,8,7,7,7,7 etc)

flagbits declare how many ABpairs and how many EMBEDDED ABpackets are in *this* array. A mixture of up to 16 items exist for each ABpacket.

Embedded ABPackets can (and often do) contain further, embedded ABpackets.

Each 'chunk' has only a single ABpacket struct to start it off. Everything else in the block, is embedded to that 1st struct.

flagbits are read right to left (lsb 1st)

bit = 0 means the next item is an ABpair bit = 1 means next item is the start of an EMBEDDED ABpacket

Flagbit Examples:

0x0000: standard. 16 ABpairs follow
0xFFFF: 16 Embedded ABpackets follow
0xC000: There are 14 ABpairs immediately following this flag, followed by two embedded ABpackets (which in turn will contain more ABPair/Packets)
0x1000: 12 ABpairs followed by One ABpacket followed by 3 AB pairs

/* the last example is important to understand, when decoding as the 'stream' looks initially complex (it isn't, a simple recursive function can handle this.

To keep it simple, assuming the single (embedded) packet contains a flag of all zeros (meaning 16 ab-pairs follow)

0x1000: means  12 pairs 0x0000 19 pairs 

the last trailing 3 pairs are NOT associated with the embedded packet, they 'follow on' from the initial packet.

I mention the above because in a hex dump, there appears to be no rhyme or reason why some pair strings are one's and two;s, others, quite a lot <grin>

• /

Each chunk is 'wholesome'. The above decoding does NOT produce truncated chunk. The end of decoding, is, the start of the next 'chunk'. (which might be the no-chunk zero fill above)

Mikero (nee Ook?)

I think that after the byte Indicator already an ABPacket block follows. It makes sense at least. Your description works so far and I am able to go through this datastructure but we still need to find out how to interprete the data to create TextureIndices[texZ][texX] array --T_D 20:03, 5 December 2008 (CET)

The answer to that is no (it looked very much like a leading ABpacket flag but isn't). It is a chunks flag, declaring how many chunks are in the block. I used Plank's haggis island (32 x 32) to discover the difference. Mikero (nee Ook?)

structMaterials

i think the reason for the 1st null entry eg 'one less' than stated is for faster indexing

an material index with a value of zero means, no rvmat, don't go looking.

any other value in the 'cell' (for want of a better term) means the 'cell' has an rvmat.

This is a small point, but, I also suspect that structMaterials is indeed a concatenated string type. I suspect, that BI can add additional rvmats to the same 'object' if they choose to do so. It's very typical of them to use this string type in class:inheritance type stuctures eg.