-
Posts
1911 -
Joined
-
Last visited
Community Answers
-
Tannin42's post in Vortex crash was marked as the answer
Please see this thread: https://forums.nexusmods.com/index.php?/topic/9097253-vortex-crash-loop-on-startup-divide-by-zero-error/
It contains a workaround
-
Tannin42's post in Vortex crash loop on startup - divide by zero error was marked as the answer
I think I know what it is. Is it possible you have a savegame where the filename consists only of numbers?
When you usually save a game in Skyrim Special Edition for example it will have a generated name like this:
Save1_24E584BB_1_436C61697265_Tamriel_000927_20171003164013_11_1.ess
but via the console - or probably through a mod - you could produce save games called something like "1.ess".
With that I can reproduce the issue.
-
Tannin42's post in Vortex download manager is super slow... was marked as the answer
Vortex itself has no influence on the download speed, it downloads as fast as the server will let it.
Which is another way of saying: Your problem is with the server, not with Vortex.
-
Tannin42's post in Gamebryo-Plugin-Management was marked as the answer
Please try installing the visual c runtime (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads - this is an official microsoft download) and let us know if this helps
-
Tannin42's post in "Script Extender Plugins Error Detected" Issue with HDT DLL Won't Go Away was marked as the answer
The notification is generated by parsing the skse log files, so it will only go away after you ran the game (via skse) with the incompatible plugin disabled.
-
Tannin42's post in Deployment failed and redundant mods. was marked as the answer
In your log we have these lines:
So your staging folder is on C, the game is on F. You shouldn't have been able to deploy like that at all because the bethesda games only work with hard links deployment and hard link deployment only works if staging and game are on the same drive.
I have no clue why Vortex didn't warn about this, the fix for now would be to go to settings->mods and set your staging folder to be on F (you can probably click "Suggest" and it should put in a valid path on F)
-
Tannin42's post in How does Vortex deal with pre-existing files that have been installed outside of Vortex? was marked as the answer
It is in fact a feature, Vortex tries its damnedest to not affect the game in any way that can't be repaired - e.g. by replacing files where we don't know where they came from or if/how you would recover them.
Imaging it's your own mod you're working on and didn't realize another mod you're installing would overwrite the file you had been working on.
Vortex's job is to add mods to your game and cleanly revert the changes it made if you want to get rid of them. It's not intended to clean up stuff you've added manually or with other tools.
What Vortex does is this: if it _would_ replace an existing file, it will rename the file to <whatever it was called before>.vortex_backup. On purging its own files it restores those .vortex_backup files.
If you actually want to remove it, you can just search for .vortex_backup files and then batch-delete them. (a good file explorer - i use Directory Opus (https://www.gpsoft.com.au/) - will have the option to find files in all subdirectories or you can write a command line script or something)
-
Tannin42's post in Vortex Application Install Path was marked as the answer
There is a pattern how windows applications should be developed to provide a degree of "standardization" and this pattern has been established since Windows NT, 25 years ago.
This pattern requires that "static" application files, that is: parts of the application that don't get changed outside installation/update should go to c:\program files and that the installation of software should only be done as administrator. The file permissions enforce that.
Non-static application data that gets created or changed when you use the application should either go to AppData if the files are fully under control of the application or to the Documents directory if they are intended to be accessed directly by the user (e.g. with other applications or to be copied to different systems).
Applications that follow this pattern have no problems:
- they install correctly on a fresh windows and any windows that is correctly maintained
- their data gets picked up by any reasonable backup software
- they are much more secure
- you can update the application without worrying that you may be overwriting/deleting any of the users data
Vortex follows these guidelines so it's ok to be installed to Program Files.
Steam doesn't and it's a bit of a mess, because apparently the Steam developers have learned programming in the 80s and refused to adapt to the operating system changing. The same is unfortunately true for some game devs.
Most games nowadays however are developed "properly" It's just that when it comes to modding, we sometimes have to change files that were intended to be static by the game developers, hence having a game installed in c:\program files would be perfectly fine, but the moment you want to mod it you may have to overcome the file permissions on the directory.
There are multiple ways to do that though. The worst is: Run as admin. Admin can write to anything so there is no problem but it's a massive security issue that no amount of AVs can fix.
You can install the game to a directory that has no limits on the file permissions. That is the most convenient solution.
Or you can install the game as intended but then change the permissions on the directories you have to edit. This would be the most professional approach.
tl;dr: There is no general problem with having applications in Program Files, in fact they absolutely should be there, just when you do modding it may be more tedious if the game you're modding is in Program Files. And applications developed for Windows 98 and haven't been overhauled since, like Steam, should not be in Program Files.
-
Tannin42's post in Reformatting, how to move my mods to new PC was marked as the answer
There is a wiki article about this: https://wiki.nexusmods.com/index.php/Moving_your_Vortex_Mod_Setup_to_a_new_Computer
-
Tannin42's post in Mod can be updated (but it hasn't changed and can't be updated) 1.2.20/19 was marked as the answer
Update: you can fix this without reinstalling mods:
- Wait at least one hour after you did your last "check for updates"
- Click the little arrow down to the right of "Check for Updates" and in the menu that opens click "Check for Updates (Full)"
This check will take longer than the usual update check but it should clear out the incorrect cached data.
If you accidentally clicked the big update button or "Check for Updates (Optimized)" you have to wait for another hour. This wait is because Vortex won't check any mod more than once per hour to avoid using up the limited number of api requests you can make.
-
Tannin42's post in Vortex's reliance upon download filenames for versioning was marked as the answer
First of all, I'm fully aware that mod authors often don't use the version field correctly. The problem is that this is not a solvable problem.
Look at this mod: https://www.nexusmods.com/skyrimspecialedition/mods/5804
Assume you currently have the Paper variant of the mod at - for example - version 8.2.
How is Vortex to decide which file to get? The version number is part of the file name so vortex can't just look for the file with the same name as it currently has and then pick the newest version but it also can't simply take the file with the highest version number because that would be the "Vivid with Stone Roads" variant which is at version 9.0.1 whereas the newest Paper variant is only at version 9.0P.
The tl;dr is: It's not possible - in the absence of magic - to reliably determine mod updates for all mods, the file version is completely worthless for this purpose because way too many mod authors encode the *variant* (like "paper") into the version field, in other cases the mod has multiple variants/alternatives (e.g. 2k/4k texture resolutions) with the exact same version number.
No matter how much we communicate with the page, the information simply doesn't exist (at least not for all mods) and no matter what we change to the site now, for older mods the information will never exist.
No matter how the update mechanism works, there is a large number of mods that will not update correctly with it, we can merely decide _which_ mods will fail and the mechanism Vortex uses is the one that is least likely to lead to an unnecessary update or an update to a completely different file. As far as humanly possible it errs on the side of caution.
So this is a base fact I need people to understand: Mod updating through a tool is always a heuristic, it can fail, that can't be changed. By nobody. ever. Not without overhauling the existing data for hundreds of thousands of mods.
There is no point calling this a bug or pestering mod manager authors about it, it's a fundamental historic flaw in how nexusmods stores mods and we will never get rid of it, we have to make the best of the information we have.
The only ones who can actually ensure a clean update procedure is mod authors, by strictly using only a subset of the functionality the site offers, such that mod managers even have a chance to correctly find an update. But that too would first have to be communicated through the site...
To address your actual point: Vortex doesn't use the file version. At all. Anywhere.
Vortex determines updates in one of two ways:
a) Mod Authors can, when they upload a file, declare that "this file is an update to this older file I uploaded earlier". This information is saved internally, not visible to the user, but mod managers can query it. If this info is available, Vortex follows this chain of "file x was replaced by y was replaced by z ..." until it finds a file that hasn't been updated and assumes that that file is current and if it's not the one installed.
b) If that information is absent, Vortex simply checks if there is a single "Main File" for the mod. If so, it compares the file id against the one it has locally and if they differ, updates to it.
In both cases, the version number/text is irrelevant, in both cases the download happens based on a file id, an id that has to be different from the one already installed and that is found through a deterministic algorithm that won't find a different file the next call (unless a new file was actually uploaded).
If both these methods don't find a single file (either they find nothing or multiple files) Vortex will not update automatically but ask the user to figure out which update to download and then again, Vortex downloads the file based on an id that the user clicks.
At no point is the file version relevant for anything in Vortex, it's only there for the user.
However: if the author uploads the same file again, unmodified, that file will have a new id and Vortex will have no way to determine that it's the same file without downloading it. And to be perfectly honest, even if it did, this wouldn't be worth having a separate check in Vortex If anything the page should be catching this and simply not give out a new file id for an unmodified file.
-
Tannin42's post in Skyrim do not show up as a game was marked as the answer
Could you check in Extensions if "Game: Skyrim" is disabled for some reason?
-
Tannin42's post in Disable vs uninstall was marked as the answer
If a mod is disabled it will not deployed into the game directory or if it already was it will be "undeployed" on the next deployment.
Remove physically removes the mod from staging.
The effective differences are:
- a disabled mod still occupies the same disk space
- disabled affects only the active profile
- "remove" enforces a deployment (we can't correctly remove the mod without it first being "undeployed") whereas, if you have automatic deployment disabled, Vortex will request that you deploy after disabling the mod but technically a user might ignore that.
So your advice to disable mods for searching problems for example is absolutely correct, I do get the impression though that a surprising number of users avoid deployment and then not realize that it is part of their problem.
And yes, disabling a mod works the same on every game.
-
Tannin42's post in GRRRRR was marked as the answer
Wait wait wait.
For you to run skyrim from your e drive, the vortex staging folder has to be on e.
It doesn't matter where the Vortex application itself is installed! No matter how you installed Vortex you can change the staging folder location inside Vortex at any time.
Where Vortex itself is installed is completely irrelevant for all intents and purposes, it really just affects where the Vortex application itself occupies ~300MB of disk space.
-
Tannin42's post in Vortex giving "Application State Invalid" warning + more was marked as the answer
What the dialog is telling you is that if you click "Apply Changes", Vortex will create a valid mod entry for that one mod. The mod is probably not going to work since it wasn't installed correctly but you can then simply remove it from inside Vortex and - if you want - try to install it again. All other mods should be fine, Vortex isn't touching anything else.
The dialog says that mods removed in this step will be irreversably lost, but that's not what's happening in this case, Vortex is _adding_ a mod that it didn't previously have information on.
It's just trying to tell you "pleeaaase review the changes described below carefully, don't just click continue blindly.". The message isn't intended to scare you off, just to be careful.
-
Tannin42's post in zeromq.node is not a valid Win32 application error? (1.2.17) was marked as the answer
The zeromq.node we ship is definitively a valid module, when your system reports it's invalid that means it became invalid on your system.
That could be due to a corrupted download archive, a virus or hardware defect causing the file to get corrupted but in that case Vortex should have informed you on startup that files have been modified on disk.
The more likely scenario is that as HTR said, that your AV is preventing Vortex from loading the module.
-
Tannin42's post in Vortex turned from awesome to dumpsterfire and I cant find a reason why was marked as the answer
This bug will be fixed in the next release (planned for next week).
The simplest solution for now would be to simply drag the file into the Vortex download directory directly with windows explorer instead of going through Vortex.
Sorry for the inconvenience.
-
Tannin42's post in Reduce size request was marked as the answer
That's not _entirely_ true, it has to do with the programming framework.
NMM for example was based on .Net, which is installed by windows.
Mod Organizer is based on Qt, Vortex on electron, both have to be shipped with the application and increase their size.
Software like NMM being smaller is a bit of a deception though. On my system .net takes up over 3 GB and is used by less than half a dozen applications I use.
Suddenly NMM isn't all that small anymore, it's just that its framework is hidden somewhere in your c:\windows directory and get's updated by the windows updater instead of with the next NMM update.
The only way to actually build very tiny applications that still have guis are "thin" toolkits like fltk or IUP which use the windows api directly for graphics.
The result is that they are obnoxious and slow to work with, are hard to get help with (for the developer), look extremely old fashioned with next to no customization features and usually can't share code with other platforms (yes, admittedly Vortex doesn't support Linux or MacOS either but that would be a manageable amount of work if we had the man-power, it wouldn't require a completely separate application).
-
Tannin42's post in Is it possible to load a plugin "Immediately After"? was marked as the answer
No, sorry, the way loot orders doesn't give control over the "distance" between the plugins.
You could try to assign your patch to one of the early loading groups (something like DLC, Unofficial Patches, ...). It will still obey your "load after" rule but should otherwise attempt to load it as early as possible.
That may however also affect when the "buggy" plugin gets loaded, plus it's a bit hacky.
The clean solution would be to create rules or group assignments that load those "late-loading patches" after your custom patch, but that may be more work.
-
Tannin42's post in Tracking a file back to its associated mod? was marked as the answer
A quick way may be to look at the vortex.deployment.json file in <path to your game>\data
In there you will find every file Vortex deployed, each entry has "relPath" which is the path to the file (relative to "data") and "source" which is the name of the mod, however it's not the name you manually gave the mod but the a name derived from the the archive you originally installed the mod from.
Please don't edit the file, Vortex needs it to work correctly.
-
Tannin42's post in FOMODs and INI Tweaks was marked as the answer
C# based fomods can use the function "EditIni" to edit ini settings but I would strongly advice against using C# based fomods nowadays.
What Vortex does with EditIni is it creates a wrye bash compatible "Ini Tweak" meaning it creates an ini file in the "INI Tweaks" subdirectory of the mod with a name like "foobar [OblivionPrefs].ini".
The user will then have the option to toggle "foobar" on and off and if it's on, the ini settings from that file will be merged into OblivionPrefs.ini, if the user toggles it off the changes get reverted again.
Instead of using C# based fomods you can simply package Ini Tweaks like that with your mod. No need to do anything fancy, just bundle the correctly named ini files in a "Ini Tweaks" directory and the user can choose from those settings (after installation, they can toggle them any time they want)
-
Tannin42's post in Slow download speeds with or without Premium was marked as the answer
https://help.nexusmods.com/article/92-im-having-download-issues-what-can-i-do
-
Tannin42's post in Help understanding mod types and installer selection was marked as the answer
Well, the instructions the installer generates are evaluated when the archive is extracted whereas the mod type is evaluated during every deployment so the mod type is more "dynamic". A user can change the mod type of an installed mod and thereby change where the mod gets deployed, but the "instructions" that define the directory layout of a mod can't be changed without reinstalling the mod.
Since the mod type is a flag on the mod you can also use it for custom logic, e.g. an extension can react to events Vortex triggers and then have behavior that differs depending on the mod type, whereas the installer that was used during the installation is "forgotten". This is maybe something to reiterate: Once the installation of a mod is done, the installer is done, you can't have logic that goes "if mod x was installed with installer y do z". You can however have logic that goes "if mod x has mod type y do z".
Another consequences of mod types that has to be mentioned though: Each mod type is deployed individually, Vortex is not (currently) able to detect file conflicts between mods of different types. E.g. if you have a regular skyrim mod with default type that contains the file "foobar.esp" and then you have a enb mod that contains "data\foobar.esp" it will not show a conflict between the mods and it will always use the foobar.esp from the enb mod (which gets deployed later) and the user has no way of affecting that order.
Because the deployment process is done separately for each mod type, having many mod types is also bad for performance.
Both of these mean that mod types currently have to be used with care. In particular we ourselves try to avoid introducing mod types that aren't limited to individual games, because there is a performance overhead for every registered mod type where the "isSupported" function returns true.
-
Tannin42's post in Donwload issues was marked as the answer
Since last year Nexus Mods employs its own CDN which will automatically connect you to the nearest out of multiple file servers.
If that nearest server is overloaded you get bad download speed even though some of the other servers may have plenty of capacity.
The way this could get fixed is by people affected contacting the Nexus Mods web team who maintain these servers and provide information on where (geographically) you are so that they can identify CDN servers with insufficient capacity and increase capacity, or change the routing so that people get directed to more appropriate servers.
The problem is that people are telling the Vortex team about their speed problems (we get multiple messages a day for the many months now) even though we can't do anything about it.
Generally: If you have slow download speeds that's practically never a software problem but either a problem with your own internet connection, your ISP or the server. Posting about this on the Vortex forums makes no sense, pleaaaaaaaase make it stop. God, please make it stop.
-
Tannin42's post in Loading Vortex hangs on Loading Bar (1.1.15) was marked as the answer
The error messages clearly indicate network problems and it it almost certainly on your end because both the connection to our server (api.nexusmods.com) as well as the connection to github.com time out. It would be a big coincidence for both these services to have network problems at the same time.
However, network problems shouldn't keep Vortex from starting, these operations happen independently and asynchronously to the application start.
You shouldn't send us excerpts of logs, just send complete logs or upload them somewhere and send us a link. Even non-error message can be extremely enlightening because they tell us which operations were successful before it stopped, which helps us narrow down where it got caught up.