• "DecayVFX"

New property, specifies a VFX that'll play when the card decays.

• "Induces"

Works virtually the same, but inductions now a) check requirements and b) use expulsions.
Note that Inductions only happen from the "unshrouded" cards - the cards that lie-face up at the end of the recipe chain. The card is "shrouded" if it was created with "Effects" recipe property during the current recipe chain - and was never xtriggered since then. All other card-creating effects - like deck draws, and spawn morph effects - create cards in an unshrouded state.
(well, technically deck draws don't create a card, only move it from the deck, so it makes sense.
To make this mess a bit more controllable, there's another property:

• "Shrouded"

This value overrides the state of the card after its creation. If not defined, it follows the default rules - shrouded if created in "Effects", unshrouded if created otherwise. If defined as "false", the card will end up unshrouded in any case. If defined as "true", the card will be shrouded even if it was created via xtrigger with spawn morpheffect (or normally, with "Effects" - but still not in case of DeckEffects).

• "XTriggers"

First of all, they now take in account both catalyst and token quantity - let's take a hypothetical situation where 3 cards of X met 3 cards of Y in a recipe, and the card X is set to spawn a card Z when hit with Y. With Roost they'll always spawn 3 * 3 = 9 cards. In the unmodded game that amount could vary, depending on several factors.

Second, elements' native aspects can serve as a catalysts for xtriggers - in the core game, only mutated aspects were evaluated.

Third, an assortment of the possible xtrigger effects is significantly expanded. In addition to the normal Transform, Spawn, and Mutate there now are:

• SetMutation - applies a non-additive mutation.
  
• DeckDraw - draws from a deck specified in xtrigger's ID.
  
• DeckShuffle - shuffles a specified deck .
  
• Destroy - destroys a Token, ignoring its decayTo property.
  
• Decay - decays a Token.
  
• Induce - creates a new Situation Token with a specified Recipe running, with specified Expulsion (optionally).
  
• Link - adds a link to a specified recipe ID on the top of the linked recipes list for the current recipe. The link exists only for the current recipe execution, and won't be evaluated again if the same recipe is executed without the trigger that adds that link.

Fourth, "Chance" and "Level" can now be expressions.

Fifth, there are now three additional sub-properties

• "VFX" - specifies a VFX that plays when XTrigger is applied. By default is "CardTransformWhite".
  
• "IgnoreAmount" - boolean, means the xtrigger will always behave as if the affected Token has Quantity of 1. By default is false.
  
• "IgnoreCatalystAmount" - boolean, means the xtrigger will always behave as if the catalyst's Quantity is 1. False by default.

Sixth, instead of defining "id" and "level" properties separately, it's now possible to define them as [id value]: [level value]. Ex. { "morpheffect": "mutate", "id": "lantern", "level": 1 } equals { "morpheffects": "mutate", "lantern": 1 }. Note that it's just a syntax shortcut, and you can't define more than one id/value for a single xtrigger effect, ie { "morpheffect": "mutate", "forge": 1, "lantern": 1 } is invalid and should be split into two different effects.

Seventh, it's not new, but just a reminder - xtriggers are quick spec entities, so they can be defined via single string, where "xtriggers": { "catalyst": "element" } means "transform into the following element when "catalyst" is present.

• "DisplaceTo"

Determines

An important thing to know about decks is that they are always empty at the start of the new game and are filled only on the first draw - even the ones that normally don't reset on exhaustion. So, if you're relying on a deck in expressions, make sure it was shuffled (there's now a recipe property for that).

• "ShuffleAfterDraw"

New boolean property, if true, the deck will be shuffled after the each draw effect in which this deck was affected. Note: not after *each draw*, but after the *whole draw effect* - if you do 3 draws, the deck will be reshuffled only after all 3 were done. If you need the deck to be reshuffled after each draw, you'll need to split the draws across several recipes. Default value is, of course, false.

• "IsHidden"

New property, boolean, false by default. Defines whether the deck draws preview will be visible in the Situation window. Useful if your draws serve only some kind of tech purpose and won't make any sense for the player.

• "Cover"

Actually not a new property and not modified in any way, but did you know that you can define a deck's icon in aforementioned deck draws preview by specifying its Cover property - which can either be one of the three default values ("default", "books", "eye") or a custom one, loaded from the "mod/images/cardbacks".

• "Draws"

Only used for internal decks, can now be an expression.

• "ForLegacyFamily"

Is now a list of strings. Default value is single "".
See more below, in Legacies.

• "Family"

Is now a list of strings. Default value is single "".
When the new run starts, the game goes through all the decks and checks whether its "ForLegacyFamily" property has any matches in the current Legacy's "Family". If it does, the deck is initialized, which affects two things a) the deck can now be drawn from and d) game performance is *slightly* worse. Basically, unless you're using a lot of decks with big specs, you don't need to worry about that.

That's where it's at. Most of the Recipe effects properties now make use of expressions - all of them, in fact, except for Purge, DeleteVerb and HaltVerb.

Order of effects
The properties are executed in the following order:
Root Effects -> Mutations -> XTriggers -> Deck Shuffles -> Deck Effects -> Effects -> Decays -> HaltVerb -> DeleteVerbs-> DistantEffects -> Movements -> Purges -> Induces
(I'll explain what exactly each effect does later)

Any changes made within the same property effect will *never* affect any expressions/filters defined in the same property:
"effects": { "forge": "lantern", "lantern": "forge" } - the forge and lantern are cross-referenced here, but, whichever is effect takes place first, the resulting amount of both will always be consistent - and it depend on the values that were present *before* this property's execution. And similarly, if something got a mutation, it won't be counted until the whole "Mutations" execution ends, and so on with each property.

• "GrandReqs"

Additional requirements that make use of expressions and thus can combine normal reqs, tablereqs and extantreqs (and any other possible reqs) in a single property. Structured like the normal reqs: { [what's required]: [requred value] } and both sides can use expressions. Evaluated as the normal reqs too - if the requrement value is positive, the left value must be either greater or equal, if the requirement value is negative, the left value must be lower than the req's absolute value. (this may sound confusing, but this is just how normal reqs work). Examples:
"grandreqs":
"lantern": 1, if lantern in the current situation ≥ 1
"~/tabletop:lantern": -5, if lantern on the table <5
"~/tabletop+:lantern": -1, if extant lantern = 0 (note the "+" after the ~/tabletop - means "tabletop and all the spheres on the tabletop").
"[~/tabletop:lantern]*2": -10, if twice the lantern on the table is less than 10
"[lantern]+[forge]": 36, if both lantern and forge together are ≥ 36
"[lantern]>[forge]": 1, if lantern in the current situation is bigger than the forge in the current situation; please note that { "lantern": "forge" } will not work the same way as it checks for greater or equal.

• "RootEffects"

Root is a global scope of the game. It can accept mutations, that can later be retrieved by an expression via "root:aspect". All mutations are additive, values can be expressions.
Examples:
"rooteffects": { "lantern": 1 } - adds 1 lantern to the root
"rooteffects": { "lantern": -[root:lantern] } - sets the lantern amount of the root to 0
Also make sure not to store here an aspect called "II".

• "Mutations"

Apart from the usual addition of expressions, "Mutations" got an alternative syntax. While in the core game, "Mutations" property is a list of separate mutations, each having its own filter, in the Roost, "Mutations" is a dictionary, with filters being the keys and the associated values defined as a list of mutation effects. Mutation effects in turn can have all the usual properties (that are, "Mutate", "Level", and "Additive"), as well as a separate "VFX" property.

Examples:

"mutations": [{ "filter": "lantern", mutate": "forge", "level": 1, "additive": true } ]
"mutations": { "filter": "lantern", mutate": "forge", "level": 1, "additive": true }
"mutations": { "lantern": [{ "mutate": "forge", "level": 1, "additive": true } ] }
"mutations": { "lantern": { "mutate": "forge", "level": 1, "additive": true } }
"mutations": { "lantern": "forge" }
"mutations": { "lantern": { "forge": 1, "additive": true } }
All these do the same thing - add 1 Forge on all the tokens that have Lantern aspect

As seen in the last example, mutation effects, similar to XTriggers, can use syntax { [mutateValue]: [levelValue] } instead of { "mutate": [mutateValue], "level": [levelValue] }.
As also can be seen from examples, mutation effects are quick spec - means they can be defined from a single string, in which case they're defined as "the level 1 additive mutation of the specified aspect".

• "Aspects"

Not many changes here. The aspect level is now can defined as an expression, which can be useful for xtriggers that are sensitive for the catalyst amount.
Other than that, this property can be used for inductions if the current recipe is the last in the recipe chain - in which case the amount is irrelevant, of course.

• "DeckShuffles"

List of strings - shuffles the following decks.

• "DeckEffects"

Same as all other things, the number of draws can be an expression, works the same otherwise. The only thing to keep an eye on, is the fact that, when draw effect happens, the card is *immediately* removed from the deck - so it's not counted for the expressions now - but it's *not* moved anywhere else immediately. A simpler rule of thumb may sound as "do not cross-reference decks in DeckEffects". To illustrate further, "deckeffects": { "deck1": "~/deck2_draw:$count", "deck2": "~/deck1_draw:$count" } - this may return an inconsistent results. The case is really niche, but just to warn.

• "Effects"

The effect value is now an expression. Additionally, if you want to destroy something, you can now use a filter instead of plain id:
"effects": { "[lantern]>5": -5 } - destroy five cards that have their lantern aspect above 5. The cards to destroy/reduce amount are chosen randomly among all the eligible cards.
Please note, that if you're using an expression for a value, and it turns out >0, then filter-effect will do nothing.

• "Decays"

List of filters. Forces all cards that are chosen by a filter to decay (i.e. to either transform into their DecayTo, or to be destroyed if it's not defined). Note that the same cards can be chosen by a different filter - in this case they won't decay several times, but it may reduce the overall amount of affected cards.

Examples:
"decays": [{ "filter": "lantern" } ] - decay all the cards that have lantern aspect.
"decays": [{ "filter": "lantern", "limit": 1 } ] - decay a single card that have lantern aspect
"decays": ["lantern", "forge" ] - decay all the cards that have either lantern or forge
aspect
"decays": ["lantern || forge", { "filter": "edge", "limit": 1 } ] - decay all the cards that have either lantern or forge, and then a single card that have edge aspect.

• "Movements"

Moves an amount of tokens that satisfy a filter from the current sphere to a specified sphere. More about filters here.
Can be used, for example, to shuffle present cards *in* decks, or to gracefully spit them from a verb on the tabletop without using intermediary expulsion.
If the target sphere is the tabletop or any slot, the card will visibly float to it from the current sphere.

Syntax examples:
"Move all the tokens that have Lantern aspect to the tabletop sphere":
"movements": { "~/tabletop": [{ "filter": "lantern" } ] } -
"movements": { "~/tabletop": { "filter": "lantern" } }
"movements": { "~/tabletop": "lantern" }

"Move all the tokens that have Lantern aspect to the Tabletop sphere, and then do the same with all the Tokens that have Forge aspect":
"movements": { "~/tabletop": ["lantern", "forge" ] }

"Move a single token that has Lantern aspect to the Tabletop sphere, and then do the same with a single Token that has Forge aspect":
"movements": { "~/tabletop": [{ "filter": "lantern", "limit": 1 }, {"filter": "forge", "limit": 1 } ] }

"Move a single token that has Lantern aspect to the Tabletop sphere, and then do the same with all the Tokens that have Forge aspect":
"movements": { "~/tabletop": [{ "filter": "lantern", "limit": 1 }, "forge" ] }

"Move a single token that has either Lantern or Forge aspect to the Tabletop sphere":
"movements": { "~/tabletop": [{ "filter": "[lantern] || [forge]", "limit": 1 } ] }

"Move all the mortals from here to the "hunters" deck".
"movements": { "~/hunters_draw": "mortal" }

• HaltVerb/DeleteVerbs

The values can now be an expression, other than that nothing new.

• DistantEffects

Imagine that, after you ran the recipe effects, you were able to run another set of effects inside the same recipe. Imagine then, that you are able to run recipe effects not just inside the current situation, but inside any Sphere of the game - another verb, tabletop, even deck, a specific slot, if you want it.
That's what DistantEffects are. It is a list that contains a set of effects unified by a single Sphere target.
"distanteffects": [{ "target": "~/tabletop", "effects": { "funds": 5 } } ] - this will create 5 Funds on the tabletop.
Distant effects can have all the effect properties that a normal Recipe has, that is: RootEffects, Mutations, Aspects, DeckShuffles, DeckEffects, Effects, Decays, HaltVerb, DeleteVerb and DistantEffects and Movements, as well as an additional property "Target" - a FuсinePath that specifies where the effects will take place. Note, that if your path points to several spheres, effects will take place in all of them, which can be either very handy or disastrous.
Since the "DistantEffects" is a list, all effect sets are executed in the specified order. This can also be used to circumvent the normal execution order - if you target the same sphere where the execution already takes place (by leaving Target blank or using "~/sphere" or "~/local").
"distanteffects": [{ "effects": { "funds": 5 } }, { "mutations": { "funds": "worth" } } ] - this first creates 5 Funds in the Situation storage, and then mutates 1 Worth on them.

• Induces

A property that has the same syntax as "linked" and "alt". After the recipe ends, it tries to create new situation tokens with the specified recipes running, plain and simple. No "alt-additionals" involved. The reqs for these recipes are evaluated right after all the effects took place, but before any vanilla inductions and alt recipes are performed (and therefore the reqs are unaffected by any further expulsions).

• Purge

The property is unaffected, can't use expressions and kept only for legacy reasons. But I recommend to use DistantEffects and either Decays or XTriggers to imitate the Purge effect.

• VFX properties

Finally, when your effects target a Sphere which is can display VFX, you can specify one of the several VFX properties - DeckEffectsVFX, CreateVFX, DestroyVFX, DecaysVFX and MovementsVFX. They set VFX for all the effects of the same type, so, in case you need to have different VFX for the same type, you have to split either your recipe or your effect sets into groups.

Can only be displayed in Spheres of Category World (that's tabletop) annd Threshold (that's slots) - so it only makes sense to set VFX for action that'll take place in one of the Spheres of these types.

CardBurn, CardBlood, CardBloodSplatter, CardDrown, CardLight, CardLightDramatic, CardSpend, CardTaken, CardTakenShadow, CardTakenShadowSlow, CardTransformWhite, CardHide, Default, None

An auxilary entity that selects tokens from a given set (usually a contents of a Sphere) by a filter. Has two properties - "Limit" and "Filter" (similarly to Expulsion). "Filter" is a boolean expression and has to be defined, "Limit" is a number and can be an expression, sets the maximum amount of cards pulled by a filter, if not defined that amount is unlimited.
It's is a QuickSpec entity, and thus can be defined as a simple string - again, then there will be no limit.
Filter syntax examples:
{ "filer": "lantern", "limit": "1" } - "a single card with a lantern aspect"
{ "filter": "[lantern]>5", "limit": "forge" } - "cards with at least 6 of lantern intensity, amount of cards is up to the amount of forge aspect in the local sphere"
{ "filter": "lantern" } - "an unlimited amount of cards with lantern aspect"
just "lantern" - same as the above.