Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
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> |
#1 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,214
|
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> |
#2 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
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> 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 |
#3 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,214
|
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. |
#4 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
Quote:
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:
Incidentally, thank you for responding today. I know some people are off work for New Years Eve. |
||
#5 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,214
|
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. |
#6 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
Quote:
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:
Quote:
Quote:
|
||||
#7 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
Heh, and searching for "agent tables", this isn't the first time I've asked this question. Two years ago...
|
#8 |
Senior Member
Volunteer Data File Contributor
Join Date: Nov 2009
Posts: 1,502
|
Side note to this, I was currently wrong about being able to add Specialties from Mayhem cards, so this gets a bit easier...
|
#9 |
|
|