Talk:Wrp File Format - OPRWv17 to 24

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.

Between 0 and 16 Indices blocks can exist. They extend from the end of the peaks structure, to beginning of the compressed data block. There's nothing else 'there'

I have only ever seen 8 blocks, and always, 8 blocks.

peaks {....};

byte  Indicator;  // always 0x01 ? 
ushort IndicesBlocksFlag; //always 0x3333 ??// see at very end for a 'discussion of what i think this is

Block1
{
 ABPacket[1];
};
.......
Block8{.......}

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 progressively linear (1,1,2,2,3,3 etc) and the range is less than 1000

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, embeded ABpackets.

Each 'block' 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>

• /

/////// /////// indices block ///////

Each block is 'wholesome'. The above decoding does NOT produce truncated block. The end of decoding, is, the start of the next 'block'.

The eight blocks are split into AB pairs of blocks (block B immediately follows block A)

Thus

Block1 & 2 8 zeroes 8 zeroes Block3 & 4 8 zeroes 8 zeroes Block5 & 6 8 zeroes 8 zeroes Block7 & 8 8 zeroes 8 zeroes

I am now guessing, but I'm rather confident about the IndicesBlocksFlag

It's value always seems to be 0x3333 ( 0011 0011 0011 0011)

The 8 zero bits (or alternately the 8 one bits) indicate a block present / block absent.

The 'pattern' corresponds to the above pair blocks/ non blocks arrangement.

Mikero (nee Ook?)