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

Description

See

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.

Environment

None

Activity

Show:
Dave Griffin
December 20, 2012, 8:12 PM

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 ?

Tom Parker
December 20, 2012, 8:31 PM

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.

Dave Griffin
December 20, 2012, 8:44 PM

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...

Tom Parker
December 20, 2012, 8:55 PM

Committed revision 18729.

Dave Griffin
March 25, 2013, 3:39 PM

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.

Fixed

Assignee

Tom Parker

Reporter

Dave Griffin

Labels

None

Theme

None

Epic/Theme

None

Pending User Input

None

Components

Fix versions

Affects versions

Priority

Minor
Configure