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

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?

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 ?

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.

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

Committed revision 18729.

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.