I thought I understood how to decode the models.lst file. I just discovered I made a mistake. Here is what I know. The type of a clip is encoded in the number after the final underscore "_" and before the dot. It seems to follow a simple rule. The last 2 digits are a sequence number to distinguish between cards that would otherwise have the same number. The third digit from the right is the hotness. The remaining digits are a decimal representation of a binary number where each binary digit is a yes/no description. From low to high these are:

bit 0 = on bar
bit 1 = behind bar
bit 2 = pole
bit 3 = used but meaning unknown
bit 4 = sign (rarely seen)
bit 5 = accessories
bit 6 = from side (or in-out)
bit 7 = always 0
bit 8 = always 0
bit 9 = cage
bit 10 = on top
bit 11 = dry start (transition control)
bit 12 = dead end (transition control)
bit 13 = magic start (transition control)
bit 14 = magic end (transition control)
bit 15 = nude start (transition control?)

Now I thought the same information was in the models.lst file. There is a block of binary data in the file for each clip. The block begins with the card's file name and continues with 28 additional bytes. These are arranged in groups of 4 and in all but one case each group is a long unsigned integer. The fourth group of 4 seems to be a set of bit flags. I thought the low order 16 flags matched the encoding in the file name. I was close, but not always. The low 7 bits (0-6) match. Bit 7 usually correlates with whether the card is a demo. Bit 8 correlates with whether the card has "SC" in its name. Bits 9 & 10 correlate as do 13-15. The headache came with bits 11 and 12. It seems they are true when they should be false and vice versa.

Can anyone confirm my guesses?

I just figured out the inversion of bits 11 and 12. They are inverted in the clip's file name, not the models.lst. This was done so that all legacy clips would be recognized as dry start & dead end.

Now, if I can only figure out what bit 3 means.

I'm also trying to understand the it codes. So far, I think

it01 = I'm waiting or come-on already
it10 = Standing to table
it11 = spin to clothed
it12 = Table to standing

Maybe this helps..
A while back I wrote an Excel file that decodes the Clip number ( you type it in the box) it displays the bits..
or on the bottom half you click the bits on and off, it generates the code.

@Wyldanimal

Thanks. What does "Full Legs" mean? It looks like I've got the other OK.

@Dorsai6,
All your definitions listed for the bits are correct except for bits 3, 11 and 12. I also know some better definitions that qualify the conditions better. For example, my definition for bit 15 is "Nude at start: Girl is 'fully nude' at start of clip (excluding all clips not linkable or magic at start)".

Bit 3 actually means "Full video shows below the taskbar (legs are not cut off)". Since all clips that are produced now show the entire view of a girls legs, this bit is always on (set). But the older cards cut off a girls legs on all "over the taskbar" clips. Therefore, Totem automatically sets bit 3 whenever bit 0 is set (over the taskbar clips).

Bit 11 means "Not a dry start" and bit 12 means "Not a dead end". They had to do the negative of these because all older cards were dry start and dead end which had the bits set to zero by default. IMO, a better definition for bit 11 and 12 would have been to say they are "linkable to the start of another interactive clip" and "linkable to the end of another interactive clip" respectively.

Clips in Small mode are positioned over a Hot Spot. This spot is remembered, and it becomes the starting Spot for the Next Small clip in that position.
The Hot Spot Could Be Linked to the Top of an Open Window, it it will move around with that window.
When you Quit iStripper, and then Re-start it, These Saved Hot Spots are Reloaded, and re-used.

They are Generated using a formula that Calculates the Available Width, and places it in the Middle of the Width.
This then Divides the Space in half, and the Next Spot is calculated based on the Now Half Width..
Until there isn't enough Space for a new clip.

If you Want to Have New Spots, then Delete the file called entrances.dat in the Data folder.

If a remembered hot spot was attached to a window that no Longer is open, it is forgotten and a new one takes it's place.

itNN clips
it01 - Hang around Hot Spot ( or Center of Screen if clip is starter at center screen )
Might Walk around, but returns to Hot Spot.
it04 - Fall to a Standing position
it05 - the Hanging clip - as when you ***** an interactive clip
it06 - Exit to the Right side
it07 - Exit to the left side
it10 - Stand to Sit transition
it11 - Part of Magic
it12 - Sit to Stand Transition
it13 - Fall to Sitting position

The Magic Spin is to Get Dressed or to get naked.

Except for it11
there are .demo ( clothed ) and .vghd naked versions of each itNN type.
Sometimes there are more than One of the it01, it06 and it07 types.
these would be other variations. One Might just stand around, one might Tap her wrist like she's waiting...

the attached picture shows a sample of 6 active hot spots on my screen.

this Picture shows the models in action. Notice the models might move from the hot spot, but the spot stays in place.
The next clip will start where the hot spot is.
***** a clip and dropping it at a new location will cause the Hot spot to Move to that new location.

I'm using my own Software that I wrote called VirtuaStage to create invisible stages for the models to stand on.
here you can see the Stages, and the Hotspots positioned on them, and then how it looks when only the models are performing.

Seems models.lst have changed version (280 -> 281) and the nee format is not beckward compatible.
Anywhere to get the new format?

8 bytes were removed from the main section before the date
and a 4 bytes add Just before the clip loop.

it's not too significant

a HEX viewer with a compare function is a valuable tool.

Same collection.
copy the Models.lst file from the old version
then copy the Models.lst file from the new version
use the Hex utility to show the difference...

I use HHD Hex editor Nero
https://www.hhdsoftware.com/hex-editor

there are free ones, but I bought that one, and it has served me well for many years.

Thx.
Seems like it stops my private rating system from functioning - and THAT is definately significant!
😉 😎
And the problem with comparing is that new versions overwrite old ones. I believe there is a new file just about every day (every new card).
Guess I could (should) progam a backup of the file, once it is read sucessfully.

Project staticProperties.xml has been abandoned?

Was thinking... why is it called models.lst, when it actually contains data for all the cards - models data are scattered throughout the cards xml-files
😲
Was looking forward to a simpified representation in staticProperties - but the xml file has not been updated since february.
Simplified, in the sense that each show has a desciption, and each model has a description - kind of where evolution is going - rather than the description for the model is repeated for every card she is performing on, and these are stored (only once) seperately or with the data they belong to, rather than spread out over numerous files.
Seems it would be both more informative, possibly save some space as well.

Just my 2 cents... 😊

staticProperties.xml was generated by mistake with the client software ver 1.2.216
If I need a 'fresh' version of that file I simply install the .216 software, which generates an aktual .xml, then I go back to the current software version. Done.😇

OK.
Thx for explanation.

Seems a lot of work to do to have updated data on a daily basis ...

Does the staticProperties.cds file contain the same (but updated) info in binary format?

Your welcome.
Don't know exactly, but I think so. Maybe @Wyldanimal knows the format of the .cds

@Birger52 It would make sense. Version 1.2.216 most probably just extracts a .xml from the .cds data. All .cds files are kept updated.

staticProperties.xml

that file is not the standard file used by istripper
iStripper uses an encrypted version of staticProperties.xml called staticProperties.cds

to Get an updated staticProperties.xml, you have to manually download it yourself.
i'm pretty sure I've sent you a PM with the details, go look back at your PM's

Names of the models and the cards are stored in the Names.xml file
But the Order of the data in that file is Based on your own My Collection Sort order.
So for to build a complete collection Data you need to parse the names.xml and pair that with parsing the models.lst file.


Models.lst is the repository of the Rebuild Collection Inventory.
it is a database of every clip that is in your Models Folder.

The App keeps this data in Memory, and only Updates Models.lst when you Quit the App.

why is it not more user friendly?

The app was not designed with the intent of having 3rd party programs access it's information.

Back in 2008
I watched card after card and discovered that each card, made a change to the registry.
so I wrote a little app the watched the registry.
I watched card after card, and made notes of the file name and what was in the card.
I decoded the file name scheme.
from that I was able to determine what each clip name described.
I also discovered I could push a clip name in the correct syntax on to the registry
and the App would then play that as the next clip.

I wanted a CLIP player.
There was no way to select a specific clip and play it back in 2008.
I wrote to both Rex and Herve to get permission to write one.
I sent them a sample of my work.
and they gave me the OK to do it.

Many times an update would come out, that broke the Registry Push.
using the registry push, was a way to interface with the App that wasn't Hacking.
Countless time I wrote to the Developer asking to have the function restored.
We had many conversations, as to what could be done, and what couldn't be done.
That developer moved on, and I've had similar dialog with the current developer.

We are now at the point where, these are the Two Shared Files that 3rd party apps can use.
models.lst, names.xml. and the Registry Push.

I've asked to have the Screen save function restored, but it's not a priority.
I don't know if it will.
It used to be, you could push a value to the registry, and it would trigger the screen saver to start.

I used that almost exclusively with my player to watch playlists.

that function no longer exists.
I wish it did. as I prefer to watch using Scenes rather than desktop mode.

Updates cause changes, we have to adapt to them, and when needed, ask to have a function restored.
but as of now, the three things have been provided to us..
models.lst
names.xml
registry Push

as long as we have these three things, we can continue to create our own 3rd party apps.

Maybe @Wyldanimal knows the format of the .cds

I have never tried to decode the .cds format.
So no, I don't have that information.

Also, most of the .cds files, have an XML file which contains the same data.
So there is not a need to decode them.

@Wyldanimal is right the .cds are almost the same as their .xml version.
I don't think we should use them even for personnal purpose since it would be agaisnt the TOC.

If you want informations about cards on your collection rely on model.lst.
If you need individual information about models/card you have to rely on the .xml for each card (time consuming).

The alternative is to get the staticProperties.xml which is easier to use since it contains almost the same data as it's .cds version. It's a general file you can also get the upcoming cards from it.
You don't need to install any specific version of iStripper to get it, it's not a secret but I will not provide a direct link on the forum (you can ask @Wyldanimal or me).

I'm using only staticProperties.xml and model.lst

@Birger52 - the contents of the various files such as models.lst, staticProperties.cds and the many .xml files should be regarded being implementation details (as should such things as registry entries), they are most definitely NOT public interfaces. As such their format, meaning, or even their existence, can vary from release to release for no apparent reason. By all means use them for your own private tools, but do not expect Totem to maintain backward compatibility.

Strictly speaking to decode these files is a ***** of the following clause in the Licence we all agreed to

You agree that you will not, under any circumstances:

...

Copy, reproduce, translate, reverse engineer, decompile, derive source code from, or disassemble, in whole or in part, the Software or the Product, or create derivative works based on the Product

But Totem seem not to mind mild violations of this clause.

I'm simply making a way to view data I have bought, in another way that is not ossible by the original software, pertly to be able to add my own data.
I am actually not "Copy, reproduce, translate, reverse engineer, decompile, derive source code from, or disassemble, in whole or in part, the Software or the Product, or create derivative works based on the Product".

@Birger52 - if you are interpreting an undocumented file then you are reverse engineering. OK, only in a very ***** way but strictly speaking it is an infraction of the licence. More importantly you can have no guarentee that things will not change in a way to make your interpretation obsolete.

"Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance the object."
Not what I'm doing.
And I haven't asked for any guarantee...
😉

"Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance the object."

Completely agree with that. It's only what we do with it that might become an infraction. Otherwise learning by studying how something works might also be an infraction.

Copy, reproduce, translate, reverse engineer, decompile, derive source code from, or disassemble, in whole or in part, the Software or the Product, or create derivative works based on the Product

Yes figuring out the format of a file like models.lst is a form of reverse engineering, but what is the scope of the phrase "the Product."

@TheEmu
The fact you are looking into a file to search some information or just to know to what this correspond is usually called Data mining, and this is normally tolerated by any industrial companies. This is not the same as reverse enginering.

Even if a program is under a license (and generally you pay the rights to use it), if you install it on your own computer you have the rights to look how it works or what it does, simply because this is a question of security. My computer is my proprity like my house (that might not be the rights in all country but in mine it's the case).

By the same token I have a right to look at everything on it. I agree this doesn't give me the rights to decompile/reverse enginering any software but infact you can't be puirsuited even if you do do it.

The reason is simple how would you be able to check if a program isn't a virus or a malicous program of any kind, if you can't see or understand what it does? What do you think antivirus software are doing ?
A simple answer is : data mining, reverse enginering and such things and this is legit.

If you do not do it for a purpose or to cause ***** to a person or a company, there is nothing they can do.

Most of the members who have their own 3rd party App have already asked for Permission from Totem to do so.
None of these 3rd party Apps, have direct control of any of the Native software.
It is all done, via Pushing a value to the registry. nothing is hacked.

Can you open and Read a BOOK?
is that reverse engineering or hacking the Book?

if a file in digital format can be open and read, that is not hacking or reverse engineering it.
Altering it's content, or creating New content based on it is...

As long as your app is not altering the models.lst file
then reading the content of that file without altering it any way
does not constitute a hack.

Totem has provided 3 features without documentation for authorized 3rd party app developer to use.
models.lst
names.xml
and a registry value
Computer\HKEY_CURRENT_USER\Software\Totem\vghd\parameters\ForceAnim



Nothing is altered or hacked, but members did have to figure out how to use them.
None of the 3rd party Apps make changes to Totems software.

Totem has also provide for Scene Creators
Does reading one of the official Scenes and using code from that Scene to create your own scene, constitute Reverse engineering or Hacking?

Totem has also provide for Custom card images, custom Full size images
By storing your custom images in the data folder. is that Altering the Product?

Totem has also Provide for Skin creators
Duplicate an Existing Skin folder
Rename it
Create your own graphics
Create your own Palette.txt

None of that is Hacking or violates the T&C

So while Yes, what you point out is written in the T&C, it is also written in the T&C

unless expressly authorized by Totem Entertainment;

I believe all of the 3rd party app developer have requested, and received authorization.

A member doing so for their own behalf, Not sharing it with anyone else...
probably doesn't need pre-Authorization.
They are not Altering , Distributing or sharing anything.

@Birger52 asking for information for his own personal use
does not ***** the terms of the T&C.

If at some point in time @Birger52 wishes to Share his work, then he Must Ask for and receive Authorization to do so.

@Birger52

"Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance the object."

Not what I'm doing.

That is indeed what you are doing, or rather what you or someone else did when you decoded the format of the file. The object in this case being a data file.

@elfine - no it is not called data mining. Data mining is a different activity altogether and is applied to the process of getting nuggets of information from huge data repositories.

@Wyldanimal

@Birger52 asking for information for his own personal use
does not ***** the terms of the T&C.

Asking for the information violates nothing, but decoding the file for yourself does ***** the terms and conditions which say that you may not do this under any circumstances. This includes personal use.

In both my previous posts on this I have said that strictly speaking this is a ***** of the terms and conditions - and I have also pointed out that Totem, like many other sofware companies, do not seem to mind,

With regard to reading a book, no that does not ***** any terms and conditions because one were imposed (over and above copyright) when you obtained the book.

With regard to user created scenes then again,

strictly speaking

, we were originally violating the terms and conditions when we tried to undersatnd how the .scn files worked but later Totem provided most of the infrmation themselves so it ceased to be a *****.

In practice Totem only care when we create and want to share "add on" products, though they would also care very much if someone did the equivalent of looking at and understanding the .cds files but with the .vghd files themselves and created a private program to play them.

Of course Totem take a sensible view of all this so small infractions are ignored and in practice there is no problem in rverse engineering the ***** files used by the app, but it helps to be aware of what we are doing rather than just pretend we are not doing it.

I've been on the prosecution side of a reverse engineering case.
Don't know outside the US, but
In that case, It was defined as Decompiling of executable code.
Data files were pretty much excluded from that definition.
the Models.lst file is not executable code.
But one could argue that the Animation files are, as they get Played / Executed as video.

A fine line would be, if you Decompiled the Executable Binary file to determine how the data was read from the Models.lst file.

I personally did not do that,
back in 2008
I wrote a hex viewer and determined the Structure, just by observing the grouping of the bytes.