Hi, Richard... I've got a script in beta (about to get a major update). It's called InsertArgs, and it takes a slightly different approach to your predicament. First, I don't think there is a way to let the players select tokens without giving them the ability to select them... and I don't mean that to be funny. I just mean that it would be a nice feature to have a middle ground pseudo-selection interaction -- a "draggable" target interaction, let's say. But we don't have that. So we are left to figure out our own solution. Here's what I did... Write your Abilities as you would normally (right now it's just abilities, but soon it will be more) Wherever in those Abilities you think you're going to need ad hoc information that can't be covered in a query, drop a "hook" -- cleanly identifiable text That hook becomes an argument to the InsertArgs script, to which you feed the ad hoc information. I know, it sounds hard to follow in the abstract. Let's say you had your spell macro/ability and it said: !awesomeblast #pts|12 #dmg|+3 #tgt|@{target|Target 1|token_id} ...and you didn't want to have multiple abilities for that same spell, each with a higher number of targets: !awesomeblast #pts|12 #dmg|+3 #tgt|@{target|Target 1|token_id} !awesomeblast #pts|12 #dmg|+3 #tgt|@{target|Target 1|token_id} @{target|Target 1|token_id} !awesomeblast #pts|12 #dmg|+3 #tgt|@{target|Target 1|token_id} @{target|Target 1|token_id} @{target|Target 1|token_id} Rewrite and keep only one of them to replace that targeting information with a hook !awesomeblast #pts|12 #dmg|+3 #tgt|tgthook (you can name the hook anything you want... with a couple of edge case exceptions) Just to have a handle, let's call that Ability "AwesomeBlast". Then, create an Ability for an InsertArg call AwesomeBlast, and feed the appropriate information for the moment: !insertarg --button#AwesomeBlast --tgthook#gettargets(?{How many targets?|1})
↑ ↑ ↑ ↑ ↑ 1 2 3 4 5
1 - how you want to output the result available options are chat, whisper, button, and load
since this involves targeting, you can't chat it; button is your best bet
2 - the ability to read for the source command line
3 - your first hook (others could follow as more arguments, if you had other things to replace)
4 - internal function to the insertarg script producing x number of @{target} calls
5 - query to prompt you for the number of targets to request of the gettargets() function The end result is that you get a button with the ad hoc build of the ability with your hooks replaced with the output text. Your original ability is unchanged, so you can perform this action again. This thread for the original beta has a use case for an 8 ability selection that were all able to be handled by one insertarg call. That example still stands, even though the script has upgraded since then. There's also an "xray" side of the script discussed here . This is the script for which I was writing a recursive descent parser , so now that that part is done, I just have to tie the parser in to the script engine. Once that is done, you'll be able to utilize one function inside another function in the script call. I know, it's all sort of meta, especially if you don't have the script in front of you to play with and see it happen... but suffice it to say it can solve the issue you're looking to have solved! If you didn't catch the link to the script in the linked threads, you can find it here .
