msg.selected and @{target|token_id}

So when you issue an api command, the tokens selected are available in msg.selected. However, if you specify a token_id via @{target, it deselects the tokens and msg.selected is empty. I'm trying to use msg.selected to pick multiple tokens to all perform the same action against a target token. Currently I'm working around this via one command to select the actors and a second command to perform the action, but that is rather inelegant. If anyone has a better suggestion, I'd love to hear it. (The major problem is that you can't even chain the commands in a macro, since the @{target is resolved first, and deselects the tokens.

Does something like !scriptname @{selected|token_id} @{target|token_id} not work for your script? That way you would have both the selected and the targetted to manipulate in your script.

That only lets you have one selected. Specifically I'm automating archer combat, so I'll have a squad of archers selected, firing at the same target. If @{selected|token_id} would give an array of selected tokens, it would work, but if you have multiple selected, it gives the id of the first only.

For this reason you cannot use msg.selected for multiple targets. You need to create a macro like this: !AddTarget @{target|First Target|token_id} @{target|Second Target|token_id} @{target|Third Target|token_id} @{target|Fourth Target|token_id} @{target|Fifth Target|token_id} @{target|Sixth Target|token_id} @{target|Seventh Target|token_id} @{target|Eighth Target|token_id} @{target|Ninth Target|token_id} @{target|Tenth Target|token_id} And then grab each token_id in the API using the 'on("chat:message", function(msg)' I have macros numbered from 1 to 10 that allow for me to click the macro number for the relevant number of targets that I am selecting.

Ah, that's a good thought, doesn't let you drag-select, but is a good idea in general. I wonder if the msg.selected list is in a useful order... If it is in the order the tokens were selected, you could select the attackers, shift-click the target so it's at the end of the list and go from there...

Just so I follow what you're trying to do, you'd like to: Select a bunch of tokens, say a company of archers Have them all perform an attack against a single selected target? And you're triggering this with a macro?

Yup, or by typing !attack @{target|token_id} (the macro just runs !attack @target...) I also realised I want to be able to tell group A to attack group B, which will almost certainly require selecting group a, hitting a button, selecting group B and hitting attack... I also may be able to select group A, select group B and run !attack <number_of_people_in_group_a>, assuming the list is in order selected rather than some arbitrary order.

Yeah, I was going to suggest breaking it out over two commands: !set-attack-group !attack @{target|token_id} The first one can store all the ids of the selected, the second can then retrieve the attack group and apply attacks to the targeted token. The same process could be done to have one group attack another group with something like !set-attack-group (or just checking the selected for !attack if there wasn't an argument).

BTW, shift clicking does seem to maintain order.

Thanks, I've been meaning to try it out but have been busy. The set-attack/attack is what I've been doing, and I find it clunky, especially since I don't currently have a way to denote the current attackers and they are lost when the sandbox restarts. (I could put them in state, but that doesn't seem appropriate). Also, it uses one set of attackers for all players, which is a problem; I could fix it, but like I said, I find the entire method cumbersome and inelegant. What I'm thinking now is to select the attackers then select the targets. If no number is specified, assume the last member of the list is the target and all others are attackers. If a number n is specified, the first n tokens are attackers and the others are targets. Then I simple provide a !count function which says how many are selected. The order is then select the attackers, if they are in formation the number of them is trivial (2x6 or 2x10 or whatever), otherwise run !count, select the targets, run !attack number. I think that's about as good as it's going to get. It'd be neat if you could select multiple groups with different highlighting colours ...

You could store the selection of groups under an array in state based on the player issuing the commands, then each player has their own groups. As for selecting tokens with different highlighting colors, do you mean the status markers? Like mark one group as blue? You can totally do that. findObjs({_type: "graphic", statusmarkers: "blue"}) will give you all the tokens with the blue marker on them.

Yeah, if I didn't come up with the idea using just msg.selected, I would put them in state indexed by activator. I hadn't thought about using the status indicators, which could probably work too. What I meant was to be able to do something like left-click drag-select and middle-click drag-select to provide something like msg.selected1 and msg.selected2, each showing up on the tabletop with a different selection box. I also may do something with the token groups feature, assuming I can access it via the API, it would let me handle it on a squad basis...

I don't see grouping in the objects reference section. :/

Yeah, neither did I, when you have multiple selected on the map you can tell it to group them, but I don't think you can find out what's grouped via the API...

Logan P. said: Yeah, neither did I, when you have multiple selected on the map you can tell it to group them, but I don't think you can find out what's grouped via the API... Grouping is merely for asset control on the map layers. This doesn't bind them into one entity for the API to use. You are going to have to use find objs to get them all. The alternative here is to make the squad a single token (like a warhammer 40k unit) then you only need to pass 1 selected ID for the squad then in the script just simulate hit rolls for all "members" in the squad. If each squad member has different stats or abilities, annotate them in the BIO/GM info panel, and put them in the script somewhere. That is the beauty of the API, once you have passed token info, you can do anything you want in the API.

Yeah, I know it doesn't bind them into one entity; the hope was to find a way from one entity to get a list of attached entities, but I figured it would be a long shot.

You could certainly maintain that grouping yourself in the state, particularly if you have one "seargent" unit.

True, and I'll end up doing something that way certainly. I'm going to end up running battles with hundreds of men on each side, so I'm working on automation scripts. I am looking for a good way to auto-calculate battles without details for what happens when the PCs are not around, but battles with them actually present can't just be determined by a probability table...

Sounds like a fascinating scripting challenge. Tell me more! =D

Heh, yeah, conceptually it isn't bad; I've written some basic AIs in the past and this basically is just that. The problem is the short time slices we can use from within the sandbox. If it would let us auto-throttle the script it'd be fine, especially if we could get access to the javascript threading API, but alas, no. So I've been working with Alex L. on getting a firebase client working to access the api log and communicate with the sandbox. With that I can have my computer, locally, provide the brains to the AI and just let their sandbox make the needed changes to position, orientation, and health of the various units. This solves the performance issues, and lets me write the AI in lisp, which is a plus so far as I'm concerned. I have a pathfinding algorithm that will just get plugged in and used, requires a bit of info on the map; the AI will be pretty simple, melee units advance on closest non-surrounded enemy and engage, ranged units target random enemy in closest non-engaged unit, when unit morale drops enough, units flee straight away. I may get more advanced later, but I think it will do a good job of giving the players the right atmosphere.

Neat! =D