CHVIEW Binary Data definition - ljramones/trips GitHub Wiki
the following is derived from the CHV binary file format specification at http://members.nova.org/~sol/chview/chvb.htm
This document notes differences between the theoretical format and actual data from CHV data sets we have copies of.
As the internal format of ChView is object based, the data file is comprised of serialised objects. Each fundamental data type has its own representation on disk.
- Integers: are saved as 2 byte bitfields small value first
- Booleans are stored as integers... 0 or 1 and so require two bytes.
- Longs: are saved as 4 byte bitfields small value first
- Strings: are saved a a 1 byte length determinator followed by that many bytes of data. There are some issues tho.
- Sometimes, a string with have a length expressed as TWO characters. Generall, since most strings are less than 254 characters, you can just test for 00 in the byte after the length, and if it's 00 then assume the actual string itself proceeds on from there.
- Sometimes however, the string length is in fact stored in just one byte, so if the following byte ISN'T 00, you just move to the next byte to get the start of the string.
- BUT if the string is longer than 254 characters then the length byte contains FF with the two bytes following containing the actual length, then the string starts.
- Unless it's Tuesday. :-)
- Floats: are unusual. They are stored as string representations.
- This is done because most of the floating point numbers Jo wanted to store are nice small numbers, frequently integers even if they're floats. Jo believed it was more efficient to store them as strings than 8-byte floating point values. Of course, he could have stored them as 4 byte, 32 bit floats. Between the length byte and three or four characters of value, Jo saved about 4 bytes per float net. But you have to remember that CHVIEW was written back with a 10 meg hard disk was big and many people used dual-floppy systems.
- Colorref: this is a Windows RGB value. It is promoted to a long and saved as that. 4 bytes Why he didn't just save it as three bytes (RGB) I'll never know.
- LogFont: a binary representation of the Windows structure.
public class LOGFONT
{
public int lfHeight = 0;
public int lfWidth = 0;
public int lfEscapement = 0;
public int lfOrientation = 0;
public int lfWeight = 0;
public byte lfItalic = 0;
public byte lfUnderline = 0;
public byte lfStrikeOut = 0;
public byte lfCharSet = 0;
public byte lfOutPrecision = 0;
public byte lfClipPrecision = 0;
public byte lfQuality = 0;
public byte lfPitchAndFamily = 0;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst=32)]
public string lfFaceName = string.Empty;
}
So, a logfont field is 18 characters of blah-blah-blah followed by a string of the font name which is terminated by a 00 byte. Then, that whole thing is padded out with meaningless drivel to 32 characters if the name didn't go that far. When you see "double" in the table below, that's the way OUR database needs to store the info, in an 8 byte float, but floats, as described above are stored as ascii strings. Just remember that.
File Structure:
Preamble:
This area stores overall information for the data file.
| Field | Type | Description |
|---|---|---|
| version number | long | This is supposed to be the CHV version and should always be #00000101 stored as 01 01 00 00 |
| Grid | int | Display grid or not boolean 1 or 0 so 01 00 or 00 00 |
| GridSize | double | Granularity of grid BUT floats are stored as strings, so it's one-byte for the string length, then the ascii characters of the grid granularity Example: 01 35 for 5 LY |
| Link | int | Display Links or not Boolean saved as a two byte int so 00 01 00 or 00 00 |
| LinkNumbers | int | Display Link Numbers or not -- another boolean int 01 00 or 00 00 |
| LinkSize1 | double | Size of each link gradation. Ascii float. Number of char, ascii value, example 02 31 30 is "10" |
| LinkSize2 | double | Size of each link gradation |
| LinkSize3 | double | Size of each link gradation |
| LinkSize4 | double | Size of each link gradation |
| StarName | int | Display Star Names or not boolean |
| Radius | double | View Radius |
| Scale | int | Display Scope or not Boolean 1 or 0 |
| GridStyle | int | Style of grid lines solid, dashed, etc. predefined so 0, 1, 2 |
| LinkStyle1 | int | Style of link lines for route 1 should be 0, 1, 2 3 |
| LinkStyle2 | int | Style of link lines for route 2 |
| LinkStyle3 | int | Style of link lines for route 3 |
| StemStyle | int | Style of stems should be 0, 1, 2, 3 |
| StarOutline | int | Display star outline or not Boolean 1 or 0 |
| RouteDisp | int | Display routes or not Boolean 1 or 0 |
| Dummy x 8 | long | Reserved 8 "long" fields, should probably be NUL for now for all bytes. |
| OColour | Colorref | Colour of spectral type O stars, 4 bytes |
| BColour | Colorref | |
| AColour | Colorref | |
| FColour | Colorref | |
| GColour | Colorref | |
| KColour | Colorref | |
| MColour | Colorref | |
| XColour | Colorref | |
| BackColour | Colorref | Colour of background |
| TextColour | Colorref | Colour of text |
| LinkNumColour | Colorref | Colour of link numbers |
| LinkColour x 3 | Colorref | Colour of link gradations |
| GridColour | Colorref | Colour of grid |
| StemColour | Colorref | Colour of stems |
| ORad | int | Radius of spectral class O stars. We probably ought to think of this as "pixels" but perhaps not. The values are largish |
| BRad | int | |
| ARad | int | |
| FRad | int | |
| GRad | int | |
| KRad | int | |
| MRad | int | |
| XRad | int | |
| DwarfRad | int | |
| GiantRad | int | |
| SuperGiantRad | int | |
| CentreOrds x 3 | double | Galactic coordinates of centre of the display X,Y,Z |
| theta | double | Rotational position |
| phi | double | |
| rho | double | |
| tscale | double | Angular scales |
| pscale | double | |
| rscale | double | |
| xscale | double | Display scales |
| yscale | double | |
| GroupLabel x 4 | string | Names of groups default was |
| DisplayGroup x 4 | int | Display each group or not |
| RouteLabel \ | string | Name of Route label |
| RouteColour x 4 | colorref | Colour of Route == Four sets of Label, Color, Style NOT 4 labels, 4 colors, 4 styles. |
| RouteStyle / | int | Style of Route lines |
| LinkF | logfont | Link Number font |
| NameF | logfont | StarName font |
| UNameF | logfont | Unused font |
| ???? | long | 4 bytes for something. Who knows what? |
| NumStars | long | 4 bytes, number of stars in the file. |
Star Data:
Many star objects follow, one after another. Each object consists of the following:
| Field | Type | Description |
|---|---|---|
| cjcName | string | Proper Name of Place |
| starName | string | Official name of star |
| dToEarth | double | Distance to earth |
| Spectra | string | Spectra |
| Mass | double | Collapsed mass |
| ActualMass | double | Uncollapsed mass |
| ords[0] | double | Galactic coordinates |
| ords[1] | double | |
| ords[2] | double | |
| Constellation | string | Constellation |
| Comment | string | Comment-- Notes |
| Selected | int | Selected or not |
| index | int | Index in file |
| Group | int | Group of star, Colony, Station, Military, Explored. If a box is checked that bit in the int is turned on, so Colony = 1, station = 2, Military = 4, Explored = 8. If multiples are checked, just add the values. When we import into TRIPS, we leave those fields alone and instead we will use the value to populate the Polity field. Colony checked = Arat Kur Station checked = Hkh’Rkh Military checked = Ktor Explored checked = one of Terran, Slaasriithi, Dornaani |
There is a single byte indicating if there is a subsidiary star orbiting this one. If so this entire data structure repeats (recursively).
Lastly we record the links. First is a integer value indicating the number of following links. Each link is then represented by a integer containing the type of link and a string containing the starName of the destination.
Postamble:
This contains only a string giving general comments on the entire file.