Просмотр полной версии : Концепция "расписание"
Здесь делимся опытом в Timetable concept. Как мне кажется, вещь интересная и стоит отдельной темы.
Я, по правде сказать, вообще не понял как это работает. И что это. :D
Если создавать расписание, то это проще проехать в одиночке с записью времени. А данную программу я слышал, но она для сценариев больше делалась т.к. мстс считал по своему.
Ну я сценарии так и делаю .... сначало прохожу весь маршрут с определенной скоростью отмечаю время проследования .... накидываю +-3,4 минуты
Я, по правде сказать, вообще не понял как это работает. И что это. :D
Тема создана для того, чтобы разобраться и делиться опытом!
Если создавать расписание, то это проще проехать в одиночке с записью времени. А данную программу я слышал, но она для сценариев больше делалась т.к. мстс считал по своему.
Ну я сценарии так и делаю .... сначало прохожу весь маршрут с определенной скоростью отмечаю время проследования .... накидываю +-3,4 минуты
Лучше трафик прогнать и, либо следить за ним со свободной камеры, либо по окну диспетчера, или по HUD F5 (диспетчер), там даже лучше : он отставание от заявленного графика выдаёт.
Концепция создана для возможности реализаций реального расписания на реальных маршрутах. С нереальными надо "потанцевать с бубном", но, по мне - это то продолжение которым я собираюсь заниматься. Трафик у меня и так полностью круги описывает, а "расписание" даёт ещё кое-какие возможности, которых нет в Activity Mode...
В принципе, как только была анонсирована реализация манёвров и отцепок-прицепок локомотивов (пока лок отцепляется только если заданна смена направления с перегонкой локомотива в хвост, либо если состав состоит из нескольких consist-ов), я открыл эту тему и буду сам более серьёзно вникать в концепцию. Есть вещи, которые меня в ней привлекают больше, чем в Activity Mode: возможность смены направления и одновременной подмены ПС (хорошо для смены указателей маршрутов электричек, например или мгновенный "разворот на месте" лока с неанимированным передним пантографом и не прописанными задней кабиной, источниками света и т.п.), превращения отработавшего сервиса в статику и наоборот, можно задать сервису поехать в депо и ждать там продолжения работы и так далее...
vicente, хорошо бы записать вам видео о чем идет речь. Я по прочитанному плохо понял.
Здесь делимся опытом в Timetable concept.
Опыт негативный. Чего-то я там колупал. Давно было уже не вспомню. В результате ни с того ни с сего сломался маршрут "Степанки". Пришлось переустанавливать. Не знаю, связаны ли между собой эти 2 события, но вот такая штука приключилась.
Видео действительно помогло б
Не совсем понял. Видео чего?
Вы создали тему по программе расписания в ор. Данную прогу использовали в мстс, но в ор не знает ни кто как она себя ведёт и работает.
Вот и предложили вам снять видео по её работе в ОР. Так будет нагляднее и народ поймёт.
Эта тема создана для обсуждения концепции (способа) игры в OpenRails, которая называется Timetable mode. Это никакая не программа и она заложена в сам код симулятора. Ничего подобного в MSTS нет и, насколько мне известно, не было (могу ошибаться, "ткните носом").
Насчет видео, во-первых, мне тяжело дается каждый ролик, потому как я пожилой человек и "старовер" :D, посему из софта у меня только фрапс и пара редакторов, да и в этом я "плаваю"..
Поэтому и просил уточнить: что именно должно быть в этом видео .
Повторюсь: я только изучаю сабж, а так как "одна голова хорошо, а две (а желательно -- больше) -- лучше", и была создана данная тема.
Тогда понятно.
Вопрос такой. В какой из версий ОР данный код вшит, что бы можно было посмотреть на досуге?
И по поводу записи видео порекомендую вам программу OBS. Она записывает видео и на ютубе можно сразу сделать трансляцию онлайн. В ютубе вбейте как настроить программу OBS и там найдете подходящее видео, если не пойдет, то я помогу объяснить вам.
В стабильных точно есть уже. Раньше, в 0.9 тоже присутствовало. Не знаю точно с какой... Это основное направление в организации движения в OpenRails на сегодня, насколько я понимаю. Во всяком случае, Роб Ротердинк, который в команде занимается этими вещами (движение, светофоры), играет именно так и развивает именно эту "ветвь".
К слову, рекомендую сохранить текущию тестовую версию, на всякий случай -- грядут глобальные изменения в логике сигнализации. Неизвестно: как и что будет работать в Activity mode. Если что, обращайтесь. Я от раза к разу запасаюсь ими.
Прогу посмотрю в воскресенье, спасибо (выходные мои принадлежат супруге)
Я, по правде сказать, вообще не понял как это работает. И что это. :D
Базовые понятия "что это", "как это работает" и с чем его едят будут вкратце описаны в следующем посте.
Для того, чтобы играть в Timetable mode нужно сначала создать сценарий. Для этого существует Timetable editor в меню Toolshttp://storage3.static.itmages.ru/i/17/0316/h_1489667080_1874181_88f753f5ea.pngПри наведении мышки на кнопки в верхнем ряду, можно разобраться что к чему. Например, новое расписание создается левой кнопкой.http://storage7.static.itmages.ru/i/17/0316/h_1489667082_8518967_cea9be8330.pngЧтобы получить список станций, нужно выбрать файл *.tdb маршрута. Данный файл, как известно находится в папке маршрута, но с созданием первого сценария-расписания, он также копируется в папку ACTIVITIES маршрута в папку Openrails.http://storage8.static.itmages.ru/i/17/0316/h_1489667082_8216506_c0cc27baba.pngТуда же будут записываться файлы самого расписания и файл станций.
После выбора файла *.tdb нам будет предложен существующий файл списка станций с опцией его выбора либо опция создания нового списка.http://storage9.static.itmages.ru/i/17/0316/h_1489667083_8276198_2075242a38.pngЕсли файла списка станций ещё нет, сразу выведется меню создания такого спискаhttp://storage1.static.itmages.ru/i/17/0316/h_1489667084_1670742_c1fbdccfbe.pngСтанции можно привести к любой последовательности при помощи этих стрелок
http://storage1.static.itmages.ru/i/17/0316/h_1489667084_4803713_68b31211b5.pngПосле создания первого списка станций будет предложено создать папку OpenRails в папке ACTIVITIES
http://storage2.static.itmages.ru/i/17/0316/h_1489667084_3158455_34de2559fd.pngДобавлено через 1 час 41 минуту
Каждый сервис имеет свой состав (consist), который должен быть в папке CONSISTS симулятора, а также путь (path), соответственно, который должен быть создан и находиться в папке PATHS. Точки ожидания не поддерживаются, их использование приведёт к вылету при попытке запустить расписание. Есть группа команд, поддерживающихся симулятором. У каждой команды -- определённый синтаксис. Команды могут быть привязаны ко всему сервису или к определённой локации (станции). Например, можно заставить сервис дать приоритет другому сервису и он будет ждать этот дугой сервис. Если команда задана для сервиса (в поле note), то на станции, после которой у путей этих двух сервисов есть общая точка, светофор перед точкой этому сервису будет закрыт. Если команда задана на поле станции, ожидание произойдёт именно там и состоится обгон ожидаемым ожидающего.
По окончании пути сервис "пропадёт" как в Activity mode (или как в MSTS) только если ему не задано продолжение в поле dispose. В противном случае, он автоматически начинает выполнять новое расписание, к которому привязан в этом поле (либо становится статикой, если задана соответствующая команда)
Добавлено через 13 минут
http://storage2.static.itmages.ru/i/17/0318/h_1489874775_3724006_b2e7263130.png
Станцией (или локацией) считаются все одноимённые в грфе "название станции" платформы. Sidings не распознаются, а, так как действия с сервисами, привязанные к месту могут производиться только на станциях, все пути должны быть определены как пассажирские платформы. Это немного неудобно из-за такой штуки, как location linked passing path - выбор самим симулятором пути, на который приримается поезд, если путь, заданный в path занят другим поездом или статикой. Выход мне видится в разделении названий путей станций, оборудованных платформами и не оборудованных ими. К примеру к "грузовым" путям добавлять какой-нибудь значок
Время, вносимое в "соты" напротив станций может быть оформлено двумя способами. Во-первых, естественно, форма ввода врпмени ЧЧ:ММ в 24-часовом формате. Первый вариант -- вводится одно время. Тогда введенное время будет временем отправления. Второй вариант -- ввести два времени: первое будет временем прибытия, второе -- временем отправления. Между этими двумя используется дефис (-). В остальном в сценарии сервис ведет себя так же, как в Activity mode или в MSTS: остановка на станции, по окончании станционных операций -- сравнение времени с временем отправления и отправление. С той лишь разницей, что в вышеперечисленных на остановке время стоянки расчитывается по параметру "количество пассажиров" в свойствах платформы, а в Timetable concept поезд будет стоять на платформе столько времени, сколько задано в "минимальном времени остановки" в тех же свойствах.
DEPO_MINSK
20.05.2018, 23:17
Timetable вещь прикольная. Вообщем можно создать реальное движение поездов по служебным расписаниям в маршрутам созданных из реальных. Расписание поездов загоняем на все 24 часа. Играть начинать можно с любого поезда и трафик двигается по расписанию. Главное чтоб сигналка правильно работала.
Timetable вещь прикольная. Главное чтоб сигналка правильно работала.
:D
И добавить больше нечего...
https://youtu.be/-XuOyhXrLDY
Кондрат Сидорович
17.06.2018, 17:48
Видео по редактору Open Rail
Только вот не понял, как изменить масштаб маршрута
https://youtu.be/u3pRo20LRbI
Shimanski
25.12.2019, 02:06
Покопался я в timetable штука ПОТРЯСАЮЩАЯ!!!!
Жаль что на РП сигналка глючит в ОР.
А то уже давно бы запилил НГДП в timetable и было бы сценариев - дофига и больше.
Жаль, "руки не доходят" до этого всего. Там мало того, что реальное расписание можно запилить (для того этот режим и разрабатывался), в любом сценарии можно избежать "танцев с бубном": невидимок, точек ожидания, тестов на тему "прокатит - не прокатит" и вообще свнсти на минимум непредвиденного развития событий из-за поведения игрока.
Для тех, кто занимается Timetable, обратите внимание: несмотря на то, что движение поездов "круглосуточно" официально не поддерживается и, так же как в MSTS и Activity Mode после полуночи продолжают работать только сервисы, заявленные в предыдущие сутки, здесь есть два "трюка". Во-первых, команда $next в стартовой строке после времени старта должна стартовать сервис на следующие сутки, а не тогда, когда стартует сценарий. С этим я пока не игрался - у меня не было такой ситуации, когда это бы пригодилось. Второй вариант - старт сервиса "из другого сервиса". То есть, по командам в строке #dispose $forms, $triggers и вариантам с отцепками. В этом случае, $next не обязателен. Более того, стартовавший после полуночи из сервиса, стартовавшего до полуночи сервис выполняет расписание в новый день. То есть распознаёт время 00:30, например, и так далее.
Товарищи!
Кто-нибудь применяет команду /clouseup в поле #dispose? Поделитесь опытом! У меня в "отстойнике" не хватает места на остановку электропоезда "по умолчанию" - не заходит за сигнал, но до конца трека есть место, которое мне нужно. Так вот, во-первых, команда не работает с $triggers. С $forms она, да, работает, но образованный по $forms сервис при подаче на платформу благополучно проследует её до следующего светофора, останавливается (там красный), и только тогда выполняет свой #dispose поле.
Есть соображения?
Я понемногу пытаюсь разбираться. Мануал бы по-человечески на русский перевести... Глядишь, больше желающих попробовать появится.
Ну, сейчас, с карантином, может, и переведу.
На самом деле, штука довольно простая. Осваивается "во время движения". Основная проблема, как и с симулятором вообще - в нём постоянно "ковыряются". Причем много народа и в разных местах. В каждой новой "тестовой" версии, наряду с "плюшками", бывают "цепляют" то, что работает. Пару лет назад у меня вообще руки опускались. Я "подкрутил" сигнализацию под ORTS, всё работало, потом они начали улучшать её с полным изменением принципов работы. А, возыращаться к тому, что уже сделал и переделывать... сами понимаете. А проблемы устраняют только те, которые считают нужным сами. Помимо, когда-то разработчик APK_LDVZ им писал и требовал учитывать наши "танцы с бубном" с сигнализацией, они "покрутили пальцем у виска" и мягко "отшили" его. С другой стороны, они с год назад "трахнули" в том же Timetables команду $triggers, я и ещё один, кажется, парень потребовали вернуть - сразу же сделали. В принципе, то, что я написал - баг. И, если этот вопрос поднять - сделают (может, так и сделаю). Просто я проблему решил вчера не заводя состав за сигнал. У меня был конфликт двух встречных маршрутов сервисов (вечный красный обоим) и я думал, что маршрут встречному построен из-за того, что этот самый электропоезд меняет направление не по сигналам, а значит переходит на NODE mode. Но, проблема была не в этом и установка приоритетов сервисов её решила.
Не знаю, доберусь ли я до перевода даже руководства по командам для Timetable - там два десятка страниц печатного текста. Тем более, что сам я ещё далеко вначале - делаю пока пассажирское пригородное расписание - то есть отцепки-прицепки не тестировал.
Поэтому буду потихоньку обсуждать команды. Может, кому пригодится.
Итак, описаная мной проблема:
У меня есть конечная станция двух пригородных маршрутов с одной платформой. За платформой есть отстойный тупик (два, на самом деле, со стрелкой, ограждённые светофорами). Есть поезд, который прибывает на платформу с двухпутного перегона, высаживает пассажиров и отправляется в отстойник. Там он ожидает пока на платформу прибывает ещё один поезд, другого маршрута, тот производит посадку-высадку и отправляется в обратный путь. Ожидающий поезд после этого возвращается на платформу, производит посадку и должен отправляться. В это время на подходе к станции - ещё один поезд того, второго маршрута. Таким образом, во входной горловине происходит обычное классическое скрещение.
Проблема в том, что этот отстаивающийся поезд состоит на самом деле из 4-х сервисов:
1) 6160 (я им даю номера поездов) - сам поезд, делающий свой маршрут до этой конечной станции - в поле #dispose - $forms=0-6160
2) 0-6160 - с платформы в отстойник. У него другой Path . В принципе, можно делать один Path до отстойника, но так как у меня в отстойнике разъезд, я предпочел разделить их. В поле #dispose - $triggers=0-6161
3) 0-6161 - подача из отстойника на платформу под следующий поезд - 6161. В поле #dispose - $forms=6161.
Так вот, когда этот самый "многострадальный" пригородный на платформе, к станции подъезжает ещё один пригородный - 6058. Из-за особенностей сигнализации, она позволяет автодиспетчеру "собрать" маршрут на занятый путь (на платформу). Нужно поставить приоритет поезду 6161 перед поездом 6058, чтобы скрещение произошло на входном сигнале на станцию (по расписанию 6058 даже не останавливается у входного, но если ему заперт маршрут, он остановится там, а 6161 не сможет отправится - так как маршрут на стрелках - "не его"). Делается это с помощью команды $wait=<train>. Команда эта может быть вписана либо в поле локации (локация здесь и далее - название станции) или в поле #note. Разница в том, что первый способ гарантирует скрещение в указанном месте, а второй - на первой по пути обоих сервисов "совместной" секции пути. Естественно, по ситуации и светофорам. О чем я? Я поставил $wait в поле предпоследней остановки - о.п., находящимся на перегоне перед предвходным. То есть между сигналами "4" и "2". Это ничего не меняет. Скрещение будет всё равно на входном, потому что именно он ограждает первую со стороны 6058 стрелку, по которой проходит и Path 6161. Несмотря ни на что, даже после установки $wait=6161 в указанном месте, скрещение не срабатывало, 6058 упорно прокладывал себе маршрут на занятый 6161-м путь и оба сервиса "застрявали" на "вечном красном". Причина, оказалось, в том, что 6058 успевал "проложить" себе маршрут в горловине до того, как 6161 "появился" из 0-6161! То есть, сама по себе "голая" команда $wait не действует, если сервис на момент, когда другой сервис воздействует на ограничивающий стрелку светофор не стартовал в расписании. Разработчик это учёл и добавил в программу "индикаторы", можно назвать их "уточнения". Они вносятся сразу после команды через косую черту.
Для команды $wait таких уточнений 4:
/maxdelay
/notstarted
/owndelay и
/atstart
Для моей задачи нужен второй "индикатор" - /notstarted. Когда он установлен, при приближении сервиса к точке скрещения, симулятор "проверяет" должен ли указанный сервис "появиться" в продолжение процесса расписания, и если да - останавливает поезд для скрещения - то есть, не собирает ему маршрут на нужной стрелке.
Я установил $wait=6161/notstarted в локации перед входным на станцию и всё заработало так, как мне нужно.
Когда б ты за это взялся, если б не карантин?
/maxdelay=<n>
...где n - минуты.
Симулятор высчитывает опоздание сервиса относительно заданного расписания. Так вот, этот параметр задаёт условие максимального опоздания в минутах, при котором $wait будет работать. Если опоздание будет большим, чем указано, команда не сработает.
/owndelay=<n>
...где n - минуты.
Относится к разнице между опозданиями сервисов, заданных командой. Ожидание сработает, если разница в опозданиях ожидающего и ожидаемого сервисов будет больше указанного за знаком равенства значения. То есть, если задано "10", а сервис опаздывает на 12 минут, скрещение произойдет. Но, если одидаемый сервис, в свою очередь, будет опаздывать на 5 минут, то разница в опозданиях будет всего 7 минут и $wait не сработает.
/atstart
Не совсем понятная команда. Разработчик разъясняет, что эту команду нужно применять если ожидаемый сервис появляется на той же станции, что и ожидающий "и у них нет возможности разъехаться" . Я не знаю: где и как это применимо. Я так не играю в симулятор.
Спасибо, за разъяснения.
Меня вопрос мучает: маневровое что-то реально сделать? Я так и не понял. :D
И, это какая конкретно сигналка? Строю роут, планирую для него делать расписание. Что лучше ставить?
Сами по себе манёвры должны работать. Есть команды на отцепки-прицепки, там различные варианты. Ничего ещё не тестировал. Дело в том, что я играл в симулятор на подобии "расписания". То есть, у меня сервисы трафика не появлялись и исчезали перед игроком, как делают это в сценариях, а были построены на весь маршрут их поездов. То есть, могли быть трафики, которых я даже мог не "видеть" в игре. В MSTS это была мука, в ORTS Activity Mode оно "пошло" и довольно неплохо работало. Около года назад там что-то "сбилось" именно с манёврами. До этого я цеплялся за Activity Mode из-за открытия-закрытия дверей у трафиков на остановках, даже когда реализовали в Timetable манёвры, но что-то там пошло не так. Может, у меня сбилось, потому что, представьте себе: как оно - сделать манёвры в Activity: надо подгадывать по времени... прибывает состав, отцепляется лок, другой лок "возникает" или с точки ожидания по времени заходит под состав. Всё это с большим трафиком, есть скрещения, сигналка работает, кто-то где-то задержался и - всё - лок цепляет "воздух" и вместо поезда на маршруте - одиночный локомотив, вагоны стоят на пути вместо того, чтобы освободить его и т.д. В Timetable такого произойти по определению не может. Потому что команда указывает кто и с кем сцепляется, от кого отцепляется и что потом с каждой частью пооисходит.
Короче, оказалось, что не только меня привлекает такая манера игры, но и одного из основных разработчиков, делающих ORTS, голландца Роба Ротердинка. Он-то и разрабатывает Timetable Mode.
Добавлено через 6 минут
Так что, сейчас я занимаюсь тем, что перекладываю то, что у меня было в Activity на Timetable. Сегодня-завтра закончу с МВПС и перейду на локомотивы с манёврами. Отпишусь по командам.
Насчёт сигнализации.
Сигнализацию пришлось руками переделывать под Open Rails. Начинал с сигналки Адамайтиса, потом добавил объектов, позаимствованных у Кости Елисеева.
Логику всю переписал сам, чтобы работало.
Олег, а что, в новой версии опять все плохо со светофорами?...
Костя... Только хотел "направить" товарища к тебе за сигналкой. Захожу, а ты - тут как тут! :D
Да, нет. Я с лета не открывал его, сейчас скачал новую версию после того, как проехался на старой. Моя сигналка работает на все 100% на всех версиях. Это ты писал (http://www.trainsim.ru/forum/showpost.php?p=587802&postcount=99) что-то год назад. Я не проверяю существующие версии на работоспособность. Мы уже обсуждали этот вопрос. У разработчиков ОР нсть принципы, от которых они не готовы отступать и я смирился с этим. Их тоже можно понять: каждая новая версия должна позволять всем маршрутам, включая дефолтные, работать с точки зрения сигнализации. На сегодняшний день есть очень много новых возможностей. Программа под ОР находится в своей папке, отдельно от MSTS и одно другому не мешает. Около года назад возможности сигнализации в ОР были довольно серьёзно расширены. Но, на то, что уже работало оно не должно влиять, если те правила, о которых мы когда-то говорили, были соблюдены. У меня они соблюдегы и всё работает. Хочется верить, что когда-нибудь я таки доберусь до этих возможностей и сделаю своей сигналке "апгрейд". Например, я так и не смог в своё время определить разницу между маневровым маршрутом на свободный путь на станции и поездным. Не было технической возможности сделать это. И у меня на занятый путь манёвры идут по белому, а на свободный - по синему (хотя аспект, естественно, разрешающий). Есть ещё пара "штрихов", которые я специально оставил для удобства тестирования. У меня когда путь занят , а поезд у входного, на маневровом за входным горит белый. Визуально, мне так было удобней определять: почему не открывается входной. Сегодня надобность в таком "несоответствии" реальности отпала.
Но, сначала, я хочу сделать расписание. Потом буду править сигналку. По большому счету, она работает вполне удовлетворительно. Есть разные мысли как её улучшить под Timetable. В принципе, направленность разработчика по сигнализации именно на Timetable. Потому что это тот же самый разработчик. :D
Есть идея сделать условно-разрешающий сигнал. Раньше меня эта идея не привлекала, потому что нельзя было сделать отдельно логику для грузовых поездов. Сегодня можно наделить поезд функцией Call_On и для поездов с этой функцией давать другой аспект (разрешающий). То же самое и с пригласительными.
Всё упирается во время. Успеть бы до конца карантина восстановить то, что у меня было в Activity Mode и перенести это в Timetable. Если успею, "поковыряю" и сигналку.
В принципе, из официальных, у тебя, я так понимаю, самая работоспособная сигнализация. Помоги товарищу с маршрутом :)
Ну не сказал бы что прям самая работоспособная... вот сейчас для "Лесногорск-2" ее доделываю, а то недостатки вылезли...
А условно-разрешающий пробовал делать, он был на state= 2;. Но не проверял, так как свой гордый горный маршрут похерил по неосторожности...:confused:
Нет, Костя. Речь идёт именно о Timetable Mode.
Можно задать сигналу зависимость if (TrainHasCallOn () ), дать ему в этом случае на занятый путь 2, и тогда поезд, у которого в Timetable в этой локации определено CallOn будет получать 2, а остальные - 0. Штука разработана для приёма поезда на занятый путь в оригинале. Но, я думаю, что для пригласительного - самое то. Не обязательно давать занятость. А, вот, на перегонах надо проверять: как оно работает. Я тут выше писал, что задал $wait за несколько блок-участков до входного, на котором хотел это самое ожидание получить и сработало. Мне кажется, что так будет работать и с этой функцией. В принципе, CallOn-ом можно "наградить" сервис на всём протяжении пути в графе #note, но тогда на эту функцию нельзя будет "посадить" и условно-разрешающий и пригласительные. Потому что, на подъемах такой поезд будет проезжать по условно-разрешающим, но на станциях (если все входные запрограммировать на callOn, а это то, что я собираюсь сделать) будет ВСЕГДА получать пригласительный.
Добавлено через 9 минут
А условно-разрешающий пробовал делать, он был на state= 2;.
Проблема в том, что если просто задать 2 на занятый путь, его будут проезжать ВСЕ сервисы. А нам нужны только грузовые. Да, и то - не все, а только тяжеловесные.
Добавлено через 3 минуты
Ни MSTS, ни Activity Mode такой возможности нам не дают. Только Timetable
Интересно, что получится, когда тяжелый грузовой, проходя по условно-разрешающим, догонит впередиидущий обычный состав?
Выполнит предписания ПТЭ и остановится. Метрах в 50 где-то. Open Rails может работать без светофоров вообще.
Добавлено через 11 минут
Когда-то, очень давно, я запустил на Marias Pass такой трафик, что грузовые шли с интервалом то ли 10 то ли 15 минут. Сигнализация там - вообще безбашенная. Все проходные светофоры, были с условно-разрешающими "платами" (Gradient и Number). Нет, кажется ВООБЩЕ ВСЕ. Так там поезда "пронзали друг друга" :D
В ORTS такого нет. По определению, можно вообще без светофоров ездить. Никто ни с кем не столкнётся.
Я описывал два дня назад свою ситуацию, когда электропоезд не заходит за сигнал в отстойнике. Так там он начинает движение к платформе, когда на платформе другой электропоезд. Ничего. Потихоньку подъезжал и останавливался, как я уже сказал, метрах в 50-ти. Потом, когда предыдущий отъезжал - возобновлял движение
В принципе, CallOn-ом можно "наградить" сервис на всём протяжении пути в графе #note...
Важная поправка!
Нельзя задать CallOn в графе #note! Прошу прощения . CallOn задаётся в графе остановки сервиса в локации. Сейчас пробежался по мануалу команд. Там однозначно дана только такая опция.
По поводу манёвров. Timetable поддерживает точки разворота. То есть путь сервиса (path) может включать их в себя. Точки ожидания не поддерживаются. Ожидание делается с помощью команд (я уже описывал команду $wait). Но, когда сервис разворачивается, автоматически добавляется время ожидания - 0.5 сек на метр длины. В оригинале это сделано, чтобы симулировать переход бригады из кабины в кабину. В маневровой работе это неактуально. Чтобы "шант" не простаивал на точке разворота нелогичное время, нужно добавить команду $REVERSE /ADDITIONAL = 0
Меня вопрос мучает: маневровое что-то реально сделать? Я так и не понял. :D
Запилил сейчас акт сцены со сменой локомотива. Работает шикарно. Преимущество перед Activity Mode очевидно: там нужно очень точно "подгадывать" по времени что отеуда отцепляется и что куда прицепляется. Малейший сбой в движении (а, оно у меня - просто адское) и локи "цепляются" к воздуху, двухсекционники расцепляются и т.д и т.п. Timetable учитывает опоздания, различные изменения непредвиденные... но прицепка-отцепка будет всегда к тому, что прописано.
Товарищи!
Кто-нибудь применяет команду /clouseup в поле #dispose? Поделитесь опытом! У меня в "отстойнике" не хватает места на остановку электропоезда "по умолчанию" - не заходит за сигнал, но до конца трека есть место, которое мне нужно. Так вот, во-первых, команда не работает с $triggers. С $forms она, да, работает, но образованный по $forms сервис при подаче на платформу благополучно проследует её до следующего светофора, останавливается (там красный), и только тогда выполняет свой #dispose поле.
Есть соображения?
Дополнительная команда /clouseup в поле #dispose работает только с $forms и $static согласно мануалу.
Так что, вопрос снят.
http://i.piccy.info/i9/ec8778c7e8b6fc256afa02d2e747cbe3/1587018681/14598/1373151/RunActivity32_2020_04_16_09_14_55_500.jpg (http://piccy.info/view3/13757732/146926c0ff7cd8fb5d7b6874800786b0/)http://i.piccy.info/a3/2020-04-16-06-31/i9-13757732/472x354-r/i.gif (http://i.piccy.info/a3c/2020-04-16-06-31/i9-13757732/472x354-r)
Вот такое расстояние между поездами трафика. Конечно, и в Activity Mode можно привести к подобной ситуации "шаманскими танцами с бубном", но, здесь поезда трафика находятся на стартовой позиции. И на самом деле их там три, один за другим, на одном пути.
http://i.piccy.info/i9/a6d8995b59d31cbb185aa8854bf24fde/1587027801/12473/1373151/RunActivity32_2020_04_16_11_59_00_500.jpg (http://piccy.info/view3/13757982/81e46033e9cceae07b8ee72c40946672/)http://i.piccy.info/a3/2020-04-16-09-03/i9-13757982/472x354-r/i.gif (http://i.piccy.info/a3c/2020-04-16-09-03/i9-13757982/472x354-r)
А, вот эти два "товарища" находятся в позиции #dispose с применением команды и идентификатора $static/closeup. Полезная вещь, если речь идёт о депо, как на скрине, или нужно запихнуть побольше ПС, скажем, в тупик.
Добавлено через 44 минуты
Смена направления может быть задана двумя способами: точка разворота в Path или команда в поле #dispose, когда сервис в одном направлении перестает существовать, а "из него возникает" другой сервис посредством команды $forms или $triggers. В обоих случаях нужно быть внимательными со стрелками, которые становятся противошерстными после разворота. Если ПС не проследовал полностью стрелку за точку узла, движение не возобновится даже в случае, если нет надобности в переводе этой стрелки для обратного движения. То есть, если состав "освободил" pin-ы стрелки с одной стороны, и не проехал pin с другой - есть проблемы. Я столкнулся с такими случаями дважды (двумя описанными способами) и в обоих случаях трафик "застрявал" и не продолжал движение.
Вообще симулятор пытается учесть и стрелки и светофоры в случае разворота. Если стрелка защищена светофором, ORTS позаботится о том, чтобы весь состав проследовал его независимо от того, где находится точка разворота Path или конечная точка той его части, которая "туда" в случае с #dispose. В случае, когда светофоров нет (деповские пути, заводские и т.д.) сим постарается "завести" сервис за стрелку. Проблема может возникнуть в случаях если недостаточно места для состава (в тупике) или, если за указанной стрелкой есть ещё одна стрелка - если точка разворота не находится за всеми pin-ами той стрелки, трафик останавливается перед узлом. В этом случае "решает" отодвигание точки разворота. Не бойтесь отодвинуть её дальше. Симулятор "развернёт" трафик на нужной вам стрелке, не выполняя "лишних" движений до фактической точки разворота на Path.
Насчёт сигнализации.
Сигнализацию пришлось руками переделывать под Open Rails. Начинал с сигналки Адамайтиса, потом добавил объектов, позаимствованных у Кости Елисеева.
Логику всю переписал сам, чтобы работало.
Олег, можешь скрипты выложить, чтоб поизучать, как там что надо писать?
SignalTypes ( 290
SignalShapes ( 171
Которые из них? :D
Да, и смысл? У нас принципиально разные подходы к самой концепции сигнализации в симуляторе. Тебе неприемлема "многоголовость", мне - эти "шины" с DISTANCE и т.п. Потому, в своё время, я и отошёл от Open Source, когда она пошла в том направлении, которое мне неинтересно.
А, серьёзно - насчет скриптов - мне не жалко. Но, чем тебе поможет, скажем, входной светофор, который работает по следующему за ним маневровому, который тоже NORMAL? А, маневровый - по следующему маневровому с иным скриптом или по невидимому светофору РЦ на противоположном выходном... Мы когда-то всё это обсуждали (не помню уже где - надо искать) и я всю свою "религию" в этом вопросе расписывал.
Сейчас я "долблю" Timetable, сигналка - потом. Там есть много "вкусняшек" новых под ОР, я ничего не применял ещё. По большому счёту, кроме некоторых добавок в версии под ОР, типа signalflags (OR_NOSPEEDREDUCTION) , ApproachControlSettings и т.п., она ничем не отличается от МСТСовской. Вернее, то же самое. но без дополнительных функций, которые работают в ОР, а МСТС на их присутствие в конфигурации ругается и вылетает у меня работает и в МСТС. Так что ответ на сегодняшний день - точно так же, как и в МСТС.
Буду рад ответить на все возникшие вопросы в теме (http://www.trainsim.ru/forum/showthread.php?t=13819) о сигнализации. Ну, по крайней мере, что вспомню. Уже несколько лет не трогал её.
Написал в теме.http://www.trainsim.ru/forum/showthread.php?p=592474#post592474
Олег, а что, в новой версии опять все плохо со светофорами?...
Моя сигналка работает на 100% на всех версиях.
Блин. Таки сломали мне что-то, редиски :D
Скорее всего, разные значения SignalNumClearAhead не воздействуют на функцию enabled() как раньше. Работало таким образом, что получив enabled() , светофор уже не сбрасывал его пока сервис его не проедет. Сейчас, похоже, сигнализация строго придерживается значения SNCA светофора перед поездом. Естественно, аспекты "понижаются" , часто, когда поезд уже на блок-участке.
Для Timetable мне это не ломает всё. В проблемных местах я ставлю $hold на станциях и это держит мне первый светофор после платформы (выходной или маршрутный) в закрытом аспекте (0). Так что придётся ковыряться в ней. А, я ещё подумывал , что может не трогать. :(
Спасибо, за разъяснения.
Меня вопрос мучает: маневровое что-то реально сделать? Я так и не понял. :D
Реально. Есть даже не один способ это реализовать.
wBIvsdKXjTw
На видео - состав прибывает, ему запланирована остановка в 18 минут, от состава отцепляется локомотив, формируясь в новый сервис, и уходит в депо. Из депо выезжает сменный локомотив и заезжает под состав и поезд отправляется по графику и продолжает свой путь.
Есть другой вариант отцепки-прицепки. В данном случае можно было проложить путь сервиса в депо, прописать, что сервис отцепляет вагоны на платформе. Другой сервис выезжает из депо на платформу, забирает статический состав (то, что оставил предыдущий) командой $pickup/static и продолжает с вагонами.
Классный видос. Сигналка, судя по всему, срабатывает корректно?
Predator
01.06.2020, 00:24
Реально. Есть даже не один способ это реализовать.
Ну это вообще классно! :cool:
Вот так понемногу и "раскуриваем" Open Rails.
А можно ли изменить скорость сервису, указав нужные значения команд в расписании?
Сигналка, судя по всему, срабатывает корректно?
Куда ж она от меня денется? :cool:
А можно ли изменить скорость сервису, указав нужные значения команд в расписании?
OR использует некоторые конкретные значения скорости для трафиков в определенных ситуациях, например, минимальная скорость при приближении к сигналу («скорость ползучести»), скорость при присоединении поездов и т. д. Кроме того, существуют ситуации, когда поезда обычно движутся со скоростью, несколько ниже допустимого максимума, и только когда поезд опаздывает, он движется на максимальной скорости. Это определение называется «крейсерская скорость». Можно указать эти значения для отдельных поездов. Обратите внимание, что такие ограничения не распространяются, если поезд формируется в другой поезд, то есть, его колонка в расписании перестаёт действовать.
Как устанавливать?
В "шапке" - там, где определяется сервис, его консист, путь и т.д. добавляется строка с заголовком
#speed: скорость задается в м / с. #speedkph: скорость задается в км / час.
или
#speedmph: значения скорости в милях / час.
Настройки скорости, которые можно определять в этой строке:
#max Общая максимальная скорость Значение по умолчанию
#cruise Нормальная крейсерская скорость. Действует только в сочетании с командой #maxdelay. #maxdelay Максимальная задержка (в минутах) для крейсерской скорости.
#creep Скорость при приближении к запрещающему сигналу.
#attach Скорость при соединении с другим поездом.
Прямая ссылка на документ по командам Timetable Mode.
http://www.elvastower.com/forums/index.php?app=core&module=attach§ion=attach&attach_id=96641
Добавлено через 7 минут
Дополнительные команды и изменения в концепции качаем отсюда: http://www.elvastower.com/forums/index.php?app=core&module=attach§ion=attach&attach_id=77330
Немного непонятно в документе с командами описана эта команда. Там перед таблицей указывается, что все единицы - в секундах. Во втором документе указано, что единицы n для этой команды сек/метр. На самом деле n - количество секунд, которое умножается на метр длины ПС. Результат - время ожидания. То есть, для того, чтобы 20-метровый локомотив ожидал минуту в точке разворота, нужно задать в поле #restartdelay - $reverse /additional = 3
Как я писал (http://www.trainsim.ru/forum/showpost.php?p=593945&postcount=49), есть два способа расцепить сервис:
1. Отцепить ПС, оставив его как статический состав путем (например)
$detach = nonpower/static - отцепляются все единицы типа Wagon и остаются статикой на месте. То, что отцепилось, продолжает работать под тем же названием, что было задано в расписании. В этом случае нам не поможет для присоединения команда $attach = <сервис> . Нужно прописывать $pickup/static.
2. $detach/power/forms = <новый сервис> - отцепит ТПС от сервиса, сформирует из него новый сервис как определено в команде $forms, а оставшаяся часть сохраняет своё наименование и продолжает выполнять то, что определено в расписании.
Проблема в том, что, очевидно, эта самая часть "сохраняет" и то, что было задано в оригинальном файле .con. А, как известно, составы трафика передвигаются именно согласно данных, заложеных там.
Именно поэтому у меня вагоны после отцепки локомотива поехали сами , когда пришло время отправления, несмотря на то, что в консисте не было ни одной единицы, определённой как Engine
Количество сервисов в расписании перевалило за 500
https://i.ibb.co/XWGkpPL/20210117-164536.jpg (https://ibb.co/XWGkpPL)
Если кто заметил, второй раз за последние 4 месяца в программе появляется баг с вылетом при формировании поезда игрока в следующий поезд (команда $forms, а также при присоединении по команде $attach , когда поезд перестаёт существовать и игрок должен продолжить с поездом, к которому он прицепился, также я сам лично "вылетал" при выполнении команды $detach/.../forms).
В очередной раз баг пофиксили. Вышла специальная версия OR NY MG 88.1, цель которой - ликвидация данного безобразия. В следующей тестовой тоже будет исправлено.
vBulletin® v3.8.12 by vBS, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot