filter_player_class

[Citizen_001]

This should definitely be an entity. It would be the most versatile and simple system for mappers. Is it possible to make though?

[Bad King Urgrain]

I'm not too familiar with filter entities. Am I correct in assuming this hypothetical entity would fire an output if the activator of the input was innocent/detective/traitor, and ignore it otherwise?

[Citizen_001]

Filter entities are completely unrelated to all inputs/outputs, as in they do not output anything themselves. They are simply referenced by an output emitting entity (such as a trigger) through a keyvalue called "Filter Type" and they prevent the trigger from emitting any output relating to it's activation such as "OnStartTouch" unless the activator of the trigger passes the filter whether it be a filter_activator_name which discriminates based on name or filter_activator_class which discriminates on entity type (npc_zombie or whatnot).

This is where the trigger references the filter's name:

[Bad King Urgrain]

Looking at the C++ sourcecode of the filter ents, they are indeed separate from input/output. The bad news is that this means there are no Lua hooks for it and I can't make a proper filter.

It does seem very possible to do what I described: an entity you'd put in an input/output chain that only fires its output if the !activator is a certain type of player. It would work like using a filter_activator_* "manually", through its TestActivator input and OnPass/OnFail outputs. A bit more like you normally use a logic_* entity I suppose. All in all it would be more cumbersome than a proper filter, but it should work for traitor/detective buttons and such.

[Citizen_001]

That does sound better than what there is currently since it would allow me to discriminate from traitors and innocents a bit more actively.

[Bad King Urgrain]

I've added a ttt_logic_role entity that pretty much mimics the filter entity's setup as I described above, so a role keyvalue to specify what type of player to check for, a TestActivator input to see if the !activator is indeed a player with that role, and OnPass/OnFail outputs for the result of that check.

Seems to be much easier to set up for traitor-only buttons/doors and such.

If you're in a big hurry I could put up a version with just the new entity added, but there will be an update with it in there this week regardless.

[Citizen_001]

Nah, you can just put it in the next update.