James_Richards

I am including some mods that I don't normally play without. I recently got into player homes and was wanting to include Elysium Estate. Seems the kind of home I am looking for. I added it, along with the sandboxing, multiple adoptions and my home is your home mods. When I LOOT'd them, there isn't much change in load order of the surrounding mods. This is mostly a good thing. I then encountered the home in my playthrough and had floating grass around the property. I had forgotten I didn't regenerate the LOD and such. So, I reran xLODGen, put the output in new mod folders (keeping the original STEP content in case I need to step back), ran ACMOS, TexGen and DynDOLOD. No real hiccups as far as I can tell. loaded up a new save and... many things wrong. Dragonsreach was not visible from the road leading out of Riverwood. In fact, a lot of assets were just plain missing. I hadn't even gotten tot he estate yet, as I am currently rerunning all the LOD programs again to make sure I didn't miss something. I also had bright green grass in the distance, yet dark green when getting close. Until I am waiting for that to complete and see what happens, I searched for other people who had a problem with Elsyium Estate and floating grass. I can't seem to find any suitable patches, and looking at xEdit, Elysium Estate's esp is the last thing to touch the area around the estate. This post discusses hiding the ini for STEP - Conflict Resolution, but the only ini's I can find are under the DynDOLOD folder and there are three of them. This answer seems quite confusing. Another fix found on the mod page in the posts section says to disable the conflict esp altogether, but that patch as far as I can tell still doesn't touch the cells Elysium Estate is in. Does anyone have any advice

Well, I can't argue with that idea. Keeping things around is indeed helpful. I just think my impatience may have asked a question that has one of those universal "Duh" responses. Thank you for the response, though.

You will find the same issues downstream in the custom builds like soda, GE-WINE, GE-Proton, etc. Even Lutris-wine and fshack have issues inherited by WINE upstream. What Valve is doing, is not only applying "tricks" to get around them, but they are also giving back upstream to WINE, while them and the developer community at large are trying to find ways to skirt the problem or understand poorly documented calls. Any compatibility layer is going to be janky and fragile. WINE just requires a little more attention to details. This wouldn't be a problem if Microsoft had adopted open standards from the beginning and allowed their API and DLL calls to be completely documented. Hence the existence of winetricks and protontricks. Great! I can probably include that for users on your flavor of Linux in my tips guide I am working on. The only problem I see with that, as a global effect, you might break some of the other ENBs out there should you stray from STEP. There is a reason why I am pushing the use of WINE outright, or Proton from Valve as much as possible. They usually have things working better than other outfits. BUT. Greta thing about Linux; it is YOUR system. You do as you please. That also just adds more headache to wider adoption of Linux. If something breaks, it can break spectacularly.

How does Skyrim run with NO mods? Might be silly question, but if Skyrim is looking for an API/DLL call that is not fully implemented in any of the Proton, WINE or compatibility layers tweaked by PlayOnLinux, Bottles, CodeWeavers, etc; you will have a problem regardless. If a mod is making those calls and isn't getting them, that is another problem again. the virtual file system (VFS) created by something like Mod Organizer is already playing tricks to Windows. Now imagine the VFS working on a simulation of NTFS on top of whatever file system you have for your distro? Which may have issues with symlinks in the first place? This is what my terminal window looks like at some point when working with Mod Organizer: This is just opened, and as I use it, it keeps having handler errors and as I add or remove mods, change things, it will start to spit out it can't find a certain file once in a while. So far, the missing file messages are bollocks, as refreshing MO2 fixes those issues, or at least no longer a problem when I launch SKSE.

So, recently working on some additions to the game, and I got Winter is Coming and Cloaks of Skyrim installed, with Survival mode patches for them. They are ordered properly as far as I can tell. Even opened ALL the active esm, esp and esl in xEdit and checked, one by one, each cloak and cape from these mods and the last edits are the patches. Nothing else. Yet, when I am in game and in a cold area, wearing a brown bear cloak I pilfered from a dead guy, it offers no protection. I still get a notice that I am chilly with a status effect on the magic screen. Is this by design? Am I missing something? I almost feel like I am stripping that bit of creation club content as well and replace it with Frostfall or something. EDIT I spent more time doing the one thing I harp on. I read some stuff. Looks like the Creative Club content is not really a copy of Frostfall. Looks like this implementations of Survival Mode is a bit more complex. I need to also wear fur armor as well. Plain leather armor is not enough. This can be ignored. I am trying to find a DELETE button.

Did you find a resolution to your issue? If not, post a mod load order for me along with any dll injection or ENB you are running. It would help to know if you are running into an odd Bethesda bug or something brought on by a mod glitch. Without that info, no one will be able to help you.

As mentioned, if on Windows 11, you might be running into some kind of access control that was not there on Windows 7 or 10. If there isn't too much hassle, maybe try the update 479 version for LE on Vorontsov's site. He tends to test things on reasonably updated equipment and older version of the d3d dll's may not be usable on current versions of Windows. I generally try to stay as up to date on everything I can. dll injection/wrapping has always been finicky and has only gotten better with time. This is assuming it is definitely an issue with ENB and not an SKSE dependant mod/dll.

I may also be tempted to create an AE from GoG guide. I plan on tinkering with that as well.

I am using the 493 (if you have Skyrim SE) version without issues. Like I mentioned in our direct message exchange, there is a LinuxVersion folder. Use the dll from there. You can use the rest of the files from the WrapperVersion folder. Vorontsov's site should have it. Direct link: http://enbdev.com/enbseries_skyrimse_v0493.zip From enbdev.com, click NEWS, then from the top Download, then scrolls down under the "graphics modification" heading to your preferred version of Skyrim. "TES Skyrim SE". The 493 version should be there. Also, forgot to mention; Vorontsov keeps milestone versions on the site. If he doesn't have a version available, there is usually a good reason.

This guide is for people using Steam and Proton HERE is a WINE-ge non-steam GoG focused guide. HERE (05-10-2024) I thought I would share my adventure in getting STEP setup and working on Linux. Specifically, Arch Linux. Due to the proliferation of various open source drivers, window managers, desktop managers and now going from Xorg/X11 to Wayland; Linux can be quite difficult to do some more advanced gaming. In the last few years, Linux has become a more viable gaming platform, with Valve and CodeWeavers spearheading WINE development and improvements. Many Linux users for the last couple decades have become quite familiar with WINE and applicaitons serving to help simplify the experience (PlayOnLinux, Wine Bottles, and now Lutris). My guide's goal is for the people who are just now getting into Linux or have been using Linux and want to stop dualbooting just to play their games. My guide is built on a system running systemd as much as possible (from boot to desktop environment, no GRUB here), KWin for a windowing manager and (KDE) Plasma for a desktop environment. It shouldn't matter your setup, as long as you are able to download and install a game made for SteamOS, no matter what distribution you are using (Ubuntu, Arch, Manjaro, PopOS! or anything else out there). If you can't; stop and fix that first. I am not a Guru at Linux yet, and I will try and help, but you will be better served ensuring you can 1) play a Linux game without issue 2) can install steam and install one of the many SteamOS games out there and 3) check the support forums for your particular distribution. Asking for help is no longer a moment of fear; the community is not gate-kept buy crotchety old men and women who feel superior to others. The community is much more open these days. Just make sure you spend some time Googling for your answers or searching the forums before asking. Let us look at what I did to make things easier. I have Steam installed and have been able to download and play many games that are built with SteamOS in mind. These are usually "Linux games", meaning the executable or binary (as I am apt to call them) are *.sh files. NOT *.exe or *.bat files. I would give examples, but I am not sure what the 15 to 20 somethings are playing these days. As with every Skyrim modding step, download and run Skyrim for the first time. Start the launcher, let it select your graphics settings (these will be changed later anyway), start a new game and let it play past the titles to when you get that classic "Hey, you!". Just quite the game. Don't bother changing your key bindings or preferences, those changes will end up being overwritten later. When you are back in Steam, right click the game in your list of playables and go to Properties. I have always had issues with the Steam Overlay, and I have never used it. So I turn it off, as well as Theater mode (I am too poor to do anything with VR anyway). For me, I also stop syncing game saves. Why? For one thing, I have my own backup system in place and I was running into a weird issue where things would stop working when trying to run SKSE when it was on, for some reason. I might explore that later. I also set Skyrim to update only when I ran it, zipped up the main exe and launcher and saved that. I don't see Skyrim being updated that often anymore. I think Bethesda are going to be focusing on their other properties for a while. BUT, better safe than sorry, and running Skyrim through SKSE should keep things from updating anyway. On the left, chose 'Compatibility' and put a check to force the use of a specific Steam Play Compatibility tool. For my success, and until I am able to properly put my setup through its paces, I am using Proton 7 (7.0-6). Proton 8 I believe has some feature regressions that cause problems. Close the window, minimize Steam. If you have Skyrim Special Edition / Anniversary Edition, both Edition monikers use the same compatdata folder. This folder is where your "C Drive" is going to be. Depending on your install, how you have Steam setup and where you have your Steam Library, you will want to open your file manager of choice and go to ~/path/to/steamapps/compatdata/489830/pfx/drive_c Looks a little familiar? Windows folders. AppData folder. You are most likely in the right place. You can double check by going to "users", then "steamuser" (most installs have this as Proton doesn't always carry over your SteamID info the same way it would on Windows), "Documents" or "My Documents" (the later is linked to the same folder), the "My Games" and you should see the Skyrim folder that houses your save games and current INI's. DO NOT CHANGE ANYTHING YET I mentioned those settings will change and if you have already read the STEP guide from top to bottom before starting (you did that, right?), BethINI WILL change or remove everything you change or add. Anyway, go back to the "drive_c" folder. I made a folder, Modding. I did not bother creating a "Tools" folder there as I kept in mind where all the applications and tools were being installed/uncompressed to and slightly changed the tool setups according to STEP. Really, this is probably the ONLY thing I changed early on. In this folder is where the ACMOS Roadgen, BethINI, DynDOLOD, MO2, Mopy, SSEdit and xLODGen folders are made. When working with WINE, a user should specify the environment and where things like the binary and compatibility files should be installed. You can do this outside of Steam. First, since we are using Proton, we need to ensure we keep the "Proton Ecosystem" intact. In terminal, enter STEAM_COMPAT_CLIENT_INSTALL_PATH=/usr/bin/steam STEAM_COMPAT_DATA_PATH=/home/james/Games/steamapps/compatdata/489830/ /home/james/Games/steamapps/common/Proton\ 7.0/proton run /home/james/Downloads/Mod.Organizer-2.4.4.exe STEAM_COMPAT_CLIENT_INSTALL_PATH is where the Steam binary is, the executable that starts Steam. STEAM_COMPAT_DATA_PATH is the variable where the compatibility folder will be, your "Windows DLL" and such will reside. It is a neat way to keep your WINE installs separate. I have managed to get Windows 98 games installed using some of these methods, and you should really read up on the WINE HQ site on how to do this. The next variable, is the "wine variable" the executable that makes, in this case, Proton run. (/home/james/Games/steamapps/common/Proton\ 7.0/proton) The back slash "\" represent an escape character for a space. If you do not keep that in place, you will have problems, unless you surround the variable in quotes "/home/james/Games/steamapps/common/Proton 7.0/proton" Next is "run" this tells Proton you want to run something. Which is followed by the MO2 installer. Again, if you have spaces in your variable, put a "\" before the space and you should be fine, but until you get really used to how terminal works, I would just use quotes. So again, with quotes, I would run MO2 installer like this: STEAM_COMPAT_CLIENT_INSTALL_PATH="/usr/bin/steam" STEAM_COMPAT_DATA_PATH="/home/james/Games/steamapps/compatdata/489830/" "/home/james/Games/steamapps/common/Proton 7.0/proton"" run "/home/james/Downloads/Mod.Organizer-2.4.4.exe" Usually, you can also remove the "/home/james/" and use "~/", but I am the type that is a little too anal about some things and I would rather know exactly which "home" folder I am working with. Following the STEP guide, get your tools installed and ready and then run Mod Organizer 2 for the first time. I won't go into too much detail, because it is almost exactly the same as installing MO2. The binary has changed, is all. STEAM_COMPAT_CLIENT_INSTALL_PATH=/usr/bin/steam STEAM_COMPAT_DATA_PATH=/home/james/Games/steamapps/compatdata/489830/ /home/james/Games/steamapps/common/Proton\ 7.0/proton run /home/james/Games/steamapps/compatdata/489830/pfx/drive_c/Modding/MO2/ModOrganizer.exe It should fire right up. Follow STEPS recommended setup, or do what I did. I just setup a portable version. When setting up tools to run in Mod Organizer 2, and this is for people who have been around for a while, I was using STEP a loooooong time ago; use the x64 versions of the binaries of these tools. Unless you are truly unfortunate and still run a 32-bit system, almost everyone by now should be on 64-bit enabled systems. There was old prevailing wisdom that even if you are on a 64-bit system, especially with LOD generation, using 64-bit binaries were sluggish, slow and unstable. I made the assumption that this was still the case and it was causing me nothing but headaches. Linux Proton users; use the 64-bit versions! (usually have a name like LODGenx64.exe) When instructed to run BethINI, close MO2 as normal, look at the terminal window and you should see one last line; mod organizer done. You should have control of your terminal again and can run BethINI. Just like running MO2, this is what I enter: STEAM_COMPAT_CLIENT_INSTALL_PATH=/usr/bin/steam STEAM_COMPAT_DATA_PATH=/home/james/Games/steamapps/compatdata/489830/ /home/james/Games/steamapps/common/Proton\ 7.0/proton run /home/james/Games/steamapps/compatdata/489830/pfx/drive_c/Modding/BethINI/BethINI.exe or STEAM_COMPAT_CLIENT_INSTALL_PATH="/usr/bin/steam" STEAM_COMPAT_DATA_PATH="/home/james/Games/steamapps/compatdata/489830/" "/home/james/Games/steamapps/common/Proton 7.0/proton" run ""/home/james/Games/steamapps/compatdata/489830/pfx/drive_c/Modding/BethINI/BethINI.exe" Then, follow the rest of the STEP guide, do not stray! It might be tempting. Once you have a good owrking setup, you can then start changing things. I have 8 different profiles setup in MO2 right now, each one with some slight changes I would make, allowing me to go back easily and undo those changes. Now, time for first launch. Or at least the benchmarking steps. I am not talking about the smoke tests. If you have problems here, double check which version of SkyrimSE.exe you have. Make sure you have the right version of SKSE64 installed AND the extenders. Not all Special Editions right now are created equal. During your benchmarking, you might run into some problems. If you installed everything like I did; participating in the ENB setup for certain mods, and choosing that you will indeed be using the mods suggested for Weather and Lighting, there really should be no problems. If you do, this is where you are probably having some varying system issue that might be sought after for answers elsewhere. STEP, though some knowledgeable people, are more than likely Windows users and their skills are invaluable for the Windows side of things. You can still ask, just don't expect them to move mountains like the Linux nerds littered all over the internet can. The real problems I see, are coming during the Post-Processing portion of the guide. Benchmarking would be fine, until I enable/installed ENB. Once you are invited to test again after the post-processing section is where I had my first problems. Performance TANKED hard when ENB went online. Following the STEP guidelines on this MIGHT be detrimental to your system. If you have sever performance penalties after turning on ENB, you might want to consider the steps I took. In the zip file downloaded from the ENBSeries site, at the time of writing is v0.493, there is a WrapperVersion and LinuxVersion folder. I used the d3d11.dll file from this folder. There is an accompanying README that explains the differences and the system used to make and test the DLL when Vorontsov Boris shipped this package. This DLL works a lot better! For me, My performance did not fall so hard as before. Due to the age of my system, however, I had to make a slight adjustment to the Display Tweaks ini; I kept the vsync off and screen tearing on. I also put the fps cap to 60 and I played for a couple hours. Cleared out Bleakfalls Barrow and the mine near Riverwood, ran to Whiterun and into Dragonsreach. Cheated some gold in because I wanted to see what the Tundra Homestead was all about. I noticed some screen tearing, but it really was not that bad. For me, as long as there was no lag for input (I'll be exploring that soon as well, would be nice to turn off tearing and have smooth frames with good response). As for the LOD tools, they can be run safely through MO2 without issue. Just make sure you choose the x64 versions and things should really be just fine. Most likely, my continued tinkering will have to wait until I can afford to buy new components. This rig is approaching 8 years old and I was an idiot for not keeping up with an update cycle. Right now, I am just switching out mods, replacing mods with different versions, etc... STEP has always been a good base to start at and then move into more. I for one, got rid of all the pets, mudcrab, zombies and I might start going after the goblins if I find I don't like them. Get familiar with xEdit so if you do the same, you can clean out the masters from the STEP patches. Get used to using Wrye Bash so you can manage any new items leveled lists and such and tings will be great! Wish I had a job thought... I really want a better computer. One last thing. I noticed as I would install and manipulate mods, MO2 would begin to slow down. It wasn't suing a lot resources, and my CPU never went above 10% utilization, but it would really slow down. I just got int he habit of working with 3 or 4 mods and when I notice things slowing down, I would quit MO2 and reopen it. No biggy. My next post, if it is wanted, I am thinking of writing up how to setup NXM handling and creating desktop shortcuts for those would like to use less of the terminal. I hope that maybe my insight might help someone, and I am available for direct messaging, or responses here. If I notice a FAQ coming on, I'll build one of those. This might go through rewrites or changes to reflect anything I found or felt needed to change or be brought up. I will do my best to keep this maintained. If I slack off, just message me and give me a good bollocking

I think I got it working, but it is taking FOREVER! And 3 hours and 25 minutes later, Done! I am guessing my issue is not using the 64-bit variants of these programs. I am really certain that previous STEP version I used a looooon time ago said not to use them as they were unstable, even on 64-bit Windows. Maybe my assumption is wrong this time around and I should be using them. Going to testr TexGen again and see if I will be able to do all this without a WIndows VM Final issue resolution, I think. DynDOLODx64 works just fine, as intended by the guide. I don't really know what I was doing wrong. So, I installed the DynDOLOD Resources SE mod, then the DynDOLOD DLL SE. Originally, I was having some issues which I think stem from using the 32-bit version of the binaries. Still using the 32-bit version, I ended up hiding the scripts from the Resources to ensure the DLL scripts were available, then replaced the scripts from the Mega download I mentioned previously. Things worked finally, it just took forever. On further inspection, it may all be a red herring as comparing the two downloads, there is no difference, right down to the byte of every individual file in the acrhives. I have no idea how it all just started working. After everything was done, I reinstalled the Resources and DLL from the guide download. Doing nothing else, except switching to the 64-bit binary, things worked as intended. I think the old habits and advice from previous versions of STEP advising NOT to use the 64-bit binaries, even when on a 64-bit system have been the cause of all my problems. Back then, there was a problem with the 64-bit binaries, that have either been resolved (hence why I do not see that advice in the current STEP guide) or for people on Linux running through WINE and Proton, the 64-bit binaries are beneficial and useful. Either way, all that is left is to run tests and see how the full ENB and LOD loadout for STEP is going to work for me. Initial tests hows a flat and constant 30 fps, but there is input delay. I think I'll be tweaking the ENB or Display tweaks. For some reason I can't get the ENB configuration to open with the shift+enter combo. @z929669, I don't think I'll be going to sheson just yet as this may all be misunderstanding and ineptitude on my part

