I'd like some help or information from anyone familiar with the format of the model.lst file. The following is what I currently understand.

I've finally found the time to rework my Playlist Generator to support the current version of iStripper. In doing this I've reexamined the models.lst file which is a key source of information. The models.lst file is a binary file that describes all the cards in your models folder. This includes both the cards in your collection and the preview cards which are also in that folder.

The file consists of a small header plus a block of data for each card. Each cards data consists of a card header plus a block of data for each clip.

The file header consists of two long integers (2 bytes each). The first is the version number which is currently 281. The second is a count of the number of cards in your models folder.

Each card header consists of 58 bytes in the following order:
9 bytes hold the card number as a C string (4 bytes hold the string length and 5 the actual string)
4 bytes hold the date the card was purchased
2 bytes appear to be unused and are always 0
2 bytes hold 16 flag bits but not all are used, more later
4 bytes appear to be unused and are always 0
4 bytes hold the size of the card's model folder
4 bytes appear to be unused and are always 0
5 bytes appear to be unused and are always 255
4 bytes purport to hold the count of the number of times the card was played, but this data does not appear to be updated reliably
4 bytes contain an integer code describing the resolution of the card
4 bytes contain flag bits indicating the available resolutions of the card
4 bytes contain a yes/no (1 or 0) indicator showing if a new resolution is available
4 bytes appear to be unused and are always 255
4 bytes provide a count of the number of clips

The first of the two flag bytes is used as follows (bit 0 is the 1's bit and 7 is the 128 bit):
0 = I've seen this set occasionally, but I'm not sure what it does
1 = In my collection
2 = Hidden card
3 = always false
4 = always false
5 = Card has been downloaded
6 = Card has been purchased (seems to duplicate 5)
7 = Update available
The second of the two flag bytes is used as follows:
0 = always false
1 = always false
2 = New Banner on card
3 = I can't figure this out. It is set for about 50 cards in my collection.
4 = Card has been downloaded ??
5 = Previews ?? This is a guess. The cards are not in my collection, but I've not been able to cross check against the preview page.
6 = always false
7 = Card Enabled on UI

*** The above flags are my area of greatest concern

continued from previous message

Each clip block is of variable size because the clip names are of variable length
The first group of bytes holds the clip name as a C string, but the characters are in unicode which means two bytes are used for each character.
4 bytes provide a play sequence number when the clip is an sc clip
4 bytes hold an integer describing the clip type if it is a transition clip
4 bytes hold the hotness level as an integer
4 bytes contain bit flags
The first byte is not currently used
In the second byte, only the first (bit 0, 1's position) bit is used. It identifies a glass clip
In the third byte all the bits are used:
0 = is sc clip
1 = cage clip
2 = on top (swing clip)
3 = dry start (for transition clip management)
4 = dead end (for transition clip management)
5 = magic start (for transition clip management)
6 = magic end (for transition clip management)
7 = nude start (for transition clip management)
In the last byte all but on of the bits are used:
0 = on the task bar
1 = behind the task bar
2 = pole
3 = sitting on task bar with full legs shown (not cut off)
4 = with sign (just a few old clips)
5 = with accessory
6 = from side (model enters from the side)