Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

Últimos mensajes - Página 1675

  Foro

Dorsai6
Desde en Apr 2013
3459 posts

Decoding iStripper files

Todo sobre iStripper
June 15, 2016, 12 respuestas
I finally took the time to figure out the format of the iStripper models.lst and xxx.vpl files.

The .vpl (playlist) files are straight forward. The first 4 bytes (a long integer) is the format ID (=1). The next 4 bytes is the number of entries in the playlist. For each entry this is one text string. The first 4 bytes is the number of bytes in the string. The characters themselves are in unicode requiring 2 bytes per character. Use of unicode in preference to ASCII is an industry trend. Totem made that shift in the models.lst file about a year ago.

The models.lst file has changed a bit, but not all that much. The first 4 bytes is the format ID(=280). The next 4 bytes is the number of cards. Each card consists of some card data followed by one entry for each clip. It seems that only the card header has changed. The model name and card name are gone. Some new data has been added, but I'm don't know what it means. Here is the header in order:

Card ID: 4 byte length followed by unicode text
Dummy?: 8 bytes that seem to be always hex FF
Date Purchased: 4 bytes. I throw away the2 high bytes and convert the low bytes with a base date of Nov 12, 1926.
Flags : 4 bytes of binary flags. These seem to convert the same a for previous versions, but I'm not certain. In order high to low:

update available
card purchased
in my collection
card is sc type
bit not used
favorite
bit not used
bit not used
card enabled
bit not used
download in progress
full show downloaded
demo downloaded
flag card as new
flag card as deleted
flag card as last days (legacy?)

long integer: always zero
long integer: models folder size
long integer: mostly zero about 10% have values from 2457551-2457554. Meaning unknown.
5 bytes: always hex FF
long integer: number of times played (many not be correct)
long integer: (1-4) resolution of card as currently downloaded
long integer: (1-4) best resolution available for card.
long integer: flag fo new resolution available
long integer: count of number of clips of all kinds including transition

For each clip we have

Clip ID: Long integer length followed by unicode characters
long integer: Sequence number of clip
long integer: Might be flags. I don't know what they mean.
long integer: hotness level
long integer: binary flags describing the card
In order high to low:

not used
use nude start transition
use magic end transition
use magic start transition
dead end (no transition at end)
dry start (no transition at start)
swing clip
cage clip
SC clip
demo clip (mostly)
from side
accessories
sign
not used
pole
behind bar
on bar

long integer: clip size in bytes
long integer: SC number
long integer: clip is enabled flag
long integer: not used


WARNING: NEVER MAKE CHANGES TO THE MODELS.LST WHILE iStripper is running. Reading the models.lst file is safe.
FalconAF
Desde en Jan 2008
530 posts

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Todo sobre iStripper
June 13, 2016, 5087 respuestas
Yes, I started experiencing the same inout parameter things while modifying some scenes I have. I hadn't done any scene creation in quite a while, and I was stumped as to what was happening. So I asked (accidentally in the other thread) if any of the "old" parameters had been changed, removed, modified, etc as to how they work. I'm gonna go test some of my old scenes and see if it actually is the use of "allow: inout" that is my problem now.

Update: It appears the "allow: inout" parameter still works for all cards, but it works DIFFERENTLY now for the 3K (or UHD...whatever they are called) cards now. For the Clipsprite value that determines the left or right position of the model in the scene, a non-3K card will allow the model to enter the scene from the side of your screen and continue moving until she gets to the parameter number position on the screen. But the SAME parameter number for a 3K card model using a clip that is a "screen edge" clip (where she "peeks around the side" of your screen) will position the edge of the clip INSIDE the edge of your screen to begin with. It doesn't line up the edge of the clip with the edge of the screen. Instead, it lines up the edge of the clip where she "peeks around it" to the parameter value that is farther inside from the edge of your screen.

If that is what is happening, the only solution I can think of now is to have separate scenes for the 3K model cards that use these "edge of screen clips". You would have to set the position parameter in the Clipsprite to the edge of your screen value. That may or may not allow a non-3K model "inout" clip to walk far enough from the left or right starting point of HER clip to even make it ON to the screen.

I've been away from scene creating for a while, so if any of that is wrong or I'm missing something, I'll crawl under a rock and hide. ;-)