Everything is cleaned. DynDOLOD is not complaining about that. The link for DynDOLOD NG in the guide, does come with scripts. Apparently for me, bad ones. I am just waiting for LOD to complete. Might be a while. The guide is assuming I am on Windows, so I need more time than what is outlined. Right now, it is sitting at "Waiting for LODGen.exe generating object LOD for Tamriel."

I don't suppose one of you fine people can upload a copy of your DynDoLOD output folder? I followed every step of the current STEP guide for ENB and post processing, including the weather and lighting. I am asking because the only thing keeping me from moving forward now is DynDoLOD. Keeps complaining about no NG scripts Large reference bugs workaround requirements not met. DynDOLOD.DLL: NG, Scripts: not NG, Deleted references: no I have even put the scripts and skse folder into the Data folder manually, disabled the DLL SE mod entry in "foundation" in Mod Organizer and ran DynDoLOD and still get the same error. As we are using a version not supported by the author, again adhering strictly to the guide, I cannot get support from them. I might use a newer version anyway and see what happens. Well. A fix here again. When I visited the link in the error (https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements) I downloaded the Mega link (https://mega.nz/file/lIwlXJYJ#kJKIgFkJPlEZ-NzmrbvtlxDe2JQOuXyyvibuvNt_bgk) and replaced the Scripts folder in "DynDOLOD DLL SE", from the DynDOLOD DLL NG entry, and now it runs.

