Discuss feature request - I want a third type - PC/NPC/*TEAM*

[bubblobill]

I have been developing a framework for a popular tabletop miniatures wargame.
MapTool isn't set up for this type of player vs. player action where each player has many tokens and each player belongs to a team of players.
Whether or not my framework becomes an unplayable resource hog, it would have been darn handy to be able to assign players to teams.

Everyone on a team should be treated as a separate group of PCs, and not entitled to things like shared vision from different teams.
Consider something like the Stats sheet pop-up. It would be nice if I could set properties as visible to GM, Self, Team, or Anyone (** unrelated but nice idea, have an option for make properties visible on Visible tokens.)

As it stands, all players can see all tokens. This makes it hard for one player to conceal a piece behind a wall. It kind of kills the surprise. Making macros to handle all the situations like this is umm.. challenging.

So this is my feature request up for discussion: Create another option beyond the PC/NPC dichotomy to allow for player teams.

I see macro implementations along the lines of;

• set/getTeam()
• set/getPlayerTeam()
• set/getTeamPlayers()
• isOnTeam()
• getTeamTokens()
• etc.

Discuss.

[Full Bleed]

I think that, ultimately, what we need is to be able to create custom token types like we can create token properties (heck, I use different token properties for NPCs and PCs in my framework.)

A "team" type seems to just address one more narrow token type and I'd like to be able to have types that were for summons, familiars, or friendly NPCs, etc.

[Merudo]

It's possible to allow for teams within MapTool:

1. Set individualized views on.
2. Give ownership of the Team A tokens to every member of Team A.
3. Give ownership of the Team B tokens to every member of Team B.

[Full Bleed]

It's possible to allow for teams within MapTool:

1. Set individualized views on.
2. Give ownership of the Team A tokens to every member of Team A.
3. Give ownership of the Team B tokens to every member of Team B.

Good solution. Not perfect since interteam members aren't walled off from one another, but certainly a good work-around.

[bubblobill]

It is currently doable but the methods are not brilliant.
The ownership fixes some problems but introduces others. It allows all team members to use and edit tokens that do not belong to them.
If PC/NPC was changed from a binary flag to something else, what would work best?

[jfrazierjr]

There have been some discussions about this for years around various features(some I understand and some I don't).

One such request has to do with wanting to make NPC's(allies???) but not call them PC's and so some of the various vision related thinks that are locked to PC's for performance reasons don't work. One of the proposals I suggested 10 years ago or so was to expand the list to:

PC
NPC(specifically, GM OWNED THINGS)
Allies(player or GM owned things but "allies" of the player)
Enemies(always owned by the GM and never reveal vision)

the discussion kind of died since there were some questions about WHEN to add such support and how or if it would be backwards compatible(I would say no) and would have been somethign to tackle cleanly when javafx and the new FOW system would be introduced in 2.0).

As well, we also discussed some various team related flags on the tokens but again, it was always "we should talk about this when we do 2.0).

Note that Jamz has done some thinking on this(almost certainly Craig as well) but no one has had time to really hammer down the technical details(or have not shared it, or I missed it since I am not super regular). I suspect that it won't happen until at least 1.6 is finished up and even then will depend on someone spending literally hundreds of hours rebuilding stuff as this would be a giant change to incorporate.