Starfield Extension has been updated to v0.5.7

[insomnious]

Thank you to everyone who's helped test version 0.5 of the extension over the past few weeks. It's a big foundational update that does help to simplify things moving forward. We have reached a point where we are happy enough to get it out there for users to start putting it through it's paces.

This extension requires Vortex 1.9 or greater.

To install, click the Vortex button at the top of the Starfield Extension page on Nexus Mods, and then click Install.

You can also manually install it by downloading the main file and dragging it into the drop target labelled Drop File(s) in the Extensions page at the bottom right.

The key benefits to this version are:

• Mod authors no longer need to use mod manager specific instructions as Vortex will follow the pre-established pattern of deploying FOMODs to the data folder by default.
• Mods installation logic now use stop patterns.
• Fix for Cater for mods that have redundant top-level folders
• Added migration logic to seamlessly migrate 0.4 users to the new 0.5 stop patterns installation functionality.

There are some really important known issues:

• 0.5 has introduced a new modType system which is used to define where the mods are deployed. Unfortunately you may be faced with a longstanding bug in Vortex which cannot detect file conflicts between mod types (this is currently being worked on). If you're encountering the "External Changes Dialog" during EVERY deployment event, you're most likely affected by this bug. There are a few things you can try to fix it:
  • Make sure to always select "revert all" in the changes dialog to maintain the mod files as the mod author intended.
  • Re-install your mods - this will ensure that all of your mods are using the new modType system and should ensure that modType conflicts do not occur.
  • If all of your mods are using the new modType system and the external changes dialog is still popping up - that means you have one or several mods that are deploying the same files as another mod which is assigned to the data folder. Compare the Vortex deployment JSON files which are found inside the game's root path and 'Data' path to note any conflicting files and their respective mods. Enabling/disabling/modifying the mod inside the staging folder will resolve the conflict.
• Mods installed with 0.4 should still function as they previously did. If for any reason you suspect the mod has missing files, simply re-install it and the new installation logic will ensure that the mod is installed correctly.
• Collections that were created before 0.5 will still function correctly on both 0.4 and 0.5; however any collections created in 0.5 are not necessarily backwards compatible with 0.4 and could potentially result in a broken mod setup, especially if the mods included in the collection are known to cause issues in 0.4.
• Although not necessary if you're happy with your current mod setup, it is highly advisable for 0.5 users to re-install all of their mods to ensure that the new mod type system kicks in.

We are always looking for users to help out and the next update (version 0.6) is being tested internally as we speak. This update will bring Load Order/plugins.txt support and will be available to testers on Mon 4th Dec.

Happy modding!

insomnious

Full Changelog

• Modified stop patterns to install known injector type assemblies to the game's root folder
• Improved the stop patterns to deploy INI and TXT files to root (also executables!)
• Starfield notifications now dismissed on game mode change
• Added migration capabilities for collections created with 0.4
• Added missing "sound" stop pattern
• Improved junction suppression/my games notification flow
• Fix for Add a notification for when Data folder exists in My Games
• Fix for SFSE installer false positives
• Improved invalid FOMOD detection
• FOMOD install check will now only run for data folder ModType.
• Added a notification specifying the changes in the extension to the users.
• Mods installation logic now use stop patterns.
• Fix for Cater for mods that have redundant top-level folders
• Removed deprecated starfield installer.
• Added Data folder modType to support the new installation logic.
• Added check for incorrectly installed FOMODs.
• Added migration logic to seamlessly migrate 0.4 users to the new 0.5 stop patterns installation functionality.

[VirtualChrisM]

Hi, I just started up Vortex and it must have auto updated to this version.... (which is a separate issue)...

I got the message that "Some mods are redundant" and clicking show, lists every mod I have!

What's going on here?  How do I resolve this?

What's worse, is that a lot of my mods seem to have been uninstalled from the data folder but are still showing as "Enabled" in Vortex.  FFS!

EDIT: I can't disable and enable the mods to get them to re-install... what the actual f*#@?!

EDIT2: All my mods have to uninstalled, and then re-installed. That's over 100 mods. What the hell man?! I can't imagine a more trash update to put out there.

Edited December 5, 2023 by VirtualChrisM

[TennesseeTuxedo]

I just installed the latest Starfield extension and Vortex appears to now be putting .esm files into the main Starfield folder instead of Starfield/Data.  I recreated it just disabling and re-enabling a mod.  I can workaround it by copying the .esms, I have not seen what it might do to other files such as textures.  Is there a configuration for this path in Vortex or the extension?  I can't find it.

[VirtualChrisM]

2 minutes ago, TennesseeTuxedo said:

I just installed the latest Starfield extension and Vortex appears to now be putting .esm files into the main Starfield folder instead of Starfield/Data.  I recreated it just disabling and re-enabling a mod.  I can workaround it by copying the .esms, I have not seen what it might do to other files such as textures.  Is there a configuration for this path in Vortex or the extension?  I can't find it.

Seems you're having a different issue from me.  My mods are no where... Not even in the wrong directory... simply uninstalled.  And I have to select "Uninstall" form Vortex, and then "Enable" to put them back. One at a frickin time... times 100 mods!  Who ever put this out there needs a serious flogging.

[Nagev]

5 hours ago, TennesseeTuxedo said:

I just installed the latest Starfield extension and Vortex appears to now be putting .esm files into the main Starfield folder instead of Starfield/Data.  I recreated it just disabling and re-enabling a mod.  I can workaround it by copying the .esms, I have not seen what it might do to other files such as textures.  Is there a configuration for this path in Vortex or the extension?  I can't find it.

Simply re-install the mods that are affected and it should deploy them to "Data" can you let us know which mod/s are causing this on your end?

6 hours ago, VirtualChrisM said:

Hi, I just started up Vortex and it must have auto updated to this version.... (which is a separate issue)...

I got the message that "Some mods are redundant" and clicking show, lists every mod I have!

What's going on here?  How do I resolve this?

What's worse, is that a lot of my mods seem to have been uninstalled from the data folder but are still showing as "Enabled" in Vortex.  FFS!

EDIT: I can't disable and enable the mods to get them to re-install... what the actual f*#@?!

EDIT2: All my mods have to uninstalled, and then re-installed. That's over 100 mods. What the hell man?! I can't imagine a more trash update to put out there.

The only way that would be remotely possible is if you had your Vortex staging folder inside your game's directory or some other weird environment setup. There's a good reason why Vortex has mechanisms in place to prevent users from doing that. Alternatively Vortex may have tried to warn you about external changes due to a fault in the migration and you chose to save all changes, which would've indeed removed the mod files. Perhaps I would've been more interested to investigate your issue had you been more respectful - something to keep in mind for next time.

5 hours ago, VirtualChrisM said:

Seems you're having a different issue from me.  My mods are no where... Not even in the wrong directory... simply uninstalled.  And I have to select "Uninstall" form Vortex, and then "Enable" to put them back. One at a frickin time... times 100 mods!  Who ever put this out there needs a serious flogging.

You can select all of your mods by clicking "ctrl + a" and then use the bottom toolbar to uninstall/reinstall them all in one click.

[VirtualChrisM]

I don’t know what happened, but I launched Vortex, it auto updated, and then flagged 90% of my 100 mods as redundant, and uninstalled them all.. Texture mods, ESM mods, CCR mods, and even SFSE and other DLL mods. WTF?!  My install is nothing unusual… everything is in the mod staging folder structure (not in the game folder structure at all) and has been working flawlessly until now. I couldn’t just enable the mods, which appeared to work, because it wasn’t actually moving files… I had to uninstall, and restore that way, which leads me to believe the mod staging area was also wiped.

I lost a lot of time tonight because this release clearly wasn’t tested and you’re lecturing me about respect. How about respect for people’s time and not publishing game breaking updates that creates a huge mess to clean up?

Edited December 5, 2023 by VirtualChrisM

[Pickysaurus]

@VirtualChrisMI'm sorry you're having issues, but you have to realise this problem is unique to your setup. We do thoroughly test extensions before they go live and this did not happen in any test case. 

As Nagev said, you may have misconfigured Vortex. Did you put your mod staging folder for Starfield in the same folder you installed Vortex to? If so, this would have been completely erased when updating Vortex. There are safeguards in the app to prevent this but if this is what happened you managed to get around it somehow. 

 

To be clear if Vortex was installed to "C:\Program Files\Black Tree Gaming Ltd\Vortex" and your staging folder for Starfield was at something like "C:\Program Files\Black Tree Gaming Ltd\Vortex\starfield" the entire "Vortex" folder gets removed and replaced during an update to the core application (not an extension update).

Edited December 5, 2023 by Pickysaurus
Providing an example for clarity.

[1997riccardo]

Hey, i can't make this extension work, at launch it says "Preparing game for modding" but after a bunch of seconds it gave me an error "Unhandled exception in extension".

The error detail are this:
"Error: Maximum call stack size exceeded
    at walk (G:\Gaming\Programmi Gaming\Vortex\resources\app.asar\node_modules\turbowalk\index.js:20:22)
    at C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:1489:39
    at Promise.cancellationExecute [as _execute] (G:\Gaming\Programmi Gaming\Vortex\resources\app.asar\node_modules\bluebird\js\release\debuggability.js:406:9)
    at Promise._resolveFromExecutor (G:\Gaming\Programmi Gaming\Vortex\resources\app.asar\node_modules\bluebird\js\release\promise.js:518:18)
    at new Promise (G:\Gaming\Programmi Gaming\Vortex\resources\app.asar\node_modules\bluebird\js\release\promise.js:103:10)
    at walkPath (C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:1488:12)
    at nuclearPurge (C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:1509:27)
    at migrate050 (C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:861:39)
    at migrateExtension (C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:852:15)
    at async setup (C:\Users\cricc\AppData\Roaming\Vortex\plugins\Vortex Extension Update - Starfield Vortex Extension v0.5.7\index.js:977:5)"

[Akopian]

I want to see if I have translated the new structure so far.   Instead of a staging folder for a mod needing a data folder at its top level (if it changes anything in the data folder or its subfolders) you can now change the type of file to mod type: Data folder and that will directly deploy the files to the data folder.  Is that correct?

And old mods using the old system still can have the data folder so long as they are not mod type Data folder?  I, for instance, would go back and make sure that if a mod was supposed to be installed in a data folder that it had in the staging folder for the mod a "data" folder if it did not have one already, and put the files that were supposed to be installed to the data folder inside the corresponding folder in the staging folder's data folder.  I will no longer need to do that if a mod is designated a mod type: Data.  In fact, if I did add a data folder, then after deployment I would have in the actual game "data" folder an extra but useless "data" folder, correct?

Sometimes though, mod authors compress their mod creation file and name the zip file.  So you might have MODA.zip and instead of the first folder being data, it might be MODA and then inside that folder would be the "Data" folder.  This caused problems.  I always solved that by moving the data file to the first folder file and deleting in this example the MODA file.  Now I will no longer need to move the data folder because Vortex will do that on its own, correct?

Now for a new issue since I know where to ask this:  Sometimes mod authors have lots of ba2 files with lots of esm files that reflect how they have broken up their texture projects.  I found that I could use a single esm file if I loaded a blank esm file with the same name as the relevant portion of the ba2 file.  Using the blank.esm mod, I would make a master mod for all of that author's ba2 mods.  I would rename all the ba2 files of an author to comply with the name I renamed the blank esm file (xxxx-y1.ba2 ... xxxs-yz.ba2; and the esm file xxxx.esm).  That would load all the ba2 files by that author while only using one esm. 

Before I would do any of that, I would first create a folder with the name of the esm file (like "xxxx esm folder") and drop that into vortex or just have it "install" that empty folder. That would create the staging folder.  Then I would just manually move my esm file and ba2 files into a data folder inside the xxxx esm folder.  I noticed that if I moved the folder with all of those files into vortex instead of just the folder, vortex would try to compress the whole thing into a zip file (for reinstalling later as a sort of reference and version archive) and that took forever.  My computer was much faster at just moving the uncompressed folder into the staging folder rather than compressing then uncompressing.  To monitor for updates of those files, I would keep the uncombined versions in vortex as disabled (and delete the ba2 files of the disabled folder to save drive space), and that would at least notify me if I needed to update the author's part mod to my master version containing all of the ba2 parts of mods.  

Is there any reason why that procedure would no longer work?  Is there something about the procedure that might have been messing up something for me without my realizing it?

Thanks for your time presuming you have read this far.  I have found most of how everything works with vortex to be a bit vague, but I used to be an attorney (had a brain injury so no longer), and I am kind of good at sussing out difficult instructions--but not perfect!  That is why I want to make sure I have all this straight.

Oh, one final questions.  I know that supposedly several fomods were messed up and then fixed by vortex.  Does this mean that the old fomods were putting vortex installations into a data folder whereas the fixed fomods should just now have the type data and no reason to have an actual data folder in the staging folder?  

[Akopian]

Oh!  I thought it might be useful if you guys defined what some of your terms are.  I can kind of guess from the context and from using vortex what some of them mean, but I am not really sure.  Here are the unclear words based on what I read here (unclear as that they are not defined and have never run into them before--I am sure they are crystal clear to you):

Stop Pattern - Not sure what that means at all

Top level folders - the very top folder for a staging folder would be the name of an archive in most cases and the next level would be the first folder in the zip file, right?

A "mod type system" seems to include two designations so far: data and collections.  I suppose you could have sub data types like textures or interface as those are sub-folders of data.  I do not think there is a collections folder, so the mod-type is not merely which folder the mod info belongs to at the top level.

A migration is making sure after an update that all the data from before is formatted properly to be used after the update?

Migration logic refers to the rules involved in changing the format to meet the requirements of the new update?