WINE/Proton create a kind of virtual machine. A kind of compatibility layer. When you run a Windows binary that relies on DLL files, it uses them as if you were on a real Windows system. Kinda like Linux apps relying on .so files. They are kinda the same thing. I am in the middle of working on the LOD stuff and will be testing again soon with the Linux version of the DLL I saw int he latest release for enbseries.

NEW Advice Request; I am running into a problem running xLODGen, again I am following the STEP 2.2.0 guide, so running for the first time, I set the settings as shown and run it. I come back 30 minutes later and it just says Operation Aborted. No reason why. There is some output done, though I am not sure it is complete. I don't remember the last worldspace entry it was working on, as I am going to run it again soon and keep track. I whipped up an OCR tool that watches the window and spits the lines out into a text file for review. I did notice, several lines about VR not being found? Again, cannot recall the exact wording. Did I miss something? Edit====== Alright. Might have found the issue. xLODGen can work, but it looks like Valve/Proton/WINE have not adopted the XDG base specs and standards completely. Not allowing to find paths properly. So, when running xLODGen on Linux, with Proton v7 (I may try version 8 soon, and then GE's version), an error pops up frequently; "Unable to read VR Path Registry from C:\users\steamuser\AppData\Local\openvr\openvrpaths.vrpath". the only solution I have found is to run this particular tool in Windows. I fired up my VM and cloned the modding directories and installed Skyrim SE/AE on it and ran it. No problems. I'll just copy the output into the Linux environment. I'll still do some research on this unless someone familiar with the problem and has found a resolution chimes in. Multiple errors like this might be why it just aborted with no real reason. At least I can't find one in the logs. ========== I am going to review every step and reread everything twice to make sure I comprehend what I am reading. Also, in the past, STEP had explicitly stated not to use the x64 versions, even when running on 64-bit enabled systems, of LODGen and TexGen. Is this still the rule? Or has the x64 versions become more stable and responsive to use on 64-bit systems?

1920x1080. I had ENB on a previous STEP install. That was a while ago and it was while I was still on Windows. I am not expecting to achieve graphical greatness I had before, Not only has Skyrim and mods changed, Proton, WINE, DXVK and such have all added a layer of working code that probably doesn't allow for the headroom. I did notice a folder labeled "LinuxVersion" in the v0.493 ENBDev download... Maybe I need the the d3d11.dll from there to replace the version in the Wrapper folder? Lots of things to test and try.

Yeah. Linux is only beginning as a viable option I remember trying to get into Linux before Skyrim released. Things are much different now, and much better, getting better. I can play my Windows 95 and 98 era games in PCEM, DOSBox, XP and 7 era games, without issues. BUT things are starting to get a little tough in the emulation area, mainly it is my hardware. I just didn't keep up with the update cycle as I should have. Now I'll be buying a whole new rig once I get the money. Newer titles are starting to chug along. And it doesn't help that it all goes through a compatibility layer like WINE and Proton. So. As for display drivers, I have an alternate initramfs I can boot that can activate AMD's closed source drivers. I will be trying all my options. I am just bewildered that I used to have an A10-6800 APU from AMD that I did my first STEP install on a few years ago. It is fun. And a learning experience.

I will surely keep that in mind. I just jumped back in to see if there are other things I can use as I hit another snag. I got to the point where I run for the first time to benchmark and tweak with BethINI. I get on average 120-130 fps, make sure all the mods in previous steps that deal with ENB and post-processing are setup, run benchmark again with the milk drinker ENB ini and my performance tanks straight to 30. I am going to finish and just tweak what is installed and see if things improve. I already skimmed over a couple posts on improving ENB performance in Linux/Proton, so I am hopeful. If not, I'll just play without ENB and hopefully be on path to a new computer like I am planning. This thing is almost 8 years old!

That...definitely simplifies the process. I assume from your answer that any resolutions or tweaks are not dependent on each other at such a level the patches break completely. This is going to be great. Thank you for your time! I'll be on my way now.

Oh yeah. Forgot about that. I imagine I'll be putting my own twist on STEP once it is finalized and working. I did that before, I'll be doing it again. So, I will need the animations to work. Between our posts, I managed to get it working. The issue with Linux support is the vast array of installs and setups. However, with Arch Linux being as "no fluff" as possible when it comes to various distros, I am hoping the weird quirks I run into might be of use, agnostic of which distro anybody might be using. And since I'll be relying on Valve's Proton, it will simplify things even more. I did get the GoG version of Anniversary Edition, on sale, so my next chore will be to try and mod that setup, without Proton and see how it goes. I am keeping notes. While I am here, If you don't mind, when I was first playing with mods, I setup the Anniversary Content Picker. I found I really only liked 6 of the plugins I think. How difficult do you think it would be to divorce a chunk of those plugins from the STEP Conflict resolution and other patches?

So, XP32 doesn't require rebuilding animations? I thought it was required to make sure the skeleton animations worked.

You are right, my fault for not supplying more info on what was happening, or the error. My apologies. I think I had burnt out already resolving various issues along the way. I tried getting Skyrim and MO2 to work shortly after I moved to Linux and there was just so little info out there at the time. Now there is a lot. I may have seen that particular post, but like I said, I can only take so much googling and trying different things that my head just shuts off. Just trying to get NXM handler to work broke something else, which was un-borkable and I ended up just clean slating it and reinstalling Arch. Anyway. I will take a look and update if that is what makes the problems go away. I have to put in some work to get some money first. Since I am unemployed, doing surveys to get things i need. EDIT! Yes! Moustick, your googling seems better than mine, or at least I should have slept and tried this again. The resolution for now, seems to create a symbolic link to the actual Data folder of Skyrim. A test shows the engine updated and also rebuilt the animations. One step closer to a fully modded Skyrim on Linux! Unfortunately, more symlinks that aren't easily portable unless notes are kept or actions remembered. Something I was hoping to avoid. BUT this may be helpful info for both MO2 and Nemesis teams. Think anyone would be interested in a guide I write up on doing it? Replete with commands? It looks like a number of people having issues with these tools (not just for doing STEP) are the type to not use a console and just use the GUI provided by common distros. EDIT 2 And not quite so fast. Subsequent use brings back the same behaviors. More investigation required.

It sure has been a while since I have been here. A lot has changed and well, so have I. About around the time Cyberpunk 2077 came out, I stopped playing Skyrim. I kept up on the newses, mods and scene as much as possible, but I just didn't want to stop playing Cyberpunk just yet. About a year and half ago, I decided to ditch Windows and get on Linux. I had heard rumblings about Proton and the improvements made to WINE and other programs that made Linux a viable gaming platform, so making the switch was very appealing. I am also on a quest to learn as much as I can in order to take some Linux cert courses and improve my hire-ability and what jobs I can take. I did and do not dual-boot. I haven't touched Windows only in the last couple months when I wanted to make sure LibreOffice was really exporting my .odt documents to .docx and it all looked correct. Even then, that is in a virtual machine that I can get rid of by poking the delete button in KDE. I have been able to get almost every game in Steam, GoG and personal library that has grown since mid 90's to run and well, and I am quite content. So far, I have managed to get Mod Organizer 2 with SKSE64 and a few simple mods working with as far as I can tell, no issues. The problem is now S.T.E.P. I am following the latest 2.2.0 I think, and my only issue stopping me completely without tweaking the mod order is getting Nemesis Behavior Engine to work. I am assuming it is a replacement to FNIS. I haven't tried FNIS as I am wanting to follow this guide from beginning to end. NXM linking from Firefox into Mod Organizer2 works as intended. BethINI works correctly. xEdit works correctly. Wrye Bash, too. Until I can get Nemesis to work, I don't know about LODGen and such. Does anyone have any advice? Has someone gotten things to work on Linux just fine? The long workaround would be to import everything into a VM with Windows, run the tools that way and bring them back. Or create a bunch of symlinks and loose all sense of organization. My current specs: CPU: i5-6600K (stock) RAM: 16G, DDR4-2400, CL12 GFX: MSI Radeon RX 580X GAMING 8GB OS: Arch Linux (6.2.13-arch1-1) Desktop: Plasma 5.27.4 Window Manager: KWin If more info is needed, just let me know. I'll be tinkering until then and if I find the fix, I will update. I can also share what I have done so far to get things working so far, if others are interested. UPDATE: If you have a TL;Dr problem, the resolution (big thanks to Mousetick) is to create a symlink to the Data folder. For me, on Arch Linux, I entered in console: ln -s "/home/james/Games/steamapps/compatdata/489830/pfx/drive_c/Modding/MO2/mods/Nemesis Unlimited Behavior Engine/Nemesis_Engine/" "/home/james/Games/steamapps/common/Skyrim Special Edition/Data/Nemesis_Engine" Basically; ln -s "/path/to/Nemesis_Engine/" "path/to/Skyrim's/folder/Data/Nemesis_Engine" Your Linux build may differ slightly, but understanding what is happening can be found HERE and for Arch 'ln' man page HERE I am also tweaking the title of this post a bit AND may update this post with additional things as I run into them. If interest in a more detailed guide is requested, I may be inclined to do so. EDIT 2 And not quite so fast. Subsequent use brings back the same behaviors. More investigation required. Final Edit For my resolution, the symlink was fine. A Gremlin in the system was causing symlink issues. Something about an unused, but detrimental buidl requirement for another program, older version of "python-pathlib2" was causing issues. I removed the original symlink (and for some reason another link was made in the engine original directory) rebuilt it and now Nemesis Engine runs without issue as far as I can tell. The real test will be if the ice skating animations are not working as intended or everyone is in T-pose when I start the game next.

As of August 08 2020, this mod is hidden again.

I may just ignore the ability to use LOOT by now, I just cannot figure this out. How good is the LOOTcli within Mod Organizer?