Chooser_table - Need Entity to use candidate field?
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 |
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. |
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 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... |
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?
|
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"> |
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.
|
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:
Code:
<it_bootcustom compset="cmpsetSB" target="child"> |
All times are GMT -8. The time now is 12:51 AM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.