kamikatze13

brb, trying it out =] EDIT: nope. didn't change anything :sad: ADDENDUM: i also have a hard time enabling the disabled esms: i can get one .esm - actually i can only enable update.esm - to be enabled (not that it persists after application restarts) - but not the others.

yeah, it's an edge case - i'm fine with no official support, just looking at what is possible and what isn't =] Thanks for pointing out the single config/database situation - any plans on changing that? I'll keep the extension suggestion in mind, though.

a good point, thanks. maybe it'll do. However, i'd still like to know if anybody has tried multiple instances

Here ya go =] You know the MO alternative? boy i'm running into a minefield here once again klicking a bunch of times is fine. dropdowns are kinda alright (tho they aren't a pleasant UX). klicking the same bloody dropdowns all over again in a setup with six hundred mods, knowing you could just drag a certain mod once? priceless! and i totally am going to recreate my LE modlist in VO, just for the sake of breaking testing it. (i tried to import but VO just committed suicide during the process)

what if a mod contains a data folder, accompanied by a bunch of readmes and screenshots? will they automagically land in the root, thus cluttering it?

basically with profiles there's no way to hide mods that are used in other profiles, is there?

I cleaned the ESMs and made a new mod which contains the cleaned ESMs, so i have the originals and can disable the cleaned ones if anything goes awry - whole point of mod management, amirite? However, VO is going nuts in the plugins section: they are no longer recognized as "loaded by engine", the load order is just plain wrong, all of them end up being "disabled" after application restart which, besides being a minor annoyance, it throws the mod index off. a workaround is to copy the edited ESMs into the data folder, thus circumventing VO entirely - but this kinda defeats the use case of a mod manager in my eyes. so, yeah. it's a bug report i guess.

the issue with profiles is they all share the same set of installed mods. which is exactly the nitpick i try to work around. i'd end up with up to 3/4 of mods just linger there being disabled for a given profile.

late to the party but i thought i'd chime in: I see the the ball is currently on the nexus side: Dark0ne needs to separate SSE and VR. If i understood arthmoor right, beth don't support mods on VR (minor issue) as well as VR being developed on a much older code basis (major issue), rendering sse-compatible mods incompatible on a subtle level anyway, e.g. USSEP is unsupported for VR, for a reason. This issue needs to be communicated clearly - which only a clean cut will adress properly. VR is not just SSE in 3D. imho it's much more of a hassle to find out if a given SSE mod works for VR. Dealing with VR support also means additional workload for mod authors. TL;DR: split the games at nexus level. However, if the split is not feasable, i'd vote for Sol B Var 1 (not var 2) as well as what @Michelangelos proposed (user prompt with a checkbox for setting a default until application restart)

Coming from MO, I had four different installations, where each installation would add new, installation-specific mods to the respective load order. Mods from other installations were symlinked on a case-by-case basis. So basically what i had was profile/instance-specific mod sets: MO instance 1: Mod A, Mod B MO instance 2: Mod A*, Mod B*, Mod C MO instance 3: Mod A*, Mod C*, Mod D, Mod E (notice Mod B is missing) * indicates symlink, so i don't have multiple copies of mod files and so on. Am I able to replicate this with VO?

Just wanted to throw the news in, since it's platform-related, just as performance is. Glad to hear performance is at least on the priority list, though. I have to say though that dealing with security concerns previously only related to web applications on desktop is .. well, unsettling to say the least. While I respect your choice of platform - you surely have your reasons - I find it ... let's call it "unfortunate".

ran into this issues a few days back. definitely needs improvement. i resolved to updating my mods manually via changing the files inside the respective mod folder.

i tend to agree with @thunderlord2200 on the conflict resolution being a PITA. Boy did i have a blast setting this one up: and this is not even my final form the dyndolod output folder

while i agree about the development stage, i'd wager this security-dumpster-fire of web develolment would still have a disadvantage to a native desktop application. Addendum: i have currently ~60 mods installed. It lags while scrolling. I had tried to import my >600 LE load order from MO: Vortex basically commited suicide.

screw guessing. have the user click a checkbox (slider like esp index locking): it gives control to the user and solves the problem efficiently and reliably.

Good evening, well, title basically: on conflict resolution, a check if the file in conflict is the same across the conflicting mods would be handy. Might show a grey lightning instead of a red one, since no user intervention is required. reasoning: simplification for noobs, which is VO arguably is all about. currently VO is showing me about ten conflicts with the same bloody farmhouserailing.nif. i know it's the same - i checked the hash values for all the mods in question - and i don't care which mod wins for the same very reason.

