# Scripting Migrations (/platform/algos/alert-scripting/migrations)



<MigrationUtility />

## v1 to v2 [#v1-to-v2]

The version 2 of our scripting language comes with the following changes:

* Multiple sequences can now be defined.

* Sequences can now be used with strategy scripting.

* Sequences are no longer constructed from one condition per line, instead the new `then` operator should be used.

* New `{any_inactive_step}` placeholder returning true if any step but the active one is true, can only be used for invalidation

* Actions `@invalidate` and `@set_step` have been replaced with their corresponding [methods](./actions-methods).

* Actions no longer require to have the argument name specified:

before: `@label(y = "{close}", text = "hello")`

now: `@label({close}, "hello")`

<Warning>
  Do note that the order of arguments needs to be respected. It is still good practice to specify action arguments names to avoid confusion.
</Warning>

* Actions argument values no longer requires to be in between quotes/double quotes.

<Tip>
  It is still good practice to use quotes for strings.
</Tip>

* y argument for `@label` and `@line` actions now support historical referencing.

* Action `@valuewhen` now accepts a new `reference` argument allowing to reuse the captured value in other conditions/actions.

* Removed `@filter` action.

### Migrating from v1 to v2 [#migrating-from-v1-to-v2]

#### Defining Sequences [#defining-sequences]

Scripted alerts using a sequence previously separated steps by linebreaks:

```
{close} > {open} // Step 1

{close} crossover {close[9]} // Step 2

{volume} crossover 10000 // Step 3
```

Now sequences can be defined inline using the new `then` operator as follows:

```
{close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000
```

#### Invalidating Sequences [#invalidating-sequences]

Previously sequences were invalidated using the `@invalidate` action:

```
{close} > {open} // Step 1

{close} crossover {close[9]} // Step 2

{volume} crossover 10000 // Step 3

@invalidate() = {close} < {open} // invalidate if closing price is lower than open
```

This can now be done inline using the new operator `!`:

```
{close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000 ! {close} < {open} 
```

Or using the new method `invalidate` as long as an udp is defined for the sequence:

```
{my_sequence}.invalidate() = {close} < {open} // Invalidation of {my_sequence}

{my_sequence} = {close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000
```

<Info>
  In V1 invalidation always took place first, as such we want `{my_sequence}.invalidate()` to appear first in the script.
</Info>

If your invalidation setup only affected specific steps such that you had:

```
@invalidate(step= 1,2) = {close} < {open} // invalidate if closing price is lower than open and active steps are the second one or third one
```

Then you can reuse a similar setup:

```
{my_sequence}.invalidate(step= 1,2) = {close} < {open} // Invalidation of {my_sequence}
```

#### Changing Step [#changing-step]

Previously users could change the active step of a sequence using the `@set_step` action:

```
{close} > {open} // Step 1

{close} crossover {close[9]} // Step 2

{volume} crossover 10000 // Step 3

@set_step(0) = {close} < {open} // Set step to 0 if closing price is lower than open
```

Now this can be done with the `set_step` action:

```
{my_sequence}.set_step(0) = {close} < {open} // Set step to 0 if closing price is lower than open

{my_sequence} = {close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000
```

<Info>
  In V1 setting a sequence step always took place first, as such we want `{my_sequence}.set_step(0)` to appear first in the script.
</Info>

The value argument still accept increments and decrements.

#### Accessing a sequence active step [#accessing-a-sequence-active-step]

Previously users could access the active step of a sequence (the step subject to evaluation) using the `{step}` placeholder.

Due to the possibility with version 2 of hacing multipe sequences in a single script, the active step can be obtained from a defined UDP for the sequence:

```
{my_sequence} = {close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000

// Get the active step for {my_sequence}
{my_sequence.step}.
```

#### Accessing a sequence elapsed bars since new step [#accessing-a-sequence-elapsed-bars-since-new-step]

Previously users could access the numbers of bars elapsed since a last step was true or invalidation of the sequence using the `{barssince_step}` placeholder.

Due to the possibility with version 2 of hacing multipe sequences in a single script, the active step can be obtained from a defined UDP for the sequence:

```
{my_sequence} = {close} > {open} then {close} crossover {close[9]} then {volume} crossover 10000

// Get the number of bars ellapsed since a last step was true or invalidation for {my_sequence}
{my_sequence.barssince_step}
```

#### Filtering each steps with @filter [#filtering-each-steps-with-filter]

Previously users could apply a condition to all steps of a sequence with a single usage of the `@filter` action as follows:

```
{close} > {open} // Step 1

{close} crossover {close[9]} // Step 2

{volume} crossover 10000 // Step 3

@filter() = {volume} > 5000 // Test for all steps if volume is above 5000
```

This can be done by having a UDP associated to this filter condition and using the and operators with it:

```
{vol_filter} = {volume} > 5000 
{my_sequence} = {close} > {open} and {vol_filter} then {close} crossover {close[9]} and {vol_filter} then {volume} crossover 10000 and {vol_filter}
```