Tannin42

RAM is not a fast storage system, that fills up and when it's full you have a problem.
RAM is a slow cache, that will try its best to keep as much information from storage (e.g. disk, internet) accessible quickly. Memory Management keeps track of whether the data is present and up-to-date on storage and when it was last accessed so it can drop low-priority data if necessary.
 
As such, having a lot of memory usage is not a problem per se. In an ideal world your RAM would always be 100% utilized, everything less is a waste of resources you paid for.
The more interesting question of "how much RAM does this application require minimum in a pinch" is not answered by the task manager.
 
Vortex leaves memory management to the backend, we allocate memory that we intend to work with and when we stop working with it, the backend is free to return it at its own discretion. But when that actually is will vary a lot on your system and what other software you run. From experience Vortex (like every chrome-based application btw.) will use more memory on systems that have a lot of memory installed.
That makes it really difficult to see whether Vortex is actually using "too much" memory, it may simply be the backend having no reason to return the memory yet because there is plenty left and freeing memory in large chunks can be better for performance.
 
It should also not affect game performance because if a game actually requires the memory, the OS should be taking anything non-essential back from Vortex.
 
This is not a problem unless we have an actual bug where it looks to the backend like memory is still being used by Vortex even if it's not. If that was the case, it would lead to a Vortex crash after a while.
Again, you can't see this in task manager, you can only see it by Vortex crashing or system performance becoming bad as a result.

You can also look at the source code directly: https://github.com/Nexus-Mods/Vortex/tree/master/src/stylesheets though I'll admit it's a bit of a mess.
 
The other thing that can help is this extension: https://www.nexusmods.com/site/mods/12
It allows you to open the chrome inspector. If you don't know it, you can use the "Elements" tab to see how the ui is layed out, what ids&classes are assigned to the controls you're interested in and what existing css is there.
You can also use it to test your own css on the fly.

You are likely using reparse points (aka junction points) to have your d:\program files and c:\program files be the same? AppData\Roaming also seems to have been redirected?
This unfortunately confuses the hell out of node.js to where it doesn't load things correctly.
Since this happens in the framework we're using it's not something we can fix on our end, you'll have to use the custom vortex installer and install it to a location that is not in a reparse point.

You don't have a cycle between groups, you have a cycle between mods, the group assignments are only part of that.
 
It's possible that there is a masterlist rule between two of these mods that can't be fulfilled because of the group assignments.
When you over over the orange arrows (-->) it will tell you why it has to put them in that order.
 
In general it's a really really really bad idea to customize these groups to this degree.
really really bad.
Load Ordering is exclusively there for the engine to avoid plugin conflicts causing crashes or quests to fail and so on.
The moment you (ab)use LO to make the list more maintainable for you as a user, you're basically begging for problems like these because LOOT is solely trying to prevent actual ingame problem and having a "stable" order and having a "pretty" order are opposing goals.

So the problem appears to be that the location Vortex has stored for the Witcher 3 Script Merger is corrupted.
You can reset that without losing any other settings, but you'll have to use the command prompt and be careful you follow the instructions exactly.
 
First, close Vortex if it's running.
Then, open a command prompt and copy these two commands:
cd C:\Program Files\Black Tree Gaming Ltd\Vortex Vortex --del settings.gameMode.discovered.witcher3.toolsAfter a moment you should see a couple of messages looking like this:
removing settings.gameMode.discovered.witcher3.tools.W3ScriptMerger.idNow restart Vortex and you should be good.
 
 
If you want to fully reset Vortex, reinstalling Vortex isn't enough, you'd have to delete the application state which is stored in C:\Users\<username>\AppData\Roaming\Vortex but I'd really only suggest that as a last resort - or if you haven't set up any mods yet anyway

I replied to this in the issue tracker:
This is the intended behavior. Vortex acts as a front-end to LOOT and LOOT explicitly supports and sorts ghosted plugins.
The purpose of ghosting plugins is (exclusively) to hide them from the game.
Hiding plugins from LOOT as well is a separate feature - not saying unreasonable but independent.

As I said: This has been the behavior from the start. Usually you'd get the update notification shortly after you start Vortex, that's where we do the check but it this case, who knows, maybe the server (updates are received from github) was really really slow or you were doing other downloads at the same time?
The notification happens when the update is downloaded, we have no direct control over how long that takes. 1 hr is certainly excessive but again: out of our hands. The only alternative would be to _not_ notify you at all.
But unfortunately if you do shut down your computer, windows will close Vortex, which triggers the update without Vortex even knowing we're doing a shutdown and then Windows at a random time terminates the installer and then you're left with a broken Vortex install.
 
