Hero Lab scripting 201: Location, Location, Location
This article is part of a collection of editor and scripting articles: http://forums.wolflair.com/showthread.php?t=21688
I decided to add an article on a topic I don't think we've covered in much detail anywhere else. The principles I'm discussing apply to all game systems in Hero Lab, but for this article I'll be drawing my examples from Pathfinder. In a character in Hero Lab, there are many items - each attribute is an item, each feat, level of a class, archetype, weapon, etc. is its own individual item. For the rest of this article, I'll refer to them as picks. Very often, while writing a script, you'll want to look up information on another pick (perhaps to set the number of uses equal to an attribute modifier), or you'll want to change something about another pick (like adding a bonus to a skill). I'll be discussing how to travel around the set of picks that make up your character and the sorts of things you can do once you get somewhere and that sorts of questions you can ask once you get there. In Hero Lab's scripting language, the period: . is used as the transition from one place to another. You are allowed to make more that one transition in a row - it's actually very common to use many transitions in a row in order to travel from one pick to another. Every pick in a Hero Lab character is stored within a container. 98% of the picks in a character will be in a container called "hero", and there's only one "hero" container for each character. The rest will be in containers called gizmos - those are containers that exist within other picks. Each pick can only have one gizmo, and most picks will not actually have a gizmo. Gizmos are used in cases where at item is customizable - the custom versions of armor, weapons, scrolls, potions, wands, spells, and wordspells. Although I'm using the term container here, that isn't actually related to what you'd commonly call a container - things like backpacks and houses. If you tell Hero Lab that the group of alchemist's fire bottles you own should be stored within your belt pouch, it doesn't change the underlying container for either the alchemist's fire or the belt pouch. What it does do is to set up a new relationship between the alchemist's fire and the belt pouch. Within the scripting language, that relationship is referred to as gearholding, and I'll cover that later in this article. Let's take a look at some transitions: hero.child[skClimb].field[Bonus].value Breaking that down: hero . child[skClimb] . field[Bonus] . value So, what that's saying is: first, travel to the hero, then travel to the child of the hero whose Id is "skClimb" (which is the climb skill), then travel to the field on that child whose Id is "Bonus" (which is for untyped bonuses), then report the value of that field. Here's how you might use that: Code:
hero.child[skClimb].field[Bonus].value = hero.child[skClimb].field[Bonus].value + 2 That one's actually so commonly used that we've added some abbreviations, so that it takes less typing to get the same effect: Code:
#skillbonus[skClimb] += 2 hero.child[skClimb].tagis[Helper.ClassSkill] hero . child[skClimb] . tagis[Helper.ClassSkill] In other words: "travel to the hero container, and then to the climb skill pick that's in that container, and then report whether a Tag whose Id is "Helper.ClassSkill" is present on that pick". In simpler terms: "Is climb a class skill right now?" tagis[], like all the other TRUE/FALSE questions in Hero Lab, will report it's answer in the form of a number. It will report "0" if the answer is FALSE, and "1", if the answer is "TRUE". Example #3: field[usrChosen1].chosen.field[skRanks].value field[usrChosen1] . chosen . field[skRanks] . value That's saying: travel to the field (on us) called "usrChosen1" (which stores the user's choice from a drop-down menu), then travel to the pick the user chose, then travel to the skRanks field on that pick (which tells you how many ranks the user has applied to that skill), and report the value of that field. Here's how you might use that: Code:
if (field[usrChosen1].ischosen <> 0) then Example #4: hero.findchild[BaseRace].field[livename].text hero . findchild[BaseRace] . field[livename] . text That's saying: Travel to the hero container, then search among all the picks in that container for the first one you find that uses the BaseRace component, then travel to the livename field on that pick (livename stores the version of the name that will be displayed to the user), and report the text stored in that field. Here's how that might be used: Code:
hero.findchild[BaseRace].field[livename].text = "Mountain " & hero.findchild[BaseRace].field[livename].text In the next few posts, I'll look at each of the types of locations you might visit, and list where you can go from there, what questions you can ask while you're there, and what orders you can give Hero Lab while you're there. If you're writing an Eval Script or an Eval Rule, you'll start out in the pick context. If you're writing a Prereq or an Exprreq, you'll start out in the container context (either hero or gizmo, depending on what container this item will be in once it's added). |
Hero Context
Places you can travel to:
|
Pick Context
Places you can travel to:
|
Field Context
There are three types of fields - numerical, text, or menu, and each has different operations that can be performed. Places you can travel to:
(This can either be used to look up information on the field or to change the value of the field):
|
Gizmo Context
Places you can travel to:
|
Special Transition: Focus
Often, you'll need to do a lot of typing in order to travel to a particular thing. There's a special transition called the focus transition that you can use to "save your place", so that you don't have to do lots of typing if you need to do multiple things there. Places you can travel to:
|
Special Transitions: Searching
Often, you don't know exactly what child you want to transition to, but you know some things about what it will be like. For example "I want to find a light weapon that deals piercing damage and is made of metal". Other times, you know there are multiple picks with the same Id. The child[] transition would only take you to one of them, and it would pick that one at random, so, you need a way to find all of them. That's handled by searching through a container to find those picks. Code:
In that, replace component with the Id of a component that all of the things you're searching for have in common. To find this, add some examples of a few of the things you're trying to find to a test character, and look at their tags. There will be a section of tags whose Group Ids are all "component". Pick one of these - one that all of the things you're looking for will have. Replace test expression with a tag expression that narrows down the list even further than just the component does. To find these tags, look at the tags on the example items you added, and compare them to the tags on things that are like those examples, but not quite. If just the component will do the trick and will identify all the things you're searching for, you can leave out 'where "text expression"' entirely. While you're in that foreach, you can use a special transition:
An example: Code:
On each of the picks it finds, it will travel to the Bonus field for that pick, and add 1 to its value. In other words; "All our class skills get +1". Once you're done with all the operations that apply to the things you're searching for, close your foreach with the following line: Code:
This is a special transition you can do from either the hero or gizmo contexts: findchild[component,test expression] component is the same as in a foreach, and test expression is also the same as in a foreach. As in a foreach, if you don't need an expression, you can leave it out (if you do, leave out the comma, too). It's very common to use the setfocus instruction after findchild[] - that way, you don't need to repeat the search if there are lots of questions you want to ask on that pick and/or many things to change. Think of it as findchild[component,test expression].setfocus |
Special Case: Prereqs
The context of a prereq or an exprreq is the container (either the hero or the gizmo) that this item is being added to (or is currently in, if the user has selected this item). This is different from the eval scripts, where the initial context is the pick that the script is running on. In a prereq or an exprreq, there are some special instructions and special transitions that are available, and there are some restrictions on what you'll be able to accomplish. Questions you can ask
(these can either look up the current value of this special operator, or you can change its value)
Code:
|
(just in case I find another topic I want to add)
|
(just in case I find yet another topic I want to add)
|
All times are GMT -8. The time now is 01:06 PM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.