Code
  1. Code
  2. CODE-1736

Debug console to indicate PCC's loaded (in order)

    Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.17.19
    • Fix Version/s: 6.01.01
    • Labels:
      None

      Description

      See CODE-1277

      I have a set of 'campaign' PCC's (one for each gaming session), that defines the various sourcebooks (sub-PCC's) that are used for that particular gaming group.
      Each of these sub-PCC's may in turn also include other PCC's based on their dependancies.
      While each of these PCC's can be included manually in the 'select source' screen, the 'campaign' PCC's make it far easier to switch from one game to another.

      To aid in diagnosing issues in my homebrew, I'd like to have the log indicate which PCC it has loaded in and is processing (in order), so that any data errors that appear can be easily traced back to the originating PCC file.

      Not all errors indicate the source file that caused them unfortunately, so this additional logging will help with diagnosing those hard to find issues.

        Activity

        Hide
        Tom Parker
        added a comment -

        PCC files are all loaded when PCGen is loaded, so the PCC files are all resident in memory before you load any sources. It is then the files they refer to that are loaded individually when you load sources. As it so happens, if a file is mentioned in more than one PCC file, we try to avoid loading it twice. So the concept of "which PCC file is being loaded" is a lost by the time we are loading LST files.

        So there are potentially two separate issues here. The first is diagnosing the PCC files themselves, the second is diagnosing the LST files.

        We can add a debug-level message prior to loading each LST URI (file/URL/whatever) if that is what you are asking for, but it will not be for PCCs, it will be for the content. Adding the PCC files would be a different endeavor.

        Can you confirm if that the message about the LST to be loaded is actually what you are looking to achieve?

        Show
        Tom Parker
        added a comment - PCC files are all loaded when PCGen is loaded, so the PCC files are all resident in memory before you load any sources. It is then the files they refer to that are loaded individually when you load sources. As it so happens, if a file is mentioned in more than one PCC file, we try to avoid loading it twice. So the concept of "which PCC file is being loaded" is a lost by the time we are loading LST files. So there are potentially two separate issues here. The first is diagnosing the PCC files themselves, the second is diagnosing the LST files. We can add a debug-level message prior to loading each LST URI (file/URL/whatever) if that is what you are asking for, but it will not be for PCCs, it will be for the content. Adding the PCC files would be a different endeavor. Can you confirm if that the message about the LST to be loaded is actually what you are looking to achieve?
        Hide
        Dave Griffin
        added a comment -

        If the debug could provide a full list of every .lst file, as it's loaded (rather than only listing the filenames when an error is encountered), then this would allow verification of which lst files had already been processed, and thus (by extrapolation) which pcc's had been processed, that would cover it.

        This will however list a lot more info than the original request unfortunately...

        I appreciate all pcc's are loaded in at startup, but when I click 'load', it then processes the selected source PCC's to flag which .LST files it will then process... hmmm, so yes, I guess when it's actually loading lst files its only got a <list> of .lst files, and no reference back to the .pcc that defined those .lst's...
        Assuming that's the case, could that <list> of .lst files include special entries that merely flag 'the first .lst file from .pcc xyz' only to be used for debug ?

        Show
        Dave Griffin
        added a comment - If the debug could provide a full list of every .lst file, as it's loaded (rather than only listing the filenames when an error is encountered), then this would allow verification of which lst files had already been processed, and thus (by extrapolation) which pcc's had been processed, that would cover it. This will however list a lot more info than the original request unfortunately... I appreciate all pcc's are loaded in at startup, but when I click 'load', it then processes the selected source PCC's to flag which .LST files it will then process... hmmm, so yes, I guess when it's actually loading lst files its only got a <list> of .lst files, and no reference back to the .pcc that defined those .lst's... Assuming that's the case, could that <list> of .lst files include special entries that merely flag 'the first .lst file from .pcc xyz' only to be used for debug ?
        Hide
        Tom Parker
        added a comment -

        Yea, so to clarify how loading works:

        The situation with PCCs is that if you have:
        a.pcc:
        PCC:B

        b.pcc:
        PCC:C

        c.pcc:
        FEAT:blah.lst

        Then when PCGen loads the PCC files, it "flattens" all of them in memory. So Campaign a, Campaign b, and Campaign c all have blah.lst as a FEAT file. It can no longer distinguish for Campaign a whether blah.lst came from a, b, or c (and no longer remembers that a contains b which contains c)

        That's one problem.

        Problem #2 with listing files by what PCC they are related to is that we don't load in PCC order. We load (for example) all WEAPONPROF files, then all SKILL files, then all FEAT files, etc. regardless of what PCC file they came from. So if a PCC has a WEAPONPROF entry in it (or any child) it will do that first, but that really isn't useful to identify which PCC the system is "in" at any given time (by the time we are loading LST files, the entire concept of PCCs is "arcane"). So even adding a system to track "first file" would be quite an exercise and not very useful to debug the eventual source PCC (then there are the associated complexities when a file is the first for more than one PCC, so this isn't even trivial to implement).

        I think the best we can do is spew out which file we are in, even though that's a lot of output.

        Show
        Tom Parker
        added a comment - Yea, so to clarify how loading works: The situation with PCCs is that if you have: a.pcc: PCC:B b.pcc: PCC:C c.pcc: FEAT:blah.lst Then when PCGen loads the PCC files, it "flattens" all of them in memory. So Campaign a, Campaign b, and Campaign c all have blah.lst as a FEAT file. It can no longer distinguish for Campaign a whether blah.lst came from a, b, or c (and no longer remembers that a contains b which contains c) That's one problem. Problem #2 with listing files by what PCC they are related to is that we don't load in PCC order. We load (for example) all WEAPONPROF files, then all SKILL files, then all FEAT files, etc. regardless of what PCC file they came from. So if a PCC has a WEAPONPROF entry in it (or any child) it will do that first, but that really isn't useful to identify which PCC the system is "in" at any given time (by the time we are loading LST files, the entire concept of PCCs is "arcane"). So even adding a system to track "first file" would be quite an exercise and not very useful to debug the eventual source PCC (then there are the associated complexities when a file is the first for more than one PCC, so this isn't even trivial to implement). I think the best we can do is spew out which file we are in, even though that's a lot of output.
        Hide
        Dave Griffin
        added a comment -

        Gotcha.
        Problem two isnt really an issue, as if I have, say, a problem with a feat being MOD'ed, I'm thenonly looking at feats, and don't care what weaponprofs have been loaded, I only care at that point which feat files (in which order) have been processed.

        Spewing out all the filenames would cover it, and this is only for 'deep' debugging...

        Show
        Dave Griffin
        added a comment - Gotcha. Problem two isnt really an issue, as if I have, say, a problem with a feat being MOD'ed, I'm thenonly looking at feats, and don't care what weaponprofs have been loaded, I only care at that point which feat files (in which order) have been processed. Spewing out all the filenames would cover it, and this is only for 'deep' debugging...
        Hide
        Tom Parker
        added a comment -

        Committed revision 18729.

        Show
        Tom Parker
        added a comment - Committed revision 18729.
        Hide
        Dave Griffin
        added a comment -

        In the 6.00.01 autobuild, I'm only seeing filenames for files that have given errors themselves (and mostly a load of 'worthless key change' messages as shown below - loading RSRD).

        21:34:46.266 FINER Thread-12 AbstractReferenceManufacturer:541 Worthless Key change encountered: Low-Light Vision Low-Light Vision
        21:34:46.266 FINER Thread-12 AbstractReferenceManufacturer:543 (Source: file:/C:/Utils/PCGen/pcgen-Autobuild/data/d20ogl/srd35/basics/rsrd_abilities_racial.lst)

        I think that now however, the debugging I need to do is clearer thanks to the extra error checking throughout, so I'm not concerned about this any more.

        Show
        Dave Griffin
        added a comment - In the 6.00.01 autobuild, I'm only seeing filenames for files that have given errors themselves (and mostly a load of 'worthless key change' messages as shown below - loading RSRD). 21:34:46.266 FINER Thread-12 AbstractReferenceManufacturer:541 Worthless Key change encountered: Low-Light Vision Low-Light Vision 21:34:46.266 FINER Thread-12 AbstractReferenceManufacturer:543 (Source: file:/C:/Utils/PCGen/pcgen-Autobuild/data/d20ogl/srd35/basics/rsrd_abilities_racial.lst ) I think that now however, the debugging I need to do is clearer thanks to the extra error checking throughout, so I'm not concerned about this any more.

          People

          • Assignee:
            Tom Parker
            Reporter:
            Dave Griffin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: