prinyo

In response to post #57249476. #57250746 is also a reply to the same post. > "Vortex screen space usage is very inefficient" I was thinking the same looking at a screenshot of the plugins tab - all those white spaces that mean you need to scroll way more and you see less plugins at a glance (less plugins visible at the same time). My mind breaks with data been presented in such an inefficient way. Hope there is a "compact view". As Google offered when they inserted similar white spaces in the mail listing and people started complaining. Looking at the screenshots it seems that Vortex is targeted exclusively at casual users.

[edited] I didn't believe I can be more disappointed in Bethesda - no new IP, delayed FO4VR and showed a not very promising trailer about it, but this... If it turns out SkyrimVR is a PSVR exclusive ... very disappointing.

Whoa, hold on there, I don't remember electing you to represent everybody, and you certainly don't represent me. I'm confused now, after reading your next post. Do you want virtual install with links or not. My point was this. The MO crowd wants the new manager to use virtualization of "pure nature" with "pristinely clean" data folder as MO does it. The NMM crowd wants direct mod installs as NMM 0.5* does it. (Almost) nobody wants it to handle the mod installs as the current NMM versions do - a mix of the two ways. Now, I hate the virtual install with links and I believe that Talos himself can't create a mod manager that uses this way of installing mods that will not confuse me and that I would be able to use with pleasure. I, been a vocal NMM 0.5 fan on other forums for some time, recently started transitioning to MO with the idea to use it for the future games. The fact is the way MO deals with mods is easier to work with than the new NMM. That said, I, been a programmer myself, have a pretty good idea why Tannin is pushing for this kind of system and I realize that if I was in his shoes I would go ahead and implement it exactly the way I believe is right. This means that, as an user, I need to wait a month or two and see what happens. It seems there will be one mod manager able to handle Skyrim SE and we have no way of knowing what the response of community to this development will be.

Everything I said in my post was in regards to the concept and not the implementation. That's why at the start I gave an example with the type of problems I'm not going to discuss (the half-install thingy). I need to specify also that I'm talking about the experience of the more "advanced" users. For most of the players it doesn't really matter what happens in the background if everything works as they expect. What I'm talking about is the "tweaking" users. Many of those tweaking users will start by modding mods and can one day create and publish their own mod. Discouraging them is really not a good idea. And a very important point is that we are talking about the basic tool. The idea been that this tool will operate in a way that is easy to use and easy to understand. And would allow additional functionality to be "plugged-in" later. Also I would like to give an example that might sound strange at first, but the invention of the automobile didn't make the bicycles obsolete. Even if you develop different tools and modules for the advanced users lots of them can and will prefer to use the basic tool depending on their way of thinking and on what level of complexity makes them feel comfortable. So my point about the learning curve stays the same. If this basic tool uses the current NMM concept the learning curve will still be steeper than MO for the advances (tweaking) users. About the backup - I was talking about an outside-of-the-manager backup. A simple and universal backup that 98% of the users want to do - copy and paste. Not a backup that is tied to specific mod manager. <edit>I'm not talking about backup of the mods. I'm talking about a backup of the whole game, including the main game folder. Except mods that includes also cleaned .esm, ENB files + Settings, SKSE and whatever else is there.</edit> Also another thing when speaking about using a basic modding tool. For example - how do I switch between Skyrim and Enderal. There are 2 folders in my Steam directory - SkyrimEnd and SkyrimMain. Renaming one of them to Skyrim is everything I need to do in order to switch. This will be impossible to do with a linked virtual install as renaming the main Skyrim directory will immediately consume additional 50GB. Switching profiles - how long will it take to any linked virtual install based manager to remove/create all the needed links for mods like 3DNPC? Something that can be done in a second will now take quite some time. And it is also simpler. Yes, I understand how cool it is to drive a car, but I prefer the bike. After all we are talking about the basic modding tool here. On point 4 - I'm not really sure how this is different between linked VI and direct file install. In both case you need a manifest to know which files you need to restore. The way MO does it doesn't have this problem, but when you end up writing some kind of files in the data dir the problem will be the same. <edit>Also with direct install it is not necessary to always unzip the archives in order to find the file that needs to be restored. If for example there is a directory Overwritten then any file that will be overwritten can be moved there and then directly used.</edit> On point 2 - I completely agree that at the end it is the same. But it is not the same in the head of the user. That's why I was talking about the fact that the linked virtual install is confusing. Way too confusing for a base/basic modding tool. I do realize that my points are made by a person who "doesn't know better" and probably my bad experience with the implementation is influencing my understanding about the concept in was I can't appreciate. I simply wanted to share my experience in what it means to run a "basic" and an "confusingly virtual" tool. And I hope other users will do the same and add their experience.

This will only escalate with Skyrim SE. I have asked here on this forum if they would be willing to add support for it to NMM 0.56.1 but got only silence as an reply. The only good thing in this regard is that it will take some time before SKSE/SkyUI and other fundamental mods are available for it (as well as for FO4) and by then I guess the dust will settle and the big picture in regards to mod organizers will be more clear. Seems to me that the possibility that someone will fork NMM 0.56 and start working on updating it is getting more and more real.

That's what I was expecting after reading the posts here but then after reading on the STEP forum I realized this is not what they are actually planning to do.

Even if we assume that the problems that now exist with half-install and half-removing of mods leaving stray files in the data directory are caused by old and un-optimized code, there are still enough reasons that turn such a system into a nightmare for the advanced users and are now forcing them to use 0.56.1 as the last version of NMM that is actually usable. And those reasons have nothing to do with the quality of the software itself but the problems the concept of linked virtual install creates. Having the files in one place is logical and easy to work with (like MO and the old NMM), having ghosts of files in more places makes the experience quite limiting, confusing and annoying. 1. Backups - it is not possible to make an usable backup independently of the manager. What do you copy - the files in the data folder or the files in the VirtualInstall? Or both? Whatever you do there is no meaningful way to use such a backup. You are forced to make a copy of the two as this is the only way to use it and that means - 2 times longer do make/apply the backup, 2 times more space for the backup, 2 directories to backup instead of one and most importantly - twice the size of the game folder after the backup is used. This is a huge deal as most players put those games on small SSD drives. If you have 50GB of mods and want to use a backup then your game will now consume a total of 100GB. And even if the drive space is not a big problem, having several games inflated like that is not really acceptable. Because yes - when you install a mod and create links for all the files then you are not using twice the space - you have one and same file with two different addresses. So 1k file in data = 1k file in VI = 1k total. But when you copy the files and put them somewhere else the bond will break and you will end up with two independent "real" files. And yes - you need to make and use a backup of both data and VI folders. If you only use the data folder the game will work but the mod manager will become useless. If you only use a backup of the VI then there will be no mods in the game... So you are forced to endure the double backup and inflated drive space usage. 2. Freedom, predictability and flexibility (and way less chaos) - it is surprisingly easy to break the link and end up with two different files. This limits your possibility to reuse self-modified mod assets on a new install, create confusion when you edit a file that you don't immediately realize is not tied to it's counterpart anymore, forcing you to constantly think about which files are tied and which not and which copy you are editing. The "schizophrenic" state an install like this exists in is extremely confusing and adds way more complications than it is worth. 3. Learning curve. It is been mentioned many time on the forums that the learning curve for NMM 0.6* is steeper than MO. And it is true. Introducing this to the "basic" variation of the software seems strange. 4. For what? People would probably accept all this complications and problems if the would see the benefit such a system brings. However there is none. The predictability, usability and stability of the "one file" install logic is sacrificed for what... For profiles? Let's be honest, everybody who wanted profiles was already using MO. Now if you want to create the basic modding tool and with options to add modules and upgrade, are there Profiles in that very basic tool? There is no "greater good" here. It is complication for the sake of the complication. None of the potential benefits of the virtualization are realized by the linked virtual install, only the negatives. I would suggest starting a new thread about this and letting all people that still use the old NMM versions tell their reasons. Because I'm pretty sure none of them would be using this new manager if uses the same logic that made them stay away from the new versions anyway. I understand from the point of view of the MO crowd the phrase "advanced NMM users" is an oxymoron, but in reality there are advanced users who have experience in both pre- and after- 0.6 NMM.

This sounded really good until I read the comments on the STEP forum where there is this: "The default setting will probably work similar to what NMM is doing currently, using symlinks or hardlinks into the game directory because this is simply more robust " This is bad news. This is exactly what nobody wants. This is exactly what people want to get rid of. When people talk about "the way NMM works" they mean pre-0.6. If the new manager uses the current NMM logic then everybody loses. It was obvious that the choices you make about this will upset one of the two crowds. But upsetting both of them at the same time... hmm

Well, it is obvious the first and probably most important decision they need to make is the hardest - what system for mod install to use. And there is no correct answer it seems as whatever they do there will be a vocal opposition. On one hand you have people who want "a clean data directory", "mod isolation" and virtualization. And there are those who want it to work the way NMM used to work before 0.6 was introduced. I guess nobody wants it to work the way NMM works now - with the virtual install and the symlinks. They can probably do those 2 things with no problems. Make the base manager install mods directly and provide a module that would change that to some sort of virtualization. If instead they choose one of those paths there will be an outcry. It seems there is simply no correct answer to this except in providing a switch.

