Сигнализация: конфигурация и скрипты

[vicente]

Сообщение от КЕ

Нет, проходной оставался открытым при реверсе.

Да, это так. Подзабыл, прошу прощения. Ровно 10 лет назад я нацарапал на заборе тестил эту функцию "чистым тестом" с блэкджеком и шлюхами с фотографиями (к сожалению, сайты давно почили в бозе, и много материала утеряно). Описание теста прилагаю полным текстом сообщения, за исключением скринов..

Скрытый текст:

Немного о функции*enabled

Данная функция является внешней функцией относительно скрипта. Мы знаем, что в скриптах есть функции внешние, то есть прописаны они в другом месте - ехе-файле симулятора и изменять в работе самой функции мы ничего не можем (см.мануал) и есть функции, которые, теоретически, может прописать разработчик сигнализации внутри самого скрипта (чем и занимаюсь сейчас для создания своего варианта одностороннего пропуска).
Итак, enabled.
Кужувский разработчик пишет:

Код:

Contains TRUE (non-zero) if the current signal instance is enabled to show
its natural state, or FALSE otherwise.


Это значит, что функция возвращает единицу, если светофор включен, чтобы показать его состояние, в противном случае - выдает 0.
То есть не все светофоры на маршруте работают по скрипту, а только те, которые находятся впереди и позади сервиса на определенном расстоянии. Расстоянием здесь является не километраж и не количество узлов, как в подготовке маршрута МСТС, а количество светофоров. Какое кол-во светофоров будут enabled перед сервисом (кстати, не важно сервис ли это игрока или трафик) мы задаем в файле конфигурации сигнала в параметре SignalNumClearAhead. Небольшой тест покажет наглядно как это работает.
Я поставил на перегоне проходные светофоры (модели Тимаса), прописав в них SignalNumClearAhead (2), обычные сигналы проходного 3АБ, а при функции enabled = 0, или правильней - !enabled - синий.

Результат - перед сервисом 2 светофора зеленые, остальные - синие - !enabled. Это понятно. Цель теста - выяснить, что с остальными светофорами на перегоне. У нас еще три направления. На скрине мы видим, что за занятым сервисом блок-участком светофор красный, то есть enabled. За этим светофором, против хода сервиса,как и положено желтый, а уже перед ним - !enabled - синий.
Что происходит с противоположной стороны?


Перед сервисом 2 светофора становятся enabled красный и желтый. Светофоры же позади него сразу же становятся !enabled - синие.
Интересно, что если я возвращаюсь назад, то светофоры по мере удаления от них остаются enabled - зелеными. То есть если я вернусь на 2 блок-участка, то впереди меня будет не 2, а 4 зеленых светофора. В обратном же направлении, направлении движения, ни один светофор enabled не становится.

Нужное место я выделил под спойлером в последнем абзаце

Добавлено через 30 минут

Сообщение от КЕ

Но если б можно было передавать аспекты "вперед" по ходу сервиса.... Мечты!

Ну, с MSTS уже вряд ли что можно сделать. Но, мечты сбываются в наше время в Open Rails , и это дело обещают/сделано уже там. Но, как поётся в песне, "того, что нужно нам, всегда на свете нет..." Прграммировать светофоры для этого нужно с С#, а я вообще не знаю его, и в жизни программированием не занимаюсь.

Сообщение от КЕ

Насколько надежно это работало?

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

[КЕ]

Сообщение от vicente

Прграммировать светофоры для этого нужно с С#...

В смысле - менять исходный код ORTS?

Сообщение от vicente

... Единственное- пришлось поднять SignalNumClearAhead , а я это очень не люблю. Но, маршрут - мой личный, ворочу чего хочу, в сценариях, естественно, я это учитывал.

Какое число было необходимым?

[vicente]

Сообщение от КЕ

Какое число было необходимым?

7

[vicente]

Сообщение от КЕ

В смысле - менять исходный код ORTS?

Нет. Исходный код меняют разрабы. Есть там определённая процедура изменения кода. "Открытость" состоит в том, что любой желающий может предложить изменения в коде, а команда вносит эти изменения в тестовые версии по своему усмотрению. Русификацию, например, делает твой "визави" на форуме Игоря... ну, тот, что в беседу тебя внёс на elvastower.com , ссылку на которую ты мне кинул
Речь идёт о замене sigscr.dat на программу на С#.

