Jump to content

ousnius

Premium Member
  • Posts

    251
  • Joined

  • Last visited

Posts posted by ousnius

  1. As BodySlide was updated, the shaders and more were improved, so what it looks like now is roughly what the skin texture should be.

    In FO4, the skin textures are generally a little darker.

     

    But yes, there's nothing wrong about that here.

    You could increase the brightness in Outfit Studio, but that's not recommended, because then the bright outfits will become even more bright than they should be.

  2. After reading 11 pages I still don't understand:

     

    90% of nexus users are fools and they can't manually sort the plugins. Then need to limit their ability.

    Or

    90% of nexus users are advanced users and they can write rules for LOOT. Then why limit their ability?

     

    I'm in confusion.

     

    Once you accept it and know how to work with it, rules of Vortex are the best for both worlds.

  3. Vortex has a concept of "mod types" and it can handle different mod types differently.

    E.g. enb is not a planned feature, it's technically already in there. If Vortex recognizes a mod as an enb then it will install it to the game root directory alongside the exe, not to data.

    Same is true for mods that rely on hooking dinput8.dll.

     

    That's a large "if" though, currently the detection of what's an enb mod is fairly dumb, iirc it requires the mod to contain an enbseries.ini file.

     

    It might be "dumb", but I can't think of a single ENB preset without an enbseries.ini file. So it should work rather well.

  4.  

    I have 'This profile has it's own game settings' selected in the 'Edit' options under each profile if that makes a difference. Then when viewing the vortex folder in appdata I see a copy of the ini files in each profiles folder. Apologies if i'm mistaken, I just hoped this meant vortex handled seperate ini files for each profile?

    Interesting, I didn't know of that. Well, you can still deploy your profile and then edit the .ini files in your documents\my games folder.

    Since Vortex uses hardlinks, they will be the same file. When you want to edit the other profile's inis, deploy that profile again instead.

     

    They're profile specific in that they're swapped out once you swap your profile inside Vortex, which is really all that matters.

    As for Windows users, your documents folder is already user-based.

  5. If this is actually true that there's no manual means of adjusting load order, Vortex will be one of the most user UNfriendly things made for modding in the last 15 years.

     

    As even the LOOT developers are likely to tell you, LOOT is only the beginning of load order, not the end. Demanding that everyone write their own rules to bypass bad sorts is never going to be widely accepted.

     

    The same holds true for Vortex. It uses LOOT as a base to get a mostly working order for you automatically, and then you can go in and apply your own rules and priority numbers to affect or override what LOOT is doing.

    It's not a drag and drop like in NMM or MO, but it nevertheless allow for the same (actually even more) amount of customization. It's different and takes getting used to of course.

  6. Nonsense. Visually arranging the plugins offer an immediate and direct indication of how they will go. There's no ease of use added anywhere.

     

    The counter argument is that you don't need to know where they will go, other than adding rules or merging a few you know have conflicts that LOOT doesn't detect.

    But yes, Vortex needs more visual indicators.

  7.  

    I find myself rather amused by the fact that I told Vortex to check FO4 mods for updates and it's claiming a mod I know damn well is the most current version is out of date...

     

    ...It's MY MOD. Heh...

    Yeah, it is doing similar things for me.

     

    Which mod, does the version number follow semantic standards? (1.2.4 etc.)

    Is the file vs mod page version/main file correct? Did you install it from the Nexus or manually via archive?

  8. Not that it's going to matter, or convince anyone, but it's NOT actually putting anything in the Data folder that Steam didn't put there, or the user manually - it just LOOKS like it is.

     

    As a test to determine how deployment functioned, I made a small edit to a texture file that I knew was going to be overwritten in the Data folder, to see if it would be reverted after undeploying the overwriting mod. In actuality, the edit was made to the file in the Vortex mod folder. Although in file explorer it looks like the file is in the Data folder, you're actually accessing the file in the mod folder.

     

    If that makes any more sense...

     

    EDIT: Just thought of a better way to characterize it:

     

    Essentially, with mods deployed, when you open a file explorer to the Data folder, you're not actually seeing the Data folder, you're seeing MO's vfs.

     

    There's an exception for that with certain tools like xEdit or Photoshop, because they actually rename files back and forth instead of straight up replacing the old file you're saving over, which breaks up the hard link.

    However, Vortex will see this and merge it back into its own folder or ask to do so.

  9. To answer the question as to why I need precise positioning of a mod in the load order -

     

    When I'm testing a mod, for some tests I prepare bat files (this is Skyrim/SSE) to execute some of the tests so that I can perform exactly the same tests repeatably after changing things (regression testing). They need to reference specific records in specific plugins and to do that, I have to hard-code the FormIds into the bat files. The command language is very limited and it doesn't allow variables or indirection - everything has to be explicit. That means hard-coding a specific load order position for the target plugin that contains the target form because load order is the top byte of the FormId. So before running the test, I need to ensure that specific plugins are in the right place in the load order. Not relative to other mods, but absolute position as seen in-game by the game engine.

     

    Not many people do those kinds of tests, so not many people need to do absolute positioning. It so happens that NMM makes it easy to do (because drag and drop) but Vortex doesn't (because it doesn't think that way) so for me, NMM is more useful than Vortex.

     

    Vortex wasn't designed for me. But that's not intended to be a criticism of Vortex, which for nearly everybody else is going to be a great tool, it just means I'm out of step.

     

    You can turn off auto-sorting of plugins in Vortex, and run your batch scripts after you installed all mods.

    The plugins.txt and loadorder.txt files still exist.

  10. I have 'This profile has it's own game settings' selected in the 'Edit' options under each profile if that makes a difference. Then when viewing the vortex folder in appdata I see a copy of the ini files in each profiles folder. Apologies if i'm mistaken, I just hoped this meant vortex handled seperate ini files for each profile?

    Interesting, I didn't know of that. Well, you can still deploy your profile and then edit the .ini files in your documents\my games folder.

    Since Vortex uses hardlinks, they will be the same file. When you want to edit the other profile's inis, deploy that profile again instead.

  11. I can't speak for the OP on this, but for me I NEED precise plugin placement, because having to stop development just to rewrite rules for the mod to get placed where I want it, rather than just dragging it to the position I want to test, not only completely breaks my thought process but also wastes a considerable amount of time over the course of development. In other words it is unduly cumbersome and restrictive.

     

    Why do you need to move your plugin order around to test your mods?

    You said you need it at specific positions to test, but what's the technical reason for that?

     

    You can temporarily force a global priority to the plugin, if you need it to be at the end always for testing purposes.

    I'm not sure why would need to test intentionally breaking your mod by putting it above conflicting other plugins.

     

    What I do agree on is the visual representation of both the mod and plugin order.

    The result of what all your rules and priorities come down to isn't clear enough to me yet.

  12. So my question with this is, how do you do this with say mod a which is at the top of the load order, and mod b which is in the middle and mod c which is at the end. c depends on b which depends on a. when you have 200+ mods and it wont allow you to scroll up or down when you are trying to link dependencies this is an issue.

     

    You don't need to drag a line all across the list. When there's a file conflict, Vortex will know and you can click the lightning bolt icon on either of the mods (a single left click).

    Then you can set the rule in the dialog.

     

    Unless you're talking about mods that don't have a physical conflict, of course. But those should be very rare or basically non-existent.

    If there's no conflict, you don't need to set any order or rule, as the order doesn't matter then.

     

    As for plugins, you can use the dependency manager in the toolbar of the plugins tab.

  13.  

    The choice of which files are deployed is done at the time of deployment. Vortex decides what to put in the data folder based on what's in the mod folder and the order it's been given using dependencies.

     

    If you don't want a particular file from a particular mod, you will need to manually change the file extension or delete the file in the mod folder. Here is where the "open in file manager" from my first post comes in handy :smile:

    Okay, got it, thanks. In an extreme case, it will be like manually installing mods, except into the mod folder instead of directly into the game's data folder, prior to deferred deployment. So it's do-able.

     

    I'm just a bit worried about explaining that to my users. You see, I have a popular mod that contains an embedded version (3.3) of a particular SKSE plugin, and SKSE plugins have to be loose files. There's another popular mod (not by me) that has a similarly embedded copy of the same plugin but it's an older mod that is no longer under development and it contains an older version (3.2) of the plugin. Using both mods together is popular and indeed you get extra in-game goodies if you have both installed. But my mod doesn't work properly with V3.2 of the SKSE plugin, it has to be V3.3. So the loose file from my mod has to overwrite the loose file from the other mod, regardless of which order they are installed. If we were doing manual installs, I would simply tell my users they must install my mod after the other one, and re-install it last if necessary. I'm wondering, what corresponding instructions can I post for users of Vortex?

     

    If the SKSE plugin has the same file name, Vortex will show a notification at the top right saying that "there are conflicting files".

     

    The user has to click on the lightning icon of your mod in the mods tab, which will bring up the conflict resolution menu.

    There, tell people to have your mod load after the other mod with the older plugin as seen in Thallassa's screenshots.

  14. In response to post #56081601. #56081651, #56083286 are all replies on the same post.


    Moksha8088 wrote: Will this proposed recognition be for new mods only or will it extend to established mods? It would be nice to see mod authors receive more than simple praise. Their labors have given us joy and keep us coming back to this site.
    Dark0ne wrote: Mod authors can opt-in old or new mods alike at their own discretion, but they will not receive Donation Points retrospectively e.g. for unique downloads they've accumulated before the month they opt-in. Hopefully for obvious reasons!
    Moksha8088 wrote: Too bad it cannot reward the mods that most of us use since we have already downloaded and endorsed them long ago and will remain on our systems for future playthroughs.

    Will authors benefit from updating their mods?


    Yes, as that counts for a new unique download in the respective month.
    EDIT: I got told I was wrong, it's only for new unique downloads total, not in the current month.
  15. In response to post #56081996. #56082276 is also a reply to the same post.


    JimmyRJump wrote: I like the overall concept, although for SSE this could prove a bit of a hornet's nest with a lot of "modders" adapting restrictionless Skyrim2011 mods for the SE version.

    What I'd like to know is if folk willing to donate to the pool will be able to do so on an automated basis for a fix amount per month, like the recurring fee paid for Supporter/Premium status?
    nesbit098 wrote: Interesting point of view....


    The opt-in will be off by default for each mod page. That means, people won't be allowed to make "points" off of porting SSE mods, unless the author specifically enables the permissions option for it.
  16. In response to post #56081816.


    literallybyronic wrote: I feel like this may cause a bit of strife in mod authors who do large mods or compilations. For instance, my most popular mod is NPC replacers and presets for now going on 11 characters, but they are installed via a FOMOD which is one file on one mod page that lets you pick and choose who you want to install. It's far easier for mod users to use that way but with this points system it actually hurts me to do it that way when I could make a separate mod page for each character and potentially get up to 11 unique downloads from the same user instead of one. This wouldn't really fall under the "milking the patch from a separate page" idea since I'd say at least half of the current NPC replacer mod library on Nexus are single characters so you couldn't really fault someone for releasing them as such. Not just in my own situation either, but let's say the author of Beantown Interiors decided to release their work neighbourhood by neighbourhood instead of an all in one, or like Vivid Landscapes is an AIO now, when they used to be separate downloads for terrain, foliage, roads, etc. Even if these mods were divvied up into categorized segments they would still each be standalone mods in their own right. so not really the same as making a small patch its own page. I don't really know what the best way to deal with this would be tbh but I have a feeling it's going to ruffle some feathers no matter what.


    Each character individually doesn't necessarily give you more total unique downloads , unless you have thousands of fans that download all of your mods, or all of them get into hot files, in which case it's a good thing for you.
  17. There was no update. It's merely a change to the Steam manifest file, 1 KB.

    Even if there were an update, you can simply backup your old executable and put it back after the update, in case it would have changed the file.

  18. In response to post #54930308. #54930478, #54930773, #54930833, #54930843, #54930848, #54930913, #54931018, #54931133, #54931298, #54931363, #54931473, #54931588 are all replies on the same post.


    Kevin843 wrote: Like I said before no REAL virtual data=no using Vortex, I dont want my data folder messed up and ability to reorder mods is what makes MO2 the best mod manager. I am disappointed it is highly anticipated it will not have a virtual data like MO2. Hopefully there will still be community builds of MO2 for future Bethesda games. No way I can go back to installing mods to data folder now. I wont even bother using it if it dosent have these "Essential" MO2 features.
    Zora wrote: I agree, not using a virtual file system is a step-back from what could be a huge improvement to mod managers we've seen so far. I still have high hopes for Vortex and will probably use it either way.
    SarahTheMascara wrote: I agree. Keeping the data folder clean is essential for me as well. I have so many different builds for Skyrim and I'm jumping back and forth between profiles regularly.
    BlueGunk wrote: From the interview with Tannin, 10 May 2017:

    Robin: I think we both know the biggest questions we've received around Vortex have been in regards to virtualisation and how Vortex will handle and store files on people's hard-drives. Is Vortex going to use virtualisation?

    Tannin: Yes it does.

    I know people have - often very strong - opinions on the topic so I ask that you please read my reasons before you go to the comments and vent.

    In the initial release of Vortex, virtualisation will be implemented using links (symbolic or hard links), similar to NMM v0.6. We've left the door open so we can implement different approaches (i.e. the usvfs library from Mod Organizer) but at this point I don't think there will be a "no virtualisation" option.
    Dark0ne wrote: Thanks for your feedback.

    If you're not interested in a mod manager that doesn't use MO's functionality VFS, that's fine. But this is about Vortex, not MO.

    I'll be deleting any more comments that follow this line of thought as it's completely irrelevant to what I've talked about in this news article.
    Yggdrasil7557 wrote: There are many reasons for this, Tannin is the original developer of mod organizer, and he was one of the people who decided not to use virtual filing. the new program will feature mod managing methods similar to how mod organizer currently works, the file managing will be able to work in many the same ways that mo does, the only difference is that it will actually place the files in the correct locations, this is for the same reason that el presidente gave up on mo2, the crashes due to virtual filing, especially in 64 bit are far too complex. for more info go read all previous posts about vortex, including the post where tannin said he was discontinuing development of mo1
    Valyn81 wrote:
    Remember that it is not the same thing as the old NMM did, corrupting your data folder easily.

    TanninOne is helping them make the new Vortex, so you know Vortex will have some aspect of MO2 in order to help minimize data folder corruption.

    *EDIT*
    Seems BlueGunk, Yggdrasil7557, and I all have the same thought at about the same time, lol.

    :wub:

     

    Here is the link to help the people with Facts about Vortex and its Virtualization:
    https://www.nexusmods.com/skyrim/news/13257/?

    Qrygg wrote: I'm confused... where does it say there will be no virtualization?
    Dark0ne wrote:
    I'm confused... where does it say there will be no virtualization?


    They're getting confused (which is kind of telling), there is virtualisation, it's just not the same as MO's virtualisation, which is what they are actually taking issue with.

    We already did a Q&A with Tannin where it was explained why Tannin had decided to choose a different method, so the fact this needs to be brought up in a different news article about a different topic is...odd...to say the least.

    If not using MO's virtualisation is a "no deal" for you, I just don't really understand why you're here, posting it as a comment in a completely unrelated article about Vortex.
    Ethreon wrote: You expect rando user who doesn't know what's in his data folder to remember previous discussions?
    Valyn81 wrote: *Delete this comment, content moved to my first reply.*
    AnyOldName3 wrote: Mod Organizer 2 doesn't seem to actually be abandoned anymore. There were commits today, for example, which doesn't suggest to me that it's abandoned.
    Valyn81 wrote: They said MO1 not MO2.

    *Replying from the forum is annoying*


    A clean data folder is really not an argument for using or not using Vortex. It really isn't.

    You're saying you're switching profiles all the time, but these are all things that are still possible (just as easily and quickly) as with NMM or MO. Just instead of doing it at runtime, the hard links are handling it within seconds. This was all explained in the previous news post already.
  19. Your graphics card supports the latest versions of the program.

    Even a GT 120 supports it.

     

    You're either missing the latest graphics drivers from NVIDIA, or you're not running the program with the dedicated graphics.

    Read up on how to run programs with the dedicated instead of the integrated graphics chip.

  20. The flex system they integrated into FO4 is only exposed for shooting stuff into the ground.

    You can't use it for other game effects or assign it to other actions in the engine - what you can do is change the meshes (.nif files) used and some randomization parameters in the .txt file that's located in the game folder.

×
×
  • Create New...