From what I understand the VRAM cap for DX9 applications is added by Microsoft, not by any of the GPU manufacturers. But it only affects DX9 games. It is expected the Skyrim RE to be DX11 so there will be no limit anymore. This is what the tool provided by the author of ENB shows on my PC. First window - Skyrim now, second window - expected Skyrim RE. To make things easier, I think we can agree that Skyrim faces 2 different limitations: - RAM - been a 32bit app it can't consume more that 3.1GB of RAM - VRAM - been a DX9 app it faces a 4GB VRAM limit, arbitrarily added for unknown (or no) reason Those two are completely unrelated to each-other. (This is what the thread on the Nvidia forum is mostly about). Also as the game puts it's eggs in two baskets - the meshes and textures are duplicated in RAM and VRAM, removing one of those limits will not help much. The confusion seems to start when ENB Boos is added to the picture. Been an independent process that has it's own caps my logic says that the total limit for RAM and VRAM for the ENB+Skyrim combo should be greatly increased. Also what I've seen in my game is that the reported memory usage of Skyrim itself is 2 times less with ENB Boost running, which led me to believe that the rest is "outsourced" to the ENB. However judging by the fact that the author of ENB complained about the VRAM limit on the Nvidia forum and some people reporting problems when they hit 4GB it seems the VRAM cap is not increased. Again there are lot's of points of view about how it works and why. The way I understand is that ENB Boost can provide RAM, but not VRAM and this is where I was wrong in my previous post. When Skyrim consumes it's 4GB of VRAM it will continue to expand into "fake" VRAM - as in RAM that ENB provides under the disguise of VRAM. But as the RAM is not fast enough graphic problems start to appear in the game. It will not crash, but there would be problems. So it seems I was wrong - ENB Boost can help the game not crash when it reaches any of the two limits, but it will not help it use more than 4GB of VRAM regardless of how much you have.

It would be really great if somebody explains all this in terms more people can understand, including myself. The thread you point to has all the problems I was talking about - it is toxic, it is way too technical when it is on point and everybody seems to have their own idea about how things work. This last problem is actualy the most serious for me in trying to understand what is going on. STEP explains this: http://wiki.step-project.com/Guide:ENB AMong other things it says: "This means that although TESV.exe can only use a maximum of 2GB of system RAM on 32-bit Windows systems, it can access up to about 3.1GB of system RAM (4GB - about 900MB of system resources) on 64-bit systems. To drive the video card in displaying Skyrim's 3D rendered graphics, TESV.exe must store object geometry (the shapes of things in the game) and texture data cached in its memory space, which is then copied to your video card's VRAM to display." Hence my understanding that because the meshes and textures are duplicated even if there is no limit on the VRAM the game will still crash because of the RAM limit. Further STEP explains that "ENBoost overcomes this memory limitation by ... using available VRAM on your video card " And also " The effectiveness and performance of ENBoost is determined by a number of factors, such as size of system RAM / VRAM" This seems to imply that with ENB Boost you can actually use the additional VRAM that you have if you have it. Or not? At the end my understanding is that ENB Boost works by reserving VRAM and RAM for itself and then "providing it" to the game. So I would image running it does in fact help Skyrim use more of the VRAM you have than it would have used without it. In other words, it changes the VRAM cap. No for Skyrim itself, but for the Skyrim-ENBBoost combo which for the player means more RAM and VRAM available. Again, this is based on my lamers understanding after reading quite a lot of threads and reddit posts. If I'm wrong I would really appreciate any corrections.

I might be (and probably am) completely wrong but I was under the impression that Skyrim keeps the textures in both RAM and VRAM. So you can't really use all the VRAM if the game crashes at 3.1GB anyway (both RAM and VRAM limits will kill it). I've read a lot about this and tried to understand as much as possible with my limited understanding and the only thing I understood is that it is not possible to change the limitations and the only practical solution is to optimize the memory usage of the game - what ENB Boost does. I've been trying to read and try to understand more about all this graphic setup stuff, but it is not easy because all the forums about it are full with people who shout at each other and the technical discussion is always in the shadows of everyone trying to explain to everybody else how stupid they are. It doesn't help that different people have different understanding about how things work.

So many posts and no one points to the solution/workaround. ENB Boost (correctly configured) from http://enbdev.com/ It will not allow the game to use more memory, instead it makes Skyrim use two times less memory. Under Win 10 the game in fact crashes when it reaches 3.1GB of memory usage. And it is really easy to reach it. The second part of this video helps with the configuration:

Are there any news about this? Any, no matter how small? After seeing the GTA room-scale VR mod it drives me crazy there is nothing even similar for Skyrim/FO4. I'm willing to help and experiment as much as I can.

Actually if you are serious about modding - NMM 0.56 or installing by hand. The paradigm of MO is wrong as it makes you think about modding the game in terms of arbitrary file "packets" - mods. The misguided ideal about a "clean" data directory sounds interesting and I can see how it can be sold to people. But it is a bad way to organize the user's workflow. Having all the files in the data directory makes you think about modding the game in terms of the game itself and the files it will see and use. If I see an outfit I want to change I don't need to find the mod that adds it in order to edit it. I just open the file and change it. That's just a simple example. Also to all condescending MO evangelists who continue to pollute threads all over the internet - if you read the forums here you will see that most people who actually use NMM want the return of the old system and not more virtualization. I'm glad you have found your perfect mod manager, now stop insulting everybody else and let us be. Thanks!