• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Link pick to a tab?

TCArknight

Well-known member
Back with yet another question. :)

I have an ability chosen from a table_dynamic portal which is now a pick on the hero.

Is there a way to link this chosen pick to the tab so that other portals on the tab can access it's fields, values, etc easily?

For example:
Component S has four fields value1, value2, field3 and field 4 along with it's description.

the tab's panel has a table_dynamic portal, a label portal (info) and two more table_dynamic portals whose number of choices should come from Component S in value1 and value2 fields. The displayed header title for these should be based on field3 and field4

Would childfound take a string variable containing the idstring of the pick or am I stuck with doing foreach pick since there is only to be 1 of Component S on the hero at a time..?

Thanks!
TC
 
Last edited:
Are you using an agent tab? That would give you that kind of access directly to the chosen pick, the way custom class abilities in Pathfinder can access the class they're linked to with linkage
.

Other than that, there aren't any quick reference methods, other than setting a focus at the beginning of each script that needs it.
 
Mathias,

The agent tab looks like what would be needed. I had completely forgotten about that!

Currently, the situation is:
1) Each hero can have a 'Magic' advantage, and the type of sorcery used is dependent on what region they are from. If you're from X, you can use MagicX but if you're from Y, you can use MagicY instead. By selecting this advantage, the "Magic.Magic" tag gets placed on the hero indicating their ability to use magic. This tag also forces the delete of the HideTab.magic tag, thus revealing the Magic tab.

2) I have it set up for the hero to choose a Magic on a dynamic table. Each Region has forwarded a "Region.X" identity tag to the hero already, so with each Magic tagged with the matching Region tag, I use a needtag element on the table so only 1 Magic is available to select.

Should the appropriate Magic be bootstrapped to the Hero with the Region selection and just nothing done with it unless the hero also has the "Magic.Magic" tag?

3) The chosen Magic (MagicX for example) forwards the identity tag "HasMagic.MagicX" to the hero.

Using the agent tab though, the panel should look like:
Code:
!-- Magic panel -->
<panel
  id="Magic"
  name="Magic"
  order="150"
  marginhorz="5"
  marginvert="5"
  agentcompset="Magic"
  agentlive="HasMagic"
  agentname="name">

Then in other portals on the tab, I would be able to use a agent.field[field3].text to get the content of field3 on the appropriate Magic, correct?
 
Sorry Mathias, I guess I got a bit long-winded.

Assuming the component to be displayed is compset.Magic, and that will forward the identity tag "HasMagic.Xxx" when the hero also has the "Magic.Magic" tag indicating the ability to use magic.

The panel I listed will allow for agent.xxx transitions?

Also any portals on the panel will need the useagentlinkage="yes" entry, correct? Are there any other agent tags that are not optional for the portals on the tab?
 
The transition from a pick to the pick of its agent tab is not agent. - it's linkage
.

What does your 4th line mean? The first sentence talks about a table setting, but the second sentence talks about agent tags, but they seem to be talking about the same thing.
 
If I'm doing the titlebar for a dynamic table on the portal, I don't use this (from your example here - http://forums.wolflair.com/showpost.php?p=169519&postcount=3)
<titlebar><![CDATA[
@text = "Choose your " & lowercase(agent.field[cSpBkName].text) & " " & lowercase(agent.field[cSpellName].text) & "."
]]></titlebar>

I'd use this instead?
<titlebar><![CDATA[
@text = "Choose your " & lowercase(linkage
.field[cSpBkName].text) & " " & lowercase(linkage
.field[cSpellName].text) & "."
]]></titlebar>

My bad, not tags, but elements? Like the useagentadd, useagentcandidate, agentlist, agentautotag ones on that table...

Is the usage of these documented anywhere else or have they come up in other forum threads?
 
PLEASE be more specific about what type of script you are trying to write. I did not know you were writing a titlebar script, where agent. is the correct answer. I thought you were writing eval scripts on the picks being added to these tables, where linkage
is how you get to the agent pick.

Here's a thread about agent tabs: http://forums.wolflair.com/showthread.php?t=46548&highlight=agent

There isn't any real documentation about agent tabs.
 
I Apologize, I didn't realize there was a difference in how the transition was handled between the titlebar script and the regular eval scripts.

For the tab, I'm looking at 3 portals, 1 label to show the description of he magic, and two dynamic tables (minor magic and major magic). Would the correct transition for the label text be agent.field[descript].text since it's not an eval script?

For the Minor/Major tables, each ability would be tagged with MinorMag.X and MajorMag.X which would be identity tags from the Magic component. Would this be a useagentCandidate or simply a needtag with the container set to the agent?
 
http://hlkitwiki.wolflair.com/index.php5?title=TitleBar_Script

The initial context of a titlebar script is the container, so in most cases, that's the hero. So, in that case, there's a different transition than you'd use if you were starting in a pick context.

If you want to show portals on the agent tab, create a template and place it on the tab. Then, the template is set to use the agent pick, so the portals inside that template are already in the context of the agent pick, so they can just use field="", instead of <labeltext> (unless you want more complicated text, in which case you can just use field[descript].text or whatever with no need to transition anywhere).

<templateref template="cTitle" useagent="yes"/>

So for this other question, what you're trying to implement is that each pick that can create one of these agent tabs has some abilities that can only be chosen for that pick, right?

needtag won't work, because agent picks are not containers, so you can't set the needtag to a container that doesn't exist. You'll need to set up a candidate field on these picks that's linked to by useagentcandidate, and then have a script on the pick write that candidate expression so that it only allows the correct set of abilities.
 
THanks! Mostly working. However, I'm running into an error when I try adding the first of the table_dynamic to the template. I get
Syntax error in 'titlebar' script for Template 'soSorTemp' (in Portal 'soMinor') on line 2
-> Invalid use of a reserved word in script

If I change the titlebar to agent.field[sMinName].text then I get:
Template 'soSorTemp' - Reference to portal 'soMinor' that can only be used within a layout

Here's my tab:
Code:
  <template
    id="soSorTemp"
    name="Sorcery Template"
    compset="Sorcery"
    marginhorz="3"
    marginvert="2">

    <portal
      id="soSorTitle"
      style="lblTitle">
      <label>
        <labeltext><![CDATA[
          @text = "Description"
          ]]></labeltext>
        </label>
      </portal>
      
    <portal
      id="soSorDesc"
      style="lblBrdLeft">
      <label
        field="descript"
        ismultiline="yes">
        </label>
      </portal>

    <portal
      id="soMinor"
      style="tblNormal">
      <table_dynamic
        component="Power"
        showtemplate="SimpleItem"
        choosetemplate="SimpleItem"
        useagentadd="yes"
        useagentcandidate="yes"
        useagentlinkage="yes"
        candidatefield="sPwrExpr">
        <titlebar><![CDATA[
          @text = "Add a Minor " & field[sMinName].text
          ]]></titlebar>
        <description/>
        <headertitle><![CDATA[
          @text = "Minor: " & field[sMinName].text & "(" & field[sMaxMinor].text & ")"
          ]]></headertitle>
        <additem><![CDATA[
          @text &= "Add New Minor " & field[sMinName].text
          ]]></additem>
        </table_dynamic>
      </portal>
          
    <position><![CDATA[
      ~set up our dimensions, with a width that we dictate; our width can vary
      portal[soSorTitle].height = 20
      portal[soSorDesc].height = height/3
      portal[soMinor].height = height/3

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

      ~position the description on the left and let it use all available space
      portal[soSorTitle].top = 0
      portal[soSorTitle].left = 0
      portal[soSorTitle].width = width
      portal[soSorDesc].top = portal[soSorTitle].bottom + 2
      portal[soSorDesc].left = portal[soSorTitle].left
      portal[soSorDesc].width = portal[soSorTitle].width
      portal[soMinor].top = portal[soSorDesc].bottom + 10
      portal[soMinor].left = portal[soSorDesc].left
      portal[soMinor].width = (portal[soSorDesc].width/2) - 5
      
      ]]></position>

    </template>
                   
  <!-- sorcery layout
        This layout orchestrates the display of the visual elements that comprise
        the Skills tab. This amounts to a title at the top and a dynamic table below
        where the user can add and adjust the skills he wants.

        The logic for this layout is similar to (albeit much simpler than) the
        logic for the Basics tab. So please refer to the Basics tab for more details.
  -->
  <layout
    id="sorcery">
    <templateref template="soSorTemp" useagent="yes"/>

    <!-- This script sizes and positions the layout and its child visual elements. -->
    <position><![CDATA[
      ~freeze our skills table in advancement mode to disable adding new choices
      ~Note: All freezing must be done *before* any positioning is performed.
      ~if (state.iscreate = 0) then
      ~  template[soSorTemp].freeze = 1
      ~  endif

      ~both tables span the full width
      template[soSorTemp].width = width
      
      template[soSorTemp].visible = hero.tagis[Sorcery.Sorcery]
      
      perform template[soSorTemp].autoplace[0]

      ]]></position>

    </layout>

  <!-- sorcery panel
        This is the "Sorcery" panel shown within Hero Lab.
  -->
  <panel
    id="sorcery"
    name="Sorcery"
    marginhorz="5"
    marginvert="5"
    order="155"
    agentcompset="Sorcery"
    agentlive="HasSorc"
    agentname="name"
    >
    <live>!HideTab.sorcery</live>
    <layoutref layout="sorcery"/>
    <position><![CDATA[
      ]]></position>
    </panel>

am I missing something with the agent?
 
You may not put a table_dynamic inside a template - only on the tab itself. So both your table and your template will be entries on your tab's layout, with the table separate from the template.
 
That did it, thank you! :)

Every time I reload, since I've gone from the chooser to the agent tab I'm getting a message about the Magic being orphaned. I'll probably rebuild the test character from scratch to see if it's a true issue or just something with the reloading, etc..
 
Yes, if the table/chooser something was added to no longer exists, that pick is permanently orphaned. You'll find that you'll end up discarding a few test characters over the course of creating a game system.
 
Back
Top