On 8/16/2022 6:38 AM, juan via agora-discussion wrote: > * I really don't know when to use switches and when to directly define > attributes.
Switches comes with all kinds of protections including weekly (or monthly) self-ratifying reporting and how to resolve uncertainty in values. This is useful if the attribute is a "primary" status which you want to correct the game towards in case of error, where in the long run it's more important for game play to be certain about a fixed status than to worry about how you got there. The best case study for Switches is Offices. If some problem with a past election turns up months after the election, you don't want to invalidate everything the supposed winner did as that officer - it's better for the game to auto-correct through self-ratification that we knew who the officer was, even if the election "failed". (this exact thing happening was instrumental in designing the switch rules). On the other hand, if you're tracking the result of non-fliplike actions that are themselves tracked, continuously-evaluated attributes might work better. For example, for CFJs: > At any time, each CFJ is either open (default), suspended, or > assigned exactly one judgement that was validly assigned. For CFJs you'd rather correct any reporting errors towards the actions that happened, not towards the reported state. Like, if you have a case report that erroneously says of an Open CFJ "CFJ X switch=judged" that self-ratifies, but no judgement was actually delivered, the case ends up being weirdly stuck as being "judged" but not having an actual judgement, with no really good way to resolve the problem. Here, the history of the actions is more important than the reported state. So you wouldn't want a switch to self-ratify there. -G.
