Campaign Theatre Question - monster/npc numbering

[cheshyre]

Hi,

When using Campaign Theatre the system adds numbers automatically to monsters when the monsters are added to the stage (i.e., enact script).

Is there a way to modify that number? Or to change the "name" of the monster. For example change Rat, Giant #33 to Rat, Giant #1 or to Rat, Giant Orange Token?

We are really enjoying using Campaign Theatre but right now we are finding that there is an additional layer of book-keeping to track the monster in Campaign Theatre with the monster token that the players are seeing on the VTT. Often the question is wait, is #24 the one that has already been hit? Etc.
It is easy to put markers on tokens to indicate them by a color or a number 1-9, but have not been able to figure out how to modify what is showing on the stage so that both GM and players can easily determine which campaign theatre # monster relates to the monster token on the map.

Thanks for any guidance or input.

Roy

 

[rob]

All of that numbering is currently done automatically under the covers to distinguish between each of the cast members on the stage. Based on the way that is handled, making the jersey numbers user editable will actually entail quite a bit of work. I'll add this to the Book of Infinite Tasks, but I honestly don't expect we'll get to this in the near term, since there are already a ton of very important changes/improvements working their way through the pipeline.

Is there any way to change the token number within the VTT as an interim solution?

 

[cheshyre]

Many thanks for the quick reply. Much appreciated. And I'm sure the Book of Infinite Tasks always hungers for more ink for its pages.

There will definitely be some sort of workaround. However in general, right now the VTT token just is the token image and then apply a status marker to identify between the different tokens. So for the playing group it has felt like the disconnect is in the labeling in the Campaign Theatre. Multiple different options to try...the preferred was just to rename the creature on the Stage.

Many thanks and hope the team is doing well with everything going on in the world.

 

[charlieluce]

The way Campaign Theater behaves is kind of disconcerting. I haven't been able to figure out when it adds numbers and when it doesn't. HLC only used numbers for explicit copies of the same monster, and they were easy to edit in advance to coordinate with my map tokens. With HLC so far I have had to stop at the beginning of every combat to edit token names in MapTool.

 

[rob]

The way Campaign Theater behaves is kind of disconcerting. I haven't been able to figure out when it adds numbers and when it doesn't. HLC only used numbers for explicit copies of the same monster, and they were easy to edit in advance to coordinate with my map tokens. With HLC so far I have had to stop at the beginning of every combat to edit token names in MapTool.

Each non-unique cast member is assigned a jersey number when it is added to the stage. If a cast member is unique, there can never be multiples of it, so there's no need to assign a number.

This behavior is necessitated because the same script can be enacted multiple times. Or a different script containing the same creature can be enacted. Or the same creature can be manually added directly to the stage. All of these could result in the same creature appearing multiple times on the stage, so each is assigned a number to uniquely identify it.

In Classic, if you wanted to have 7 goblins, you had to pre-create each of them in advance. So each had its own name that could be edited in advance. This was fiddly and unnecessary prep work in the eyes of most users. In HLO, only a single goblin needs to be defined, along with a quantity. HLO then takes care of ensuring that everything is assigned a unique jersey number.

In the specific case of getting the numbering synchronized between a VTT and HLO, that's where this overall improvement for most users breaks down. But it's an interim issue only. Once we're able to export characters from HLO and VTTs can import them, this mismatch problem goes away and it's an improvement for everyone, whether or not they use a VTT.

Please also remember that, when we designed/built all of this, it was a pre-Covid world where face-to-face gaming was still vastly more common that the use of VTTs. So we optimized the UX for the most common usage pattern.

If you want to bruteforce things to work, you can use the old Classic approach within HLO. Create 7 separate goblins within the script, marking each one as unique and assigning your own number to each within its name. Then HLO won't assign a jersey number and you can have everything matched up in advance. That seems rather clunky to me, just like it was within Classic, but it ought to give you exactly what you want as an interim solution.

Hope this helps!

 

[charlieluce]

Thanks for the explanation, Rob. MapTool defaults to numbering duplicates of the same token (by file name), which basically tracked how HLC did it, so the change threw me off. I don't currently have much need for unique opponents, but there's no harm in using them to avoid numbering the boss in a boss-and-flunkies fight. At any rate it's easier to edit on the MapTool side than the HLO side.


How does HLO determine the number of ordering? Is it by level-then-alphabetical?

 

[rob]

How does HLO determine the number of ordering? Is it by level-then-alphabetical?

There is currently no consistent order for this, as none was thought to be necessary when it was written. All of the mooks of a given type are generated at the same time and will have sequential numbers. However, the order in which the different types of mooks are generated is whatever the database query happens to return.

 

[dacoobob]

is there a way to at least restart the numbering for each creature type? so instead of Goblin 1/2/3 and Goblin Dog 3/4/5, could we get HLO to name them Goblin 1/2/3 and Goblin Dog 1/2/3? That would get around the VTT limitation of only allowing numbers 1-9 on the markers.

 

[cheshyre]

if dacoobob's suggestion is something that is implementable that would be an excellent stop-gap measure until VTT integration gets built out.

 

[rob]

is there a way to at least restart the numbering for each creature type? so instead of Goblin 1/2/3 and Goblin Dog 3/4/5, could we get HLO to name them Goblin 1/2/3 and Goblin Dog 1/2/3? That would get around the VTT limitation of only allowing numbers 1-9 on the markers.

Not without a lot of work. There are a variety of usage scenarios that make doing that extremely complicated to solve. None of those scenarios will be common, but they still need to be handled cleanly.

FWIW, the model you proposed was what I originally started to implement in the backend. But those "problem child" scenarios forced me to re-think and adopt the current approach instead.

This can definitely be something I circle back to in the future, but it's not something that can be changed quickly. Unfortunately.

 

[charlieluce]

There is currently no consistent order for this, as none was thought to be necessary when it was written. All of the mooks of a given type are generated at the same time and will have sequential numbers. However, the order in which the different types of mooks are generated is whatever the database query happens to return.

Ah, well, that is going to be an ongoing issue then.
Is it consistent within a script, at least, or is it possible for the same script to give different results at different times?

 

[rob]

Ah, well, that is going to be an ongoing issue then.
Is it consistent within a script, at least, or is it possible for the same script to give different results at different times?

That's where things start to get complicated. What if a script is enacted into a scene. Then the GM enacts the SAME script into the SAME scene a second time? Everything gets doubled.

The GM could enact Script#1 first and then Script#2. OR he could enable Script#2 first and then Script#1. What if both scripts have goblins in them?

What if the GM enacts a script with 3 goblins and then adds a goblin manually to the stage?

A single script is pretty straightforward, but multiple scripts can get wonky.

I can see about ensuring that a single script always behaves in an internally consistent manner. But across scripts is gets very messy, and there will be times when GMs want to leverage multiple scripts at the same time.