You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the way the priority selection (and priority changing) system works in Chummer5a right now, there is a niche situation where a user can corrupt their characters' data when using certain types of custom content related to priority tables.
Specifically, talent priorities are set up to allow a character to gain one or more qualities. This is used in the base data files to add qualities like Adept or Magician or Technomancer, but the system is not necessarily restricted to these types of qualities. For example, a talent priority entry could be set up to grant the character the Wanted quality, or the Big Regret quality, or the Allergy (Severe, Specific) quality.
The problem this issue highlights can arise when talent priorities have been modified to grant qualities whose bonuses prompt the user to select something: a text box for a description, a specific weapon, etc. If the user selects such a talent priority, clicks OK to confirm their priorities, and then cancels out of the selection dialog for a talent-priority-granted quality, they will corrupt their characters who now have a non-functional version of that quality on their sheet. The only way this change can be undone is by swapping priorities back and forth and then not canceling out the second time. If a character is exported to career mode with such corruption present, it cannot be undone.
This problem cannot occur with the base data files because all qualities given by priorities in this way either have no selection dialogs or have their selection dialogs bypassed by specific logic (namely, Aspected Magician's prompt to choose a skill group to unlock). However, this behavior still should not be possible even with custom data files that do allow it to happen.
This issue is caused by logic within the SelectMetatypePriority::MetatypeSelected() method, highlighted with a TODO comment within. As of writing, canceling out of such a dialog does nothing, and an empty, non-functional version of the quality is added to the character. Ideally, what should happen is that canceling out of such a dialog also cancels out of the method itself, but this is easier said than done. The complicating issue is that, among other things, changes to the character's metatype and metatype-related properties are already processed by the time talent priorities and any qualities they give are considered. This cannot be bypassed by just rearranging the order in which these steps are taken, because things like metatype and metatype-given qualities can have downstream effects on which talent-given quality options a character is eligible for. E.g., if a talent were to give Prototype Transhuman, metatype-given qualities can be important for what negative qualities the user can choose.
A rigorous solution would probably require some sort of buffer system, where changes to a character can be processed in a temporary buffer before they are applied wholesale to the character as a whole. The Improvements Manager already has a small-scale version of this (which is why it has the Commit() and Rollback() methods), but that's only very narrowly defined for Improvements.
The text was updated successfully, but these errors were encountered:
With the way the priority selection (and priority changing) system works in Chummer5a right now, there is a niche situation where a user can corrupt their characters' data when using certain types of custom content related to priority tables.
Specifically, talent priorities are set up to allow a character to gain one or more qualities. This is used in the base data files to add qualities like Adept or Magician or Technomancer, but the system is not necessarily restricted to these types of qualities. For example, a talent priority entry could be set up to grant the character the
Wanted
quality, or theBig Regret
quality, or theAllergy (Severe, Specific)
quality.The problem this issue highlights can arise when talent priorities have been modified to grant qualities whose bonuses prompt the user to select something: a text box for a description, a specific weapon, etc. If the user selects such a talent priority, clicks OK to confirm their priorities, and then cancels out of the selection dialog for a talent-priority-granted quality, they will corrupt their characters who now have a non-functional version of that quality on their sheet. The only way this change can be undone is by swapping priorities back and forth and then not canceling out the second time. If a character is exported to career mode with such corruption present, it cannot be undone.
This problem cannot occur with the base data files because all qualities given by priorities in this way either have no selection dialogs or have their selection dialogs bypassed by specific logic (namely, Aspected Magician's prompt to choose a skill group to unlock). However, this behavior still should not be possible even with custom data files that do allow it to happen.
This issue is caused by logic within the
SelectMetatypePriority::MetatypeSelected()
method, highlighted with a TODO comment within. As of writing, canceling out of such a dialog does nothing, and an empty, non-functional version of the quality is added to the character. Ideally, what should happen is that canceling out of such a dialog also cancels out of the method itself, but this is easier said than done. The complicating issue is that, among other things, changes to the character's metatype and metatype-related properties are already processed by the time talent priorities and any qualities they give are considered. This cannot be bypassed by just rearranging the order in which these steps are taken, because things like metatype and metatype-given qualities can have downstream effects on which talent-given quality options a character is eligible for. E.g., if a talent were to give Prototype Transhuman, metatype-given qualities can be important for what negative qualities the user can choose.A rigorous solution would probably require some sort of buffer system, where changes to a character can be processed in a temporary buffer before they are applied wholesale to the character as a whole. The Improvements Manager already has a small-scale version of this (which is why it has the
Commit()
andRollback()
methods), but that's only very narrowly defined for Improvements.The text was updated successfully, but these errors were encountered: