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,502

Old December 31st, 2019, 09:12 AM
This is my code for a chooser-table to pick Specialties that match a given entry's tags. I thought I understood needtag, but apparently not. The skill choice has a tag of Skill.skMech (which refers to the Mechanic skill) and no other Skill tags. There are three specialties that have the Skill.skMech. And yet, when I bring up the chooser table, it has all of the specialties. I thought that, with useHero not being set, it would look for all Specialities that match the skill choice thing.

Code:
<portal
  id="specChoose"
  style="chsNormal">
  <chooser_table
    component="Specialty"
    choosetemplate="LargeItem"
    choosepicks="thing"
    >
    <needtag container="Skill" thing="Skill"/>
    <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>
Am I missing something obvious? Or is there a good way to debug why this is happening?
Duggan is offline   #1 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 13,207

Old December 31st, 2019, 09:28 AM
This is a table within the gizmo of that skill?

So be careful as to whether the Skill pick is on the skjill pick itself or the container within the skill - in order for needtag to work, you have to have the tag in the container within the skill - no-where else will be checked. In the debugs, when debugging the skill's tags, scroll down a bit, and there are two more headers to look for in the list - "Gizmo Tags" and "Global Tags".

Here's Shadowrun's script to set up a needtag for skill specialties:


Code:
    <eval index="10" phase="Initialize" priority="10000"><![CDATA[
      ~copy our SkillList tags to the gizmo so they can be used for the needtag
      if (isgizmo <> 0) then
        perform gizmo.pushtags[SkillList.?]

        ~tags added to the gizmo are then automatically added to the parent of
        ~that gizmo - but that's where those tags were just pushed from, meaning
        ~that what happens is to duplicate them all.  So, delete the ones on
        ~ourself, then pull the tags from the gizmo.
        perform delete[SkillList.?]
        perform gizmo.pulltags[SkillList.?]
        endif
      ]]></eval>
Mathias is online now   #2 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,502

Old December 31st, 2019, 11:28 AM
Ah, this actually isn't using any gizmos at the moment. On the tab_basic page, the player can choose a background. One of the backgrounds allow them to pick a skill specialty associated with the Mechanics skill, so it bootstraps a pick of the following, which has the Skill.SkMech tag added to it:

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"/>
  <tag group="ChooseSrc2" tag="Thing"/>
  <eval index="1" phase="PreTraits" priority="900">
    <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

    field[usrCandid2].text &= " & (" & combined & ")"
    ]]></eval>
  
  </thing>
When listing the various bonuses I display the chooser table excerpted above if if the usrCandid2 field is filled out (which it actually has a condition in there, which was originally how I was trying to make this work).

So the idea is that the "fRPlusSp" bootstrapped onto the Mechanic background has the Skill.skMech tag, as do the specialties such as "Jury-Rig", and I thought I could use <needtag> to tie them together. Or would it make more sense to set up a candidatepick and maybe a candidatefield to instead do the picking? When I looked into that, it seemed kind of complicated, particularly since I really only need the field value (which I can grab from usrCandid2) and the candidatepick seemed almost like adding a gizmo to it.

That said, I've also realized that I've done this before, and similarly had issues where the Background gets changed, and the hero retains the Specialty pick. I vaguely remember there being a way to ensure such picks get deleted when the base object is, but
Duggan is offline   #3 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 13,207

Old December 31st, 2019, 12:17 PM
The problem with needtag, if you're not using gizmos is - what if you have more than one thing that provides a selection of specialties, but each one allows a choice from different lists? If all the tables are on the hero container, then all the tags are in the same place.

I'd think about what your game system needs to do with these specialties - list out every way that a character could get a speciality, and then from that list, figure out what's the best way to set up how the specialties will be defined.
Mathias is online now   #4 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,502

Old December 31st, 2019, 03:08 PM
Quote:
I'd think about what your game system needs to do with these specialties - list out every way that a character could get a speciality, and then from that list, figure out what's the best way to set up how the specialties will be defined.
Ah. Well, there are basically four ways.
  1. One way is to gain them by by your Background, Command Package, or Sophont Type, all of which fall under background info that are chosen when first creating the character, and are basically treated as the same, a Thing with bootstrapped adjustments.
    • One method gives a fixed value. That's working right now.
    • Slightly lower priority, since it's only come up in user datasets, is allowing the player to choose from a list that are constrained by Skill or SkillType tags on that bootstrap.
  2. By selecting them off of a list associated with a skill (currently done by clicking on a button by the skill name in the relevant tab). This works.
  3. Through an Advancement (basically, gaining a level). This works, although I see now that I need to tweak the list for Specialities the character already has (since they're unique)
  4. Through in-game adjustments (there are cards that add or remove Specialties). I haven't gotten that working yet.

Only Number 2 costs character build points, which so far I have working. Honestly, if I can get Number 4, in-game adjustments, working, I'll be satisfied for it being close enough.

I'm still figuring out how to code things properly here, but I feel like Backgrounds, Advancements, and Adjustments should carry their individual Specialties so that they can be removed if the corresponding item is (although honestly, it doesn't seem like that would happen all that often). Currently, the method of choosing them corresponding to skill (Number 2 above) adds the specialty to the skill and then I think then then get Forwarded to the Hero. I know that deleting the corresponding Advancement removes the Specialty again. Removing a Background removes the fixed value Specialties (the ones bootstrapped to it), but not the ones I have being chosen right now.

And honestly, I have no idea how to properly handle removing Specialties. Based on the Savage Worlds coding, it looks like the best method allows some value to be edited as to the number of Specialties allowable, and then simply allow them to be editable outside of creation. So they'd add an Adjustment to reduce the number of skills (raising a validation error) and would then go in and remove those specialties. Which... hmmm... could interact oddly with items bootstrapped from the background or from Advancement.

Quote:
The problem with needtag, if you're not using gizmos is - what if you have more than one thing that provides a selection of specialties, but each one allows a choice from different lists? If all the tables are on the hero container, then all the tags are in the same place.
So far, when I've had choices, I've had the Background Thing (which could be a Background, Command Package, or Sophont Type), which has bootstrapped items to provide things like skill bonuses, so each of those are the ones that have the tags that need to be compared against. So I should be able to test each one separately for which values are valid, although that might bump up against what Specialties the player already has through other Backgrounds or if they buy them up on the skill screen before changing their Background.

Incidentally, thank you for responding today. I know some people are off work for New Years Eve.
Duggan is offline   #5 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 13,207

Old December 31st, 2019, 03:36 PM
So it sounds like you'll want to set up agent tables for the background things - even if the majority of them grant a fixed skill specialty, it sounds like there are several that allow a choice by the user from a list that's only part of the entire list of specialties in the game. That'll mean that the specialty you chose for one of your background elements gets cleaned up if you change your mind on which background to add for that category. The hassle there is that it means that each background element will end up having its own tab. The alternative would be to use gizmos and shadowing - more complex, but do-able - what it would look like to the user is that they'd click an edit button to open a form, and then select the specialty for that background on the pop-up form. That's how SR5 handles its lifestyle modules.


So how permanent are these specialty removals, and how permanent are the additions from cards? And if you get one removed, can you then replace it with something else?


Since you have a mix of specialties chosen by the user in tables and specialties that are bootstrapped as a fixed choice from a background, plus ones gained as advancements, I don't think having the user actually delete the specialty pick is the right solution, and I'm not sure what Savage Worlds is doing - what you explained doesn't sound like a good solution. I think the best option here is a tag that gets assigned to the removed specialties, which is then checked by the list expressions in the various tables where specialties are displayed, and any tagged specialties are skipped. Then, in the original table where the specialty was added, instead of hiding it, you use the position script for that template to change the styles, and make it look disabled. The result will be that when the user looks at their summary panels or printed character sheet, the removed specialties will not be shown.


The company holidays are only Christmas day and New Years day, and this year, I only decided to use my time off for the days before and after Christmas. So I'll be signing off in about half an hour and then I'll be back on Thursday.
Mathias is online now   #6 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,502

Old December 31st, 2019, 04:09 PM
Quote:
Originally Posted by Mathias View Post
So it sounds like you'll want to set up agent tables for the background things - even if the majority of them grant a fixed skill specialty, it sounds like there are several that allow a choice by the user from a list that's only part of the entire list of specialties in the game. That'll mean that the specialty you chose for one of your background elements gets cleaned up if you change your mind on which background to add for that category. The hassle there is that it means that each background element will end up having its own tab. The alternative would be to use gizmos and shadowing - more complex, but do-able - what it would look like to the user is that they'd click an edit button to open a form, and then select the specialty for that background on the pop-up form. That's how SR5 handles its lifestyle modules.
Hmm... So one for Sophont Type, one for Background, one for Command Package? That doesn't really fit in with how I'd like things to work, but it could be workable. I guess I'd use the additional space to provide descriptive text and/or an image.

I'm guessing that the form would probably work a lot like the existing gizmo I have to pick Specialties (is it just me, or is it hard to not spell that as "speciality"? I know the Savage World files have that spelling problem) for each skill?

Quote:
So how permanent are these specialty removals, and how permanent are the additions from cards? And if you get one removed, can you then replace it with something else?
Almost all of the changes are permanent. There are a few cases of temporary skill bonuses or penalties, but I figure most GCs can just make their own notes. I'm building this more for building and storing characters. Honestly, I'm half tempted to just leave skills and specialties modifiable when not in Character Creation and let players handle themselves. In an ideal world, I'd tag it into the current Journal entry so that there's a history of changes, but that's a stretch goal kind of thing. And I think I'd have to modify the form to show and hide the incrementers so that they properly handle the lack of limits after creation.

Quote:
Since you have a mix of specialties chosen by the user in tables and specialties that are bootstrapped as a fixed choice from a background, plus ones gained as advancements, I don't think having the user actually delete the specialty pick is the right solution, and I'm not sure what Savage Worlds is doing - what you explained doesn't sound like a good solution. I think the best option here is a tag that gets assigned to the removed specialties, which is then checked by the list expressions in the various tables where specialties are displayed, and any tagged specialties are skipped. Then, in the original table where the specialty was added, instead of hiding it, you use the position script for that template to change the styles, and make it look disabled. The result will be that when the user looks at their summary panels or printed character sheet, the removed specialties will not be shown.
Hmm... and I'm guessing that the "deleted" ones would then be reavailable for adding, and would instead clear the tag. Were it not for that there are a few non-unique Specialities, I'd be tempted to just start adding all Specialties to all characters and just mark them as not picked just yet.

Quote:
The company holidays are only Christmas day and New Years day, and this year, I only decided to use my time off for the days before and after Christmas. So I'll be signing off in about half an hour and then I'll be back on Thursday.
Regardless, thank you for your help. Over two years I've been plugging at this off and on...
Duggan is offline   #7 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,502

Old January 1st, 2020, 10:38 AM
Heh, and searching for "agent tables", this isn't the first time I've asked this question. Two years ago...
Duggan is offline   #8 Reply With Quote
Duggan
Senior Member
Volunteer Data File Contributor
 
Join Date: Nov 2009
Posts: 1,502

Old April 4th, 2020, 04:14 PM
Side note to this, I was currently wrong about being able to add Specialties from Mayhem cards, so this gets a bit easier...
Duggan is offline   #9 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 09:28 AM.


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