piperman123

@Tannin42 To be precise: I said it's ok to roll back 0.18 to 0.17, I didn't say it's ok to roll back to older versions in general. @OP We don't support manually creating junction points for staging files. We never said we supported this. I don't know why you thought we supported this because we never said we did. This is not a failure of Vortex, you're trying to force Vortex to work like you think it should and it doesn't. I'm not 100% sure what you're actually doing so just to clarify a few things: a) You can not create a junction point from a different drive into a vortex staging folder and expect vortex to deploy those files, it's not possible. b) If you're creating a junction point from your manually managed directory to the game directory that works, but you have to make sure Vortex never tries to deploy those same files c) You seem to be suggesting Vortex "digs up" files from the archive. That's not the case, Vortex never touches the archives unless you're explicitly installing or re-installing the mod. If you purge mods, remove files from a staging folder and then deploy again, those files are gone and don't come back until you, the user, explicitly reinstall the mod. Sorry for chucking this on here but I can't find much on the topic, this does tie in with the question to a degree and I didn't feel it would need it's own thread. I've been away from the scene for a while now and just came back to vortex. When I last used Vortex I'm pretty sure I had no trouble running a mod folder on another drive but now it seems this is not possible? I'm curious why this is. I get the limitations of hardlinks so I can understand why that needs to be used this way but I'm convinced I didn't have my mods folder and game on the same filesystem last time. Perhaps I was using the move deployment option at the time but this seems to not work now either, which seems to also only work if it's also on the same drive? Does Skyrim SE not recognize junctions or is there another reason Hardlinks are the only method the Nexus team or relying on?

Sorry are you asking if I reported it or saying you already have? I only noticed it after getting it to activate, I'm guessing you mean you did too right?

Awesome, thanks for that. It worked for me. Mods I've manually copied into the downloads folder aren't actually showing though. just a heads up. I wonder if Tannin42 n that know about this, can't imagine it being too hard to have vortex create the mod folder on activation of the game so it's weird that they haven't sorted that out.

So I'm using the witcher 3 mod manager and I ran the mod merger then script merger and I've got everything working fine except armour mods aren't working (I'm not entirely sure any of the merged texture mods are to be totally honest) and I've added custom inputs for search radius for the AutoLoot AIO mod as per the instructions in the comments on the mod page (tweaked a bit). I've set it to "IK_Pad_LeftThumb=(Action=AutoLootRadius,State=Duration,IdleTime=1)" which works but then geralt won't move. If I get roach near me and mount I can move but pressing the left thumb will loot and force me to jump of roach and then I'm stuck again. Relevant excerpt from input file: https://pastebin.com/TXHSSFnA I've also manually merged the scripts, seem fine to me but perhaps there's something I'm not understanding and that's causing the issue? https://pastebin.com/wiPnNNt2

So nothing? Surely someone else is having the issue, or maybe @Tannin42 can chip in with some thoughts? I've read that it can be an issue with switching from the likes of skyrim to the witcher but at the moment nexus isn't managing any game (it deselected skyrim after trying to activate the witcher) so shouldn't apply to this issue, right?

Yeah I did, wouldn't detect it during the scan.

I've added the witcher 3 to vortex but every time I activate it I get an error; Failed to set game mode "error missing:undefined". Any Ideas? -Edit Vortex Version 1.57 Witcher GOTY version 3.0.10.5955 Log only shows that it detects the game and then ends with that error.

Had my fingers crossed in vain hope there but, yeah, I expected as much. Thanks for confirming though, glad it will be resolved in the next version. I can see what you mean with individual files but would it not be feasible to have it log the affected mods as apposed to the individual files, that's all I was thinking of. Maybe make it log any altered esps and bsas and then what sub folder? That way you could see the main things and go as far as knowing if it was textures or meshes for example, narrows it down pretty substantially without logging tons of text. Even go as far as to have an option to tell Vortex to not log changes to certain mods? Such as your FNIS output folder for example? That way Vortex would only have to log the name of the mods it displays in the confirmation box. And I was thinking having it output into a separate log to the normal Vortex one, which would obviously make more sense for numerous reasons. That would be enough to keep track of most things, I assume users would usually know what contents have likely changed if they know what mod has been affected? It would just be handy to know what changes have been made so that if something is done by mistake it can be rectified. Also, makes it much easier to keep track of edits/modifications. While were on the topic though, the reason that happened with the purge was Vortex has become pretty sluggish, not sure if it's because it's managing so many mods now (I have 500 odd mods, 50 odd GB and just under 100k files in the mod folder)? I would have thought only the enabled mods would affect how fast Vortex was, or does the overall affect it? This is all despite it being on an SSD btw, so no normal HDD seeks or fragmentation affecting it. Perhaps you'd consider adding some sort of icon to distinguish mods that have been altered since install? I can see a number of use cases for that. if the above idea seems feasible perhaps you could have it so you could right click a mod and have it show what contents have been modded? Such as 'main.esp' or 'Textures/' something along those lines?

