Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canceling Out of a Quality Prompt after Clicking OK within Priority Selection Leads to Incorrect Characters #5044

Open
DelnarErsike opened this issue Aug 21, 2023 · 0 comments
Labels
bug: C# pinned Issues that cannot be automatically flagged as stale

Comments

@DelnarErsike
Copy link
Collaborator

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.

@DelnarErsike DelnarErsike added bug: C# pinned Issues that cannot be automatically flagged as stale labels Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: C# pinned Issues that cannot be automatically flagged as stale
Projects
None yet
Development

No branches or pull requests

1 participant