Unexpected behaviour from FOMOD installer flag values

[Sync-67]

Describe the Bug:

When using a FOMOD installer, modifying the value of a previously set flag can result in unexpected behaviour:

• If a flag is set to "On" and a step after it has an option that modifies its value, the flag can be set to "Off" even if the selected option does not affect the flag.
• If an option changes the value of a flag used in a condition to determine the visibility of a previous step, that step may be erroneously be hidden or displayed when using the button to move back a step.

To Reproduce:

See attached file for a FOMOD installer that demonstrates this issue.
The installer has four steps:

• Step 1 sets the 'Test' flag to 'On.'
• Step 2 requires 'Test' == 'On' for it to be displayed.
• Step 3 has options to change the value of the 'Test' flag, showing the different results.
• Step 4 requires 'Test' == 'On' for it to be displayed.

1. Use Vortex to install the demo FOMOD. Moving through the steps, you should see step 1, 2, and 3 displayed.

2. Step 3 has three options:

   A. Set 'Test' flag to 'Off'
   B. Don't Change Flag State
   C. Set 'Test' to 'On'

3. If Option A is chosen, the back button (bottom left) will change to lead back to Step 1, and the forward button (bottom right) will finish the install, correctly skipping Step 4.

4. Click the back button to return to Step 1. The forward button will now lead to Step 3 instead of Step 2.

5. Move back to Step 3 and select Option B instead. Despite not setting or changing any flags, the back button will lead to Step 1, and the forward button will still finish the install instead of displaying Step 4 (Note: This remains true even if you restart the install and skip selecting Option A, or select Option C and then change to Option B).

6. Change the selection in Step 3 to Option C. Step 2 and 4 will be displayed as expected.

Expected Behavior:

• The back button should always lead to the step the user saw previously. Steps the user has seen should not be hidden when moving backward if the value of the flag controlling their visibility changes. If a step was not displayed when going forward through the install the first time, changing the value of the flag controlling its visibility should not let it become visible when moving backward.
• If a selected option makes no changes to a previously set flag, the value of that flag should not change.
• If a step has options that do make changes to the value of a previously set flag, those changes should be reverted when moving in reverse.

Platform:

• OS: Windows 10 Home, Version 22H2, OS Build 19045.4651, x64
• Vortex Version: 1.11.7

Additional Context:

From my testing, it appears that if a step has any option that modifies the value of a previously set flag, then selecting options that do not change that flag will result in it being set to "Off" (even if they set a different flag).
For example, if Option A is omitted from Step 3 in the demo file, selecting Option B will still result in 'Test' being set to 'Off' in Step 3. If both Option A and Option C are omitted, then Option B will have no effect on the 'Test' flag and behave as expected.

The order of the options in Step 3 does not appear to have any affect on the incorrect flag values. If Option C is put first in the list, Option B will still set the 'Test' flag to 'Off.' Changing the names of the options so they have a different alphabetical order also has no effect.

Please let me know if I can provide any more information, or if anything is unclear. If you'd like assistance with testing possible fixes I'm happy to help with that as well!

FOMOD-Flag-Value-Bug-Demo.zip

[IDCs]

Hi there @Sync-67 - no offense intended, but the use case you're describing is simply put... Very bad FOMOD design - why would anyone decide to block the visibility of a page based on a flag which can be changed multiple times in pages in front and behind that page? That's just looking for trouble.

As far as I can see Vortex is behaving exactly as expected, using the defined flags to display/hide pages. The FOMOD installer is context aware and any flags defined as part of the installation are fully controlled by the FOMOD's design.

Can you give me one world example where this type of pattern is required?

[Sync-67]

Sorry - I think I hit a wrong key while I was typing my response and it marked this issue as closed. I reopened it, but hopefully that didn't mess anything up for tracking the issue.

[Sync-67]

Hi @IDCs,
I agree, this FOMOD design is not ideal. Unfortunately, this was the best solution I could come up with to get the functionality that I needed.

For one of my mods, I'd like to display a message to the user explaining why some patch combinations can't be used together. My mod makes a change to some mushroom meshes that improves the collision. However, there are various other mods that also modify the same meshes, so I'm providing patches for them.

During installation, users are seeing the patch options and expect to be able to select all the options for the mods that they have in their load order, not realizing that for the mushroom meshes specifically, they are only really using one mod which they have set to override the others.
The mods being patched include mods that have a wide range effect, touching many meshes in the game, as well as mods with a very narrow effect, like overhauling the appearance of the mushrooms. Some of these mods are compatible with each other, and others are not. Users have more than one mod installed and don't necessarily understand how they interact at the level of a single specific mesh.

I've tried changing the installer to prevent invalid installations with the 'SelectExactlyOne' type option, but this can confuse users that don't have a great understanding of the file interactions, since they expect to select patches for all the mods they have installed.

Ideally, I'd like to allow any combination of the patches to be selected, but then show steps that alert them to invalid combinations, explain why what they selected can't be installed, and allow them to correct the installation. In the FOMOD, this means changing the value of a previously set flag. While it could probably be worked around by having very specific flags for all the different conditions, this would make constructing the FOMOD much more complex and it would be very difficult to maintain in the future.

A FOMOD installer that modifies the value of a previously set flag works fine in MO2, but results in this unexpected behaviour when installed with Vortex.