Help with adding advanced features to extension

[SaintBaron1]

Hi all,

 

I have made an extension for Bugsnax and I'm looking to add some more complexity to it. When someone enables an addon, I want to read a json in the addon's zip folder and then make changes to the right XMLs in the game. How would I go about calling a function to do this? Could I do it natively in the .js for the addon or would I need to create a mod manager for the game? If I need to create a mod manager for the game, how would I link that into Vortex?

 

Thanks!

[Tannin42]

You can do that from Vortex, but I wouldn't go about it the way you describe.

You _can_ react to mods being enabled, either by listening to an event (context.api.events.on('mods-enabled', ...) or by reacting to state changes (context.api.onStateChange(['persistent', 'profiles'], ...)
You can find code samples for both in our repository. The second variant, listening to changes to profiles, then figuring out if a profile was enabled/disabled is a bit more work but it's more robust because theoretically third-party extensions could set a mod to enabled without triggering the event.

However: I would strongly suggest you do neither of these because what if the user enabled a mod and then later changes the xml file manually or restores it from a backup or something? Or what if you find you made a mistake in how you edit the xml - you can fix your extension but what about all the users who used the broken one?

Instead what we usually do for things like this would be to do this during deployment.

You can do something like this:

    context.api.onAsync('did-deploy', (profileId: string) => {
      const profile = selectors.profileById(context.api.getState(), profileId);
      if (profile?.gameId === GAME_ID) {
        // your code here
      }
      return Promise.resolve();
    });

That code would get called reliably every time the user deploys, after all files have already been deployed to the mod directory (you can also use the will-deploy event to act before that)
At that point you could read all the json files and update the xml files accordingly. That way you're refreshing the xml every deployment giving you opportunity to set everything up properly in a single step.

If reading those json files is an actual performance issue you might instead use actions.setModAttribute to "cache" the information with the mod so that you don't have to re-read
the file every time.

You will however have to consider the fact that the xml file might have the changes from a prior deployment in it.
If that is _not_ an option, another solution would be to use context.registerMerge.
This works similar to what I described above but instead of modifying the xml directly, the merge creates a new mod with a new xml file that can combine the info from the original
file with the information from the addon json files.
That file then gets deployed like any other mod and you can deploy it so it overwrites the original xml (use a mod type (context.registerModType) if the xml file is not in the usual mod directory).
Because Vortex keeps backups of all files it replaces you'd still have the original unmodified xml. The next time you deploy the merge is called again using the unmodified xml as the input,
so you always have the same input data to generate your modified xml.
This has the added benefit that if the user perges their mod install, that will also restore the xml file to unmodded state.



You should be able to find example uses of all of these apis in our own game repository (https://github.com/Nexus-Mods/vortex-games)