kudos, priorities seem to be more appropriate

After a coffee, i decided to create a new profile, disable all but the aforementioned mods, create the supposed load order via index-locking each plugin and finally daisy-chaining the plugin sorting rules. after over a week of using VO to recreate a specific mod list, this is my verdict on rule-based load order: http://i0.kym-cdn.com/entries/icons/facebook/000/024/153/soundsgood.jpg ADDENDUM: f***. me. the upper darker nights plugin has a mod index of B1 (lower prio) despite there existing a rule which forces it to load after the plugin at the bottom, which has the index B3 (and thus getting a higher prio and thus breaking the sorting rule). and no it's not index-locked - i double-checked. Consider this a bug report. ADDENDUM 2: after a restart of VO, some of my plugins are locked to index 0 (all of the disabled ones), even though they were not locked before restart. removing the index locking on each plugin and restarting VO reverts them to being locked to index 0. This is another bug report. WORKAROUND: for each plugin affected: toggle index-locking off->enable->get it sorted onto a position->toggle index locking on for this plugin->toggle it off again-> restart VO

Good evening, i finally decided to both take up FO4 as well as let VO loose onto it. The journey was quite nice, until now... I'm currently trying to get the correct load order between TrueStorms+VividWeathers+DarkerNights+TS-VW-DN-MergePatch - and with >15 plugins involved it's a nightmare. Maybe i'm tired, maybe i'm retarded, maybe even both - but after creating twenty-something rules to cover the relevant plugins (cause LOOT is putting each plugin into the wrong order if i ever exclude it from the rules) i lose track and have to start from scratch, since i've forgotten which plugin i was currently at, which rules i have already created and which i have yet to do. Yes i know i can read it up under 'manage dependencies'. no it's not helping. I tried top-down, bottom-up, "transitive" rulesetting - i end up with unmanageable complexity and start again. I'm both out of ideas as well out of breath. My next move is locking each plugin to a specific index. And since i'm here, scrolling through 200 mods/plugins lags incredibly - is it only on my end?

well aware that alpha software is not feature-complete, just hoping it'll be bumped further up on the todo list :wink:

having started to mod fallout 4 yesterday from scratch with VO, the lack of BA2-BA2 and BA2-loosefile conflict recognition is off-putting - i'm starting to consider extracting

Just a heads-up: With the patch 1.3, Warhorse seems to have introduced another way of mod handling, which involves creating a `Mods` folder in the root directory of the game, containing mods as subfolders. These subfolders' contains are relative to the root directory, and not /data (easy way of handling mods with localization files). Also it seems some sort of descriptions in form of `.manifest`s are supported. Here's an example mod Here's another Mods with that sort of setup structure are incompatible with the way VO currently handles mods without manual intervention (VO ver 0.13.3) TIL there's a nexus wiki

Well if you use the `Source` dropdown, you can let VO guess the mod ID, so there's that - i see however that if the ID has been guessed correctly it also could go a step further and check the filename/hash of the installer to get the correct version number from nexus. Same for mod names

agreed, it should be the easiest one. If the system has to be developed for a game anyways, it might be deployed for KCD as well - it should work just fine. Just gave it a shot, it's alphabetical only - putting a leading integer into the filename makes the original archives overwrite the mod. one archive at the bottom - zzz_all_my_mods.pak - seems the most effective solution ADDENDUM: there are mods which put archives not only into /../data/ but also into /../localization/ - here's an example. This should be taken into account on the next iteration of the KCD plugin.

VSYNC toggle oneliner, Volumetric Fog oneliner, and some texture streaming improvements. I dunno if it's worth the hassle, though. well, the magic number is 504b 0304 for both the original paks as well as for the mods', so i think those really are just plain zip archives. I'll poke around today and maybe i'll find something out about the order in which the paks are loaded and whether loose assets get loaded or not. hell, it might even be loading the paks alphanumerically, since modded paks tend to start with zzz_*. EDIT: loose assets don't get loaded, load order seems to be alphanumeric indeed (according to comments in a mod, havent tested it yet). repacking assets as zip and changing the file ending works. a thought crossed my mind about conflict resolution, if we were to go the route of modifying the paks which the mods consist of, maybe we could just throw all the correct assets into one big archive? But now that i'm typing this it seems like a bad idea after all, management would become much more difficult.