Senior Member
Join Date: Aug 2010
Posts: 576
|
I want to make a new magic item simular to Boots of Freindly terrain with the exception that the weraer can choose tree terrains and adds 19; to his movement in the favored terrains that he choose. I looked at the evaluation script for boots of freindly terrain but di not understand them. could some one give me some help.
|
#1 |
Senior Member
Join Date: Nov 2011
Location: Michigan
Posts: 182
|
I summon Wall of Text!
Hopefully this works.... |
#2 |
Senior Member
Join Date: Nov 2011
Location: Michigan
Posts: 182
|
Ok, here's an attempt to explain a bit of what is going on.
I will assume zero knowledge, forgive me if some of my explainations seem overly simplistic. I hope this is correct, but I'm still new at this scripting language and I am still learning its nuances. This script contains many techniques that I have not seen yet, and by doing this I am learning as well. Hopefully, Mathias, ShadowChemosh, et. al. will correct any mistakes I make. Code:
doneif (field[usrChosen1].ischosen = 0) By the way, the field[userChosen1] is a property on the boots. It is related to the section in the editor called "Item Selection" The Custom Expression entry sets a field on the boots named usrCandid1 to its value (as seen with the Fields button) The Restrict First List To... entry adds a tag whose GroupID.TagID is ChooseSrc1.Thing (as seen in the Tags button) Code:
var sourcename as string Code:
if (field[usrChosen1].chosen.tagis[User.NeedDomain] <> 0) then For example: The Cold terrain choice is a simple one, and the User.NeedDomain tag would not be present on that target Terrain type. However, the Chaos-Aligned Plane is one that requires that you specify a specific plain, and the User.NeedDomain tag would be present on that choice. If the choice needs further explanation, then we run the remaining portion of the if section, up to the else. Code:
perform assign[User.NeedDomain] perform assign[User.OptDomain] perform assign[User.NoAutoName] field[livename].text = field[name].text & " (" & lowercase(field[domDomain].text) & ")" field[shortname].text = field[livename].text sourcename = lowercase(field[domDomain].text) User.NeedDomain appears to tell HeroLab that it needs a user entered text field. I have no clue how this works internally. User.optDomain I don't know what this one does. My guess is that it means the Domain text entry is optional (won't turn red when blank) User.NoAutoName appears to turn off the autonaming feature for objects, so that we can name it ourselves without HL overwriting it. field[livename] (what you see on the user side) is then set to equal the existing name of the object, plus the text - field[domDomain] - that was typed in by the user, placed inside of parenthesis. field[shortname] is set to equal the field[livename] The sourcename variable is loaded with the new live name of the object for future use. If the initial terrain choice by the user does not require a text input (e.g.: Forest) Code:
else field[livename].text = field[name].text & " (" & lowercase(field[usrChosen1].chosen.field[shortname].text) & ")" sourcename = lowercase(field[usrChosen1].chosen.field[shortname].text) endif The sourcename variable is loaded with the new live name of the object for future use. At this point, we've allowed the user to pick a terrain, accounting for the special cases where a user entry is required, and changed the name of the boots to match. If the boots aren't being worn, we can leave, since there's nothing else to do. Code:
doneif (field[gIsEquip].value = 0) If we've gotten this far, the boots' terrain type has been chosen, and the boots are being worn. Now we've got work to do. Code:
var searchexpr as string searchexpr = field[usrChosen1].chosen.tagids[thingid.?,"|"] var foundone as number One called searchexpr to hold a string value, then give it an expression to use later for a search. Another called foundone to hold a number. Next, we use a searching mechanism. This syntax reminds me a lot of SQL. We ask the system to go through the list of picks on the hero, but only the ones in a pre-defined set called BaseCustSp I assume these are the chosen Specials? (there are other sets named BaseAttr, BaseWep, and probably more.) The searchexpr gets expanded, so this... Code:
foreach pick in hero from BaseCustSp where searchexpr Code:
foreach pick in hero from BaseCustSp where field[usrChosen1].chosen.tagids[thingid.?,"|"] Within the foreach-nexteach loop, we can process eachpick in turn. (Personally, I like this script function a lot) Code:
if (eachpick.tagis[User.NeedDomain] <> 0) then if (compare(eachpick.field[domDomain].text,field[domDomain].text) = 0) then eachpick.field[abValue].value += 2 foundone = 1 endif If so, compare the user text of the current pick to the user text of the boots. If they match, then boost the current pick (Ranger Terrain). Code:
else eachpick.field[abValue].value += 2 foundone = 1 endif In either case, we'll also set foundone to 1, so we know if we ever did find a matching terrain. NOTE: field[abValue] is a standard concept that all picks in Pathfinder should use. If you're creating your own feat or ability, etc. that holds a number, you should create a field[abValue] to calculate from. It allows external sources to modify the base value, exactly like we're doing here. We don't need to know anything about how the Terrains calculate their values, we can simply add two to the existing abValue, and the ability does the rest. Code:
nexteach Code:
doneif (foundone <> 0) Code:
var favbonus as number favbonus = 2 Code:
call FavTerrain No Clue what's going on here. Obviously, this is telling the Favored Terrain ability to recalculate its bonuses, but I this is the first time I've seen the 'call' command, and I don't know where that function name 'FavTerrain' is defined. Last edited by lifer4700; January 16th, 2013 at 07:09 AM. Reason: Typos... |
#3 |
|
|