Lone Wolf Development Forums  

Go Back   Lone Wolf Development Forums > Hero Lab Forums > HL - Authoring Kit

Notices

Reply
 
Thread Tools Display Modes
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 13th, 2017, 05:40 AM
I am replacing a menu_things with a chooser_table to leverage the choice actually being added as a pick (specifically, I want a particular character Background to allow the choice of a Skill Specialty). Previously, I used "candidatefield" on the menu_things to make it easy to build a list of choices to be stored in a field, something like "component.Specialty & (Specialty.spEngArch | Specialty.spEngVeh)" to restrict the choice to either the Architecture or Vehicle specialty of Engineering.

When I try to use that, I get a message saying that candidatepick has to be specified as well. Looking at the code examples I have where that is used, it always seems to be tied to a gizmo. Is there a way to tell it to just look at a field on the UserSelect? Or is there a way to tell the candidate child element to draw its contents from a field?

Code:
<portal
  id="specChoose"
  style="chsNormal">
  <chooser_table
    component="Specialty"
    choosetemplate="SpecPick3"
    candidatefield="userCandid2">
    <chosen><![CDATA[
      if (@ispick = 0) then
        @text = "{text clrwarning}Select Specialty"
      else
        @text = field[name].text
        endif
      ]]></chosen>
    <titlebar><![CDATA[
      @text = "Choose a specialty"
      ]]></titlebar>
    </chooser_table>
  </portal>
Duggan is offline   #1 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 12,236

Old December 13th, 2017, 09:30 AM
So all you've told HL is hero.child[?].field[userCandid2].text - it needs to know what pick to look up that field on. That's what the candidatepick="" is for.

Or do you mean that this is a table within a gizmo? If that's the case, search this forum for where I've explained the use of "agent" transitions and controls to others.
Mathias is online now   #2 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 13th, 2017, 12:55 PM
I'm an idiot. I added a gizmo to this so that it would have something to hook onto. I re-used the SpecHelp that I used for the Specialty. It sets correctly, as per the debug statement, but setting that chooser_table's candidatepick to "SpecHelp" and candidatefield to "SpecExpr" still doesn't restrict the pick.

Code:
<thing
  id="fRPlusSp"
  name="Bonus Specialty"
  compset="cmpsetSB"
  description="Adds the selected specialty.">
  <fieldval field="usrCandid2" value="component.Specialty"/>
  <tag group="Hide" tag="Special"/>
  <eval index="1" phase="PreTraits" priority="4900">
    <before name="Calc trtFinal"/><![CDATA[
    ~build the candidate expression out of our specialty tags
    var specs as string
    specs = tagids[Specialty.?, " | "]
    var skills as string
    skills = tagids[Skill.?, " | "]

    var combined as string
    if (tagis[Skill.?] <> 0) then
      if (tagis[Specialty.?] <> 0) then
        combined = skills & " | " & specs
      else
        combined = skills
      endif
    else
      combined = specs
    endif

    debug "combined: " & combined
    gizmo.childfound[SpecHelp].field[SpecExpr].text = combined
    ]]></eval>
  
  <child entity="entSpec" />
  </thing>
For example, I have it set to "Specialty.spEngArch | Specialty.spPistBeam" according to the debug statement, but it still displays all of the items.

Putting that same string inside a candidate element does work. Is there a way to simply set it programmatically there?

Ok... and I'm definitely doing something wrong. If I add two fRPlusSp items (to allow the user to pick two Specialties), changing one changes both of them. *sigh* Back to the drawing board...

Last edited by Duggan; December 13th, 2017 at 02:16 PM.
Duggan is offline   #3 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 13th, 2017, 02:12 PM
Hmm... and I may have other problems. When I switch backgrounds, the chosen specialty sticks, showing a source of SpecChoose, the chooser_table I'm using above. If I switch the background back to the one I'm testing that allows a Specialty choice, it's back and already chosen. I know I have a bit of a tendency to put up walls of code. Which parts would help you the most to know?
Duggan is offline   #4 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 18th, 2017, 04:29 AM
I have a glimmer of an idea that it might be because I was adding a single entity for all instances of fRPlusSp instead of assigning it any time it's defined in the editor for a given background, but I'm not certain how I would do that, since it's a thing bootstrapped onto another thing.

For example, here a very simplified background that offers a choice of one of three skill specialties:
Code:
<thing id="bckTestBG" name="Test BG" compset="Bckgrnd" uniqueness="unique">
  <bootstrap thing="fRPlusSp">
    <autotag group="Specialty" tag="spEngArch"/>
    <autotag group="Specialty" tag="spHvyBeam"/>
    <autotag group="Specialty" tag="spPistBeam"/>
    </bootstrap>
  </thing>
I can't seem to add a child inside of the bootstrap element. So maybe putting it in the fRPlusSp thing is fine? But if so, how do I get each one to have their own entity so that they're not all selecting the same thing?

Last edited by Duggan; December 18th, 2017 at 04:38 AM.
Duggan is offline   #5 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 18th, 2017, 03:56 PM
And indeed, the picks aren't being added to the gizmo, but to the specChoose portal, which also, I guess, explains why it isn't going away when I change backgrounds, and might also explain why changing one specChoose changes them all.
Duggan is offline   #6 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,166

Old December 25th, 2017, 09:31 AM
Hmmm... looking back through this post, I'm seeing if there's a way to insert this through the editor in an effort to figure out the code. Using the "defchild" attribute doesn't seem to put it in the right place. "target" seems like it makes sense on the sub-element (the fRPlusSp) but when I tried doing that, I got a message that "default entity is required if an input thing with an entity target is specified." I don't know if that means I wrote it wrong, and it's an undocumented element.

Quote:
Hero Lab was forced to stop compilation after the following errors were detected:

Edit Thing 'Bckgrnd' - A default entity is required if an input thing with an entity target is specified.
Edit Thing 'CmdPckge' - A default entity is required if an input thing with an entity target is specified.
Edit Thing 'Race' - A default entity is required if an input thing with an entity target is specified.
Code:
<it_bootcustom compset="cmpsetSB" target="child">
Duggan is offline   #7 Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 06:40 AM.


Powered by vBulletin® - Copyright ©2000 - 2018, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.