Configurables and spellbooks

[Nightfox]

Thank you for sticking with me on this.
Here is the thought process that led to assigning the expression in an eval script.

I started with the code in the field instead of script. As you can see from your own tests, if the tag is already on the "thing" it shows, but if the tag is assigned later it doesn't (at least i couldn't get it to work for me).

So thinking it might be a timing issue, I tested assigning the expression to the field in an eval script at a later timing to make sure that my script assigning the tag would run before the configurable. Again, if the tag is directly assigned to the "thing" it shows up, but even with the later entry of the expression, anything that did not have the tag directly assigned still does not show.

Here is how I was testing this.
- remove the tag from your fake ability. (of course it won't show now)
- create a feat and bootstrap the ability to it (so it will be on the hero)
- create a eval script on the feat to assign the tag to the ability.

Use the floating windows to verify that the ability is on the hero and that it has the tag. <check>
Then check if it shows on the configurable. <...>


Right now I suspect that the configurable pulls tags at start (ie only initial tags) and sorts them late (I think the task was around Final Phase 50,000)

[Sendric]

I'm happy to help, but I'm still a little confused as to why you're trying to set the expression through a script. I'm not saying there isn't a reason for it, I just can't think of one. If I understand things correctly, you want the ability to show you a specific list of spells and for it to be selectable in the configurable. Assigning the expression in the field directly rather than through a script accomplishes this goal.

Incidentally, you don't need the ability to be on the character for it to be selectable in the configurable. That would actually make the configurable redundant. In fact, after playing around with the scripting, it may very well be impossible to have an ability appear on the configurable list if you're waiting to add the necessary tag only when it's added to the character already.

What I did find was that if you ssign the appropriate tag to the ability directly, you can use a script to assign the expression to the configurable and have the ability show up. Again, I'm not really sure what the purpose of that would be, but it does work.

One more thought. The Helper.Helper tag on an ability doesn't really do anything. This tag is generally used to prevent things from appearing on certain lists (such as weapons or armor in the purchase menu) so players don't accidentally add something they shouldn't be able to. This doesn't really apply with abilities, especially custom abillities that only your configurable will be looking for anyway.

Oh, and another one more thought. You said you were assigning text to the field "cfgAllow2". Why? This is the expression for the second menu in the configurable. I'm not sure that would be needed in this case.

[Nightfox]

I was using the script to apply the expression just to see if I could change the timing of when it pulls the tags. As you say, it doesn't seem to matter.

As you noted, if the tag is applied directly to the ability it shows up just find.

Normally, in some of these tables (on the class, on a configurable, or even just in the system) there are long lists, with some greyed out because they are not valid picks. I know I can do this with the Expr-Req.

What I was trying to do, get only valid option to show. Either by applying a tag to the ability after a condition was met. Or remove a tag from the ability after the condition was met.

But it appears that these tables pull the tags at the beginning so no matter how they are changed on the ability before the actual calculation, the table only uses the initial tags.

[Sendric]

Are there other abilities showing up in your table you don't want? The best way to handle that is using a custom tag (like the one you have) and make sure it's part of the expression.

[Nightfox]

I'm sorry, I guess I am not explaining this very well. There are many possible options, but they may not be Valid options. "Valid" would be based on the user's choices though.

Let's say the expression is looking for 4 things.
Is it an ability (component.Ability)
Is it part of our custom set (Custom.LnkSrg)
Is it NOT just here for show (!Helper.Helper)
Is it NOT obsolete (!Helper.Obsolete)

There is a 5th criteria though...
Is the linked spell in our spellbook (Spellbook.cHelpWiz)... but this is on the spell not the ability. I can have script check for this, and add or remove a tag on the ability, but it seems this change in tags does not carry over to the table.

I think the only option is to set a prereq on the ability to check for the spellbook tag on its associated spell. The ability will still show up in the table regardless, but will be greyed out if they do not have the spell.

[Sendric]

OH! Okay. I assumed you were going to create a list of spell names within the ability. I'm not sure how you intend to display the list then. If all you want is the list of abilities in the configurable to only show those that qualify, I don't think that's something you can do. The configurable table shows abilities that meet the requirements before any scripts are run.

Alternately, you can use the specials tab (though that would get long) and hide anything that doesn't meet the requirements or use the abililty to create a list that is then stored as the ability's description. There is a limite to how many characters can be there, but that is probably what I would do. Maybe make one ability per level of spell or something.

[Nightfox]

yeah, that's sort of what I'm thinking. I can at least use the Expr-Reqs to indicate which ones are valid picks and which ones are not.

Thank you for sticking with me through this