Difference between revisions of "Data LST Standards"

From PCGen Wiki
Jump to: navigation, search
(General Variable Naming Standards)
Line 35: Line 35:
 
Where it is possible to do so there should be only one DEFINE statement per variable and the DEFINE should be set at 0 with a BONUS:VAR used to adjust the value.
 
Where it is possible to do so there should be only one DEFINE statement per variable and the DEFINE should be set at 0 with a BONUS:VAR used to adjust the value.
  
Variable names in all capitals are reserved for hard coded or variable defined in the system files.
+
Variable names in all capitals are reserved for hard coded variables or variables defined within the system files.
  
 
Where it is possible to do so variables should be DEFINEd within the parent object where it is first used or encountered.
 
Where it is possible to do so variables should be DEFINEd within the parent object where it is first used or encountered.
  
 
It is good practice to leave comments within the data sets LST code explaining what variables have been used in the set, what their purpose is and how they are to be used.
 
It is good practice to leave comments within the data sets LST code explaining what variables have been used in the set, what their purpose is and how they are to be used.
 
  
 
===General EQMOD Naming Standards===
 
===General EQMOD Naming Standards===

Revision as of 17:59, 24 February 2009

General Object Naming Standards

These are general rules for the naming of classes, feats, races and other objects.

Characters approved for use in object names are: upper and lower case letters, numbers, single spaces in between multiple words (never before or after) and the following glyphs: underscore (_), dash (-), apostrophe ('), parentheses (), slash (/), and a tilde (~).

Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=).

Two words separated by a dash should both be capitalized.

Within these limits the name should be as close as possible to the published source.


Additional Restrictions

No object may be named a valid number (even 0x45 or 1e20 could be a problem) as items with optional count can fail.

No object may be called "ANY" or "ALL" or "LIST".

No Class may be called "HIGHESTLEVELCLASS".

No Equipment may be called "Total".

No Weaponprof may be called "DEITYWEAPON".

No equipment (or eqmod ITYPE) may use the types "ADD" or "REMOVE".


General Variable Naming Standards

Variables syntax should start with a letter and should be composed of only letters, _ and numbers. The standard Convention is to use only letters, capitalizing individual words for readability.

Examples: TurnUndead, SpecialAbility, UncannyDodgeFlankingLevel.

Where it is possible to do so there should be only one DEFINE statement per variable and the DEFINE should be set at 0 with a BONUS:VAR used to adjust the value.

Variable names in all capitals are reserved for hard coded variables or variables defined within the system files.

Where it is possible to do so variables should be DEFINEd within the parent object where it is first used or encountered.

It is good practice to leave comments within the data sets LST code explaining what variables have been used in the set, what their purpose is and how they are to be used.

General EQMOD Naming Standards

EQMOD keys are to be in all capital letters and may only contain letters, numbers and underscores ("_").

Each word should be separated by an underscore character for ease in reading.

For purposes of abbreviation the letter limit on the first and second sections of the Key name is 8 and 7.

EQMODs for different item types (Weapon vs. Armor for example) will be done as separate EQMODs.

Materials which list different pricing for different item types or sub types (Light Armor vs. Medium Armor for example) will be done as separate EQMODs for each price type.