Vambropy v1.07
Configuration and first start:

Start Vambropy and click on "Edit config.ini" button. Or, first edit config.ini. 

VAM_dir=  

Write your full vam path. Example: VAM_dir=c:\games\vam
It will look for AddonPackages and Allpackages directories, and Custom/PluginData/sfishere/autoinstall.txt file. If the file is not found it will create a formatted and empty one.

Optional settings:
Configure var repositiores, external to VaM, to import their info in the database; and to use them as external sources for directly copying vars from.

common_dir=  

Write a subdirectory name, common for all your different external var repositories. Example: common_dir=commondi
Then, you can configure up to 5 simultaneous repos,

Repo1=
Repo2=
Repo3=
Repo4=
Repo5=

Make sure they all have that common_dir in common. Example:  e:\game_data\vam\commondi\repo1;  f:\3dart\vam\commondi
Data scanned from repos will be kept always in the database, showing as "external". 
Each time Vambropy starts, if the paths are not accesable, a dialog will show, but all previously scanned data will be present.
You can clear the repo settings or comment them out with ; or #. When installing from external, packages not found will keep being "external", they will not change their status/color as "installed".

You can unpack clothing or hair packages, When you do, they will be marked as "unpacked" in the database.
Optionally, you can also install a dummy file for them, so VaM does not show a "missing dependency" message for each unpacked var. (VaM always finds and loads the unpacked clothing anyway)

dummyvars=

Set to False/True. When enabled, dummy vars will be created in AddonPackages/dummyvars directory, for each unpacked var.
Unpacked contents from vars is not recommended. Vambropy only allows to unpack Clothing and Hair vars. Dummy vars are created only to prevent VaM from showing messages of missing vars, but the scenes will correctly load all Clothing and Hair from local (because they always use the UID, which is present in all unpacked .vam files)

autoview=

Set to False/True. Default setting for the autoview checkbox, to enable or disable automatically load thumbnail and info when you navigate the packages list with keys <up> and <down>


max_threads=

Set to 5 default, less if your cpu have problems with it or increase for more threads in the parallel processing (experimental)

The rest of settings are somewhat self-explained in the config.ini

More examples for repos:
          
Let's say you have g:\backup\commondi directory and it has the following tree:
g: <root dir>
    backup <dir>
        commondi <dir>:
            looks <dir>
            scripts <dir>
            scenes <dir>
                my.examplescene.1.var

So the name 'commondi' is the key name. The packages copied from 'commondi' to 'AddonPackages' will preserve the path structure starting from 'commondi' as root (not included).
If you copy my.examplescene.1.var scene from the repo, it will be installed as AddonPackages/scenes/my.examplescene.1.var (in VaM directory)

Let's say you prefer to identify var files copied from your repo so they don't mix with the ones installed (maybe if you use same sufdirectories for looks, scenes, etc.):

h: <root dir>
    backup2024 <dir>
        commondi <dir>
            from_repo <dir>:
                looks <dir>
                scripts <dir>
                scenes <dir>
                    my.examplescene.1.var

In this case you will have installed the scene as AddonPackages/from_repo1/scenes/my.examplescene.1.var (in VaM directory)

There are other ways of configure it. You can decide how the tree goes, but you must always use the common directory name in the path of all repos.

Why not use the last directory in the path then? 
Let's say you want set it up to scan this folder f:\games\vamdata\vars\commondi\new_ones because you have another directory old_ones and you don't want those vars.
So the package scan will run only in the new_ones directory but will use the relative path starting from commondi.
When a package installs from it, i.e. f:\games\vam\commondi\new_ones\scripts\my\my.newplugin.1.var, it will be installed to AddonPackages/new_ones/scripts/my/my.newplugin.1.var

So, Repo1, Repo2, Repo3... will need to have that directory in common, configured by the setting 'common_dir='



First start:

If using the source code version, you need to have python 3.11 (or later if compatible) installed. Preferably use miniconda.
( with miniconda: ) Create a new environment for python 3.11. Activate it. Install pillow (pip install pillow)
You can run the app with python and the full or relative path to vambropy.pyw file:
 

Example: 
d:\> python\python.exe c:\sources\vambropy\vambrpopy.pyw
d:\miniconda\envs\311\> python.exe c:\sources\vambropy\vambropy.pyw

For these examples you have to have python.exe path set in your environment (path=%path%; d:\python)
e:\backup\> python c:\sources\vambropy\vambropy.pyw
c:\sources\> python vambropy\vambropy.pyw
c:\sources\vambropy\> python vambropy.pyw


Compiling Vambopy: When compiled, an .exe file is created and it does not depends on installed Python anymore.
It is recommended using a clean python 3.11 installation (or conda environment). 
Only pillow libraries are needed.

1. Install pillow and pyinstaller: 'pip install pyintstaller, pillow'
2. Then go to vambropy directory and make vambropy.exe: pyinstaller  vambropy.spec
3. Then go to Dist directory, there is the newly created vambropy.exe
4. Make sure to have the file config.ini along the vambropy.exe file in the same directory
5. If you already have the database packages.db from version 1.05 you can copy it too, to avoid scanning all vars again. 
6. Same with thumbnails directory, to avoid thumbnails rebuild. Same with lists directory (profiles), if you already have
