Automatic lair action token

[Drenam1]

When adding a token (for example, ancient red dragon) to the combat tracker, it checks the monster's attribute 'hasLair'. If the attribute is true, then it adds a second item to the initiative tracker at initiative count 20, with the name "MonsterName (Lair)" and the exclamation point image. The lair token is hidden from the players.

Create.mp4

When the dragon is removed from the combat tracker (whether by deleting it from the tracker, via the token menu or by deleting the entire monster from the scene), its lair action token is also deleted.

Delete.mp4

The lair token can also be deleted without affecting the original token.

Remove.Lair.mp4

[Azmoria]

Looks good, I think people will appreciate this. I'll give this a test probably tonight and get it merged in if alls good.

[Drenam1]

One thing I couldnt figure out (not for lack of trying) was maintaining the deletion status of the lair token between sessions.

For example, if I add an ancient red dragon to the combat tracker but its not in its lair, then I can delete the lair token no issue. However, if I then close AVTT and reopen it, the lair token reappears on the combat tracker. So if you can think of an easy way to do that during your testing (and if you think its even necessary) then that'd be awesome 😄

[Azmoria]

I think for it to not readd the lair tokens on refresh after removed, we'll need a flag on the main token saying not to add the lair action again. Since we rebuild the combat tracker by readding tokens to combat based on token data on the scene.

Using the dragon example, if the lair action is removed it should add a do not add lair action option to the dragon token. Then when it does get readded on reload it can look for the flag and not add the lair action token.

---

I'm getting an error when adding a creature with a custom statblock, I think you'll just need to remove the customStat option in the if statement where it runs fetch. The open5e statblocks while not erroring alsso aren't adding the lair action token.

We can look at supporting both custom statblocks and open5e but they'll need some different logic of where to look I think.

---

When switching scenes with lair action creatures in combat it's doubling up on them as well. I suspect it's got the original in all_token_objects (cross scene token data) and creating new ones in TOKEN_OBJECTS (on scene token data). This could potentially be fixed by the same main token, do not add lair action flag, if it set immediately after creating the original lair action token.

I'm not sure if the lair tokens are syncing to the server at the moment though, if they aren't we may need a different solution so it doesn't mess up refreshing when you want the lair action token there too.

We'd probably want to remove/disable the flag on removing the main token from combat manually, so it does readd the lair action token.

---

Minor issue I have or have a use case I'm not thinking of but I think we should only ever have 1 lair action token if multiple creatures are in combat that have lair actions. I added a few and it clogs up the combat tracker pretty quick/is annoying to remove the extras. Running a dragon campaign right now and I often have a few dragons in combat at a time so this would come up prettty frequently for me.

---

Possibly an option to disable this too, with having static initiative tokens now I'll probably be making my own lair action tokens with statblocks that just have the lair action/other round effects. So I'd almost never want them adding when using those. This could be be enabled by default and then those who don't want it can disable it, or make the option 'disable auto add lair action tokens'.

---

Let me know you're thoughts, I can look into doing some of the above too if you'd like.

[jeffsenn]

I haven't really looked at the impl ... but an idea: since the token in the combat tracker does really need "all the stuff" -- could it just be a "synthetic token" (ie just autogen'd by tracker - maybe it can combine lair actions from other tokens into a stat block if we're fancy) managed by the tracker that notices if anything in the tracker has lair actions? (appears and disappears under tracker control).

[Azmoria]

I haven't really looked at the impl ... but an idea: since the token in the combat tracker does really need "all the stuff" -- could it just be a "synthetic token" (ie just autogen'd by tracker - maybe it can combine lair actions from other tokens into a stat block if we're fancy) managed by the tracker that notices if anything in the tracker has lair actions? (appears and disappears under tracker control).

Drenam has the tracker generating a token at the moment. It does auto add/remove with the linked token - there's just 1 per token. It's just on token add/ct_load per token. Potentially moving it to end of ct_load, ct_reorder or ct_persist if we only ever need 1 could be an option. I think we'd still want manual removal. So may have to flag all tokens in the tracker, with some don't add lair token, when removed if we go with the 1.

Groups are done this way too since everything is assumed to be a token by the tracker. We could flag it to be a 'lair action' token type if we want to do special stuff with it.

Alternatively create something new the tracker can accept.

For the combine, yeah I had a similar though for a future improvement. Since it's a token just add a custom statblock or note if that seems better to allow editing, with the lair action text would do it.

Since anything in the tracker is already built as a token this could be relatively simple for lair action text we can detect/collect.

[Drenam1]

Hey @Azmoria sorry to leave this hanging, work has been slamming me this month so I haven't had the time or bandwidth for anything else. If this isn't good enough in its current iteration, then it can be discarded - I'm not going to be able to get back to it for a while I think.

[Azmoria]

No worries - real life comes first. I can probably add this to my list to adjust/look at when I get the chance.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.