Details

    • Type: New Token New Token
    • Status: Proposed Proposed
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Dependent Data:
      Pathfinder
    • Subtype:
      None Taken

      Description

      This is for allowing the duplicates to be present but keeping the log screen free from excessive dupe messages for known items. This is a bare bones proposal to be completed by Stefan.

      SUPPRESSDUPES:x|y|y

      X = File/Object Type

      Y = Name of Object

      SUPPRESSDUPES:RACE|Ogre

      Would suppress any duplicates caused by another race by the name of 'Ogre'

      SUPPRESSDUPES:EQUIPMENT|Sword (Short)|Longsword

      The reason this is required, is the debugging monkeys (Myself mainly) are hit by walls of duplicate text, making it hard to find actual errors and problems. This is the compromise solution to allow duplicates to be present and still allow the debugging monkeys to quickly find errors without wasting time searching through huge walls of duplicate error messages. Duplicates would still show up if they aren't in the list of approved items. Which would be ideal so any issues can be addressed.

        Activity

        Hide
        James Dempsey
        added a comment -

        A few questions for the clarification stage.
        What sort of file would this appear in?
        Say you start with Ogre in source A and in source B. How would this cater for the addition of a third Ogre definition from another source? Would it silently ignore it?
        How does this interact with the "Allow newer sources to override duplicate object from older sources" preference?
        Is the source date still used to decide which one to use?

        Relevant code is in pcgen.persistence.lst.LstObjectFileLoader.storeObject(LoadContext, T)

        Show
        James Dempsey
        added a comment - A few questions for the clarification stage. What sort of file would this appear in? Say you start with Ogre in source A and in source B. How would this cater for the addition of a third Ogre definition from another source? Would it silently ignore it? How does this interact with the "Allow newer sources to override duplicate object from older sources" preference? Is the source date still used to decide which one to use? Relevant code is in pcgen.persistence.lst.LstObjectFileLoader.storeObject(LoadContext, T)
        Hide
        Andrew Maitland
        added a comment - - edited

        #1 - This should be a PCC file tag only.
        #2 - This should be going in order of newest. Let's say Source A is the Core Book. Source B is the Set that is newer than Core Book. We know there is an Orge in Source A, and this one would override, to suppress the error we set up this tag. SUPPRESSDUPE:RACE|Ogre. Source C comes along and is newer than Source B. Since it's a newer source, it's duplicate should still flag. (That's the only logical way I can think this would work, otherwise, we'd have to specificy which sources to ignore dupes from... which is fine as well, I don't see that as too much of a hassle) - This is up for discussion obviously.
        #3 - When the 'Allow newer sources to override duplicate object from older sources' is 'ACTIVE, we never see the errors. They are all suppressed by default, the newest source is automatically chosen. So there should be NO interaction between the two. This proposal is for the monkeys who need the Preference turned off to do a full and complete debug to make sure the source is error free.

        I hope that answers your three questions sufficiently.

        Show
        Andrew Maitland
        added a comment - - edited #1 - This should be a PCC file tag only. #2 - This should be going in order of newest. Let's say Source A is the Core Book. Source B is the Set that is newer than Core Book. We know there is an Orge in Source A, and this one would override, to suppress the error we set up this tag. SUPPRESSDUPE:RACE|Ogre. Source C comes along and is newer than Source B. Since it's a newer source, it's duplicate should still flag. (That's the only logical way I can think this would work, otherwise, we'd have to specificy which sources to ignore dupes from... which is fine as well, I don't see that as too much of a hassle) - This is up for discussion obviously. #3 - When the 'Allow newer sources to override duplicate object from older sources' is 'ACTIVE, we never see the errors. They are all suppressed by default, the newest source is automatically chosen. So there should be NO interaction between the two. This proposal is for the monkeys who need the Preference turned off to do a full and complete debug to make sure the source is error free. I hope that answers your three questions sufficiently.
        Hide
        Andrew Maitland
        added a comment -

        Are you able to implement this Stefan?

        Show
        Andrew Maitland
        added a comment - Are you able to implement this Stefan?
        Hide
        Tom Parker
        added a comment -

        No, not approved - still too much ambiguity and risk here. Why should there be duplicates at all if we are not having newer sources override? This is trying to create a token to fix bad data design.

        Show
        Tom Parker
        added a comment - No, not approved - still too much ambiguity and risk here. Why should there be duplicates at all if we are not having newer sources override? This is trying to create a token to fix bad data design.

          People

          • Assignee:
            Stefan Radermacher
            Reporter:
            Andrew Maitland
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: