If there is an after entry naming X.esp that is conditional on Y.esp being present and another that naming X.esp that is conditional on Z.esp being present, only one will be preserved (though for sorting most masterlist and userlist metadata is kept separate).
This is due to the equality / ordering operator implementations on the metadata data types, so change them to compare all fields.
Change PluginCleaningData, File, Tag, Location, Message, MessageContent and Group's overloaded operators to compare all fields. The last three aren't affected by this issue, but should be updated to avoid similar future issues and for consistency.
Update everywhere that relies on the current equality / ordering behaviour to catch "duplicates" to instead explicitly check the field that is of interest:
PluginCleaningData: When generating messages, don't deduplicate, as all the fields may contain useful information (even if having multiple messages might look odd).
File: When generating messages from File objects for the UI, deduplicate by comparing display names.
Tag: When generating a tag list for the UI, deduplicate by comparing names.
Location: Location objects aren't used beyond being able to see and set them in the metadata editor, so no UI deduplication is necessary.
Message: No deduplication necessary.
MessageContent: No deduplication necessary.
Group: Deduplicate by comparing their names.
The full set of operators should also be implemented, as currently most metadata types only have < and == implemented. The others can be implemented in terms of those, so they should be provided for completeness.
If there is an
after
entry namingX.esp
that is conditional onY.esp
being present and another that namingX.esp
that is conditional onZ.esp
being present, only one will be preserved (though for sorting most masterlist and userlist metadata is kept separate).This is due to the equality / ordering operator implementations on the metadata data types, so change them to compare all fields.
PluginCleaningData
,File
,Tag
,Location
,Message
,MessageContent
andGroup
's overloaded operators to compare all fields. The last three aren't affected by this issue, but should be updated to avoid similar future issues and for consistency.PluginCleaningData
: When generating messages, don't deduplicate, as all the fields may contain useful information (even if having multiple messages might look odd).File
: When generating messages fromFile
objects for the UI, deduplicate by comparing display names.Tag
: When generating a tag list for the UI, deduplicate by comparing names.Location
:Location
objects aren't used beyond being able to see and set them in the metadata editor, so no UI deduplication is necessary.Message
: No deduplication necessary.MessageContent
: No deduplication necessary.Group
: Deduplicate by comparing their names.The full set of operators should also be implemented, as currently most metadata types only have
<
and==
implemented. The others can be implemented in terms of those, so they should be provided for completeness.