https://hlkitwiki.wolflair.com/api.php5?action=feedcontributions&user=Rob&feedformat=atomHLKitWiki - User contributions [en]2024-03-29T00:46:46ZUser contributionsMediaWiki 1.25.3https://hlkitwiki.wolflair.com/index.php5?title=Kit_Reference&diff=3012Kit Reference2009-06-26T00:36:00Z<p>Rob: /* Scripting Language{{anchor|scripts}} */</p>
<hr />
<div>{{context}}<br />
[[Category:Kit Reference]]<br />
<br />
==Overview==<br />
<br />
This section details all of the specific formats and mechanisms used within the Kit. This encompasses all of the different file formats, all the scripting contexts and transitions, required and pre-defined elements, and anything else that requires specification. Click on the various topics below to delve into the details for that facet of the Kit.<br />
<br />
==Revision History==<br />
<br />
The Authoring Kit is an evolving toolset. A detailed summary of the changes and enhancements made within each new version after the initial V3.0 release is accessible via the links below.<br />
<br />
*{{flalt|Functionality Revision History|Functionality Changes and Enhancements}}<br />
*{{flalt|Skeleton Data File Revision History|Skeleton Data File Changes and Enhancements}}<br />
<br />
==XML Details==<br />
<br />
Most of the basics regarding the Kit's use of XML files and their implications can be found in the section on [[XML Files]]. Additional reference details are outlined in the topics below.<br />
<br />
*{{fl|XML Character Encoding Set}}<br />
<br />
==Conventions Used Below{{anchor|conventions}}==<br />
<br />
The reference section of this documentation utilizes a variety of notational conventions for presenting how things work. This includes the syntax used for data files, as well as the formats for other types of files, which are outlined in the topics below.<br />
<br />
*{{fl|XML Attributes in Data Files}}<br />
*{{fl|Specifying PCDATA in Data Files}}<br />
*{{fl|Optional Attributes in Data Files}}<br />
<br />
==Tags and Tag Expressions{{anchor|tagexprs}}==<br />
<br />
Tags are a fundamental building block that a wide range of mechanisms leverage through the Kit. Tags are utilized to identify and classify objects through tag expressions. The following topics delve into the various facets of using tags.<br />
<br />
*{{fl|Leveraging Tags Via Tag Expressions}}<br />
*{{fl|Tag Expression Types}}<br />
<br />
==Scripting Language{{anchor|scripts}}==<br />
<br />
The types of behaviors that exist within the realm of RPGs is limitless. As such, it's impossible for HL to anticipate everything, so the Kit provides a versatile scripting language that enables data files to adapt to virtually any game system. The scripting language has many facets that you should be familiar with, and the topics below outline the information you'll need.<br />
<br />
*{{fl|Scripting Language Overview}}<br />
*{{fl|Language Syntax}}<br />
*{{fl|Declaring Variables}}<br />
*{{fl|Basic Language Mechanisms}}<br />
*{{fl|Flow Control}}<br />
*{{fl|Other Language Statements}}<br />
*{{fl|Language Intrinsics}}<br />
*{{fl|Special Symbols}}<br />
*[[Encoded Text|Formatting with Encoded Text]]<br />
*{{fl|Script Macros}}<br />
*{{fl|Re-usable Procedures}}<br />
*{{fl|Debugging Mechanisms}}<br />
*{{fl|Compiler Error Messages}}<br />
<br />
==Script Data Access==<br />
<br />
The majority of your scripts will focus on accessing and manipulating the data managed within HL. This will involving identifying both the structural and visual elements throughout the data hierarchy. The following topics detail the various pieces involved in data access. <br />
<br />
{{important}}Be sure you are familiar with the [[Data Manipulation Basics|basics of data manipulation]] before reviewing this content.<br />
<br />
*{{fl|Script Contexts}}<br />
*{{fl|Context Transitions}}<br />
*{{fl|Target References}}<br />
*{{fl|Data Access Examples}}<br />
*{{fl|Employing Script Macros}}<br />
*{{fl|Script Types}}<br />
<br />
==Structure of Data Files==<br />
<br />
There are a number of different types of files that comprise the data files for a game system. Each of the topics below describes the structure of one of these file types.<br />
<br />
*{{fl|Definition File Reference}}<br />
*{{fl|Structural File Reference}}<br />
*{{fl|Data File Reference}}<br />
<br />
==Auto-Defined Elements==<br />
<br />
The Kit automatically defines a variety of different structural and visual elements for use in common situations. These auto-defined elements help to streamline and simplify the authoring process, and they are detailed in the topics below.<br />
<br />
*{{fl|Pseudo-Fields}}<br />
*{{fl|Auto-Defined Tags and Tag Groups}}<br />
*{{fl|Auto-Defined Components and Fields}}<br />
**journal, transact, stackable, gear, shortname, etc.<br />
*{{fl|Auto-Defined Component Sets}}<br />
*{{fl|Auto-Defined Things}}<br />
*{{fl|Auto-Defined Sort Sets}}<br />
*{{fl|Built-in Resources}}<br />
*{{fl|System Resources}}<br />
<br />
==Required Elements==<br />
<br />
There are an assortment of structural and visual elements that every set of data files is required to define. By standardizing on a core set of objects, everything becomes simpler to manage for the data file author. To make the process as easy as possible, the Skeleton data files pre-define these necessary pieces, which you can leave as is or modify if you wish.<br />
<br />
*{{fl|Required Panels}}<br />
*{{fl|Required Forms}}<br />
*{{fl|Required Components and Fields}}<br />
*{{fl|Required Component Sets}}<br />
*{{fl|Required Things}}<br />
<br />
==Other File Formats==<br />
<br />
In addition to the various data files, HL utilizes a few other types of files. The contents of these files is documented in the topics below.<br />
<br />
*{{fl|Timing Report File Reference}}<br />
*{{fl|Portfolio File Reference}}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Encoded_Text&diff=3011Encoded Text2009-06-26T00:33:13Z<p>Rob: </p>
<hr />
<div>{{contextmulti}}<br />
<br />
While not exactly a true "building block", encoded text is an important facet of the visual presentation for any game system. Encoded text is the term used for inserting control over colors, fonts, and even bitmaps within text strings. If you want to highlight a word within a string in red, you'll use encoded text. If you want to change the font size for a few works or put a keyword in bold, you'll use encoded text. You can also insert bitmaps into the text stream with encoded text, which makes it possible to do things like display the sequence of dots for traits within the World of Darkness game system.<br />
<br />
The encoding syntax uses the characters '{' and '}' to identify the special codes, much like HTML uses the '<' and '>' characters to wrap special codes. The text found between the '{' and '}' characters is interpreted based on the table given below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|{br}<br />
|Inserts a carriage return into the text at this position.<br />
|-<br />
|{nbsp}<br />
|Inserts a non-breaking space into the text at this position. Word-wrapping behavior is not allowed to occur on a non-breaking space, so the space is tied to whatever other text appears before and/or after it. This can be useful for placing padding around text that changes foreground and/or background colors.<br />
|-<br />
|{spc}<br />
|From this point forward in the text, all sequences of multiple spaces are collapsed into a single space.<br />
|-<br />
|{b} {/b}<br />
|Text following the "{b}" sequence is rendered in bold. This persists until the "{/b}" sequence turns off bold rendering.<br />
|-<br />
|{i} {/i}<br />
|Text following the "{i}" sequence is rendered in italics. This persists until the "{/i}" sequence turns off italics rendering.<br />
|-<br />
|{u} {/u}<br />
|Text following the "{u}" sequence is underlined. This persists until the "{/u}" sequence turns off underline rendering.<br />
|-<br />
|{font name}<br />
|From this point forward in the text, the font with the specified "name" will be used for output. The prevailing size and style are used in conjunction with the new font.<br />
{{note}}Use of a font that is not a standard Windows font will result in the new font being ignored on any computer that does not possess the font. So be sure to only use standard Windows fonts if you plan on distributing your data files to others.<br />
|-<br />
|{size value}<br />
|From this point forward in the text, the font size is changed to the given "value". In order to support fractional point sizes, the value is the number of quarter-points, so a value of 40 would translate to a point size of 10, while a value of 38 would translate to a point size of 9.5. The prevailing font and style are used in conjunction with the new size.<br />
|-<br />
|{revert}<br />
|From this point forward in the text, the original default font characteristics are restored. All states for bold, italics, and underline are reset to off, regardless of the default font characteristics restored. The primary use for this encoding is to output some text in the default font, configure the text properly for a short segment, and then revert to outputting the rest of the text in the original font. This way, the same encoded text works consistently even when the default font varies between situations.<br />
|-<br />
|{text xxxxxx}<br />
|This sequence changes the foreground text color to the color given by "xxxxxx". The format for the color uses standard HTML color syntax, with each character representing a hexadecimal digit. The first two characters define the Red color value, the next two Green, and the last two Blue. For example, the encoding "{text ff0080}" specifies a Red value of "ff", a Green value of "00", and a Blue value of "80". To revert the foreground text color back to the default, use a color value of "010101".<br />
{{note}}For additional details on specifying colors via the HTML syntax, please refer to one of the many websites that provide this information, such as <br />
[http://www.w3schools.com/Html/html_colors.asp http://www.w3schools.com/Html/html_colors.asp].<br />
|-<br />
|{back xxxxxx}<br />
|This sequence changes the background text color to the color given by "xxxxxx". The color format uses standard HTML syntax, as described for "{text}" above. To disable use of a background color and display text transparently, use a color value of "010101".<br />
|-<br />
|{align position}<br />
|From this point forward in the text, each new line of text will be aligned based on the given "position". The position must be one of the following values: "left" for left-aligned text, "right" for right-aligned text, or "center" for centered text.<br />
|-<br />
|{vert value}<br />
|Vertical spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{horz value}<br />
|Horizontal spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{offset value}<br />
|From this point forward, every new line of text has "value" pixels of horizontal spacing inserted at the start of the line. The offset persists, allowing large blocks of text to be inset from other text. You can turn off the offset by applying an equivalent negative offset. Repeated uses of "offset" are cumulative.<br />
|-<br />
|{indent value}<br />
|From this point forward, every new paragraph of text gains an indentation behavior dictated by "value". If "value" is positive, normal indentation logic is used and the first line of each paragraph is indented that number of pixels. If "value" is negative, a hanging indent is applied, with the second and subsequent lines being indented the specified number of pixels (as an absolute value). Repeated uses of "indent" are cumulative, except for a value of zero, which turns off any active indent behavior.<br />
|-<br />
|{bmp name}<br />
|Inserts into the output the bitmap image with the file name of "name.bmp" that resides in the data file directory for the game system. This bitmap is assumed to be transparent, with the pixel at (0,0) indicating the transparent color. For example, the code "{bmp foo}" would insert the bitmap file named "foo.bmp" that is found in the game system directory. <br />
{{note}} If the bitmap is not found or the output doesn't support encoding, the "name" is inserted as text. So if the filename is "[R].bmp" and referenced as "{bmp [R]}", the text inserted would be "[R]".<br> <br />
{{note}} By default, bitmaps are never scaled when output, but individual styles can explicitly enable scaling of bitmaps inserted via encoded text. If scaling is enabled, the bitmaps may not look ideal due to the scaling.<br />
|-<br />
|{bmpscale factor name}<br />
|As {bmp name}, above, except the the bitmap is scaled by a factor of "factor" (from 2-9) before being output. For example, if you create a bitmap "somebitmap.bmp" with a size of 400x400 and then output it using {bmpscale 4 somebitmap}, it will be drawn with a size of 100x100. This can be useful for drawing bitmaps at large scales, then shrinking them down for use on high-dpi mediums (such as printed pages).<br />
{{note}}This is only recommended for use on output sheets. Due to the windows bitmap resizing algorithm, results of this will likely be poor if used on the screen.<br />
|-<br />
|{meta behavior}<br />
|The behavior specifies a new rendering behavior that will persist until it is again changed. The specified behavior must be one of the following values:<br />
<ul class="sets"><br />
<li>bmpfull – Bitmaps embedded in the encoded text are vertically centered within the full height of the text, including the region of any descender.</li><br />
<li>bmpbaseline – Bitmaps embedded in the encoded text are vertically centered between the baseline of the text and the top edge of the text. This is the default behavior used by encoded text.</li><br />
<li>revert – All behavior changes applied via "meta" special codes are reverted to their default state.</li><br />
</ul><br />
|-<br />
|{macro name}<br />
|Looks for the macro with the unique id given by name and processes the contents of that macro as if it were found in the text instead. This means that macros MAY include encoded text that will be properly processed when the macro is evaluated.<br />
{{note}}Macros MAY be nested within each other, but only to a limited extent, so use nesting sparingly. If a macro references another macro within it, the nested macro will be correctly processed, up to a small number of nesting levels.<br />
NOTE! If an undefined macro is referenced, a message of the form "[Undefined macro: name]" is inserted into the resulting text where the macro would be.<br />
|-<br />
|{ref name}<br />
|Designates the start of a reference region (or "hot zone") that the user can click within to obtain additional information. The name specifies the predefined reference to show when the user clicks in the zone. The zone spans all text from this point forward until the zone is terminated. Terminating a reference zone is accomplished by leaving the name blank. The following is an example of using a reference: "before {ref foo}hot zone{ref} after".<br />
{{note}}If an undefined reference is used, a message of the form "[Undefined reference: name]" is displayed when the reference hot zone is clicked within by the user.<br />
|-<br />
|{url name}<br />
|Designates the start of a hot zone corresponding to an internet URL. The name specifies the actual URL to which the user will be sent when the zone is clicked within (e.g. <nowiki>"http://www.wolflair.com"</nowiki>). The zone spans all text from this point forward until the zone is terminated. Terminating a URL zone is accomplished by leaving the name blank. The following is an example of using a URL zone: <nowiki>"before {url http://www.wolflair.com}hot zone{url} after"</nowiki>.<br />
{{note}}When clicked, Windows is instructed to launch the default web browser that is currently configured by the user and to load the specified URL into that browser. If no browser is properly configured, an error will be reported. If the URL is invalid, the web browser will report that to the user.<br />
|-<br />
|\n<br />
|Identical to "{br}". This is a programming convenience for automated conversion programs written in C/C++.<br />
|-<br />
|}<br />
<br />
{{important}}Not everything within HL makes use of encoded text, so be sure to check the documentation first. If you use encoded text in a place where it's not supported, you will see your embedded special codes within the text displayed.<br />
<br />
{{note}}Encoded text sequences ignore case, so "{BR}" is identical to "{br}". Exceptions to this are macro and reference names, which are case-sensitive. Similarly, URLs are case-sensitive if the website being addressed uses case-sensitive URLs.<br />
<br />
{{note}}If the text within an encoding does not correctly match one of the codes defined above, the text is left unchanged, except as noted above.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Thing_Context&diff=3005Thing Context2009-05-12T10:05:53Z<p>Rob: /* Target References{{anchor|references}} */</p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "thing" context represents a thing that has not been added to the portfolio. The thing context is very similar to the pick context in behavior, with the only real difference being that the dynamic facets of picks don't exist for things, resulting in many valid actions for picks being inaccessible from things.<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
A "thing" context is very similar to a "pick" context, except that a "thing" context represents a thing that has not yet been added to a container and therefore lacks any dynamic state. As a result, the "thing" context is much more restrictive than the "pick" context. From within a "thing" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|state<br />
|Transitions to the [[State Context|state context]].<br><br />
Example: this.state<br />
|-<br />
|field[''id'']<br />
|Transitions to the [[Field Context|field context]] corresponding to the field within the current thing that has the ''id'' specified. If the given field does not exist for the current thing, the transition fails to resolve.<br><br />
Example: this.field[myfield]<br><br />
{{note}}Within things and picks, there are a number of pre-defined pseudo-fields that are always defined and that allow access to facets of the pick that are not governed by user-defined fields. These pseudo-fields behave like normal fields in all respects within scripts, except that some are read-only. The list of pre-defined fields can be found elsewhere in the [[Kit Reference]] documentation.<br />
|-<br />
|linkage[''id'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the linkage with the ''id'' specified. If the linkage is not defined, an error is reported.<br><br />
Example: this.linkage[mylink]<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
There are a number of target references that apply to things that have not been added to a container. These come into play at times like testing pre-requisites and when things are selected via menus. While similar to picks in many ways, things have no dynamic facets and are therefore always read-only in behavior. The complete list of target references for thing is presented in the table below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|idstring<br />
|(Right, String) Returns the unique id of the thing as a string. This can be extremely handy when synthesizing tag templates and tag expressions on-the-fly via scripts.<br><br />
Example: result = this.idstring<br />
|-<br />
|ispick<br />
|(Right, Number) Returns non-zero if the current context is a pick and zero if it's a thing. This provides a means to discern the nature of the context when the circumstances make a distinction uncertain, such as within procedures.<br><br />
Example: result = this.ispick<br />
|-<br />
|isunique<br />
|(Right, Number) Returns non-zero if the thing behaves as unique.<br><br />
Example: result = this.isunique<br />
|-<br />
|isentity<br />
|(Right, Number) Returns non-zero if the thing directly attaches a child entity.<br><br />
Example: result = this.isentity<br />
|-<br />
|tagis[''tmpl'']<br />
|(Right, Number) Returns non-zero if any tags assigned to the thing match the tag template ''tmpl'', else zero if no tags match. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: this.tagis[skill.?]<br />
|-<br />
|tagcount[''tmpl'']<br />
|(Right, Number) Returns the number of tags assigned to the thing that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagcount[skill.?]<br />
|-<br />
|tagvalue[''tmpl'']<br />
|(Right, Number) Returns the value of a tag assigned to the thing that matches the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagvalue[spelllevel.wizard?]<br />
|-<br />
|tagmin[''tmpl'']<br />
|(Right, Number) Returns the minimum value of all tags assigned to the thing that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmin[spelllevel.wizard?]<br />
|-<br />
|tagmax[''tmpl'']<br />
|(Right, Number) Returns the maximum value of all tags assigned to the thing that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmax[spelllevel.wizard?]<br />
|-<br />
|tagunique[''tmpl'']<br />
|(Right, Number) Returns the number of unique tags assigned to the thing that match the tag template ''tmpl''. If a tag is assigned multiple times, it is only counted once. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagunique[skill.?]<br />
|-<br />
|tagexpr[''expr'']<br />
|(Right, Number) Returns non-zero if the tags assigned to the thing match the tag expression ''expr'', else zero is returned. The ''expr'' parameter must be a valid tag expression.<br><br />
Example: result = this.tagexpr[class.wizard & (val:spelllevel.wizard? > 5)]<br />
|-<br />
|tagcountstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagcount", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagcountstr["skill.?"]<br />
|-<br />
|tagvaluestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagvalue", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagvaluestr["spelllevel.wizard?"]<br />
|-<br />
|tagminstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmin", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagminstr["spelllevel.wizard?"]<br />
|-<br />
|tagmaxstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmax", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagmaxstr["spelllevel.wizard?"]<br />
|-<br />
|taguniquestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagunique", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.taguniquestr["skill.?"]<br />
|-<br />
|tagsearch[''str'']<br />
|(Right, Number) This target reference is identical to "tagexpr", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag expression to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagsearch["class.wizard & (val:spelllevel.wizard? > 5)"]<br><br />
{{note}}Using "tagsearch" is MUCH slower in performance than using "tagexpr", since the tagexpr must be parsed and compiled every time the script is evaluated. Be sure to use "tagexpr" whenever possible.<br />
|-<br />
|tagmatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within a reference context also exist within a match context, else zero. This allows tags from one context to be verified to exist within another context, making tag-based comparisons between two objects possible. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = hero.tagmatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|intersect[''init'',''curr'']<br />
|(Right, Number) Returns non-zero if tags within the initial script context also exist within the currently transitioned context, else zero. All of the tags that belong to the ''init'' tag group within the initial script context are compared against the tags that belong to the ''curr'' tag group within the current context. If any of those tags possess the identical tag id, then a match is returned (i.e. non-zero). The same tag group may be used for both contexts, and both contexts must be objects that possess tags (i.e. container, pick, or thing).<br><br />
Example: result = this.interset[MyGroup,AltGroup]<br />
|-<br />
|tagnames[''tmpl'',''spl'']<br />
|(Right, String) Generates and returns a list of tags within the thing. Only tags that match the tag template ''tmpl'' are included in the list. The generated string appends the names of the tags together, inserting the splicing string ''spl'' between each name if there is more than one. A thing with no tags matching the template will return the empty string.<br><br />
Example: result = this.tagnames[Weapon.?,"+"]<br />
|-<br />
|tagabbrevs[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the abbreviations for all matching tags instead of their names.<br><br />
Example: result = this.tagabbrevs[Weapon.?,"+"]<br />
|-<br />
|tagids[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the unique ids for all matching tags instead of their names.<br><br />
Example: result = this.tagids[Weapon.?,"+"]<br />
|-<br />
|prereqok<br />
|(Right, Number) Returns non-zero if the pick satisfies all of its pre-requisites. May not be used during evaluation.<br><br />
Example: result = this.prereqok<br />
|-<br />
|prereqnum<br />
|(Right, Number) Returns the total number of pre-requisite rules that exist for the current pick. May not be used during evaluation.<br><br />
Example: result = this.prereqnum<br />
|-<br />
|prereqmsg[''index'']<br />
|(Right, String) Returns the message associated with a specific pre-requisite test for the current pick, where the desired test is given by ''index''. The index is zero-based, so the values 0 through 4 should be used for a pick with 5 pre-requisites. If the individual pre-requisite is satisfied, the text returned is the empty string. Otherwise, the text returned is the corresponding message. May not be used during evaluation.<br><br />
Example: result = this.prereqmsg[i]<br><br />
{{note}}Retrieving the message for individual pre-requisite tests will trigger a re-calculation '''every''' time, so it is expensive and should only be used sparingly.<br />
|-<br />
|isgear<br />
|(Right, Number) Returns non-zero if the thing is a piece of gear.<br><br />
Example: result = this.isgear<br />
|-<br />
|isholdable<br />
|(Right, Number) Returns non-zero if the pick is gear that can be placed into a gear holder.<br><br />
Example: result = this.isholdable<br />
|-<br />
|stackable<br />
|(Right, Number) Returns non-zero if the thing can be stacked with other equivalent picks.<br><br />
Example: result = this.stackable<br />
|-<br />
|isbootstrap[''thing'']<br />
|(Right, Number) Returns non-zero if the current thing directly bootstraps a thing with the specified id ''thing''.<br><br />
Example: result = this.isbootstrap[thingid]<br />
|-<br />
|islinkage[''link'']<br />
|(Right, Number) Returns non-zero if the current thing possesses a linkage with the specified id ''link''.<br><br />
Example: result = this.islinkage[linkid]<br />
|-<br />
|ispanel<br />
|(Right, Number) Returns non-zero if the thing has a panel linkage defined for it. This allows generic handling of panel linkages within component scripts when the actual panel linkage is optionally controlled by the thing.<br><br />
Example: result = this.ispanel<br />
|-<br />
|sourcerefs[''spl'']<br />
|(Right, String) Generates and returns a list of all sources that the current thing is dependent upon. The generated string appends the names of the sources together, inserting the splicing string ''spl'' between each name if there is more than one. A thing with no source dependencies will return the empty string.<br><br />
Example: result = this.sourcerefs["+"]<br />
|-<br />
|amendthing[''targ'',''str'']<br />
|(Right, String) Modifies the name or description of the thing henceforth for the current actor. Once amended, all subsequent references to the thing will return the new contents. This includes the details shown within chooser tables that display things for selection by the user. The ''targ'' parameter must be either "name" or "description", specifying which facet of the thing is being amended. The new contents are given by the string expression ''str''. Always returns a value of zero.<br><br />
Example: result = this.amendthing[name,"New Name"]<br><br />
{{note}}The amendment is applied to the thing at the time of evaluation, so any access of the name or description on derived picks prior to the amendment will not show the effects of the amendment. All amendments persist until the start of the next evaluation cycle, at which time they are all reset.<br><br />
{{note}}Each actor maintains its own set of amendments, so it is perfectly valid to have multiple different actors with different amendments to the same thing.<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Language_Intrinsics&diff=3004Language Intrinsics2009-05-12T09:57:15Z<p>Rob: /* Intrinsic Functions */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
==Overview==<br />
<br />
The scripting language has an assortment of intrinsic (i.e. built-in) functions that can be used for various purposes. Some intrinsic functions operate on strings, while others operate on numbers. Some intrinsic functions return strings, while others return numbers.<br />
<br />
The purpose of intrinsic functions is to provide authors with re-usable mechanisms that can be used to perform script operations that arise on a recurring basis. For example, the Kit includes intrinsic functions for searching string, carving up strings, comparing strings, and replacing text within strings. Intrinsics are also included to determine the minimum or maximum of two values, round a number off at a certain level of precision, and generate a random number. <br />
<br />
==Intrinsic Functions==<br />
<br />
The complete list of intrinsic functions provided by the language is presented below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|length<br />
|number length(string str)<br><br />
Returns the number of characters in the string ''str''.<br />
|-<br />
|left<br />
|string left(string str, number num)<br />
Returns a new string containing the leftmost ''num'' characters of the string ''str''.<br />
|-<br />
|right<br />
|string right(string str, number num)<br />
Returns a new string containing the rightmost ''num'' characters of the string ''str''.<br />
|-<br />
|mid<br />
|string mid(string str, number start, number num)<br />
Returns a new string containing a substring of string ''str''. The new string begins with the character at position ''start'' and is ''num'' characters in length. Character positions are 0-based, so the first character in a string is at position zero (0).<br />
|-<br />
|pos<br />
|number pos(string str, string search)<br />
Return the character position where the string ''search'' first appears within ''str''. Character positions are 0-based, so the first character in a string is at position zero (0). If search does not exist within str, a value of –1 is returned.<br />
|-<br />
|uppercase<br />
|string uppercase(string str)<br />
Returns a new string that is an upper case version of string ''str''.<br />
|-<br />
|lowercase<br />
|string lowercase(string str)<br />
Returns a new string that is an lower case version of string ''str''.<br />
|-<br />
|lastpos<br />
|number lastpos(string str, string search)<br />
Return the character position where the string ''search'' '''last''' appears within ''str''. Character positions are 0-based, so the first character in a string is at position zero (0). If search does not exist within str, a value of –1 is returned.<br />
|-<br />
|asc<br />
|number asc(string str)<br />
Returns the ASCII value of the first character of string ''str''.<br />
|-<br />
|chr<br />
|string chr(number val)<br />
Returns a new string that consists of a single character, which has an ASCII value of ''val''. For example, 'chr(10)' is the newline character.<br />
|-<br />
|compare<br />
|number compare(string str1, string str2)<br />
Compare the two strings ''str1'' and ''str2''. If the strings are identical, the value 0 is returned. If ''str1'' would appear before ''str2'' in an alphabetical sort (based on the ASCII code of each character), a value less than 0 is returned. If ''str1'' would appear after ''str2'' in an alphabetical sort, a value greater than 0 is returned. Note that all uppercase characters are sorted before lowercase characters.<br />
|-<br />
|replace<br />
|string replace(string str, string match, string replace, number maxcount)<br />
Searches through the string ''str'' and replaces all instances of the string ''match'' with the string ''replace''. A maximum number of replacements is given by ''maxcount'', with a value of zero indicating that all matches should be replaced. The converted string is returned, with the original string left untouched.<br />
|-<br />
|int<br />
|number int(number val)<br />
Returns a value that represents the integer portion only of ''val''. For example, the integer portion of the value –123.45 would be –123.<br />
|-<br />
|random<br />
|number random(number range)<br />
Returns a random integer value between zero and ''range''–1.<br />
|-<br />
|minimum<br />
|number minimum(number val1, number val2)<br />
Returns the lower of the two values given.<br />
|-<br />
|maximum<br />
|number maximum(number val1, number val2)<br />
Returns the higher of the two values given.<br />
|-<br />
|power<br />
|number power(number val1, number val2)<br />
Returns ''val1'' raised to the power of ''val2'' (e.g. x^y). For example, "power(4,2)" would yield 4 squared, which is 16.<br />
|-<br />
|nthroot<br />
|number nthroot(number val, number nth)<br />
Returns the nth root of a number, where ''val'' is the value to get the root of and ''nth'' indicates the root to obtain. For example, "nthroot(16,2)" would yield the square root of 16, which is 4.<br />
|-<br />
|round<br />
|number round(number val, number dec, number dir)<br />
Returns the rounded value of ''val'', where ''dec'' indicates the number of decimal places at which to perform the rounding and ''dir'' indicates how to perform the rounding. If ''dir'' is zero, normal rounding is performed (e.g. 0.5-0.99 round up to 1.0 and 0.01-0.49 round down to 0.0). If ''dir'' is positive, the value is always rounded up. If ''dir'' is negative, the value is always rounded down. For example, "round(4.36,1,0)" would yield 4.4 and "round(4.36,1,-1)" would yield 4.3.<br />
|-<br />
|signed<br />
|string signed(number val)<br />
Returns a string that represents the properly signed version of 'val', including a prefix of either '+' or '-'. For example, the signed version of the value 1.42 would be "+1.42", while the signed version of the value -6.23 would be "-6.23".<br />
|-<br />
|decimals<br />
|string decimals(number val, number dec)<br />
Returns a string that contains the rounded value of ''val'', where ''dec'' indicates the number of decimal places at which to perform the rounding (normal rounding is always performed). In addition, if the value requires fewer decimal places than specified, zeroes are appended to bring the value to the full number of decimals. This intrinsic is ideal for formatting currency with a fixed number of decimals, so that "decimals(1.5,2) produces "1.50" instead of the normal "1.5".<br />
|-<br />
|bitwise_and<br />
|number bitwise_and(number val1, number val2)<br />
Returns the bit-wise "and" of ''val1'' and ''val2'', treating both parameters as integer values for the operation. The bit-wise "and" performs a comparison of the two values, one bit at a time, with the resulting value having a bit value of 1 only if both ''val1'' and ''val2'' have that bit set to 1. For example, "bitwise_and(14,7)" would yield 6, since the two parameters have binary representations of "1110" and "0111", which results in a value with a binary representation of "0110" (or 6).<br />
|-<br />
|bitwise_or<br />
|number bitwise_or(number val1, number val2)<br />
Returns the bit-wise "or" of ''val1'' and ''val2'', treating both parameters as integer values for the operation. The bit-wise "or" performs a comparison of the two values, one bit at a time, with the resulting value having a bit value of 1 if either ''val1'' or ''val2'' has that bit set to 1, or if both have the bit set to 1. For example, "bitwise_or(10,3)" would yield 12, since the two parameters have binary representations of "1010" and "0011", which results in a value with a binary representation of "1011" (or 12).<br />
|-<br />
|bitwise_xor<br />
|number bitwise_xor(number val1, number val2)<br />
Returns the bit-wise "xor" of ''val1'' and ''val2'', treating both parameters as integer values for the operation. The bit-wise "xor" performs a comparison of the two values, one bit at a time, with the resulting value having a bit value of 1 only if one of ''val1'' and ''val2'' have that bit set to 1 - not both. For example, "bitwise_xor(14,7)" would yield 9, since the two parameters have binary representations of "1110" and "0111", which results in a value with a binary representation of "1001" (or 9).<br />
|-<br />
|bitwise_not<br />
|number bitwise_not(number val)<br />
Returns the bit-wise "not" of ''val'', treating the parameter as an integer value for the operation. The bit-wise "not" processes the value, one bit at a time, with the resulting value having each bit possess the opposite value that it started with. This means that any bit with a value of 1 becomes 0, and vice versa. For example, "bitwise_not(9)" would yield 6, since the parameter has a binary representation of "1001", which results in a value with a binary representation of "0110" (or 6).<br />
|-<br />
|empty<br />
|number empty(string str)<br />
Returns a non-zero value if the string ''str'' has a length of zero characters, else a value of zero is returned. The "empty" intrinsic is significantly faster than using "length" and comparing it to zero.<br />
|-<br />
|plaintext<br />
|string plaintext(string str)<br />
Returns the string ''str'' with all encoded text stripped out. This provides a quick an easy mechanism for converting a string with encoded text (e.g. color usage) to its equivalent without any special formatting.<br />
|-<br />
|today<br />
|number today()<br />
Returns the current date in the proper format utilized by fields that store dates and times which users can edit via "editdate" portals. This provides a convenient mechanism for initializing journal entries and any other situations with the current date.<br />
|-<br />
|}<br />
<br />
==Examples==<br />
<br />
Simple examples of how to use each of the various intrinsic functions are provided below.<br />
<br />
<pre><br />
var str as string<br />
var len as number<br />
var piece as string<br />
var temp as string<br />
var val as number<br />
var total as number<br />
var NewLine as string<br />
var tag_count as number<br />
var link_count as number<br />
str = "hello there world there"<br />
<br />
~Get the length of the string, which is 23<br />
len = length(str)<br />
<br />
~Extract the first 5 character of the string, which is "hello"<br />
piece = left(str,5)<br />
<br />
~Extract the last 5 characters of the string, which is "there"<br />
piece = right(str,5)<br />
<br />
~Extract 5 characters from the string, starting at position 6, which is "there"<br />
piece = mid(str,6,5)<br />
<br />
~Locate the first occurrance of the string "there" within the string, which<br />
~starts at position 6<br />
val = pos(str,"there")<br />
<br />
~Locate the last occurrance of the string "there" within the string, which<br />
~starts at position 18<br />
val = lastpos(str,"there")<br />
<br />
~Convert a string to all uppercase, then to all lowercase<br />
temp = uppercase(str)<br />
temp = lowercase(str)<br />
<br />
~Get the ASCII value of the first character of the string<br />
val = asc(str)<br />
<br />
~Create a string of one character, where that character is an 'A'<br />
piece = chr(65)<br />
<br />
~Create a string of one character, where that character is a newline<br />
NewLine = chr(10)<br />
<br />
~Compare the two strings, with the first string being less than the second<br />
val = compare(str,"second")<br />
<br />
~Replace all instances of "there" with "change"<br />
temp = replace(str,"there","change",0) <br />
<br />
~Extract the integer portion only of –123.45, which is –123<br />
val = int(-123.45)<br />
<br />
~Generate a random number between 0 and 9<br />
val = random(10)<br />
<br />
~Determine the lower and higher of two values<br />
val = minimum(123.45,val)<br />
val = maximum(123.45,val)<br />
<br />
~Calculate 4 squared, which yields 16<br />
val = power(4,2)<br />
<br />
~Calculate the square root of 16, which yields 4<br />
val = nthroot(16,2)<br />
<br />
~Round the value 4.36 normally to one decimal place, which yields 4.4<br />
val = round(4.36,1,0)<br />
<br />
~Get the signed version of a value<br />
temp = signed(-123.45)<br />
<br />
~Convert a value to formatted currency<br />
temp = "$" & decimals(1.5,2)<br />
<br />
~Perform bitwise operations on two values<br />
total = bitwise_and(14,7)<br />
total = bitwise_or(10,3)<br />
total = bitwise_xor(14,7)<br />
total = bitwise_not(9)<br />
<br />
~Determine if a string is empty<br />
value = empty(str)<br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Source_Element_(Data)&diff=3003Source Element (Data)2009-05-12T09:53:48Z<p>Rob: /* The "source" Element */</p>
<hr />
<div>{{context|Kit Reference|Structural File Reference}}<br />
<br />
==The "source" Element==<br />
<br />
Authors can use the [[Sources|sources mechanism]] as the mean for defining configuration settings that the user can toggle on and off via the "Configure Hero" form. When a given source is enabled by the user, a corresponding tag is automatically added to the actor, which can then be tested within the data files. Each individual source can be defined via the "source" element. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id to utilize for this source.<br />
|-<br />
|name<br />
|Text – Name to be displayed to the user for this source. Maximum length is 50 characters.<br />
|-<br />
|abbrev<br />
|(Optional) Text – Shortened name to be displayed within the summary of enabled sources. If empty, the name is used as the abbreviation. Maximum length is 50 characters. Default: Empty.<br />
|-<br />
|description<br />
|(Optional) Text – Description of the source and what behavior(s) it governs within the data files. Default: Empty.<br />
|-<br />
|parent<br />
|(Optional) Id – Specifies the unique id of a different source that is treated as the parent of this source. All sources are displayed in a hierarchy within the "Configure Hero" form. If empty, this source is presented to the user as a top-level selection. Default: Empty.<br />
|-<br />
|sortorder<br />
|(Optional) Integer – Assigns an explicit sort order to this source, enabling the display sequence of sources to be controlled by the author (see below). All sources are sequenced in increasing sort order. Default: "99999999".<br />
|-<br />
|selectable<br />
|(Optional) Boolean – Indicates whether the source is selectable by the user. This option allows sources that are solely used to visually group sources in a hierarchy to be made non-selectable. Default: "yes".<br />
|-<br />
|maxchoices<br />
|(Optional) Integer - Specifies the maximum number of child sources that can be selected by the user at once. This makes it possible to limit the user to select only one option from a list of sources. If zero, there is no limit to the number of sources that can be selected. Default: "0".<br />
|-<br />
|minchoices<br />
|(Optional) Integer - Specifies the minimum number of child sources that must be selected by the user beneath this source. This makes it possible to require the user to select one or more options from a list of sources. If zero, there is no requirement to select any sources. Default: "0".<br />
|-<br />
|reportable<br />
|(Optional) Boolean – Indicates whether the source is included in the hierarchical summary report of selected sources. Allows authors to prune the summary report of unnecessary layers so that the informnation presented to users is both clear and reasonably compact. Default: "yes".<br />
|-<br />
|reportname<br />
|(Optional) Text – Alternate name to be displayed for the source within the hierarchical summary report. Allows for a more compact name to be used for this purpose. If empty, the name of the source is used in the report. Default: Empty.<br />
|-<br />
|default<br />
|(Optional) Boolean – Indicates whether the initial (default) state of the source for a new actor is selected or non-selected. Default: "no".<br />
|-<br />
|}<br />
<br />
{{note}}Sources that are user-selectable may '''not''' also possess child sources. If a user-selectable source is designated as the parent of another source, a compilation error will be reported.<br />
<br />
{{note}}When either "minchoices" or "maxchoices" is specified as non-zero, child sources may NOT possess child sources of their own.<br />
<br />
{{note}}By default, all sources are sorted alphabetically, based on their name. If an explicit sort order is specified, sources are sorted in increasing order. Sources with children are always sorted AFTER sources without children within the displayed list. This ensures that sources without children are grouped together and directly beneath the parent source for intuitive visual grouping. The handling of sources with/without children takes precedence over any explicit ordering that may be given.<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "source" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<source<br />
id="Output"<br />
name="Output Options"<br />
selectable="no"<br />
description="Assortment of options governing character sheet output"><br />
</source><br />
<br />
<source<br />
id="Validation"<br />
name="Include Validation Report on Sheet"<br />
abbrev="Show Validation Report"<br />
parent="Output"<br />
default="yes"<br />
description="Whether validation report is included at bottom of character sheet"><br />
</source><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Source_Element_(Data)&diff=3002Source Element (Data)2009-05-12T09:52:32Z<p>Rob: /* The "source" Element */</p>
<hr />
<div>{{context|Kit Reference|Structural File Reference}}<br />
<br />
==The "source" Element==<br />
<br />
Authors can use the [[Sources|sources mechanism]] as the mean for defining configuration settings that the user can toggle on and off via the "Configure Hero" form. When a given source is enabled by the user, a corresponding tag is automatically added to the actor, which can then be tested within the data files. Each individual source can be defined via the "source" element. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id to utilize for this source.<br />
|-<br />
|name<br />
|Text – Name to be displayed to the user for this source. Maximum length is 50 characters.<br />
|-<br />
|abbrev<br />
|(Optional) Text – Shortened name to be displayed within the summary of enabled sources. If empty, the name is used as the abbreviation. Maximum length is 50 characters. Default: Empty.<br />
|-<br />
|description<br />
|(Optional) Text – Description of the source and what behavior(s) it governs within the data files. Default: Empty.<br />
|-<br />
|parent<br />
|(Optional) Id – Specifies the unique id of a different source that is treated as the parent of this source. All sources are displayed in a hierarchy within the "Configure Hero" form. If empty, this source is presented to the user as a top-level selection. Default: Empty.<br />
|-<br />
|sortorder<br />
|(Optional) Integer – Assigns an explicit sort order to this source, enabling the display sequence of sources to be controlled by the author (see below). All sources are sequenced in increasing sort order. Default: "99999999".<br />
|-<br />
|selectable<br />
|(Optional) Boolean – Indicates whether the source is selectable by the user. This option allows sources that are solely used to visually group sources in a hierarchy to be made non-selectable. Default: "yes".<br />
|-<br />
|maxchoices<br />
|(Optional) Integer - Specifies the maximum number of child sources that can be selected by the user at once. This makes it possible to limit the user to select only one option from a list of sources. If zero, there is no limit to the number of sources that can be selected. Default: "0".<br />
{{note}}When non-zero, child sources may NOT possess child sources of their own.<br />
|-<br />
|minchoices<br />
|(Optional) Integer - Specifies the minimum number of child sources that must be selected by the user beneath this source. This makes it possible to require the user to select one or more options from a list of sources. If zero, there is no requirement to select any sources. Default: "0".<br />
{{note}}When non-zero, child sources may NOT possess child sources of their own.<br />
|-<br />
|reportable<br />
|(Optional) Boolean – Indicates whether the source is included in the hierarchical summary report of selected sources. Allows authors to prune the summary report of unnecessary layers so that the informnation presented to users is both clear and reasonably compact. Default: "yes".<br />
|-<br />
|reportname<br />
|(Optional) Text – Alternate name to be displayed for the source within the hierarchical summary report. Allows for a more compact name to be used for this purpose. If empty, the name of the source is used in the report. Default: Empty.<br />
|-<br />
|default<br />
|(Optional) Boolean – Indicates whether the initial (default) state of the source for a new actor is selected or non-selected. Default: "no".<br />
|-<br />
|}<br />
<br />
{{note}}Sources that are user-selectable may '''not''' also possess child sources. If a user-selectable source is designated as the parent of another source, a compilation error will be reported.<br />
<br />
{{note}}By default, all sources are sorted alphabetically, based on their name. If an explicit sort order is specified, sources are sorted in increasing order. Sources with children are always sorted AFTER sources without children within the displayed list. This ensures that sources without children are grouped together and directly beneath the parent source for intuitive visual grouping. The handling of sources with/without children takes precedence over any explicit ordering that may be given.<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "source" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<source<br />
id="Output"<br />
name="Output Options"<br />
selectable="no"<br />
description="Assortment of options governing character sheet output"><br />
</source><br />
<br />
<source<br />
id="Validation"<br />
name="Include Validation Report on Sheet"<br />
abbrev="Show Validation Report"<br />
parent="Output"<br />
default="yes"<br />
description="Whether validation report is included at bottom of character sheet"><br />
</source><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Source_Element_(Data)&diff=3001Source Element (Data)2009-05-12T09:51:16Z<p>Rob: /* The "source" Element */</p>
<hr />
<div>{{context|Kit Reference|Structural File Reference}}<br />
<br />
==The "source" Element==<br />
<br />
Authors can use the [[Sources|sources mechanism]] as the mean for defining configuration settings that the user can toggle on and off via the "Configure Hero" form. When a given source is enabled by the user, a corresponding tag is automatically added to the actor, which can then be tested within the data files. Each individual source can be defined via the "source" element. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id to utilize for this source.<br />
|-<br />
|name<br />
|Text – Name to be displayed to the user for this source. Maximum length is 50 characters.<br />
|-<br />
|abbrev<br />
|(Optional) Text – Shortened name to be displayed within the summary of enabled sources. If empty, the name is used as the abbreviation. Maximum length is 50 characters. Default: Empty.<br />
|-<br />
|description<br />
|(Optional) Text – Description of the source and what behavior(s) it governs within the data files. Default: Empty.<br />
|-<br />
|parent<br />
|(Optional) Id – Specifies the unique id of a different source that is treated as the parent of this source. All sources are displayed in a hierarchy within the "Configure Hero" form. If empty, this source is presented to the user as a top-level selection. Default: Empty.<br />
|-<br />
|sortorder<br />
|(Optional) Integer – Assigns an explicit sort order to this source, enabling the display sequence of sources to be controlled by the author (see below). All sources are sequenced in increasing sort order. Default: "99999999".<br />
|-<br />
|selectable<br />
|(Optional) Boolean – Indicates whether the source is selectable by the user. This option allows sources that are solely used to visually group sources in a hierarchy to be made non-selectable. Default: "yes".<br />
|-<br />
|maxchoices<br />
|(Optional) Integer - Specifies the maximum number of child sources that can be selected by the user at once. This makes it possible to limit the user to select only one option from a list of sources. If zero, there is no limit to the number of sources that can be selected. Default: "0".<br />
{{note}}When non-zero, child sources may NOT possess child sources of their own.<br />
|-<br />
|reportable<br />
|(Optional) Boolean – Indicates whether the source is included in the hierarchical summary report of selected sources. Allows authors to prune the summary report of unnecessary layers so that the informnation presented to users is both clear and reasonably compact. Default: "yes".<br />
|-<br />
|reportname<br />
|(Optional) Text – Alternate name to be displayed for the source within the hierarchical summary report. Allows for a more compact name to be used for this purpose. If empty, the name of the source is used in the report. Default: Empty.<br />
|-<br />
|default<br />
|(Optional) Boolean – Indicates whether the initial (default) state of the source for a new actor is selected or non-selected. Default: "no".<br />
|-<br />
|}<br />
<br />
{{note}}Sources that are user-selectable may '''not''' also possess child sources. If a user-selectable source is designated as the parent of another source, a compilation error will be reported.<br />
<br />
{{note}}By default, all sources are sorted alphabetically, based on their name. If an explicit sort order is specified, sources are sorted in increasing order. Sources with children are always sorted AFTER sources without children within the displayed list. This ensures that sources without children are grouped together and directly beneath the parent source for intuitive visual grouping. The handling of sources with/without children takes precedence over any explicit ordering that may be given.<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "source" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<source<br />
id="Output"<br />
name="Output Options"<br />
selectable="no"<br />
description="Assortment of options governing character sheet output"><br />
</source><br />
<br />
<source<br />
id="Validation"<br />
name="Include Validation Report on Sheet"<br />
abbrev="Show Validation Report"<br />
parent="Output"<br />
default="yes"<br />
description="Whether validation report is included at bottom of character sheet"><br />
</source><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Container_Context&diff=3000Container Context2009-05-12T09:46:16Z<p>Rob: /* Target References{{anchor|references}} */</p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "container" context represents any container within the portfolio. The container could be an actor or a gizmo.<br />
<br />
{{important}}If the container context happens to be an actor, then you can utilize the context as either a standard container context '''or''' as a [[Hero Context]].<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
From within a "container" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|state<br />
|Transitions to the [[State Context|state context]].<br><br />
Example: this.state<br />
|-<br />
|hero<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the hero that is the parent of the current container. If the current container '''is''' a hero, then this transition changes nothing but does resolve successfully.<br><br />
Example: this.hero<br />
|-<br />
|container<br />
|Transitions to the [[Container Context|container context]] corresponding to whatever container is the immediate parent of the current container. If the current container is a hero, then the transition fails to resolve.<br><br />
Example: this.container<br />
|-<br />
|parent<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the parent pick that attaches the container. If the container is a hero and has no parent pick, the transition fails to resolve.<br><br />
Example: this.parent<br />
|-<br />
|child[''id'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the first pick within the container that derives from the thing with the ''id'' specified. If the container has no child pick with the given unique id, a run-time error notification is reported to the user and the transition fails to resolve.<br><br />
Example: this.child[mypick]<br />
|-<br />
|childfound[''id'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the first pick within the container that derives from the thing with the ''id'' specified. This transition is identical to "child[id]", except that the existence of the child pick is optional. If the child is found, the transition occurs normally. If the child does not exist, no run-time error is reported, although the transition still fails to resolve.<br><br />
Example: this.childfound[mypick]<br />
|-<br />
|firstchild[''expr'',''sort'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the first pick within the container that satisfies the tag expression given by ''expr''. Since multiple children may satisfy the tag expression, an optional sort set id may be specified by ''sort'', resulting in all matching children being sorted and the first child being used after the sort is performed. The tag expression may be either a literal string or a string expression. If no matching child exists, the transition fails to resolve.<br><br />
Example: this.firstchild[expr,mysort]<br><br />
Example: this.firstchild[expr]<br />
|-<br />
|anchor<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the pick within the master actor that attaches the current actor as a minion. If the container does not reside within a minion, the transition fails to resolve.<br><br />
Example: this.anchor<br />
|-<br />
|master<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the master actor for which this container is a minion. If the container is not a minion, the transition fails to resolve.<br><br />
Example: this.master<br />
|-<br />
|minion[''id'']<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the minion actor with the given ''id'' that exists beneath the actor that possesses the current container. If the container is not a master or the specified minion does not exist, the transition fails to resolve.<br><br />
Example: this.minion[myminion]<br />
|-<br />
|herofield[''id'']<br />
|Transitions to the [[Field Context|field context]] corresponding to the field given by ''id'' that exists on the "actor" pick for the containing actor. This is a shorthand notation for "hero.child[actor].field[id]".<br><br />
Example: this.herofield[myfield]<br />
|-<br />
|usagepool[''id'']<br />
|Transitions to the [[Pool Context|pool context]] corresponding to the usage pool given by ''id'' that exists within the current container. This transition is only valid for actors, since gizmos do not possess usage pools.<br><br />
Example: this.usagepool[mypool]<br />
|-<br />
|transact<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the transaction pick that is associated with the hero governing the current context.<br><br />
Example: this.transact<br><br />
{{note}}The transaction pick is only utilized within buy and sell transactions. As such, this transition is only valid within a few select scripts.<br />
|-<br />
|dynalink[''index'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the registered dynamic linkage with the ''index'' specified. If no dynamic linkage has been registered with the given ''index'', the transition fails to resolve. The ''index'' may be an arithmetic expression that calculates the actual index value to be used.<br><br />
Example: this.dynalink[myindex]<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
There are a wide assortment of operations that can be performed on containers, some of which modify the container and some that simply retrieve information about the container. The container context applies equally to heroes and gizmos, although there are some behavioral differences that arise for some target references. The complete list of target references for containers is presented in the table below.<br />
<br />
{{note}}When a container is accessed from within a visual script, all operations are restricted to read-only behavior. Any attempts to modify a container from within a visual script will fail.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|live<br />
|(Right, Number) Returns non-zero if the container is currently considered "live", else zero if non-live. The live state for a gizmo is dictated by the live state of its parent pick that attaches it, while a hero is always considered live.<br><br />
Example: result = this.live<br />
|-<br />
|ishero<br />
|(Right, Number) Returns non-zero if the container is a hero, else zero for a gizmo.<br><br />
Example: result = this.ishero<br />
|-<br />
|isactive<br />
|(Right, Number) Returns non-zero if the container either is or resides within the currently active actor within the HL interface. If the container is or resides within a different actor, zero is returned.<br><br />
Example: result = this.isactive<br />
|-<br />
|livename<br />
|(Right, String) Returns a suitable name for the container that is based on dynamic changes made via scripts. If the container is an actor, the name of the actor is returned, else the name of the parent pick of the gizmo is returned.<br><br />
Example: result = this.livename<br />
|-<br />
|actorname<br />
|(Right, String) Returns the name of the actor that encompasses the current container context. The name is whatever has been assigned by the user.<br><br />
Example: result = this.actorname<br />
|-<br />
|playername<br />
|(Right, String) Returns the name of the player that is associated with the current lead. The name is whatever has been entered by the user.<br><br />
Example: result = this.playername<br />
|-<br />
|assign[''tag'']<br />
|(Right, Number) Assigns the indicated ''tag'' to the container. The tag must be specified using the standard "group.id" syntax. The tag is verified to exist during compilation of the script. Always returns a value of zero.<br><br />
Example: perform this.assign[skill.appraise]<br />
|-<br />
|delete[''tmpl'']<br />
|(Right, Number) Deletes all tags from the container that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard. If the template employs a wildcard, all tags matching the template are deleted. If the template specifies an explicit tag, and the tag has been assigned to the container multiple times, the tag is deleted only once, thereby providing detailed control to authors when needed. Always returns a value of zero.<br><br />
Example: perform this.delete[skill.craft?]<br />
|-<br />
|assignstr[''str'']<br />
|(Right, Number) This target reference is identical to "assign", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag to be dynamically determined via the script instead of being hard-wired at compilation. Always returns a value of zero.<br><br />
Example: perform this.assignstr[skill.appraise]<br />
|-<br />
|deletestr[''str'']<br />
|(Right, Number) This target reference is identical to "delete", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation. Always returns a value of zero.<br><br />
Example: perform this.deletestr["skill.craft?"]<br />
|-<br />
|tagis[''tmpl'']<br />
|(Right, Number) Returns non-zero if any tags assigned to the container match the tag template ''tmpl'', else zero if no tags match. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: this.tagis[skill.?]<br />
|-<br />
|tagcount[''tmpl'']<br />
|(Right, Number) Returns the number of tags assigned to the container that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagcount[skill.?]<br />
|-<br />
|tagvalue[''tmpl'']<br />
|(Right, Number) Returns the value of a tag assigned to the container that matches the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagvalue[spelllevel.wizard?]<br />
|-<br />
|tagmin[''tmpl'']<br />
|(Right, Number) Returns the minimum value of all tags assigned to the container that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmin[spelllevel.wizard?]<br />
|-<br />
|tagmax[''tmpl'']<br />
|(Right, Number) Returns the maximum value of all tags assigned to the container that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmax[spelllevel.wizard?]<br />
|-<br />
|tagunique[''tmpl'']<br />
|(Right, Number) Returns the number of unique tags assigned to the container that match the tag template ''tmpl''. If a tag is assigned multiple times, it is only counted once. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagunique[skill.?]<br />
|-<br />
|tagexpr[''expr'']<br />
|(Right, Number) Returns non-zero if the tags assigned to the container match the tag expression ''expr'', else zero is returned. The ''expr'' parameter must be a valid tag expression.<br><br />
Example: result = this.tagexpr[class.wizard & (val:spelllevel.wizard? > 5)]<br />
|-<br />
|tagcountstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagcount", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagcountstr["skill.?"]<br />
|-<br />
|tagvaluestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagvalue", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagvaluestr["spelllevel.wizard?"]<br />
|-<br />
|tagminstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmin", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagminstr["spelllevel.wizard?"]<br />
|-<br />
|tagmaxstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmax", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagmaxstr["spelllevel.wizard?"]<br />
|-<br />
|taguniquestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagunique", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.taguniquestr["skill.?"]<br />
|-<br />
|tagsearch[''str'']<br />
|(Right, Number) This target reference is identical to "tagexpr", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag expression to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagsearch["class.wizard & (val:spelllevel.wizard? > 5)"]<br><br />
{{note}}Using "tagsearch" is MUCH slower in performance than using "tagexpr", since the tagexpr must be parsed and compiled every time the script is evaluated. Be sure to use "tagexpr" whenever possible.<br />
|-<br />
|tagmatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within a reference context also exist within a match context, else zero. This allows tags from one context to be verified to exist within another context, making tag-based comparisons between two objects possible. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = hero.tagmatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|heromatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within the actor also exist within a match context, else zero. This allows tags from the actor to be verified to exist within another context, making tag-based comparisons between the actor and another object possible. The key difference between "heromatch" and "tagmatch" is that this target reference always assumes the initial context is the actor, which is then compared against the context that is transitioned to. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = this.heromatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|intersect[''init'',''curr'']<br />
|(Right, Number) Returns non-zero if tags within the initial script context also exist within the currently transitioned context, else zero. All of the tags that belong to the ''init'' tag group within the initial script context are compared against the tags that belong to the ''curr'' tag group within the current context. If any of those tags possess the identical tag id, then a match is returned (i.e. non-zero). The same tag group may be used for both contexts, and both contexts must be objects that possess tags (i.e. container, pick, or thing).<br><br />
Example: result = this.interset[MyGroup,AltGroup]<br />
|-<br />
|inherit[''id'']<br />
|(Right, Number) The container inherits all tags from one or all of its child picks. If an ''id'' is given, then all tags from the pick with that id are inherited into the container. If no parameter is given, then all tags from all child picks are inherited. The return value is the total number of tags inherited.<br><br />
Example: result = this.inherit[mypick]<br><br />
Example: result = this.inherit<br />
|-<br />
|pulltags[''tmpl'',''grp'']<br />
|(Right, Number) Copies tags from the transitioned container context into the initial pick or container context and returns the total number of tags copied. The set of tags to be copied from the transitioned context are dictated by the tag template ''tmpl''. If the second parameter is omitted, the identified tags are copied to the initial context. If the second parameter is provided, ''grp'' must specify a tag group. All tags identified by ''tmpl'' are mapped to equivalent tags within the tag group ''grp'', and those mapped tags are then assigned to the initial context. When mapping, an equivalent mapped tag must exist for all identified tags. Both the initial and transitioned script context must be either picks or containers.<br><br />
Example: result = hero.pulltags[thingid.?]<br><br />
Example: result = hero.pulltags[thingid.?,Ability]<br />
|-<br />
|pushtags[''tmpl'',''grp'']<br />
|(Right, Number) Copies tags from the initial pick or container context into the transitioned container context and returns the total number of tags copied. This target reference is identical in behavior to "pulltags", except that the tags are copied in the opposite direction.<br><br />
Example: result = hero.pushtags[thingid.?]<br><br />
Example: result = hero.pushtags[thingid.?,Ability]<br />
|-<br />
|childexists[''id'']<br />
|(Right, Number) Returns non-zero if any child pick with the given ''id'' exists within the container, else zero if no matching pick is found.<br><br />
Example: result = this.childexists[mypick]<br />
|-<br />
|childlives[''id'']<br />
|(Right, Number) Returns non-zero if any child pick with the given ''id'' exists within the container '''and''' is "live". If either no matching pick is found or all matching picks found are "non-live", zero is returned.<br><br />
Example: result = this.childlives[mypick]<br />
|-<br />
|childcount[''id'']<br />
|(Right, Number) Returns the number of child picks with the given ''id'' that exist within the container. A value of zero indicates that no matching picks were found.<br><br />
Example: result = this.childcount[mypick]<br />
|-<br />
|haschild[''str'']<br />
|(Right, Number) Returns the number of child picks within the container that match the tag expression given by ''str''. The parameter is a string expression that must contain a valid tag expression and is tested against all children of the container. The parameter can be synthesized dynamically within the script.<br><br />
Example: result = this.haschild["component.Skill"]<br />
|-<br />
|setidentity[''grp'']<br />
|(Right, Number) Assigns to the container the identity tag from the tag group ''grp'' that corresponds to the initial context of the script. The identity tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.setidentity[groupid]<br />
|-<br />
|isidentity[''grp'']<br />
|(Right, Number) As the counterpart of "setidentity", this target reference returns non-zero if the indicated identity tag has been assigned to the container and zero if not. The identity tag sought must be from the tag group ''grp'' and the tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.isidentity[groupid]<br />
|-<br />
|countidentity[''grp'']<br />
|(Right, Number) Similar to "isidentity", this target reference returns the count of the identity tags assigned to the container. The identity tag sought must be from the tag group ''grp'' and the tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.countidentity[groupid]<br />
|-<br />
|isminion<br />
|(Right, Number) Returns non-zero if the container is or resides within a minion, else zero.<br><br />
Example: result = this.isminion<br />
|-<br />
|ismaster<br />
|(Right, Number) Returns non-zero if the container is or resides within a master, else zero.<br><br />
Example: result = this.ismaster<br />
|-<br />
|hasminion[''id'']<br />
|(Right, Number) Returns non-zero if the container is or resides within an actor that possesses a minion with the specified ''id''. If the container is not within a master or does not contain the specified minion, zero is returned.<br><br />
Example: result = this.hasminion[myminion]<br />
|-<br />
|isdynalink[expr]<br />
|(Right, Number) Returns non-zero if a dynamic linkage has been defined for the implied hero context with the index specified, else zero if no linkage exists. If the container is a gizmo, then the containing actor is used as the hero context. The value given by index may be an arithmetic expression that will be resolved properly at run-time.<br><br />
Example: result = this.isdynalink[4]<br />
|-<br />
|istransact<br />
|(Right, Number) Returns non-zero if a viable transaction context exists for the container. This allows scripts to check that a transaction context exists before attempting to transition into the transaction context.<br><br />
Example: result = this.istransact<br />
|-<br />
|panelvalid[''id'']<br />
|(Left, Number) Sets the validity state of the tab panel given by ''id''. If the value assigned is zero, the panel is designated as non-valid and its name will be highlighted in red to the user. Since the default state of all panels is valid, if a non-zero value is assigned, this target reference is ignored. This means you can simply designate a panel as invalid when appropriate and do nothing when the panel is valid.<br><br />
Example: result = this.panelvalid[mypanel]<br><br />
{{note}}This target reference can only be used from within an Eval Rule or a Validate script.<br />
|-<br />
|tagnames[''tmpl'',''spl'']<br />
|(Right, String) Generates and returns a list of tags within the container. Only tags that match the tag template ''tmpl'' are included in the list. The generated string appends the names of the tags together, inserting the splicing string ''spl'' between each name if there is more than one. A container with no tags matching the template will return the empty string.<br><br />
Example: result = this.tagnames[Weapon.?,"+"]<br />
|-<br />
|tagabbrevs[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the abbreviations for all matching tags instead of their names.<br><br />
Example: result = this.tagabbrevs[Weapon.?,"+"]<br />
|-<br />
|tagids[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the unique ids for all matching tags instead of their names.<br><br />
Example: result = this.tagids[Weapon.?,"+"]<br />
|-<br />
|weight<br />
|(Right, Number) Returns the total weight of all "gear" picks within the container.<br><br />
Example: result = this.weight<br />
|-<br />
|gearlist[''spl'',''expr'']<br />
|(Right, String) Generates and returns a list of gear held within the container, which means gear that is '''not''' held within another gear holder. Only picks that are designated as gear and that are not assigned to a holder are candidates for inclusion in the list. Each candidate piece of gear is compared against the tag expression ''expr'', and only those that satisfy the tag expression are included in the final list. The generated string appends the names of all pieces of gear together, inserting the splicing string ''spl'' between each name if there is more than one. A container that holds no gear matching the tag expression will return the empty string.<br><br />
Example: result = this.gearlist["+",!Equipment.Natural]<br />
|-<br />
|geartree[''expr'']<br />
|(Right, String) Generates and returns a hierarchical tree view of the gear picks possessed by the container context, as appropriate for use within the Dashboard and Tactical Console. Only picks that are designated as gear are candidates for inclusion in the report. Each candidate piece of gear is compared against the tag expression ''expr'', and only those that satisfy the tag expression are included in the final report. All gear is output in a hierarchy, where each level of containment is indented beneath the level above it. Gear within child gizmos is also included, with indentation as if the gizmo were a holder within the container and its contents indented beneath it.<br><br />
Example: result = this.geartree[!Helper.NoMove]<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Pick_Context&diff=2999Pick Context2009-05-12T09:45:06Z<p>Rob: </p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "pick" context represents any pick throughout the portfolio, located within any container.<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
From within a "pick" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|state<br />
|Transitions to the [[State Context|state context]].<br><br />
Example: this.state<br />
|-<br />
|hero<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the hero that contains the current pick.<br><br />
Example: this.hero<br />
|-<br />
|container<br />
|Transitions to the [[Container Context|container context]] corresponding to the immediate container of the current pick, whether it be a hero or a gizmo.<br><br />
Example: this.container<br />
|-<br />
|parent<br />
|Transitions to the [[Container Context|container context]] corresponding to the immediate container of the current pick, just like the "container" transition.<br><br />
Example: this.parent<br />
|-<br />
|gizmo<br />
|Transitions to the [[Container Context|container context]] corresponding to the child gizmo directly attached by the pick. If the pick has no attached child gizmo, the transition fails to resolve.<br><br />
Example: this.gizmo<br />
|-<br />
|field[''id'']<br />
|Transitions to the [[Field Context|field context]] corresponding to the field within the current pick that has the ''id'' specified. If the given field does not exist for the current pick, the transition fails to resolve.<br><br />
Example: this.field[myfield]<br><br />
{{note}}Within things and picks, there are a number of pre-defined pseudo-fields that are always defined and that allow access to facets of the pick that are not governed by user-defined fields. These pseudo-fields behave like normal fields in all respects within scripts, except that some are read-only. The list of pre-defined fields can be found elsewhere in the [[Kit Reference]] documentation.<br />
|-<br />
|root<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the root pick that bootstraps the current pick into the container. If the current pick is not bootstrapped, or if the current pick is designated as unique and can possess multiple bootstraps, the transition fails to resolve.<br><br />
Example: this.source<br />
|-<br />
|gearholder<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the pick that is assigned as the gear holder of the current pick. If the current pick is not held, the transition fails to resolve. If the current pick is not gear, an error is reported and the transition fails to resolve.<br><br />
Example: this.gearholder<br />
|-<br />
|linkage[''id'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the linkage with the ''id'' specified. If the linkage is not defined, an error is reported.<br><br />
Example: this.linkage[mylink]<br />
|-<br />
|anchor<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the pick within the master actor that attaches the current actor as a minion. If the pick does not reside within a minion, the transition fails to resolve.<br><br />
Example: this.anchor<br />
|-<br />
|master<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the master actor for which this pick's container is a minion. If the pick is not within a minion, the transition fails to resolve.<br><br />
Example: this.master<br />
|-<br />
|minion[''id'']<br />
|Transitions to the [[Hero Context|hero context]] corresponding to the minion actor with the given ''id'' that exists beneath the actor that possesses the current pick. The ''id'' can be omitted, in which case the minion is implicitly identified and must be directly attached by the current pick. If the pick does not reside within a master or the specified minion does not exist, the transition fails to resolve.<br><br />
Example: this.minion[myminion]<br><br />
Example: this.minion<br />
|-<br />
|herofield[''id'']<br />
|Transitions to the [[Field Context|field context]] corresponding to the field given by ''id'' that exists on the "actor" pick for the containing actor. This is a shorthand notation for "hero.child[actor].field[id]".<br><br />
Example: this.herofield[myfield]<br />
|-<br />
|usagepool[''id'']<br />
|Transitions to the [[Pool Context|pool context]] corresponding to the usage pool with the ''id'' specified for the current pick.<br><br />
Example: this.usagepool[mypool]<br />
|-<br />
|shadow<br />
|Transitions to the [[Container Context|container context]] corresponding to the container into which the current pick is shadowed. If the pick is not shadowed, an error is reported and the transition fails to resolve.<br><br />
Example: this.shadow<br />
|-<br />
|origin<br />
|Transitions to the [[Container Context|container context]] corresponding to the container into which the current pick was originally added. If the pick is displaced, the container is where the pick was added by the user. If not displaced, the container is simply the container for the pick.<br><br />
Example: this.origin<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
Picks are going to be the most prevalent object type within any set of data files, so it's no surprise that picks have the largest and most varied assortment of target references. The complete list of target references for picks is presented in the table below.<br />
<br />
{{note}}When a pick is accessed from within a visual script, all operations are restricted to read-only behavior. Any attempts to modify a pick from within a visual script will fail.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|livename<br />
|(Right, String) Returns an appropriate name for the pick. If the user has explicitly named the pick, that name is returned. If not named by the user, any name change dictated by scripts is returned. Otherwise, the name of the thing is used.<br><br />
Example: result = this.livename<br />
|-<br />
|idstring<br />
|(Right, String) Returns the unique id of the thing as a string. This can be extremely handy when synthesizing tag templates and tag expressions on-the-fly via scripts.<br><br />
Example: result = this.idstring<br />
|-<br />
|valid<br />
|(Right, Number) Returns non-zero if the pick is valid and zero if the pick has been designated as non-valid. Validity is controlled via mechanisms like pre-requisite tests and Eval Rules.<br><br />
Example: result = this.valid<br />
|-<br />
|isuser<br />
|(Right, Number) Returns non-zero if the pick was directly added by the user, else zero. Picks that are bootstrapped by containers or other picks are not considered user-added, even if the pick that does the bootstrapping '''is''' user-added.<br><br />
Example: result = this.isuser<br />
|-<br />
|ispick<br />
|(Right, Number) Returns non-zero if the current context is a pick and zero if it's a thing. This provides a means to discern the nature of the context when the circumstances make a distinction uncertain, such as within procedures.<br><br />
Example: result = this.ispick<br />
|-<br />
|isroot<br />
|(Right, Number) Returns non-zero if the pick has been bootstrapped and therefore has a root pick available.<br><br />
Example: result = this.isroot<br />
|-<br />
|isgizmo<br />
|(Right, Number) Returns non-zero if the pick directly attaches a child gizmo.<br><br />
Example: result = this.isgizmo<br />
|-<br />
|isentity<br />
|(Right, Number) Returns non-zero if the pick directly attaches a child entity.<br><br />
Example: result = this.isentity<br><br />
{{note}}This target reference is essentially identical to "isgizmo" (above).<br />
|-<br />
|isunique<br />
|(Right, Number) Returns non-zero if the pick behaves as unique.<br><br />
Example: result = this.isunique<br />
|-<br />
|shadowed<br />
|(Right, Number) Returns non-zero if the pick has been shadowed and also exists within an alternate container.<br><br />
Example: result = this.shadowed<br />
|-<br />
|displaced<br />
|(Right, Number) Returns non-zero if the pick has been displaced and also exists within an alternate container.<br><br />
Example: result = this.displaced<br />
|-<br />
|countme<br />
|(Right, Number) Returns the total number of instances of the current pick that exist within the container of the current pick. As long as the thing id matches, two picks are considered equivalent. If stacking is utilized, this target reference returns the total number of distinct picks within the container, ignoring all stacked quantities.<br><br />
Example: result = this.countme<br />
|-<br />
|uniqcount<br />
|(Right, Number) Return the number of times that a unique pick has been added to the current container. Every time a unique pick is added, whether by the user or via bootstrapping, it's reference count is incremented, and this target reference returns the reference count. If the pick is not unique, a run-time error is reported and zero is returned.<br><br />
Example: result = this.uniqcount<br />
|-<br />
|assign[''tag'']<br />
|(Right, Number) Assigns the indicated ''tag'' to the pick. The tag must be specified using the standard "group.id" syntax. The tag is verified to exist during compilation of the script. Always returns a value of zero.<br><br />
Example: perform this.assign[skill.appraise]<br />
|-<br />
|delete[''tmpl'']<br />
|(Right, Number) Deletes all tags from the pick that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard. If the template employs a wildcard, all tags matching the template are deleted. If the template specifies an explicit tag, and the tag has been assigned to the pick multiple times, the tag is deleted only once, thereby providing detailed control to authors when needed. Always returns a value of zero.<br><br />
Example: perform this.delete[skill.craft?]<br />
|-<br />
|assignstr[''str'']<br />
|(Right, Number) This target reference is identical to "assign", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag to be dynamically determined via the script instead of being hard-wired at compilation. Always returns a value of zero.<br><br />
Example: perform this.assignstr[skill.appraise]<br />
|-<br />
|deletestr[''str'']<br />
|(Right, Number) This target reference is identical to "delete", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation. Always returns a value of zero.<br><br />
Example: perform this.deletestr["skill.craft?"]<br />
|-<br />
|tagis[''tmpl'']<br />
|(Right, Number) Returns non-zero if any tags assigned to the pick match the tag template ''tmpl'', else zero if no tags match. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: this.tagis[skill.?]<br />
|-<br />
|tagcount[''tmpl'']<br />
|(Right, Number) Returns the number of tags assigned to the pick that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagcount[skill.?]<br />
|-<br />
|tagvalue[''tmpl'']<br />
|(Right, Number) Returns the value of a tag assigned to the pick that matches the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagvalue[spelllevel.wizard?]<br />
|-<br />
|tagmin[''tmpl'']<br />
|(Right, Number) Returns the minimum value of all tags assigned to the pick that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmin[spelllevel.wizard?]<br />
|-<br />
|tagmax[''tmpl'']<br />
|(Right, Number) Returns the maximum value of all tags assigned to the pick that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmax[spelllevel.wizard?]<br />
|-<br />
|tagunique[''tmpl'']<br />
|(Right, Number) Returns the number of unique tags assigned to the pick that match the tag template ''tmpl''. If a tag is assigned multiple times, it is only counted once. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagunique[skill.?]<br />
|-<br />
|tagexpr[''expr'']<br />
|(Right, Number) Returns non-zero if the tags assigned to the pick match the tag expression ''expr'', else zero is returned. The ''expr'' parameter must be a valid tag expression.<br><br />
Example: result = this.tagexpr[class.wizard & (val:spelllevel.wizard? > 5)]<br />
|-<br />
|tagcountstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagcount", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagcountstr["skill.?"]<br />
|-<br />
|tagvaluestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagvalue", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagvaluestr["spelllevel.wizard?"]<br />
|-<br />
|tagminstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmin", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagminstr["spelllevel.wizard?"]<br />
|-<br />
|tagmaxstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmax", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagmaxstr["spelllevel.wizard?"]<br />
|-<br />
|taguniquestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagunique", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.taguniquestr["skill.?"]<br />
|-<br />
|tagsearch[''str'']<br />
|(Right, Number) This target reference is identical to "tagexpr", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag expression to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagsearch["class.wizard & (val:spelllevel.wizard? > 5)"]<br><br />
{{note}}Using "tagsearch" is MUCH slower in performance than using "tagexpr", since the tagexpr must be parsed and compiled every time the script is evaluated. Be sure to use "tagexpr" whenever possible.<br />
|-<br />
|tagmatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within a reference context also exist within a match context, else zero. This allows tags from one context to be verified to exist within another context, making tag-based comparisons between two objects possible. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = hero.tagmatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|heromatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within the actor also exist within a match context, else zero. This allows tags from the actor to be verified to exist within another context, making tag-based comparisons between the actor and another object possible. The key difference between "heromatch" and "tagmatch" is that this target reference always assumes the initial context is the actor, which is then compared against the context that is transitioned to. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = hero.heromatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|intersect[''init'',''curr'']<br />
|(Right, Number) Returns non-zero if tags within the initial script context also exist within the currently transitioned context, else zero. All of the tags that belong to the ''init'' tag group within the initial script context are compared against the tags that belong to the ''curr'' tag group within the current context. If any of those tags possess the identical tag id, then a match is returned (i.e. non-zero). The same tag group may be used for both contexts, and both contexts must be objects that possess tags (i.e. container, pick, or thing).<br><br />
Example: result = this.interset[MyGroup,AltGroup]<br />
|-<br />
|pulltags[''tmpl'',''grp'']<br />
|(Right, Number) Copies tags from the transitioned pick context into the initial pick or container context and returns the total number of tags copied. The set of tags to be copied from the transitioned context are dictated by the tag template ''tmpl''. If the second parameter is omitted, the identified tags are copied to the initial context. If the second parameter is provided, ''grp'' must specify a tag group. All tags identified by ''tmpl'' are mapped to equivalent tags within the tag group ''grp'', and those mapped tags are then assigned to the initial context. When mapping, an equivalent mapped tag must exist for all identified tags. Both the initial and transitioned script context must be either picks or containers.<br><br />
Example: result = this.pulltags[thingid.?]<br><br />
Example: result = this.pulltags[thingid.?,Ability]<br />
|-<br />
|pushtags[''tmpl'',''grp'']<br />
|(Right, Number) Copies tags from the initial pick or container context into the transitioned pick context and returns the total number of tags copied. This target reference is identical in behavior to "pulltags", except that the tags are copied in the opposite direction.<br><br />
Example: result = this.pushtags[thingid.?]<br><br />
Example: result = this.pushtags[thingid.?,Ability]<br />
|-<br />
|forward[''tmpl'',''target'']<br />
|(Right, Number) Copies tags from the pick context into the corresponding container and returns the total number of tags copied. The set of tags to be copied are dictated by the tag template ''tmpl''. The tags are copied to the container dictated by ''target'', which must be one of the following values:<br />
<ul class="sets"><br />
<li>parent – Tags are copied to the standard parent container of the pick.</li><br />
<li>shadow – Tags are copied to the shadow container of the pick, which is only applicable when the pick has been shadowed.</li><br />
<li>origin – Tags are copied to the origin container of the pick, which is only applicable when the pick has been displaced.</li><br />
</ul><br />
The ''target'' parameter may be omitted, in which case all tags matching the tag template are copied to the "parent" container. Both parameters may also be omitted, in which case all tags within the pick are copied to the "parent" container.<br><br />
Example: result = this.forward[thingid.?,shadow]<br><br />
Example: result = this.forward[thingid.?]<br><br />
Example: result = this.forward<br />
|-<br />
|setidentity[''grp'']<br />
|(Right, Number) Assigns to the pick the identity tag from the tag group ''grp'' that corresponds to the initial context of the script. The identity tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.setidentity[groupid]<br />
|-<br />
|isidentity[''grp'']<br />
|(Right, Number) As the counterpart of "setidentity", this target reference returns non-zero if the indicated identity tag has been assigned to the pick and zero if not. The identity tag sought must be from the tag group ''grp'' and the tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.isidentity[groupid]<br />
|-<br />
|countidentity[''grp'']<br />
|(Right, Number) Similar to "isidentity", this target reference returns the count of the identity tags assigned to the pick. The identity tag sought must be from the tag group ''grp'' and the tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]].<br><br />
Example: result = this.countidentity[groupid]<br />
|-<br />
|shareidentity[''grp'',''pick'']<br />
|(Right, Number) The pick with unique id ''pick'' is assigned the identity tag from the tag group ''grp'' for the current pick context. This allows a script to explicitly identify a pick and assign an identity tag to it. The identity tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]]. If the specified pick does not exist, a run-time error is reported. A value of zero is always returned.<br><br />
Example: perform this.shareidentity[ClassSkill,mypick]<br />
|-<br />
|pullidentity[''grp'']<br />
|(Right, Number) Locates the identity tag from the tag group ''grp'' for the current pick context and assigns it to the initial script context. The identity tag id is dictated by the initial context of the script. For more details, [[Identity Target References|please check here]]. If the initial script context is neither a pick nor a container, a run-time error is reported. A value of zero is always returned.<br><br />
Example: perform this.pullidentity[groupid]<br />
|-<br />
|tagnames[''tmpl'',''spl'']<br />
|(Right, String) Generates and returns a list of tags within the pick. Only tags that match the tag template ''tmpl'' are included in the list. The generated string appends the names of the tags together, inserting the splicing string ''spl'' between each name if there is more than one. A pick with no tags matching the template will return the empty string.<br><br />
Example: result = this.tagnames[Weapon.?,"+"]<br />
|-<br />
|tagabbrevs[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the abbreviations for all matching tags instead of their names.<br><br />
Example: result = this.tagabbrevs[Weapon.?,"+"]<br />
|-<br />
|tagids[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the unique ids for all matching tags instead of their names.<br><br />
Example: result = this.tagids[Weapon.?,"+"]<br />
|-<br />
|prereqok<br />
|(Right, Number) Returns non-zero if the pick satisfies all of its pre-requisites. May not be used during evaluation.<br><br />
Example: result = this.prereqok<br />
|-<br />
|prereqnum<br />
|(Right, Number) Returns the total number of pre-requisite rules that exist for the current pick. May not be used during evaluation.<br><br />
Example: result = this.prereqnum<br />
|-<br />
|prereqmsg[''index'']<br />
|(Right, String) Returns the message associated with a specific pre-requisite test for the current pick, where the desired test is given by ''index''. The index is zero-based, so the values 0 through 4 should be used for a pick with 5 pre-requisites. If the individual pre-requisite is satisfied, the text returned is the empty string. Otherwise, the text returned is the corresponding message. May not be used during evaluation.<br><br />
Example: result = this.prereqmsg[i]<br><br />
{{note}}Retrieving the message for individual pre-requisite tests will trigger a re-calculation '''every''' time, so it is expensive and should only be used sparingly.<br />
|-<br />
|isgear<br />
|(Right, Number) Returns non-zero if the pick is a piece of gear.<br><br />
Example: result = this.isgear<br />
|-<br />
|isholdable<br />
|(Right, Number) Returns non-zero if the pick is gear that can be placed into a gear holder.<br><br />
Example: result = this.isholdable<br />
|-<br />
|isgearheld<br />
|(Right, Number) Returns non-zero if the pick is a piece of gear that is currently being held within another piece of gear.<br><br />
Example: result = this.isgearheld<br />
|-<br />
|gearcount<br />
|(Right, Number) Returns the total number of pieces of gear that are currently being held within the pick. If the pick is not a gear holder, the count will always be zero.<br><br />
Example: result = this.gearcount<br />
|-<br />
|gearpath[''spl'']<br />
|(Right, String) Generates and returns the entire gear containment hierarchy for this piece of gear. The hierarchy starts with the topmost gear holder of this pick and works downward through the immediate holder of the pick, showing the sequence. The generated string lists all the holders by name, inserting the splicing string ''spl'' between each name if there is more than one. A piece of gear that is not held will return the empty string.<br><br />
Example: result = this.gearpath["+"]<br />
|-<br />
|isgearlist<br />
|(Right, Number) Returns non-zero if the pick is a gear holder and can contain a list of held gear, regardless of whether any gear is actually held.<br><br />
Example: result = this.isgearlist<br />
|-<br />
|gearlist[''spl'',''expr'']<br />
|(Right, String) Generates and returns a list of gear held within the pick, provided the pick is a gear holder. Only picks that are designated as gear and that are assigned to this pick as their holder are candidates for inclusion in the list. Each candidate piece of gear is compared against the tag expression ''expr'', and only those that satisfy the tag expression are included in the final list. The generated string appends the names of all pieces of gear together, inserting the splicing string ''spl'' between each name if there is more than one. A pick that holds no gear matching the tag expression will return the empty string.<br><br />
Example: result = this.gearlist["+",!Equipment.Natural]<br />
|-<br />
|stackable<br />
|(Right, Number) Returns non-zero if the pick can be stacked with other equivalent picks.<br><br />
Example: result = this.stackable<br />
|-<br />
|isbootstrap[''thing'']<br />
|(Right, Number) Returns non-zero if the current pick directly bootstraps a pick with the specified id ''thing''.<br><br />
Example: result = this.isbootstrap[thingid]<br />
|-<br />
|rootnames[''spl'']<br />
|(Right, String) Generates and returns a list of picks that bootstrap the current pick. The generated string appends the names of the root picks together, inserting the splicing string ''spl'' between each name if there is more than one. A pick with no root picks will return the empty string.<br><br />
Example: result = this.rootnames["+"]<br />
|-<br />
|islinkage[''link'']<br />
|(Right, Number) Returns non-zero if the current pick possesses a linkage with the specified id ''link''.<br><br />
Example: result = this.islinkage[linkid]<br />
|-<br />
|autonomous<br />
|(Right, Number) Returns non-zero if the pick has '''zero''' other picks that are currently based upon it. Picks that have other picks based upon them are typically made non-deletable, so this target reference provides a means to detect that condition.<br><br />
Example: result = this.autonomous<br />
|-<br />
|creation<br />
|(Right, Number) Returns non-zero if the pick was added to the character during "creation" mode and zero if added during "advancement" mode. This makes it possible to validate options that are only seelctable during character creation. If advancement mode is not enabled for the game system, all picks are always added in creation mode.<br><br />
Example: result = this.creation<br />
|-<br />
|setfocus<br />
|(Right, Number) Establishes the current pick context as the new "pick focus". Thereafter, the script can use the "focus." initial context transition to directly access the pick that is setup as the focus. Always returns a value of zero.<br><br />
Example: perform this.setfocus<br />
|-<br />
|ispanel<br />
|(Right, Number) Returns non-zero is the pick has a panel linkage defined for it. This allows generic handling of panel linkages within component scripts when the actual panel linkage is optionally controlled by the thing.<br><br />
Example: result = this.ispanel<br />
|-<br />
|panelactive<br />
|(Right, Number) Returns non-zero if the current active tab panel is the one specified as a panel linkage for the current pick. If the pick has no designated panel linkage, zero is returned.<br><br />
Example: result = this.panelactive<br />
|-<br />
|sourcerefs[''spl'']<br />
|(Right, String) Generates and returns a list of all sources that the current pick is dependent upon. The generated string appends the names of the sources together, inserting the splicing string ''spl'' between each name if there is more than one. A pick with no source dependencies will return the empty string.<br><br />
Example: result = this.sourcerefs["+"]<br />
|-<br />
|uniqindex<br />
|(Right, Number) Returns an integer value that uniquely identifies the pick throughout the entire portfolio. This value is *not* guaranteed to be the same when the portfolio is reloaded. It is intended for use in differentiating picks within rules and should never be saved in any way or otherwise used as a persistent reference.<br><br />
Example: result = this.uniqindex<br />
|-<br />
|dynareg[''index'']<br />
|(Right, Number) Registers a dynamic linkage to the current pick context and assigns that linkage the unique index value ''index''. Once registered, the current pick can be accessed from the "hero" context via the "dynalink" context transition. This makes it possible to dynamically setup access to a special pick throughout an actor. This target reference can only be utilized from within a [[Creation Script]]. Always returns a value of zero.<br><br />
Example: perform this.dynareg[42]<br />
|-<br />
|isminion<br />
|(Right, Number) Returns non-zero if the pick resides within a minion, else zero.<br><br />
Example: result = this.isminion<br />
|-<br />
|ismaster<br />
|(Right, Number) Returns non-zero if the pick resides within a master, else zero.<br><br />
Example: result = this.ismaster<br />
|-<br />
|hasminion[''id'']<br />
|(Right, Number) Returns non-zero if the pick resides within an actor that possesses a minion with the specified ''id''. The parameter can be omitted, in which case non-zero is returned only if the pick directly attaches a minion. If the pick is not within a master or the specified minion does not exist, zero is returned.<br><br />
Example: result = this.hasminion[myminion]<br><br />
Example: result = this.hasminion<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=MenuThings_Element_(Data)&diff=2998MenuThings Element (Data)2009-05-12T09:41:28Z<p>Rob: /* The "menu_things" Element */</p>
<hr />
<div>{{context|Kit Reference|Data File Reference|Portal Element (Data)}}<br />
<br />
==The "menu_things" Element==<br />
<br />
The "menu_things" element is used when the user needs to select an item that exists within the data files. For example, an in-play adjustment can select an attribute or skill that the actor possesses, or an ability can select a weapon type that receives a bonus. The common thread is that the options presented in the menu are either things or picks within the data files. The complete list of attributes for this element is below.<br />
<br />
{{important}}Within a thing-based menu, the selected thing is '''not''' added to the container as a new pick. The thing is merely identified for reference and can be accessed via the menu, but no new pick appears within the container. Only tables and choosers can actually add new picks to a container.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|field<br />
|Id – Specifies the unique id of the field whose contents reflect the current selection from the menu. The field must be a value-based field of style "menu" and must exist within the pick/thing associated with the containing template. If this portal is not defined within a template, a menu is not allowed.<br />
|-<br />
|component<br />
|Id – Specifies the unique id of the component that all choices must be derived from.<br />
|-<br />
|defthing<br />
|(Optional) Id – Specifies the unique id of the thing to pre-select as the default choice within the menu. If empty, no default selection is made. Default: Empty.<br />
|-<br />
|usepicks<br />
|(Optional) Set – Designates whether the menu is populated with things or picks, and, if the latter, where the list of picks is retrieved from. Must be one of these values:<br />
<ul class="sets"><br />
<li>thing – The menu is populated with things.</li><br />
<li>container – The menu is populated with picks from the container of the pick associated with the template.</li><br />
<li>hero – The menu is populated with picks from the actor.</li><br />
<li>actor – Same as "hero".</li><br />
<li>Default: "thing".</li><br />
</ul><br />
|-<br />
|sortset<br />
|(Optional) Id – Specifies the unique id of the sort set to be used to determine the sequence in which the items are listed in the menu. If empty, the items are listed alphabetically. Default: Empty.<br />
|-<br />
|maxvisible<br />
|(Optional) Integer – Specifies the maximum number of items that will be visible at one time within the menu when the user opens it for selection. If there are more items to choose from, a scroller will allow the user to access them. Default: "5".<br />
|-<br />
|usepicksfield<br />
|(Optional) Id – Specifies the unique id of a value-based field that dynamically dictates when the menu is populated with things or picks. If empty, the "usepicks" attribute dictates the behavior. If specified, the field value dictates the behavior according to the list below. Default: Empty.<br />
<ul class="sets"><br />
<li>0 – The menu is populated with things.</li><br />
<li>1 – The menu is populated with picks from the container of the pick associated with the template.</li><br />
<li>2 – The menu is populated with picks from the actor.</li><br />
</ul><br />
|-<br />
|candidatefield<br />
|(Optional) Id – Specifies the unique id of a text-based field that contains the [[Candidate Tag Expression|Candidate tag expression]] to be used when populating the menu options. Default: Empty.<br><br />
{{important}}This mechanism is secondary to the "candidate" element, so the field is '''ignored''' if the "candidate" element is non-empty.<br />
|-<br />
|namefield<br />
|(Optional) Id - Specifies the unique id of a text-based field that is used instead of the "name" of each thing shown within the array. This makes it possible to customize the name to be displayed in the menu differently from the standard name shown for the thing.<br />
|-<br />
|}<br />
<br />
The "menu_things" element also possesses child elements that define additional facets of the portal. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[#candidate|candidate]]<br />
|An optional "candidate" element may appear as defined by the given link. This element defines a [[Candidate Tag Expression]] for the portal.<br />
|-<br />
|[[#change|change]]<br />
|An optional "change" element may appear as defined by the given link. This element defines a [[Change Script]] for the portal.<br />
|-<br />
|}<br />
<br />
==The "candidate" Element{{anchor|candidate}}==<br />
<br />
The "candidate" element defines a [[Candidate Tag Expression]] for the portal that limits the set of things/picks that are available for selection. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|PCDATA<br />
|TagExpr – Specifies the code comprising the Candidate tag expression.<br />
|-<br />
|}<br />
<br />
==The "change" Element{{anchor|change}}==<br />
<br />
The "change" element defines a [[Change Script]] for the portal that is invoked whenever the user selects a new choice from the list of options. This script allows the implications of the new selection to be integrated and the display updated. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|PCDATA<br />
|Script – Specifies the code comprising the Change script.<br />
|-<br />
|}<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a thing-based menu portal might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<portal id="menu" style="menuNormal"><br />
<menu_things field="adjChosen" component="none" maxvisible="20"<br />
usepicksfield="adjUsePick" candidatefield="adjCandid"><br />
<candidate></candidate><br />
</menu_things><br />
</portal><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Field_Context&diff=2997Field Context2009-05-12T09:36:16Z<p>Rob: /* Target References{{anchor|references}} */</p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "field" context represents any field within any pick or thing. If within a thing, all aspects of the field are read-only.<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
From within a "field" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|state<br />
|Transitions to the [[State Context|state context]].<br><br />
Example: this.state<br />
|-<br />
|pick<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the pick that contains the current field.<br><br />
Example: this.pick<br />
|-<br />
|chosen<br />
|Transitions to either the [[Pick Context|pick context]] corresponding to the user-selected pick stored within the field or the [[Thing Context|thing context]] corresponding to the user-selected thing stored within the field, depending on the nature of the field. The transition is only valid for use on fields that store menu selections made by the user.<br><br />
Example: this.chosen<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
There are a variety of ways to access and manipulate the contents of fields. The complete list of target references for fields is presented in the table below.<br />
<br />
{{note}}When a field is accessed from within a thing or a visual script, all operations are restricted to read-only behavior. Any attempts to modify a field from within a thing context or via a visual script will fail.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|value<br />
|(Left, Right, Number) Accesses the contents of the field as a numeric value. If the field is text and the contents retrieved, the contents are automatically converted to a suitable value.<br><br />
Example: result = this.field[myfield].value<br><br />
Example: this.field[myfield].value = 42<br />
|-<br />
|text<br />
|(Left, Right, String) Accesses the contents of the field as a string. If the field is numeric can the contents retrieved, the contents are automatically converted to a suitable string.<br><br />
Example: result = this.field[myfield].text<br><br />
Example: this.field[myfield].text = "hello"<br />
|-<br />
|isempty<br />
|(Right, Number) Returns non-zero if the field contains the empty string and zero if it contains text of any length. If used on a numeric field or with an array or matrix, an error is reported. Testing of array and matrix elements must be done via the "compare" intrinsic.<br><br />
Example: result = this.field[myfield].isempty<br />
|-<br />
|ischanged<br />
|(Right, Number) Returns non-zero if the field contents have been changed in any way from its original starting state. This can detect a field that has been changed by the user or via a script.<br><br />
Example: result = this.field[myfield].ischanged<br />
|-<br />
|reset<br />
|(Right, Number) The contents of the field are reset to the initial default value for the thing. A value of zero is always returned.<br><br />
Example: perform this.field[myfield].reset<br />
|-<br />
|ischosen<br />
|(Right, Number) Returns non-zero if the field contains a pick or a thing that was selected via a menu. If the field is associated with a menu and no selection has yet been made, zero is returned.<br><br />
Example: result = this.field[myfield].ischosen<br />
|-<br />
|delta<br />
|(Left, Right, Number) Accesses the delta component of a user field for manipulation separately from the user-specified value. The field must be explicitly configured to support delta processing.<br><br />
Example: result = this.field[myfield].delta<br><br />
Example: this.field[myfield].delta = 2<br />
|-<br />
|arrayvalue[''row'']<br />
|(Left, Right, Number) Accesses the contents of a specific element of the array-based field as a numeric value. The index of the element is given by ''row'', where the index is a zero-based value that must be less than the number of rows in the array. If the field is text and the contents retrieved, the contents are automatically converted to a suitable value.<br><br />
Example: result = this.field[myfield].arrayvalue[3]<br><br />
Example: this.field[myfield].arrayvalue[3] = 42<br />
|-<br />
|arraytext[''row'']<br />
|(Left, Right, Number) Accesses the contents of a specific element of the array-based field as a string. The index of the element is given by ''row'', where the index is a zero-based value that must be less than the number of rows in the array. If the field is numeric can the contents retrieved, the contents are automatically converted to a suitable string.<br><br />
Example: result = this.field[myfield].arraytext[3]<br><br />
Example: this.field[myfield].arraytext[3] = "hello"<br />
|-<br />
|matrixvalue[''row'',''col'']<br />
|(Left, Right, Number) Accesses the contents of a specific element of the matrix-based field as a numeric value. The index of the element is given by ''row'' and ''col'', where the indices are zero-based values that must be less than the number of rows and columns in the matrix, respectively. If the field is text and the contents retrieved, the contents are automatically converted to a suitable value.<br><br />
Example: result = this.field[myfield].matrixvalue[3,4]<br><br />
Example: this.field[myfield].matrixvalue[3,4] = 42<br />
|-<br />
|matrixtext[''row'',''col'']<br />
|(Left, Right, String) Accesses the contents of a specific element of the matrix-based field as a string. The index of the element is given by ''row'' and ''col'', where the indices are zero-based values that must be less than the number of rows and columns in the matrix, respectively. If the field is numeric and the contents retrieved, the contents are automatically converted to a suitable string.<br><br />
Example: result = this.field[myfield].matrixvalue[3,4]<br><br />
Example: this.field[myfield].matrixvalue[3,4] = 42<br />
|-<br />
|arraydump<br />
|(Right, String) Generates and returns a text string that contains the values of all elements in the array, with the results appropriately formatted for easy viewing. This mechanism is ideal for use within "debug" statements to help isolate scripting problems with arrays. Only usable with array-based fields.<br><br />
Example: result = this.field[myfield].arraydump<br><br />
{{note}}The generated output is capped to the limits of the debug output mechanism, so using this mechanism with large arrays and/or text-based fields may result in the output being truncated.<br />
|-<br />
|matrixdump<br />
|(Right, String) Generates and returns a text string that contains the values of all elements in the matrix, with the results appropriately formatted for easy viewing. This mechanism is ideal for use within "debug" statements to help isolate scripting problems with matrices. Only usable with matrix-based fields.<br><br />
Example: result = this.field[myfield].matrixdump<br><br />
{{note}}The generated output is capped to the limits of the debug output mechanism, so using this mechanism with large matrices and/or text-based fields may result in the output being truncated.<br />
|-<br />
|datetime[''fmt'',''sep'']<br />
|(Right, String) Returns the contents of the field formatted for output as a date or time, where ''sep'' is the separator string to use between values. The ''fmt'' parameter dictates the formatting to be used and must be one of the following values:<br />
<ul class="sets"><br />
<li>realdate – Formatted as if it's a real-world date.</li><br />
<li>realtime – Formatted as if it's a real-world time.</li><br />
<li>gamedate – Formatted as if it's a game-world date.</li><br />
<li>gametime – Formatted as if it's a game-world time.</li><br />
</ul><br />
Example: result = this.field[myfield].datetime[gamedate,"/"]<br><br />
{{note}}This target reference is only supported on fields within picks - not things.<br />
|-<br />
|modify[''oper'',''val'',''str'']<br />
|(Right, Number) Applies a modification to the field with accompanying notes for tracking a history of changes. The modification nature is given by the ''oper'' parameter, which which specifies the operation to be performed. The ''val'' parameter is an arithmetic expression the provides the modification value to be applied. The ''str'' parameter is a text annotation that is recorded along with the modification. If ''str'' is the empty string, the notes are the name of the initial pick context that is applying the change (or "?????" if the initial context is not a pick). The ''oper'' parameter must be one of the following:<br />
<ul class="sets"><br />
<li>'+' - The value is added to the field.</li><br />
<li>'-' - The value is subtracted from the field.</li><br />
<li>'*' - The value is multiplied into the field.</li><br />
<li>'/' - The value is divided into the field.</li><br />
<li>'=' - The new value is assigned to the field and all previous adjustments to the field are ignored. This operator is only valid with "stack" or "changes" history tracking.</li><br />
<li>'#' - The value is added to the field, but no sign is displayed for the field within the history report. This allows the identification of basic values included into the field calculation that are distinct from bonuses (which include the '+').</li><br />
<li>'$' - The value is completely ignored and only the text entry is added for the modification. This allows a history entry to be recorded that has no value but that needs to be included in the report.</li><br />
</ul><br />
The field must be explicitly configured to support history tracking. Always returns a value of zero.<br><br />
Example: perform this.field[myfield].modify[+,1,"first"]<br />
|-<br />
|history[''spl'',''start'']<br />
|(Right, String) Generates and returns a text string that contains the change history for the field. The ''spl'' parameter is a string that is inserted between entries in the change history, splicing them together for appropriate output. The ''start'' parameter is the starting value used for the field within the report. Both the ''spl'' and ''start'' parameters are optional, although the ''spl'' is required in order to specify the ''start'' parameter. If omitted, the ''spl'' parameter defaults to a comma and a space (", "), while the ''start'' parameter defaults to zero. The history report contents depend on the history behavior assigned to the field, as given below:<br />
<ul class="sets"><br />
<li>best – Only the notes text for each history entry is reported</li><br />
<li>stack – The notes text for each entry is reported and the adjustment details are included in parentheses with the notes (e.g. "notes (+2)")</li><br />
<li>changes - Same as 'stack'</li><br />
</ul><br />
Example: result = this.field[myfield].history<br><br />
Example: result = this.field[myfield].history["&"]<br><br />
Example: result = this.field[myfield].history[", ",42]<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Thing_Context&diff=2996Thing Context2009-05-12T09:26:44Z<p>Rob: /* Context Transitions{{anchor|transitions}} */</p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "thing" context represents a thing that has not been added to the portfolio. The thing context is very similar to the pick context in behavior, with the only real difference being that the dynamic facets of picks don't exist for things, resulting in many valid actions for picks being inaccessible from things.<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
A "thing" context is very similar to a "pick" context, except that a "thing" context represents a thing that has not yet been added to a container and therefore lacks any dynamic state. As a result, the "thing" context is much more restrictive than the "pick" context. From within a "thing" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|state<br />
|Transitions to the [[State Context|state context]].<br><br />
Example: this.state<br />
|-<br />
|field[''id'']<br />
|Transitions to the [[Field Context|field context]] corresponding to the field within the current thing that has the ''id'' specified. If the given field does not exist for the current thing, the transition fails to resolve.<br><br />
Example: this.field[myfield]<br><br />
{{note}}Within things and picks, there are a number of pre-defined pseudo-fields that are always defined and that allow access to facets of the pick that are not governed by user-defined fields. These pseudo-fields behave like normal fields in all respects within scripts, except that some are read-only. The list of pre-defined fields can be found elsewhere in the [[Kit Reference]] documentation.<br />
|-<br />
|linkage[''id'']<br />
|Transitions to the [[Pick Context|pick context]] corresponding to the linkage with the ''id'' specified. If the linkage is not defined, an error is reported.<br><br />
Example: this.linkage[mylink]<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
There are a number of target references that apply to things that have not been added to a container. These come into play at times like testing pre-requisites and when things are selected via menus. While similar to picks in many ways, things have no dynamic facets and are therefore always read-only in behavior. The complete list of target references for thing is presented in the table below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|idstring<br />
|(Right, String) Returns the unique id of the thing as a string. This can be extremely handy when synthesizing tag templates and tag expressions on-the-fly via scripts.<br><br />
Example: result = this.idstring<br />
|-<br />
|ispick<br />
|(Right, Number) Returns non-zero if the current context is a pick and zero if it's a thing. This provides a means to discern the nature of the context when the circumstances make a distinction uncertain, such as within procedures.<br><br />
Example: result = this.ispick<br />
|-<br />
|isunique<br />
|(Right, Number) Returns non-zero if the thing behaves as unique.<br><br />
Example: result = this.isunique<br />
|-<br />
|isentity<br />
|(Right, Number) Returns non-zero if the thing directly attaches a child entity.<br><br />
Example: result = this.isentity<br />
|-<br />
|tagis[''tmpl'']<br />
|(Right, Number) Returns non-zero if any tags assigned to the thing match the tag template ''tmpl'', else zero if no tags match. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: this.tagis[skill.?]<br />
|-<br />
|tagcount[''tmpl'']<br />
|(Right, Number) Returns the number of tags assigned to the thing that match the tag template ''tmpl''. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagcount[skill.?]<br />
|-<br />
|tagvalue[''tmpl'']<br />
|(Right, Number) Returns the value of a tag assigned to the thing that matches the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagvalue[spelllevel.wizard?]<br />
|-<br />
|tagmin[''tmpl'']<br />
|(Right, Number) Returns the minimum value of all tags assigned to the thing that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmin[spelllevel.wizard?]<br />
|-<br />
|tagmax[''tmpl'']<br />
|(Right, Number) Returns the maximum value of all tags assigned to the thing that match the tag template ''tmpl''. The rules associated with tag values in tag expressions apply. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagmax[spelllevel.wizard?]<br />
|-<br />
|tagunique[''tmpl'']<br />
|(Right, Number) Returns the number of unique tags assigned to the thing that match the tag template ''tmpl''. If a tag is assigned multiple times, it is only counted once. The template must use the standard "group.id" syntax and may contain a wildcard.<br><br />
Example: result = this.tagunique[skill.?]<br />
|-<br />
|tagexpr[''expr'']<br />
|(Right, Number) Returns non-zero if the tags assigned to the thing match the tag expression ''expr'', else zero is returned. The ''expr'' parameter must be a valid tag expression.<br><br />
Example: result = this.tagexpr[class.wizard & (val:spelllevel.wizard? > 5)]<br />
|-<br />
|tagcountstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagcount", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagcountstr["skill.?"]<br />
|-<br />
|tagvaluestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagvalue", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagvaluestr["spelllevel.wizard?"]<br />
|-<br />
|tagminstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmin", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagminstr["spelllevel.wizard?"]<br />
|-<br />
|tagmaxstr[''str'']<br />
|(Right, Number) This target reference is identical to "tagmax", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagmaxstr["spelllevel.wizard?"]<br />
|-<br />
|taguniquestr[''str'']<br />
|(Right, Number) This target reference is identical to "tagunique", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag template to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.taguniquestr["skill.?"]<br />
|-<br />
|tagsearch[''str'']<br />
|(Right, Number) This target reference is identical to "tagexpr", except that the ''str'' parameter is a string expression that is evaluated within the script. This allows the tag expression to be dynamically determined via the script instead of being hard-wired at compilation.<br><br />
Example: result = this.tagsearch["class.wizard & (val:spelllevel.wizard? > 5)"]<br><br />
{{note}}Using "tagsearch" is MUCH slower in performance than using "tagexpr", since the tagexpr must be parsed and compiled every time the script is evaluated. Be sure to use "tagexpr" whenever possible.<br />
|-<br />
|tagmatch[''refgrp'',''match'',''ref'']<br />
|(Right, Number) Returns non-zero if any tags within a reference context also exist within a match context, else zero. This allows tags from one context to be verified to exist within another context, making tag-based comparisons between two objects possible. For more details, [[The "tagmatch" Target Reference|please check here]].<br><br />
Example: result = hero.tagmatch[NeedStatus,HasStatus,initial]<br />
|-<br />
|intersect[''init'',''curr'']<br />
|(Right, Number) Returns non-zero if tags within the initial script context also exist within the currently transitioned context, else zero. All of the tags that belong to the ''init'' tag group within the initial script context are compared against the tags that belong to the ''curr'' tag group within the current context. If any of those tags possess the identical tag id, then a match is returned (i.e. non-zero). The same tag group may be used for both contexts, and both contexts must be objects that possess tags (i.e. container, pick, or thing).<br><br />
Example: result = this.interset[MyGroup,AltGroup]<br />
|-<br />
|tagnames[''tmpl'',''spl'']<br />
|(Right, String) Generates and returns a list of tags within the thing. Only tags that match the tag template ''tmpl'' are included in the list. The generated string appends the names of the tags together, inserting the splicing string ''spl'' between each name if there is more than one. A thing with no tags matching the template will return the empty string.<br><br />
Example: result = this.tagnames[Weapon.?,"+"]<br />
|-<br />
|tagabbrevs[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the abbreviations for all matching tags instead of their names.<br><br />
Example: result = this.tagabbrevs[Weapon.?,"+"]<br />
|-<br />
|tagids[''tmpl'',''spl'']<br />
|(Right, String) Works identically to "tagnames", except that the generated string is comprised of the unique ids for all matching tags instead of their names.<br><br />
Example: result = this.tagids[Weapon.?,"+"]<br />
|-<br />
|prereqok<br />
|(Right, Number) Returns non-zero if the pick satisfies all of its pre-requisites. May not be used during evaluation.<br><br />
Example: result = this.prereqok<br />
|-<br />
|prereqnum<br />
|(Right, Number) Returns the total number of pre-requisite rules that exist for the current pick. May not be used during evaluation.<br><br />
Example: result = this.prereqnum<br />
|-<br />
|prereqmsg[''index'']<br />
|(Right, String) Returns the message associated with a specific pre-requisite test for the current pick, where the desired test is given by ''index''. The index is zero-based, so the values 0 through 4 should be used for a pick with 5 pre-requisites. If the individual pre-requisite is satisfied, the text returned is the empty string. Otherwise, the text returned is the corresponding message. May not be used during evaluation.<br><br />
Example: result = this.prereqmsg[i]<br><br />
{{note}}Retrieving the message for individual pre-requisite tests will trigger a re-calculation '''every''' time, so it is expensive and should only be used sparingly.<br />
|-<br />
|isgear<br />
|(Right, Number) Returns non-zero if the thing is a piece of gear.<br><br />
Example: result = this.isgear<br />
|-<br />
|isholdable<br />
|(Right, Number) Returns non-zero if the pick is gear that can be placed into a gear holder.<br><br />
Example: result = this.isholdable<br />
|-<br />
|stackable<br />
|(Right, Number) Returns non-zero if the thing can be stacked with other equivalent picks.<br><br />
Example: result = this.stackable<br />
|-<br />
|isbootstrap[''thing'']<br />
|(Right, Number) Returns non-zero if the current thing directly bootstraps a thing with the specified id ''thing''.<br><br />
Example: result = this.isbootstrap[thingid]<br />
|-<br />
|islinkage[''link'']<br />
|(Right, Number) Returns non-zero if the current thing possesses a linkage with the specified id ''link''.<br><br />
Example: result = this.islinkage[linkid]<br />
|-<br />
|ispanel<br />
|(Right, Number) Returns non-zero if the thing has a panel linkage defined for it. This allows generic handling of panel linkages within component scripts when the actual panel linkage is optionally controlled by the thing.<br><br />
Example: result = this.ispanel<br />
|-<br />
|sourcerefs[''spl'']<br />
|(Right, String) Generates and returns a list of all sources that the current thing is dependent upon. The generated string appends the names of the sources together, inserting the splicing string ''spl'' between each name if there is more than one. A thing with no source dependencies will return the empty string.<br><br />
Example: result = this.sourcerefs["+"]<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=State_Context&diff=2995State Context2009-05-12T09:25:00Z<p>Rob: /* Context Transitions{{anchor|transitions}} */</p>
<hr />
<div>{{contextmulti|Kit Reference}}<br />
<br />
Jump to: [[#references|Target References]]<br />
<br />
The "state" context provides access to overall state information that pertains to the portfolio as a whole or general information about the evaluation cycle.<br />
<br />
==Context Transitions{{anchor|transitions}}==<br />
<br />
From within a "state" context, you can utilize the following set of valid context transitions:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|thing[''id'']<br />
|Transitions to the [[Thing Context|thing context]] corresponding to the thing with the ''id'' specified. If no thing exists with the given unique id, an error is reported.<br><br />
Example: this.thing[myid]<br />
|-<br />
|}<br />
<br />
==Target References{{anchor|references}}==<br />
<br />
The "state" context is a general context that maintains information outside the normal data hierarchy. The target references for this context span a wide range of details that may prove useful within your scripts. The complete list of target references for the "state" context is presented in the table below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|isfocus<br />
|(Right, Number) Returns non-zero if a focus pick has been properly established via the "setfocus" target reference.<br><br />
Example: result = state.isfocus<br />
|-<br />
|clearfocus<br />
|(Right, Number) Clears any focus pick that has been established and resets to a state where there is no focus pick.<br><br />
Example: perform state.clearfocus<br />
|-<br />
|timing<br />
|(Right, String) Returns the phase and priority timing during which the current script is being invoked in an effort to simplify debugging of data files.<br><br />
Example: result = state.timing<br />
|-<br />
|iscreate<br />
|(Right, Number) Returns non-zero if the character is currently in creation mode.<br><br />
Example: result = state.iscreate<br />
|-<br />
|isadvance<br />
|(Right, Number) Returns non-zero if the character is currently in advancement mode.<br><br />
Example: result = state.isadvance<br />
|-<br />
|issell<br />
|(Right, Number) Returns non-zero if the user is currently in the midst of a sell transaction.<br><br />
Example: result = state.issell<br />
|-<br />
|isload<br />
|(Right, Number) Returns non-zero if the loading of a saved portfolio is currently in progress.<br><br />
Example: result = state.isload<br />
|-<br />
|isoutput<br />
|(Right, Number) Returns non-zero if the rendering of character sheet output is currently in progress.<br><br />
Example: result = state.isoutput<br />
|-<br />
|isdossierstyle[''style'']<br />
|(Right, Number) Returns whether the user selected text output to be formatted in the style given by the ''style'' parameter. The ''style'' parameter must be one of the following values: "plain", "html", or "bbcode".<br><br />
Example: result = state.isdossierstyle[html]<br />
|-<br />
|istext<br />
|(Right, Number) Returns non-zero if the render of text output is currently in progress.<br><br />
Example: result = state.istext<br />
|-<br />
|iscombat<br />
|(Right, Number) Returns non-zero if combat mode is currently enabled within the Tactical Console.<br><br />
Example: result = state.iscombat<br />
|-<br />
|isendturn<br />
|(Right, Number) Returns non-zero if all combatants have taken their allotted actions and it is valid to end the current combat turn.<br><br />
Example: result = state.isendturn<br />
|-<br />
|combatturn<br />
|(Right, Number) Returns the current combat turn that is underway within the Tactical Console.<br><br />
Example: result = state.combatturn<br />
|-<br />
|initchange<br />
|(Right, Number) Returns non-zero if any actor has a user-modified initiative value.<br><br />
Example: result = state.initchange<br />
|-<br />
|actorcount<br />
|(Right, Number) Returns the total number of actors within the portfolio, including all minions.<br><br />
Example: result = state.actorcount<br />
|-<br />
|reload[''table'']<br />
|(Right, Number) Forces a re-load and re-sort of the table portal whose id is given by the ''table'' parameter. This target reference is only accessible from within a [[Trigger Script]].<br><br />
Example: result = state.reload[myportal]<br />
|-<br />
|value[''id'']<br />
|(Left, Right, Number) Provides direct access (read/write) to a global value with the given ''id''. This value is globally defined, outside the scope of any actors, and it is persistent. The state of all global values is saved with the portfolio and restored on a reload. A global value must be set before it is retrieved, else a run-time error is reported.<br><br />
Example: result = state.value[id]<br><br />
{{note}}This mechanism makes it possible to manage state across the entire portfolio.<br />
|-<br />
|setrandom[''id'',''cnt'']<br />
|(Right, Number) Creates a new set of random values with the given ''id''. The set contains the integer values zero through ''cnt''-1, with the values being in a random sequence. The set of values is globally defined, outside the scope of any actors, and it is persistent. The state of the set will be saved with the portfolio and restored on a reload. The value returned is always zero.<br><br />
Example: result = state.setrandom[setid,42]<br><br />
{{note}}This mechanism makes it possible to simulate set-based behaviors, such as a deck of cards. The other target references beginning with the "set" prefix below are used in conjunction with this set.<br />
|-<br />
|setextract[''id'']<br />
|(Right, Number) Extracts and returns the next value from the set with the given ''id'', which must already be created. If there are no values left within the set, a run-time error is reported and the value zero is returned.<br><br />
Example: result = state.setextract[setid]<br />
|-<br />
|setremain[''id'']<br />
|(Right, Number) Returns the number of values that remain within the set with the given ''id''.<br><br />
Example: result = state.setremain[setid]<br />
|-<br />
|setdiscard[''id'',''val'']<br />
|(Right, Number) Locates the value ''val'' within the set with the given ''id'' and discards it from the set. Once discarded, the set behaves as if the value no longer exists within the set.<br><br />
Example: result = state.setdiscard[setid,42]<br />
|-<br />
|}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Flow_Control&diff=2994Flow Control2009-05-12T09:09:17Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The scripting language supports a variety of basic flow control mechanisms, and each is described in the sections below.<br />
<br />
==Label and Goto Statements==<br />
<br />
The most primitive form of flow control is the use of "label" and "goto" statements. Label statements are defined with the form "name:", where "name" follows the same naming rules as variables. To transfer control to a label statement, a goto statement is used. The syntax for a goto statement is "goto name", where name corresponds to an existing label within the script. When a goto statement is executed, control passes to the label statement, and the next line executed in the script is the one immediately following the label statement. It is perfectly valid to issue a goto statement prior to the definition of the label statement, allowing you to skip over a section of the script if you wish. An example code block demonstrating the use of labels and gotos is given below.<br />
<br />
<pre><br />
var foo as number<br />
foo = 10<br />
goto mylabel<br />
foo = 20<br />
mylabel:<br />
~The value of foo is still 10, since we skipped over the assignment to 20.<br />
</pre><br />
<br />
==If/Then Blocks==<br />
<br />
A more traditional form of control flow is with the "if/then" block. Within an if/then block, a test of some sort is performed. Based on the results of that test, the following block of code may or may not be executed. The if/then block consists of two separate statements. The first statement is the test to be performed and uses the syntax "if (expr1 comparison expr2) then". The values of "expr1" and "expr2" can be any valid arithmetic expression. The valid values for "comparison" are the various relationship operators: '<', '<=', '=', '>=', '>', and '<>'. The first five of these comparison operators should be familiar, while the last one implies "not equal".<br />
<br />
The "if" statement evaluates the two expressions and then compares them with the relationship indicated. If the comparison is satisfied, then execution continues with the line immediately following the "if" statement. <br />
<br />
The second statement identifies the end of the if/then block and has the simple syntax "endif". If the comparison is failed, then execution skips over the if/then block until the "endif" statement is reached, at which point execution resumes. An example if/then block is shown below.<br />
<br />
<pre><br />
var foo as number<br />
foo = 10<br />
if (foo + 3 > 20) then<br />
foo = 1<br />
endif<br />
~The value of foo is still 10, since we skipped over the assignment above.<br />
</pre><br />
<br />
==If/Then/Else Blocks==<br />
<br />
The if/then block can be extended to be an if/then/else block. This form is useful when you need to execute one block of code if the condition is true and another block of code if it fails. The if/then/else block is identical to the if/then block, except that an additional "else" statement is inserted. This new statement demarcates where the block of code to execute on success ends and the block of code to execute on failure begins. If the conditional test is satisfied, then execution continues with the next line, but when the "else" statement is encountered, execution jumps to the line following the "endif" statement. If the conditional test fails, then execution jumps to the line following the "else" statement. An example if/then/else block is shown below.<br />
<br />
<pre><br />
var foo as number<br />
foo = 10<br />
if (foo + 3 > 20) then<br />
foo = 1<br />
else<br />
foo = foo + 10<br />
endif<br />
~The value of foo is now 20, since we executed the "else" clause only.<br />
</pre><br />
<br />
==If/Then/Elseif/Else Blocks==<br />
<br />
To handle the situation where multiple value ranges need to be handled, the if/then/else block also supports an "elseif" statement. The "elseif" statement allows a separate condition to be tested, with its own block of code to be executed if the condition is satisfied. All condition blocks are tested in sequence, with only the first one that is satisfied having its code executed.<br />
<br />
<pre><br />
var foo as number<br />
foo = 8<br />
if (foo <= 5) then<br />
foo = 1<br />
elseif (foo <= 10) then<br />
foo = 2<br />
elseif (foo <= 15) then<br />
foo = 3<br />
else<br />
foo = 4<br />
endif<br />
~The value of foo is now 2, since we executed the first "elseif" clause only.<br />
</pre><br />
<br />
==While/Loop Blocks==<br />
<br />
Another control flow mechanism provided by the scripting language is the "while/loop" block. The while/loop block executes a block of code repeatedly as long as a particular conditional test remains satisfied. The while/loop block begins with a statement of the form "while (expr1 comparison expr2)", where "expr1", "expr2", and "comparison" all behave identically to a standard "if" statement. The end of a while/loop block is identified by a "loop" statement, which consists solely of the keyword "loop" on a line. When the "loop" statement is encountered, the conditional test is evaluated again. As long as the condition remains satisfied, execution continues with the line following the "while" statement. Once the condition fails, execution jumps to the line following the "loop" statement. The loop will continue executing the code until the conditional test finally fails. An example while/loop block is shown below.<br />
<br />
<pre><br />
var foo as number<br />
foo = 1<br />
while (foo <= 10)<br />
foo = foo + 1<br />
loop<br />
~The value of foo is now 11.<br />
</pre><br />
<br />
==For/Next Blocks==<br />
<br />
The final control flow mechanism available is the "for/next" block. Like the while/loop block, the for/next block executes a block of code repeatedly, keying on the value of a variable (the "loop index"). The for/next block is identified by "for varname = expr1 to expr2", where "varname" is the name of the numeric variable to be used as the loop index and "expr1" and "expr2" are complex expressions. The variable is initialized with a given value and incremented by 1 every iteration of the loop. After the second value has been reached and processed, the iteration stops (so looping from 1 to 5 will run through the loop 5 times, the index taking on values of 1, 2, 3, 4 and 5 in succession before stopping). The loop index is automatically incremented by the for/next construct itself, and does not have to be maintained by the script writer.<br />
<br />
<pre><br />
var x as number<br />
var text as string<br />
text = "A list of some numbers: "<br />
for x = 0 to (100 / 20 * 2)<br />
text = text & x<br />
next<br />
~The string 'text' will now contain an ascending list of the numbers from 0 up to 10.<br />
</pre><br />
<br />
==Nesting==<br />
<br />
All conditional statements (if/then, if/then/else, while/loop and for/next) can be safely nested within each other. For example, if two separate conditions must be satisfied in order to perform some action, you might have a script that looks similar to the example below. When nesting conditional statements, each "endif" statement is associated with the closest "if/then" statement. Appropriate use of indentation can greatly enhance the readability of scripts when nested statements are employed.<br />
<br />
<pre><br />
if (x > y) then<br />
if (a > b) then<br />
z = 1<br />
else<br />
z = 0<br />
endif<br />
else<br />
if (a > b) then<br />
z = 0<br />
else<br />
z = 1<br />
endif<br />
endif<br />
</pre><br />
<br />
{{important}}The scripting mechanism is designed to handle scripts of only moderate size and complexity. As such, scripts possess a maximum nesting depth of 20 levels, which ought to be significantly more than any script should ever need.<br />
<br />
If a script is too large or complex, an error will be reported when compiling the script. In general, a given script can utilize dozens of flow control constructs without becoming too complex, so the complexity limit should not be reached under normal conditions.<br />
<br />
==Done Statement==<br />
<br />
If you reach a point in the execution of a script where all necessary processing is completed, you can utilize the "done" statement to immediately exit the current script. Judicious use of "done" can simplify scripts and make them easier to maintain by eliminating a great deal of nesting and matching of if/then/else statements. <br />
<br />
Two examples are shown below, where the second script accomplishes the same as the first. The key difference is that the second script utilizes the "done" statement. Use of the "done" statement is a matter of personal style, but it can be very handy for scripts with both simple and complex conditions.<br />
<br />
<pre><br />
if (foo <= 3) then<br />
~do something<br />
else<br />
~lots of code<br />
if (for <= 6) then<br />
~lots of code<br />
else<br />
~lots of code<br />
endif<br />
~lots of code<br />
endif<br />
</pre><br />
<br />
<pre><br />
if (foo <= 3) then<br />
~do something<br />
done<br />
endif<br />
~lots of code<br />
if (for <= 6) then<br />
~lots of code<br />
else<br />
~lots of code<br />
endif<br />
~lots of code<br />
</pre><br />
<br />
==DoneIf Statement==<br />
<br />
There will be numerous situations when writing scripts where you'll want to test for a condition and exit out of the script. This amounts to writing an "if" statement and using "done" if the test is satisfied. That's three lines of code that you'll be using over and over again.<br />
<br />
To simplify this, the scripting language provides a "doneif" statement. This statement takes a comparison expression and will exit the script if the test is satisfied, thereby reducing three lines of code to one. For example, the following two blocks of code are functionally equivalent.<br />
<br />
<pre><br />
if (foo <= 3) then<br />
done<br />
endif<br />
</pre><br />
<br />
<pre><br />
doneif (foo <= 3)<br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=HoldLimit_Tag_Expression&diff=2993HoldLimit Tag Expression2009-05-12T09:04:29Z<p>Rob: Created page with '{{context|Kit Reference|Tag Expression Types}} The role of the HoldLimit tag expression is to determine whether a piece of gear can be held by another piece of gear. By default,...'</p>
<hr />
<div>{{context|Kit Reference|Tag Expression Types}}<br />
<br />
The role of the HoldLimit tag expression is to determine whether a piece of gear can be held by another piece of gear. By default, any piece of gear can be held within gear designated as a "holder". With the HoldLimit tag expression, the set of gear that can be held by a holder is further restricted. Only a piece of gear that also satisfies the HoldLimit tag expression is allowed to be held by the holder.<br />
<br />
The primary use of the HoldLimit tag expression is to leverage the containment mechanism to associate weapon options with the various weapons. For example, a laser sight might confer bonuses to the use of a gun, but that laser sight can be moved between different weapons. Through the use of the HoldLimit tag expression, the gun can be restricted to only hold laser sights and other similar weapon options. The user can then move the laser sight gear from one gun to another, with a script being used on the laser sight to automatically apply the appropriate bonus to the gun the laser sight is attached to.<br />
<br />
The HoldLimit tag expression is only applied against tags that are assigned directly to a thing at definition, including any component tags. Any tags that are assigned dynamically after the gear is added to the character are ignored. Consequently, the tag expression is evaluated against each piece of gear when the user brings up the menu to move the gear to a new holder. Once a piece of gear is assigned to a holder, no further evaluation is performed, unless the user chooses to move the gear again.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Tag_Expression_Types&diff=2992Tag Expression Types2009-05-12T08:53:51Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Kit leverages a variety of tag expressions for different purposes. The topics below provide a brief discussion of both the role and behavior of each different type of tag expression.<br />
<br />
*{{fl|Live Tag Expression}}<br />
*{{fl|Container Tag Expression}}<br />
*{{fl|Match Tag Expression}}<br />
*{{fl|List Tag Expression}}<br />
*{{fl|Candidate Tag Expression}}<br />
*{{fl|Restriction Tag Expression}}<br />
*{{fl|Secondary Tag Expression}}<br />
*{{fl|Existence Tag Expression}}<br />
*{{fl|HoldLimit Tag Expression}}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Thing_Element_(Data)&diff=2991Thing Element (Data)2009-05-12T08:52:47Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference|Data File Reference}}<br />
<br />
==The "thing" Element==<br />
<br />
The vast majority of objects that will comprise your data files are "things", which will be added to actors and customized via scripts. By definition, all behaviors for things are inherited by any derived picks, unless specified otherwise. Each thing is specified through the use of a "thing" element. The complete list of attributes for this element is below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id of the thing. This id is used in all references to the thing.<br />
|-<br />
|compset<br />
|Id – Specifies the unique id of the component set from which this thing is derived.<br />
|-<br />
|name<br />
|Text – Public name associated with the thing. Maximum length of 100 characters.<br />
|-<br />
|description<br />
|(Optional) Text – Detailed description text associated with the thing, for display to the user. Default: Empty.<br />
|-<br />
|summary<br />
|(Optional) Text – Brief summary description for the thing, for display to the user in space-constrained situations. If empty, the full description is always used as the summary. Default: Empty.<br />
|-<br />
|isunique<br />
|(Optional) Boolean – Indicates whether this thing is treated as unique within each container. If unique, a single pick is only ever added, while non-unique things can be separately added any number of times. Default: "no".<br />
|-<br />
|holdable<br />
|(Optional) Boolean – Indicates whether this thing can be held within other other things, such as backpacks hold various pieces of gear. Default: "yes".<br />
|-<br />
|maxlimit<br />
|(Optional) Integer – Specifies the maximum number of instances of this thing that can be added to a given container. If zero, there is no limit imposed. Default: "0".<br />
|-<br />
|panellink<br />
|(Optional) Id – Specifies the unique id of a panel that is officially associated with this thing. Scripts can generically determine the panel linked to a thing to mark it invalid if picks within the panel are invalid. If empty, the default panel linkage defined by components is assumed. Default: Empty.<br />
|-<br />
|stacking<br />
|(Optional) Set – Designates the default stacking behavior to be assumed whenever this thing is purchased by the user. Must be one of these values:<br />
<ul class="sets"><br />
<li>solo – Item is created individually, so buying 5 of the thing will add 5 separate instances of the thing to the container.</li><br />
<li>new – Item is purchased as a new group, so buying 5 of the thing will add one new instance of the thing that has a quantity of 5.</li><br />
<li>merge – Item is merged to any existing instance of the thing within the container, adding the quantity purchased to the existing quantity. If item does not currently exist, "new" behavior is used.</li><br />
<li>never – Item can never support stacking.</li><br />
<li>Default: "solo".</li><br />
</ul><br />
|-<br />
|lotsize<br />
|(Optional) Integer – Specifies the number of items typically purchased as a single unit when buying this thing. For example, bullets might be purchased by the box, with a box having 25 bullets in it. Default: "1".<br />
|-<br />
|replaces<br />
|(Optional) Id – Specifies the unique id of another thing which is completely replaced by this thing. All references to the replaced thing are automatically mapped to this thing, such as bootstrapping. This allows you to wholesale replace a built-in item with new behaviors of your own choosing. If empty, no replacement behavior is utilized. Default: Empty.<br />
|-<br />
|buytemplate<br />
|(Optional) Id – Specifies the unique id of a template that is used for purchasing the thing. This attribute is only applicable to things which have a child entity and whose purchase cost is variable based on the user-specified composition of the child entity. The specified template is used similarly to the buy template that appears within tables and choosers. However, the template is centered at the bottom of the form used for editing the child gizmo. This mechanism is needed when you have something like a user-customizable magic item within the d20 System, where the cost is based on the options selected by the user. If empty, no template is associated with the thing. Default: Empty.<br />
|-<br />
|xactspecial<br />
|(Optional) Integer – When a buy template is shared between two or more portals or things, the template behavior may need to be tailored based on the usage. If this need arises, this attribute specifies a unique value that identifies this particular usage. By assigning a different value to each usage and keying on it within the template's Position script, you can tailor the template appropriately. Default: "0".<br />
|-<br />
|isprivate<br />
|(Optional) Boolean – Indicates whether this thing should be kept private from users within the integrated Editor. When a user creates a new thing as a copy of another thing, all existing things derived from the compset are presented for use as the copy source. By making this thing private, it will not appear for selection. Default: "no".<br />
|-<br />
|}<br />
<br />
The "thing" element also possesses child elements that define various facets of the thing. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[#fieldval|fieldval]]<br />
|Zero or more "fieldval" elements may appear as defined by the given link. This element specifies the starting value for individual fields within the thing.<br />
|-<br />
|[[#arrayval|arrayval]]<br />
|Zero or more "arrayval" elements may appear as defined by the given link. This element specifies the starting value for individual array and matrix elements within the thing.<br />
|-<br />
|[[#usesource|usesource]]<br />
|Zero or more "usesource" elements may appear as defined by the given link. This element specifies the sources relied upon for this thing to be accessible to the user.<br />
|-<br />
|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the thing.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped when this thing is added to a container.<br />
|-<br />
|[[ContainerReq Element (Data)|containerreq]]<br />
|Zero or more "containerreq" elements may appear as defined by the given link. This element specifies any container requirements for the thing.<br />
|-<br />
|[[#holdlimit|holdlimit]]<br />
|An optional "holdlimit" element may appear as defined by the given link. This element defines a [[HoldLimit Tag Expression]] that restricts the valid set of gear that can be held by the thing.<br />
|-<br />
|[[#gear|gear]]<br />
|An optional "gear" element may appear as defined by the given link. This element defines a [[Gear Script]] for the thing to calculate its weight.<br />
|-<br />
|[[#link|link]]<br />
|Zero or more "link" elements may appear as defined by the given link. This element specifies the specific [[Pick Linkages|pick linkages]] that exist for this thing.<br />
|-<br />
|[[Eval Element (Data)|eval]]<br />
|Zero or more "eval" elements may appear as defined by the given link. This element specifies any [[Eval Script|Eval Scripts]] that must be performed for the thing.<br />
|-<br />
|[[EvalRule Element (Data)|evalrule]]<br />
|Zero or more "evalrule" elements may appear as defined by the given link. This element specifies any [[EvalRule Script|EvalRule Scripts]] that must be performed for the thing.<br />
|-<br />
|[[#pickreq|pickreq]]<br />
|Zero or more "pickreq" elements may appear as defined by the given link. This element specifies any [[Dependencies on Specific Things|dependencies upon other picks]] within the container.<br />
|-<br />
|[[#exprreq|exprreq]]<br />
|Zero or more "exprreq" elements may appear as defined by the given link. This element specifies any [[Expression-Based Requirements|expression-based dependencies ]] upon the state of the container.<br />
|-<br />
|[[PreReq Element (Data)|prereq]]<br />
|Zero or more "prereq" elements may appear as defined by the given link. This element specifies any [[General Pre-Requisites|pre-requisite tests]] that are applied to the thing.<br />
|-<br />
|[[#child|child]]<br />
|An optional "child" element may appear as defined by the given link. This element defines the particulars of a child entity that is attached by the thing.<br />
|-<br />
|[[#minion|minion]]<br />
|An optional "minion" element may appear as defined by the given link. This element defines the particulars of a minion that is attached by the thing.<br />
|-<br />
|}<br />
<br />
==The "fieldval" Element{{anchor|fieldval}}==<br />
<br />
The "fieldval" element defines the starting values to use for various fields within the thing. To initialize elements within arrays and matrices, please see the "arrayval" element (below). The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|field<br />
|Id – Unique id of the field for which to specify a starting value.<br />
|-<br />
|value<br />
|Text – Starting value to assign to the field. If the field is text-based, the value is simply assigned, although it may be truncated if it exceeds the defined maximum length for the field. If the field is value-based, the text is converted to a floating point value and assigned.<br />
|-<br />
|}<br />
<br />
==The "arrayval" Element{{anchor|arrayval}}==<br />
<br />
The "arrayval" element defines the starting values to use for individual elements within array and matrix fields of the thing. To initialize elements within fields that are not an array or matrix, please see the "fieldval" attribute (above). The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|field<br />
|Id – Unique id of the field for which to specify a starting value. If the field is not an array or matrix, an error is reported.<br />
|-<br />
|index<br />
|Integer – Specifies the row index of the element to be initialized. The first element of arrays and matrices is index zero.<br />
|-<br />
|column<br />
|(Optional) Integer – Specifies the column of the element to be initialized within a matrix. The first element of matrices is index zero. This attribute is required for matrix elements and may be omitted for array elements. Default: Empty.<br />
|-<br />
|value<br />
|Text – Starting value to assign to the field element. If the field is text-based, the value is simply assigned, although it may be truncated if it exceeds the defined maximum length for the field. If the field is value-based, the text is converted to a floating point value and assigned.<br />
|-<br />
|}<br />
<br />
==The "usesource" Element{{anchor|usesource}}==<br />
<br />
The "usesource" element specifies a [[Sources|source]] that this thing is dependent upon. If the designated source is not enabled by the user, this thing will be treated as not existing for the character. You may define a new source on-the-fly via this element by providing a new unique id and the appropriate additional information. However, you should typically avoid doing so, since you cannot control important facets of sources with just-in-time definition. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|source<br />
|Id – Specifies the unique id of the source with which to establish a dependence.<br />
|-<br />
|name<br />
|(Optional) Text – Name to be displayed to the user for this source. Maximum length is 50 characters. If the source already exists, this attribute can be left empty. Default: Empty.<br />
|-<br />
|parent<br />
|(Optional) Id – Specifies the unique id of a different source that is treated as the parent of this source. All sources are displayed in a hierarchy within the "Configure Hero" form. If the source already exists, this attribute can be left empty and the behaviors of the existing source are utilized. If empty and the source does not yet exist, the new source is presented to the user as a top-level selection. Default: Empty.<br />
|-<br />
|}<br />
<br />
==The "holdlimit" Element{{anchor|holdlimit}}==<br />
<br />
The "holdlimit" element defines a [[HoldLimit Tag Expression]] for the thing, which restricts the set of things that can be assigned to this thing as held gear. The tag expression is compared against the tags assigned to each prospective piece of gear that the user wants to move. If the tag expression is satisfied, the gear can be held within the thing, else it cannot. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|PCDATA<br />
|TagExpr – Specifies the code comprising the HoldLimit tag expression.<br />
|-<br />
|}<br />
<br />
==The "gear" Element{{anchor|gear}}==<br />
<br />
The "gear" element defines a [[Gear Script]] for the thing, which is used to calculate the weight of held items and perform additional gear processing on the thing. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|PCDATA<br />
|Script – Specifies the code comprising the Gear script.<br />
|-<br />
|}<br />
<br />
==The "link" Element{{anchor|link}}==<br />
<br />
The "link" element defines a [[Pick Linkages|linkage to another thing]] based on the set of possible linkages defined for the underlying components. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|linkage<br />
|Id – Unique id of the linkage that is being setup for this thing.<br />
|-<br />
|thing<br />
|Id – Unique id of the thing to which the linkage should be established.<br />
|-<br />
|}<br />
<br />
==The "pickreq" Element{{anchor|pickreq}}==<br />
<br />
The "pickreq" element defines a [[Dependencies on Specific Things|dependency on a specific thing]] whose existence is important within the container. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|thing<br />
|Id – Unique id of the thing upon which the dependency is being established.<br />
|-<br />
|iserror<br />
|(Optional) Boolean – Indicates whether failure of the requirement should be treated as an error or merely a warning. Default: "yes".<br />
|-<br />
|ispreclude<br />
|(Optional) Boolean – Indicates whether the specified thing must exist or must not exist within the container in order for the requirement to be satisfied. Preclusion implies that the thing is not allowed to exist. Default: "no".<br />
|-<br />
|onlyonce<br />
|(Optional) Boolean – Indicates whether the pre-requisite should only be reported to the user a single time if it fails, regardless of the number of times the thing is added to the container. Default: "no".<br />
|-<br />
|issilent<br />
|(Optional) Boolean – Indicates whether the pre-requisite should report an error message to the user if failed. Default: "no".<br />
|-<br />
|}<br />
<br />
==The "exprreq" Element{{anchor|exprreq}}==<br />
<br />
The "exprreq" element defines a [[Expression-Based Requirements|dependency on an arithmetic expression]] that must be satisfied by the container. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|message<br />
|Text – Specifies the message to be reported if the requirement is not satisfied.<br />
|-<br />
|iserror<br />
|(Optional) Boolean – Indicates whether failure of the requirement should be treated as an error or merely a warning. Default: "yes".<br />
|-<br />
|onlyonce<br />
|(Optional) Boolean – Indicates whether the pre-requisite should only be reported to the user a single time if it fails, regardless of the number of times the thing is added to the container. Default: "no".<br />
|-<br />
|issilent<br />
|(Optional) Boolean – Indicates whether the pre-requisite should report an error message to the user if failed. Default: "no".<br />
|-<br />
|PCDATA<br />
|Text – Specifies an arithmetic expression that is applied to the container to determine whether the requirement is satisfied. The expression must be a valid chunk of script code that can be placed between the parentheses in a standard "if/then" statement (e.g. "if (expr) then").<br />
|-<br />
|}<br />
<br />
==The "child" Element{{anchor|child}}==<br />
<br />
The "child" element specifies an entity that is always added as a [[Advanced Gizmos|child gizmo]] of the thing. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|entity<br />
|Id – Specifies the unique id of the entity to be attached as a child gizmo.<br />
|-<br />
|}<br />
<br />
The "child" element also possesses child elements that tailor the entity. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the gizmo when it is created.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped into the gizmo when it is created.<br />
|-<br />
|}<br />
<br />
==The "minion" Element{{anchor|minion}}==<br />
<br />
The "minion" element specifies that the thing always [[Minions and Masters|attaches a minion]]. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id to be used for the minion attached via this thing.<br />
|-<br />
|ownmode<br />
|(Optional) Boolean – Indicates whether the minion has an independent creation/advancement mode from its master. In some cases, you will want the minion to possess the same behavior as the master and transition with the master. However, if the minion is constructed as an independent character, you may want to handle advancement separately. Default: "yes".<br />
|-<br />
|isinherit<br />
|(Optional) Boolean – Indicates whether the minion inherits the set of enabled sources from its master. If inheritance is active, the source selections for the master are locked in for the minion, with any changes to the master being immediately reflected within the minion. Default: "no".<br />
|-<br />
|}<br />
<br />
The "minion" element also possesses child elements that tailor the minion. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the minion when it is created.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped into the minion when it is created.<br />
|-<br />
|}<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "thing" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<thing id="MyThing" name="Sample" compset="Race" isunique="yes"<br />
description="Description goes here"><br />
<fieldval field="FieldId" value="42"/><br />
<tag group="Helper" tag="MyTag"/><br />
<bootstrap thing="MyAbility"/><br />
<eval phase="Setup" priority="5000"><br />
~script code goes here<br />
</eval><br />
</thing><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Thing_Element_(Data)&diff=2990Thing Element (Data)2009-05-12T08:49:24Z<p>Rob: /* The "thing" Element */</p>
<hr />
<div>{{context|Kit Reference|Data File Reference}}<br />
<br />
==The "thing" Element==<br />
<br />
The vast majority of objects that will comprise your data files are "things", which will be added to actors and customized via scripts. By definition, all behaviors for things are inherited by any derived picks, unless specified otherwise. Each thing is specified through the use of a "thing" element. The complete list of attributes for this element is below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id of the thing. This id is used in all references to the thing.<br />
|-<br />
|compset<br />
|Id – Specifies the unique id of the component set from which this thing is derived.<br />
|-<br />
|name<br />
|Text – Public name associated with the thing. Maximum length of 100 characters.<br />
|-<br />
|description<br />
|(Optional) Text – Detailed description text associated with the thing, for display to the user. Default: Empty.<br />
|-<br />
|summary<br />
|(Optional) Text – Brief summary description for the thing, for display to the user in space-constrained situations. If empty, the full description is always used as the summary. Default: Empty.<br />
|-<br />
|isunique<br />
|(Optional) Boolean – Indicates whether this thing is treated as unique within each container. If unique, a single pick is only ever added, while non-unique things can be separately added any number of times. Default: "no".<br />
|-<br />
|holdable<br />
|(Optional) Boolean – Indicates whether this thing can be held within other other things, such as backpacks hold various pieces of gear. Default: "yes".<br />
|-<br />
|maxlimit<br />
|(Optional) Integer – Specifies the maximum number of instances of this thing that can be added to a given container. If zero, there is no limit imposed. Default: "0".<br />
|-<br />
|panellink<br />
|(Optional) Id – Specifies the unique id of a panel that is officially associated with this thing. Scripts can generically determine the panel linked to a thing to mark it invalid if picks within the panel are invalid. If empty, the default panel linkage defined by components is assumed. Default: Empty.<br />
|-<br />
|stacking<br />
|(Optional) Set – Designates the default stacking behavior to be assumed whenever this thing is purchased by the user. Must be one of these values:<br />
<ul class="sets"><br />
<li>solo – Item is created individually, so buying 5 of the thing will add 5 separate instances of the thing to the container.</li><br />
<li>new – Item is purchased as a new group, so buying 5 of the thing will add one new instance of the thing that has a quantity of 5.</li><br />
<li>merge – Item is merged to any existing instance of the thing within the container, adding the quantity purchased to the existing quantity. If item does not currently exist, "new" behavior is used.</li><br />
<li>never – Item can never support stacking.</li><br />
<li>Default: "solo".</li><br />
</ul><br />
|-<br />
|lotsize<br />
|(Optional) Integer – Specifies the number of items typically purchased as a single unit when buying this thing. For example, bullets might be purchased by the box, with a box having 25 bullets in it. Default: "1".<br />
|-<br />
|replaces<br />
|(Optional) Id – Specifies the unique id of another thing which is completely replaced by this thing. All references to the replaced thing are automatically mapped to this thing, such as bootstrapping. This allows you to wholesale replace a built-in item with new behaviors of your own choosing. If empty, no replacement behavior is utilized. Default: Empty.<br />
|-<br />
|buytemplate<br />
|(Optional) Id – Specifies the unique id of a template that is used for purchasing the thing. This attribute is only applicable to things which have a child entity and whose purchase cost is variable based on the user-specified composition of the child entity. The specified template is used similarly to the buy template that appears within tables and choosers. However, the template is centered at the bottom of the form used for editing the child gizmo. This mechanism is needed when you have something like a user-customizable magic item within the d20 System, where the cost is based on the options selected by the user. If empty, no template is associated with the thing. Default: Empty.<br />
|-<br />
|xactspecial<br />
|(Optional) Integer – When a buy template is shared between two or more portals or things, the template behavior may need to be tailored based on the usage. If this need arises, this attribute specifies a unique value that identifies this particular usage. By assigning a different value to each usage and keying on it within the template's Position script, you can tailor the template appropriately. Default: "0".<br />
|-<br />
|isprivate<br />
|(Optional) Boolean – Indicates whether this thing should be kept private from users within the integrated Editor. When a user creates a new thing as a copy of another thing, all existing things derived from the compset are presented for use as the copy source. By making this thing private, it will not appear for selection. Default: "no".<br />
|-<br />
|}<br />
<br />
The "thing" element also possesses child elements that define various facets of the thing. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[#fieldval|fieldval]]<br />
|Zero or more "fieldval" elements may appear as defined by the given link. This element specifies the starting value for individual fields within the thing.<br />
|-<br />
|[[#arrayval|arrayval]]<br />
|Zero or more "arrayval" elements may appear as defined by the given link. This element specifies the starting value for individual array and matrix elements within the thing.<br />
|-<br />
|[[#usesource|usesource]]<br />
|Zero or more "usesource" elements may appear as defined by the given link. This element specifies the sources relied upon for this thing to be accessible to the user.<br />
|-<br />
|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the thing.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped when this thing is added to a container.<br />
|-<br />
|[[ContainerReq Element (Data)|containerreq]]<br />
|Zero or more "containerreq" elements may appear as defined by the given link. This element specifies any container requirements for the thing.<br />
|-<br />
|[[#holdlimit|holdlimit]]<br />
|An optional "holdlimit" element may appear as defined by the given link. This element defines a [[HoldLimit Tag Expression]] that restricts the valid set of gear that can be held by the thing.<br />
|-<br />
|[[#gear|gear]]<br />
|An optional "gear" element may appear as defined by the given link. This element defines a [[Gear Script]] for the thing to calculate its weight.<br />
|-<br />
|[[#link|link]]<br />
|Zero or more "link" elements may appear as defined by the given link. This element specifies the specific [[Pick Linkages|pick linkages]] that exist for this thing.<br />
|-<br />
|[[Eval Element (Data)|eval]]<br />
|Zero or more "eval" elements may appear as defined by the given link. This element specifies any [[Eval Script|Eval Scripts]] that must be performed for the thing.<br />
|-<br />
|[[EvalRule Element (Data)|evalrule]]<br />
|Zero or more "evalrule" elements may appear as defined by the given link. This element specifies any [[EvalRule Script|EvalRule Scripts]] that must be performed for the thing.<br />
|-<br />
|[[#pickreq|pickreq]]<br />
|Zero or more "pickreq" elements may appear as defined by the given link. This element specifies any [[Dependencies on Specific Things|dependencies upon other picks]] within the container.<br />
|-<br />
|[[#exprreq|exprreq]]<br />
|Zero or more "exprreq" elements may appear as defined by the given link. This element specifies any [[Expression-Based Requirements|expression-based dependencies ]] upon the state of the container.<br />
|-<br />
|[[PreReq Element (Data)|prereq]]<br />
|Zero or more "prereq" elements may appear as defined by the given link. This element specifies any [[General Pre-Requisites|pre-requisite tests]] that are applied to the thing.<br />
|-<br />
|[[#child|child]]<br />
|An optional "child" element may appear as defined by the given link. This element defines the particulars of a child entity that is attached by the thing.<br />
|-<br />
|[[#minion|minion]]<br />
|An optional "minion" element may appear as defined by the given link. This element defines the particulars of a minion that is attached by the thing.<br />
|-<br />
|}<br />
<br />
==The "fieldval" Element{{anchor|fieldval}}==<br />
<br />
The "fieldval" element defines the starting values to use for various fields within the thing. To initialize elements within arrays and matrices, please see the "arrayval" element (below). The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|field<br />
|Id – Unique id of the field for which to specify a starting value.<br />
|-<br />
|value<br />
|Text – Starting value to assign to the field. If the field is text-based, the value is simply assigned, although it may be truncated if it exceeds the defined maximum length for the field. If the field is value-based, the text is converted to a floating point value and assigned.<br />
|-<br />
|}<br />
<br />
==The "arrayval" Element{{anchor|arrayval}}==<br />
<br />
The "arrayval" element defines the starting values to use for individual elements within array and matrix fields of the thing. To initialize elements within fields that are not an array or matrix, please see the "fieldval" attribute (above). The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|field<br />
|Id – Unique id of the field for which to specify a starting value. If the field is not an array or matrix, an error is reported.<br />
|-<br />
|index<br />
|Integer – Specifies the row index of the element to be initialized. The first element of arrays and matrices is index zero.<br />
|-<br />
|column<br />
|(Optional) Integer – Specifies the column of the element to be initialized within a matrix. The first element of matrices is index zero. This attribute is required for matrix elements and may be omitted for array elements. Default: Empty.<br />
|-<br />
|value<br />
|Text – Starting value to assign to the field element. If the field is text-based, the value is simply assigned, although it may be truncated if it exceeds the defined maximum length for the field. If the field is value-based, the text is converted to a floating point value and assigned.<br />
|-<br />
|}<br />
<br />
==The "usesource" Element{{anchor|usesource}}==<br />
<br />
The "usesource" element specifies a [[Sources|source]] that this thing is dependent upon. If the designated source is not enabled by the user, this thing will be treated as not existing for the character. You may define a new source on-the-fly via this element by providing a new unique id and the appropriate additional information. However, you should typically avoid doing so, since you cannot control important facets of sources with just-in-time definition. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|source<br />
|Id – Specifies the unique id of the source with which to establish a dependence.<br />
|-<br />
|name<br />
|(Optional) Text – Name to be displayed to the user for this source. Maximum length is 50 characters. If the source already exists, this attribute can be left empty. Default: Empty.<br />
|-<br />
|parent<br />
|(Optional) Id – Specifies the unique id of a different source that is treated as the parent of this source. All sources are displayed in a hierarchy within the "Configure Hero" form. If the source already exists, this attribute can be left empty and the behaviors of the existing source are utilized. If empty and the source does not yet exist, the new source is presented to the user as a top-level selection. Default: Empty.<br />
|-<br />
|}<br />
<br />
==The "gear" Element{{anchor|gear}}==<br />
<br />
The "gear" element defines a [[Gear Script]] for the thing, which is used to calculate the weight of held items and perform additional gear processing on the thing. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|PCDATA<br />
|Script – Specifies the code comprising the Gear script.<br />
|-<br />
|}<br />
<br />
==The "link" Element{{anchor|link}}==<br />
<br />
The "link" element defines a [[Pick Linkages|linkage to another thing]] based on the set of possible linkages defined for the underlying components. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|linkage<br />
|Id – Unique id of the linkage that is being setup for this thing.<br />
|-<br />
|thing<br />
|Id – Unique id of the thing to which the linkage should be established.<br />
|-<br />
|}<br />
<br />
==The "pickreq" Element{{anchor|pickreq}}==<br />
<br />
The "pickreq" element defines a [[Dependencies on Specific Things|dependency on a specific thing]] whose existence is important within the container. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|thing<br />
|Id – Unique id of the thing upon which the dependency is being established.<br />
|-<br />
|iserror<br />
|(Optional) Boolean – Indicates whether failure of the requirement should be treated as an error or merely a warning. Default: "yes".<br />
|-<br />
|ispreclude<br />
|(Optional) Boolean – Indicates whether the specified thing must exist or must not exist within the container in order for the requirement to be satisfied. Preclusion implies that the thing is not allowed to exist. Default: "no".<br />
|-<br />
|onlyonce<br />
|(Optional) Boolean – Indicates whether the pre-requisite should only be reported to the user a single time if it fails, regardless of the number of times the thing is added to the container. Default: "no".<br />
|-<br />
|issilent<br />
|(Optional) Boolean – Indicates whether the pre-requisite should report an error message to the user if failed. Default: "no".<br />
|-<br />
|}<br />
<br />
==The "exprreq" Element{{anchor|exprreq}}==<br />
<br />
The "exprreq" element defines a [[Expression-Based Requirements|dependency on an arithmetic expression]] that must be satisfied by the container. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|message<br />
|Text – Specifies the message to be reported if the requirement is not satisfied.<br />
|-<br />
|iserror<br />
|(Optional) Boolean – Indicates whether failure of the requirement should be treated as an error or merely a warning. Default: "yes".<br />
|-<br />
|onlyonce<br />
|(Optional) Boolean – Indicates whether the pre-requisite should only be reported to the user a single time if it fails, regardless of the number of times the thing is added to the container. Default: "no".<br />
|-<br />
|issilent<br />
|(Optional) Boolean – Indicates whether the pre-requisite should report an error message to the user if failed. Default: "no".<br />
|-<br />
|PCDATA<br />
|Text – Specifies an arithmetic expression that is applied to the container to determine whether the requirement is satisfied. The expression must be a valid chunk of script code that can be placed between the parentheses in a standard "if/then" statement (e.g. "if (expr) then").<br />
|-<br />
|}<br />
<br />
==The "child" Element{{anchor|child}}==<br />
<br />
The "child" element specifies an entity that is always added as a [[Advanced Gizmos|child gizmo]] of the thing. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|entity<br />
|Id – Specifies the unique id of the entity to be attached as a child gizmo.<br />
|-<br />
|}<br />
<br />
The "child" element also possesses child elements that tailor the entity. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the gizmo when it is created.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped into the gizmo when it is created.<br />
|-<br />
|}<br />
<br />
==The "minion" Element{{anchor|minion}}==<br />
<br />
The "minion" element specifies that the thing always [[Minions and Masters|attaches a minion]]. The complete list of attributes for this element is below. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id to be used for the minion attached via this thing.<br />
|-<br />
|ownmode<br />
|(Optional) Boolean – Indicates whether the minion has an independent creation/advancement mode from its master. In some cases, you will want the minion to possess the same behavior as the master and transition with the master. However, if the minion is constructed as an independent character, you may want to handle advancement separately. Default: "yes".<br />
|-<br />
|isinherit<br />
|(Optional) Boolean – Indicates whether the minion inherits the set of enabled sources from its master. If inheritance is active, the source selections for the master are locked in for the minion, with any changes to the master being immediately reflected within the minion. Default: "no".<br />
|-<br />
|}<br />
<br />
The "minion" element also possesses child elements that tailor the minion. The list of these child elements is below and must appear in the order shown. Click on the link to access the details for each element. <br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|[[Tag Element (Data)|tag]]<br />
|Zero or more "tag" elements may appear as defined by the given link. This element specifies any tags that are automatically assigned to the minion when it is created.<br />
|-<br />
|[[Bootstrap Element (Data)|bootstrap]]<br />
|Zero or more "bootstrap" elements may appear as defined by the given link. This element specifies any things that are automatically bootstrapped into the minion when it is created.<br />
|-<br />
|}<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "thing" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<thing id="MyThing" name="Sample" compset="Race" isunique="yes"<br />
description="Description goes here"><br />
<fieldval field="FieldId" value="42"/><br />
<tag group="Helper" tag="MyTag"/><br />
<bootstrap thing="MyAbility"/><br />
<eval phase="Setup" priority="5000"><br />
~script code goes here<br />
</eval><br />
</thing><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Encoded_Text&diff=2989Encoded Text2009-05-12T08:44:20Z<p>Rob: </p>
<hr />
<div>{{context|Basic Concepts and Terminology|Visual Building Blocks}}<br />
<br />
While not exactly a true "building block", encoded text is an important facet of the visual presentation for any game system. Encoded text is the term used for inserting control over colors, fonts, and even bitmaps within text strings. If you want to highlight a word within a string in red, you'll use encoded text. If you want to change the font size for a few works or put a keyword in bold, you'll use encoded text. You can also insert bitmaps into the text stream with encoded text, which makes it possible to do things like display the sequence of dots for traits within the World of Darkness game system.<br />
<br />
The encoding syntax uses the characters '{' and '}' to identify the special codes, much like HTML uses the '<' and '>' characters to wrap special codes. The text found between the '{' and '}' characters is interpreted based on the table given below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|{br}<br />
|Inserts a carriage return into the text at this position.<br />
|-<br />
|{nbsp}<br />
|Inserts a non-breaking space into the text at this position. Word-wrapping behavior is not allowed to occur on a non-breaking space, so the space is tied to whatever other text appears before and/or after it. This can be useful for placing padding around text that changes foreground and/or background colors.<br />
|-<br />
|{spc}<br />
|From this point forward in the text, all sequences of multiple spaces are collapsed into a single space.<br />
|-<br />
|{b} {/b}<br />
|Text following the "{b}" sequence is rendered in bold. This persists until the "{/b}" sequence turns off bold rendering.<br />
|-<br />
|{i} {/i}<br />
|Text following the "{i}" sequence is rendered in italics. This persists until the "{/i}" sequence turns off italics rendering.<br />
|-<br />
|{u} {/u}<br />
|Text following the "{u}" sequence is underlined. This persists until the "{/u}" sequence turns off underline rendering.<br />
|-<br />
|{font name}<br />
|From this point forward in the text, the font with the specified "name" will be used for output. The prevailing size and style are used in conjunction with the new font.<br />
{{note}}Use of a font that is not a standard Windows font will result in the new font being ignored on any computer that does not possess the font. So be sure to only use standard Windows fonts if you plan on distributing your data files to others.<br />
|-<br />
|{size value}<br />
|From this point forward in the text, the font size is changed to the given "value". In order to support fractional point sizes, the value is the number of quarter-points, so a value of 40 would translate to a point size of 10, while a value of 38 would translate to a point size of 9.5. The prevailing font and style are used in conjunction with the new size.<br />
|-<br />
|{revert}<br />
|From this point forward in the text, the original default font characteristics are restored. All states for bold, italics, and underline are reset to off, regardless of the default font characteristics restored. The primary use for this encoding is to output some text in the default font, configure the text properly for a short segment, and then revert to outputting the rest of the text in the original font. This way, the same encoded text works consistently even when the default font varies between situations.<br />
|-<br />
|{text xxxxxx}<br />
|This sequence changes the foreground text color to the color given by "xxxxxx". The format for the color uses standard HTML color syntax, with each character representing a hexadecimal digit. The first two characters define the Red color value, the next two Green, and the last two Blue. For example, the encoding "{text ff0080}" specifies a Red value of "ff", a Green value of "00", and a Blue value of "80". To revert the foreground text color back to the default, use a color value of "010101".<br />
{{note}}For additional details on specifying colors via the HTML syntax, please refer to one of the many websites that provide this information, such as <br />
[http://www.w3schools.com/Html/html_colors.asp http://www.w3schools.com/Html/html_colors.asp].<br />
|-<br />
|{back xxxxxx}<br />
|This sequence changes the background text color to the color given by "xxxxxx". The color format uses standard HTML syntax, as described for "{text}" above. To disable use of a background color and display text transparently, use a color value of "010101".<br />
|-<br />
|{align position}<br />
|From this point forward in the text, each new line of text will be aligned based on the given "position". The position must be one of the following values: "left" for left-aligned text, "right" for right-aligned text, or "center" for centered text.<br />
|-<br />
|{vert value}<br />
|Vertical spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{horz value}<br />
|Horizontal spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{offset value}<br />
|From this point forward, every new line of text has "value" pixels of horizontal spacing inserted at the start of the line. The offset persists, allowing large blocks of text to be inset from other text. You can turn off the offset by applying an equivalent negative offset. Repeated uses of "offset" are cumulative.<br />
|-<br />
|{indent value}<br />
|From this point forward, every new paragraph of text gains an indentation behavior dictated by "value". If "value" is positive, normal indentation logic is used and the first line of each paragraph is indented that number of pixels. If "value" is negative, a hanging indent is applied, with the second and subsequent lines being indented the specified number of pixels (as an absolute value). Repeated uses of "indent" are cumulative, except for a value of zero, which turns off any active indent behavior.<br />
|-<br />
|{bmp name}<br />
|Inserts into the output the bitmap image with the file name of "name.bmp" that resides in the data file directory for the game system. This bitmap is assumed to be transparent, with the pixel at (0,0) indicating the transparent color. For example, the code "{bmp foo}" would insert the bitmap file named "foo.bmp" that is found in the game system directory. <br />
{{note}} If the bitmap is not found or the output doesn't support encoding, the "name" is inserted as text. So if the filename is "[R].bmp" and referenced as "{bmp [R]}", the text inserted would be "[R]".<br> <br />
{{note}} By default, bitmaps are never scaled when output, but individual styles can explicitly enable scaling of bitmaps inserted via encoded text. If scaling is enabled, the bitmaps may not look ideal due to the scaling.<br />
|-<br />
|{bmpscale factor name}<br />
|As {bmp name}, above, except the the bitmap is scaled by a factor of "factor" (from 2-9) before being output. For example, if you create a bitmap "somebitmap.bmp" with a size of 400x400 and then output it using {bmpscale 4 somebitmap}, it will be drawn with a size of 100x100. This can be useful for drawing bitmaps at large scales, then shrinking them down for use on high-dpi mediums (such as printed pages).<br />
{{note}}This is only recommended for use on output sheets. Due to the windows bitmap resizing algorithm, results of this will likely be poor if used on the screen.<br />
|-<br />
|{meta behavior}<br />
|The behavior specifies a new rendering behavior that will persist until it is again changed. The specified behavior must be one of the following values:<br />
<ul class="sets"><br />
<li>bmpfull – Bitmaps embedded in the encoded text are vertically centered within the full height of the text, including the region of any descender.</li><br />
<li>bmpbaseline – Bitmaps embedded in the encoded text are vertically centered between the baseline of the text and the top edge of the text. This is the default behavior used by encoded text.</li><br />
<li>revert – All behavior changes applied via "meta" special codes are reverted to their default state.</li><br />
</ul><br />
|-<br />
|{macro name}<br />
|Looks for the macro with the unique id given by name and processes the contents of that macro as if it were found in the text instead. This means that macros MAY include encoded text that will be properly processed when the macro is evaluated.<br />
{{note}}Macros MAY be nested within each other, but only to a limited extent, so use nesting sparingly. If a macro references another macro within it, the nested macro will be correctly processed, up to a small number of nesting levels.<br />
NOTE! If an undefined macro is referenced, a message of the form "[Undefined macro: name]" is inserted into the resulting text where the macro would be.<br />
|-<br />
|{ref name}<br />
|Designates the start of a reference region (or "hot zone") that the user can click within to obtain additional information. The name specifies the predefined reference to show when the user clicks in the zone. The zone spans all text from this point forward until the zone is terminated. Terminating a reference zone is accomplished by leaving the name blank. The following is an example of using a reference: "before {ref foo}hot zone{ref} after".<br />
{{note}}If an undefined reference is used, a message of the form "[Undefined reference: name]" is displayed when the reference hot zone is clicked within by the user.<br />
|-<br />
|{url name}<br />
|Designates the start of a hot zone corresponding to an internet URL. The name specifies the actual URL to which the user will be sent when the zone is clicked within (e.g. <nowiki>"http://www.wolflair.com"</nowiki>). The zone spans all text from this point forward until the zone is terminated. Terminating a URL zone is accomplished by leaving the name blank. The following is an example of using a URL zone: <nowiki>"before {url http://www.wolflair.com}hot zone{url} after"</nowiki>.<br />
{{note}}When clicked, Windows is instructed to launch the default web browser that is currently configured by the user and to load the specified URL into that browser. If no browser is properly configured, an error will be reported. If the URL is invalid, the web browser will report that to the user.<br />
|-<br />
|\n<br />
|Identical to "{br}". This is a programming convenience for automated conversion programs written in C/C++.<br />
|-<br />
|}<br />
<br />
{{important}}Not everything within HL makes use of encoded text, so be sure to check the documentation first. If you use encoded text in a place where it's not supported, you will see your embedded special codes within the text displayed.<br />
<br />
{{note}}Encoded text sequences ignore case, so "{BR}" is identical to "{br}". Exceptions to this are macro and reference names, which are case-sensitive. Similarly, URLs are case-sensitive if the website being addressed uses case-sensitive URLs.<br />
<br />
{{note}}If the text within an encoding does not correctly match one of the codes defined above, the text is left unchanged, except as noted above.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Encoded_Text&diff=2988Encoded Text2009-05-12T08:43:40Z<p>Rob: </p>
<hr />
<div>{{context|Basic Concepts and Terminology|Visual Building Blocks}}<br />
<br />
While not exactly a true "building block", encoded text is an important facet of the visual presentation for any game system. Encoded text is the term used for inserting control over colors, fonts, and even bitmaps within text strings. If you want to highlight a word within a string in red, you'll use encoded text. If you want to change the font size for a few works or put a keyword in bold, you'll use encoded text. You can also insert bitmaps into the text stream with encoded text, which makes it possible to do things like display the sequence of dots for traits within the World of Darkness game system.<br />
<br />
The encoding syntax uses the characters '{' and '}' to identify the special codes, much like HTML uses the '<' and '>' characters to wrap special codes. The text found between the '{' and '}' characters is interpreted based on the table given below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|{br}<br />
|Inserts a carriage return into the text at this position.<br />
|-<br />
|{nbsp}<br />
|Inserts a non-breaking space into the text at this position. Word-wrapping behavior is not allowed to occur on a non-breaking space, so the space is tied to whatever other text appears before and/or after it. This can be useful for placing padding around text that changes foreground and/or background colors.<br />
|-<br />
|{spc}<br />
|From this point forward in the text, all sequences of multiple spaces are collapsed into a single space.<br />
|-<br />
|{b} {/b}<br />
|Text following the "{b}" sequence is rendered in bold. This persists until the "{/b}" sequence turns off bold rendering.<br />
|-<br />
|{i} {/i}<br />
|Text following the "{i}" sequence is rendered in italics. This persists until the "{/i}" sequence turns off italics rendering.<br />
|-<br />
|{u} {/u}<br />
|Text following the "{u}" sequence is underlined. This persists until the "{/u}" sequence turns off underline rendering.<br />
|-<br />
|{font name}<br />
|From this point forward in the text, the font with the specified "name" will be used for output. The prevailing size and style are used in conjunction with the new font.<br />
{{note}}Use of a font that is not a standard Windows font will result in the new font being ignored on any computer that does not possess the font. So be sure to only use standard Windows fonts if you plan on distributing your data files to others.<br />
|-<br />
|{size value}<br />
|From this point forward in the text, the font size is changed to the given "value". In order to support fractional point sizes, the value is the number of quarter-points, so a value of 40 would translate to a point size of 10, while a value of 38 would translate to a point size of 9.5. The prevailing font and style are used in conjunction with the new size.<br />
|-<br />
|{revert}<br />
|From this point forward in the text, the original default font characteristics are restored. All states for bold, italics, and underline are reset to off, regardless of the default font characteristics restored. The primary use for this encoding is to output some text in the default font, configure the text properly for a short segment, and then revert to outputting the rest of the text in the original font. This way, the same encoded text works consistently even when the default font varies between situations.<br />
|-<br />
|{text xxxxxx}<br />
|This sequence changes the foreground text color to the color given by "xxxxxx". The format for the color uses standard HTML color syntax, with each character representing a hexadecimal digit. The first two characters define the Red color value, the next two Green, and the last two Blue. For example, the encoding "{text ff0080}" specifies a Red value of "ff", a Green value of "00", and a Blue value of "80". To revert the foreground text color back to the default, use a color value of "010101".<br />
{{note}}For additional details on specifying colors via the HTML syntax, please refer to one of the many websites that provide this information, such as <br />
[http://www.w3schools.com/Html/html_colors.asp http://www.w3schools.com/Html/html_colors.asp].<br />
|-<br />
|{back xxxxxx}<br />
|This sequence changes the background text color to the color given by "xxxxxx". The color format uses standard HTML syntax, as described for "{text}" above. To disable use of a background color and display text transparently, use a color value of "010101".<br />
|-<br />
|{align position}<br />
|From this point forward in the text, each new line of text will be aligned based on the given "position". The position must be one of the following values: "left" for left-aligned text, "right" for right-aligned text, or "center" for centered text.<br />
|-<br />
|{vert value}<br />
|Vertical spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{horz value}<br />
|Horizontal spacing is immediately inserted into the output, with "value" indicating the number of pixels worth of gap to insert.<br />
|-<br />
|{offset value}<br />
|From this point forward, every new line of text has "value" pixels of horizontal spacing inserted at the start of the line. The offset persists, allowing large blocks of text to be inset from other text. You can turn off the offset by applying an equivalent negative offset. Repeated uses of "offset" are cumulative.<br />
|-<br />
|{indent value}<br />
|From this point forward, every new paragraph of text gains an indentation behavior dictated by "value". If "value" is positive, normal indentation logic is used and the first line of each paragraph is indented that number of pixels. If "value" is negative, a hanging indent is applied, with the second and subsequent lines being indented the specified number of pixels (as an absolute value). Repeated uses of "indent" are cumulative, except for a value of zero, which turns off any active indent behavior.<br />
|-<br />
|{bmp name}<br />
|Inserts into the output the bitmap image with the file name of "name.bmp" that resides in the data file directory for the game system. This bitmap is assumed to be transparent, with the pixel at (0,0) indicating the transparent color. For example, the code "{bmp foo}" would insert the bitmap file named "foo.bmp" that is found in the game system directory. <br />
{{note}} If the bitmap is not found or the output doesn't support encoding, the "name" is inserted as text. So if the filename is "[R].bmp" and referenced as "{bmp [R]}", the text inserted would be "[R]". <br />
{{note}} By default, bitmaps are never scaled when output, but individual styles can explicitly enable scaling of bitmaps inserted via encoded text. If scaling is enabled, the bitmaps may not look ideal due to the scaling.<br />
|-<br />
|{bmpscale factor name}<br />
|As {bmp name}, above, except the the bitmap is scaled by a factor of "factor" (from 2-9) before being output. For example, if you create a bitmap "somebitmap.bmp" with a size of 400x400 and then output it using {bmpscale 4 somebitmap}, it will be drawn with a size of 100x100. This can be useful for drawing bitmaps at large scales, then shrinking them down for use on high-dpi mediums (such as printed pages).<br />
{{note}}This is only recommended for use on output sheets. Due to the windows bitmap resizing algorithm, results of this will likely be poor if used on the screen.<br />
|-<br />
|{meta behavior}<br />
|The behavior specifies a new rendering behavior that will persist until it is again changed. The specified behavior must be one of the following values:<br />
<ul class="sets"><br />
<li>bmpfull – Bitmaps embedded in the encoded text are vertically centered within the full height of the text, including the region of any descender.</li><br />
<li>bmpbaseline – Bitmaps embedded in the encoded text are vertically centered between the baseline of the text and the top edge of the text. This is the default behavior used by encoded text.</li><br />
<li>revert – All behavior changes applied via "meta" special codes are reverted to their default state.</li><br />
</ul><br />
|-<br />
|{macro name}<br />
|Looks for the macro with the unique id given by name and processes the contents of that macro as if it were found in the text instead. This means that macros MAY include encoded text that will be properly processed when the macro is evaluated.<br />
{{note}}Macros MAY be nested within each other, but only to a limited extent, so use nesting sparingly. If a macro references another macro within it, the nested macro will be correctly processed, up to a small number of nesting levels.<br />
NOTE! If an undefined macro is referenced, a message of the form "[Undefined macro: name]" is inserted into the resulting text where the macro would be.<br />
|-<br />
|{ref name}<br />
|Designates the start of a reference region (or "hot zone") that the user can click within to obtain additional information. The name specifies the predefined reference to show when the user clicks in the zone. The zone spans all text from this point forward until the zone is terminated. Terminating a reference zone is accomplished by leaving the name blank. The following is an example of using a reference: "before {ref foo}hot zone{ref} after".<br />
{{note}}If an undefined reference is used, a message of the form "[Undefined reference: name]" is displayed when the reference hot zone is clicked within by the user.<br />
|-<br />
|{url name}<br />
|Designates the start of a hot zone corresponding to an internet URL. The name specifies the actual URL to which the user will be sent when the zone is clicked within (e.g. <nowiki>"http://www.wolflair.com"</nowiki>). The zone spans all text from this point forward until the zone is terminated. Terminating a URL zone is accomplished by leaving the name blank. The following is an example of using a URL zone: <nowiki>"before {url http://www.wolflair.com}hot zone{url} after"</nowiki>.<br />
{{note}}When clicked, Windows is instructed to launch the default web browser that is currently configured by the user and to load the specified URL into that browser. If no browser is properly configured, an error will be reported. If the URL is invalid, the web browser will report that to the user.<br />
|-<br />
|\n<br />
|Identical to "{br}". This is a programming convenience for automated conversion programs written in C/C++.<br />
|-<br />
|}<br />
<br />
{{important}}Not everything within HL makes use of encoded text, so be sure to check the documentation first. If you use encoded text in a place where it's not supported, you will see your embedded special codes within the text displayed.<br />
<br />
{{note}}Encoded text sequences ignore case, so "{BR}" is identical to "{br}". Exceptions to this are macro and reference names, which are case-sensitive. Similarly, URLs are case-sensitive if the website being addressed uses case-sensitive URLs.<br />
<br />
{{note}}If the text within an encoding does not correctly match one of the codes defined above, the text is left unchanged, except as noted above.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Procedure_Element_(Data)&diff=2987Procedure Element (Data)2009-05-12T08:26:52Z<p>Rob: /* The "procedure" Element */</p>
<hr />
<div>{{context|Kit Reference|Data File Reference}}<br />
<br />
==The "procedure" Element==<br />
<br />
If you need to invoke the same script code from multiple scripts, then you should consider writing a [[Re-usable Procedures|re-usable procedure]] that defines the code once and can be called from multiple scripts. Each procedure is defined through the use of a "procedure" element. The complete list of attributes for this element is below.<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|id<br />
|Id – Specifies the unique id of the procedure. This id is used in all references to the procedure.<br />
|-<br />
|context<br />
|(Optional) Set – Designates a general script context from which this procedure is designed to be called. A script context spans multiple different script types that are related in nature and behavior. Must be one of these values:<br />
<ul class="sets"><br />
<li>unknown – Procedure may only be invoked from within a specific type of script, as dictated by the "scripttype" attribute (below).</li><br />
<li>pick – Procedure can be called from any script with a pick as its initial context.</li><br />
<li>container – Procedure can be called from any script with a container as its initial context.</li><br />
<li>entity – Procedure can be called from entity-related scripts, such as the [[TitleBar Script]].</li><br />
<li>info – Procedure can be called from any information synthesis script for a thing or pick, such as the [[MouseInfo Script]].</li><br />
<li>transact – Procedure can be called from any transaction script, such as the [[TransactBuy Script]].</li><br />
<li>combat – Procedure can be called from any combat-related script, such as the [[NewCombat Script]].</li><br />
<li>Default: "unknown".</li><br />
</ul><br />
|-<br />
|scripttype<br />
|(Optional) Set – Designates the specific script type from which this procedure may be called. The procedure may only be called from scripts of this type. Must be one of these values:<br />
<ul class="sets"><br />
<li>unknown – Procedure may be invoked from a general category of scripts, as dictated by the "context" attribute (above).</li><br />
<li>finalize – Procedure may only be called from within a [[Finalize Script]].</li><br />
<li>calculate – Procedure may only be called from within a [[Calculate Script]].</li><br />
<li>bounds – Procedure may only be called from within a [[Bound Script]].</li><br />
<li>eval – Procedure may only be called from within an [[Eval Script]].</li><br />
<li>evalrule – Procedure may only be called from within an [[EvalRule Script]].</li><br />
<li>mouseinfo – Procedure may only be called from within a [[MouseInfo Script]].</li><br />
<li>titlebar – Procedure may only be called from within a [[TitleBar Script]].</li><br />
<li>description – Procedure may only be called from within a [[Description Script]].</li><br />
<li>trigger – Procedure may only be called from within a [[Trigger Script]].</li><br />
<li>label – Procedure may only be called from within a [[Label Script]].</li><br />
<li>validate – Procedure may only be called from within a [[Validate Script]].</li><br />
<li>xactsetup – Procedure may only be called from within a [[TransactSetup Script]].</li><br />
<li>xactbuy – Procedure may only be called from within a [[TransactBuy Script]].</li><br />
<li>xactsell – Procedure may only be called from within a [[TransactSell Script]].</li><br />
<li>newcombat – Procedure may only be called from within a [[NewCombat Script]].</li><br />
<li>endcombat – Procedure may only be called from within an [[EndCombat Script]].</li><br />
<li>newturn – Procedure may only be called from within a [[NewTurn Script]].</li><br />
<li>integrate – Procedure may only be called from within an [[Integrate Script]].</li><br />
<li>synthesize – Procedure may only be called from within a [[Synthesize Script]].</li><br />
<li>none – Procedure may be called from '''any''' type of script. However, there is no initial context for identifiers, so no context transitions may be specified that don't explicitly designate a safe initial context (e.g. "hero."). This procedure type is useful when all inputs can be passed via variables and all results returned via variables.<li><br />
<li>Default: "unknown".</li><br />
</ul><br />
{{note}}It is '''valid''' to setup a focus pick via "setfocus" within a calling script and then utilize the inherited focus pick within a procedure of type "none".<br />
|-<br />
|PCDATA<br />
|Script – Specifies the code comprising the procedure.<br />
|-<br />
|}<br />
<br />
==Example==<br />
<br />
The following example demonstrates what a "procedure" element might look like. All default values are assumed for optional attributes.<br />
<br />
<pre><br />
<procedure id="MyProc" context="info"><br />
~insert script code here<br />
</procedure><br />
<br />
<procedure id="MyProc" scripttype="eval"><br />
~insert script code here<br />
</procedure><br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=EndCombat_Script&diff=2986EndCombat Script2009-05-12T08:18:20Z<p>Rob: Created page with '{{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Pick |- |Alternate Context: |None |-...'</p>
<hr />
<div>{{context|Kit Reference|Script Types}}<br />
<br />
==Technical Details==<br />
<br />
:{| class="scripttable"<br />
|class="leftnormal"|Initial Context:<br />
|[[Pick Context|Pick]]<br />
|-<br />
|Alternate Context:<br />
|None<br />
|-<br />
|Fields Finalized?<br />
|No<br />
|-<br />
|Where Used:<br />
|[[Behavior Element (Data)|Definition File]]<br />
|-<br />
|Procedure Use:<br />
|"endcombat" type, "pick" context<br />
|-<br />
|}<br />
<br />
The EndCombat script utilizes the following special symbols:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|isfirst<br />
|(Number) Entry: Non-zero if this script is being invoked for the first actor in the portfolio.<br><br />
Exit: Ignored.<br />
|-<br />
|}<br />
<br />
==Description==<br />
<br />
The EndCombat script is the counterpart of the NewCombat script and is invoked whenever the user triggers the end of a combat within the Tactical Console. When combat is ended, this script is applied to each actor. Like its counterpart, the EndCombat script starts with the "actor" pick of an actor in the combat as its initial context. It is invoked for all actors in the combat (non-combatants are ignored). This allows the author to reset state for each actor after combat completes.<br />
<br />
==Example==<br />
<br />
In various game systems, there is the notion of "waiting" or "holding an action". This state will persist for each actor after combat ends, so it can be reset at the end of combat instead of at the start.<br />
<br />
<pre><br />
herofield[acAbandon].value = 0<br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Script_Types&diff=2985Script Types2009-05-12T08:15:12Z<p>Rob: /* Trigger */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Kit leverages a diverse assortment of scripts for a wide range of purposes. The topics below provide a brief discussion of both the role and behavior of each different type of script. The scripts have been grouped into general categories for improved utility.<br />
<br />
==Pick Manipulation==<br />
<br />
These scripts manipulate the contents of picks during the evaluation cycle.<br />
<br />
*{{fl|Eval Script}}<br />
*{{fl|Gear Script}}<br />
<br />
==Field Manipulation==<br />
<br />
These scripts manipulate the contents of fields for both display and constraint.<br />
<br />
*{{fl|Bound Script}}<br />
*{{fl|Calculate Script}}<br />
*{{fl|Finalize Script}}<br />
*{{fl|InitFinalize Script}}<br />
<br />
==Validation==<br />
<br />
These scripts apply validation tests to objects with integrated reporting of errors.<br />
<br />
*{{fl|EvalRule Script}}<br />
*{{fl|Validate Script}}<br />
*{{fl|Integrity Script}}<br />
<br />
==Creation/Deletion==<br />
<br />
These scripts perform appropriate setup and cleanup of specialized objects.<br />
<br />
*{{fl|Creation Script}}<br />
*{{fl|Deletion Script}}<br />
<br />
==Visual Positioning==<br />
<br />
These scripts manage the size and positioning of visual elements within panels and sheets.<br />
<br />
*{{fl|Position Script}}<br />
*{{fl|Header Script}}<br />
<br />
==Synthesis & Presentation==<br />
<br />
These scripts synthesize information for display to the user in some fashion, including labels, descriptions, mouse-over information, and stat blocks.<br />
<br />
*{{fl|Description Script}}<br />
*{{fl|MouseInfo Script}}<br />
*{{fl|Label Script}}<br />
*{{fl|TitleBar Script}}<br />
*{{fl|HeaderTitle Script}}<br />
*{{fl|AddItem Script}}<br />
*{{fl|Chosen Script}}<br />
*{{fl|LeadSummary Script}}<br />
*{{fl|Synthesize Script}}<br />
<br />
==Trigger==<br />
<br />
These scripts are invoked in direct response to user actions, such as merging and splitting stackable gear, controlling combat and turns, etc.<br />
<br />
*{{fl|Trigger Script}}<br />
*{{fl|Integrate Script}}<br />
*{{fl|NewCombat Script}}<br />
*{{fl|EndCombat Script}}<br />
*{{fl|NewTurn Script}}<br />
*{{fl|Initiative Script}}<br />
*{{fl|Merge Script}}<br />
*{{fl|Split Script}}<br />
*{{fl|Change Script}}<br />
<br />
==Transaction==<br />
<br />
These scripts are associated with the buying and selling of equipment.<br />
<br />
*{{fl|TransactSetup Script}}<br />
*{{fl|TransactBuy Script}}<br />
*{{fl|TransactSell Script}}<br />
<br />
==Mode Transition==<br />
<br />
These scripts associated with the transition into and out of advancement mode.<br />
<br />
*{{fl|CanAdvance Script}}<br />
*{{fl|Transition Script}}<br />
<br />
==Release Changes==<br />
<br />
These scripts are used to accommodate changes between data file releases and potential loading errors of portfolios.<br />
<br />
*{{fl|LoadError Script}}<br />
*{{fl|LoadFixup Script}}</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Synthesize_Script&diff=2984Synthesize Script2009-05-12T08:14:12Z<p>Rob: /* Description */</p>
<hr />
<div>{{context|Kit Reference|Script Types}}<br />
<br />
==Technical Details==<br />
<br />
:{| class="scripttable"<br />
|class="leftnormal"|Initial Context:<br />
|[[Hero Context|Hero]]<br />
|-<br />
|Alternate Context:<br />
|None<br />
|-<br />
|Fields Finalized?<br />
|Yes<br />
|-<br />
|Where Used:<br />
|[[Dossier Element (Data)|Dossiers]]<br />
|-<br />
|Procedure Use:<br />
|"synthesize" type, "container" context<br />
|-<br />
|}<br />
<br />
The Synthesize script utilizes the following special symbols:<br />
<br />
:{| class="infotable"<br />
|class="leftnormal"|newline<br />
|(String) Entry: Contains the appropriate text to begin a new line of text within the output being synthesized (i.e. insert a line break).<br><br />
Exit: Ignored.<br />
|-<br />
|boldon<br />
|(String) Entry: Contains the appropriate text to turn on output of bold text.<br><br />
Exit: Ignored.<br />
|-<br />
|boldoff<br />
|(String) Entry: Contains the appropriate text to turn off output of bold text.<br><br />
Exit: Ignored.<br />
|-<br />
|italicson<br />
|(String) Entry: Contains the appropriate text to turn on output of italic text.<br><br />
Exit: Ignored.<br />
|-<br />
|italicsoff<br />
|(String) Entry: Contains the appropriate text to turn off output of italic text.<br><br />
Exit: Ignored.<br />
|-<br />
|separator<br />
|(String) Entry: Contains the appropriate text to insert a suitable horizontal separator. In HTML output, this is the "<nowiki><hr></nowiki>" element, and elsewhere it's a line consisting of a string of dashes.<br><br />
Exit: Ignored.<br />
|-<br />
|}<br />
<br />
==Description==<br />
<br />
The Synthesize script is utilized when generating text output for a character dossier. A classic example is the creation of statblock output. When the user requests text output, he will also specify the style to be used when synthesizing the output (e.g. HTML, BBCode, or plain text). Before the script is invoked, HL will setup a number of appropriate mechanisms for that output style, which are provided via the various special symbols. For example, in HTML output, the "@boldon" special symbol will map to "<nowiki><b></nowiki>", while it will be "[b]" for BBCode output and do nothing for plain text output. This makes it possible for you to write a single Synthesize script that will generate output properly for each different style, without having to do any special handling within the script.<br />
<br />
Unlike other scripts, the Synthesize script does not use a "@text" special symbol. Since the volume of output in some cases will be significant, using the standard approach simply isn't practical or efficient. Instead, the output is generated in sequential fashion, and the "append" language statement is used to accomplish this ([[Other Language Statements|see details]]). The "append" statement allows you to systematically construct the output, one section at a time. Once something is output, you can forget about it and let HL handle it.<br />
<br />
If you need to do special formatting within a Synthesize script that is based on the output style, you can. You can find out the style by using the the "isdossierstyle" script target reference from within the [[State Context|State script context]].<br />
<br />
The Synthesize script starts with the actor to be output as its initial context. You can then cull whatever information you need from the actor for inclusion within the output.<br />
<br />
{{note}} The Synthesize script is read-only. Within this script, virtually all aspects of the structural hierarchy can be accessed, but nothing can be changed.<br />
<br />
{{note}} While within a Synthesize script and any procedures that are invoked, a global tag is automatically assigned by HL. The tag belongs to the "dossier" tag group and has the unique id of the dossier being output. This allows the script code to base its behavior on the actual dossier that the user is outputting.<br />
<br />
==Example==<br />
<br />
Every statblock starts with the character's name and then continues with other appropriate information that depends on the game system. The example below shows the start of a Synthesize script that includes the name, race, and age of the character.<br />
<br />
<pre><br />
var txt as string<br />
<br />
~start by getting our name<br />
if (empty(hero.actorname) = 0) then<br />
txt = hero.actorname<br />
else<br />
txt = "Unnamed Character"<br />
endif<br />
<br />
~output our name<br />
append @boldon & "Name: " & @boldoff & txt & @newline<br />
<br />
~output any race<br />
txt = hero.firstchild["Race.?"].field[name].text<br />
if (empty(txt) <> 0) then<br />
txt = "-none-"<br />
endif<br />
append @boldon & "Race: " & @boldoff & txt & @newline<br />
<br />
~output age<br />
append @boldon & "Age: " & @boldoff & hero.child[mscPerson].field[perAge].text & @newline<br />
</pre></div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Functionality_Revision_History&diff=2983Functionality Revision History2009-05-12T07:39:17Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
Beginning with the V3.1 release, a summary of the functional changes and enhancements to the Kit within each release is provided below.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Extended "foreach" statement to support "foreach thing in component" syntax, which processes all things derived from a specified component.<br />
#Extended "foreach" statement to support "foreach bootstrap in thing", which processes all things that are directly bootstrapped by an identified thing.<br />
#Extended "foreach" statement to support "foreach bootstrap in entity" for use within Description scripts, which processes all things directly attached to the entity associated with the current thing context.<br />
#The "isentity" target reference on picks and things indicates whether the item has a child entity attached.<br />
#The "isgizmo" target reference behaves equally for things as well as picks.<br />
#Picks with attached entities are treated the same as minions with respect to the scheduling of the final condition test. This means the final condition test is scheduled at the time of the latest condition test instead of at the earliest script. This change ensures that a single condition test can be defined on a component so that all child picks can safely test their live state, which depends on the live state of the gizmo, which depends on the live state of the pick that attaches the gizmo.<br />
#When auto-tags are assigned via a bootstrap with a condition test, the tags are only assigned to the pick when the condition test is satisfied.<br />
#Bootstraps can selectively override the values assigned to fields within the bootstrapped pick via the "assignval" child element.<br />
#The "editthing" element can be assigned a "prefix" attribute, which will be used by the Editor to setup an initial unique id for new things created within the Editor.<br />
#History tracking for fields with "stack" behavior supports the "=" operator, which overwrites the current value with the new value specified.<br />
#If a field history entry adds or subtracts a negative value, the operator is automatically inverted and the value is negated, changing entries from "+-3" to "-3".<br />
#The "history" target reference for fields and values supports an optional starting value to be shown in the report. Also, the splicing text can be omitted, in which case ", " is used.<br />
#The "history" attribute for fields has a "changes" option available that omits any adjustments that yield no actual change, such as "+0" or "*1".<br />
#When "best" history tracking is used for fields, any adjustments that fail to apply a meaningful change are ignored (like the "changes" behavior above).<br />
#Portals of type "table_fixed" are automatically omitted by the auto-place mechanism when empty.<br />
#Field history tracking is now allowed for fields that possess a Finalize script.<br />
#The "output_dots" portal type was added to make it easy to insert a series of dots between two portals within character sheet output.<br />
#Header portals used within dual-purpose templates may now use scripts, although the initial script context is undefined and the author must immediately transition to a valid context.<br />
#The "ischanged" target reference on fields and values returns whether the field value has been changed in some way from its original starting state.<br />
#The "pushtags" and "pulltags" target references now support containers as either the source or destination, or both.<br />
#The pseudo-field "thingname" provides access to the original name assigned to a thing, which was otherwise inaccessible if the name of a pick was either modified via a script or renamed by the user.<br />
#The "scenevalue" target reference provides a mechanism for managing "global" values within the context of a scene to allow communication between the scene and all layout and template scripts within it.<br />
#The global "state" script context provides support for setting and getting persistent values that are global and exist at the portfolio level, outside of any actor. This mechanism makes it possible to manage state across the entire portfolio.<br />
#The management of global, persistent, named sets of values is provided within the "global" script context via the "setrandom", "setextract", "setremain", and "setdiscard" target references.<br />
#The NewCombat and NewTurn scripts possess an "@isfirst" special symbol, which indicates whether the script is being invoked on the very first actor. This allows one-time handling at the start of a combat or turn that spans all actors.<br />
#The NewCombat and NewTurn scripts are always invoked *before* the Initiative script is invoked for any actor.<br />
#The "shortname" field is now synthesized at a priority of 100 within the "Render" phase, if that phase exists, else in the last phase of evaluation.<br />
#The minimum font size supported by "sizetofit" is now 6-point when rendering to the screen and 4-point when rendering onto sheets for printouts.<br />
#The primary and secondary initiative values for each actor will persist if they are not set to a new value within the Initiative script.<br />
#The InitFinalize script can be specified in the definition file and will be used as the Finalize script for the "initiative" field.<br />
#The "initminimum" and "initmaximum" attributes were added to the "behavior" element in the definition file, dictating the lower and upper bounds for the initiative value when the user adjusts the value via the incrementer in the TacCon.<br />
#The "gaphorz" and "gapvert" target references on visual elements have been renamed to "gapx" and "gapy", respectively, to eliminate confusion regarding their behavior.<br />
#The various "gap" attributes on table portals have been renamed to eliminate confusion about their use. The "showgaphorz" and "showgapvert" attributes are now "showgapx" and "showgapy", respectively. The "choosegaphorz" and "choosegapvert" were renamed to "choosegapx" and "choosegapy".<br />
#Printing of a spillover page continues until a page is generated that contains no data to output, at which point printing continues with the next page.<br />
#Encoded text supports the indenting of the first line of a paragraph via the "{indent value}" syntax. Both normal and hanging indents are supported.<br />
#Menu styles possess the "droplist" and "droplistoff" attributes, allowing the author to override the bitmaps used for the drop-arrow.<br />
#The LeadSummary script is allowed to call procedures, which must be either the "container" context or "any" script type.<br />
#Picks support the "uniqindex" target reference, which returns a value that uniquely identifies the pick throughout the entire portfolio.<br />
#Only "derived" fields may utilize a Calculate script.<br />
#The "output_separator" portal can be used within sheet output to insert an solid black line within the dimensions given.<br />
#The "isroot" target reference (of picks) is accessible from the "template" script context.<br />
#If the "@message" special symbol is set within an Eval Rule, but the "@summary" symbol is not, the returned message text is automatically used as the summary for display on the validation summary bar.<br />
#The "exprreq" and "pickreq" elements on things support the "onlyonce" and "issilent" attributes, exactly the same way as they work on standard "prereq" elements.<br />
#The "image_literal" portal supports the "isbuiltin" attribute, which identifies a bitmap that is provided by HL for general use.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#The dossier being output adds a "dossier.<id>" global tag to the portfolio during output. This allows scripts to check which dossier is being output.<br />
#An "EndCombat" script is invoked on each actor when combat ends.<br />
#An "endcombat" procedure type is supported for use with the EndCombat script.<br />
#The "meta" text encoding allows the alignment behavior of bitmaps to be controlled relative to the position of text when mixing text and bitmaps.<br />
#The scripting language supports the "doneif" statement to simplify coding.<br />
#The "state" script context supports the "thing[id]" transition to directly access all facets of a thing.<br />
#The "modify" target reference for fields supports the "#" operator, which suppresses the display of any operator within the resulting history report.<br />
#The "modify" target reference for fields supports the "$" operator, which inserts a history entry with no field value and only a text description.<br />
#Things possess the "holdlimit" tag expression to restrict the types of things that can be held by the thing within the gear containment hierarchy. This makes it possible to assign laser sights and such to weapons.<br />
#The "it_field" input thing has an optional boolean "multiline" attribute to support the entry of multi-line text fields within the Editor.<br />
#Thing-based menus can specify an alternate field to display for the menu item via the "namefield" attribute.<br />
#The "heromatch" target reference on picks and containers behaves the same as "tagmatch", except that the initial context is always assumed to be the current actor. This allows arbitrary matches against the hero from anywhere.<br />
#Sources possess both the "maxchoices" and "minchoices" attributes. These allow an author to specify a minimum and/or maximum number of child sources that can be selected by the user.<br />
#Added the "plaintext" intrinsic function to the scripting language.<br />
#Added the "amendthing" target reference to the "thing" script context, which allows pertinent feats in 4E to directly modify the powers that they impact.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2982Skeleton Data File Revision History2009-05-12T02:58:19Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from three edit portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#Added support for the "Lot Cost" and "Weight" fields for all types of equipment within the Editor.<br />
#Added a shell "editor.htm" file that can be used as the basis for providing suitable documentation for adding content to the game system via the Editor.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2981Changes in V3.2 (Savage)2009-05-11T20:54:36Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#All ammunition is automatically designated as a "GearType" of "Ammo".<br />
#Eliminated reliance on the "Wingdings 2" font by replacing all uses of that font with suitable alternates from the "Wingdings" font. The "Wingdings 2" font is not always available on all computers.<br />
#Changed the timing of the Eval scripts on the "Rich" and "Filthy Rich" edges to occur during the Setup phase.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Character_Sheet_Phase_5_(Savage)&diff=2980Character Sheet Phase 5 (Savage)2009-05-05T06:15:08Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
===Overview===<br />
<br />
We're making great progress and are almost finished with the character sheet. There are only a few more sections remaining, which we'll add in this phase of development.<br />
<br />
===Armor===<br />
<br />
The next section for us to deal with on the character sheet is armor. In Savage Worlds, armor is relatively simple, but there are still some important details we should include for each piece. Obviously, the armor rating is needed. For shields, we need to include the parry rating if it is non-zero. For armor, we need to include the areas covered by the armor.<br />
<br />
One option is to do this with columns of data, just like we did for arcane powers. However, shields and armor need to show different details, and the number of details is small, so we'll just list the details in text appended after the name. The Skeleton files provide handling for armor that uses this same technique, so we'll adapt the provided "oArmorPick" template for our needs.<br />
<br />
Before we do that, though, we need to consider how we're going to display the various areas covered by the armor. If we use the names "Head", "Torso", and such, we'll never be able to fit the details text without switching to an incredibly small font or running onto a second line. Since space is at a premium, we need something to fit on one line. The easiest solution is to only show the first letter of each area, so "Head" would be shown as "H", etc. This will be immediately obvious to someone reviewing the character sheet and be very compact.<br />
<br />
The question now becomes how best can be get the first letter of every area. Within the script, we'll be able to retrieve the names of each area, so we can then muck with the string we get back to strip out only the first characters. However, that will be a real pain to do. A much easier solution is to define an abbreviation for each of the tags for the different areas that is the first character. Once we do that, we can use the "tagabbrevs" target reference instead of "tagnames" and retrieve the abbreviations for display.<br />
<br />
To add the abbreviations, we need to modify the various armor location tags. Open the file "tags.1st" and locate the tag group "ArmorLoc". Then add appropriate abbreviations to each tag. The result should look like the following.<br />
<br />
<pre><br />
<group<br />
id="ArmorLoc"><br />
<value id="Torso" abbrev="T"/><br />
<value id="Head" abbrev="H"/><br />
<value id="Arms" abbrev="A"/><br />
<value id="Legs" abbrev="L"/><br />
</group><br />
</pre><br />
<br />
Now that the tags have been modified, we can shift our focus to the template showing each piece of defensive equipment. First of all, we don't need the "badstr" portal, so can rip that out. Next we can revise the "name" portal to synthesize the information we identified above for output. Since we're changing the font for the details text, sizing the "name" field to fit is inappropriate, so we must also eliminate that behavior. This yields the following revised template.<br />
<br />
<pre><br />
<template<br />
id="oArmorPick"<br />
name="Output Armor Table"<br />
compset="Equipment"<br />
marginvert="1"><br />
<br />
<portal<br />
id="equipped"<br />
style="outNameMed"><br />
<output_label><br />
<labeltext><![CDATA[<br />
@text = "{bmpscale 3 output_armor}"<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="name"<br />
style="outNameMed"><br />
<output_label><br />
<labeltext><![CDATA[<br />
~start with the name and switch to a smaller, non-bold font for details<br />
var temp as string<br />
@text = field[name].text<br />
@text &= "{size 36}{/b} ("<br />
<br />
~add the defense rating<br />
@text &= field[defDefense].text<br />
<br />
~if this is a shield, include the parry rating (if non-zero)<br />
if (tagis[component.Shield] <> 0) then<br />
if (field[defParry].value <> 0) then<br />
@text &= ", Parry: " & signed(field[defParry].value)<br />
endif<br />
endif<br />
<br />
~if this is armor, include the areas covered by the equipment<br />
if (tagis[component.Armor] <> 0) then<br />
temp = tagabbrevs[ArmorLoc.?,","]<br />
if (empty(temp) = 0) then<br />
@text &= ", Covers: " & temp<br />
endif<br />
endif<br />
<br />
~wrapup the details<br />
@text &= ")"<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<position><![CDATA[<br />
~our height is the height of the tallest portal<br />
height = maximum(portal[name].height,portal[equipped].height)<br />
if (issizing <> 0) then<br />
done<br />
endif<br />
<br />
~if the armor is not equipped, hide the bitmap<br />
if (tagis[Equipped.Equipped] = 0) then<br />
portal[equipped].visible = 0<br />
endif<br />
<br />
~center all portals vertically<br />
perform portal[equipped].centervert<br />
perform portal[name].centervert<br />
<br />
~shift the "equipped" bitmap downward a little bit; this is because it is a<br />
~lone bitmap drawn via encoded text, and bitmaps are never drawn within the<br />
~descender portion of the text, which causes it to appear higher than we want it<br />
portal[equipped].top += 4<br />
<br />
~align everything horizontally<br />
perform portal[name].alignrel[ltor,equipped,5]<br />
]]></position><br />
<br />
</template><br />
</pre><br />
<br />
===Weapons===<br />
<br />
Weapons are next on our list. We need to decide whether we want to use columns of data for weapons or stream the info as details like we just did for armor. There are four primary pieces of info for weapons, aside from the name. These are the attack roll, damage, range (if applicable), and armor piercing rating (if any). We should also include a notation if there are special rules for the weapon that need to be remembered by the player, as well as indicating if the minimum strength requirement for the weapon is not satisfied.<br />
<br />
We'll make use of columnar data, since that will probably look better. We'll note a failed strength requirement via a bitmap indicator the prefixes the name. We'll indicate is there are special rules with a bitmap after the name. Since we'll have limited space, we'll display the "shortname" field for each weapon. In terms of columns, we'll have one for the attack, another for damage, a third for armor piercing, and a fourth for range.<br />
<br />
We'll use the same implementation approach as we employed for arcane powers. We first create the table without the header, and then we add the header information.<br />
<br />
====Table Portals====<br />
<br />
For the table itself, we'll first figure out what indicators to use for insufficient strength and special notes. Within the interface, we use the universal "no" symbol and a star symbol, respectively. We should strive to be consistent, so we'll use the same symbols on the character sheet. The star symbol in the interface is a bitmap that is designed for the on-screen use, so it will look poor on the character sheet. If we bring up the "Character Map" tool and scan through the various symbol fonts we discussed earlier, we can quickly find a suitable character in the "Wingdings" font.<br />
<br />
Now that we've identified all the pieces we need, we can define the additional portals. We'll add a "special" portal to indicate special details for the weapon. We'll also add an "ap" portal to display the armor piercing rating for the weapon. For the "range" portal, we want to show something other than just blank when there is no range, so we'll revise the Label script accordingly. Lastly, we need to realize that the current portals mostly use the "outNameMed" style, which utilizes a rather large, bold font. This simply won't fit in the space we've got to work with, so we need to switch to an alternate style that will fit. We can create our own or use something that already exists. Probably the best choice is to try the "outPlain" style and see if that works, after which we can change it if there are problems. We'll use this style for all portals except for the name, which we'll leave using the "outNameMed" style.<br />
<br />
Based on the above considerations, we'll define the portals. This yields a collection of portals that looks like the set below.<br />
<br />
<pre><br />
<portal<br />
id="badstr"<br />
style="outPlain"><br />
<output_label><br />
<labeltext><![CDATA[<br />
@text = "{font Webdings}" & chr(120)<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="name"<br />
style="outNameMed"><br />
<output_label<br />
field="shortname"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="special"<br />
style="outPlain"><br />
<output_label><br />
<labeltext><![CDATA[<br />
@text = "{font Wingdings}" & chr(171)<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="attack"<br />
style="outPlain"><br />
<output_label<br />
field="wpNetAtk"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="damage"<br />
style="outPlain"><br />
<output_label<br />
field="wpDamage"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="ap"<br />
style="outPlain"><br />
<output_label><br />
<labeltext><![CDATA[<br />
if (field[wpPiercing].value <> 0) then<br />
@text = field[wpPiercing].text<br />
else<br />
@text = "-"<br />
endif<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="range"<br />
style="outPlain"><br />
<output_label><br />
<labeltext><![CDATA[<br />
if (tagis[component.WeapRange] <> 0) then<br />
@text = field[wpRange].text<br />
else<br />
@text = "-"<br />
endif<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="dots"<br />
style="outDots"><br />
<output_dots><br />
</output_dots><br />
</portal><br />
</pre><br />
<br />
====Positioning the Portals====<br />
<br />
Now that we have all the portals, we need to position them appropriately. We'll start by centering the name. We'll also center our indicator symbols vertically, since they will be flanking the name on either side. All other portals use a smaller font than the name, so we need to align them along the same baseline as the name. Since we're using columns, we need to specify appropriate widths for each of the four columns other than the name. The name will then inherit whatever space remains. If we don't pick the correct widths for the columns, we can easily refine the values with a little bit of experimentation.<br />
<br />
Once we have the space for the name identified, we can position the portals for each column. Now we are left with positioning the name appropriately. The two indicator bitmaps will be displayed as part of the name column. Consequently, we must determine which of the indicators is applicable and set our visibility accordingly. If the strength requirement is shown, then the name itself must be positioned to the right of the indicator.<br />
<br />
Since the indicators are part of the space for the name, we need to subtract them from the width allocated to the name portal. Once that's done, we can automatically shrink the name to fit within the available space if it's too large. When we do this, we have to remember that shrinking the name keeps its "top" position the same, which means that smaller text will creep upwards. We want it to retain the same baseline position, so we have to re-position the portal after the resize to ensure the baseline doesn't change.<br />
<br />
At this point, the name portal extends to the rightmost edge of the space we reserved for the name. However, we want the "special" portal to appear immediately adjacent to the name. We also want to include a sequence of dots between the name and the attack portal for better clarity. To accomplish this, we must now force the "name" portal to re-calculate its width based on the new font. Assuming the "sizetofit" operation above shrunk the name sufficiently, this will work perfectly. However, if the name is extremely long, we specified a minimum font size, so the operation may have stopped when the font size reached the minimum. If that's the case, re-calculating the size will end up making the portal wider, which will extend it into other columns. We can't allow that, so we must first get the current width, then re-calculate the width, and finally limit the new width to the original width.<br />
<br />
Everything has been figured out now. So we can position the "name" portal properly and then position the "special" portal to its right, if necessary. The final step is showing the "dots" portal between the right edge of the used name region and the left edge of the attack column.<br />
<br />
All of this logic can be seen in the Position script shown below.<br />
<br />
<pre><br />
~our height is based on the tallest portal within<br />
height = portal[name].height<br />
if (issizing <> 0) then<br />
done<br />
endif<br />
<br />
~center the name and indicators vertically<br />
perform portal[name].centervert<br />
perform portal[badstr].centervert<br />
perform portal[special].centervert<br />
<br />
~position the other portals with the same baseline as the name; since they<br />
~use a smaller font, they will have a smaller height, so centering them will<br />
~make them appear to float up relative to the name<br />
perform portal[attack].alignrel[btob,name,0]<br />
perform portal[damage].alignrel[btob,name,0]<br />
perform portal[ap].alignrel[btob,name,0]<br />
perform portal[range].alignrel[btob,name,0]<br />
perform portal[dots].alignrel[btob,name,0]<br />
<br />
~establish suitable fixed widths for the various columns of data<br />
portal[attack].width = 135<br />
portal[damage].width = 165<br />
portal[ap].width = 50<br />
portal[range].width = 225<br />
<br />
~assign the name the remaining horizontal space<br />
~Note: We must also account for a gap of 5 between portals.<br />
portal[name].width = width - 4 * 5<br />
portal[name].width -= portal[attack].width + portal[damage].width<br />
portal[name].width -= portal[ap].width + portal[range].width<br />
<br />
~position our columns now, except for the name<br />
portal[attack].left = portal[name].right + 5<br />
perform portal[damage].alignrel[ltor,attack,5]<br />
perform portal[ap].alignrel[ltor,damage,5]<br />
perform portal[range].alignrel[ltor,ap,5]<br />
<br />
~setup to track our position when positioning portals along the x-axis<br />
var x as number<br />
x = 0<br />
<br />
~if the weapon satisfies the minimum strength requirement, hide the bitmap,<br />
~else position it on the left<br />
if (tagis[Helper.BadStrReq] = 0) then<br />
portal[badstr].visible = 0<br />
else<br />
portal[badstr].left = 0<br />
x = portal[badstr].right<br />
endif<br />
<br />
~if there are no special details for the weapon, hide the bitmap<br />
if (field[wpNotes].isempty = 1) then<br />
portal[special].visible = 0<br />
endif<br />
<br />
~shrink the space for the name based on the presence of the two bitmaps<br />
portal[name].width -= portal[badstr].width * portal[badstr].visible<br />
portal[name].width -= portal[special].width * portal[special].visible<br />
<br />
~size the name to fit the available space, then reposition it at the baseline<br />
~Note: This is needed since smaller text will have the same top position.<br />
perform portal[name].sizetofit[36]<br />
perform portal[name].autoheight<br />
perform portal[name].alignrel[btob,attack,0]<br />
<br />
~recalculate the width of the name based on the sized font<br />
~Note: This is needed so we can determine the span for the row of dots.<br />
~Note: We must also cap the name portal to its previous width, just in case<br />
~ the "sizetofit" didn't shrink the name far enough to fully fit.<br />
var limit as number<br />
limit = portal[name].width<br />
perform portal[name].autowidth<br />
if (portal[name].width > limit) then<br />
portal[name].width = limit<br />
endif<br />
<br />
~position the name and special details indicator portals horizontally now<br />
portal[name].left = x<br />
x = portal[name].right<br />
if (portal[special].visible <> 0) then<br />
portal[special].left = x<br />
x = portal[special].right<br />
endif<br />
<br />
~extend the dots from the right of the name across to the attack portal<br />
if (x > portal[attack].left - 10) then<br />
portal[dots].visible = 0<br />
else<br />
portal[dots].left = x + 5<br />
portal[dots].width = portal[attack].left - 5 - portal[dots].left<br />
endif<br />
</pre><br />
<br />
====Adding the Header====<br />
<br />
Our table is looking good, so we can now deal get the header working correctly. We already have three header portals that we'll want to retain. These portals are being positioned relative to the portals in the main table, so they are working perfectly. All we need to do is add another header portal for the armor piercing rating. This can be added and then positioned just like the other header portals in the Header script.<br />
<br />
Looking at it all, though, the header labels appear to be a little bit larger than would be optimal. Since we're using a smaller font than the provided Skeleton files, we need to ensure that the header is shrunk a bit, too. We can accomplish this by either switching to a new style or simply changing the font size used for font in the existing style. We'll do the latter and shrink the font a full point (from 36 to 32). Once we shrink the font size, we can also change the column headers to show the proper name instead of an abbreviation.<br />
<br />
Putting it all together, this yields the following portals and Header script for the template.<br />
<br />
<pre><br />
<portal<br />
id="hdrtitle"<br />
style="outTitle"<br />
isheader="yes"><br />
<output_label<br />
text="Weapons"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="hdrattack"<br />
style="outHeader"<br />
isheader="yes"><br />
<output_label<br />
text="Attack"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="hdrdamage"<br />
style="outHeader"<br />
isheader="yes"><br />
<output_label<br />
text="Damage"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="hdrap"<br />
style="outHeader"<br />
isheader="yes"><br />
<output_label<br />
text="AP"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="hdrrange"<br />
style="outHeader"<br />
isheader="yes"><br />
<output_label<br />
text="Range"><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
<pre><br />
<header><![CDATA[<br />
~our header height is the title plus a gap plus the header text<br />
height = portal[hdrtitle].height + 2 + portal[hdrattack].height<br />
if (issizing <> 0) then<br />
done<br />
endif<br />
<br />
~our title spans the entire width of the template<br />
portal[hdrtitle].width = width<br />
<br />
~each of our header labels has the same width as the corresponding data beneath<br />
portal[hdrattack].width = portal[attack].width<br />
portal[hdrdamage].width = portal[damage].width<br />
portal[hdrap].width = portal[ap].width<br />
portal[hdrrange].width = portal[range].width<br />
<br />
~center each header label on the corresponding data beneath<br />
perform portal[hdrattack].centeron[horz,attack]<br />
perform portal[hdrdamage].centeron[horz,damage]<br />
perform portal[hdrap].centeron[horz,ap]<br />
perform portal[hdrrange].centeron[horz,range]<br />
<br />
~align all header labels at the bottom of the header region<br />
perform portal[hdrattack].alignedge[bottom,0]<br />
perform portal[hdrdamage].alignedge[bottom,0]<br />
perform portal[hdrap].alignedge[bottom,0]<br />
perform portal[hdrrange].alignedge[bottom,0]<br />
]]></header><br />
</pre><br />
<br />
===Gear===<br />
<br />
The final piece of the character sheet is handling the gear. The Skeleton files provide us with a gear table that lists all the gear in a single column. Since a single column is used, the font is large and bold, plus there is plenty of unused space. We need something compact, using a smaller, non-bold font, and employing at least two columns. In fact, if we can switch to a significantly smaller font, we can probably even squeeze three columns in, which would be ideal. So we'll start by modifying the table portal to use three columns.<br />
<br />
Looking at the existing template, we don't want to keep the quantity in a separate column from the actual gear name. So we'll eliminate the separate "value" portal, but we'll move the logic for generating the quantity into the "name" portal. The template uses a large horizontal margin, which we need to shrink to something that will be just enough to separate our three columns. A value of 5 ought to be about right.<br />
<br />
We need to use a small font to squeeze the gear into three columns, so we'll simply define a style specifically for use with gear. In the file "styles_output.aug", we'll create the "outGear" style and a corresponding font for use with the style. We'll use a small point size for the font and not use bold. This results in the new definition shown below.<br />
<br />
<pre><br />
<style<br />
id="outGear"><br />
<style_output<br />
textcolor="000000"<br />
font="ofntgear"<br />
alignment="left"><br />
</style_output><br />
<resource<br />
id="ofntgear"><br />
<font<br />
face="Arial"<br />
size="36"><br />
</font><br />
</resource><br />
</style><br />
</pre><br />
<br />
We can now implement the portal appropriately. We'll use the new style and prepend the quantity onto the name, which yields the following portal.<br />
<br />
<pre><br />
<portal<br />
id="name"<br />
style="outGear"><br />
<output_label><br />
<labeltext><![CDATA[<br />
if (stackable = 0) then<br />
@text = ""<br />
elseif (field[stackQty].value = 1) then<br />
@text = ""<br />
else<br />
@text = field[stackQty].text & "x "<br />
endif<br />
@text &= field[name].text<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
With the portal in place, we need to position it. The name portal is sized based on the text within it, so our first action is the limit the width of the portal to the width of the template. Once we do that, we can try shrinking the font size to better fit longer names into the available space. Some names may still be too long, so we now limit the height to a single line. Lastly, we align the portal at the bottom of the template, which ensures that all gear entries across a row share the same baseline. This yields the following Position script.<br />
<br />
<pre><br />
~our height is the height of the tallest portal<br />
height = portal[name].height<br />
if (issizing <> 0) then<br />
done<br />
endif<br />
<br />
~limit the width of the name to the width of the template<br />
if (portal[name].width > width) then<br />
portal[name].width = width<br />
endif<br />
<br />
~size the name to fit the available space, if needed<br />
perform portal[name].sizetofit[30]<br />
<br />
~limit the name to a single line based on the updated font size<br />
portal[name].lineheight = 1<br />
<br />
~align the name at the bottom of the template<br />
perform portal[name].alignedge[bottom,0]<br />
</pre><br />
<br />
This looks pretty good, except that there is a variety of gear that has names longer than will fit in the space we've got. The solution is to do for all gear what we've already done for weapons. We can designate the "Gear" component as supporting short names, allowing a shorter name to be defined for every piece of equipment. Then we can change the Label script for the "name" portal to reference the "shortname" field instead of the "name" field. Now we should be in great shape for handling gear in a very compact fashion.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Character_Sheet_Phase_4_(Savage)&diff=2979Character Sheet Phase 4 (Savage)2009-05-05T06:13:54Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
===Overview===<br />
<br />
In the previous stage of creating the character sheet, we got started on the right side and solved the most complex piece of the output in arcane powers. The remainder of the right side of the sheet introduce a few more wrinkles, but everything should proceed smoothly from this point forward.<br />
<br />
===Breaking the Right Side into Sections===<br />
<br />
The biggest remaining issue with the right side of the sheet is managing our vertical space appropriately. If a character has arcane powers, a bunch of weapons, and lots of gear, there might not be enough space on the right side in which to fit it all. It's perfectly reasonable for that to happen, and we can safely spill the remaining items onto a second page. However, we should give thought to which information is given priority for being shown on the first page and what we're happy to let fall to the second page.<br />
<br />
It's very important that we show the region for tracking health on the first page, since that will come into play regularly for many games. Since we're pairing the health and injuries up side-by-side, we need to ensure those get included on the first page. We should also be sure to include a reminder of any actively enabled adjustments on the first page. Weapons and armor are a secondary priority, with gear being the lowest priority for the first page.<br />
<br />
In order to ensure that we honor these priorities, we need to carve the right side of the page up into pieces that can be placed in an appropriate sequence. So we need create a new layout that encompasses the material we'll place in the lower right corner, then we need to position it after the powers are handled. Within the remaining space, we can position a separate layout that includes weapons and armor. If we still have space left, then we can squeeze our gear into that region via a third layout.<br />
<br />
So our next order of business is to setup these three layouts. We already have a layout for the weapons and armor that we can use. This layout is designed to split its space between the weapons and armor tables, so we don't have to do anything special to get weapons and armor to work smoothly.<br />
<br />
For the gear, we have the table portal and simply need a layout to contain it. That layout can be defined easily as shown below, and we must remove the portal reference from the "oRightSide" layout.<br />
<br />
<pre><br />
<layout<br />
id="oGear"><br />
<portalref portal="oGear"/><br />
<position><![CDATA[<br />
~position the various tables appropriately<br />
perform portal[oGear].autoplace<br />
<br />
~our layout height is the extent of the elements within<br />
height = autotop<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
The Skeleton files provide us with a table of adjustments and a layout that contains them. For simplicity, we'll just use this layout as our third layout. When we need to add injuries and such, we'll integrate them into this layout. So we don't need to do anything further with this layout.<br />
<br />
The final thing we need to do is properly revise the sheet to incorporate these three layouts. We also need to handle these layouts within the Position script for the sheet. This entails positioning the current "oRightSide" layout, then placing the "oAdjust" layout anchored to the bottom of the sheet. Once that's done, we can position the "oArmory" layout beneath the "oRightSide" layout, using up whatever space is available. We'll place the "oGear" layout last, using the final remnants of space on the character sheet. The updated contents of the "standard1" sheet should look like the one shown below.<br />
<br />
<pre><br />
<sheet<br />
id="standard1"<br />
name="Standard character sheet, page #1"><br />
<layoutref layout="oLogos"/><br />
<layoutref layout="oLeftSide"/><br />
<layoutref layout="oRightSide"/><br />
<layoutref layout="oAdjust"/><br />
<layoutref layout="oArmory"/><br />
<layoutref layout="oGear"/><br />
<layoutref layout="oValidate"/><br />
<position><![CDATA[<br />
~set this scene variable to 1 if you want the logos to be stacked; a value<br />
~of zero places them side-by-side<br />
scenevalue[stacklogos] = 0<br />
<br />
~setup the gap to be used between the various sections of the character sheet<br />
autogap = 40<br />
scenevalue[sectiongap] = autogap<br />
<br />
~calculate the width of the two columns of the character sheet, leaving a<br />
~suitable center gap between them<br />
var colwidth as number<br />
colwidth = (width - 50) / 2<br />
<br />
~if the user wants to omit the validation report, the hide it and allow the<br />
~rest of the sheet to fill that space; otherwise, output the layout and the<br />
~top of the validation report establishes the bottom for all other output<br />
var extent as number<br />
if (hero.tagis[source.Validation] = 0) then<br />
layout[oValidate].visible = 0<br />
extent = height<br />
else<br />
layout[oValidate].width = width<br />
perform layout[oValidate].render<br />
layout[oValidate].top = height - layout[oValidate].height<br />
extent = layout[oValidate].top - scenevalue[sectiongap]<br />
endif<br />
<br />
~position the leftside layout in the upper left corner<br />
layout[oLeftSide].width = colwidth<br />
layout[oLeftSide].height = extent - layout[oLeftSide].top<br />
perform layout[oLeftSide].render<br />
<br />
~position the logos layout in the upper right corner<br />
layout[oLogos].width = colwidth<br />
perform layout[oLogos].render<br />
layout[oLogos].left = width - colwidth<br />
<br />
~position the activated adjustments at the bottom on the right; this will<br />
~establish the remaining space available on the right for other layouts<br />
layout[oAdjust].width = colwidth<br />
layout[oAdjust].left = layout[oLogos].left<br />
perform layout[oAdjust].render<br />
layout[oAdjust].top = extent - layout[oAdjust].height<br />
<br />
~position the rightside layout in the remaining space on the right<br />
layout[oRightSide].width = colwidth<br />
layout[oRightSide].top = layout[oLogos].bottom + scenevalue[sectiongap]<br />
layout[oRightSide].left = layout[oLogos].left<br />
layout[oRightSide].height = layout[oAdjust].top - scenevalue[sectiongap] - layout[oRightSide].top<br />
perform layout[oRightSide].render<br />
<br />
~position the armory layout within the remaining space on the right<br />
layout[oArmory].width = colwidth<br />
layout[oArmory].top = layout[oRightSide].bottom + scenevalue[sectiongap]<br />
layout[oArmory].left = layout[oLogos].left<br />
<br />
~if the top of the armory layout is below the adjustments layout, there is no<br />
~room for it, so hide it; otherwise, set height and render the layout properly<br />
if (layout[oArmory].top >= layout[oAdjust].top) then<br />
layout[oArmory].visible = 0<br />
else<br />
layout[oArmory].height = layout[oAdjust].top - scenevalue[sectiongap] - layout[oArmory].top<br />
perform layout[oArmory].render<br />
endif<br />
<br />
~position the gear layout in whatever space is left on the right<br />
layout[oGear].width = colwidth<br />
layout[oGear].top = layout[oArmory].bottom + scenevalue[sectiongap]<br />
layout[oGear].left = layout[oLogos].left<br />
<br />
~if the top of the gear layout is below the adjustments layout, there is no<br />
~room for it, so hide it; otherwise, set height and render the layout properly<br />
if (layout[oGear].top >= layout[oAdjust].top) then<br />
layout[oGear].visible = 0<br />
else<br />
layout[oGear].height = layout[oAdjust].top - scenevalue[sectiongap] - layout[oGear].top<br />
perform layout[oGear].render<br />
endif<br />
]]></position><br />
</sheet><br />
</pre><br />
<br />
===Adjustments===<br />
<br />
Since the adjustments layout is always going to be given priority in the lower right corner, we should make sure it's all working now. The only time the adjustments table appears is when one or more in-play or permanent adjustments are enabled for the character when the sheet is printed. For testing, we can add a few of each and preview the character sheet. They appear nicely in the lower right corner, so there's nothing further we need to do to handle them now.<br />
<br />
===Injuries and Health===<br />
<br />
The plan is to always show any injuries in the lower right corner, along with a place to track health and power points. The injuries can be managed as a simple table portal, while the condition tracking requires that we implement something that is a little more complex. We could keep things easy by just inserting a graphic, or we could actually construct something that will work. We'll try the latter, without going overboard.<br />
<br />
====Injuries Table====<br />
<br />
Before we do that, though, we'll first get the injuries table into place. The table simply lists all injuries, and we'll need to provide a template that displays each individual injury appropriately. For the template, we just need something simple that will show the name of the injury. We can clone and adapt the template used for adjustments. This results in the table portal and template shown below.<br />
<br />
<pre><br />
<portal<br />
id="oInjury"<br />
style="outNormal"><br />
<output_table<br />
component="Injury"<br />
showtemplate="oInjury"><br />
<headertitle><![CDATA[<br />
@text = "Injuries"<br />
]]></headertitle><br />
</output_table><br />
</portal><br />
<br />
<template<br />
id="oInjury"<br />
name="Output Injuries Table"<br />
compset="Injury"<br />
marginhorz="10"><br />
<br />
<portal<br />
id="name"<br />
style="outNormLt"><br />
<output_label<br />
field="name"><br />
</output_label><br />
</portal><br />
<br />
<position><![CDATA[<br />
~our height is the vertical extent of our portals<br />
height = portal[name].height<br />
if (issizing <> 0) then<br />
done<br />
endif<br />
<br />
~size the name to fit the available space<br />
portal[name].width = width<br />
perform portal[name].sizetofit[36]<br />
perform portal[name].autoheight<br />
perform portal[name].centervert<br />
]]></position><br />
<br />
</template><br />
</pre><br />
<br />
Once the table is in place, we need to add it to the layout. We'll make it 40% of the total width of the layout, leaving the rest for condition tracking. Unlike our usual approach, we cannot use "autoplace" for this table. If the table is empty, automatic placement will hide the table, which will leave an empty gap in the character sheet that will look odd. So we need to position and size the table ourselves. Since the table will use no more space than it requires, we can set the height to something very large and HL will truncate it to the appropriate height. This results in the revised layout below.<br />
<br />
<pre><br />
<layout<br />
id="oAdjust"><br />
<portalref portal="oAdjust"/><br />
<portalref portal="oInjury"/><br />
<position><![CDATA[<br />
~position the adjustments table at the top<br />
perform portal[oAdjust].autoplace<br />
<br />
~position the injuries table in the left 40% beneath the adjustments<br />
~Note: We don't use autoplace, since we never want the table hidden<br />
portal[oInjury].left = 0<br />
portal[oInjury].top = autotop + scenevalue[sectiongap]<br />
portal[oInjury].width = width * .4<br />
portal[oInjury].height = 5000<br />
<br />
~our layout height is the bottom extent of the elements within<br />
height = portal[oInjury].bottom<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
If our character has no injuries, though, this looks strange. All we see is the header above the table and nothing within it. What we need is a portal that simply says "None" that we can show just below the header if the table is empty. So we'll define a new label portal and show it appropriately via the layout. The new portal and updated layout are shown below.<br />
<br />
<pre><br />
<portal<br />
id="oNoInjury"<br />
style="outNormal"><br />
<output_label<br />
text="-None-"><br />
</output_label><br />
</portal><br />
<br />
<layout<br />
id="oAdjust"><br />
<portalref portal="oAdjust"/><br />
<portalref portal="oInjury"/><br />
<portalref portal="oNoInjury"/><br />
<position><![CDATA[<br />
~position the adjustments table at the top<br />
perform portal[oAdjust].autoplace<br />
<br />
~position the injuries table in the left 40% beneath the adjustments<br />
~Note: We don't use autoplace, since we never want the table hidden<br />
portal[oInjury].left = 0<br />
portal[oInjury].top = autotop + scenevalue[sectiongap]<br />
portal[oInjury].width = width * .4<br />
portal[oInjury].height = 5000<br />
<br />
~if there are no injuries, indicate that fact<br />
if (portal[oInjury].itemsshown <> 0) then<br />
portal[oNoInjury].visible = 0<br />
else<br />
perform portal[oNoInjury].centeron[horz,oInjury]<br />
perform portal[oNoInjury].alignrel[ttob,oInjury,10]<br />
endif<br />
<br />
~our layout height is the bottom extent of the elements within<br />
height = maximum(portal[oInjury].bottom,portal[oNoInjury].bottom)<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
====Health in Template====<br />
<br />
For tracking health, the standard representation in Savage Worlds is a Wounds progression from one end and a Fatigue progression from the other end. This can probably be best implemented via a handful of portals. Since the contents of those portals have no relationship to any aspects of the character, no template is truly necessary. However, it's probably easiest to manage this via a template, so that's the approach we'll use.<br />
<br />
We need a total of eight portals within our template. We need one to indicate "Wounds" on the left and another to indicate "Fatigue" on the right. We then need the "Incapacitated" indicator as a third portal, along with three progressive increments for wounds and two for fatigue. We'll place the two labels in the upper left and upper right corners of the span within which the condition tracking is shown. The six health levels will then be arrayed across the full width of the span. This results in a template that should look like the following.<br />
<br />
<pre><br />
<template<br />
id="oCondition"<br />
name="Output Condition"<br />
compset="Actor"><br />
<br />
<portal<br />
id="wounds"<br />
style="outNameLg"><br />
<output_label<br />
text="Wounds"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="fatigue"<br />
style="outNameLg"><br />
<output_label<br />
text="Fatigue"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="wound1"<br />
style="outNameLg"><br />
<output_label<br />
text="-1"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="wound2"<br />
style="outNameLg"><br />
<output_label<br />
text="-2"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="wound3"<br />
style="outNameLg"><br />
<output_label<br />
text="-3"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="fatigue1"<br />
style="outNameLg"><br />
<output_label<br />
text="-1"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="fatigue2"<br />
style="outNameLg"><br />
<output_label<br />
text="-2"><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="incapac"<br />
style="outNameLg"><br />
<output_label<br />
text="INC"><br />
</output_label><br />
</portal><br />
<br />
<position><![CDATA[<br />
~position the labels at the top<br />
portal[wounds].top = 0<br />
portal[fatigue].top = 0<br />
<br />
~position all health levels beneath the labels with a common baseline<br />
perform portal[wound1].alignrel[ttob,wounds,10]<br />
perform portal[wound2].alignrel[btob,wound1,0]<br />
perform portal[wound3].alignrel[btob,wound1,0]<br />
perform portal[fatigue1].alignrel[btob,wound1,0]<br />
perform portal[fatigue2].alignrel[btob,wound1,0]<br />
perform portal[incapac].alignrel[btob,wound1,0]<br />
<br />
~position the labels at the left and right edges<br />
portal[wounds].left = 0<br />
perform portal[fatigue].alignedge[right,0]<br />
<br />
~put the -1 levels at each end<br />
portal[wound1].left = 0<br />
perform portal[fatigue1].alignedge[right,0]<br />
<br />
~determine the remaining span over which the portals extend<br />
var span as number<br />
span = portal[fatigue1].left - portal[wound1].right<br />
<br />
~tally the total width of the remaining health level portals<br />
var used as number<br />
used = portal[wound2].width + portal[wound3].width<br />
used += portal[fatigue2].width + portal[incapac].width<br />
<br />
~divvy up the remaining horizontal space into equal pieces and use as spacing<br />
~for positioning the various health level horizontally<br />
var each as number<br />
each = span - used<br />
each = round(each / 5,0,0)<br />
perform portal[wound2].alignrel[ltor,wound1,each]<br />
perform portal[wound3].alignrel[ltor,wound2,each]<br />
perform portal[fatigue2].alignrel[rtol,fatigue1,-each]<br />
<br />
~size and center the incapacitated cell in the remaining space<br />
each = (portal[fatigue2].left - portal[wound3].right - portal[incapac].width) / 2<br />
perform portal[incapac].alignrel[ltor,wound3,each]<br />
<br />
~our height is the bottom extent of the portals<br />
height = portal[wound1].bottom<br />
]]></position><br />
<br />
</template><br />
</pre><br />
<br />
====Integration Into Layout====<br />
<br />
Now that we've got our template created, we need to integrate it into the layout. We first add a "templateref" element. Since the template doesn't actually reference any live data within the portfolio, we can hook the template up to any pick or thing we choose. In general, the best tactic in situations like this is to utilize the "actor" pick, so that's what we'll do.<br />
<br />
Once the template is part of the layout, we then need to position it properly. It gets placed to the right of the injuries table, leaving a little bit of a gap. The top of the template should be the same as the top of the injury table. The template will calculate its own height when it is rendered. Once rendered, it's conceivable (albeit unlikely) that the template will be taller than the table, so we need to set our height to the tallest of the two visual elements. This results in the updated layout shown below.<br />
<br />
<pre><br />
<layout<br />
id="oAdjust"><br />
<portalref portal="oAdjust"/><br />
<portalref portal="oInjury"/><br />
<portalref portal="oNoInjury"/><br />
<templateref template="oCondition" thing="actor" ispick="yes"/><br />
<position><![CDATA[<br />
~position the adjustments table at the top<br />
perform portal[oAdjust].autoplace<br />
<br />
~position the injuries table in the left 40% beneath the adjustments<br />
~Note: We don't use autoplace, since we never want the table hidden<br />
portal[oInjury].left = 0<br />
portal[oInjury].top = autotop + scenevalue[sectiongap]<br />
portal[oInjury].width = width * .4<br />
portal[oInjury].height = 5000<br />
<br />
~if there are no injuries, indicate that fact<br />
if (portal[oInjury].itemsshown <> 0) then<br />
portal[oNoInjury].visible = 0<br />
else<br />
perform portal[oNoInjury].centeron[horz,oInjury]<br />
perform portal[oNoInjury].alignrel[ttob,oInjury,10]<br />
endif<br />
<br />
~position the condition template to the right of the injuries<br />
template[oCondition].left = portal[oInjury].right + 50<br />
template[oCondition].top = portal[oInjury].top<br />
template[oCondition].width = width - template[oCondition].left<br />
perform template[oCondition].render<br />
<br />
~our layout height is the bottom extent of the elements within<br />
height = maximum(portal[oInjury].bottom,template[oCondition].bottom)<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
====Refining the Health Display====<br />
<br />
After previewing our updated character sheet, the health region looks passable, but it would really benefit by having a soft grey border around the region to set it off nicely. Unlike portals, we cannot simply put a border around a template. So we'll need to add the border via a portal within the template. This entails adding a new portal whose sole purpose is to provide the border. We then setup a margin around the edges by positioning the portals with a gap all the way around. Once that's done, we can size the border portal to encompass the full region of the other portals, resulting in a border being drawn around a collection of portals. The new portal and the revised Position script are shown below.<br />
<br />
<pre><br />
<portal<br />
id="border1"<br />
style="outGreyBox"><br />
<output_label<br />
text=" "><br />
</output_label><br />
</portal><br />
<br />
<position><![CDATA[<br />
~leave a margin around all edges to draw our border<br />
var margin as number<br />
margin = 10<br />
<br />
~position the labels at the top<br />
portal[wounds].top = margin<br />
portal[fatigue].top = margin<br />
<br />
~position all health levels beneath the labels with a common baseline<br />
perform portal[wound1].alignrel[ttob,wounds,10]<br />
perform portal[wound2].alignrel[btob,wound1,0]<br />
perform portal[wound3].alignrel[btob,wound1,0]<br />
perform portal[fatigue1].alignrel[btob,wound1,0]<br />
perform portal[fatigue2].alignrel[btob,wound1,0]<br />
perform portal[incapac].alignrel[btob,wound1,0]<br />
<br />
~position the labels at the left and right edges<br />
portal[wounds].left = margin<br />
perform portal[fatigue].alignedge[right,-margin]<br />
<br />
~put the -1 levels at each end<br />
portal[wound1].left = margin<br />
perform portal[fatigue1].alignedge[right,-margin]<br />
<br />
~determine the remaining span over which the portals extend<br />
var span as number<br />
span = portal[fatigue1].left - portal[wound1].right<br />
<br />
~tally the total width of the remaining health level portals<br />
var used as number<br />
used = portal[wound2].width + portal[wound3].width<br />
used += portal[fatigue2].width + portal[incapac].width<br />
<br />
~divvy up the remaining horizontal space into equal pieces and use as spacing<br />
~for positioning the various health level horizontally<br />
var each as number<br />
each = span - used<br />
each = round(each / 5,0,0)<br />
perform portal[wound2].alignrel[ltor,wound1,each]<br />
perform portal[wound3].alignrel[ltor,wound2,each]<br />
perform portal[fatigue2].alignrel[rtol,fatigue1,-each]<br />
<br />
~size and center the incapacitated cell in the remaining space<br />
each = (portal[fatigue2].left - portal[wound3].right - portal[incapac].width) / 2<br />
perform portal[incapac].alignrel[ltor,wound3,each]<br />
<br />
~set the first border to span the full dimensions of the health tracker<br />
portal[border1].width = width<br />
portal[border1].height = portal[wound1].bottom + margin<br />
<br />
~our height is the bottom extent of the border<br />
height = portal[border1].bottom<br />
]]></position><br />
</pre><br />
<br />
====Power Points Tracking====<br />
<br />
The final thing we need to add to the condition tracking section is a place to mark off power points that are spent. All the various character sheets tend to show 30 boxes, so we'll do the same. We'll place a sequence of boxes beneath the health tracking region and allow the user to check boxes as points are spent. Given our limited space, we won't be able to fit 30 boxes, so we'll instead output two rows of 15 boxes each. To make tracking easier for the user, we'll ensure that every fifth box is larger and stands out from the others.<br />
<br />
Synthesizing output like we need is most easily handled via a script. By using some nested "for/next" loops, we can construct the text for output. However, we need to figure out how we're going to output boxes without having to use bitmaps. The answer is the "Wingdings" font that is built into Windows. We can utilize the "Character Map" tool provided by Windows to view the various characters supported by each font. Only a small number of fonts are built into every installation of Windows, and these include the "Webdings" font and the "Wingdings" font. Scanning through the character map for "Wingdings", we spot a suitable box character that we can use (character code "A8" in hex).<br />
<br />
Let's think through our logic now. We start by switching to the "Wingdings" font via the "{font Wingdings}" encoded text sequence. Between each character, we'll need to insert a tiny extra bit of spacing, which can be accomplished via the "{horz 1}" specification. For every fifth character, we need to increase the font size and then shrink it back down, which entails using "{size 52}". After every 15 characters, a line break needs to be inserted.<br />
<br />
Since the border looks good around the health tracking, we'll use a separate border around the power points tracking region. So we'll need two new portals, with one being generating the text for output and the other providing a border. This yields the two new portals below and the additional code for the Position script given below.<br />
<br />
<pre><br />
<portal<br />
id="power"<br />
style="outPlain"><br />
<output_label><br />
<labeltext><![CDATA[<br />
var i as number<br />
var j as number<br />
var k as number<br />
@text = "{font Wingdings}"<br />
for i = 1 to 2<br />
for j = 1 to 3<br />
for k = 1 to 4<br />
@text &= chr(168) & "{horz 1}"<br />
next<br />
@text &= "{size 52}" & chr(168) & "{size 40}"<br />
next<br />
@text &= "{br}"<br />
next<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="border2"<br />
style="outGreyBox"><br />
<output_label<br />
text=" "><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
<pre><br />
~position and size the power level condition<br />
perform portal[power].alignrel[ttob,border1,10 + margin]<br />
portal[power].left = margin<br />
portal[power].width = width - margin<br />
<br />
~set the first border to span the full dimensions of the power tracker<br />
portal[border2].top = portal[power].top - margin<br />
portal[border2].width = width<br />
portal[border2].height = portal[power].height + margin * 2<br />
<br />
~our height is the bottom extent of the second border<br />
height = portal[border2].bottom<br />
</pre><br />
<br />
This doesn't provide anything impressive, but it offers a clean and effective solution in a very compact space. This will do quite nicely.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Character_Sheet_Additions_(Savage)&diff=2978Character Sheet Additions (Savage)2009-05-05T06:11:48Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
===Overview===<br />
<br />
Now that we've got allies working, we need to add them to the character sheet output. We should also provide details on vehicles within the character sheet. This wiki entry outlines how to accomplish this.<br />
<br />
===Printing Allies===<br />
<br />
Each ally can be printed out on a separate character sheet, just like a normal character. However, it would be much more convenient to print a compact representation of each ally along with the main character for which they are minions. We don't have room for allies on the first page of the character sheet, but we should be able to add them without any problem on the second page.<br />
<br />
We'll add allies after everything else is output for the character. We can define a new table of allies and integrate it easily into the layout for the second sheet. In addition to printing all the basic details for each ally, we also need to include a separate space to track damage, power points, and ammo for each ally.<br />
<br />
====The Table Portal====<br />
<br />
Our table portal is a little bit different from the ones we normally define. We need our table to list all minions of the character. This can be done by operating on all picks in the "Ally" component, just like we did in the table on the tab. However, there is a better solution. We can instead specify that we want to list all minions via the "showpicks" attribute. This establishes the "actor" pick for the actual minion as the context for each item in the table, and that means that we can use the "hero" context readily within Label scripts in the template's portals. <br />
<br />
For the sort set, we'll use the pre-defined "_ActorSeq_" sequence, which outputs the minions in an appropriate order for the character. Since our minions will not all be the same height, we need to specify that our height varies. Lastly, we don't want a header above the table. Instead, we'll draw our own header above each item in the table so that each minion looks like its own entry to the user. Consequently, we want to insert a gap between each item in the table, so we specify the "showgapy" attribute.<br />
<br />
The net result of all of this is a table portal that looks like the following.<br />
<br />
<pre><br />
<portal<br />
id="oAlly"<br />
style="outNormal"><br />
<output_table<br />
component="Ally"<br />
showtemplate="oAllyPick"<br />
showpicks="minion"<br />
showsortset="_ActorSeq_"<br />
varyheight="yes"<br />
showgapy="25"><br />
</output_table><br />
</portal><br />
</pre><br />
<br />
====Layout Integration====<br />
<br />
Integrating our new portal into the layout is trivial. We simply add a new "portalref" for the portal and then add a suitable "autoplace" of the portal within the Position script. The revised layout looks like the following.<br />
<br />
<pre><br />
<layout<br />
id="oStandard2"><br />
<portalref portal="oPower"/><br />
<portalref portal="oArmor"/><br />
<portalref portal="oWeapon"/><br />
<portalref portal="oGear"/><br />
<portalref portal="oAlly"/><br />
<position><![CDATA[<br />
~position the various tables in the desired sequence<br />
perform portal[oPower].autoplace<br />
perform portal[oArmor].autoplace<br />
perform portal[oWeapon].autoplace<br />
perform portal[oGear].autoplace<br />
perform portal[oAlly].autoplace<br />
<br />
~the height of the layout is the bottommost extent of the elements within<br />
height = autotop<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
====The Ally Template====<br />
<br />
The template itself will consist of four pieces that will each be handled by a separate portal. At the top of each ally, we'll display a title that looks like a standard title above a table. Beneath the title, we'll output all of the details for the character, including traits, abilities, and gear. At the bottom, we'll present a convenient place for tracking health and other status for the character. Between the details and tracking sections, we'll insert a solid line as a separator.<br />
<br />
The overall template will look like the one shown below. This template omits the contents of the Label scripts that will be employed for three of the portals. Those contents will be discussed in the following sections.<br />
<br />
<pre><br />
<template<br />
id="oAllyPick"<br />
name="Output Allies Table"<br />
compset="Actor"><br />
<br />
<portal<br />
id="name"<br />
style="outTitle"><br />
<output_label><br />
<labeltext><![CDATA[<br />
~insert script here<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="details"<br />
style="outAlly"><br />
<output_label><br />
<labeltext><![CDATA[<br />
~insert script here<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<portal<br />
id="line"<br />
style="oSeparator"><br />
<output_separator<br />
isvertical="no"/><br />
</portal><br />
<br />
<portal<br />
id="tracking"<br />
style="outAlly"><br />
<output_label><br />
<labeltext><![CDATA[<br />
~insert script here<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
<br />
<position><![CDATA[<br />
~our name spans the entire width and is limited to a single line in height<br />
portal[name].width = width<br />
portal[name].lineheight = 1<br />
<br />
~position the details beneath the name, spanning the full width<br />
perform portal[details].alignrel[ttob,name,10]<br />
portal[details].width = width<br />
perform portal[details].autoheight<br />
<br />
~position the line beneath the details, spanning the full width; we set the<br />
~height to double the border size so that no contents are visible and we<br />
~end up with simply a solid horizontal line<br />
perform portal[line].alignrel[ttob,details,8]<br />
portal[line].width = width<br />
portal[line].height = portal[line].bordersize * 2<br />
<br />
~position the tracking beneath the line, spanning the full width<br />
perform portal[tracking].alignrel[ttob,line,5]<br />
portal[tracking].width = width<br />
perform portal[tracking].autoheight<br />
<br />
~our final height is the bottom of the template contents<br />
height = portal[tracking].bottom<br />
]]></position><br />
</template><br />
</pre><br />
<br />
====Showing the Title====<br />
<br />
The "title" portal must show a suitable name for ally. Each minion has a name, and that name is initialized to the name of the anchor pick for the minion. Consequently, if the user has not changed the actor's name, the two will match. If the name has been changed, we want to designate the nature of the minion in parentheses after that name. If the name has not been changed, we need to omit the nature, else we'll end up duplicating the default name twice (e.g. "Ally (Ally)").<br />
<br />
We'll start with the name of the actor. If the name differs from the default name (accessed via the "miniontext" target reference), then we'll append the nature. This results in the Label script shown below.<br />
<br />
<pre><br />
@text = hero.actorname<br />
if (empty(hero.miniontext) = 0) then<br />
if (compare(hero.miniontext,@text) <> 0) then<br />
@text &= " (" & hero.miniontext & ")"<br />
endif<br />
endif<br />
</pre><br />
<br />
====Character Details====<br />
<br />
The core details for the character are rather extensive. We need to show the basics like the name and rank, as well as the attributes, derived traits, abilities, and skills. To ensure that the ally is highly usable during play, we also need to include arcane powers, weapon details, armor, and gear.<br />
<br />
The output format is very simple and compact. Each category of information is identified by an indicator in bold. The actual information follows in plain text. Each new category starts on a new line so that everything is cleanly organized and easy for the user to access whatever information he wants.<br />
<br />
At the very top of the details section, we include any notes that the user assigned to the ally. Since our script starts with the "actor" pick of the ally as its initial context, we need to access the anchor pick that attaches the minion. Once we have the anchor pick, we can then access the appropriate field to include in our output.<br />
<br />
The complete script to synthesize all the character details is shown below.<br />
<br />
<pre><br />
var txt as string<br />
var ismore as number<br />
<br />
~output any notes for the ally<br />
if (anchor.field[alySummary].isempty = 0) then<br />
@text &= "{b}Notes:{/b} " & anchor.field[alySummary].text & "{br}"<br />
endif<br />
<br />
~output any race<br />
txt = hero.firstchild["Race.?"].field[name].text<br />
if (empty(txt) <> 0) then<br />
txt = "-none-"<br />
endif<br />
@text &= "{b}Race:{/b} " & txt<br />
<br />
~output the rank and XP<br />
var rankvalue as number<br />
var ranktext as string<br />
rankvalue = herofield[acRank].value<br />
call RankName<br />
@text &= "; {b}" & ranktext & "{/b} ("<br />
@text &= hero.child[resXP].field[resMax].text & " XP)"<br />
@text &= "{br}"<br />
<br />
~use a hanging indent from here on out<br />
@text &= "{indent -100}"<br />
<br />
~output attributes<br />
@text &= "{b}Attributes:{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.Attribute & !Hide.Attribute"<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[trtAbbrev].text & " " & eachpick.field[trtDisplay].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
<br />
~output derived traits<br />
@text &= "{b}Traits:{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.Derived & !Hide.Trait" sortas explicit<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[trtAbbrev].text & " " & eachpick.field[trtDisplay].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
<br />
~output special abilities (if any)<br />
if (hero.haschild["component.Ability"] <> 0) then<br />
@text &= "{b}Abilities:{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.Ability" sortas SpecialTab<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[shortname].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
endif<br />
<br />
~output arcane powers (if any)<br />
if (hero.haschild["component.Power"] <> 0) then<br />
@text &= "{b}Arcane Powers (" & #trkmax[trkPower] & "):{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.Power"<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[name].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
endif<br />
<br />
~output skills<br />
@text &= "{b}Skills:{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.Skill & !Hide.Skill"<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[trtAbbrev].text<br />
if (eachpick.tagis[User.NeedDomain] <> 0) then<br />
@text &= " (" & eachpick.field[domDomain].text & ")"<br />
endif<br />
@text &= " " & eachpick.field[trtDisplay].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
<br />
~output weapons (if any)<br />
if (hero.haschild["component.WeaponBase"] <> 0) then<br />
@text &= "{b}Weapons:{/b} "<br />
ismore = 0<br />
foreach pick in hero where "component.WeaponBase" sortas Armory<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[name].text<br />
@text &= " " & eachpick.field[wpNetAtk].text<br />
@text &= " (" & eachpick.field[wpShowDmg].text<br />
if (eachpick.field[wpPiercing].value <> 0) then<br />
@text &= ", AP" & eachpick.field[wpPiercing].text<br />
endif<br />
if (eachpick.tagis[component.WeapRange] <> 0) then<br />
@text &= ", " & eachpick.field[wpRange].text<br />
endif<br />
@text &= ")"<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
endif<br />
<br />
~output armor and gear together (if any)<br />
if (hero.haschild["component.Defense | component.Equipment"] <> 0) then<br />
<br />
~output armor<br />
ismore = 0<br />
foreach pick in hero where "component.Defense" sortas Armory<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[name].text<br />
@text &= " (" & signed(eachpick.field[defDefense].text)<br />
if (eachpick.tagis[component.Shield] <> 0) then<br />
if (eachpick.field[defParry].value <> 0) then<br />
@text &= ", Parry" & signed(eachpick.field[defParry].text)<br />
endif<br />
endif<br />
@text &= ")"<br />
ismore = 1<br />
nexteach<br />
<br />
~output gear<br />
foreach pick in hero where "component.Equipment"<br />
if (ismore <> 0) then<br />
@text &= ", "<br />
endif<br />
@text &= eachpick.field[grStkName].text<br />
ismore = 1<br />
nexteach<br />
@text &= "{br}"<br />
endif<br />
</pre><br />
<br />
====Status Tracking====<br />
<br />
At the very bottom of each ally, we're going to allows users to easily track the status of the ally during play. We'll include tracking for the ally's health, power points (if applicable), and ammunition (if applicable). The health tracking will depend on whether the character is a wildcard or not. For power points, we'll simply show a series of boxes, up to the total number of power points possessed by the character. The ammo will use the simplified mechanism outlined in the rulebook, which presents four levels.<br />
<br />
The resulting Label script for synthesizing all the tracking information is shown below.<br />
<br />
<pre><br />
var box as string<br />
var gap as string<br />
<br />
~output mechanism for tracking health<br />
gap = "{horz 50}"<br />
@text &= "{b}Wounds:" & gap<br />
if (herofield[acIsWild].value <> 0) then<br />
@text &= "-1" & gap & "-2" & gap & "-3" & gap<br />
endif<br />
@text &= "INC"<br />
@text &= "{horz 100}Fatigue:" & gap<br />
@text &= "-1" & gap & "-2" & gap & "INC"<br />
@text &= "{/b}{br}"<br />
<br />
~output boxes for tracking power points (if applicable)<br />
if (hero.haschild["component.Power"] <> 0) then<br />
@text &= "{vert 5}"<br />
@text &= "{b}Power:{/b}{horz 40}"<br />
var i as number<br />
var j as number<br />
var limit as number<br />
limit = #trkmax[trkPower] / 5<br />
@text &= "{font wingdings}"<br />
for i = 1 to limit<br />
for j = 1 to 4<br />
@text &= chr(168)<br />
next<br />
@text &= "{size 44}" & chr(168) & "{size 36}"<br />
next<br />
@text &= "{revert}{br}"<br />
endif<br />
<br />
~output boxes for tracking the ammo supply (if any ranged weapons)<br />
if (hero.haschild["component.WeapRange"] <> 0) then<br />
@text &= "{vert 8}"<br />
box = "{font Wingdings}{size 40}" & chr(168) & "{revert}"<br />
gap = "{horz 65}"<br />
@text &= "{b}Ammo:{/b}" & gap & "Full " & box & gap & "High " & box & gap & "Low " & box & gap & "Out " & box<br />
endif<br />
</pre><br />
<br />
===Printing Vehicles===<br />
<br />
We currently just identify the existence of vehicles within the gear list. This is adequate when the vehicle is used as nothing more than a form of transportation. However, Savage Worlds includes full rules for vehicles in combat, and many of the vehicles are specifically intended for use in combat. Consequently, there will often be times when a player wants to see full details for his vehicles.<br />
<br />
We can incorporate vehicles into the character sheet in the exact same way as we handle allies. We'll use the exact same approach, showing the vehicle name as a title at the top, with the vehicle details and damage tracking beneath. Since we're using the same approach, we can copy what we have for allies and adapt it for use with vehicles.<br />
<br />
====The Table Portal====<br />
<br />
We'll start with the table portal. For vehicles, our table portal will be operating on picks within the character instead of separate minions. This means that we can use the default behaviors for both what to show in the table and how to sequence them. We'll still want our items to vary in height, and we'll provide our own title at the top of each, so we'll also need the gap between items. This results in the table portal below.<br />
<br />
<pre><br />
<portal<br />
id="oVehicle"<br />
style="outNormal"><br />
<output_table<br />
component="Vehicle"<br />
showtemplate="oVehPick"<br />
varyheight="yes"<br />
showgapy="25"><br />
</output_table><br />
</portal><br />
</pre><br />
<br />
====Layout Integration====<br />
<br />
Integrating this new table portal into the layout will work the exact same way as allies. We need to add the "portalref" element and include an "autoplace" statement to position the new table. We can add our vehicles either before or after allies, so we'll choose to add them afterwards. This results in the following revised layout.<br />
<br />
<pre><br />
<layout<br />
id="oStandard2"><br />
<portalref portal="oPower"/><br />
<portalref portal="oArmor"/><br />
<portalref portal="oWeapon"/><br />
<portalref portal="oGear"/><br />
<portalref portal="oAlly"/><br />
<portalref portal="oVehicle"/><br />
<position><![CDATA[<br />
~position the various tables in the desired sequence<br />
perform portal[oPower].autoplace<br />
perform portal[oArmor].autoplace<br />
perform portal[oWeapon].autoplace<br />
perform portal[oGear].autoplace<br />
perform portal[oAlly].autoplace<br />
perform portal[oVehicle].autoplace<br />
<br />
~the height of the layout is the bottommost extent of the elements within<br />
height = autotop<br />
]]></position><br />
</layout><br />
</pre><br />
<br />
====The Template====<br />
<br />
Our template will behave the exact same was as for allies. We'll have the same four sections that serve the same roles. As such, our Position script requires zero changes. The only things we need to change are the unique id, name, and the contents of three of the portals.<br />
<br />
The first portal outputs the name of the vehicle. Since we can assume that the names of vehicles will make each entry readily identifiable as a vehicle, we don't have to do anything special with the name. So we'll change the portal to a simple field-based portal, as shown below.<br />
<br />
<pre><br />
<portal<br />
id="name"<br />
style="outTitle"><br />
<output_label<br />
field="name"><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
The vehicle details are completely different from allies. However, we're going to use the identical approach in synthesizing the output. We can replace the Label script for the portal with the appropriate information for vehicles. If a vehicle has weapons, we need to include full details for each weapon as well. This results in the following revised portal for vehicles.<br />
<br />
<pre><br />
<portal<br />
id="details"<br />
style="outAlly"><br />
<output_label><br />
<labeltext><![CDATA[<br />
~output the crew size<br />
@text &= "{b}Crew:{/b} " & field[vhCrew].text & "{br}"<br />
<br />
~output the acceleration, speed, and climb for aircraft<br />
@text &= "{b}Acceleration{/b}: " & field[vhAccel].text<br />
@text &= "{horz 75}{b}Top Speed:{/b} " & field[vhTopSpeed].text<br />
if (tagis[VehType.Aircraft] <> 0) then<br />
@text &= "{horz 75}{b}Climb:{/b} " & field[vhClimb].text<br />
endif<br />
@text &= "{br}"<br />
<br />
~output the toughness and armor<br />
@text &= "{b}Toughness{/b}: " & field[vhTough].text<br />
@text &= "{horz 75}{b}Armor{/b}: " & field[vhArmor].text & "{br}"<br />
<br />
~if there is no child entity/gizmo, then there's nothing more to do<br />
if (isentity = 0) then<br />
done<br />
endif<br />
<br />
~use a hanging indent from here on out<br />
@text &= "{indent -150}"<br />
<br />
~there is a child entity/gizmo, so output the load-out<br />
@text &= "{b}Weapons/Equipment:{/b}{br}"<br />
foreach pick in gizmo<br />
@text &= "{horz 10}" & chr(149) & " " & eachpick.field[name].text & ": "<br />
@text &= eachpick.field[wpShowDmg].text & ", " & eachpick.field[wpRange].text<br />
if (eachpick.field[wpNotes].isempty = 0) then<br />
@text &= ", " & eachpick.field[wpNotes].text<br />
endif<br />
@text &= "{br}"<br />
nexteach<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
The portal for the separator line requires no changes, so our final portal to deal with is for status tracking during play. Vehicles only need a damage track, so that's what we'll include. Tracking ammunition for weapons with hundreds or thousands of rounds is not practical on the character sheet, so we won't even try. This yields the revised portal below.<br />
<br />
<pre><br />
<portal<br />
id="tracking"<br />
style="outAlly"><br />
<output_label><br />
<labeltext><![CDATA[<br />
var gap as string<br />
<br />
~output mechanism for tracking damage<br />
gap = "{horz 50}"<br />
@text &= "{b}Damage:" & gap<br />
@text &= "-1" & gap & "-2" & gap & "-3" & gap & "Wrecked"<br />
@text &= "{/b}"<br />
]]></labeltext><br />
</output_label><br />
</portal><br />
</pre><br />
<br />
Vehicle output within character sheets is now fully operational.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2977Changes in V3.2 (Savage)2009-05-05T06:10:26Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#All ammunition is automatically designated as a "GearType" of "Ammo".<br />
#Eliminated reliance on the "Wingdings 2" font by replacing all uses of that font with suitable alternates from the "Wingdings" font. The "Wingdings 2" font is not always available on all computers.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2976Changes in V3.2 (Savage)2009-05-05T05:54:23Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#All ammunition is automatically designated as a "GearType" of "Ammo".</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_File_Changes_V3.2&diff=2975Skeleton File Changes V3.22009-05-05T05:47:55Z<p>Rob: /* File: "editor.dat" */</p>
<hr />
<div>{{context|Kit Reference|Skeleton Data File Revision History}}<br />
<br />
===File: "tags.1st"===<br />
<br />
Line 39: Added definition of the "Helper.NoMinimum" tag for use with Resources.<br />
<br />
===File: "equipment.str"===<br />
<br />
Line 68: Corrected the calculation of the "lot cost" for a piece of gear.<br />
<br />
Line 767: When creating ammunition and we have a transaction pick, the initial user quantity must be setup based on the actual quantity purchased.<br />
<br />
===File: "traits.str"===<br />
<br />
Line 214: Added the "Activated" identity tag group for shared use with adjustments.<br />
<br />
Line 240: If an ability is activated, the corresponding "Activated" identity tag is now forwarded to the actor.<br />
<br />
===File: "miscellaneous.str"===<br />
<br />
Line 182: Added new Eval Rule script that reports a validation warning for any resource that is not fully spent, except if that resource is assigned the "Helper.NoMinimum" tag.<br />
<br />
===File: "thing_miscellaneous.dat"===<br />
<br />
Line 81: Assigned "Helper.NoMinimum" tag to disable reporting a validation warning if XP are not spent.<br />
<br />
===File: "form_static.dat"===<br />
<br />
Line 81: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_config.dat"===<br />
<br />
Line 92: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_manipulate.dat"===<br />
<br />
Line 49: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "sheet_standard2.dat"===<br />
<br />
Line 85: The right-side column of output must be properly positioned on the right.<br />
<br />
===File: "editor.dat"===<br />
<br />
Line 17: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 42: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 72: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 119: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 129: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 149: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 194: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 254: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 279: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 156: Added "Ammunition" edit thing to allow users to enter ammunition via the Editor.<br />
<br />
Line 137: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
Line 207: Added "Weight" field for use by the Editor.<br />
<br />
Line 272: Added "Weight" field for use by the Editor.<br />
<br />
Line 317: Added "Weight" field for use by the Editor.<br />
<br />
Line 347: Added "Weight" field for use by the Editor.<br />
<br />
===File: "system_resources.aug"===<br />
<br />
Line 268: Added definition of the "tabwarning" color resource to allow authors to easily override the resource if they wish.<br />
<br />
Line 626: Added definition of the "edtbackov" color resource to enable overrides.<br />
<br />
Line 1131: Added definition of the "progtext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "cnflictext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "buygameup" and "buygamedn" bitmap resources to enable overrides.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_File_Changes_V3.2&diff=2974Skeleton File Changes V3.22009-05-05T05:44:38Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference|Skeleton Data File Revision History}}<br />
<br />
===File: "tags.1st"===<br />
<br />
Line 39: Added definition of the "Helper.NoMinimum" tag for use with Resources.<br />
<br />
===File: "equipment.str"===<br />
<br />
Line 68: Corrected the calculation of the "lot cost" for a piece of gear.<br />
<br />
Line 767: When creating ammunition and we have a transaction pick, the initial user quantity must be setup based on the actual quantity purchased.<br />
<br />
===File: "traits.str"===<br />
<br />
Line 214: Added the "Activated" identity tag group for shared use with adjustments.<br />
<br />
Line 240: If an ability is activated, the corresponding "Activated" identity tag is now forwarded to the actor.<br />
<br />
===File: "miscellaneous.str"===<br />
<br />
Line 182: Added new Eval Rule script that reports a validation warning for any resource that is not fully spent, except if that resource is assigned the "Helper.NoMinimum" tag.<br />
<br />
===File: "thing_miscellaneous.dat"===<br />
<br />
Line 81: Assigned "Helper.NoMinimum" tag to disable reporting a validation warning if XP are not spent.<br />
<br />
===File: "form_static.dat"===<br />
<br />
Line 81: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_config.dat"===<br />
<br />
Line 92: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_manipulate.dat"===<br />
<br />
Line 49: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "sheet_standard2.dat"===<br />
<br />
Line 85: The right-side column of output must be properly positioned on the right.<br />
<br />
===File: "editor.dat"===<br />
<br />
Line 17: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 42: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 72: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 119: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 129: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 149: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 194: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 254: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 279: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 156: Added "Ammunition" edit thing to allow users to enter ammunition via the Editor.<br />
<br />
Line 137: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
Line 207: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
Line 277: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
Line 327: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
Line 362: Added "Lot Cost" and "Weight" fields for use by the Editor.<br />
<br />
===File: "system_resources.aug"===<br />
<br />
Line 268: Added definition of the "tabwarning" color resource to allow authors to easily override the resource if they wish.<br />
<br />
Line 626: Added definition of the "edtbackov" color resource to enable overrides.<br />
<br />
Line 1131: Added definition of the "progtext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "cnflictext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "buygameup" and "buygamedn" bitmap resources to enable overrides.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2973Changes in V3.2 (Savage)2009-05-05T05:42:08Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#Added support for the "Lot Cost" and "Weight" fields for all types of equipment within the Editor.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2972Skeleton Data File Revision History2009-05-05T05:41:57Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from three edit portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.<br />
#Added support for entering "Ammunition" via the Editor.<br />
#Added support for the "Lot Cost" and "Weight" fields for all types of equipment within the Editor.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_File_Changes_V3.2&diff=2971Skeleton File Changes V3.22009-05-05T05:23:43Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference|Skeleton Data File Revision History}}<br />
<br />
===File: "tags.1st"===<br />
<br />
Line 39: Added definition of the "Helper.NoMinimum" tag for use with Resources.<br />
<br />
===File: "equipment.str"===<br />
<br />
Line 68: Corrected the calculation of the "lot cost" for a piece of gear.<br />
<br />
Line 767: When creating ammunition and we have a transaction pick, the initial user quantity must be setup based on the actual quantity purchased.<br />
<br />
===File: "traits.str"===<br />
<br />
Line 214: Added the "Activated" identity tag group for shared use with adjustments.<br />
<br />
Line 240: If an ability is activated, the corresponding "Activated" identity tag is now forwarded to the actor.<br />
<br />
===File: "miscellaneous.str"===<br />
<br />
Line 182: Added new Eval Rule script that reports a validation warning for any resource that is not fully spent, except if that resource is assigned the "Helper.NoMinimum" tag.<br />
<br />
===File: "thing_miscellaneous.dat"===<br />
<br />
Line 81: Assigned "Helper.NoMinimum" tag to disable reporting a validation warning if XP are not spent.<br />
<br />
===File: "form_static.dat"===<br />
<br />
Line 81: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_config.dat"===<br />
<br />
Line 92: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_manipulate.dat"===<br />
<br />
Line 49: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "sheet_standard2.dat"===<br />
<br />
Line 85: The right-side column of output must be properly positioned on the right.<br />
<br />
===File: "editor.dat"===<br />
<br />
Line 17: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 42: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 72: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 119: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 129: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 149: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 194: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 254: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 279: Added "prefix" attribute for use by the Editor.<br />
<br />
===File: "system_resources.aug"===<br />
<br />
Line 268: Added definition of the "tabwarning" color resource to allow authors to easily override the resource if they wish.<br />
<br />
Line 626: Added definition of the "edtbackov" color resource to enable overrides.<br />
<br />
Line 1131: Added definition of the "progtext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "cnflictext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "buygameup" and "buygamedn" bitmap resources to enable overrides.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2970Skeleton Data File Revision History2009-05-05T05:21:40Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from three edit portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2969Changes in V3.2 (Savage)2009-05-05T05:21:27Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.<br />
#Fixed problem with the handling of abilities, where they were not being properly flagged on the actor for indication to the user.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_File_Changes_V3.2&diff=2968Skeleton File Changes V3.22009-05-04T22:24:18Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference|Skeleton Data File Revision History}}<br />
<br />
===File: "tags.1st"===<br />
<br />
Line 39: Added definition of the "Helper.NoMinimum" tag for use with Resources.<br />
<br />
===File: "equipment.str"===<br />
<br />
Line 68: Corrected the calculation of the "lot cost" for a piece of gear.<br />
<br />
Line 767: When creating ammunition and we have a transaction pick, the initial user quantity must be setup based on the actual quantity purchased.<br />
<br />
===File: "miscellaneous.str"===<br />
<br />
Line 182: Added new Eval Rule script that reports a validation warning for any resource that is not fully spent, except if that resource is assigned the "Helper.NoMinimum" tag.<br />
<br />
===File: "thing_miscellaneous.dat"===<br />
<br />
Line 81: Assigned "Helper.NoMinimum" tag to disable reporting a validation warning if XP are not spent.<br />
<br />
===File: "form_static.dat"===<br />
<br />
Line 81: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_config.dat"===<br />
<br />
Line 92: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "form_manipulate.dat"===<br />
<br />
Line 49: Eliminated the "maxlength" attribute that now results in a compilation error.<br />
<br />
===File: "sheet_standard2.dat"===<br />
<br />
Line 85: The right-side column of output must be properly positioned on the right.<br />
<br />
===File: "editor.dat"===<br />
<br />
Line 17: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 42: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 72: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 119: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 129: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 149: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 194: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 254: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 279: Added "prefix" attribute for use by the Editor.<br />
<br />
===File: "system_resources.aug"===<br />
<br />
Line 268: Added definition of the "tabwarning" color resource to allow authors to easily override the resource if they wish.<br />
<br />
Line 626: Added definition of the "edtbackov" color resource to enable overrides.<br />
<br />
Line 1131: Added definition of the "progtext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "cnflictext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "buygameup" and "buygamedn" bitmap resources to enable overrides.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2967Skeleton Data File Revision History2009-05-04T22:22:11Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from three edit portals that exceeded the maximum allowed length of the underlying field.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2966Changes in V3.2 (Savage)2009-05-04T22:21:17Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.<br />
#Eliminated the edit portal length from various portals that exceeded the maximum allowed length of the underlying field.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_File_Changes_V3.2&diff=2965Skeleton File Changes V3.22009-05-04T20:12:20Z<p>Rob: </p>
<hr />
<div>{{context|Kit Reference|Skeleton Data File Revision History}}<br />
<br />
===File: "tags.1st"===<br />
<br />
Line 39: Added definition of the "Helper.NoMinimum" tag for use with Resources.<br />
<br />
===File: "equipment.str"===<br />
<br />
Line 68: Corrected the calculation of the "lot cost" for a piece of gear.<br />
<br />
Line 767: When creating ammunition and we have a transaction pick, the initial user quantity must be setup based on the actual quantity purchased.<br />
<br />
===File: "miscellaneous.str"===<br />
<br />
Line 182: Added new Eval Rule script that reports a validation warning for any resource that is not fully spent, except if that resource is assigned the "Helper.NoMinimum" tag.<br />
<br />
===File: "thing_miscellaneous.dat"===<br />
<br />
Line 81: Assigned "Helper.NoMinimum" tag to disable reporting a validation warning if XP are not spent.<br />
<br />
===File: "sheet_standard2.dat"===<br />
<br />
Line 85: The right-side column of output must be properly positioned on the right.<br />
<br />
===File: "editor.dat"===<br />
<br />
Line 17: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 42: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 72: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 119: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 129: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 149: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 194: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 254: Added "prefix" attribute for use by the Editor.<br />
<br />
Line 279: Added "prefix" attribute for use by the Editor.<br />
<br />
===File: "system_resources.aug"===<br />
<br />
Line 268: Added definition of the "tabwarning" color resource to allow authors to easily override the resource if they wish.<br />
<br />
Line 626: Added definition of the "edtbackov" color resource to enable overrides.<br />
<br />
Line 1131: Added definition of the "progtext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "cnflictext" color resource to enable overrides.<br />
<br />
Line 1315: Added definition of the "buygameup" and "buygamedn" bitmap resources to enable overrides.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2964Skeleton Data File Revision History2009-05-04T20:09:41Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2963Changes in V3.2 (Savage)2009-05-04T20:09:28Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.<br />
#Fixed bug where ammunition was not having its quantity setup properly for tracking on the In-Play tab.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2962Changes in V3.2 (Savage)2009-05-04T09:30:03Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.<br />
#Added armor protection ratings on a per-location basis to the In-Play tab.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2961Changes in V3.2 (Savage)2009-05-03T21:59:02Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.<br />
#Added Encumbrance and Load Limit details to the character sheet.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Changes_in_V3.2_(Savage)&diff=2960Changes in V3.2 (Savage)2009-05-03T20:40:46Z<p>Rob: </p>
<hr />
<div>{{context|Authoring Examples|Savage Worlds Walk-Through}}<br />
<br />
The following changes were made to the Savage Worlds data files in the V3.2 release of Hero Lab.<br />
<br />
#Widened the space for the defensive value in the summary panel for armor and shields.<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added Minimum Rank specification to Editor for Arcane Powers.<br />
#Added Forbidden Arcane Backgrounds specification to Editor for Arcane Powers.<br />
#Fixed bug where Horse and Warhorse were treated as normal gear holders and their weight would be applied to the character.<br />
#Eliminated options for menu label text from Editor, since no labels are ever shown in Savage Worlds.<br />
#Added stock portfolio containing all the various animals from the Bestiary.<br />
#Added stock portfolio containing all monstrous creatures from the Bestiary.<br />
#Errors with arcane powers now highlight the Arcane tab in red.<br />
#Unspent resources during character creation report validation warnings and highlight the appropriate tabs.<br />
#Added an in-play adjustment for Armor to enable easy application of the effects of the Armor arcane power.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2959Skeleton Data File Revision History2009-05-03T20:39:33Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.<br />
#Added new system resources that authors can override when tailoring the interface for a custom game system.</div>Robhttps://hlkitwiki.wolflair.com/index.php5?title=Skeleton_Data_File_Revision_History&diff=2958Skeleton Data File Revision History2009-05-03T20:38:00Z<p>Rob: /* V3.2 Revision History{{anchor|v3p2}} */</p>
<hr />
<div>{{context|Kit Reference}}<br />
<br />
The Skeleton Data Files were initially released in V3.0 and have evolved since that time. If you started work on your data files with an older release than is currently available, you should probably integrate the changes listed below for each subsequent release.<br />
<br />
*[[#v3p1|V3.1 Release]]<br />
*[[#v3p2|V3.2 Release]]<br />
<br />
==V3.1 Revision History{{anchor|v3p1}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.1|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.1.<br />
<br />
#Added highlighting of any currently equipped weapon and/or armor on the Armory summary panel.<br />
#Eliminated use of the "mousepos" attribute within MouseInfo scripts whenever it specified the default behavior was to be used.<br />
#Fixed a bug in the standard character sheet that failed to handle weapons that are non-stackable.<br />
#Integrated use of the "output_dots" portal within the sample character sheet framework that is provided.<br />
#Added a few lines of missing code to Position script for the "oAdjPick" template.<br />
#Increased the "maxfinal" length of "grStkName" field within "Gear" component to 100.<br />
#Fixed problem with the color highlighting not showing red properly in Finalize script for "resAddItem" field of "Resource" component.<br />
#Revised the gear template to be more intelligent and adaptive.<br />
#Eliminated some extraneous code from the "power" portal within the "dashboard" template.<br />
#Fixed a problem in the "DshActive" procedure that was not properly outputting activated abilities that weren't in-play adjustments.<br />
#Added the "lblSmlLeft" style for general use.<br />
#Utilized the "lblSmlLeft" style within the TacCon.<br />
#Fixed problems with the Eval script for generating the name within the "Adjustment" component.<br />
#Corrected the behavior of the Label script for the "summary" portal within the "tacPick" template of the Tactical Console.<br />
#Cleaned up the code in various scripts within the "tacPick" template of the Tactical Console.<br />
#Renamed the "damage" and "status" portals within the "tacPick" template of the Tactical Console to "status1" and "status2", respectively.<br />
#Renamed the "column1" portal within the "tacPick" template of the Tactical Console to "traits".<br />
#Renamed the "DashTacCon.Column1" tag to "Traits".<br />
#The contents of the "peace" and "summary" portals within the "tacPick" template of the Tactical Console are sorted by name for display.<br />
#The "summary" portal uses "sizetofit" to shrink a bit whenever its contents are too large to fit in the available space.<br />
#The "static" form include built-in handling for accessing the master when a minion is being edited.<br />
#Defined the "actMaster" style and added the corresponding bitmaps as built-in resources.<br />
#The "Domain" component automatically integrates the domain into the name of the pick, plus the "shortname" field if one exists.<br />
#The form for advancements uses the base "thing" name when synthesizing a name for display instead of the normal name, providing full control over how the domain is shown for advancements.<br />
#Suitable abbreviations are now defined for all traits.<br />
#Revised the logic for shrinking text on the advancements form.<br />
#Revised the logic for limiting line height on advancements form.<br />
#Eliminated use of "textheight" for validation report sizing in the character sheet.<br />
#Revised a number of Position scripts within the character sheet to make proper use of "sizetofit" (some original uses were ineffectual).<br />
#Fixed problem where the Journal tab was showing the total XP based on the contents of the usage pool instead of the "resXP" resource.<br />
#Heroes track their "dead" state, which is shown on the TacCon.<br />
#Added pre-defined "menuSmall" style for smaller menus.<br />
#Added built-in support for handling things that require special user-selection behaviors, including checkboxes, array-based menus, and thing-based menus. This includes the "UserSelect" component for behaviors and "UserSelect" template to handle visuals.<br />
#Added built-in thing for handling natural armor, which requires the "defDefense" field to be "derived" instead of "static".<br />
#Added handling to the "SimpleItem" template that automatically changes the color of any non-deletable items to indicate that state.<br />
#If an equippable item possesses the "Equipment.Natural" tag at the time of creation, the item is initialized to the equipped state but may thereafter be changed.<br />
#Added option for centering the name within the "SimpleItem" and "LargeItem" templates.<br />
#Added the "Equipment.StartEquip" tag and handling for it within the Creation script of the "Equippable" component.<br />
#Revised the validation rules within the "Domain" component so that any panel linked to the thing is properly highlighted when the domain is required and not specified.<br />
#The "Domain" component supports customization of the term shown to the user for the domain within validation errors via assignment of a tag from the "DomainTerm" tag group.<br />
#The advancements mechanism supports the "DomainTerm" behaviors when displaying options that leverage domains.<br />
#Moved the user manual into the "docs" folder beneath where the data files are stored to keep it separate from the other data files.<br />
#Abilities marked as "creation only" now verify the appropriate state via the "state.iscreate" test.<br />
#Revised timing of setting the delta for the "trtUser" field in the file "traits.str".<br />
#Revised timing of the scripts that tally attribute and skill points within "traits.str".<br />
#Added a "notation" advance to the advancements mechanism.<br />
#Sheet output of abilities must be limited to a single line high.<br />
#Changed the timing of the script handling auto-equipped gear, as it was scheduled much earlier than necessary and limiting authoring options.<br />
#Moved a variety of bitmaps into the "builtin" folder, which then required changing most "image_literal" portals to utilize the bitmaps there.<br />
#Added an assortment of named color resources that are then used within the various styles, which allows for easier re-use and replacement by an author.<br />
#The Finalize script of the "acPPSumm" field on the "Actor" component must shown the "trkUser" field instead of "trtLeft".<br />
#Revamped the starting HTML file for use as a User Manual.<br />
#The ranged weapons table "arRange" must reference the "Gear" component so that the appropriate transaction scripts are invoked.<br />
<br />
==V3.2 Revision History{{anchor|v3p2}}==<br />
<br />
{{important}}A detailed list of the specific changes made to each file {{flalt|Skeleton File Changes V3.2|can be found here}}.<br />
<br />
The following changes and additions were introduced in V3.2.<br />
<br />
#Fixed bug where character sheet output that continued onto subsequent pages did not properly position the right-side column of output.<br />
#Added use of the "prefix" attribute on "editthing" elements within the Editor.<br />
#Unspent resources report validation warnings and highlight the appropriate tabs unless assigned the "Helper.NoMinimum" tag.<br />
#Fixed bug where the "lot cost" of a piece of gear was being calculated incorrectly.</div>Rob