Difference between revisions of "LVZ Format"

Latest revision as of 16:14, 24 February 2007

This is a quick description of the current .lvz file format. Only Continuum .37 and higher support LVZs. If you design a program to read or write LVZ files, please safely handle the differences of the Types for each section, since newer continuum version will add newer sections.

The first 8 bytes of every .lvz file:

After this, if the count is greater than 0, there should be a compressed header:

Once you have the decompressed data, you can take action on it, or store it for later use. The compressed header with the compressed data at the end will repeat till the number of headers equals the count (if the .lvz is made correctly), or till the end of the file.

The decompressed data can be 1 of two types for the current .lvz format. The first type is more often found in .lvzs, and this is the file type. Files are determined by having a File Time not equal to 0, and having a File Name length not being 0. Please be warned, future formats of .lvz's may change one or the other of these checks, so a good safety feature would be that files require both of these to be true. Files are normally just saved to the proper folder and the correct file time set to it. If you do not know how to set file times, its is not 100% important for most DeBuildLevel like programs.

The only other current decompressed data type is the Object section. The object section is determined by having a File Time equal to 0 and the File Name length being 0.

Object section can now have two different types, though only the Screen Objects are changed

CLV1 is for Continuum .37+, CLV2 is Continuum .38+.

Object Section always starts with this 12 byte header:

For both of CLV1's Screen/Map object, or CLV2's Map object

After the Object Section header, you would loop through the Object Count reading 10 bytes at a time till you hit the Object Count. Each of these 10 byte sections are the Object definitions:

CLV2's Screen Object

After finish looping through the Object Count, you now would loop through for the Image Count. The Image Definition are not predetermined lengths though. Image Definition:

And thats it. That is all that a .lvz can be. If you wish to test your program for creating a .lvz, I have created a DeBuildLevel program that follows these guidelines above to be pretty strict to how continuum will load from it. It will also stop at the first sign of trouble, and print a debug message for you to be able to use.

Layer Values:
0 = BelowAll
1 = AfterBackground
2 = AfterTiles
3 = AfterWeapons
4 = AfterShips
5 = AfterGauges
6 = AfterChat
7 = TopMost

Display Mode Values:
0 = ShowAlways
1 = EnterZone
2 = EnterArena
3 = Kill
4 = Death
5 = ServerControlled

Types for X/Y's (CLV2 ScreenObjects Only):
 0 = Normal (no letters in front)
 1 = C - Screen center
 2 = B - Bottom right corner
 3 = S - Stats box, lower right corner
 4 = G - Top right corner of specials
 5 = F - Bottom right corner of specials
 6 = E - Below energy bar & spec data
 7 = T - Top left corner of chat
 8 = R - Top left corner of radar
 9 = O - Top left corner of radar's text (clock/location)
10 = W - Top left corner of weapons
11 = V - Bottom left corner of weapons

Document approved for release by the developer of the current .lvz format, PriitK.

Extra information about bit ordering

All the data is in confusing little-endian byte ordering. Here's a layout of the data within each byte:

MapObject:
0: [low 7 bits id] [1 bit mapobject]
1: [high 8 bits id]
2: [low 8 bits x]
3: [high 8 bits x]
4: [low 8 bits y]
5: [high 8 bits y]
6: [8 bits image num]
7: [8 bits layer]
8: [low 8 bits display time]
9: [4 bits mode] [high 4 bits display time]

ScreenObject:
0: [low 7 bits id] [1 bit mapobject]
1: [high 8 bits id]
2: [low 4 bits x_coord] [4 bits x_type]
3: [high 8 bits x_coord]
4: [low 4 bits x_coord] [ 4 bits x_type]
5: [high 8 bits y_coord]
6: [8 bits image num]
7: [8 bits layer]
8: [low 8 bits display time]
9: [4 bits mode] [high 4 bits display time]

ImageObject:
0: [low 8 bits x-count]
1: [high 8 bits x-count]
2: [low 8 bits y-count]
3: [high 8 bits y-count]
4: [low 8 bits displayTime]
5: [high 8 bits displayTime]
6+: [Null-ended string filepath]

Also note that although ini's store the display time in 1/100th seconds for map and screenobjects... they are stored in the file as 1/10th seconds. This is not true for imageobjects.