Closed CrowdfordBot closed 10 months ago
captainluffy: yeah i suppose we do
mctsts: the alternative is to not define protections as an attribute
mctsts:
and go with a notation starting with Passive:
mctsts: but then it causes issues with active protections
mctsts: so no
mctsts: im excited for the actually complex roles
e_thsn:
do we have other conditional defenses?
Recluse
captainluffy: if we're stuck on something like runner, thats a bad omen
mctsts:
so runner protects itself so we have to look up protection syntax
also just to clarify we currently have 6 subtypes (Absence, Effect Based Defense, Role Based Defense, Partial Defense, Effect Based Alignment Change, Role Based Alignment Change), I dropped the last two for now and renamed Effect Based to Active and Role Based to Passive because thats more accurate
mctsts:
if we're stuck on something like runner, thats a bad omen
its sort of expected
mctsts:
also just to clarify we currently have 6 subtypes (Absence, Effect Based Defense, Role Based Defense, Partial Defense, Effect Based Alignment Change, Role Based Alignment Change), I dropped the last two for now and renamed Effect Based to Active and Role Based to Passive because thats more accurate
the defense subtypes have existed for a couple of years and their purpose is to e.g. prioritze witch protecion over runner protection
e_thsn: Recluse, runner and CCiv are all only immune to wolves
captainluffy: cc is a different type i think
e_thsn: Oh
e_thsn: It used to be in defenses
mctsts: unsure if CCiv will be a protection or just an alignment change
captainluffy: i mean its the demonize category of defence
mctsts: no
e_thsn: Demonise is effect based
mctsts: rn CCiv is Role Base Alignment Change and demonize is Effect Based Alignment Change
mctsts: either way I didnt add those two types to protections for now
mctsts: maybe later
captainluffy: ok so this needs major expansion
mctsts:
Protect <Target> from '<KillingSubtype>' [by <Selector>] through <Subtype> [at <Phase>] (<Duration>)
mctsts: where [] elements are optional
mctsts:
we then still need to define an @
syntax to select players with attributes
captainluffy: wait theres a different type of restriction
captainluffy: assistant restriction not working on attacks
mctsts: but thats a redirection
mctsts: I thought of that
captainluffy: yeah but its a restriction right
mctsts:
mctsts: redirection is not part of protections
captainluffy: ok u definited it there
captainluffy: smart
mctsts: FPA can redirect attacks
mctsts: so its part of the redirection not the attack
captainluffy: so we do restrctions in square brackets, but subtypes in what kind of brackets
captainluffy: it seems like you have duration in round brackets
mctsts: restrictions are part of the action
mctsts: not the ability
mctsts: so they're separated
mctsts: things like duration are part of the ability
mctsts: I put any key components of the ability directly into the sentences and then additional ability info into ()'s
mctsts:
Protect <Target> from '<KillingSubtype>' [by <Selector>] through <Subtype> [at <Phase>] (<Duration>)
With this syntax I would end up with
Protect @Self from `Attacks` by @Selector through `Passive Defense` at `Night` (~Permanent)
mctsts: well
mctsts:
Starting: Protect @Self from `Attacks` by @Selector through `Passive Defense` at `Night` (~Permanent) [Quantity: 1]
mctsts: where @Selector needs to be changed
mctsts: to something that targets wolfish players
captainluffy: so while we figure out runner, ill do another one
mctsts: Formalize all roles