Да что ж из вас по слову нужно тащить, простите ради бога..

Беру элемент "Цена входа" -- в формуле умножаю его на конст- на выходе формулы "закр по стоп-лоссу".

1. Когда условная заявка уйдет брокеру.
2. При достижении ценой уровня заявки она сработает внутри бара?
3. Если скрипт выйдет из позиции по другой ветке кто снимет условную заявку на сервере брокера.

1. После первого пересчета, со второго бара, заявка будет у брокера и каждый бар пересчитываться, снимая последнюю ставя новую.
2. Да.
3. Брокер, кроме него никто не сможет. Алгоритм работает так: Нет позы, нет завок её закрывающих(+- пинги сервера и т.д. т.п.).

P.S. Быстрее поймете, если скрипт запустите на какой-нибудь недорогой фьючерс. Потеряете 50 рубл(а может и заработаете ), при этом информации будет куда больше, чем от любых объяснений.

В стандартном баре ничего другого нет. Для ФОРТС еще доступен Открытй интерес.
Но кроме того, тслаб умеет для каждого бара запоминать bid|ask на момент закрытия бара (правда это не сохраняется в кеше между перезапусками).
Кроме того, через API доступны все сделки для свечи (если они были накоплены)

Проблема (уже обсуждалась) не раз, что нельзя выставить по одной позиции больше 1й условной заявки. Поэтому будет выставлен либо стоп или тейк-профит.

можно сделать хоть 10 блоков, одновременно будет высталена одна заявка для позиции

Я же написал, после каждого пересчета будет приянто решение какую выставлять. Профит или стоп, которая ближе к текущей цене, та и будет выставлена. Например выставился стоп, если к следующему пересчету цена подкралась к тейк-профиту, будет выставлен он. Естественно эта модель "кривая", но без поддержки связанных заявок на сервере другой быть не может, т.к. нельзя гарантировать, что мы сможем снять вторую заявку при исполнении первой. Это должен делать сервер.

перед отправкой тейк-профита стоп будет снят. Разве это не понятно?

"Открытие лимитными заявками" - заставляет TSLab выставлять вместо условной заявки выставлять лимитную (если это возможно).

бид аск сохраняется, пока есть подключение к провайдеру. При сбросе подключения, теряется история. Пока у Вас есть эта история, этими данными можно пользоваться при оптимизации.

То есть автоматически эти параметры при оптимизации не учитываются!? Надо что-то прикручивать?

В справочнике примеров использования аск/бид тоже к сожалению нет.
Подскажите как пользоваться и на что влияет!? (желательно пример скрипта)

P.s. конкретно интересует как при тестировании и оптимизации учитывать параметры объема сделок (заявок) и вытекающую от сюда ликвидность: если взять скажем для примера самый неликвидный инструмент третьего эшелона то покупая его в любом количестве он будет закупаться по одной цене (той которая висит сейчас в баре) совершенно не двигая и не изменяя цену, не учитывая проскальзывание, которое может быть катастрофическим.

В настройках скрипта конечно есть выставляемые параметры проскальзывания, но я так понимаю при тестировании они не учитываются (только при работе на реальном счете)?!