Vortex fails to move mods to external ssd

[kamikatze13]

a) that wouldn't cut it for vortex, would it?

 

you tell me - the database files are not readable with my text editor, so i have no idea what gets saved in there =P

 

thanks for the write-up, btw. security's a fair point, but i still fail to see how you would overwrite a /profiles folder in the root directory if you don't distribute one with your installer. except if you nuke the install location from the orbit before extracting new files?

[Tannin42]

you tell me - the database files are not readable with my text editor, so i have no idea what gets saved in there =P

Why do I need to tell you? You do know that vortex has to store all the files you download, all the mods you install, all the profiles you create and meta data it retrieves

about mods and meta data you edit yourself somewhere, right? You can't possibly assume this could be stored in a configuration file, right?

 

thanks for the write-up, btw. security's a fair point, but i still fail to see how you would overwrite a /profiles folder in the root directory if you don't distribute one with your installer. except if you nuke the install location from the orbit before extracting new files?

you fail to see because you've never tried to write an installer.

An installer can go down three routes:

a) It doesn't try to clean up at all, it just adds files to the directory, overwriting as it goes. This way no old files ever get deleted. With such an installer the install

directory is guaranteed to get bloaded and we'd not be able to remove or rename one of the bundled extensions for example without writing extra code

b) You just remove the entire application directory and install fresh. Simple and reliable.

c) It contains a detailed list of what to clean up, that is: a list of files and/or directories to remove before installing the new version.

Problem here is that this list needs to be kept in sync with the main application so every update of the application would also require a new installer (currently

we only update the payload, not the logic of the installer) and every time it could introduce a new bug to the installer.

Especially bugs that leave files around are hard to identify because most users wouldn't notice at first that there are unnecessary files (how would he know which files are required?).

And the list would have to include all files from any version you could be upgrading from, so the installer (uninstaller) for version

x.y.z needs a list of files/directories that covers every version that came before it, including beta/test versions and even then we could get a problem if someone forks vortex and creates

modified versions (we're open source after all) and then users want to update from a modified version back to the official one.

Plus it's entirely pointless if your application isn't supposed to be portable, because removing the application directory is supposed to have the exact same effect

as removing every file and directory that the application installed since the application directory is frozen and can't be changed (except by system administrators who

know what they're doing).

[kamikatze13]

Why do I need to tell you? You do know that vortex has to store all the files you download, all the mods you install, all the profiles you create and meta data it retrieves

about mods and meta data you edit yourself somewhere, right? You can't possibly assume this could be stored in a configuration file, right?

 

didn't mean to be rude, sorry if it came out this way. i'm genuinely curious what is being stored in the DB, since i have not found a way to access and read it (besides a hex editor lol). I'm just trying to understand why approach it with a DB rather than config files and the file system like the mod managers of old did. and the loot metadata is stored in `userlist.yaml` anyway.

 

you are correct that i have yet to write an installer myself, so thank you for your insights. tbh point c i would never even consider viable but the "glorified self-extracting archive" would be my approach.

 

now, since it looks like VO is not going to officially support standalone deployment, i'll have to work around this myself.

Edited June 6, 2018 by kamikatze13

[Tannin42]

The db is a levelup database, you may be able to find tools to edit it.

Vortex also supports command line parameters (--get, --set, --del) to edit the database directly, they only work when vortex is not running and currently not in "shared mode".

Either way you need to be very careful editing the database, a mistake make the db unreadable.

 

Now as for the why, there are a few reasons

a) a "proper" database is simply faster than a text file

b) not all data can be serialized well to a text file. For example this is how Mod organizer stores a table layout to its ini file:

plugin_list_state="@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\x2\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x1P\0\0\0\x4\x1\x1\0\x1\0\0\0\0\0\0\0\0\x1\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x4\0\0\0\xa1\0\0\0\x1\0\0\0\0\0\0\0\x32\0\0\0\x1\0\0\0\0\0\0\0;\0\0\0\x1\0\0\0\0\0\0\0\x42\0\0\0\x1\0\0\0\0\0\0\x3\xe8)"

Try to edit that without breaking something, I dare you.

c) yaml (or xml, json, ini, ...) is a database format with a strict syntax, it's a mistake to assume it's a text file users should edit manually. A wrong colon or star symbol, bad indentation or quotes in the wrong place can make the entire file unreadable. Editing a yaml file without knowing the syntax is dangerous and if you believe it can't be that hard: A large number of developers who've created yaml libraries didn't actually understand the format fully, many of these libs are broken, so how can I expect regular users to?

 

The Vortex database stores all the settings and persistent data you created with vortex, potentially many hours of work. We were worried that allowing direct manipulation was far too likely to loose you the data. And looking at NMMs not-so-glorious history of broken configuration files that worry isn't exactly unfounded. Another problem for us is that many of these issues are then blamed on us (Why didn't NMM protect me while I was editing the VirtualConfig file manually in a text editor and anyway, why does a completely f***ed up xml file not just work? Can't a computer just guess what I intended to do?)

 

So the solution was to use a db that wouldn't be editable directly but instead provide a cli to edit directly as well as an import/export option (not yet implemented). This way we can validate the file on import and simply reject a broken file on import.

 

Finally: I'm not fully ruling out that we may someday offer a way to do portable Vortex installs, I'm just laying out to you why we're not doing it now, when we have enough other stuff to implement/fix during alpha that we don't need to add another source of grief just yet.

[kamikatze13]

Try to edit that without breaking something, I dare you.

 

i bet i could if i knew what index in the byte array is doing what :tongue:

 

jokes aside, thanks for providing a view from your perspective. glad to see you haven't completely written of portable installs - for the meantime, i ended up symlinking the /appdata/roaming/vortex folder alongside my VO install for easy drag'n'drop capabilities.