tag vs autotag vs bootstrap

[Duggan]

So, in my data files for Planet Mercenary, I currently have two different ways to augment skills and specialties, as lifted from the 4E files, and one way to add a specialty, which I think I lifted from the Savage Worlds tutorial. They all seem to add the items differently, which seems to impact what tags are present. I was wondering if you could clarify that the differences are:

First, I was setting up the either-or choices for the various backgrounds, and I lifted a bootstrap / autotag combo from the 4E files as follows:

For example, this is the current Chaplain entry (which isn't quite right because I still need to figure out a way to allow for a choice from a skill type):

<thing
id="cmdChapln"
name="Chaplain"
compset="CmdPckge"
isunique="yes"
description="The Chaplain provides both moral support and a moral compass. Morale and morality! Sometimes it falls to the Chaplain to point out what horrible people the other officers could become if they follow a given path. Other times the Chaplain must bring his carbine to his shoulder and clear a path with righteous indignation!">

<tag group="SkillBonus" tag="skDodge"/>
<tag group="SkillBonus" tag="skHistory"/>

<bootstrap thing="spHistRel"/>

<bootstrap thing="fRPlusSk">
<autotag group="SkillBonus" tag="skInspire"/>
<autotag group="SkillBonus" tag="skPerform"/>
<autotag group="explicit" tag="1"/>
</bootstrap>

<bootstrap thing="fRPlusSk">
<autotag group="SkillBonus" tag="skPistol"/>
<autotag group="SkillBonus" tag="skCarbine"/>
<autotag group="SkillBonus" tag="skDodge"/>
<!-- If I were to spell out the combat options, this would be longer, but I'd prefer to pull in all skills tagged with skCombat -->
<autotag group="explicit" tag="2"/>
</bootstrap>
</thing>

The intent is to have immediate +2 Skill Bonuses to Dodge and History, add a History (Religion) Specialty, and then allow the user to select between adding +2 to Inspire or Perform, and then +2 to any one Combat skill. The specialty is currently handled by directly adding the Thing via a bootstrap. The single skill bonuses are using Tag to add a tag and the choice between two skills is handled via bootstrapping a Thing which has a series of Autotags for the choices (which eventually add SkillBonuses). The relevant bits (I think):

<thing
id="fRPlusSk"
name="+2 to Skill"
compset="SkillBonus"
description="Gives a +2 bonus to the selected skill.">
<fieldval field="usrCandid1" value="component.Skill"/>
<tag group="Hide" tag="Special"/>
<eval index="1" phase="PreTraits" priority="5000">
<before name="Calc trtFinal"/><![CDATA[
~build the candidate expression out of our SkillBonus tags
if (tagis[SkillBonus.?] <> 0) then
field[usrCandid1].text &= " & (" & tagids[SkillBonus.?, " | "] & ")"
endif

perform field[usrChosen1].chosen.field[trtBG].modify[+,2,"Background"]
]]></eval>
</thing>

<!-- BGTrait - all background traits — backgrounds, command packages, and races —
derive from this to provide common properties -->
<component
id="BGTrait"
name="Background trait"
autocompset="no"
panellink="basics">
<eval index="1" phase="Setup" priority="3000" name="BG tag final">
<before name="Size final"/><![CDATA[
var expr as string
if (tagis[SkillBonus.?] <> 0) then
expr = tagids[SkillBonus.?, " | "]
foreach pick in hero from Skill where expr
perform eachpick.field[trtBG].modify[+,2,""]
nexteach
endif
]]></eval>
</component>

I know one way of looking at things is that "If it works, that's fine", but a) it bothers me having what seems to be three different ways of doing this (and might need a fourth) and b) Right now, my attempt to provide all of the Skill Bonuses from race, background, and command packages in a table is failing because only the +2 Choice ones are showing up despite what I think should be working by showing all SkillBonuses:

<!-- Skill Bonus portal. Used to list skill bonuses from backgrounds, races, and
command packages, and to allow for choices. -->
<portal
id="skBonuses"
style="tblInvis"
width="240">
<table_fixed
component="UserSelect"
showtemplate="MenuSlPick"
showsortset="explicit"
alwaysupdate="yes">
<list><![CDATA[
(!User.NeedChosen | Helper.ChosenOpt)
]]></list>
<headertitle><![CDATA[
@text = "Skill Bonuses"
]]></headertitle>
</table_fixed>
</portal>

<template
id="MenuSlPick"
name="Configurable Pick"
compset="UserSelect"
marginhorz="5"
marginvert="3">

<portal
id="name"
style="lblLeft"
showinvalid="yes">
<label
ismultiline="yes"
field="name">
</label>
</portal>

<portal
id="thinglist"
style="menuSmall">
<menu_things
field="usrChosen1"
component="none"
candidatefield="usrCandid1"
usepicksfield="usrSource1"
maxvisible="10"
sortset="explicit">
</menu_things>
</portal>

<position><![CDATA[
~set up our height; our width is pre-initialized for us
height = portal[thinglist].height

~if this is a "sizing" calculation, we're done
doneif (issizing <> 0)

~position our tallest portal at the top
portal[thinglist].top = 0

~center the other portals on the tallest one
perform portal[name].centeron[vert,thinglist]

portal[name].left = 0
portal[name].width = 100

portal[thinglist].left = portal[name].right + 3
portal[thinglist].width = width - portal[name].width - 3
]]></position>

</template>

TL;DR: Is there a good standard way to handle all of these in a fairly common way? And how do I get these things to show up in the table of adjustments? Am I best off having multiple tables one after the other, for each of the items? This is one of those things where it seems to just work in 4E files, but that might be because the same name is often used for Tags, Things, Templates, etc, which makes it tricky to trace.

 

[RavenX]

if (tagis[SkillBonus.?] <> 0) then
expr = tagids[SkillBonus.?, " | "]
foreach pick in hero from Skill where expr
perform eachpick.field[trtBG].modify[COLOR="Red"][B][+,2,""][/B][/COLOR]
nexteach
endif

The line of code I've outlined in red is why your only seeing a +2 bonus applied. You're telling the software that for any SkillBonus tag it should apply a +2 bonus via the modify part of this script. If you are using the SkillBonus tag group to determine the value of the bonus, you need to rig it up to apply the proper bonus.

Also, the foreach loop might not even be necessary, you could rig this in an eval script on the skills component and cut the foreach loop out of the equation completely.

For example, using if () then statements to cycle through your tags...

If (tagis[SkillBonus.1] <> 0) then
perform eachpick.field[trtBG].modify[+,1,""]
elseif (tagis[SkillBonus.2] <> 0) then
perform eachpick.field[trtBG].modify[+,2,""]
endif

You can cycle through all your Skill Bonus tags, telling hero lab to apply the bonus based on the presence of a specific tag within your foreach statement. This should fix the issue of only applying a +2 bonus.

Also, the foreach loop is possibly completely unnecessary. If you rig hero lab to forward SkillBonus tags to the skills themselves you can have an eval script on your skill component that does all the trait modifications without needing that foreach loop.

You can do this by rigging a skill linkage and having your background traits establish the linkage. Then in an eval script use linkage[basis].setfocus and perform focus.assign[SkillBonus.X] to the skill directly...

 

[Duggan]

Ah. I was slightly unclear. The problem isn't that they're all +2, but that only the fRPlusSk items are showing up on the skBonuses table.

Ultimately, part of the problem, I think, is that I'm still not really clear on what's being added where to make this all work. ^_^ Like I think it's saying that there's a SkillBonus tag, but I never defined such a tag. Or is that what autotag does?

 

[Mathias]

You're throwing large blocks of code out, but I can't see where you've described the game rules you're trying to implement.

 

[Duggan]

What I'm trying to implement is in the first code block and the following text. The Chaplain package offers :

• +2 Skill Bonuses to Dodge and History
• a History (Religion) Specialty
• +2 to either Inspire or Perform
• +2 to any one Combat skill

Right now, the +2 Skill bonus to Dodge and History work (but don't show up in my list). The specialty works as-is, but I can't get it implemented in the Editor so far (most examples using Tags). The choice between Inspire and Perform works for the most part (there are some odd glitches when the change cross the min-max border as documented in one of my other posts) and show up. And I'm still puzzling out a good way to set up the +2 to a combat skill so that I don't have to spell out the choices.

I basically have two questions:
1) What is the difference between "tag" and "autotag"? Does autotag create the tag in question before adding it?
2) Why isn't the skBonuses table showing the Dodge and History items?

 

[Mathias]

When assigning a tag to a thing, the element is called <tag>. When assigning a tag to a bootstrap, the element is called <autotag>. Behind the scenes, things are being handled in different ways, but to the user, there's not much difference - the tag gets assigned to that pick once the pick is added to the character.

Can I see the identity tags you've defined for your skills component?

 

[Duggan]

Certainly.

<group
id="Skill"
dynamic="yes">
<value id="skCarbine" name="Carbines"/>
<value id="skDodge" name="Dodge"/>
<value id="skExplsves" name="Explosives"/>
<value id="skHvyWeap" name="Heavy Weapons"/>
<value id="skLongGun" name="Long Gun"/>
<value id="skMelee" name="Melee"/>
<value id="skPistol" name="Pistols"/>
<value id="skScatter" name="Scatterguns"/>
<value id="skStaWeap" name="Stationed Weapons"/>
<value id="skThrown" name="Thrown Weapons"/>
<value id="skChem" name="Chemistry"/>
<value id="skCompute" name="Computers"/>
<value id="skEcon" name="Economics"/>
<value id="skEng" name="Engineering"/>
<value id="skExpSci" name="Experimental Sciences"/>
<value id="skHistory" name="History"/>
<value id="skInsight" name="Insight"/>
<value id="skMech" name="Mechanic"/>
<value id="skMedic" name="Medicine"/>
<value id="skRes" name="Research"/>
<value id="skXeno" name="Xenobiology"/>
<value id="skAirVeh" name="Air Vehicles"/>
<value id="skAthlete" name="Athletics"/>
<value id="skEndure" name="Endurance"/>
<value id="skGrndVeh" name="Ground Vehicles"/>
<value id="skLarceny" name="Larceny"/>
<value id="skPercept" name="Perception"/>
<value id="skSpcVeh" name="Space Vehicles"/>
<value id="skStealth" name="Stealth"/>
<value id="skWatVeh" name="Water Vehicles"/>
<value id="skContract" name="Contracts"/>
<value id="skDeceive" name="Deceive"/>
<value id="skEmpathy" name="Empathy"/>
<value id="skInspire" name="Inspire"/>
<value id="skIntim" name="Intimidate"/>
<value id="skNegot" name="Negotiate"/>
<value id="skPerform" name="Perform"/>
<value id="skWillpow" name="Willpower"/>
</group>

Unless you mean the identity elements in the Skill, in which case they are the following:

<!-- Each skill needs its own identity tag so existing skills can be identified during advancement -->
<identity group="Skill"/>

<!-- Each skill can also be selected as a background/command package/race bonus.
This bonus does count against the maximum at character creation. -->
<identity group="SkillBonus"/>

 

[Mathias]

I meant the second of those.

There should not be a group named Skill in tags.1st - you're defining all those tags as identity tags on the component, so having it in tags.1st, too is redundant.

If you've got an identity tag of SkillBonus on the skills component, I see no reason these scripts should be failing.

Time to start adding debug lines and figure out what's going on in your script.

 

[Duggan]

Thank you. I hadn't found the page about debug statements before now.

 

[Duggan]

And <identity> is a tag in and of itself... suddenly a bunch of things start to make more sense.

 

[Mathias]

<identity> defines a new tag group - each thing defined for that compset will get a tag from that group, where the group Id is the <identity>, the tag ID is its own unique Id, and the tag name is its own name.

 

[Duggan]

And I got the code working for allowing a user to choose to choose any skill of a particular type (in case, allowing the military backgrounds to implement the "+2 to any Combat skill").

Is there any easy to ensure that added bootstraps get an explicit order tag?

 

[RavenX]

And I got the code working for allowing a user to choose to choose any skill of a particular type (in case, allowing the military backgrounds to implement the "+2 to any Combat skill").

Is there any easy to ensure that added bootstraps get an explicit order tag?

I think you'd have to put the explicit.x tags on the things, then go into your control file and rig up a sortset to use explicit (there should be an example of it in the control file's predefined sortsets). Make sure your display table is using that sortset on showsortset or choosesortset though.

 

[Duggan]

{nods} I have those explicit tags on the code I'm writing. I guess I was wondering if there's any way to make sure they get added for new items added via the editor. If not, that's cool.

 

[Mathias]

Is the order of the bootstraps in the book, that you're trying to match not alphabetical? Or is it that there's a sorting order that applies to things added as a bootstrap, but not the rest of the things added to that same table, so you can't use a sortset on the table itself?

 

[Duggan]

Is the order of the bootstraps in the book, that you're trying to match not alphabetical? Or is it that there's a sorting order that applies to things added as a bootstrap, but not the rest of the things added to that same table, so you can't use a sortset on the table itself?

Honestly, I mainly just don't want the items to move around as I select values. The default sort is alphabetical, so if I have:

• +2 to Skill: ________
• +2 to Skill: Deceive

And I set the unfilled skill to Engineering, I suddenly get this:

• +2 to Skill: Deceive
• +2 to Skill: Engineering

I mean, it's not a huge thing, but it also sounds like the sort of thing you've probably solved a dozen times over.

 

[Mathias]

Option 1: turn OFF alwaysupdate="yes" - then, the table will only get re-ordered when a new pick is added to the table, or if the view is created again from scratch (which happens if you use the print preview and then go back to the regular HL window), or when you reload the character. But, if these are bootstraps, and this isn't the same table their root pick is being added to, the bootstraps may not even show on the table without alwaysupdate.

Option 2: Use a shortname for the abilities, and set up a sort order for that table that's based on the shortname, not the name. The shortnames should be set up to always be named "+2 to Deceive or Engineering", and not change based on the selection. Make sure not to use _Name_ as a sorting element in that sortorder, so that when the name changes, that doesn't alter that order.

Option 3 is the explicit tags.

We normally just put multiple selections that derive from the same thing in the same ability, not on separate abilities, so this isn't normally something we run into.

 

[Duggan]

And, with a little fiddling, I verified that I'm using two different SkillBonus items here. One is the tag (which is basically just the Skill itself), bootstrapped to the player and added as part of the BGTrait component. The other is the compset item, which directly modifies the field in the thing that is bootstrapped in. That explains why I was having difficulty attaching a value to the SkillBonus tag. Namely, it wasn't actually a tag.

All of this leaves me a little better informed, but still a bit at sea on how to make this all work like I want it to. Ah, learning...