Jump to content

Kezyma

Mod Author
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Kezyma

  • Rank
    Citizen

Recent Profile Visitors

235 profile views
  1. I've just released v4.3.3 which includes an incredibly experimental and rather untested plugin which you can enable to attempt to automatically detect and install root mods. Probably wont work with everything, but I'll improve support as broken mods are reported to me!
  2. Looks like there's something wrong with the DDSPreview plugin, I'd try reinstalling MO or asking on the MO discord. I believe DDSPreview is a plugin included with MO, so someone there should be able to help!
  3. Mod Managers treat Game\Data as the 'base folder' that every mod goes into. Every mod in MO is packaged so that the contents of each mod map directly to Game\Data. Root Builder lets you install mods directly to Game\, but because there top level for MO is not that high, I created a subfolder, which, if mapped directly onto the game itself via MO would be Game\Data\Root but then Root Builder maps that folder to Game\ (although obviously in a very different way due to the different requirements of those kinds of mods). All mod managers I know will identify if a mod is packed with a Data folder or just as direct contents of a Data folder (based on a hardcoded list of valid folder names and file types). It then repackages all of them so that the mod only contains the contents of the Data folder and nothing higher than that. It's handled on install to MO as opposed to later on. Root needs to be added to the list of valid data folders for three reasons. When installing a mod via MO, if someone hypothetically did package a mod with the Root folder structure, MO would automatically detect that and install it correctly without manual rearranging needed. When installing a mod via MO, the red border and warning message that your mod is packaged wrong during manual installation would go away once you had arranged it for Root Builder. When a mod is already installed, if it only contains a Root folder, MO would no longer show an icon next to it and grey it out with the message that it contains no valid files!
  4. Building a second time while the first is still in place will just add any new files to the build, but wont remove anything you've disabled in the meantime. It'll clear when you close an app and build when you launch one. It could get confusing though and I understand, I was just pointing out that you can technically run multiple apps while having MO unlocked without clearing as I only just realised it was possible. I believe there's already some issues that can arise from running multiple apps through MO and changing enabled/disabled states anyway, which aren't to do with RB. I think that's why MO locks itself in the first place and encourages only running one app at a time. Autobuild is new, most users coming from older versions are used to manually building and tend to turn it off to stick with the workflow they're familiar with! They're all just tools and I'm glad you've found a way to make it work for you!
  5. I mean they 'could' end up doing that, I just don't 'expect' it. It's mostly out of my hands! Ideally, if I can ever figure out a way to identify the appropriate install structure of root mods, I'd just hook into MO's install process and repackage them so it ceases to be an issue for install complexity, but that's a long way off! As you said, FOMODs can still be installed manually, and I'd probably guess that they're installed manually quite often! The only real exception is stuff like OMODs, which require OBMM to install. Even then though, most people just use OBMM to install the OMODs and nothing else. Yeah I understand, it's just that's a decision out of my control. The answer I got when I asked about it today was that ideally they want plugins to be able to register additional folders as valid instead of adding it directly to the plugin. We'll see what happens with that next! Either way though, it wont be for another MO version or two before it gets implemented! Yeah, I'd like to find ways to make both easier. An automatic install process to restructure mods would be ideal, but complex to write and possibly error prone. In terms of MO warnings, it's just something that has to be worked around until MO gives me a way to resolve it. For now, I just make a note of it in the docs so that any users reading them for answers will know it's probably okay! They know I want a way to stop those errors, but until someone actually sits down and implements it, I'm sadly a bit stuck. RB has been developed for years now, and in terms of usability, it's drastically improved. The early versions required installing RB separately, adding it as an app to MO, repacking all your mods in root folders, launching RB through MO, running a (very slow) build to copy stuff across, then doing similar to clear later. There was little to no handling of file changes or additions and game updates would totally break it. It wasn't until about 6 months ago that it finally got rewritten as a plugin and got features like autobuild and redirect to make it user friendly. Now, the only thing a user has to do is learn how to repack a handful of their mods, and assuming they refer to the docs if/when they get stuck, they mostly seem okay! If I can make it easier to use, without sacrificing functionality or introducing fragile workarounds, I will, I'm just waiting on MO to get updates that allow for it.
  6. Perhaps not, it was a long time ago that it was last discussed and I can't remember the exact reason it wasn't done. Likely because at the time, RB wasn't even an MO plugin. There's lots of stuff that the API needs extending to do, but the issue usually isn't that they're unwilling to do it, it's usually more of a lack of time and dev resources to get around to it. The Root folder is the standard as far as MO and MO plugins are concerned. It's not the standard outside MO though. By standard in this sense I mean that if you have your mods installed in a way that works with RB and then RB stops working, any future plugins for MO (or direct updates to MO itself) will use the same mod structure, as does the current alternative to RB! I wouldn't ever expect mod authors to pre-pack mods with a Root folder though, since the global 'default' for modding isn't to use a mod manager at all, let alone MO specifically! All known MO plugins have been developed so closely with or by MO devs in the first place that the lines between official MO stuff and third-party plugins is pretty blurry. A lot are included with MO itself, but have newer versions available (we're currently planning on including MO 'official' plugins in Plugin Finder so that people can update them), and a good portion of them seem to be developed as third-party plugins and then get included in MO releases later on. Both Root Builder and Plugin Finder could end up in MO in future, but the MO plugin API needs extending so that I can replace some of the workarounds. They're also keen on RB defaulting to USVFS + Link mode instead of Copy mode, so that needs more testing and work first too. Currently both of those are considered nice to have but non-essential, since everything still works perfectly fine and warnings don't prevent any functionality. It's somewhat annoying to people who pay attention to it, but so far I've only had one user ask about it, and they were quite content when I told them they could ignore it (and updated the docs to let people know they can). I don't think most users even notice the warning in the first place. I also think the thing is that the users that aren't willing to put the effort in are also users that aren't bothering with MO in the first place, they're either installing manually or using Vortex because the Nexus tells them to. I've stuck a query in the MO discord about adding it to Bethesda games, so will see what is said about it! I've just checked and RB's autobuild doesn't clear until one of the apps is actually closed, so you can unlock the UI without clearing as long as you leave all the apps open. Just as a side note!
  7. Whatever checks that will re-run when you open and close the info panel in MO as far as I'm aware. At some point I'm sure the root folder will get added to the supported MO games!
  8. I have asked about it before. It'd need adding to more than just the skyrim plugin, since it works for all Bethesda games! It'd also probably need a content indication icon. I can't quite remember why it wasn't done, but I've asked again. It'll be a while either way! I could probably do it myself and just open a PR, but I don't want to go messing with other peoples code! Ideally they'd add a way for plugins to alter the current game's list of valid files/folders, but that's probably a long way off! There's a lot of cool features I'd like to add, which is why RB is technically still in beta, but I'm taking a little break at the moment as I've written a lot of plugins in athe last month (Reinstaller 30th Nov, Shortcutter 10th Dec, Plugin Finder 15th Dec, Curation Club 22nd Dec, Profile Sync 26th Dec) and released a bugfix for the CC Bloodchill Manor with majestic mountains (and other landscape changing mods). Need to take some time to actually play the games haha!
  9. Autobuild is relatively new, with it switched off, just make sure you remember to clear when you're done. It's probably fine, but it can be a bit annoying to clean up if your game happens to update while you've got a build in place That'd be nice, but there's no way for me to do that. The API available to plugins doesn't let me change the game plugin functionality. I'm not sure what exactly determines it though! I'm hoping that it gets expanded to allow this in future though! There's a lot of feature requests I've made to try and improve my plugins and I've used workarounds wherever possible in the interim. I will update it as new stuff gets added to MO though
  10. There's no special case for anything, skse was just an example because I figured it's the most common mod people use that has base game files. The old docs used MGE XE as an example! When you launch an app through MO, Root Builder checks to see if the exe is being launched from a Root folder inside a MO mod. If it is, Root Builder works out where the exe is now in the game files and tells MO to launch that instead, it's what the redirect setting enables. It doesn't work with adding flags to the exe though, due to MO limitations, but I've put in a feature request to them so that I can add flag support in the future.
  11. The devs of every currently known MO plugin are all either active or reachable in the MO discord, there's only a handful of people making plugins (Plugin Finder has 18 plugins and 6 are plugins I wrote), but I know what you mean! Thankfully, MO devs have mostly had a role in the development of every plugin and a good portion of them are actually made by MO devs anyway, so hopefully wont be going anywhere. In the case of Root Builder, it's got a few things going for it there. I've kept it updated for nearly 4 years now, in one form or another, but more importantly, there's another plugin that does something similar using the same folder structure, which seems to have been accepted as the 'standard' for root game files. So if RB and the other plugin both disappear, any replacement that someone makes will almost certainly use the same mod structure (unless RB just gets integrated into MO at some point). I've also updated all of my plugins (except the 2 still in alpha) to work on the next version of MO after playing with it for a bit, so that should last for quite a while already!
  12. You probably want it to run for LOOT, since LOOT does check to see if SKSE and stuff like that is installed, but yeah, I see your point. Perhaps one day I'll add a way to flag certain apps to skip building, although it's generally quite fast unless you have some very unusual setup! The Root Builder panel is the advanced settings panel! In the documentation, the 'Usage' section tells you everything you need to know, which is how to install root files and how to add exe files that are in mods to MO! The tools menu is mentioned in a separate section further down where I say that using the default settings, all the tools are entirely optional to use. The idea is that you install RB and it just does its thing in the background, with a settings menu to change stuff (and quick action buttons if you change stuff enough to need them, like disabling autobuild). It's meant to integrate into your usual modding workflow. Root is a folder like Meshes or Textures that just happens to be the one that you put base game files into instead of nif or dds files
  13. Yes, although you don't need to use all of them to maintain different game versions, but it can be nice to migrate most of your game to MO! In the absolute minimal game folder setup, the game folder consists of a copy of the main exe for the game (so MO detects it) and an empty Data folder, everything else is stored inside an MO mod, including alternative copies of the exe. I just leave my game folder in its normal vanilla install state and store any modifications (including downgraded versions and CC content) in mods. That way, backing up my portable MO folder is a complete backup of my mod setup, which I could copy to a new computer and install a vanilla copy of the game and be ready to play with no hassle. ENB management is probably the biggest time saver, and I'd say better than using any separate manager since it's integrated into the usual modding workflow, although I've never really played much with separate managers. Root Builder was originally converted to a plugin because I wanted to switch between vanilla Morrowind, Tamriel Rebuilt, Myar Aranath and Arktwend, all of which required different versions of various mods and different code patches to the main game exe. Instead of having a whole bunch of different versions of the game, I could have one, and just switch a profile in MO to play with the different exe. I've got similar setups for Oblivion/Nehrim and Skyrim/Enderal.
  14. Yeah, I developed it pretty much just as a request from someone who wrote a separate script to do something similar, but wanted it as a plugin. The idea is to a) help you save time downloading CC content if the game needs reinstalling and b) to allow you to pick and choose which creations you want at any given time. If everyone is meant to keep them all enabled all the time, it's probably not the most useful of plugins! :P
  15. I'd like to add something that picks up on mods being installed and tries to rearrange them for some known mods in the future, but it's quite a complicated process, so it might be a while! The biggest problem is working out how to arrange stuff so that it all works, but I'll do my best to figure it out at some point. Pretty much, instead of manually installing SKSE or ENB to the game folder, you just install it to a Root folder in a MO mod. That's all you need to do If you want to update SKSE or ENB, all you do is install it like any other updated mod in MO. Root Builder will handle the rest! Game updates used to break things, but I fixed that recently. When the game updates, as long as you don't have a build in place at the time (which you shouldn't unless you've started fiddling with the manual tools), Root Builder will detect that pretty easily and you wont have any problems. If you do have a build in place, all that will happen is the next time you clear, the updated game files will end up in MO's overwrite folder and the game will be reverted to pre-upgrade. You wont notice this unless you actually check though, because it should all still work as normal. You shouldn't need any ENB manager if you use Root Builder, since ENB presets become just regular mods in MO to enable and disable like anything else. You need to install mods with root files to the game folder manually already, which I don't think is much harder than installing them to a MO mod with a root folder. Other than that, you don't have to do anything else at all. Root Builder, by default, is meant to be user-friendly, it will build automatically when you run an app and clear when you close it, using copy mode. The other options are there for users that want them, but should be completely ignored by almost every user. The process should be as simple as Install Root Builder to ModOrganizer\plugins Install all base game files in MO like regular mods, putting the base game files inside a Root folder. Enable the mods you want. Play the game There has been some discussion in the past about incorporating Root Builder (and Plugin Finder) into Mod Organizer at some point, but for now, I've got a very long feature list to work on before that can be talked about again. I'm happy to answer any questions you have about the plugins
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.