Point is: Yes, Vortex is supposed to update like this. New version comes out, it gets auto installed the next time you close Vortex, with no further user interaction. A lot of software does that or when was the last time you had to manually confirm an update to Firefox or Chrome for example?
Whether you like it or not: practically all software will move to this pattern. No software company wants to deal with reports about bugs in old version of the software that have long since been fixed or complaints about how the software is affected by security issues, even though they offered a fixed version ages ago.
 
Let's be realistic here: As a user (heck, even me as a dev), how are you supposed to make an educated decision whether you should install the update and how urgent it is?
This update included an update to the electron backend we use from 11.4.3 to 11.4.8. Here's the changelog for that: https://www.electronjs.org/releases/stable?version=11
By my count that alone contains 34 security bugfixes. Which - if any - affect you, or Vortex in general?
 
I do get that it sucks to get a sound at a random time but all the alternatives might be so much worse.

Vortex doesn't detect mod conflicts (files overwriting each other) between different mod types, e.g. if you have a mod installed as ENB that contains data\foobar.txt and then another installed as the default mod type containing "foobar.txt", Vortex wouldn't correctly ask you to pick which foobar.txt to keep.
Other than that it shouldn't change anything else.

Pretty sure this is caused by your Anti-Virus quarantining the file during installation. Can you try disabling your AV during the Vortex installation?
Before that, maybe check if the AV logged anything or notified about it quarantining files. If not, might I suggest getting a better AV?

Pretty sure this is caused by your theme.
 
Try this: press ctrl+shift+S to open settings, go to themes, change to the default theme, see if that fixes it.

Ooof.
Nothing broke there, nothing stopped working. Vortex is simply warning that the bsas were built with tools for another game and they are not compatible and often the game will crash with incompatible bsas.
 
Vortex is simply warning you that there may be problems and if there are, what the source is. It's not causing any new issues it's simply making you aware of more to give you more guidance in case of trouble. It's not stopping you from playing.
If you've tested these mods and they work you can just ignore the warning.

Both orders are very similar in concept but they control things on different levels.
The mod deploy order decides which files get put into the game directory if two mods contain the same file ("the same" meaning: "a file with the same name in the same directory but potentially with different content").
The plugin load order decides which change records get put into the game world if two plugins contain the same record.
 
So the plugin order also doesn't matter unless two plugins have a conflict, it's just that Vortex can't see or show those conflicts, we delegate to LOOT to make that decision.
 