Thanks for the reply, yeah I get how it's detecting changes. The only thing I can think of is that during the purge I enabled a new mod with the setting to automatically deploy newly enabled mods. I can only assume this tricked Vortex into seeing leftover files in the data folder that are linked to it's mods but being half purged it saw the missing files and asked to make the change permanent? Or it did crash at some point, maybe that confused everything. I take it there is no record of what those changes were then, no log or anything I can use to track down the affected mods? I've sorted my mod folder by date modified and copied up to the last mod that has been emptied of files ready to overwrite them with some old backups/reinstall them. Am I right in thinking Vortex would have affected the file times this way or would simply loading them in Vortex make windows think they were modified? Nothing else had modified those files btw, Vortex left the entire file tree intact but removed all files, only some hiccup in Vortex could have made the change. I can post my logs if they'd help any?

Vortex started throwing a bunch of messages about external changes and they all seemed irrelevant, I'd written it off to something adding loads of delete_if_empty files or something. There was hundreds of file changes and skimming through that's all I saw. Turns out it wasn't and I've accidentally told Vortex to delete a bunch of stuff. No idea why it kept detecting all those changes or why it would delete some random esps, maybe I was purging and re-deploying too quickly (I was in a rush). So anyway, my question is; does Vortex log what mods/files were changed somewhere? I checked the log files and all I can see is "event=settings-changed, count=1" not sure if that's referring to what I'm talking about or just the application settings. I can't see anything that seems relevant at any rate. Any tips for how I can find which folders have been affected if Vortex doesn't log this information somewhere? And if Vortex doesn't log the information, this is a feature request, as such info would be pretty handy to have. Maybe even a setting to have Vortex backup changes, somewhere down the line?

Ok, so far Vortex has been great! GUI looks amazing, everything is easy to use/setup and really intuitive. User control still feels a fair bit more limited than with MO but I like the more straightforward methodology. I think it would still be nice to get more fine control in the advanced settings further along in Vortexs development however. Cracks do start to show a bit when your mod list starts to get a bit extensive though. At least that's when I started noticing some features that would be really handy to have: Drop down menu for filters/multiple sort optionsFilters, sorting mods is nice but it would be nicer to be able to filter mods by highlight for exampleFilter highlights by colour then icon and similar combinations therein.Deploying mods after a purge should enable plugins that were last enabled for that profilePurge should happen upon switching profilesA means to distinguish what is in a mod (plugins, scripts etc.)Change the highlights of multiple mods simultaneously.Hotbar for quick launching tools, perhaps a game specific bar under the games one?Allow for searching using "," to separate keywords? It would be useful when searching for mods that have a number of interacting patches etc.I know bsa extraction is quite strongly debated, I won't bring it up here, so I'll accept that if users want that functionality it'll have to come in the form of a 3rd party extension? But I definitely think Vortex should at least show conflicts that take place (as an advanced option) so that users who know what they're doing and want to then go and resolve those conflicts can do so. I do think, personally, the Vortex team should consider implementing the option for vortex to manage bsas, throw plenty of 'limited support' warnings, hide it in the advanced options somewhere, whatever you have to do to, but have it there for the users who ware aware of how it works, the risks etc. and still want/need that functionality. I don't know if this one can even be implemented or not but make it so Vortex retains information on pending downloads so they can resume/start after closing the program. This doesn't seem to happen at the moment. Lastly, It would be great if Vortex could display more information about plugins like wrye does for example. Such as showing what plugins are in a merged plugin, what plugins have been made redundant by Smash/Wrye etc.

Thanks for the replies. Yeah... I was aware of those methods @BloodyStigmata mentioned but I was looking for something to speed things up and save me the time I'd need to invest learning/messing with CK etc. plus, that would quickly become pretty inefficient when mods are adding tons of items and I need to check dozens of items to see if textures and meshes are working correctly. Also, I was pretty curious if there was a way to do it all in game and what everyone else was doing. In case anyone else ever stumbles on this looking for an answer though: I ended up using AddItems2 (which needs a bit of fiddling to make work for SSE, easy enough), made life waaay easier. Doesn't help with testing the levelled lists but I'll trust MatorSmash/WryeBash to handle those for me. I spawned some Frost giants which seemed to have the most varied mod added loot and enough was being distributed that I trust it was working correctly. Also, I plan on using SkyAI eventually, which although not adding to the enemy leveled lists it does distribute everything into the game. Those two things in combination make for a much quicker, easier and more streamlined means of testing.

It's in relation to the mod your editing. So if you go to edit mod A and it says load after and you pick mod B, it means that Mod A will load after Mod B. Think of at as, should the mod your editing load after the mod that's displayed in the pop up. Edit the conflict resolution of two mods and then go check the install order numbers for both, that will tell you clearly what loads after what. It's displayed near all the filters/sorting options on the mods section.

I answered that in my last post. Mods are tested by their authors under the assumption they are bundled in a certain way. They write install instructions based around that. Loot may contain plugin ordering rules based around the assumption that the bsa is loaded in that order too. When we give users the ability to extract BSAs they will use it, break mods, complain to the mod authors who then complain to us and everyone is unhappy. All this has already happened with MO. It was not handled well there, you just say that because you only know a third of the story. If you want to extract BSAs there are tools for that but we will not integrate that functionality in Vortex as that would imply it was a good idea, which it's not. Ok, I'll take your word for it. I've been away from modding for a while and have no recollection of why that would make a difference but I trust you know what your talking about. I still think the option to detect conflicting bsa's could be useful as well as what bsa's are being overwritten by loose files. Correct me if I'm wrong though. Would it not be enough to make them an option under the advanced settings? Or perhaps a filter we can manually apply which will show only mod conflicts between said files? That way only people actively looking for that will use it? Rather than it automatically appearing like the current conflict detection. Edit: Ok so after doing some reading to remind myself about bsa extraction: Seem like there's a number of pros and cons for both doing it and not. And it seems the main reasons for not doing it are people not understanding what it entails and being unable to update mods correctly as a result, similar issues with not understanding how things will then interact and more hassle for mod authors. However, it does seem like it's perfectly fine to do so when you know what your doing and if it's handled and implemented properly. So I get not wanting to implement the option in Vortex which is aiming to be the main mod manager used by modders of all levels. However, you are, or so it seems, trying to provide for more advanced modders. So would you at least be willing to create an optional extension or perhaps provide a hidden option somewhere with plenty of warnings about the risks etc. to allow those who wish to have bsa's handled in a similar way to MO2 do so? We could do with having Vortex show us the conflicts at least, so we can then go and manually handle these things if we wish to. Your choice at the end of the day but it seems like enough of the community that you're making Vortex for would appreciate the feature. I'm not asking for it now, but at some point down the line. Did my reading on Reddit, STEP and the TES wiki to try and get as much info from multiple perspectives as possible. This for example seemed quite well thought out and fair in it's arguments.

Ok, so... When your resolving conflicts and you select a mod, the load after thing is in regards to that mod, so it makes sense that they would mean load after the mod selected. This is more obvious when the mod you're resolving has multiple conflicts to be fair. It's hard to explain without having it in front of you, so go check out gophers videos. They'll probably help you a lot actually. Understanding why something should load after something else should be pretty obvious if you're so familiar with SSEedit and whatnot but I get sometimes something just doesn't click. Anything that has the same files will conflict, everything you want in your game needs to load last/win the conflict basically. Same as with your normal plugin load order essentially. Just with regards to the contents of the mods (textures and meshes being the usual culprits). This happens with bsa's automatically as the game loads them in relation to their esp which usually works. Loose files work differently, they always win over bsas and load in whatever order they were installed in (or whatever order you've configured through the conflicts and priorities) i.e. 'bsa's<loose files in mods early in Install order<loose files late in Install order'. As for documentation, this is because so much is still being added and it's only in alpha. They're expecting the people who are trialing the software to be able to work most of it out. It's pretty straightforward compared to most alpha software, go try zEdit and you'll see what I mean but that. Basically why right up a load of documentation when it's just going to change and they are still trying to actually finish the software itself? I know, it would still be helpful... and yeah, should still be provided in some degree. It's fairly amateurish to send people over to Gopher and say watch his videos instead but... excusable, arguably, for early alpha 'sort of freeware'. It's better than a lot provide. And obviously Gopher does cover basically everything and is pretty easy to follow, just that it's video instead of actual documentation. Links on Vortex's mod page. I hope all that makes sense and is easy enough to follow, explaining things ain't really my forte. Let me know if your still struggling with anything, on here or pm me. I'm happy to help.