Кстати, молодёжь, кто знает Шарп? Я вообще в нем ни бум-бум!
Может кто-нибудь набрость какой-нибудь скрипт сигнальной головы? Я имею в виду перевод из этого недо-С в С#... Я бы глянул и смекнул: что к чему. Потому что самоучитель я ниасиливаю (стар?), да и времени, если честно - совсем на него нет. Туплю на азах, в общем.
Форма скрипта в с# такова:

using System;
using Orts.Simulation.Signalling;

namespace ORTS.Scripting.Script
{ public class MYSIGNALTYPE : CsSignalScript // мой сигнальный тип - название Signal_Head
{
public override void Initialize()
{
// Perform some initializations here, taking into account // that no route information is available at this point
}
public override void Update()
{
// Set the aspect of your signal here depending on route state } public override void HandleSignalMessage(int signalId, string message)
{} } }

[roman5]

Сообщение от vicente

Кстати, молодёжь, кто знает Шарп? Я вообще в нем ни бум-бум!

Да проблема не в языке, а в самом проекте, нужно ведь изучить сорцы OR, прочитать даташиты по их функционалу, что и как подавать в эти переопределяющие методы ovveride. Сам язык понять можно быстро по ютуб урокам.

Судя по всему вся логика в Update. А вот HandleSignalMessage это что не очень понял, то ли для отладки, то ли обмен инфой между сигналами.

[roman5]

Сообщение от vicente

Прграммировать светофоры для этого нужно с С#, а я вообще не знаю его, и в жизни программированием не занимаюсь.

Удобный язык для программирования, еще qt c++ мощная штука. В msts внешнее апи очень урезанное, даже под отладку нормальных возможностей не дали - из скрипта невозможно определить с каким из шейпов идет работа. Приходится извращаться: снимать user1-4 опции у нужных сигналов, чтобы получить уникальный набор future.

Я тут поборол сигналку на БМО 1.8. Покопав далее скрипт distance входных сигналов заметил такое:

if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) {
		WORK1 = opp_sig_mr ( SIGFN_NORMAL );
		if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_ONE_WAY = 1; }
		WORK1 = opp_sig_lr ( SIGFN_DISTANCE );
		if ( WORK1 ==# SIGASP_RESTRICTING ) { opp_POEZD = 2; } if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { opp_POEZD = 1; }
	}

	if ( sig_feature( SIGFEAT_GRADIENT_PLATE ) && !sig_feature( SIGFEAT_NUMBER_PLATE ) ) {
		if ( ( block_state() ==# BLOCK_OCCUPIED || POEZD !=# 0 ) && opp_POEZD !=# 1 ) { state = SIGASP_STOP_AND_PROCEED; }
		if ( opp_ONE_WAY ==# 1 || opp_POEZD ==# 2 ) { state = SIGASP_STOP_AND_PROCEED; }
	}

Оказывается для удержания направления перегона используют не только SAP в distance, но и SAP в normal проходных сигналов.

Глянул код голов normal у проходных, нашел это:

state = SIGASP_STOP;
	if ( sig_feature( SIGFEAT_NUMBER_PLATE ) && POEZD !=# 1 ) {
		if ( block_state() !=# BLOCK_CLEAR || POEZD ==# 2 || ONE_WAY ==# 1 ) { state = SIGASP_STOP_AND_PROCEED; }
	}

То есть, если сигналы включены, то distance POEZD = 0 по скрипту и занятые участки будут в normal SAP ставить.

А выше это в коде:

WORK1 = next_sig_mr ( SIGFN_NORMAL ); if ( WORK1 ==# SIGASP_STOP_AND_PROCEED ) { ONE_WAY = 1; }

Обеспечивает удержание sap на головах normal, где участки уже clear.

Направление перегона переключается не в Иванцево, а в Драчеево, то есть с другого конца, по редактору видно, что enable не дотягивает до входного, его скрипт не срабатывает. Попробовал увеличить вAPK_3AB_YGR_YW_DISTANCE параметр SignalNumClearAhead до 15. Теперь работает на тестовой сцене.