The other difference is that with mod conflicts Vortex has full control over which files it puts where. With plugins we can control the load order only indirectly, both LOOT and the game itself have constraints what order they will accept (e.g. we can't make it load regular plugins before masters, no matter how hard we try) but those constraints always have a reason, even if t's not immediately obvious.

Please try my suggestions in this thread: https://forums.nexusmods.com/index.php?/topic/9783043-java-script-error-when-trying-to-download-mods-please-help/

Can't you set up Vortex to run the DCoTEHook.exe directly? I don't think we've ever had a case where we had to modify steam installation files which would be a bit awkward because the moment the game gets updated or files get validated, that change probably gets reverted.
If your worry is that running the DCoETHook.exe directly breaks the steam overlay: Usually with steam games if you export the environment variable "SteamAPPId=123456" (use the actual steam id) the overlay should work. You can either do that from the hook exe or you can set up vortex so it sets it when the exe gets started.
 
If you really absolutely have to change the install.vdf file, Vortex uses a node library called "simple-vdf" to read vdf files. Afaik it's supposed to also support writing vdfs but we're not using that ourselves. So you should be able to import simple-vdf, use it to read the install.vdf into a js object, change the value for the executable, dump the file to disk again => 3 lines of code plus some error handling.
Within your extension the option "setup" function in the registerGame interface would probably be the best place to do that. It gets called on startup for the active game and any time you change the active game in vortex.

No, sorry, that's not possible.
Resuming a download always reuses the same server with the same settings.
 
To get a download at full speed you have to cancel and restart.

Thank you for the state file.
 
To give you a bit of context for what is happening: That state directory contains a database with all the information Vortex stores, both your settings and all the information of what mods you have, their descriptions, internal ids so we can find mod updates and so on.
 
When Vortex starts it loads that database and has to do some transformation on the data before it can use it - that is where it's crashing.
 
The problem is: The crash happens entirely in foreign code, a third-party library which we just use, we don't really know what it does under the hood that leads to this crash.
Also I can't reproduce the crash, even on your database, so it's not fundamentally a problem with your data.
 
One thing you could try (for the purpose of narrowing down the error, I'm not suggesting this as a fix): Could you restart your windows, then start Vortex first thing and see if it then doesn't crash? As in: does having windows run for a while increase the chance/frequency of crashes?
 
Something else you can try right now: Please go to vortex settings->vortex and change "Update" to "Beta". This will update your Vortex to the current beta release which seems to be fairly stable at this point.
This Vortex update also ships which a newer version of the library that is crashing so maybe that fixes it.
If not you will have to wait for the next beta release (1.4.3) which will no longer use a different library for that operation entirely. I can't promise you that that will definitively fix the crash but if it still crashes, maybe the crash dumps will then reveal some new information on what's going on.

That's the first divinity original sin, not DOS2.
I'm afraid we currently don't support DOS1.

Settings -> Workarounds -> Allow Symlinks without elevation

I'll have to investigate but there is a good chance that it's something we can't fix I'm afraid.
Vortex itself doesn't care too much what your application path looks like, I don't see how we could be causing this. If there is a problem here it's probably in the node.js/electron framework we use under the hood. If so, the best I can do is forward it.
For you that means: don't hold your breath, work around it by putting Vortex into a different directory. Sorry for the inconvenience.
 
 
EDIT: disregard, it is our mistake after all, fix will be in 1.4.x. I would still advice against using # in folder names though, the error we made is something others (including vortex extension developers) may also stumble over:
While # is a valid character in windows paths it has special meaning in urls. Thus any application that is designed around dealing with websites but also supports local files (like a webbrowser can open sites locally via file:///c:/foobar/index.html) would have to take extra-precautions to deal with # symbols in the url because file:///c:/#foobar/index.html would be invalid, even though c:\#foobar\index.html is not.

This was solved on Discord.
 
For future reference, the reply that seems to have lead to the solution:
 
The cause for this was probably that Windows got reinstalled recently.
In NTFS, every file is owned by a user account and by default is only writable by its owner.
When you reinstall windows that also creates new user accounts. Even if they are named the same, to Windows they are different, meaning the files and directories are still owned by the old account from the old windows and not by the new one.
 
The solution is to right-click the directory in question, properties -> security and in that dialog you can assign a new owner, as well as giving your account write access (which you can do if your account is administrator)

New update today should fix this, please let us know if it doesn't

1.0.0a is not a valid semantic version that we can make a comparison on
 
In general you want the actual version to be expressed in the three numbers, nothing else.
So after 1.0.0 the next bugfix release is 1.0.1, the next feature release is 1.1.0, the next breaking change is 2.0.0, no letters or other attachments.
 
Semantic versions can have additional information attached, e.g. 1.0.0+foobar, but that is still 1.0.0, so "1.0.0+foobar is neither newer nor older than 1.0.0.
You can also attach a prerelease tag, e.g. "1.0.0-a", but that means "the alpha for 1.0.0" so 1.0.0-a is *older* than 1.0.0.

https://help.nexusmods.com/article/92-im-having-download-issues-what-can-i-do

Vortex does not limit your download speed.
https://help.nexusmods.com/article/92-im-having-download-issues-what-can-i-do

Vortex doesn't have its own location to store plugin state, it synchronizes directly with the plugin.txt used by the game and the loadorder.txt which is a standard across multiple modding tools. These files can be found in C:\Users\<username>\AppData\Local\Skyrim Special Edition
 
If you want to sync settings as well you may also want to sync the ini files in "C:\Users\<username>\Documents\My Games\Skyrim Special Edition" (including the .ini.base and .ini.baked if you use vortex on both systems).
 
 
Now whether this works depends a lot on the sync software you're using, I've never used Beyond Compare to sync directories, but usually these kinds of software, unless they're *really* smart, will copy hard links as the actual files, meaning your approach is not correct.
 
If you intend to manage mods through Vortex only on one system and only want to allow the other system to play with that mod setup but not to edit it, what you're doing is fine but then you shouldn't be synching the Vortex appdata directory, that's just a waste of disk space.
 
However if you intend to use Vortex on both system, you shouldn't be synching the game directory because the modded files in the game directory are only links and synching will probably turn them into actual files, doubling the amount of disk space it uses, plus it will confuse Vortex.
You should just be synching the vortex appdata directory and the vortex staging folder and then after the sync you press "Deploy" inside Vortex on the target system and it will set up the links in the game directory accordingly.