Tannin42

AllSetsExtended.esl is a master, HAIA.esp is not.
Masters can not be loaded after regular plugins (the game doesn't allow it, independent on which tool you use for your load ordering).
The user telling you to load them in that order was either talking about different mods, different versions of the mods or they were misinformed.
 
Edit: To clarify: files with the extension .esl are automatically masters.

It's from the skse log file in C:\Users\Tannin\Documents\My Games\Skyrim Special Edition\SKSE (or f4se or whatever, depending on the game).
 
But if you're going to continue modding you're probably going to use the script extender in the future so the easiest solution may be to just update/drop the failing plugins and then start the game without outdated se plugins.

For one thing: You really shouldn't force plugins to load in a specific place.
"where I want them in the load order" doesn't really make sense, the load order is a technical thing that can make the difference between your game working correctly or not. Either plugins conflict and *need* to be in a certain order or their order doesn't matter.
Vortex is trying to enforce known requirements on the load order which you are overriding with forced indices. Best case scenario is that this does you no good, worst case is your game will run worse than if you had done nothing, either way the time you expend on doing this is almost guaranteed to be wasted.
 
The mod index is not just an indicator of the load order, it becomes part of all form ids the mod generates, like items to mod adds to your game.
E.g. if you have a mod that adds a bunch of weapons and it loads at mod index a3 then every weapon will have an id of a3xxxxxx.
 
The tab to lock mod indices is not intended to be used as a way to enforce load order. There are plugins (very rare, as in: I know of 2 across all bethesda games and one has been removed in the meantime) that may break things if during a playthrough the mod index changes. Also some mod authors write scripts that require a plugin to be at a fixed index. The locked index Vortex offers is only intended to facilitate these use cases where the index needs to remain fixed.
 
The mods you're seeing are light plugins introduced in SSE and Fallout 4 which break some of the known rules for plugins. Light plugins are _always_ loaded as mod index FE. This is enforced by the engine and can not be changed (not, through Vortex, not through any other mod manager, not by directly editing plugins.txt) unless you convert the plugin to not be light.
That's why the index lock feature doesn't work: The mod index of these plugins is enforced by the game.
 
You need them to load at mod index 54? No, you don't, because that's not possible. No one loads them at any other index than FE. Thus no one has tested them at any other index. Thus there is no way that you have a problem with it being at index FE that you wouldn't have if it was at a different index.
 
The *load order* of light plugins *can* be changed. The *mod index* can not. For light plugins these are decoupled which makes the whole load ordering process much more complicated.

You're actually missing both the plugins and the savegames tab.
 
Please check on the "Extensions" page whether "gamebryo-plugin-management" and "gamebryo-savegame-management" are disabled or have a load error reported - it's also possible that a load error will only appear in the vortex.log
If it's just disabled you can enable it.
Otherwise you should try to reinstall Vortex.

error code 193 indicates that the files in question are supposed to be executable files (.exe or .dll) but aren't.
 
This could indicate that the files have been corrupted on your system (through a virus for example) but far more likely you're using plugins intended for the 32bit skyrim with the 64bit skyrim special edition.
These don't match, you can only use plugins found on https://www.nexusmods.com/skyrimspecialedition/ with SSE.

This is probably on a 4k screen with a high value for font scaling.
Vortex has no way I know of to influence this, the installer (fomod c#) creates its own UI calling .net framework functions directly. This is one (of many) reason I absolutely loathe c# based installers.

For reference: Others may encounter this problem after importing from NMM. The problem is that NMM doesn't seem to store the id for the files individually (it does have the attribute and we import it but it seems to always be empty, at least in my test system and obviously for Katschaba).
The result is that Vortex can't determine that the files in question here are separate modules and instead assumes they are different versions of the same file.
 
I think I have a semi-solution for future releases (1.1.1 and later) but that will only help those who import with that version. For everyone else I'm afraid you will have to reinstall (maybe even "query info" or redownload) the mods that get grouped incorrectly.

Sorry, only had time to scan previous posts.
 
The default is that file permissions are inherited, meaning: if you give write access to the base game directory this would give you write access to the entire directory and everything within - unless the files below have their own specific permissions to overwrite that.
Also, rules are additive. Usually windows only works with "allow" rules meaning a subdirectory will almost always have more or equal access rights than the parent. You _can_ use "deny" rules that take away rights that were on the parent directory but those make everything more complicated and confusing.
 
So usually it should be enough to set full control on one directory (the game directory) to allow Vortex access.

Well, the directory where mods are stored can be customised - if you did that we can obviously not tell you what you put there.
The default though is %APPDATA%\Vortex\skyrim, the downloads (mods in their packed format like .7z) are in %APPDATA%\vortex\downloads\skyrim
%APPDATA% is something you can put into the navigation line of explorer, it will automatically be replaced with "c:\users\<your username>\appdata\roaming"