Концепция "расписание"

[vicente]

Нет, Костя. Речь идёт именно о Timetable Mode.
Можно задать сигналу зависимость if (TrainHasCallOn () ), дать ему в этом случае на занятый путь 2, и тогда поезд, у которого в Timetable в этой локации определено CallOn будет получать 2, а остальные - 0. Штука разработана для приёма поезда на занятый путь в оригинале. Но, я думаю, что для пригласительного - самое то. Не обязательно давать занятость. А, вот, на перегонах надо проверять: как оно работает. Я тут выше писал, что задал $wait за несколько блок-участков до входного, на котором хотел это самое ожидание получить и сработало. Мне кажется, что так будет работать и с этой функцией. В принципе, CallOn-ом можно "наградить" сервис на всём протяжении пути в графе #note, но тогда на эту функцию нельзя будет "посадить" и условно-разрешающий и пригласительные. Потому что, на подъемах такой поезд будет проезжать по условно-разрешающим, но на станциях (если все входные запрограммировать на callOn, а это то, что я собираюсь сделать) будет ВСЕГДА получать пригласительный.

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

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

А условно-разрешающий пробовал делать, он был на state= 2;.

Проблема в том, что если просто задать 2 на занятый путь, его будут проезжать ВСЕ сервисы. А нам нужны только грузовые. Да, и то - не все, а только тяжеловесные.

Добавлено через 3 минуты
Ни MSTS, ни Activity Mode такой возможности нам не дают. Только Timetable

[vicente]

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

В принципе, CallOn-ом можно "наградить" сервис на всём протяжении пути в графе #note...

Важная поправка!
Нельзя задать CallOn в графе #note! Прошу прощения . CallOn задаётся в графе остановки сервиса в локации. Сейчас пробежался по мануалу команд. Там однозначно дана только такая опция.

[vicente]

Test

[vicente]

[IMG][/IMG]
Вот такое расстояние между поездами трафика. Конечно, и в Activity Mode можно привести к подобной ситуации "шаманскими танцами с бубном", но, здесь поезда трафика находятся на стартовой позиции. И на самом деле их там три, один за другим, на одном пути.

[vicente]

[IMG][/IMG]
А, вот эти два "товарища" находятся в позиции #dispose с применением команды и идентификатора $static/closeup. Полезная вещь, если речь идёт о депо, как на скрине, или нужно запихнуть побольше ПС, скажем, в тупик.

Добавлено через 44 минуты
Смена направления может быть задана двумя способами: точка разворота в Path или команда в поле #dispose, когда сервис в одном направлении перестает существовать, а "из него возникает" другой сервис посредством команды $forms или $triggers. В обоих случаях нужно быть внимательными со стрелками, которые становятся противошерстными после разворота. Если ПС не проследовал полностью стрелку за точку узла, движение не возобновится даже в случае, если нет надобности в переводе этой стрелки для обратного движения. То есть, если состав "освободил" pin-ы стрелки с одной стороны, и не проехал pin с другой - есть проблемы. Я столкнулся с такими случаями дважды (двумя описанными способами) и в обоих случаях трафик "застрявал" и не продолжал движение.
Вообще симулятор пытается учесть и стрелки и светофоры в случае разворота. Если стрелка защищена светофором, ORTS позаботится о том, чтобы весь состав проследовал его независимо от того, где находится точка разворота Path или конечная точка той его части, которая "туда" в случае с #dispose. В случае, когда светофоров нет (деповские пути, заводские и т.д.) сим постарается "завести" сервис за стрелку. Проблема может возникнуть в случаях если недостаточно места для состава (в тупике) или, если за указанной стрелкой есть ещё одна стрелка - если точка разворота не находится за всеми pin-ами той стрелки, трафик останавливается перед узлом. В этом случае "решает" отодвигание точки разворота. Не бойтесь отодвинуть её дальше. Симулятор "развернёт" трафик на нужной вам стрелке, не выполняя "лишних" движений до фактической точки разворота на Path.