New magc item

[Kaleb]

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.

[lifer4700]

I summon Wall of Text!

Hopefully this works....

[lifer4700]

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.

doneif (field[usrChosen1].ischosen = 0)

This checks the dropdown on the boots in the user interface, and exits the script if the user has not chosen anything. Nothing further is executed.

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)

var sourcename as string

This creates a variable called "sourcename" that will hold a string type value

  if (field[usrChosen1].chosen.tagis[User.NeedDomain] <> 0) then

This section checks the dropdown on the boots (now that we know there's been something picked) to see if the chosen Terrain needs more definition.
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.

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)

This portion add a few tags onto the boots, User.NeedDomain, User.OptDomain, and User.NoAutoName.

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)

  else
	field[livename].text = field[name].text & " (" & lowercase(field[usrChosen1].chosen.field[shortname].text) & ")"
	sourcename = lowercase(field[usrChosen1].chosen.field[shortname].text)
  endif

Simply set the field[livename] equal to the existing field[name], plus the chosen terrain's name, surrounded with parenthesis.
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.

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.

var searchexpr as string
searchexpr = field[usrChosen1].chosen.tagids[thingid.?,"|"]
var foundone as number

Set up two variables.
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...

foreach pick in hero from BaseCustSp where searchexpr

...is actually this.

foreach pick in hero from BaseCustSp where field[usrChosen1].chosen.tagids[thingid.?,"|"]

With the picks belonging to BaseCustSp, we only want the ones where the field[usrChosen1] contains a field whose [GroupID.TagID] has a GroupID of thingid (I believe they all will), and we don't care about the TagID, the question mark is a wildcard that matches all. Finally, we want the list of results separated by the pipe character.

Within the foreach-nexteach loop, we can process eachpick in turn. (Personally, I like this script function a lot)

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

For each result, check to see if it's one that needs some extra text (Chaos Plain, Evil Plane, etc.)
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).

  else
    eachpick.field[abValue].value += 2
    foundone = 1
  endif

If the pick did not require the extra user text, i.e.: tagis[User.NeedDomain] not found, then just asign the boost.
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.

nexteach

Go back to the list and check the next pick until we've checked all the results of the original search.

  doneif (foundone <> 0)

If we didn't find any Ranger Favored Terrains that matched our boots, then we're done.

  var favbonus as number
  favbonus = 2

The first two lines define a varaiable to hold the number 2, which is the amount of a bonus we're giving to the favored terrain. I'm not sure why we're setting this since we increased the field[abValue] by two.

  call FavTerrain

Black Magic.
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.