BlueSwift GridRescue - MT4/MT5 - user manual (Part 1)

#

Inputs

Description

Values & examples

1

Comment Rescue Strategy Note here

2

Turn ON/OFF Rescue?

Main toggle on/off for Rescue operation

True/False

3,4,5

#3 Scale RescueSettings for each 0.01Lot?

#4 [for scaling]Tracked GridEA’s starting lot

This group of settings allows user to universally scale the rescue parameters up /down for all rescue modes.

Scaling option – allow user to choose between 3 options:
 - No Scaling
 - By Grid Start Lot
 - From user-input

Use-case:  when user has grid starting at different lot size e.g. 0.03 instead of 0.01, user would need to manually update rescue settings (such as order size, drawdown trigger, profit-to-close level, etc.) for each rescue mode - which can be time-consuming and also may lead to sub-optimal settings (e.g. deviated from user's preferred rescue strategy). Using the Scaling option in the parameters window, user can quickly scale all the rescue metric by a factor - thus more flexible if user have different starting grid lots for each of their grid EAs

Options:

-        “No Scaling”: use the rescue setting below as it is

-        “By Grid Start Lot”: the rescue setting will be scaled by Factor computed base on the tracked grid EA start lot as follow:
ScalingFactor  = <<grid start lot >> / 0.01

For example if you put grid start lot = 0.05 then scaling factor should be 0.05 / 0.01 = 5. All the relevant settings like order’s size, profit-to-close in all the rescue mode will be scaled up by this factor

-        “From user-input”: simply scale up all rescue settings by the scaling factor input by user at field #5

6

Tracking EA's Symbol(s)-separated by comma (,)

List of Symbol which BlueSwift would operate on. Order's Symbol that not in this list will be ignore by BlueSwift

7

8

Tracking EA's Magic number(s) to rescue - separated by comma (,)

Example: 123,9999,5678

This allows GridRescue to manage multiple grid EAs on one account (e.g. one-chart setup)

9

Tracking both Stem and branch magic?

This option allow user to either:

-        track both the Stem magic basket as well as branching magic basket. i.e. “Start-with match”

-     Ignore stem magic, only track those magic as exactly provided by user’s input. i.e. “Exact-match”

True/False

For an example - there is 6 running orders with the following magic:

 Order #1: 1235300

 Order #2: 123551

 Order #3: 123551

 Order #4: 123551

 Order #5: 1232220

 Order #6: 123220

Assuming user set the Tracking EA Magic Number (field #8) above to be “123,123551”

If True, then there will be 2 baskets of grid being tracked:

  Basket 1: Order#1 - #6 (common Stem “123”)

  Basket 2: Order#2 - #4 (common Stem “123” and Branch “123551”)

If False, then only Basket 2 will be tracked because the magic “123” does not match any order’s magic

---------------------------------------------------------------------------------------------
❓ Common question: how do I know which basket is being tracked

Ans: Either check the on-chart’s dashboard or checking the “Expert” tab’s log message in the terminal, it will have a message which grid basket has been instantiated

On-chart Dashboard


Log message in 'Expert' tab

10 

Tracking EA Trade comment to rescue

Some grid experts on market use order’s comment to manage their order, because the orders maybe same symbol and magic number but with different comment. For example: ”grid_ea-M15” versus “grid_ea-H1”

------------------------------------------------------

11

12

Order count To Start Rescue

13 🚩

GridCluster's Profit to close ($)

2.1.1

Rescue Scheme

The scheme for the current iteration (i.e. 2-Node or 3-Node)

Options:

-   _default_,

-   _3node_only_,

-   _2node_for_less_than_7_orders_,

-   _2node_for_less_than_10_orders_,

-   _iteration_based_,

_default_: if grid’s size less than or equal to 4 orders then the default scheme is 2-Node, 5-10 is 3-Node

_3node_only_, always try to use 3-Node scheme, i.e. always form a cluster of three grid order and close them together at the Profit-To-Close

_2node_for_less_than_7_orders_: if grid’s size is less than 7 order than use 2-Node, and when 7 orders for more than use 3-Node

_2node_for_less_than_10_orders_: if grid’s size is less than 7 order than use 2-Node, and when 10 orders for more than use 3-Node

_iteration_based_, this option let user define specific Profit-to-close and the cluster scheme for each iteration with the syntax {scheme}:{profit-to-close} using #2.1.2, separated by comma. For example: if user put in “2:-1.25, 3:-2.50, 2:2.0, 3:-0.1”

which would means that

- 1st iteration: close 2 orders when their Profit-to-close = -$1.25

- 2nd iteration: close 3 orders when their Profit-to-close = -$2.5

- 3rd iteration: close 2 orders when their Profit-to-close = $2.0

- 4th iteration: close 3 orders when their Profit-to-close = -$0.1

So that user has complete freedom to instruct at which level of Profit-To-Close this mode should close and between 2-Node or 3-Node scheme. A best practice is to try a low, negative Profit-to-close at the early iteration and then gradually increase this amount for subsequent iteration so to avoid likelihood of deep drawdown and easier to close part of the grid at the early stage. For the _iteration_based_ option, the last iteration setting in the input will continue to be used until the whole grid is closed, so in the example above, the SubGrid Close bot will continue to close 3 orders at -$0.1 for the 5th, 6th, 7th … iteration etc.

----------------------------------------

*author note: most of the time, I use only _default_, _3node_only_ and _iteration_based_ due to personal preference, as I am not prefer to let my grid get to more than 5 running orders

2.1.2 🚩       

Iteration Mode and ProfitToClose (If select RescueScheme = _Iteration_based_)

The list of RescueScheme and Profit-To-Close for each iteration, separate by comma

{scheme}:{profit-to-close}

Example:

2:1.25, 3:2.5, 2:2.0, 3:2.0, 3:1, 3:1, 3:0.5, 3:0.5

(white-space between the comma will be automatically trimmed, so not to worry)

2.2.1

Use PanicClose Rescue Mode?

This is toggle to enable / disable PanicClose rescue mode

True/False

2.2.2

Order's count for PanicClose (0 = disable)

The number of order in the grid when you want the PanicClose mode to start execute rescue.

For example, if you set this to 5, then PanicClose would only start execute rescue when there are 5 or more orders in the grid. This is to avoid PanicClose being executed prematurely and reduce the opportunity for the whole grid being closed instead

2.2.3 🚩       

MaxDrawdown for PanicClose (0 = disable)

The level of Drawdown ($) when you want the PanicClose mode to start execute rescue

Same as above, PanicClose bot will not attempt to close orders until the grid’s drawdown has reached this level.

Example: if this set to -90, then PanicClose bot would start close TopOrder and Bottom Order (at the Profit-to-close defined) ONLY when grid’s drawdown is at -$90 or more (i.e. running profit of whole grid basket is -$90 or less).

2.2.4 🚩

MaxLotSize for PanicClose (0 = disable)

The Maximum lot size to determine if grid is in ‘Panic mode’.

Same as above, PanicClose bot will not attempt to close orders until the grid’s maximum lot size has reached this level

Example: If user set this to 0.12 then the tracked grid would be considered ‘Panic’ when an order with 0.12 lot size is opened

2.2.5 🚩

Profit level ($) for panic close

The sum of TopOrder and BottomOrder at which PanicClose bot woud close them

Can be negative – which would allow PanicClose at small loss

2.2.6

Position of 2nd panic order [0=Smallest order, 1=next grid order ...]

‘2nd panic order’ means the BottomOrder to be tracked together with the TopOrder. This allows user to pick an alternative designated ‘BottomOrder’ instead of the default one

This is used when the distance between the current Top and Bottom order in the grid is too far away which make it difficult for the their profit’s sum to reach the Profit-to-close level (in #2.2.5). Thus user can set an ‘alternative’ designated BottomOrder with a smaller distance, hence increase the chance for PanicClose bot to execute.

2.2.7 🚩

Reduce/Increase ProfiToClose in subsequent PanicClose

This toggle allow user to change the initial Profit-to-close for every subsequent PanicClose iteration, i.e. gradually increase /decrease (‘drift’) ProfitToClose value by each PanicClose iteration 

True/False

If True, the Panic’s initial Profit-to-close (defined in #2.2.5) will be ‘drifted’ by the amount (in #2.2.8 below) upward (if “+ve”) or downward (if “-ve”)

2.2.8 🚩

Step to reduce (-) or increase(+)

The ‘drift’ step by which the Panic Profit-to-close would be changed by

Example: Given that the initial Profit-to-close (#2.2.5) is -8 and #2.2.7 is True, if user set this to 6 then:

 - 1st PanicClose iteration: Profit-to-close = -$8

 - 2nd PanicClose iteration: Profit-to-close = -$2 (-8 + 6)

 - 3rd PanicClose iteration: Profit-to-close = $4 (-2 + 6)

 - 4rd PanicClose iteration: Profit-to-close = $10 (4 + 6)

and so on…

--------------------------------------------------------
Author Note: highly recommended to start the Panic’s ProfitToClose at a low level, negative even (like above example), for the first PanicClose iteration, and then gradually drift this value upward. This pattern will allow higher success rate for PanicClose to effectively reduce grid’s exposure when market price retrace and meanwhile still ensure subsequent iteration will earn back the initial loss, retaining the overall return of the grid

2.2.9 🚩

Min/Max Change to stop drift ProfitToClose

The total amount of change beyond which the drift would stop

This stop further drift of Profit-to-close when to total accumulated change from the step reached this amount.

Continue from the example in #2.2.8 above: if user set this to 12, then the drift will stop at the 2nd iteration because 6 (1st iteration) +6 (2nd iteration) = 12

2.2.10

IsPanicCloseBottomOrderIfBetter?

Instruction for PanicClose bot to compare the profit sum for default Top/Bottom pair alternatives

True/false

Given that the value in  #2.2.6 is not 0, i.e. the PanicClose pair is formed using the designated BottomOrder, then when this is True, PanicClose bot will compare the two pairs’ profit sum and pick the best one that reached current Profit-to-close: 

1. TopOrder + default BottomOrder 
2. TopOrder + alternative BottomOrder

This is for the scenario where the tracked grid Expert subsequent order opened might change the optimal pair between the (1) and (2), so that user won’t be ‘locked in’ by the choice he/she made in #2.2.6 above

The grid's Top-to-Bottom distance is tracked which then allow user to instruct GridRescue to scan all of the orders below the TopOrder to find a 'next best pairing' alternative to the currently designated BottomOrder. As a result, this helps rapidly reduce the grid's body cluster once market price cross above/below safe distance thresholds and the account's drawdown is 'contained' during large price movement.

This enhancement is extremely useful against unpredictable / highly-volatile markets like Gold (XAUUSD) or Indices instrument where a fast spike of 2000-3000 points in price is quite common which can quickly trap user in a large grid exposure, thus prevent giving back too much of the earned profit or margin call.

The setting for this option is in the following format

<Toggle Next-Best mode>:<DistanceStep>:<Position gap away from TopOrder>:<Panic’s Profit-To-Close adjustment>

Their individual functionality is explained below

2.2.12

Disable panic close after N time

This specify how many times BlueSwift would use Panic Close for a grid series. Once this limit has reached then BlueSwift would NOT continue to execute panic close. This is to avoid panic close being used too much and in case of negative profit to close (as specified above) would erode the profit earned by the tracked EA

Integer: 1,2,3,.. etc.,

Recommended values should be between 8 to 15 times