FACTSET Token - Revision history

Vest: The actual files are *_datacontrols.lst

2023-07-03T08:17:55Z

The actual files are *_datacontrols.lst

Tom Parker at 04:06, 23 January 2015

2015-01-23T04:06:55Z

Tom Parker: /* REQUIRED */

2015-01-23T04:02:34Z

‎REQUIRED

Tom Parker at 15:26, 17 January 2015

2015-01-17T15:26:07Z

Tom Parker at 15:23, 17 January 2015

2015-01-17T15:23:49Z

Tom Parker: /* Base Token (FACTSET) */

2015-01-17T04:00:41Z

‎Base Token (FACTSET)

Tom Parker: /* Global PREFACT */

2015-01-14T01:10:51Z

‎Global PREFACT

Tom Parker: /* First Token (FACTSETDEF) */

2015-01-01T16:54:40Z

‎First Token (FACTSETDEF)

Tom Parker: /* DATATYPE */

2015-01-01T16:53:37Z

‎DATATYPE

Tom Parker: /* DATATYPE */

2015-01-01T16:53:14Z

‎DATATYPE

@@ Line 59: / Line 59: @@
   y is a factual value
-An identifier (x above) must have been defined in a FACTSETDEF line in a DATACONTROL LST file.
+An identifier (x above) must have been defined in a FACTSETDEF line in a DATACONTROL LST file (*_datacontrols.lst).
 FACTSET appends.  .CLEARALL is available to reset the list.

← Older revision		Revision as of 04:06, 23 January 2015
Line 222:		Line 222:

	"x" matches the same strings used in the output file, which are shown on the [[FreeMarker Facet Output]] page. In some cases, an additional piece of information is required, as with equipment. See the [[FACT Token]] page for a specific example		"x" matches the same strings used in the output file, which are shown on the [[FreeMarker Facet Output]] page. In some cases, an additional piece of information is required, as with equipment. See the [[FACT Token]] page for a specific example
		+
		+	=Understanding Processing Order=
		+
		+	It is possible, albeit a somewhat rare case, for an output name (interpolation in FreeMarker terms) to appear in multiple places in the hierarchy. Consider the following example:
		+	* Create a GLOBAL FACTSET called "Hands"
		+	* Support the output of "Hands" on Race (HANDS is currently an integer value)
		+
		+	In this case, the exact same priority rules that occur for loading occur for output. The "more local" output value will "win" (So Race [using ${race.hands}] would output an integer and every other object type [such as ${deity.hands}] would output the FACTSET.

	=Code Team Awareness=		=Code Team Awareness=

← Older revision		Revision as of 04:02, 23 January 2015
Line 181:		Line 181:

	As caution to the data team: Use of this forces it across ALL loaded data, NOT JUST DATA FROM THE LOCAL PCC FILE. That likely means this is used sparingly, and only in base sets, otherwise the additional sets would have to .MOD a lot of stuff... An item would "pass" the required test if and only if there is content at the end of load. Data followed by .CLEARALL without additional data would trigger an error.		As caution to the data team: Use of this forces it across ALL loaded data, NOT JUST DATA FROM THE LOCAL PCC FILE. That likely means this is used sparingly, and only in base sets, otherwise the additional sets would have to .MOD a lot of stuff... An item would "pass" the required test if and only if there is content at the end of load. Data followed by .CLEARALL without additional data would trigger an error.
		+
		+	WARNING: A FACTSETDEF where the "x" value of the FACTSETDEF token is "GLOBAL" MUST NOT be Required. Using REQUIRED:YES on a global FACTSETDEF will cause a load error.

	===DISPLAYNAME===		===DISPLAYNAME===

@@ Line 157: / Line 157: @@
   CHOOSE:DEITY|PANTHEONS=Greek
-Given the above FACTSETDEF, this would allow a choice of any Deity with the 'ALIGN' FACT set to 'LG'  (this emulates the ALIGN= item we have in CHOOSE:DEITY today)
+Given the above FACTSETDEF, this would allow a choice of any Deity with the 'PANTHEONS' FACTSET including 'Greek'
-(It would produce an error if the FACTSETDEF for ALIGN was SELECTABLE:NO)
+(It would produce an error if the FACTSETDEF for Pantheons was SELECTABLE:NO)
 In case of .MOD (see FACTSETDEF for multiple definitions acting as a .MOD) this overwrites
@@ Line 165: / Line 165: @@
 ===REQUIRED===
-For any given FACTSETDEF, we can make that FACT requried for a certain type of object.
+For any given FACTSETDEF, we can make that FACTSET required for a certain type of object.
   REQUIRED:x
@@ Line 176: / Line 176: @@
   FACTSETDEF:DEITY|Pantheons <> DATAFORMAT:STRING <> VISIBLE:YES <> REQUIRED:YES
-This would then trigger an LST load error if a Deity did not have the "ALIGN" Fact assigned.
+This would then trigger an LST load error if a Deity did not have the "Pantheons" Fact assigned.
 In case of .MOD (see FACTSETDEF for multiple definitions acting as a .MOD) this overwrites

@@ Line 97: / Line 97: @@
 This token MUST appear as the first token on the line in the file.
-A Second FACTSETDEF with matching values here but different DATATYPE: will produce an error, since you have two conflicting items with the same identifier.
+A Second FACTSETDEF with matching values here but different DATAFORMAT: will produce an error, since you have two conflicting items with the same identifier.
-Duplicate FACTDEF with matching x, y and DATATYPE: are legal (thus allowing it to be present in multiple sources), but other tokens on the line are CUMULATIVE (dupe entries even in different files ACT LIKE A MOD, see DATATYPE for the exception)
+Duplicate FACTDEF with matching x, y and DATAFORMAT: are legal (thus allowing it to be present in multiple sources), but other tokens on the line are CUMULATIVE (dupe entries even in different files ACT LIKE A MOD, see DATAFORMAT for the exception)
-===DATATYPE===
+===DATAFORMAT===
-  DATATYPE:x
+  DATAFORMAT:x
-This token is REQUIRED.  A FACTSETDEF with no DATATYPE will produce an LST load error.
+This token is REQUIRED.  A FACTSETDEF with no DATAFORMAT will produce an LST load error.
 Note: The "x" Items will be hardcoded.  In addition to "STRING", it is expected IN THE FUTURE that the same items that are valid as the [http://pcgen.org/autobuilds/pcgen-docs/listfilepages/globalfilestagpages/globalfilesother.html#QUALIFY "x" value of QUALIFY] (the existing Global token) would also be legal here.  For currently legal items, see the [[FACT Token]] page
-Note: This is an exception to a duplicate FACTDEF: acting as a MOD.  Specifically, A DATATYPE: with a type that does not match a previous value will produce an error, since you have two conflicting FACTs with the same identifier.
+Note: This is an exception to a duplicate FACTDEF: acting as a MOD.  Specifically, A DATAFORMAT: with a type that does not match a previous value will produce an error, since you have two conflicting FACTs with the same identifier.
 ===VISIBLE===
@@ Line 124: / Line 124: @@
 For example:
-  FACTSETDEF:DEITY|Pantheons <> DATATYPE:STRING <> VISIBLE:EXPORT
+  FACTSETDEF:DEITY|Pantheons <> DATAFORMAT:STRING <> VISIBLE:EXPORT
 EXPORT or YES would enable the output in Freemarker:
@@ Line 151: / Line 151: @@
 For example:
-  FACTSETDEF:DEITY|Pantheons <> DATATYPE:STRING <> VISIBLE:YES <> SELECTABLE:YES
+  FACTSETDEF:DEITY|Pantheons <> DATAFORMAT:STRING <> VISIBLE:YES <> SELECTABLE:YES
 SELECTABLE:YES enables use in a CHOOSE:
@@ Line 174: / Line 174: @@
 For example:
-  FACTSETDEF:DEITY|Pantheons <> DATATYPE:STRING <> VISIBLE:YES <> REQUIRED:YES
+  FACTSETDEF:DEITY|Pantheons <> DATAFORMAT:STRING <> VISIBLE:YES <> REQUIRED:YES
 This would then trigger an LST load error if a Deity did not have the "ALIGN" Fact assigned.

← Older revision		Revision as of 04:00, 17 January 2015
Line 72:		Line 72:

	.CLEARALL will be supported as a "y" value, and it will clear just the set of facts for the single identifier. If .CLEARALL appears as a y value, it MUST be alone or the first y value on the FACTSET token.		.CLEARALL will be supported as a "y" value, and it will clear just the set of facts for the single identifier. If .CLEARALL appears as a y value, it MUST be alone or the first y value on the FACTSET token.
		+
		+	It is important to note that FACTSET cannot be used in a Campaign (PCC) file. This is because the Campaign files must be loaded to know what the data control files are, and then the data control files define what FACTSETs are legal. This is a race condition we do not intend to work around. FACTSET is simply not legal in Campaign files.

	==PCC (Campaign) LST token (DATACONTROL)==		==PCC (Campaign) LST token (DATACONTROL)==

@@ Line 204: / Line 204: @@
 In case of .MOD (see FACTSETDEF for multiple definitions acting as a .MOD) this overwrites
-==Global PREFACT==
+==Global PREFACTSET==
 Of course, being able to define a FACTSET also demands something like:
@@ Line 210: / Line 210: @@
   PREFACTSET:w,x,y=z
   w is a number
-  x is the type (e.g. DEITY) - matches the types defined for FACTSETDEF
+  x is the type (e.g. DEITY)
   y is the identifier (e.g. PANTHEONS)
   z is the required value
@@ Line 216: / Line 216: @@
 For example:
   PREFACTSET:1,DEITY,PANTHEONS=Greek
 =Code Team Awareness=

@@ Line 91: / Line 91: @@
   y is the identifier (then usable as x in the FACTSET LST token)
-Note: The "y" Items will be hardcoded.  In addition to "STRING", the same items that are valid as the "x" value of QUALIFY (the existing Global token) would also be legal here.
+Note: The "x" Items will be hardcoded.  See [[FACT Token]] legal values
 This token MUST appear as the first token on the line in the file.

@@ Line 105: / Line 105: @@
 This token is REQUIRED.  A FACTSETDEF with no DATATYPE will produce an LST load error.
-Note: The "x" Items will be hardcoded.  In addition to "STRING", it is expected that the same items that are valid as the [http://pcgen.org/autobuilds/pcgen-docs/listfilepages/globalfilestagpages/globalfilesother.html#QUALIFY "x" value of QUALIFY] (the existing Global token) would also be legal here.
+Note: The "x" Items will be hardcoded.  In addition to "STRING", it is expected IN THE FUTURE that the same items that are valid as the [http://pcgen.org/autobuilds/pcgen-docs/listfilepages/globalfilestagpages/globalfilesother.html#QUALIFY "x" value of QUALIFY] (the existing Global token) would also be legal here.  For currently legal items, see the [[FACT]] page
 Note: This is an exception to a duplicate FACTDEF: acting as a MOD.  Specifically, A DATATYPE: with a type that does not match a previous value will produce an error, since you have two conflicting FACTs with the same identifier.