Просмотр полной версии : Система сигнализации sU и система маршрутизации zxPath
Просто интерфейс для настройки связки триггеров и всё. Зачем это привязывать к переезду? И делать скрипт переезда? Связка триггеров - и есть переезд (логический), а также разводной мост, обвальное место, - в общем любые препятствия, которые ограждаются заградительными и светофорами прикрытия.
TRam_, если даже хоть одна стрелка будет с ошибкой то сигнализация работать не будет?:sorry:
---------- Сообщение добавлено в 19:45 ---------- Предыдущее сообщение размещено в 19:35 ----------
......и еще вопрос,как переименовать стрелку? пробовал не получается.
---------- Сообщение добавлено в 19:54 ---------- Предыдущее сообщение размещено в 19:45 ----------
http://savepic.org/4362970m.jpg (http://savepic.org/4362970.htm)
в смысле не получается? Нажми на неё в списке, выбери, а карту сохрани с перезаписью (чтоб стрелка сохранила это изменение). И по поводу стрелок - пиши в соответствующей теме
---------- Сообщение добавлено в 23:31 ---------- Предыдущее сообщение размещено в 23:31 ----------
если даже хоть одна стрелка будет с ошибкой то сигнализация работать не будет?работать будет, только не будут работать маршруты проходящие через эти стрелки
Петрович
26.08.2013, 14:19
Столкнулся со следующей ситуацией:
http://savepic.org/4377184m.jpg (http://savepic.org/4377184.htm)http://savepic.org/4375136m.jpg (http://savepic.org/4375136.htm)http://savepic.org/4376160m.jpg (http://savepic.org/4376160.htm)http://savepic.org/4382304m.jpg (http://savepic.org/4382304.htm).
Посмотрел видеоурок по настройке маршрутизации, пытался починить - не получилось. Помогите разобраться что к чему.
насчёт первой стрелки - там левер находится перед кружком соединения. Лучше всего это видно, если смотреть на стрелку "строго вертикально сверху".
Насчёт per6 - возможно там разрыв пути. Попробуй придвинуть триггер ближе к леверу (прямо вовнутрь стрелки) - возможно ошибка исправится (в этом случае надо будет переуложить пути - в них разрыв)
Петрович
26.08.2013, 15:26
насчёт первой стрелки - там левер находится перед кружком соединения
А где он должен быть? Я ставил его перед соединением рельсов , на соединении, но опять вскакивает эта ошибка.
---------- Сообщение добавлено в 15:26 ---------- Предыдущее сообщение размещено в 15:24 ----------
Кстати, per6 починилась только тогда, когда поставил ближе триггер, хотя разрыва не было.
Я ставил его перед соединением рельсов , на соединениинадо за соединением
Петрович
26.08.2013, 15:40
http://savepic.org/4349542m.jpg (http://savepic.org/4349542.htm)
Я что-то не понимаю, как ставить согл. картинке?
Кстати, per6 починилась только тогда, когда поставил ближе триггер, хотя разрыва не было.видимо стрелка какая-то корявая. Почти 100% уверен, что если поставишь точно так же триггер на стрелке Vit.8 , то ошибка уйдёт. Но проблемы это не исправит - разрыв пути на противошёрстном "прямом" направлении однозначно есть... А значит ни маршрута построить, ни открытия светофора на него скорее всего не будет.
Я что-то не понимаю, как ставить согл. картинке?перед. У тебя правильно поставлен.
Вопрос такой,в редакторе все маршруты добавляются и собираются,а когда начинаешь играть,собранный в редакторе маршрут не работает,а так же не собрать новый маршрут,кроме одной станции....:wacko2: будка ZX находится в сессион лаер.
попробуй эту будку удалить и поставить заново.
Спасибо,все работает!....и еще вопрос сколько и на какое расстояние можно собрать маршрут(маршрутов)?:smile2233:
Пока не вылезет ошибка.
Если вылезет - убери часть маршрутов, добавляй ещё одно правило AddPath , и добавляй в него.
То есть если правил несколько, то маршрутов может быть сколько угодно.
Если я таки доделаю алгоритмы заградительных, то как мне тогда быть с маневровым БСК ? Он может быть как "заградительный+маневровый без поездного режима", так и "маршрутный+маневроый"... И соответственно должен при этом по-разному настраиваться.
Эм... А в чём тут вопрос? Настройка и будет отличаться тем, что один "типовой светофор"+"маневровый без поездного режима"+"заградительный", а другой "типовой светофор"+"выходной/маршрутный"+"маршрутно-разделительный". Да, это требует разделения флагов. А насчёт управления заградительными надо думать. Но ясно одно - их надо объединять в группы. ИМХО, было бы лучшим вариантом, если бы внешний скрипт мог влиять на группу. Тогда скриптовать переезды можно было бы отдельно.
tepaniko
30.08.2013, 07:02
TRam_, слушай, ты не занешь где взять команду задать маршшрут на вход, проход, вход-выход для su ? просто она считает длину состава и пути, что удобно. или где она была я не могу вспомнить ?
tepaniko, по-моему, это было у Эрендира. Но он их в свет ещё не выпустил. Только у тестеров. Хотя, я могу ошибиться - может уже выпустил?
Да, это команды ботомашиниста.
tepaniko
30.08.2013, 23:26
Да, это команды ботомашиниста.
Просто странно что я не могу ее увидеть, вроде в правилах она стоит но в меню команд ее нет, там есть твоя от su
tepaniko, NickLon уже сказал что она есть только у тестеров Ботомашиниста. В свободном доступе её (в варианте для sU ) нет, есть только для z7 и z7-xPath (которая с zxPath не совместима). Здесь - https://trainzup.com/?p=3544
Волковысский
03.09.2013, 21:41
Был сегодня на станции Старый Петергоф (от станции там, правда, остались одна стрелка, пост и подъездной путь) и увидел такой вот странный светофор:
http://i.piccy.info/i7/3866c6be047f7018402eaef138a00180/4-76-544/15345246/CAM00335_800.jpg (http://piccy.info/view3/5079721/5625b8a5bbd0ebe9b053cab860d75a65/1200/)http://i.piccy.info/a3/2013-09-03-17-17/i7-5079721/566x755-r/i.gif (http://i.piccy.info/a3c/2013-09-03-17-17/i7-5079721/566x755-r) http://i.piccy.info/i7/7738a1f874c323382d0b4a31e69655f8/4-76-549/19673656/CAM00337_800.jpg (http://piccy.info/view3/5080239/ee9d348278a3bce7236938b735977815/1200/)http://i.piccy.info/a3/2013-09-03-18-34/i7-5080239/566x755-r/i.gif (http://i.piccy.info/a3c/2013-09-03-18-34/i7-5080239/566x755-r)
Что это такое? Бывший выходной, переделанный в заградительный? Да название странное какое-то: "8 4".
Teplovozz
03.09.2013, 22:38
Был сегодня на...
А при чём тут сигнализация sU? Объясни, старичёк.
Волковысский
03.09.2013, 23:29
Не знаю, может быть захотят потом реализовать подобную штуку в sU.
Извиняюсь, если оффтоп. Разрешаю списать на мой старческий маразм. :wacko2:
tramwayz
04.09.2013, 00:22
Поверь, маразм вовсе не у тебя.
Чтоб реализовать его, надо знать, как он работает, что показывает. Он вообще горит? Переезд может там есть?
B.U.G.O.R.
04.09.2013, 01:00
Это скорее бывший групповой.
Это скорее бывший групповой.
Для 8-4 путей? Странно же. Восьмёрка очень хочет стать буквой З или она была ей когда-то. Мозголомство сплошное. Надо создать тему головоломок на жд, ну и каждый будет писать свои варианты.
Волковысский
04.09.2013, 22:42
Он вообще горит? Переезд может там есть?
Не, горящим его никогда не видел. Но, однажды, когда с подъездного выезжал поезд, находящийся перед этим светофором проходной загорелся жёлтым. Наверное, он работает как заградительный. Я был далеко, и оттуда не видно было, горел он или нет.
Переезд есть, но в 800-х метрах оттуда. Там стоят нормальные заградительные.
smoothevgen
04.09.2013, 23:39
а можно будет сделать функцию светофор не работающим? Или сделать как объекты? И еще вопрос насчет текстур, будут ли ржавые светофоры?
dmitriy123
09.09.2013, 22:33
Здравствуйте. Столкнулся тут с проблемкой: цель- сделать так, что бы на перегоне не ловил код путевого светофора при полуавтоблокировке, пробовал и так и эдак, всё равно предупредительный работает как проходной и весь перегон АЛСН ловит код зелёного огня. Подскажите пожалуйста,можно ли сделать отсутствие кодов на перегоне?
dmitriy123, в настройках светофора поставить переключатель кодирование в положение "нет кода" и использовать лок с АЛСН поддерживающей все возможности sU. На сегодняшний день это только 2ТЭ121-021 выложенный на этом сайте.
antikiller_bm
10.09.2013, 09:31
Ну када там уже новые светофоры пойдут?
TRam_, привет! А ты разве не делал так, чтобы маршрут разбирался и стрелки, участвующие в маршруте, переводились в исходное положение только после того, как последний вагон проследует обратный светофор? Маршрут из стэка ДПС действительно убирается только по проследовании поезда светофора, а вот стрелки переводятся по мере освобождения.
И ещё. А почему светофор открывается, когда от него собран маршрут, но поезда перед ним нет? Грузовой следует на боковой, чтобы пропустить по главному пассажирский. Он ещё и половиной длины состава на станцию не зашел, а с главного пути выходной для пассажирского горит зеленым глазом. Да и вообще, как-то странно. Если выход с главного свободен на момент сборки маршрута, то он собирается и светофор открывается. То есть проверка возможности сборки маршрута "перепрыгивает" через впереди идущий грузовой, хоть и на боковой. Хвост то у него не то, что на главном, за метров 500 до входного даже. Который, кстати, красный.
dmitriy123
10.09.2013, 11:21
только 2ТЭ121-021
А как же ДМ62-1796? Там, на сколько мне известно, реальзовано кодирование Su и фильтр АЛСН.
OlegKhim
10.09.2013, 11:23
Вся серия тепловозов М62 будет обновляться вместе со всеми пасс вагонами, вернее уже обновляется.
А почему светофор открывается, когда от него собран маршрут, но поезда перед ним нет?
А какое отношение имеет наличие ПС перед светоформ для его открытия?
А как же ДМ62-1796? Там, на сколько мне известно, реальзовано кодирование Su и фильтр АЛСН.
Частично. Там самая первая версия нового АЛСН, и работает немного неверно. Но в данном случае, ты прав, код от светофора с отключённым кодированием приниматься не будет.
А какое отношение имеет наличие ПС перед светоформ для его открытия?
Я, наверное, немного неверно сформулировал. Действительно, если отсутствует поезд на, скажем, станции, но ему запросто может собраться транзитный маршрут по главному пути, то наличие поезда перед выходным не требуется. Но открытие выходного без наличия поезда на пути и закрытом входном - это нонсенс. Тем более, если входная горловина вообще занята прибывающим на боковой путь поездом.
Здесь ещё один момент. Прибывающий на боковой путь может ещё и не пройти входной светофор, то есть, не закрыть его, а за ним пассажирский уже проедет триггер, по которому собирается транзитный маршрут по станции. Здесь тоже не должно ничего открывать применительно для пассажирского, пока не будет свободен маршрут.
Да, забыл ещё упомянуть. Это касается правил zxAddPath и zxAddAnyPath. Команды, вроде бы, на такое не способны. Они если видят впереди поезд, то Задать маршрут от закрытого просто будет тянуть поезд вперед пока не выполнится, а Подготовить маршрут в такой ситуации вообще всё неверно сделает.
---------- Сообщение добавлено в 13:54 ---------- Предыдущее сообщение размещено в 13:17 ----------
Кстати, я никак не въеду что означает кодирование съезда "от светофора" и "к светофору"? Объясните, пожалуйста!..
Ну "от светофора" это понятно, когда, например, от входного. А в каких случаях "к светофору"?
1) zxAddAnyPath должна работать так же как и команда. Там алгоритм один и тот же. Просто не забывай их настраивать "лесенкой" (подчинённые будут собираться последними).
2) чтобы zxAddPath собирала маршруты по очереди, используй опцию добавления маршрутов "очередь". Это есть в обучающем видео №4
3) "от светофора" - между входным светофором и выходным обратного направления. "к светофору" - участок между входным и предвходным
4) когда светофоры - не знаю, у меня весь сентябрь экзамены в аспирантуру.
Кстати, я никак не въеду что означает кодирование съезда "от светофора" и "к светофору"? Объясните, пожалуйста!..
От светофора - кодирование сигнала между входным и стоящим за ним выходным при заезде на станцию
К светофору - кодирование сигнала от выходного до стоящего тылом входного при выходе со станции
Работает только с 2ТЭ121 и ещё не вышедшими машками.
1) zxAddAnyPath должна работать так же как и команда. Там алгоритм один и тот же. Просто не забывай их настраивать "лесенкой" (подчинённые будут собираться последними).
Про очередь я совершенно забыл. А вот как построить лесенку с правилом Overtaking at trackside (OAT)?
Строю "лесенку".
-Правило OAT (условия: триггер; расстояние 10000; "и не первого приоритета" - нет галки; "Выполнить..." - нет; "срабатывает ..." - есть; "сонаправлено..." - есть)
--zxAddPath
-Правило OAT (условия: триггер; расстояние 10000; "и не первого приоритета" - есть; "Выполнить..." - есть; "срабатывает ..." - есть; "сонаправлено..." - есть)
--zxAddPath
Оба варианта правила только для грузового. В первом случае он идет на боковой, во втором - по главному. Следуют три поезда друг за другом. Грузовой, Пассажирский1, Пассажирский2. Все три поезда проходят нормально. Пассажирский2 отпускает грузовой с бокового, т.к. за ним вообще ничего нет.
Стоит поменять в первом случае zxAddPath на zxAddAnyPath все поезда считают себя грузовыми. То есть, происходит сборка на боковой. Это, наверное, в особенностях правила? Если оно один раз активировалось, то теперь будет выполняться всегда? А zxAddPath - ничего подобного. Один раз выполнилось и ждет срабатывания ещё раз.
В чем тут фишка - не пойму.
---------- Сообщение добавлено в 01:13 ---------- Предыдущее сообщение размещено в 00:11 ----------
чтобы zxAddPath собирала маршруты по очереди, используй опцию добавления маршрутов "очередь".
Переключатель опций не работает. Точнее, он не влияет на порядок построения маршрутов в правиле zxAddPath. Если, конечно, не имеет значения что в каком порядке сделано: сначала маршрут задан, а потом переключатель включен или наоборот. Да и положения переключателя редактор не сохраняет.
Ant.taranish
11.09.2013, 10:09
Переключатель опций не работает.
Работает, но очередь маршрутов, как я понимаю, можно задать только в пределах одной станции, маршруты по разным станциям не будут зависеть друг от друга. Как пользоваться: задаешь первый маршрут по станции, потом выбираешь "в очередь" и задаешь следующие за ним (помечаются ^)
Например, две очереди маршрутов для разъезда на однопутке:
от Н до Н1
от Ч2 до Ч@станция А^
от Ч до Ч2
от Н1 до Н@станция Б^
1 и 3 маршруты начнут собираться сразу, 2 и 4 - только после сборки предыдущего в списке
Да, предположение такое у меня было. Вчера уже не стал проверять - поздно уже было.
Теперь бы с zxAddAnyPath в совокупности с Overtaking at trackside разобраться. Можно, конечно, только на переменных всё построить, но тогда будет как в анекдоте "Уймись, отрок, а то ты мне так на х... всю физику построишь!" Всё-таки, если есть ружье, оно должно стрелять.
А задача тоже не тривиальная. По одной из станций нужно, чтобы пассажирским не только грузовые уступали дорогу, но и МВПС тоже уходил на свой боковой, пока не пройдут скорый (скорые).
Всё-таки, если есть ружье, оно должно стрелять.в случае Overtaking at trackside - ружьё может быть с погнутым дулом. Когда я его делал, не проверял, сможет ли оно правильно срабатывать несколько раз подряд. Потому что большинство аурановских правил предназначены для одноразового использования.
В zxAddAnyPath пришлось довольно много помучаться, чтоб "лесинка" срабатывала правильно сколько угодно раз. То есть отличие от "стандартных аурановских правил" в плане перезапуска при повторном срабатывании - примерно 50%.
---------- Сообщение добавлено в 11:13 ---------- Предыдущее сообщение размещено в 11:04 ----------
Если оно один раз активировалось, то теперь будет выполняться всегда?
1) в опциях этого правила не должно быть выставлено "добавлять непрерывно"
2) я не знаю как оно сработает в паре с Overtaking at trackside, так как делал Overtaking at trackside на основе дефолтных (см. выше)
1) в опциях этого правила не должно быть выставлено "добавлять непрерывно"
А ты это о каком правиле щас говорил? М приведенной тобой моей цитате я вел речь про zxAddAnyPath. Оно у меня срабатывало когда надо и когда не надо. А срабатывать постоянно, так это в правиле Overtaking at trackside. Кстати, проверю, сработает ли оно второй раз на грузовой.
И вот ещё, разъясни, пожалуйста, толком какую роль в AddAnyPath играет триггер? Если я его не укажу вообще, то что будет? Откуда он станет, если станет вообще, собирать вариантный маршрут? И я никак не въеду, как можно строить лесенку из этих правил, если правилу требуется триггер?
Для каждого из правил zxAddAnyPath нужен свой триггер. + Overtaking at trackside также триггер. Итого 3 триггера, идущих один за другим (чтоб поезд последовательно на них наезжал).
Активированное правило zxAddAnyPath включает срабатывание при наезде поезда на её триггер. Это необходимо, чтоб понять, какому поезду строится маршрут (и его можно было отличить от впередиидущего). При наезде поезда на триггер запускается тот же алгоритм, что и для команды. Также при этом "подчинённым" правилам проводится перезапуск, и требование запоминать поезда, проследующие по ним, но не срабатывать. Далее.. Когда нужный маршрут правило соберёт, оно даёт разрешение подчинённым правилам на срабатывание, а если поезд по ним уже проехал - сработать сразу же и собрать для него маршрут.
---------- Сообщение добавлено в 13:23 ---------- Предыдущее сообщение размещено в 13:15 ----------
Если не делать подчинённые правила, то все эти правила найдут один и тот же закрытый светофор и все дружно будут пытаться его открыть. В результате одна откроет, а остальные, убедившись, что "светофор открылся без них", завершатся без открытия маршрута.
---------- Сообщение добавлено в 13:28 ---------- Предыдущее сообщение размещено в 13:23 ----------
Естественно очень нежелательно было бы, если поезд, следующий за нашим, наезжал бы на первый триггер до того, как нашему поезду построят маршрут. Потому что все правила zxAddAnyPath резетнутся и забудут о нашем поезде (и не построят ему маршрут).
Всё. Отбой. "По небу пролетела злая птица Обломина". Overtaking at trackside больше одного раза за сессию не работает. Блин, надо ж до такого додуматься то, чтобы одноразовые правила штамповать! Одно слово - туземцы.
---------- Сообщение добавлено в 17:45 ---------- Предыдущее сообщение размещено в 17:23 ----------
ЗЫ: И на переменных, как ты мне советовал делать, так, как на правиле не получится сделать. Вот смотри.
Регистрация события, что к станции, на которой настроена возможность обгона несется пассажирский осуществляется по триггеру, например, за 10 километров до триггера, по которому и определяется какой маршрут поезду следует собрать. Если возникнет связка Грузовой-Пассажирский-Грузовой-Пассажирский, то возникнет коллапс. Первый грузовой уйдет на боковой путь на станции. А пока первый пассажирский отпустит грузовой с бокового, второй пассажирский в свою очередь тоже успеет зарегистрироваться о том, что он едет к станции. Таким образом, первый пасс не отпустит с бокового грузовой, а второй грузовой застопорит движение на перегоне...
Таким образом, первый пасс не отпустит с бокового грузовой, а второй грузовой застопорит движение на перегонеэто только в том случае если у тебя всего один путь для обгона. А ведь на этот случай можно использовать остальные свободные пути станции (в том числе с "неправильной" стороны). Или у тебя станция имеет только 1 путь для обгонов?
Потому что по логике оба грузовых должны стоять, пока пассы не пройдут.
это только в том случае...
Вов, извини, я тебя перебил.
Это только в том, случае, если при наличии безумно правдоподобной поездной внешней сигнализации (sU я имею виду; OlegKhim тоже от тебя в этом плане не отстает) отсутствует механизм хоть какой-нибудь диспетчеризации движения поездного состава!
Маршрутизация - да, есть такое дело. Особенно в отличие от z7: varz так и ушел в тень, не закончив то, что задумывал.
Но здесь так и просится эволюционирование (блин, я сам, что-ли это слово придумал) уже существующего!.. С помощью переменных сделал. Но, блин, у меня мозги едва не вскипели, когда я высчитывал какими числами нужно оперировать, чтобы не повторилась уникальная ситуация расположения составов по станции. В результате - только в четном направлении одной станции 47 строк правил! В том числе и "лесенками".
Это я к чему всё это тебе выписываю - диспетчеризация нужна!
tepaniko
12.09.2013, 14:03
Поясни как расставить правила и триггеры, чтобы грузовой пропустил пассажирский и затем отправился с бокового ?
у меня получилось его отправить на боковой, но вот отправить с боковго не пойму чего то
tepaniko, а, это целая эпопея. Особенно, если у тебя два боковых используются. Но под катом (а то много букафф получилось) расскажу простой случай, когда в качестве обгонной станции используется 4-х путная станция двухпутного участка пути. Для этого нужно три триггера и одна переменная, ну и наборы правил TRam_'а, манипулирования и сравнения переменых.
Триггер, по которому собственно и происходит сборка маршрутов я ставлю в зависимости от того, скольки-значная сигнализация используется. На 3-х значной ставлю недалеко перед пред-предвходным проходным светофором. В четном направлении - это 4. Кстати, имей ввиду, что направление триггера не очевидно, когда ты его ставишь на пути. Поэтому перед триггером сначала я ставлю маркер, куда он острием будет направлен, значит туда и триггер будет направлен. Убираю маркер и туда же ставлю триггер.
Так вот, на примере станции Балабаново в четном направлении. Перед 4-м проходным ставлю триггер BLB C In, можно расшифровать как "Балабаново четный входной" (в именах не использую русские символы; пережиток прошлого в Trainz, но так уже привык), а за, к примеру, 7 км. до него ставлю триггер для фиксации подхода к станции пассажирского поезда. Например, BLB C Pass In. Далее ставлю правило Trigger Check Enhanced (это тоже усовершенствованное TRam_'ом Trigger Check, там что-то с направлением было не то вроде), в нем прописываю в Vehicle Types те типы локомотивов, на которое это правило должно сработать. А, да, ещё переменную правилом VariableAdd заведи, например blb_c. Ты, наверное, знаешь, что переменные, то ли все, то ли заведенные только этим правилом имеют по умолчанию значение 1. Так вот, по триггеру BLB C Pass In пассажирский увеличивает (Variable Modify в подчинении Trigger Check Enhanced) эту переменную на 2. blb_c стало равняться 3. Тем временем, впереди идущий грузовой, когда наезжает на триггер BLB C In проверяет переменную больше ли она 2. Если да, то собирает входной путь на боковой и увеличивает переменную ещё на 1. Теперь она стала 4. Дальше грузовой доедет только до выходного красного. А вот когда пассажирский наедет на BLB C In, он себе собирает входной и выходной маршруты по главному.
А вот третий триггер находится за входным светофором станции, за св-ром Ч в данном случае. Он тоже реагирует только на пассажирские. Например, BLB C4 Out, то есть, отправка с 4-го бокового. Ивот когда пассажирский наезжает, в подчинение ставлю "лесенку":
Уменьшить blb_c на 2
-Если blb_c = 2
--AddPath Ч4-Ч (ставит маршрут в очередь)
--уменьшить blb_c на 1. (грузовой чуть позже отправится и путь освободит)
Для чего это нужно, сначала увеличивать на 2 переменную, а потом, перед проверкой её уменьшать тоже на 2. Всё дело в том, что если к моменту, когда пассажирский проедет входной светофор, сзади может уже подходить ещё один пассажирский. Он то и увеличит переменную на 2 и первый пассажирский не соберет выходной маршрут грузовому.
Но здесь есть существенный недостаток. Что если идут 2 подряд грузовых, и позади них пассажирский успел увеличить переменную на 2. Выхода 2. Либо высчитывать математически расстояние между триггерами с учетом максимальной скорости грузового и пассажирского, либо ломать голову со множеством проверок переменной в лесенке. Я пошел по первому пути.
---------- Сообщение добавлено в 16:39 ---------- Предыдущее сообщение размещено в 16:35 ----------
Ну и домашнее задание. Видел станцию Апрелевка на маршруте tramvayz'а Москва-Малоярославец? Так вот, в четном направлении там можно на два боковых принимать грузовые. Да ещё в придачу на Ч5, тоже в бок, отправить электричку. И как потом это всё хозяйство правильно поставить и отправить со станции? Вот это то у меня и заняло 47 строк правил.
tepaniko
12.09.2013, 15:47
Вот это сильно !
А если сделать так
Поставить маркер для правила OverTrackside чтобы на нем сработка произошла
после него ставим триггер для подчиненного правила addanypath с приоритетами на боковой
потом перед выходным с бокового ставим триггер для правила addanypath с приоритетами на отправку и для определенного локомотива.
В самом простом случае это прокатит
Вот в предыдущих постах от trama про лесенку я не очень понял как она реализуется с правилом addanypath
---------- Сообщение добавлено в 16:45 ---------- Предыдущее сообщение размещено в 16:43 ----------
47 строк !!!! это просто ни в какие ворота. Нет, конечно замечательно что есть такие головы которые понимают как это расписать, но
логично было бы уже что то сделать с этим - я намекаю про твое замечание насчет Диспетчеризации
---------- Сообщение добавлено в 16:47 ---------- Предыдущее сообщение размещено в 16:45 ----------
может еще как то БОК к этому прикрутить
Это я к чему всё это тебе выписываю - диспетчеризация нужна!а почему проиритетами маршрутов не пользовался, и правилом AddAnyPath ?
tepaniko
12.09.2013, 16:03
TRam_, пояни пожалуйста как совместить два правила для пропуска поезда ?
OTR и addAnyPath
вопрос как лесенку построить вообще из нескольких правил
и как лесенку сделать из правил AddAnyPath? у меня не получилось
---------- Сообщение добавлено в 17:03 ---------- Предыдущее сообщение размещено в 17:01 ----------
Я там выше описал свою концепцию как это работает, но что то где то упустил как кажется
может еще как то БОК к этому прикрутить
Потому что БОК - это команды машинисту, а не правила. Поезд под управлением игрока не использует же команды. А я хочу, чтобы в какой лок ты бы ни сел, маршруты у тебя сами бы собирались.
Поставить маркер для правила OverTrackside чтобы на нем сработка произошла
Overtaking at trackside больше одного раза за сессию не работает.
а почему проиритетами маршрутов не пользовался, и правилом AddAnyPath ?
Да ладно приоритеты. Я что-то так и не въехал в твою "лесенку". Поясни, пожалуйста, на конкретном примере.
tepaniko, А ответ на задание довольно прост. Первое использовать несколько переменных. Но тогда, наверное, не 47 строк будет. А второе решение - найти такие числа, сумма которых будет уникальна для любого конкретного случая. У меня это 2, 3, 4 и 6.
tepaniko
12.09.2013, 16:17
Я тут еще подумал, а как организовать пропуск пассажирского если впереди него два грузовых идут ? даже если такго не бывает, это интересно можно реализовать вообще ?
потом перед выходным с бокового ставим триггер для правила addanypath с приоритетами на отправку и для определенного локомотива.
Кстати, подсказка. На выход не обязательно использовать AddAnyPath. Выход всё равно в подавляющем большинстве случаев будет на входной следующей станции. Достаточно будет AddPath. Даже если и маршрутник присутствует.
---------- Сообщение добавлено в 17:33 ---------- Предыдущее сообщение размещено в 17:27 ----------
Я тут еще подумал, а как организовать пропуск пассажирского если впереди него два грузовых идут ? даже если такго не бывает, это интересно можно реализовать вообще ?
Да реализовать то конечно можно, но вот с практической точки зрения...
Если предположить, что разница в максимальной скорости грузового и пассажирского (100 и 120, например) 20 км/ч, то овчинка выделки не будет стоить. А если разница ещё больше, например, как по умолчанию на светофорах ставится 120 и 80 то тогда надо будет вообще контролировать приближение пассажирского километров 10-15 назад, чтобы случился коллапс. А оно надо? Грузовые в этом случае только то и делать будут, что пропускать пассажирские.
Sandrilyon
12.09.2013, 18:53
NickLon, я вот только в толк не возьму - зачем все делать правилами? Я прекрасно обходился командами с переменными, все работало как часы, поезда прибывали, отправлялись и даже стояли под двойным обгоном.
:ps: Надо будет свой туториал выложить, давно уже хотел. ;)
зачем все делать правилами? NickLon хочет, чтоб одними и теми же поездами мог управлять и бот, и игрок.
Лично же я рассчитывал правила исключительно под игрока. Поэтому там и сделан выбор локомотива.
---------- Сообщение добавлено в 19:00 ---------- Предыдущее сообщение размещено в 18:54 ----------
На выход не обязательно использовать AddAnyPath в том случае если у тебя возможен приём только на один единственный путь. Если возможен приём на 2 боковых пути, то нужно именно две AddAnyPath (выходные разные).
Кстати, напомню, AddAnyPath не может держать в памяти несколько последовательно наехавших на неё подряд поездов. Она не для этого создавалась.
tepaniko
12.09.2013, 20:39
NickLon
:ps: Надо будет свой туториал выложить, давно уже хотел. ;)
Было бы замечательно!
Я что-то так и не въехал в твою "лесенку". Поясни, пожалуйста, на конкретном примере.
http://i.piccy.info/i7/bd5e26786b27d1cfb2e4139cbae0052c/4-77-63/62112204/TRam_20130913_0000_500.jpg (http://i.piccy.info/i7/473dfbbacca060b1b305753b0e0a578f/4-77-63/61781385/TRam_20130913_0000.jpg)http://i.piccy.info/a3/2013-09-13-03-02/i7-5123658/500x281-r/i.gif (http://i.piccy.info/a3c/2013-09-13-03-02/i7-5123658/500x281-r)
tepaniko
13.09.2013, 08:15
А можешь пояснить немножко на словах эту картинку
Я когда правила addAnyPath ставлю так лесенкой, то почему то маршрут собирается подчиненный очень очень много раз, в чем ошибка ?
Если возможен приём на 2 боковых пути, то нужно именно две AddAnyPath (выходные разные).
Что-то я вот тут не понял. А в какой момент ты собрался давать это самое AddAnyPath?
Вот смотри, на боковой ПС у тебя заходит, чтобы пропустить сзади идущий ПС. Ты же не сразу будешь давать команду на выход. Какой смысл тогда уходить на боковой, если он просто транзитом по этому боковому и пройдет. Следовательно, отпускать ПС с бокового должен кто-то другой. А как он определит с какого именно пути нужно открыть выход? А вот когда определит, тогда тебе и ясно будет какой конкретно маршрут нужно собирать. Только вот я не понял, а почему 2 AddAnyPath? Может в этом как раз вся и загвоздка?
А можешь пояснить немножко на словах эту картинку
А что там не понятного? Повставляй между правилами AddAnyPath Trigger Check и всё станет ясно.
Насколько я понял, первое правило играет роль взведенного курка. А выстрелы последуют по мере того, как ПС будет наезжать на триггеры, указанные в подчиненных правилах AddAnyPath. Но как по мне, так хаос там будет ещё тот: никогда не поймешь кто кому что собрал и зачем ему это понадобилось.:mocking:
Так, приступаю к станции Солнечная со стороны области. Вот тут начнется песттня и пляска с бубнами! :phil:
Может в этом как раз вся и загвоздка?да не, ты прав :) . Я просто не подумал, что триггер можно ставить на том пути, на который прибывает грузовой :).
---------- Сообщение добавлено в 19:41 ---------- Предыдущее сообщение размещено в 19:37 ----------
Насколько я понял, первое правило играет роль взведенного курка.лучше сказать наоборот. Дочернее правило не должно сработать (начать искать закрытый светофор перед поездом и собирать маршрут от него) до тех пор, пока родительское правило не построит маршрут и не откроет светофор. В противном случае (если они "параллельно" выполняются) собирать маршрут будут они оба от одного и того же светофора - одно сможет открыть а второе пропустится.
---------- Сообщение добавлено в 19:47 ---------- Предыдущее сообщение размещено в 19:41 ----------
то почему то маршрут собирается подчиненный очень очень много раз, в чем ошибка ?покажи скрин настройки дочернего правила
Teplovozz
13.09.2013, 20:28
Напомните пожалуйста, как правильно настроить маршрутный указатель.
Проехался тут давеча по Печёрке с sU - там у автора в чётной горловине ст. Валдеево с этим делом чё-то не так (маршрут собирается, но МУ ничего не показывает, а у предстоящего открывшегося выходного гаснут все линзы, хотя на мини-карте видно что он зелёный).
Или версия карты не нова, а в сигналке в плане МУ за это время что-то изменилось?
Возможно маркеры надо перенастроить. Или, возможно, их удалить и расставить заново.
Да, если маршрутный указатель стоит на одном пути со светофором, у него есть опция наподобие "подключиться к светофору". Её желательно нажать, чтобы МУ не расходовал ресурсы на поиск светофора.
tepaniko
13.09.2013, 21:01
[quote="NickLon;308368"]покажи скрин настройки дочернего правила
Вроде разобрался, поехало как надо кажись!
Есть вопр - в addAnypath обязательно триггео указывается?
Просто если я хочу грузовой который пропускает пасс, когда пойдет на боковой, ждал пока пасс не наедет на какойнить тригер например.
Я поставил перед выходным с бокового триггер на отправку грузового, и пока он до него доезжает, пасс собирает себе маршрут на проход по главному.
Но вот если нужно сделать так чтобы грузовой доехал до выходного, там постоял, и только потом собрал себе выход, как можно сделать с помощью правил?
Есть вопр - в addAnypath обязательно триггео указывается?да. Чтобы он получал ссылку на поезд от родительского правила - такое ещё не делал. Но мож со временем сделаю :) .
---------- Сообщение добавлено в 21:06 ---------- Предыдущее сообщение размещено в 21:05 ----------
как можно сделать с помощью правил?NickLon уже рассказывал. Переменными. И правилами, которые ими оперируют. Перечитай посты NickLon'a
Нужен коллективный мозговой штурм! А то я кручусь вокруг решения задачи, а не уверен, что найду его сам.
Значит, задача следующая. По станции Солнечная в четном направлении есть три боковых пути, которые я отвел для "группировки" грузовых. Это 3-й, 5-й и 7-й пути. Смысл этой группировки состоит в том, чтобы грузовые на участке Солнечная - Москва-Сортировочная не захламляли особо трафик, а то там и без них планируется (да оно и в реале так и есть) весьма интенсивное движение пассажирских и МВПС. Приоритеты по путям расставил такие: на 5-й - 3, на 7-й - 4 и на 3-й - 5. Когда первый по счету грузовой подходит к станции, он собирает себе вариантный маршрут прибытия от 3 до 5. При этом увеличивает некую переменную на 1. Так же и со вторым по счету прибывающим грузовым происходит. Итого, после прибытия второго грузового 5-й и 7-й пути заняты. Когда подходит третий по счету грузовой к станции, он, как и предыдущие грузовые проверяет переменную на равенство 3. Если равенство верно, это означает, что надо бы отправлять ребят с 5-го и 7-го, и самому тоже проскочить транзитом по 3-му пути. Загвоздка в том, что от Солнечной идет 3-х путный участок. Причем каждый из путей являет собой как-бы однопутный участок, то есть проходные стоят в обе стороны. Первый и второй пути - это как бы основные, а третий - дополнительный, который я и отвел для грузовых. Не знаю, правда, как там на самом деле, но я решил сделать на модели именно так. Так вот, выход на перегон грузовым я ещё хочу сделать тоже вариантным. Например, образовалось окно в трафике пассажирских и с 5-го пути можно отправить по III-му, а с 7-го - по основному II-му. И вот теперь я никак не соображу, как тут поездам на 5-м и 7-м пути поставить правило AddAnyPath?
Вроде бы как надо организовать лесенку, как я её назвал "взведенного курка". Но как это сделать, никак не соображу. Может будут мысли у коллективного разума?:blush2:
Если равенство верно, это означает, что надо бы отправлять ребят с 5-го и 7-го,зачем? И зачем ему ещё и по боковому проскакивать, если главный свободен?
Лучше сделать так:
1) третий поезд прибудет на 3ий путь и встанет
2) четвёртый поезд проедет станцию по главному и встанет под обгон на следующей
Это гораздо ближе к реальности.
зачем? И зачем ему ещё и по боковому проскакивать, если главный свободен?
Затем, что не факт, что он сразу проскочет. Позади него может быть куча пассажирских. Я ж не буду весь сценарий описывать в одно посте.
Лучше сделать так:
Не думаю, что так лучше. Там трехпутный участок. И все три пути нужно использовать. Твоё предложение дельно для двухпутного участка. И потом, если на 3-м пути встанет поезд, а кто их потом отпустит со станции? Пассажирским там уже нет дела до грузовых, как у меня было на предыдущих станциях обгона.
Ты посоветуй как лесенку из AddAnyPath организовать? Вот, что я сейчас буду тестить. По всем трем путям стоят триггеры. По вариантному маршруту первым займется 5-й путь, потом 7-й и только потом по триггеру на 3-м пути проследует ПС. Правило AddAnyPath для триггера на 3-м пути ставлю в корень дерева правил. А в подчинение ему два правила AddAnyPath по 5-му и по 7-му пути. Единственное, что меня смущает, так это то, что у тебя на скрине головное правило не имеет триггера. Следовательно, оно срабатывает при старте сессии, да? И все подчиненные правила взведены ещё до проезда ПС указанных в них триггеров. А у меня взводятся подчиненные уже после проезда триггера поездами. Но ты, вроде, говорил, что если поезд раньше проехал триггер, то правило сработает сразу же. Вот на это и надеюсь.
Если же ты хочшь организовать "однопутку для грузовых" на третьем пути перегона, то тут (для возможности организации движения "пакетами" поездов) нужно объединять логику всех последующих станций, считать, сколько доступно свободных путей на каждой из станций, отправлять с разных сторон на одну станцию пакеты поездов так, чтобы с одного из направлений (опять же выбираемого случайно и периодически изменяемого) количество поездов не превышало число свободных боковых путей на этой станции... А это требует рассчётов не одной станции, а всего однопутного участка (по всей длинне), управления переменными числа свободных путей на станциях, числа поездов на каждом из перегонов, выбранное "приоритетное" направление, и т.п. В общем это вещь сложная.
По поводу "взведенного курка" перед моментом проследования грузового на боковой, и последующей паузы до того момента, когда переменная окажется верной...Тут ещё не понятно - какое правило используешь в качестве родительского для отвпавления грузового? Потому что очень может быть, что правило AddAnyPath сработает для последнего поезда, проследовавшего через её триггер, если это правило не резетили.
---------- Сообщение добавлено в 12:09 ---------- Предыдущее сообщение размещено в 12:04 ----------
Правило Variable Check резетит дочерние правила перед их запуском, значит оно не подходит.
Нет. Это не совсем в чистом виде однопутка для грузовых. Ты, кстати, хорошую идею подал относительно того, по какому пути пройти последнему танку. Если позади нет пассажирских, можно и по 2-му пути пройтись. А что касается дальнейших станций, то от Солнечной до М-Сортировочной три пути так и идут. Можно организовать с переменными реверсивное движение по этому участку, но сомневаюсь, что там мне удастся столпотворение сотворить. В четном направлении то задел по времени может быть будет хватать. Группировки в нечетном направлении от Сортировочной не будет.
У тебя есть маршрут Москва-Малоярославец tramvayz'а? Если есть, посмотри путевое от 2Ч-ЧМ3-Н5/Н7. Там пока первый поезд пройдет Н5, второй уже собрав маршрут от 2Ч до ЧМ3 по идее даёт команду на сборку вариантного маршрута - на 7-й путь. Так вот, он его не собирает. Ему конечно мешает впереди идущий на 5-й путь, почему я тебе и говорю посмотреть путевое. От ЧМ3 до обратных Н5 и Н7 еще доехать надо.
---------- Сообщение добавлено в 13:43 ---------- Предыдущее сообщение размещено в 13:36 ----------
Про правило не понял. Что это значит? Не подходит для чего?
Упс:
пройти последнему танку
танковый биатлон смотрю...:mocking:
Не подходит для чего?для того, чтобы делать к нему зависимое правило AddAnyPath, которое бы сработало на последний наехавший на его триггер (стоящий над триггером по красному) поезд (как у тебя в случае триггера и правила AddPath).
---------- Сообщение добавлено в 13:47 ---------- Предыдущее сообщение размещено в 13:44 ----------
Единственное, что меня смущает, так это то, что у тебя на скрине головное правило не имеет триггера. Следовательно, оно срабатывает при старте сессии, да?нет, там просто слишком длинный список триггеров и он не уместился.
---------- Сообщение добавлено в 13:49 ---------- Предыдущее сообщение размещено в 13:47 ----------
А в подчинение ему два правила AddAnyPath по 5-му и по 7-му пути.я одного не пойму. Зачем колекционировать эти грузовые на боком пути, если перед ними, как ты сказал, есть специально выделенный путь перегона? Я б понял, если бы их коллекционировали с нечётного направления (т.к. их надо втискивать в двухпутку к пассажирским), а тут... Нереалистично в общем.
там просто слишком длинный список триггеров и он не уместился.
А-а-а, вот тогда всё понятно! Реализую, конечно же, чем для каждой станции свои триггер-чеки ставить. Только они больше одного раза сработают?
По поводу коллекционирования. В принципе, ты прав. На этот третий путь никогда ни пассажирский, ни МВПС не поедет, следовательно они для грузовых только и сгодятся. Вообще идея была такова, чтобы грузовой, при свободности II-го пути мог проехать и по нему. А вот эта самая свободность величина весьма не постоянна. А если я буду ориентироваться исключительно на III-й путь (я римскими обозначаю пути перегона, чтобы было понятно, что это не путь станции), то при том, что по нему может ехать поезд в нечетном направлении и свободном II-м пути, грузовой просто тупо будет стоять....
Хотя я, кажется, нашел выход. В том числе и как избежать зависимости AddAnyPath от правила анализа переменной. Нужно построить два варианта развития событий.
Первый, лесенка такая:
Trigger Check Solnechnaya C In
-Variable Check S>1
--AddAnyPath от 3 до 3 (построил маршрут от 2Ч до ЧМ3 по тому же триггеру Solnechnaya C In)
---AddAnyPath от 3 до 5 (вариантный маршрут до выходного от маршрутного по тому же триггеру)
----AddAnyPath от 1 до 1 (выходной маршрут только на третий путь перегона, по тому же триггеру)
И второй вариант, если S=1, всё тоже самое, только последняя строка от 1 до 2. Здесь значение S>1 означает, что позади следует пассажирский, и на II-й путь выходить - ни-ни, даже если и III-й занят. Правда, не понятно что случится раньше: переменная S примет значение 1 или освободится III-й путь. Но это уже частности и мелочи.
Вот такая схема сработает? У меня же нет между AddAnyPath проверки переменной, значит и ресетить она правила не должна. Взлетит?..
---------- Сообщение добавлено в 16:20 ---------- Предыдущее сообщение размещено в 16:18 ----------
А, что меня смущает в моей схеме, ток это то, что используется один единственный триггер. Это нормально, должно срабатывать?
1) на каждое правило нужно по одному триггеру, на которые поезд будет последовательно наезжать. Я это на скрине показал. То есть + Trigger Check будет 4 триггера.
2) к сожалению, если последнее из правил AddAnyPath не сможет завершиться до того, как будет выполнено первое (очередным грузовым), то, вероятно, оно сломается. Или не сработает для второго поезда. В общем я не знаю как оно себя поведёт.
Только они больше одного раза сработают?Из-за Variable Check может быть и нет.
если последнее из правил AddAnyPath не сможет завершиться до того, как будет выполнено первое (очередным грузовым),
А факт исполнения правила есть сборка маршрута и открытие светофора? Я думал, что правило кинет маршрут в стек и забудет, что когда-то выполнялось. Да, есть вариант, что ни один маршрут не будет свободным и не понятно какой именно маршрут кидать в стек, ну тогда, может быть, по приоритету? Если приоритеты от 1 до 2, и на момент исполнения правила нельзя собрать и открыть светофор ни по одному из приоритетов, то может быть просто закидывать в стек маршрут по первому приоритету и пусть ПС ждет, пока этот самый первый приоритет освободится?
---------- Сообщение добавлено в 17:27 ---------- Предыдущее сообщение размещено в 17:13 ----------
Не, не работает такая лесенка. Вов, а zxAddPath запускает дочерние правила zxAddAnyPath также, как и сама zxAddAnyPath?
---------- Сообщение добавлено в 17:34 ---------- Предыдущее сообщение размещено в 17:27 ----------
Ответ: нет, не запускает. А почему? Это же тоже твоё правило. Добавь там тоже такой механизм. Глядишь, и пригодится. Мне бы сейчас пригодился.
А факт исполнения правила есть сборка маршрута и открытие светофора? Я думал, что правило кинет маршрут в стек и забудет, что когда-то выполнялось.Правила и команды действительно завершаются только после предоткрытия светофора. Иначе следующие команды нашли бы этот же закрытый светофор снова.
Да, есть вариант, что ни один маршрут не будет свободным и не понятно какой именно маршрут кидать в стек, ну тогда, может быть, по приоритету?именно так и делается для маршрутов приёма. А вот для маршрутов отправления, если свободного маршрута нет, там сразу кидается наиболее приоритетный маршрут в стек (потому что неизвестно, изменится направление перегона сразу, или надо долго ждать).
---------- Сообщение добавлено в 16:42 ---------- Предыдущее сообщение размещено в 16:39 ----------
Добавь там тоже такой механизм. Глядишь, и пригодится. Мне бы сейчас пригодился.начинать надо с механизма Variable Check.
zxAddPath тупо добавляет списки маршрутов в стек, соответственно толку от неё (в плане вызова зависимых правил) никакого. Она ни за чем не следит.
Да, с переменной ничего не получается. Да и хрен с ней. Можно поставить триггер достаточно далеко, чтобы по наезде на него пассажирский без очередей собирал себе маршруты по главному. А, кстати, AddAnyPath как маршруты ставит, обычно или очередь? Если обычно, то - не взлетит.
По поводу того, что если не выполнилось последнее правило и вновь цепочку нужно проходить, то да, в лучшем случае собирается первый маршрут, два других, подчиненных - нифига. Зато третьему поезду опять собирается всё как ни в чем не бывало. Это при том, что я второму поезду сам последующие два маршрута вручную собрал.
Теперь буду играться с триггерами, чтобы расставить их правильно.
чтобы по наезде на него пассажирский без очередей собирал себе маршруты по главномуне взлетит. Вообще никак. Так что жди, мож сделаю для тебя "многоразовое" правило с переменными.
---------- Сообщение добавлено в 18:31 ---------- Предыдущее сообщение размещено в 18:25 ----------
Потому что очереди добавляются только в порядке их выполнения. А тут ты предлагаешь наоборот.
не взлетит.
Нет, взлетит! :blum1:
Грузовой будет себе собирать маршруты перед 4-м проходным, а пассажирский перед 10-м, например. Пока второй грузовой доедет до 4-го, пассажирский в стек себе уже набросает маршрут без опции "очередь". И от Ч2 до IIЧ@Очаково не только соберется маршрут, а ещё и светофор откроется. Тогда уж грузовые никак на II путь не выйдут, а будут стоять на боковых, дожидаться, пока их III-й освободится. Вроде как-то так должно быть.
По поводу "жди, мож сделаю", Вов, я тебя просил года полтора назад сделать Variable Add, чтобы в одной строке правила можно было бы все переменные задавать, а не на каждую переменную лепить отдельное правило. Так это было тогда. А сейчас у тебя экзамены, потом учеба - нельзя же в первый же год на неё забивать, хоть даже и в аспирантуре. Так что довольствоваться нам тем, что уже есть от тебя года полтора-два как минимум.
Teplovozz
14.09.2013, 19:57
Так и не нашёл, где почитать про настройку МУ. Пробовал, честно - ничего не выходит, кроме жука"...
Владимир, подскажи пожалуйста. Или кто ещё знает?
1) МУ свободно установленный, или на светофоре?
2) если выдаёт ошибку, попробуй удалить и поставить заново
3) если что, скинь карту в личку
Teplovozz
14.09.2013, 21:43
МУ свободно установленный, или на светофоре?
МУ свободно установленный.
Но хотелось бы узнать и про оба варианта.
Если речь о МУ на поездном светофоре, то просто ставишь галочку, указываешь цвет линз и тип матрицы.
МУ свободно устанавливающийся имеет одно единственное отличие от МУ в той же z7 - кнопкой "привязка". Которая позволяет привязать срабатывание к светофору, стоящему на одном пути с ним:
http://i.piccy.info/i7/e43f4d886a7912519a858ed3c64fbdcd/4-77-137/54935069/TRam_20130914_0001_500.jpg (http://piccy.info/view3/5132055/9a35f26b8063c7bcd1578b972321ee91/)http://i.piccy.info/a3/2013-09-14-18-57/i7-5132055/500x281-r/i.gif (http://i.piccy.info/a3c/2013-09-14-18-57/i7-5132055/500x281-r)
Если такого светофора нет, то нажимать её не нужно.
---------- Сообщение добавлено в 22:02 ---------- Предыдущее сообщение размещено в 21:58 ----------
С маркером вовсе никаких проблем не вижу:
http://i.piccy.info/i7/ae69cb4b51e03cf958cc81d5bf1169ce/4-77-138/2207359/TRam_20130914_0002_500.jpg (http://piccy.info/view3/5132076/865c9e234df4e015837d0d16b47a2506/)http://i.piccy.info/a3/2013-09-14-19-00/i7-5132076/500x281-r/i.gif (http://i.piccy.info/a3c/2013-09-14-19-00/i7-5132076/500x281-r)
если требуется, ставить дополнительные галочки (тогда его можно совмещать с другими типами маркеров).
О буквах есть в шапке темы.
Использование букв в МУ.
В маркеры с опцией MRN допустимо заносить арабские цифры и следующие значения в качестве номера пути:
Буквы:
А А
Б B
В V
Г G
Д D
Е E
Ж J
И I
К K
Л L
М M
Н N
О О
П P
Р R
С S
Т T
У U
Ф F
Х H
Ц C
Ч Q
Ш X
Э e
Ю Y
Я Z
Римские цифры:
I a
II b
III c
IV d
Положения:
\ l
/ r
| f
- h
Э e
Teplovozz
14.09.2013, 23:45
А "state" для чего нужна?
Положения:
\ l
/ r
| f
- h
Э e
И вот это можно расшифровать?
проверить, как МУ показывает то или иное показание. Т.Е. для дебага.
---------- Сообщение добавлено в 23:48 ---------- Предыдущее сообщение размещено в 23:46 ----------
И вот это можно расшифровать?для полосы "влево" в маркере должна быть литера l, для показания "поперёк" - литера h, для "Э" литера e.
Все, поехала у меня Солнечная. Только вот без лесенок. Что-то они у тебя, Вов, не работают как заявлено. Да и ладно. Ларчик просто открывался - все в корень правил, и правильно расставить триггеры, и все поедет... Завтра еще немного поиздеваюсь над своей схемой на предмет как ее завалить, и дальше до М-Киевской пойду.
tepaniko
15.09.2013, 22:28
Главное потом туториал или мануал выложи для использования - чтобы и люд знал как все это можно использовать! Цены бы не было :)
А какой туториал я могу выложить? Только рассказать о том, как у себя настроил каждый конкретный случай. А настраивал методом тыка. Каждый раз правила ведут себя одинаково только в общем случае, а частности всплывают уже во время тестов. Эти частности зависят от того, как близко стоят триггеры, по которым срабатывают правила AddAnyPath. Например, я пришел к выводу, что очень близко триггеры разных строк AddAnyPath не должны стоять. По крайней мере, с первого триггера ПС должен уже съехать, прежде, чем наедет на следующий, который привязан к следующей строке AddAnyPath. А TRam_ может сказать, что это чушь. Ничего подобного. Так что не с меня туториал должен быть.
1) как поставить развернутый входной?
2) как поставить заградительные сигналы на переезде (развернутые)?
Что значит развёрнутый?
Заградительные не реализованы.
kemal, это тот который стоит по неправильному пути а линзы направлены в ту же сторону что и у обычного входного
А, теперь понял, что тебе нужно. Задай ему отрицательное смещение.
Aleks_93
17.09.2013, 17:46
Добрый день! Сделав примитивную сортировочную горку, установил на ней сигнализацию Su. Такой вопрос: можно ли задать сразу несколько маневровых маршрутов для того чтобы, каждый отцепленый вагон следуя своим ходом с горки отправлялся на заранее подготовленый путь, например: 1 вагон на 1 путь, 2 вагон на 4 путь, 3 вагон на 5 путь и так далее. Чтобы маршруты готовились автоматически. Возможно ли такое реализовать? И еще вопрос не в тему: отцепляю вагоны, а они сами не катятся. Что нужно сделать, чтобы после отцепки они ищли своим ходом?
1) нет. Маневровых маршрутов на всей карте невероятно много, чтоб их запомнить. Поэтому маневровые маргруты генерируются в реальном времени, их список задать в будку нельзя. Но можно в редакторе настроить набор правил "zxPath AddShuntPath" (причём чтоб правило последующего маршрута подчинялось предыдущему), указав что собирать маршрут надо от локомотива, осуществляющего роспуск.
Другой вариант - набор команд сборки маршрутов вместе с командами движения машинисту (как тут - https://www.youtube.com/watch?v=4G9SQ3sCYAE)
2) чтоб вагоны скатывались, необходимо поставить патч SP1 . Но в этом случае сломается разборка маршрутов (потому что в SP1 сломалась система сообщений, и либо какая-то стрелка переведётся под вагоном, либо она не сможет разблокироваться после прохода вагонов). Либо, если не ставить SP1, нужно после каждой расцепки останавливать состав, и только тогда вагоны покатятся (сцепка не расцепляется без остановки)
Вов, у меня вот такой вопрос. Общеизвестно, что если на пути построения маршрута поставить триггер с наименованием, которое начинается с ключевого слова stop, то маршрут через этот триггер не построится. А можно немножко докрутить этот механизм, чтобы построение маршрута не только на наличие стоп-триггера реагировало, но и на то, куда он направлен. То есть, если построение маршрута идет со направлено стоп-триггеру, то такой маршрут не строить, а если нет - то игнорировать этот триггер?
А то уже раз третий или 4-й пересчитываю ст. Москва-Киевская (ты, наверное, видел, что там черт ногу сломит и без стоп-триггеров там не обойтись), потому как не всё то, что стоит в реале, можно четко совместить с sU, а обнаруживается это уже в процессе пересчета. И приходится опять ставить-убирать стоп-триггеры едва ли не для каждого светофора. А на 4-й раз уже и не упомнишь, где чего стояло и зачем оно там было надо.
NickLon, а насчёт какой зоны этой станции идёт речь? А то что-то не припомню на ней путей, по которым в одну сторону возможен пропуск в поездом порядке, а в другую - невозможен?
И да, если ты о путях возле вокзала, то разве автоудаление неправильно срабатывает?
---------- Сообщение добавлено в 19:04 ---------- Предыдущее сообщение размещено в 18:49 ----------
Кстати, по поводу триггеров... Ты не пробовал их в слои устанавливать :) ? Чтоб для каждой группы светофоров - слой сессии с нужными триггерами.
TRam_, А при чем здесь какие-то зоны и поездной, и маневровой порядков пропуска ПС? Да и автоудаление, наверное, правильно и здесь бы сработало. Но я хочу оставить несколько (скорее даже не больше двух) вариантов проследования маршрута как на отправление, так и на прибытие. Так меньше всего будут прибывающие и отправляющиеся поезда мешать друг другу. Это же тупиковая станция. В общем, потребность в этом есть.
Впрочем, расскажи, пожалуйста об этих слоях. Задумывался я об этом давно, но для чего эти слои, как ими управлять - не понимаю. Не понятно что значит слой для группы светофоров? То есть, в один слой светофоры и триггеры и они между собой будут взаимодействовать, не обращая внимания на другие светофоры и триггеры в других слоях?.. Все равно, что-то я себе это смутно представляю.
Fix 3 - http://yadi.sk/d/FaS0aicY9TNgf
проценты просчёта стрелок и генерации маршрутов в будке и её браузере теперь автоматически обновляются
поправлена работа zxPath AddShuntPath для работы с подчинёнными правилами
Ставить с пропуском.
tepaniko
18.09.2013, 12:58
Вопрос такой,
у меня лесенка построена для поезда и по ней последнее правило открывает маршрут на прием до закрытого светофора
но следующий поезд, который проезжает по триггеру для этого последнего правила, тоже срабатывает и строит себе маршрут также на вход, хотя не должен же по идее этого делать, так как он в лесенке то не участвует ведь
Я правильно рассуждаю или есть нюанс ?
А по какой это "идее" он не должен этого делать, если ты не настроил ни машинистов, на которые срабатывает правило ни типов ПС, ни конкретных ПС. А если настроил, то скрин лесенки - в студию. Не понятно, что у тебя предшествует этому самому последнему правилу.
tepaniko
18.09.2013, 17:48
Я думал что если по лесенке, то будет правила подчиняться и последнее не будет срабатывать отдельно, если на него наедет следующий состав. Тоесть оно выполнилось и типа его нет и сработать нечему
Так то понятно отдельный триггер для груз и пассов и все работает как надо.
Просто дело в том, что лесенка "однозадачная". Она не сможет работать так, чтобы дочернее правило обрабатывало один поезд, а родительское - другой. То есть при наезде второго поезда на триггер первого правила происходит сброс последующих правил (при условии срабатывания).
так как он в лесенке то не участвует ведьпроверь чтоб в первом правиле лесенки была опция "срабатывать 1 раз". Если же тебе надо несколько поездов отправлять на боковой, то тут надо указывать в правиле, на поезда с какими вагонами нужно срабатывать.
Вов, Эврика! То есть, я докопался! Правда, может быть ты уже это пофиксил - летом я не особо пристально следил за твоими разработками.
Так вот, помнишь мы решали проблему с тем, что пассажирским проходные выдают ограничение скорости грузовых. Мы ещё ломали голову, то ли это пред-предвходной, то ли все. Ты, вроде, даже фикс выпускал.
Сейчас решение другой проблемы меня и натолкнуло на мысль. Че за проблема - интересно будет, расскажу. Так вот, проходные по-прежнему дают пассажирскому(! именно пассажирскому, а не пассажирским!) ограничение по скорости грузовых. А знаешь какому пассажирскому?.. Наверное уже сам догадался - первому, блин, который в первый раз проезжает через этот проходной. Для всех последующих пассажирских - нормально!
Выводы, думаю, и сам сделаешь.:i_am_so_happy:
tepaniko
19.09.2013, 11:53
Просто дело в том, что лесенка "однозадачная". Она не сможет работать так, чтобы дочернее правило обрабатывало один поезд, а родительское - другой. То есть при наезде второго поезда на триггер первого правила происходит сброс последующих правил (при условии срабатывания).
Слушай, а ты можешь более развернуто и подробно описать последовательность правил в представленной картинке - лесенке ранее ? и что внутри них стоит ?
просто у тебя первое правило без триггеров, я тоже так попробовал, но ничего не срабатывает тогда
Я чего то так до конца не могу принцип уяснить, поэтому и прошу описать последовательно что какое правило делает у тебя ?
п.с. еще момент, где у тебя куча триггеров перечислена в правиле, оно как действует - ждет пока какойнибудь поезд не пересечет все эти триггеры и только тогда будут действовать следующие или как ?
tepaniko, я уже задавал такой вопрос. :) Делов в том, что список триггеров в первом правиле очень большой и он не умещается в это окошко, и правило вообще ничего тогда туда не пишет.
А что касается лесенки. Вот смотри, ставишь первое правило AddAnyPath, назовем его Правило1, в корень. Оно ссылается на Триггер1. В подчинение ему ставишь AddAnyPath, Правило2. Оно ссылается на Тригер2. Таким образом, когда у тебя ПС наедет на Триггер1, сработает Правило1, то есть, построит Маршрут1 и кроме этого как бы взведет в состояние ожидания Правило2. И когда поезд наедет на Триггер2 Правило2 соберет тебе Маршрут2.
Ты спросишь, а зачем это надо это лесенка, если триггеры разные и всё равно ждешь проезда триггеров последовательно? А это для того случая, когда на момент наезда ПС на Триггер1, на Триггер2 ПС уже наезжал. Тогда Правило2 сработает моментально, не ожидая, пока ПС наедет на Триггер2. Теперь понятно? :-)
А последующая куча правил на одном уровне как раз и нужна для т.н. отложенной сборки маршрута. То бишь, я Маршрут2 готов собрать, но только после того, ка соберется родительский Маршрут1.
---------- Сообщение добавлено в 13:22 ---------- Предыдущее сообщение размещено в 13:13 ----------
Да, забыл сказать, тут большая пребольшая собака зарыта, собственно, что практически нивелирует всю прелесть этих лесенок. ПС наехал на Триггер1, собрался Маршрут1. Потом он наехал на Триггер2, собрался Маршрут2. Так вот, пока этот Маршрут2 не разберется и не уйдет из стека, а тем временем эту цепочку начнет выполнять следом идущий поезд, то этому следующему поезду в лучшем случае соберется только Маршрут1, в худшем - вообще ничего не соберется. Причем, это верно и для тех правил, которые стоят непосредственно в корне. то есть, пока маршрут собранный ПС1 не разберется, маршрут для ПС2 не соберется.
---------- Сообщение добавлено в 14:11 ---------- Предыдущее сообщение размещено в 13:22 ----------
О, Вов, спасибо за измененную VariableAdd! Только я бы ещё один столбец добавил. Там бы хранил описание предназначения этой переменной. Когда для каждой переменной надо было ставить отдельное правило, то я в наименовании этого правила кратко писал для чего она мне, что потом голову не ломать зачем я завел её когда-то? Не обязательно, чтобы весь текст помещался в столбец. Достаточно того, что когда кликнешь на него, открывалось бы окошко для написания этого текста, а в нем тот самый текст.
tepaniko
19.09.2013, 14:42
вроде стало понятней, но есть еще один момент вот с этим: куча триггеров перечислена в правиле, оно как действует - ждет пока какойнибудь поезд не пересечет все эти триггеры и только тогда будут действовать следующие или как ?
тоесть в правиле AddAnyPath мы можем добавить дофига триггеров на срабатывание - это значит что если на один из них наедет состав, то начнется следующее правило или если состав все их пересечет сработает следующее правило ? я вот тут чет не очень понял.
Если рассмотреть картинку то вот что я вижу:
1) правило с кучей триггеров с маршрутом по определенным станциям - гдето состав наехал - сработало
2) правило с триггерими и маршрутом - собрется когда поезд наеден на один из триггеров - срабатывает сборка на выход видимо
3) под ним правило видимо маршрут для след станции вход
4) под ним на выход по тойже станции
Там бы хранил описание предназначения этой переменной.хорошо, поробую.
Так вот, пока этот Маршрут2 не разберется и не уйдет из стекаесли точнее, пока светофор, от которого строится этот маршрут, не получит предоткрытие.
---------- Сообщение добавлено в 13:48 ---------- Предыдущее сообщение размещено в 13:44 ----------
это значит что если на один из них наедет состав, то начнется следующее правило или если состав все их пересечет сработает следующее правило ?когда состав пересекает одно правило, оно даёт команду следующему запомнить поезд, который через них проедет. Если правило выполняется, то следующее (если поезд через него ещё не ехал) ждёт поезда, или (если поезд проехал) выполняется для проехавшего поезда.
Если рассмотреть картинку то вот что я вижу:
1) правило с кучей триггеров с маршрутом по определенным станциям - гдето состав наехал - сработало
2) правило с триггерими и маршрутом - собрется когда поезд наеден на один из триггеров - срабатывает сборка на выход видимо
3) под ним правило видимо маршрут для след станции вход
4) под ним на выход по тойже станциине совсем. Там пункты 2, 3 и 4:
2) маршрут на выход или по станции (если маршрутный)
3) маршрут на выход или по станции (если маршрутный)
4) маршрут на выход
Потому что некоторые станции там сложные, по несколько парков и соответственно маршрутных.
Вов, расскажи, пожалуйста, как у тебя работает правило Variable Check Rev.1 с опцией проверять переменную каждые 5 секунд, если оно стоит в подчинении, например, Trigger Check? Если мои надежды оправданы, то когда поезд проедет триггер, сработает проверка переменной. Если условие ложно, то правило будет проверять переменную каждые 5 секунд, до тех пор, пока оно не станет истинно. Как только условие стало истинно, дальнейшая проверка переменной каждые 5 секунд выключается, срабатывает подчиненное проверке переменной правило, и правило проверки переменной ждет, пока вновь будет активизировано очередным наехавшим на триггер поездом. Я правильно изложил? Или всё-таки единожды взведенное правило проверки переменной теперь будет до конца сессии проверять эту переменную на истинность и всякий раз, когда условие будет истинно оно будет запускать подчиненные ему правила?
Если условие ложно, то правило будет проверять переменную каждые 5 секунд, до тех пор, пока оно не станет истинно. Как только условие стало истинно, дальнейшая проверка переменной каждые 5 секунд выключается, срабатывает подчиненное проверке переменной правило, и правило проверки переменной ждет, пока вновь будет активизировано очередным наехавшим на триггер поездом. Я правильно изложил?да, в последней редакции этого правила вроде именно так и сделал. По крайней мере задумывал так.
Но вот будет ли его резетить Trigger Check - не знаю. AddAnyPath будет.
если точнее, пока светофор, от которого строится этот маршрут, не получит предоткрытие....
...когда состав пересекает одно правило, оно даёт команду следующему запомнить поезд, который через них проедет. Если правило выполняется, то следующее (если поезд через него ещё не ехал) ждёт поезда, или (если поезд проехал) выполняется для проехавшего поезда.
Не пойму. Если у родительского правила 20 триггеров и хотя бы по половине из них проехали поезда, то это родительское правило даст команду следующему запомнить 10 поездов, которые проедут через 10 из очередных 20-ти триггеров, так что ли?
Тогда почему по одному триггеру нельзя запомнить 10 поездов?
Если у родительского правила 20 триггеров и хотя бы по половине из них проехали поезда, то это родительское правило даст команду следующему запомнить 10 поездов, которые проедут через 10 из очередных 20-ти триггеров, так что ли?нет конечно. Просто сбросит запомненые поезда у других.
Уже ж говорил, что правила однозадачные. То есть один поезд на каждую лесенку, только тогда будет нормально работать.
В случае вышеупомянутой картинки - она изображает постройку маршрутов для игрока в сценарии. Поезд игрока определяется с помощью фильтра по локомотиву (можно по вагону).
---------- Сообщение добавлено в 14:09 ---------- Предыдущее сообщение размещено в 14:04 ----------
Не, я могу сделать, чтобы правила запоминали по 100500 поездов, которые по ним проехали. Но Я тогда ХЗ как эти правила связывать, чтоб они правильно поняли, какому поезду что можно открывать.
Не, я могу сделать, чтобы правила запоминали по 100500 поездов, которые по ним проехали. Но Я тогда ХЗ как эти правила связывать, чтоб они правильно поняли, какому поезду что можно открывать.
А в чем там проблема то, я не пойму? Вот, проехал по родительскому AddAnyPath Поезд1. Правило его запомнило, передало подчиненному. Потом проехал Поезд2, та же картина. А уж потом, то ли Поезд2 проедет по одному из триггеров подчиненного правила, то ли Поезд1 - уже без разницы, и без разницы в каком порядке. Самое главное, чтобы подчиненное правило поняло какой именно триггер проехал один из поездов, чтобы от правильного триггера построить вариантный маршрут. И помнило, что у него ещё один поезд должен проехать один из триггеров и какой именно поезд. Вроде в единичном случае это всё у тебя работает.
---------- Сообщение добавлено в 16:45 ---------- Предыдущее сообщение размещено в 16:28 ----------
Я ещё вот над чем завис. У Москвы-Киевской как бы два пассажирских парка. Если смотреть на вокзал со стороны области по ж.д., то в крайнем правом парке 4 пути, и в левом ещё 4 отвел под пассажирские. остальные крайние левые 4 отвел под МВПС. Так вот, определяться в какой именно парк прибывать нужно заранее, после выходного из М-Сортировочной сразу. Вот скрин серии подчиненных правил для определения можно ли ехать на IIЧ М-Киевской:
http://savepic.su/3299465m.jpg (http://savepic.su/3299465.jpg)
Значит здесь Variable Check Rev.1 у меня проверяет возможность занять один из путей условно говоря левого парка. Если условие выполняется, всё замечательно, почапали дальше. А если нет? Тогда нужно проверить вторую переменную, второго парка, правого. А куда ставить правило проверки второй переменной? Если на тот же уровень, что и правило проверки первой переменной - а если оба условия выполнятся, то поезду разорваться? Вот никак не придумаю, куда его воткнуть?
---------- Сообщение добавлено в 19:30 ---------- Предыдущее сообщение размещено в 16:45 ----------
Но вот будет ли его резетить Trigger Check - не знаю.
Значит, сегодня протестирую. Хотя у меня уже были случаи, когда под Trigger Check Enhanced ставил AddAnyPath. С галкой "ждать исполнения дочерних правил". Только вот вот эту часть фразы я так и не понял: "...if no trains are present in rule triggers". Я предполагаю, что если в дочерних правилах присутствует условие наезда на другой триггер, например, твоя AddAnyPath, то это правило будет ждать наезда на этот самый другой триггер. То есть, то, что у тебя реализовано в том же AddAnyPath, если оно стоит в корне и имеет такие же AddAnyPath в своём подчинении. Как я это назвал "правило взведённого курка".
А проблему с прибытием, по поводу которой скрин выставлял, таки решил. :-)
Но вот будет ли его резетить Trigger Check - не знаю.посмотрел скрипт - вроде бы должно.
---------- Сообщение добавлено в 19:23 ---------- Предыдущее сообщение размещено в 19:12 ----------
Только вот вот эту часть фразы я так и не понял: "...if no trains are present in rule triggersа эта галочка, к сожалению, приводит только к "заклиниванию" правила. В теории она должна была заставлять правило не обращать внимания ни на какие проезжающие поезда, пока не завершатся все дочерние правила. Но, на сколько я знаю, тебе "пропущенные правилом поезда" не нужны, поэтому исправлять проверку завершения дочерних правил пока не буду.
Не, Вов, это просто чума какая-то с этой одноразовостью AddAnyPath. М-Киевская, получается, не по зубам такой маршрутизации. Надо что-то делать...
Не, Вов, это просто чума какая-то с этой одноразовостью AddAnyPath. М-Киевская, получается, не по зубам такой маршрутизации. Надо что-то делать...переводить на команды машинисту, например. Опять же с переменными. Вот они-то точно многоразовые, так как у каждого машиниста - свои собственные.
Для билда 3.7 сделано правило по деблокированию стрелок из-за сломанного аураном сообщения Object,Leave. http://yadi.sk/d/mvzoWKsX9a9wX . Чтоб поезда не сходили в этом билде, обязательно ставте именованные объекты между стрелками.
переводить на команды машинисту, например. Опять же с переменными. Вот они-то точно многоразовые, так как у каждого машиниста - свои собственные.
Не-е, батенька, после таких стараний на последнем этапе сдаться? Что-нибудь придумаю, конечно же.
Только мне вот как-то странно читать, что я процитировал выше, после этого:
Не, я могу сделать, чтобы правила запоминали по 100500 поездов, которые по ним проехали.
А как же ДСП, в соседнем разделе которое обсуждается? При таком подходе разработка, даже не начавшись, уже обречена на провал. И стоит ли тогда ломать копья? Я считаю, что нужно искать решение проблемы, а не способы её нивелировать и сделать вид, что она вовсе не существенна.
TRam_, а ты это правило на длс не заливал?
ещё нет. Потестируете, тогда.
TRam_, написал бы открытый исходник класса АЛСН, который позволяет локу принимать сигналы sU?
А то до сих пор в кабинах на древнющей сигналке ездим. А был бы незакрытый скрипт, можно было бы его ко многим кабинам прикрутить...
proton2, а причём тут Tram_? АЛСН для sU написан мной. Исходник я никому не дам, но желающие использовать его в своих скриптах могут мне написать, и я подскажу, как его можно прикрутить к своему скрипту.
Я считаю, что нужно искать решение проблемы, а не способы её нивелировать и сделать вид, что она вовсе не существенна.я и так уже перевернул логику аурановских правил с ног на голову, чтоб они многократно исполнялись. А ты предлагаешь мало того, чтоб они строили очереди из поездов, но ещё и плодили копии дочерних правил (чтоб на каждый поезд возникала своя собственная лестница правил, на которую бы не влияли остальные поезда). Если б это предложили, например, аурану, он бы сказал "мы не для этого правила создавали".
после таких стараний на последнем этапе сдаться?это не конец, это только самое-самое начало. Но если тебе не хочется ждать продолжения (а оно будет не раньше чем через полгода, так как реализацию "самовоспроизводящихся правил" нужно хорошо обдумать) - я же сказал, есть простой способ - команды. Либо делать лестницы так, чтобы одновременно могло работать "в режиме ожидания" не более чем одно правило каждой лестницы.
А ты предлагаешь мало того, чтоб они строили очереди из поездов, но ещё и плодили копии дочерних правил
Да вообще-то не до жиру. От "лесенок" я уже отказался. Если пораскинуть мозгами, то можно запросто и без них обойтись. Тут лишь бы одно единственное правило, которое стоит в корне правил, работало хотя бы с двумя поездами.
fin ДВЖД
20.09.2013, 16:39
Все сделал "по науке", но за место средней линзы в этом светофоре не хочет становиться заглушка:
http://savepic.su/3318813m.jpg (http://savepic.su/3318813.htm)
и в этом средняя линза тоже не заменяется на заглушку:
http://savepic.su/3293213m.jpg (http://savepic.su/3293213.htm)
это так и должно быть?
fin ДВЖД, ну как бы стоит внимательнее прочитать шапку
7) выкалывание любых линз у мачтовых светофоров (ограничение - в 3-линзовой головке можно выколоть только одну из линз)
То есть, это значит, что у карликов вытыкать линзы нельзя.
fin ДВЖД
20.09.2013, 16:45
стоит внимательнее прочитать шапку
буду внимательней, спасибо
То есть, это значит, что у карликов вытыкать линзы нельзя.
Крайне жаль. Трам, почему бы не добавить эту возможность и в карлики?
Потому что головки карликовых не выделялись в отдельные объекты, чтобы объединить их в одну мешь и снизить количество текстур (для всего набора карликов их всего две).
Предполагалось, что будут перекраски со "стандартными" выколотыми линзами, но у меня на них не осталось никакого желания. Кстати, если умеешь работать с фотошопом, можешь их сделать. Закрасить козырьки альфой, убрать прописанное в конфиге место для линзы и её козырька, переписать стандартные розжиги. И будет у тебя светофор с требуемой выколотой линзой.
Sandrilyon
21.09.2013, 10:32
TRam_, на БМО есть стрелки сбрасывающие, которые линкуются вместе обычными трэксайд-объектом, т.е. при переводе обычной стрелки вместе переводится и сбрасывающая. Как zxPath с этим будет дружить?
не будет zxPath с этим дружить - поезда с рельс будут сходить. Удалить надо все линкующие объекты.
Ant.taranish
21.09.2013, 14:36
Для билда 3.7 сделано правило по деблокированию стрелок
Неужели это решит проблему с неразборкой маршрутов?
Решает на 100%. Но чтобы поезда при этом не сходили, незабывай, что между любыми 2мя стрелками должен быть именованный объект, иначе скрипт просто не сможет проверять свободность этого участка (и считает его свободным).
Ant.taranish
21.09.2013, 14:49
TRam_, спасибо, мой сценарий только что перестал быть эксклюзивом для TS14. Вторая хорошая новость, что правило сборки маневровых маршрутов из Fix 3 теперь ждет разворота ПС, так же как и команда.:i_am_so_happy:
PS чуток обновил этот JunctionResetter, чтоб стабильно работал c командами, непрерывно собирающими маршруты машинистам. Ссылка та же (http://yadi.sk/d/mvzoWKsX9a9wX)
На консолях светофоры вроде бы разрабатывались я видел, они не вышли? И, Трам_ , вроде ты что-то экспериментировал с пульт-табло для ДСП. Его можно как-то воплатить в жизнь(в ТРС) ?
На консолях светофоры вроде бы разрабатывались я видел, они не вышли?спроси у Teplovozz'а, его разработка.
И, Трам_ , вроде ты что-то экспериментировал с пульт-табло для ДСП.ну, я даже сделал специальный шлюз для его возможного подключения в сигналке sU. Проблема заключается в том, что схему для него создавать невероятно сложно. То есть участок из 3-4 простейших станций может быть и можно создать (закодировать) вручную, но что-то типа этого - http://vk.com/doc-40231285_203026093?dl=2443fcbacef3ff9787 - только с применением специального редактора (который опять же надо с нуля делать), по-другому это не построишь... И нет никакой гарантии что это сможет работать без лагов :( .
Teplovozz
21.09.2013, 20:41
спроси у Teplovozz'а, его разработка.
Очень жду новые головы. :pardon:
*перечитался нормативной документации*
А что у нас с сигнализацией безостановочного пропуска? Точнее случаев её отсутствия. Хотелось бы видеть ЖЖ на входном вне зависимости от выходного при маршруте на путь, по которому не предусмотрен безостановочный пропуск. Да и, вроде бы, кто-то уже просил возможность задавать менее разрешающее показание.
Хотелось бы видеть ЖЖ на входном вне зависимости от выходного при маршруте на путь достаточно двух маркеров - "отклонение + переход на ПАБ". В моей сигналке сделано согласно РУ-30-80 (т.е. выходной на ПАБе не может показывать Жм-Ж, хотя ИСИ говорит обратное).
---------- Сообщение добавлено в 23:48 ---------- Предыдущее сообщение размещено в 23:42 ----------
Да и, вроде бы, кто-то уже просил возможность задавать менее разрешающее показание.на вот этого (т.е. жёлтый вместо зелёного или жёлтого мигающего) не предусмотрено.
Ant.taranish
23.09.2013, 15:06
TRam_, пара вопросов по патчу для 3.7
1. Не может ли быть такого, что после заезда лока за конечный светофор маневрового маршрута последняя стрелка вернется в "исходное" положение, хотя через нее уже собран другой маршрут? У меня происходит такая фигня:
http://i.piccy.info/i8/fffd99f3aca53ddda4eabd108fe8d801/1379937283/23794/167675/wtf_500.jpg (http://piccy.info/view3/5174908/29f1d8ca51dc5b744365daa05545e565/)http://i.piccy.info/a3/2013-09-23-11-54/i8-5174908/500x188-r/i.gif (http://i.piccy.info/a3c/2013-09-23-11-54/i8-5174908/500x188-r)
По-умолчанию стрелка выставлена на отклонение (не заметил, когда правил стрелки)
2. Если маршрут все-таки не разбирается, где искать зарытую собаку? Между любыми двумя стрелками маршрута есть именованные объекты, правда у некоторых из этих стрелок с 3-й стороны таких объектов нет.
Собаки нет. Я этот баг ожидал. Теперь, видимо, придётся для 3.7 ещё и ядро sU переделывать.
ALEXEY401
23.09.2013, 20:34
этого (т.е. жёлтый вместо зелёного или жёлтого мигающего
Ну, не совсем - СЦБисты как то обсуждали случай, что перед жёлтым может быть Жм.
Sandrilyon
23.09.2013, 21:04
TRam_, мне как-то следующая ситуация не попадалась, но чисто теоретически, как сработает zxPath, если поезд, следующий по перегону по удалению соберет входной маршрут на станцию раньше, чем поезд впереди него, который начнет собирать маршрут позже?
Если поезда используют команды, тот там стоит блокировка от этого (поиск другого поезда перед светофором). Так же и в правиле AddAnyPath. А вот для обычных добавленных маршрутов, с использованием обычного AddPath, поезда поедут не по своим маршрутам.
Sandrilyon
23.09.2013, 21:39
А если игрок соберет себе маршрут из браузера на ту станцию, куда перед ним уехал бот, но еще не добрался до точки сборки маршрутов, что в этом случае будет?
Ant.taranish, вроде придумал, как это обходить. Переделка sU не потребовалась.
http://yadi.sk/d/mvzoWKsX9a9wX
---------- Сообщение добавлено 24.09.2013 в 01:00 ---------- Предыдущее сообщение размещено 23.09.2013 в 23:35 ----------
А если игрок соберет себе маршрут из браузера на ту станцию, куда перед ним уехал бот, но еще не добрался до точки сборки маршрутов, что в этом случае будет?бот будет строить свой маршрут от следующего светофора (т.е. от выходного). Так как входной открыт, а команда ищет закрытые светофоры. Но ищет всего 1 раз, поэтому, если светофор откроют во время поисков (или ожидания освобождения) маршрута, команда завершится без сбора маршрута.
Вов, смотри, какая ситуация странная:
http://savepic.su/3327540m.jpg (http://savepic.su/3327540.jpg)
Я даже не могу понять, как такое может произойти. Пока я грузовым заходил на боковой, пассажирский нагнал меня? Так если стрелки не собрали маршрут, почему открылся входной? Хотя в ДСП видно, что маршруты по главному собрались и маршрут на боковой разобран. Я не видел, как это произошло. Пока в кабине ждал, когда же меня обгонит пассажирский, сзади вот такое произошло.
А, остановился пассажирский перед не в ту сторону повернутой стрелкой. Это та, которая пошерстная пассажирскому и ведёт на подъездной путь справа. А под поездом стрелка не перевелась в исходное положение.
возможно где-то затерялся синхронизатор сбрасывающей стрелки.
И маршруты у тебя правилами AddPath, так ведь?
---------- Сообщение добавлено в 15:11 ---------- Предыдущее сообщение размещено в 15:05 ----------
Так если стрелки не собрали маршрут, почему открылся входной?если маршрут собирался бы командой "от красного" или "AddAnyPath", я бы мог сказать, что твой поезд повторно освободил стрелку через длительный интервал времени. В момент открытия светофора стрелка была направлена правильно, иначе он бы не получил разрешающего показания и тем более не открылся бы следующий.
Ты удалил с карты главный контроллер z7? И правило JunctionResetter?
Sandrilyon
24.09.2013, 16:13
Я уткнулся в странную ошибку. Банальная ситуация: маневровый, стрелка, тыльный маневровый... Не могу собрать маршрут на отклонение, по прямой собирает. Уже и пути перекладывал, чего только не делал:
http://s58.radikal.ru/i162/1309/be/d1eb813b3068.jpg
TRam_, не, ларчик, наверное, просто открывался. В тяговой этого локомотива, который с пассажирским, было малое значение max-deccel (как-то так, в общем). Эрендир мне говорил, что оно должно быть около 80000, а стояло 45000.Я поправил, но на следующий прогон уже такая ситуация не повторилась. Мне с моим грузовым удалось достаточно далеко убежать от пассажирского и правила, отвечающие за обгон на этой станции не сработали. Зато, блин, этот скорый так шустро пронесся по входной горловине, что "забыл" разобрать свой входной маршрут. Стрелки слишком близко друг к другу. Надо раздвигать. Да и вообще, надо взять за правило по станциям проходить не более 90-100 км/ч.
А контроллера z7 у меня уже давным давно на картах не присутствует. Насчет JuctionResetter не уверен. Посмотрю, как в редактор попаду, а то у меня на М-Киевской леверы на х-стрелках переводятся под составом. Причем перед последним или предпоследним вагоном.
---------- Сообщение добавлено в 17:57 ---------- Предыдущее сообщение размещено в 17:55 ----------
Sandrilyon, пересчитай стрелки. Не светофоры, а стрелки. А то, небось, где-то по этому маршруту изменял имена или заменял стрелки, не присвоив старое наименование заменяемым леверам. В общем, в любом случае - только пересчет стрелок.
Sandrilyon
24.09.2013, 17:13
Sandrilyon, пересчитай стрелки. Не светофоры, а стрелки. А то, небось, где-то по этому маршруту изменял имена или заменял стрелки, не присвоив старое наименование заменяемым леверам. В общем, в любом случае - только пересчет стрелок.
Да это само собою, каждый раз пересчитываю. Какая-то мистика. В обратную сторону собирается, а в нужную - только по прямой без отклонений.
Sandrilyon, проверь, может у тебя там триггеры или маркеры с совпадающими именами.
Если что - временно перетащи с соседней станции маневровый светофор (чтоб не пересчитывать их), и пользуясь им как "блокировщиком", определи то место, начиная с которого поиск глючит.
PS ошибка означает следующие - "при проверке свободности участка пути между стрелками был выявлен поломанный объект или разрыв пути".
TRam_, он говорит, что в обратную сторону считается. Может быть левер неправильно установлен? Пошерстно считает, а противошерстно - нет. Такое может быть? Да, кстати, о маневровых. Я тут однажды сманеврировал по Киевской, убирал состав от пассажирских платформ в парк. Так он мне такую змейку нарисовал. По какому принципу собираются маневровые маршруты? Я думал, что выбирается тот маршрут, у которого наименьшее количество стрелок.
Sandrilyon
24.09.2013, 21:04
Долго определял, где ошибка. Оказалось, проблемное место было аж в другой горловине. Ошибку генерировал маневровый светофор, стоящий спиною с красной линзой из вытяжного тупика. И до того места получалось более 2 км! Но дело не совсем в нем. Перед ним была стрелка, так что из тупика можно было в обход горловины попасть в середину станции только маневровым порядком, короче, туда, где и находился проблемный участок. В общем, удаляю этот светофор - багов нет, все открывается, возвращаю обратно - снова те же ошибки. Чтобы оставить светофор и не убирать вытяжной тупик, пришлось убрать обходной путь. Теперь все без ошибок. 2 час убил на это.
2 час убил на это.
Хех, удивил! Бывают заморочки, над которыми днями бьёшься! Понимаешь, что где-то сам лажанулся, а где именно - не понимаешь. Вот и строишь такие защитные барьеры. Я когда Бекасово настраивал, чуть вообще умом не тронулся. Понятное дело, что "игрушка", понятное дело, что можно забить, да как-нибудь примитивно сделать, лишь бы ошибки не было - и ладно. Ан нет, гложет же: неужели я такой дурак, что не смогу эту фигню одолеть?..
А что касается твое проблемы:
так что из тупика можно было в обход горловины попасть в середину станции только маневровым порядком,
Так ты что, из тупика пытался поездной маршрут посчитать? Да ещё и без стоп-триггеров? Чё-то я не въехал в твою проблему до конца-то.
По какому принципу собираются маневровые маршруты? Я думал, что выбирается тот маршрут, у которого наименьшее количество стрелок.
По идее должен выбираться тот, который короче.
С учётом того, что расчёт длины несобранного маршрута, фактически, невозможен (т.е. померять можно только переведя стрелки, а переводить стрелки для поиска маршрута нельзя). Поэтому пока что так - вначале поиск проходит по стрелке так, как она выставлена по в редакторе (на момент инициализации стрелок), а затем - по отклонению этой стрелки. Причём поиск ведётся не "от ближайших" (к светофору начала маршрута), а "от самых дальних" (при этом экономится память - не надо хранить 100500 вариантов маршрутов, ведущих не туда куда надо). Вариантные маршруты для маневровых, кстати, вовсе не ищутся (т.е. принцип "первый попавшийся") - зато работают там, где "найти все варианты" (у поездных маршрутов) вываливается с ошибкой "зависание скрипта"
Sandrilyon
25.09.2013, 00:55
Самое интересно, что при просчете маршрутов, zxPath, бывает, первым находит более длинные маршруты. По привычке начинаешь отсекать те, что внизу, но на некоторых станциях самые короткие бывают в конце. Если быть невнимательным, то потом появляются "змейки". Я так думаю, первым маршрут считается тот, что без отклонений, но на станциях разное бывает...
Я так думаю, первым маршрут считается тот, что без отклонений, но на станциях разное бывает...уже ответил. Первым идёт тот маршрут, у которого все стрелки стоят так, как в редакторе (кроме пошёрстных). Далее идёт маршрут, у которого самя дальняя стрелка переведена. Далее - предпоследняя переведена... И так далее.
Вов, а стоп-триггеры именно для маневровых маршрутов сложно дополнить? На станциях, типа М-Киевская логично рассчитывать, в том числе и маневровые, маршруты по уборке составов с путей у платформ так, чтобы эти маневры не мешали, насколько это возможно, вновь прибывающим поездам.
В качестве стоп-триггеров нужны маневровые светофоры, отнесённые к другому парку. Возможно невидимые. Но так же как стоп-триггеры, они полностью блокируют движение через себя в маневровом порядке.
---------- Сообщение добавлено в 01:48 ---------- Предыдущее сообщение размещено в 01:44 ----------
Построение поездных маршрутов их не видит.
Ant.taranish
25.09.2013, 19:56
вроде придумал, как это обходить. Переделка sU не потребовалась.
К сожалению, исправленное правило не решает проблему с поломкой маршрута. Ставил с перезаписью, чистил кэш, удалял-добавлял правило - не помогло.
а, это маневровый... Сразу и не понял, думал поездной. Ну что ж, посмотрю ещё.
---------- Сообщение добавлено 26.09.2013 в 01:39 ---------- Предыдущее сообщение размещено 25.09.2013 в 20:35 ----------
Промоделировал у себя и понял в чём дело. В том, что выходной светофор повторно "сбрасывает занятость" вне зависимости от того, какой маршрут к нему был проложен (поездной или маневровый), а как оказался проложен в момент заезда за него. Так что прийдётся немного дорабатывать и sU core, и zxPath Maibase .
Sandrilyon
26.09.2013, 19:23
TRam_, твое модифицированное правило UnPortal, а именно опция выпускать в рэндомном порядке поезда из портала работает не совсем уж рэндомно. За 50 запусков у меня не разу не вышел один из 5 поездов, зато поезд, прописанный под №1 в списке для портала, выпускается из него "неслучайно" часто. Так если подумать, то на 5 поездов получается вот такая "рэндомность": поезд №1 - 50% вероятности, №2 - 25, №3 -12.5% и т.п. Как так?
Хотя, наверное, ты и не трогал эту опцию, а она осталась от изначального автора.
:ps: И можно ли в этом правиле сделать, что первым выпускался поезд не из последнего в списке портала, а из всех случайным образом?
За 50 запусков у меня не разу не вышел один из 5 поездов
Это нормально. В этом генераторе числе, как и в большинстве, никогда не будет значения 1. Потому максимальное значение надо задавать как "кол-во чего либо" + 1
выпускается из него "неслучайно" часто
Это генератор псевдослучайных чисел. Это значит, что при каждом новом запуске ТРС последовательность выдаваемых чисел всегда одинаковая...
И можно ли в этом правиле сделать, что первым выпускался поезд не из последнего в списке портала, а из всех случайным образом?в той редакции которая есть, одно правило может выпускать одновременно только один поезд.
Sandrilyon
26.09.2013, 23:06
И можно ли в этом правиле сделать, что первым выпускался поезд не из последнего в списке портала, а из всех случайным образом?в той редакции которая есть, одно правило может выпускать одновременно только один поезд.
Это я знаю. Суть в том, что я последовательно вписываю имеющиеся на карте порталы в правило, и тот портал, который оказывается в списке последний, первым выпустит состав на карту при старте сессии. И так далее по списку вверх. Не фатально, конечно, но смешно, если такое не корректируется скриптом.
Скорректировать может и можно, но не в том виде, в котором оно есть сейчас. Т.е. я имею в виду проще будет переписать половину правила заново.
---------- Сообщение добавлено 27.09.2013 в 00:06 ---------- Предыдущее сообщение размещено 26.09.2013 в 23:30 ----------
Итак, исправил работу стрелок в случае, найденном Ant.taranish'ом, за что я ему очень благодарен. Одновременно при этом был исправлен разбор маршрута на тот станционный путь, где нет выходного обратного направления (т.е. если там только маневровый с синей линзой или вовсе ничего нет).
Скачать Fix4 - http://yadi.sk/d/dBftfwp79xFbT
Также небольшое исправление сделано в zxPath Junction Resetter , http://yadi.sk/d/mvzoWKsX9a9wX
---------- Сообщение добавлено в 01:01 ---------- Предыдущее сообщение размещено в 00:06 ----------
ещё один баг нашёл, ссылку обновил.
С учётом того, что расчёт длины несобранного маршрута, фактически, невозможен (т.е. померять можно только переведя стрелки, а переводить стрелки для поиска маршрута нельзя). Поэтому пока что так - вначале поиск проходит по стрелке так, как она выставлена по в редакторе (на момент инициализации стрелок), а затем - по отклонению этой стрелки. Причём поиск ведётся не "от ближайших" (к светофору начала маршрута), а "от самых дальних" (при этом экономится память - не надо хранить 100500 вариантов маршрутов, ведущих не туда куда надо). Вариантные маршруты для маневровых, кстати, вовсе не ищутся (т.е. принцип "первый попавшийся") - зато работают там, где "найти все варианты" (у поездных маршрутов) вываливается с ошибкой "зависание скрипта"
Получается, при расчёте поездных маршрутов их длина не измеряется?
Нет. Она измеряется только при "автоудалении вариантных", для чего последовательно собирается каждый из маршрутов от одного светофора к другому, и затем удаляются те, которые длиннее чем самый короткий.
Измеряется только полезная длина станционного пути (между выходными).
Вов, так Resetter этот нужно ставить или нет?
NickLon, на 3.6 нет, это патч для версии 3.7
Нет. Она измеряется только при "автоудалении вариантных", для чего последовательно собирается каждый из маршрутов от одного светофора к другому, и затем удаляются те, которые длиннее чем самый короткий.
Измеряется только полезная длина станционного пути (между выходными).
Может стоит ввести предварительный расчёт элементарных маневровых маршрутов в редакторе? Рассчитывать только ближайших соседей для каждого светофора, измеряя расстояние до каждого из них переводя стрелки. Тогда в машинисте при задании маневрового маршрута между двумя светофорами система будет строить его из заранее рассчитанных элементарных маршрутов и, зная длину каждого, собирать самый короткий составной маршрут. Здесь есть рациональное зерно?
Здесь есть рациональное зерно?Учитывая, сколько бывает элементарных маневровых маршрутов на средних и больших картах - не очень, хотя бы даже если взять потребление памяти на их хранение. Да и выигрыш от 5-6 лишних метров получится небольшой - тут зависит больше от того, кому этот маневровый сможет помешать своим маршрутом. А это можно предусмотреть, выставив стрелку "по умолчанию" (в редакторе перед инициализацией) нужным образом.
Сумма вариантов комбинаций элементарных маршрутов будет ровно такой же, как сумма вариантов сложных маршрутов, так что поиск среди них будет не проще, чем поиск сложного маршрута среди стрелок (т.е. мы опять же приходим к тому, что сможем без ошибки найти только один маневровый маршрут).
TRam_, я тебе один умный вещь скажу...
Используй функцию JunctionBase.BeginTrackSearch(int). Позволяет искать в любом направлении.
Что-бы это значило?
http://savepic.org/4478608m.jpg (http://savepic.org/4478608.htm)
B.U.G.O.R.
27.09.2013, 17:35
Что-бы это значило?
Видимо, что-то произошло.
Видимо, ДААААА...
Не могешь ответить, нефиг подкалывать...
tolrum, что один из твоих поездов пытаешься собрать маршрут без единой стрелки. Такие маршруты недопустимы в этой системе (между любыми 2мя поездными светофорами должна быть по крайней мере невидимое ответветвление с стрелкой).
Если более подробно - ошибка доступа к массиву, в котором содержится имя, направление и пошёрстность последней стрелки маршрута по причине отсутствия стрелок в маршруте и неинициализации массива.
---------- Сообщение добавлено в 17:55 ---------- Предыдущее сообщение размещено в 17:47 ----------
kemal, возможно со временем на неё перейду. В 2010ом трейнзе (а именно в его API создавалась концепция z7-xPath) такой функции не припомню.
---------- Сообщение добавлено в 19:48 ---------- Предыдущее сообщение размещено в 17:55 ----------
Fix 4 ещё раз обновил, добавил расшифровку для случая tolrum'a (какой светофор с маршрутом без стрелок) и довёл до ума тот момент, который вчера ночью правил. http://yadi.sk/d/dBftfwp79xFbT
TRam_, как думаешь, может есть ли смысл реорганизовать систему следующим образом:
Как я понимаю, рассчитанное путевое хозяйство (комплекс стрелок с указанием соседей - правильно?) хранится отдельно, комплекс светофоров - отдельно, рассчитанные поездные маршруты - тоже отдельно, маневровые - рассчитываются и строятся во время игры. А ведь это элементы одной системы. Может, стоит их объединить? А именно: рассчитывать путевое хозяйство как комплекс стрелок с указанием соседей и расстояния между ними, маркеров и светофоров. И не рассчитывать маршруты заранее, а делать это перед сборкой нужного маршрута в игре. Лирика: одни и те же поездные маршруты можно рассчитать по-разному, что повышает гибкость системы при плотном движении (маневровый застрял на пути, стрелка заблокирована); при введении системы маркеров (об этом ниже) можно не указывать конкретный путь приёма (или группы путей по приоритетам), а просто тип операции (разборка, транзит со сменой локомотива, транзит со сменой бригады, пропуск на ходу, пропуск с остановкой, приём, отправление на такое-то направление и т.д.), упрощенное и более понятное использование из-за упразднения приоритетов путей и уменьшения кол-ва правил и команд взамен на систему маркеров.
Теперь о системе маркеров. Как мы знаем, каждый путь на станции имеет специализацию. Цикл обработки поезда состоит из выполнения с ним ряда конкретных операций, для каждой из которых специализируется какой-либо путь. Специализация пути и информация о нём хранится в маркере, на нём установленном. Задав для ДСП операцию с поездом, тот (в лице системы) ищет подходящий маркер и собирает маршрут на путь с ним. Такой подход более гибкий, т.к. "поднимает" пользователя от уровня ДСП ближе к уровню ДНЦ. А это - шаг в сторону диспетчеризации, когда пользователю не надо будет находиться даже на уровне ДНЦ.
CFM, это ни разу не упрощение.
И не рассчитывать маршруты заранее, а делать это перед сборкой нужного маршрута в игре.Тебя не поймёшь - то тебе надо заранее делать элементарные маневровые маршруты, то тебе надо отказаться от элементарных поездных маршрутов и делать их глобальными :) .
Поездные маршруты должны быть элементарными и генерироваться заранее для того, чтобы указать категорию (назначение, используемость) пути, к которому ведёт этот маршрут, а также важность самого маршрута. Чтоб поезд в первую очередь выбирал тот маршрут, который мы считаем более важным. Поскольку мы-то луче знаем, где путь, возможно, чуть-чуть длиннее, но зато будет меньше мешать остальным поездам.
Может, стоит их объединить?неудобно объединять. Будка - глобальный объект, но в то же время она не нужна светофорам, и кроме того, светофоры могут управляться и другими типами скриптов (диспетчеризация Эрендира, например). Поэтому будку неразрывно встраивать в светофоры бессмысленно. Правило маневровых маршрутов может быть и можно встроить в будку, но я не вижу особой необходимости в этом. Каких-то специальных настроек оно не требует (за исключением чисто браузерных скрыть/показать, свернуть/развернуть), а значит никакого сокращения времени настройки их объединение не даст.
Опять же, никакого прироста производительности это не даст. Потому что все три системы друг о друге всё нужное знают и общаются напрямую (публичными функциями), т.е. ровно точно так же, как если бы это был один скрипт.
---------- Сообщение добавлено в 12:15 ---------- Предыдущее сообщение размещено в 11:36 ----------
Цикл обработки поезда состоит из выполнения с ним ряда конкретных операций, для каждой из которых специализируется какой-либо путь.а если этот путь уже занят?
Идея приоритетов маршрутов в том, что их можно отождествить с 20 видами операций. Какая именно операция будет соответвтвовать какому приоритету - решать уже тебе.
P.S. Я не движенец, а специалист по прикладной механике, металловед и инженер-конструктор, потому и не могу самостоятельно записать все виды обработки поездов на станции. А приоритеты универсальны - им не только тип обработки можно поставить, но и порядок важности этих обработок, да и не только. Например, на какое направление нужно идти поезду при отправлении с узловой станции.
---------- Сообщение добавлено в 12:24 ---------- Предыдущее сообщение размещено в 12:15 ----------
(маневровый застрял на пути, стрелка заблокирована);ну в данной системе принудительной разблокировки стрелок нету, разве что проехать маневровым по заблокированной стрелке в направлении её блокировки :) .
Тебя не поймёшь - то тебе надо заранее делать элементарные маневровые маршруты, то тебе надо отказаться от элементарных поездных маршрутов и делать их глобальными .
Да, изначально я предлагал рассчитывать элементарные маневровые маршруты, но ты сказал, что это создаст дополнительную нагрузку на память и производительность не увеличит. И я попробовал пойти по другому пути - вообще не рассчитывать никаких маршрутов заранее, что позволит собирать их более гибко для обхода разных ситуаций, которые сделали бы невозможным сбор заранее рассчитанного маршрута, а также не хранить их в памяти.
Поездные маршруты должны быть элементарными и генерироваться заранее для того, чтобы указать категорию (назначение, используемость) пути, к которому ведёт этот маршрут, а также важность самого маршрута.
В моей мысли указание назначения пути происходило в маркере, установленном на нём. И при необходимости определённой обработки поезда на станции система смотрела, какие пути подходят для такой обработки и собирала маршрут от пути, где находится поезд на путь, куда его нужно направить. Вот что ты думаешь об этом подходе к хранению назначения и свойств путей в маркерах, а также поиске и сборе маршрутов между двумя маркерами вместо хранения свойств путей в приоритетах заранее рассчитанных маршрутов? По-моему, это значительно повышает гибкость и живучесть системы.
что позволит собирать их более гибко для обхода разных ситуаций, которые сделали бы невозможным сбор заранее рассчитанного маршрута,ну так поездные маршруты рассчитываются все возможные. Я в самых первых редакциях z7-xPath даже делал автоматический перебор всех вариантных маршрутов, но потом понял, что только потери времени. Поэтому это всё свалил на команды машинисту и правила (которые как раз и ищут самый первый маршрут, который можно собрать, и по возможности самый приоритетный).
В моей мысли указание назначения пути происходило в маркере а почему не в задании машинисту поезда, то есть его командах? Как по мне, это ещё более гибко - мы не привязаны к конкретному пути.
а если этот путь уже занят?
Ну ясен пень, что тогда не собирать туда поездной маршрут.
Идея приоритетов маршрутов в том, что их можно отождествить с 20 видами операций. Какая именно операция будет соответвтвовать какому приоритету - решать уже тебе.
Здесь ошибка в том, что маршруты не нужно отождествлять с операциями. Нужно разделить задачи. Маршруты - это всего лишь путь между двумя специализированными путями, который может быть собран по-разному, что очень ценно для станций, которые сложнее разъездов и для участков хотя бы со среднем движением. А отождествлять операции надо как раз-таки с путями. Это даёт гибкость системе - нужно лишь найти наиболее короткий и не конфликтующий маршрут между двумя путями.
не могу самостоятельно записать все виды обработки поездов на станции. А приоритеты универсальны - им не только тип обработки можно поставить, но и порядок важности этих обработок, да и не только.
На самом деле виды обработок жёстко определены и конкретны, их таки можно узнать и указать. Но даже если больше по душе приоритеты, то лучше их присваивать путям, а не маршрутам.
ну в данной системе принудительной разблокировки стрелок нету, разве что проехать маневровым по заблокированной стрелке в направлении её блокировки .
А если маневровым, но направление стрелки враждебное?мА если надо поездным? А если и вовсе локомотив оттуда не успел уйти? В существующей системе поезд бы встал и, возможно, повесил бы движение. В моей мысли нашёлся бы вариантный маршрут, по которому спокойно обошлось бы проблемное место.
о даже если больше по душе приоритеты, то лучше их присваивать путям, а не маршрутам.именно для этого я и вынес приоритеты, устанавливаемые маршрутам по умолчанию, в светофоры (для данного случая важны именно выходные/маршрутные светофоры). И светофоры будут выполнять роль тех самых "маркеров пути" с "нужным назначением". А дополнительно в вариантных маршрутах можно указать , например, менее удобные способы попадания на путь.
---------- Сообщение добавлено в 13:19 ---------- Предыдущее сообщение размещено в 13:15 ----------
В существующей системе поезд бы всталон бы выбрал альтернативый маршрут, если его конечно не удалили с помощью автоудаления. Ну или если приоритет вариантного маршрута был ваставлен сильно отличающимся от целевого и не попал в диапазон собираемых командой маршрутов прибытия.
Я в самых первых редакциях z7-xPath даже делал автоматический перебор всех вариантных маршрутов, но потом понял, что только потери времени.
Да, трата времени - потому что это предварительный расчёт всех возможных маршрутов от всех возможных светофоров до всех возможных светофоров. Если рассчитывать во время игры - то гораздо быстрее, потому что не нужно искать от всех возможных светофоров, а только от необходимого, а от этого необходимого не нужно искать до всех возможных, а только до тех, которые стоят на подходящих путях. Круг в разы сужается.
а почему не в задании машинисту поезда, то есть его командах? Как по мне, это ещё более гибко - мы не привязаны к конкретному пути.
Опять же - нужно разделять задачи. Назначение пути должно храниться в самом пути, а не в задании машиниста. В задании машиниста пусть хранятся задачи поезда, который он ведёт. И пусть он сопоставляет задачи поезда со специализацией путей.
CFM, почитал я это всё твоё. Куча, конечно же, вопросов и комментариев к твоим мыслям и высказываниям возникло. Хотел даже набирать. А потом одна единственная фраза возникла - а ты вот теми средствами, которые уже есть что-то пытался сделать? Или ты, а-ля О.Бендер нам про Нью-Васюки рассказываешь?
Я - попытался. Точнее даже не попытался, а почти сделал. У меня Москва-Киевская (станция на карте Трамвайза "Малоярославец-Москва) почти пляшет! И вот это самое "почти" у меня убило охоту дальше пытаться уговаривать разработчиков "создать мне ДСП, ДНЦ и т.д." Потому что, если я, зная ЖД, понимая направления задумок разработчиков, мумукаюсь с тем, что, оказывается, светофоры "не так сели", оказывается лок немного опоздал, маневровый передержался, удивляюсь: как ты себе представляешь какие-то там расчеты маневровых и тому подобное?
:ps:Я не хотел тебя обидеть. Но от такого матерого "Трэйнзера" (только что слово выдумал) я не ожидал бы Нью-Васюков.
именно для этого я и вынес приоритеты, устанавливаемые маршрутам по умолчанию, в светофоры (для данного случая важны именно выходные/маршрутные светофоры). И светофоры будут выполнять роль тех самых "маркеров пути" с "нужным назначением". А дополнительно в вариантных маршрутах можно указать , например, менее удобные способы попадания на путь.
Тоже не совсем верно с точки зрения разделения задач. Ты присвоил приоритеты не совсем подходящему элементу системы - светофорам. А ведь светофор - разграничитель участков, который должен разрешать/запрещать движение и всё. И у одного пути, как правило, два, а то и более светофоров. В каком из них хранить инфу? А маркер - более универсальное, логичное и удобное решение (на мой взгляд, разумеется). Настраивать свойства пути в маркере удобнее и понятнее, чем в светофорах и маршрутах. Для системы правильнее и проще - нужно сначала найти подходящий маркер под нужную операцию, потом найти маркер, на котором стоит поезд и собрать маршрут между этими маркерами.
он бы выбрал альтернативый маршрут, если его конечно не удалили с помощью автоудаления.
Вот видишь. Практически все пользуются автоудалением.
Ну или если приоритет вариантного маршрута был выставлен сильно отличающимся от целевого и не попал в диапазон собираемых командой маршрутов прибытия.
Ну вот то, о чём я говорил - приоритеты хранятся там, где вообще не должны. У маршрута не должно быть приоритета, приоритет должен быть у специализированного пути. Тогда на путь нужного приоритета (специализации) можно собрать вариантный маршрут в случае чего.
В каком из них хранить инфу?в том, который соответствующего направления. Маркеров, кстати, тоже нужно было бы два - для чётного и нечётного направлений.
Если ты специализируешь путь под чётные поезда, то для нечётных ты должен их закрыть.
Настраивать свойства пути в маркере удобнее и понятнее, чем в светофорах и маршрутах.1) нужно два маркера минимум
2) светофоры уже есть на карте.
3) понятности не вижу. Светофоры, так же как и маркеры, и триггеры, имеют направление и ЗОНУ ДЕЙСТВИЯ (в отличии от светофоров реальной ж/д). Потому разница с маркерами только в их расположении на пути (и соответственно моменте срабатывания при попадании поезда на путь)
И у одного пути, как правило, два, а то и более светофоров.моя маршрутизация поддерживает один или два разнонаправленных поездных светофора на огороженном стрелками пути. Либо между светофорами ними нужно встраивать невидимую сбрасывающую стрелку (потому что унифицированный со стрелками изостык я не придумал как реализовать).
И вот это самое "почти" у меня убило охоту дальше пытаться уговаривать разработчиков "создать мне ДСП, ДНЦ и т.д."
Вот здесь момент истины и точка наших с тобой расхождений зарыта - "почти" для тебя - конечная, для меня - отправная. Вот моё мнение насчёт нынешних систем и твоих попыток с ними справиться. Системы эти - неполноценны для организации автоматического движения (т.к. задумывались немного не для этого). Ты с ними пытаешься его организовать (построить космический корабль с помощью лишь молотка и зубила), что, естественно, почти невозможно. Я предлагаю дополнить их, чтобы автоматическое движение стало возможным. По-моему, мои предложения обоснованы и аргументированы.
По-моему, мои предложения обоснованы и аргументированы.список аргументов с преимуществом маркеров против светофоров для описания свойств пути. По пунктам.
Список аргументов жёсткой привязки специализации к пути против привязки к заданию машиниста (списку команд/путевому листу).
в том, который соответствующего направления. Маркеров, кстати, тоже нужно было бы два - для чётного и нечётного направлений.
Если ты специализируешь путь под чётные поезда, то для нечётных ты должен их закрыть.
Почему нельзя хранить информацию только в одном маркере? Его же можно найти поиском, идущем в любом направлении?
понятности не вижу. Светофоры, так же как и маркеры, и триггеры, имеют направление и ЗОНУ ДЕЙСТВИЯ (в отличии от светофоров реальной ж/д). Потому разница с маркерами только в их расположении на пути (и соответственно моменте срабатывания при попадании поезда на путь)
Эти маркеры не нужны для обрабатывания входа/выхода поезда, они нужны лишь как хранилище информации о пути.
Если рассчитывать во время игры - то гораздо быстрее, потому что не нужно искать от всех возможных светофоров, а только от необходимого, а от этого необходимого не нужно искать до всех возможных, а только до тех, которые стоят на подходящих путях. Круг в разы сужается.дай определние "подходящий путь" и способ, в 100% случаев позволяющий сразу найти именно его. Расчитывать во время игры кстати дольше, чем просто проверить список стрелок на занятость и путь приёма .
---------- Сообщение добавлено в 14:44 ---------- Предыдущее сообщение размещено в 14:41 ----------
Почему нельзя хранить информацию только в одном маркере? Его же можно найти поиском, идущем в любом направлении?можно, но зачем? Полезнее это разделить, дабы не путаться. Хотя, не спорю, одновременный просмотр свойств обоих направлений одного пути даёт меньше вероятности сделать им конфликтующие назначения.
Эти маркеры не нужны для обрабатывания входа/выхода поездаа почему светофоры не могут использоваться для хранения дополнительных свойств?. Они не только огораживают путь, но и стоят на нём. Участки пути между светофорами и стрелками (снаружи пути) никакой специализации нести не могут и не должны.
CFM, для меня "почти" - это означает, что сейчас попытаюсь что-нибудь придумать. Придумал. Идёт прогон. Буду посмотреть.
А для тебя, как я понял, это не то, чтобы точка отправная, а некий барьер, за которым "я сижу и хочу, чтобы мне принесли: пирожжжное, морожжжное". У тебя очень много идей хороший, но они же так и останутся идеями. Ты об этом не думал?
Вот попытайся, для начала, "неполноценными для организации автоматического движения" системами попользоваться, а потом скажи, что нужно в этом "ущербном" хозяйстве модернизировать.
Я неоднократно намекал (в теме, например, про маршрутизацию): не надо усложнять, не стоит всё конкретизировать так, как это происходит на РЖД. Тысячи людей делают то, что ты, и иже с тобой, хотят, чтобы сделал TRam_. Никогда этого не будет. А вот что-то более простое и понятное (Люся-Клава-.. и кто-то там ещё было, не помню) реализовать можно.
список аргументов с преимуществом маркеров против светофоров для описания свойств пути. По пунктам.
1. Разделение задач между элементами системы, что логичнее и необходимо для дальнейших ступеней развития диспетчеризации.
2. Необходимость переработать логику системы на уровне ДСП для её большей самостоятельности и гибкости. Предлагаемая логика - поиск пути с конкретной специализацией согласно заданию поезда, определение пути нахождения поезда, поиск и сборка маршрута между этими двумя путями.
3. Большая гибкость системы и сопротивляемость нештатным ситуациям благодаря отсутствию жёстко заданных маршрутов и игнорированию вариантов.
4. Экономия времени и памяти на расчёте сразу всех поездных маршрутов и удалении вариантных.
5. Большая интуитивная и визуальная понятность системы при использовании маркеров для описания свойств пути, а не светофоров.
6. В плане хранения информации: один путь - один маркер вместо один путь - два светофора. Таким образом, получается оптимизация при настройке и поиске маркеров, а ещё сужается круг возможных ошибок, когда части информации находится не в одном месте, а в разных.
Список аргументов жёсткой привязки специализации к пути против привязки к заданию машиниста (списку команд/путевому листу).
1. Разделение задач между элементами системы, что логичнее и необходимо для дальнейших ступеней развития диспетчеризации.
2. Гибкость системы, её большая самостоятельность. Пользователю вообще не надо указывать поездам диапазон допускаемых путей приёма, достаточно один раз настроить маркеры на уровне карты.
3. Экономия времени и памяти ввиду ненужности задавать специализации путей каждому машинисту в каждой сессии.
---------- Сообщение добавлено в 12:37 ---------- Предыдущее сообщение размещено в 12:23 ----------
дай определние "подходящий путь" и способ, в 100% случаев позволяющий сразу найти именно его.
Подходящий путь - путь, специализация которого соответствует предстоящей операции с поездом. Способ - определение предстоящей операции, поиск среди маркеров тех, чья специализация подходит для такой операции.
а почему светофоры не могут использоваться для хранения дополнительных свойств?. Они не только огораживают путь, но и стоят на нём.
Опять же - разделение задач. В данном случае со светофорами - для более удобного восприятия и работы с системой. Получается, чтобы узнать свойство пути, нужно лезть в светофор (в какой конкретно?) или в команды машинисту (найди среди того навала команд нужную инфу). А так - увидел маркер в центре пути, открыл свойства - а там вся необходимая информация.
Участки пути между светофорами и стрелками (снаружи пути) никакой специализации нести не могут и не должны.
Естественно.
---------- Сообщение добавлено в 12:56 ---------- Предыдущее сообщение размещено в 12:37 ----------
"я сижу и хочу, чтобы мне принесли: пирожжжное, морожжжное"
Разве? Я же не сижу и не клянчу "ну когда выйдет", а активно вношу свою лепту, какую могу.
У тебя очень много идей хороший, но они же так и останутся идеями.
Слава богу, что идеи оказались хорошими. А вообще люди не умеют мечтать (не в сопливом смысле), а ведь именно с них всё и начинается. К тому же я стараюсь мечты строить на реальных исходных данных, а не на воздухе.
Я неоднократно намекал (в теме, например, про маршрутизацию): не надо усложнять, не стоит всё конкретизировать так, как это происходит на РЖД. Тысячи людей делают то, что ты, и иже с тобой, хотят, чтобы сделал TRam_. Никогда этого не будет.
А я отвечал, что тысячи людей из-за того, что они рассчитывают всю РЖД с пассажирскими перевозками, с учётом экономики, статистики и прочей неземной науки, а нам нужно максимум 600 км, без расчёта пассажирских, без расчёта экономики и т.д. Ведь разница колоссальна.
А вот что-то более простое и понятное (Люся-Клава-.. и кто-то там ещё было, не помню) реализовать можно.
Да, можно быстрее и проще реализовать, но в итоге это споткнётся об отсутствие централизации и жёсткой иерархии перевозок (как сейчас, только в более крупном масштабе), об отсутствие взгляда на организацию движения в целом, как на согласованный процесс.
Большая гибкость системы и сопротивляемость нештатным ситуациям благодаря отсутствию жёстко заданных маршрутов и игнорированию вариантов.и как это относится к свойствам в маркере/в светофоре? Ведь если ты задашь только один путь с такой категорией, то никаких вариантов у тебя не будет, если этот путь занят.
когда части информации находится не в одном месте, а в разных.что мешает сделать правило, которое синхронно задаёт свойства двум светофорам одного пути :) ?
поиск пути с конкретной специализацией согласно заданию поезда, определение пути нахождения поезда, поиск и сборка маршрута между этими двумя путями что уже сейчас делается командами машиниста. Единственное что - строку "назначение" заменить на число "приоритет".
В данном случае со светофорами - для более удобного восприятия и работы с системой. Получается, чтобы узнать свойство пути, нужно лезть в светофор (в какой конкретно?)ничто не мешает сделать правило дистанционного управления двумя светофорами одновременно. Но это именно функциональная, а не идеологическая проблема.
---------- Сообщение добавлено в 16:21 ---------- Предыдущее сообщение размещено в 16:20 ----------
Пользователю вообще не надо указывать поездам диапазон допускаемых путей приёма, достаточно один раз настроить маркеры на уровне карты.или один раз настроить светофоры на карте.
---------- Сообщение добавлено в 16:23 ---------- Предыдущее сообщение размещено в 16:21 ----------
ввиду ненужности задавать специализации путей каждому машинисту в каждой сессии.кто будет определять, что это за поезд и что он должен делать. Внешняя программа расчёта расписания?
---------- Сообщение добавлено в 16:26 ---------- Предыдущее сообщение размещено в 16:23 ----------
Экономия времени и памяти на расчёте сразу всех поездных маршрутов и удалении вариантных.1) вначале все вариантные маршруты надо найти
2) затем их надо сравнить по длине
3) потом надо собрать самый короткий и забыть все остальные
Вместо:
1) проверить готовые маршруты между путями
2) выбрать из них, по нашему мнению (т.е. настройке), наилучший
3) собрать его
CFM, то что ты предлагаешь, это утопия. Дополнительные маркеры - дополнительная возня. Простая система та, где возни с настройками и элементами меньше, а ты предлагаешь ещё и маркеры добавить.
А уж про поиск маршрута во время игры, так это вообще жесть. Действительно, почему бы не перенести самую рессурсозатратную операцию из редактора прямиком в игру. Класс придумал.
Да, рациональные идеи есть, но они мигом разбиваются о неправильное направления реализации.
Лично я не могу себе представить (на текущий момент) более унифицированого подхода, что сделал Tram_. Да, он не идеален, но пока это самое простое и удачное решение.
и как это относится к свойствам в маркере/в светофоре? Ведь если ты задашь только один путь стакой категорией, то никаких вариантов у тебя не будет, если этот путь занят.
Имелось в виду сбор вариантных маршрутов на этот путь.
что мешает сделать правило, которое синхронно задаёт свойства двум светофорам одного пути ?
Неудобство помноженное на неудобство. Почему просто не поставить один маркер в центр пути и не указать там всё?
что уже сейчас делается командами машиниста. Единственное что - строку "назначение" заменить на число "приоритет".
Суть не в том, что это уже делается, а в том, что это лучше делать не с помощью приоритетов маршрутов, а с помощью специализации маркеров.
ничто не мешает сделать правило дистанционного управления двумя светофорами одновременно. Но это именно функциональная, а не идеологическая проблема.
Даже как функциональная - система с маркерами проще, понятнее и естественнее, чем система двух светофоров и правила.
или один раз настроить светофоры на карте.
Я о том, что каждый раз указывать машинисту диапазон приоритетов муторно. С маркерами ты просто указываешь машинисту задание на поезд, и каждая станция сама обрабатывает его и выбирает подходящий путь.
кто будет определять, что это за поезд и что он должен делать. Внешняя программа расчёта расписания?
В законченной системе диспетчеризации - она сама, в предлагаемом мной варианте - пользователь. Подчёркиваю, что он это делает один раз, просто указывая операции для каждой проследуемой станции (посадка пассажиров, смена локомотива, отправление на такое-то направление, разборка, оборот) а ДСП станции, к которой приближается этот поезд в соответствии с заданием выбирает ему нужный путь.
1) вначале все вариантные маршруты надо найти
2) затем их надо сравнить по длине
3) потом надо собрать самый короткий и забыть все остальные
Но это делается только для двух конкретных светофоров - начала и конца маршрута. В твоём случае рассчитываются все возможные маршруты между всеми возможными светофорами.
---------- Сообщение добавлено в 14:10 ---------- Предыдущее сообщение размещено в 14:03 ----------
Дополнительные маркеры - дополнительная возня. Простая система та, где возни с настройками и элементами меньше, а ты предлагаешь ещё и маркеры добавить.
Я не предложил вдобавок к существующей возне добавить возню с маркерами, я предложил распределить и даже немного сократить уже имеющуюся возню более логично и удобно - оставив каждому элементу только свой круг задач. Светофоры больше не хранят информацию о свойствах пути, список маршрутов, маршрутов вообще нет, машинист больше не совмещает функции ДСП, а просто хранит информацию о задачах поезда.
А уж про поиск маршрута во время игры, так это вообще жесть. Действительно, почему бы не перенести самую рессурсозатратную операцию из редактора прямиком в игру. Класс придумал.
Так я же приводил доводы. Я не предлагал переносить поиск маршрутов в машинист в существующем виде, когда происходит расчёт ВСЕХ светофоров станции. Я предлагал рассчитывать маршрут только между двумя светофорами по мере необходимости.
Почему просто не поставить один маркер в центр пути и не указать там всё?потому что его дополнительно надо ставить. А светофор на пути будет всегда, если там предусмотрено поездное движение. Зачем лишний объект в центре пути?
---------- Сообщение добавлено в 17:19 ---------- Предыдущее сообщение размещено в 17:18 ----------
что это лучше делать не с помощью приоритетов маршрутов, а с помощью специализации маркеров.в чём их смысл? Отделить настройки светофоров от свойств пути? Зачем?
---------- Сообщение добавлено в 17:20 ---------- Предыдущее сообщение размещено в 17:19 ----------
С маркерами ты просто указываешь машинисту задание на поездчем отличается задание на поезд с навзваниями категорий путей от задания на поезд с номерами категорий путей?
Хочу добавить, что я не считаю свои мысли предпочтительнее и правильнее чьих-то, не пытаюсь ни на кого надавить, веду разговор в мирном и спокойном настроении. Я хочу исчерпать свои догадки в таких вот подробных дискуссиях, хочу убедиться в неправильности каждой, если они таковы.
в предлагаемом мной варианте - пользовательа, ну так бы сразу и сказал. Не, мне делать "перерасшифровку" на "железнодорожные термины" как-то не очень интересно. Но если кто-нибудь захочет это сделать - я против ничего не имею.
Я предлагал рассчитывать маршрут только между двумя светофорами по мере необходимости.я ещё раз повторяю - нельзя найти второй светофор, не попав по 1-2 раза на другие. На сложных станциях на другие светофоры можно вовсе попасть по 4-5 раз (за счёт чего суммарное количество маршрутов бывает до 100), прежде чем найти нужный маршрут от светофора к светофору. А так мы просматриваем готовый список этих маршрутов и у остальной их части проверяем только "конечный светофор", и только для ведущих к нашему светофору проверяем свободность и важность.
чем отличается задание на поезд с навзваниями категорий путей от задания на поезд с номерами категорий путей?
тем, что задание на поезд задаётся без указания категорий путей, ибо в них копается ДСП, а не машинист.
в чём их смысл? Отделить настройки светофоров от свойств пути? Зачем?
Разделение задач. Простота восприятия. Уменьшение шансов на ошибку. Отсутствие каши, когда в настройках светофора мы настраиваем ещё и маршруты, и пути, когда из машиниста мы делаем диспетчера, объясняя назначения путей и какие маршруты зачем собирать. Машинист хранит информацию о поезде и ведёт его, маркеры хранят информацию о путях, светофоры хранят информацию о показаниях и скоростях, о кодировании и положении головок, о розжиге и расстоянии от оси пути. Каждому - свой круг обязанностей.
потому что его дополнительно надо ставить. А светофор на пути будет всегда, если там предусмотрено поездное движение. Зачем лишний объект в центре пути?
А правило не надо дополнительно ставить, лезя в настройки сессии? А если на пути нет поездного светофора или вообще никакого (тракционные пути депо)?
А правило не надо дополнительно ставить, лезя в настройки сессии? А если на пути нет поездного светофора или вообще никакого (тракционные пути депо)?ты уже сам говорил, что "автоматические манёвры невозможны".
---------- Сообщение добавлено в 17:34 ---------- Предыдущее сообщение размещено в 17:32 ----------
когда из машиниста мы делаем диспетчера, объясняя назначения путей и какие маршруты зачем собирать. Машинист хранит информацию о поезде и ведёт его,а диспетчер не хранит информацию о поезде?
В данном случае информация о поезде записывается в "командах машинисту", а машинист и так ведёт поезд (в параллельном потоке - Ботомашинистском или дефолтном), диспетчер параллельно обрабатывает маршруты в зависимости от этих заданий.
я ещё раз повторяю - нельзя найти второй светофор, не попав по 1-2 раза на другие. На сложных станциях на другие светофоры можно вовсе попасть по 4-5 раз (за счёт чего суммарное количество маршрутов бывает до 100), прежде чем найти нужный маршрут от светофора к светофору. А так мы просматриваем готовый список этих маршрутов и у остальной их части проверяем только "конечный светофор", и только для ведущих к нашему светофору проверяем свободность и важность.
Понял. Сколько секунд, интересно, занимает поиск заданного светофора от другого заданного на огромной станции?
поиск заданного светофора от другого заданного на огромной станции?до одной (это около 80-90 маршрутов). Если оказывается больше одной, скрипт вываливается с ошибкой.
Если в списке - около пяти сотых секунды, особенно если сравниваются числа (т.е. приоритеты).
а диспетчер не хранит информацию о поезде?
Нет, только информацию о путях, стрелках и сигналах.
ты уже сам говорил, что "автоматические манёвры невозможны".
Что-то не припомню даже.
В данном случае информация о поезде записывается в "командах машинисту"
Как я понимаю, непосредственно информация о поезде не записывается, т.к. командами задаются детальные действия ДСП для каждой станции?
---------- Сообщение добавлено в 14:42 ---------- Предыдущее сообщение размещено в 14:40 ----------
до одной. Если оказывается больше одной, скрипт вываливается с ошибкой.
Поиск происходит в параллельном потоке и не мешает жизни окружающего мира, или наоборот? Если не мешает и происходит параллельно, то секунда - не критично, в реале маршрут собирается гораздо дольше.
Если не мешает и происходит параллельномешает. Потому что это будет лаг на 1 секунду.
Потоки квазипараллельны, т.е. они исполняются в течении короткого момента времени, а затем уходят в "ожидание" на предопределённый промежуток времени, затем снова срабатывают.
Поиск маршрутов у меня в командах выполняется раз в 5 секунд.
Ладно, я, наверное, на сегодня прекращаю будоражить тему, устал :) Всем спасибо за дискуссию, за ответы на мои вопросы. Нужно, чтобы всё сказанное отлежалось у всех, тогда, возможно, откроется новое понимание ситуации. К тому же очень неудобно общаться на такие сложные темы через форум, буквами. Вот если бы мы все сидели на кухне у Трама, возможно, хватило бы и получаса обсуждения в живую.
Как я понимаю, непосредственно информация о поезде не записывается, т.к. командами задаются детальные действия ДСП для каждой станции?почти да. Только с детализацией до групп путей, определённых приоритетами. Ну и с возможностью задания внешних (глобальных или локальных) условий на действия с помощью переменных.
Sandrilyon
28.09.2013, 17:51
Исходя из текущей полемики, у меня получится сейчас легкий оффтоп. :mocking:
В параллельной ветке про сигналку UZ SHEProm писал, что простым смертным zxPath неподвластна в полной мере... Ну, примерно так он говорил. Вот. Начинаю понемногу понимать, что был прав более, чем об этом могло показаться. Возьмем последнюю мою коллизию с zxPath. Обнаружил, что одна стрелка не освобождается после разборки маршрута, поскольку находится слишком близко к тыльному входному светофору. Ладно, полез в карту, передвинул входные на 50 метров подальше, уменьшил радиус левера на всякий пожарный. И тут пошло, поехало!.. Поломались все "окрестные" входные светофоры и даже те, которые даже не дышат в сторону моей станции. Уже не первый раз - со входными светофорами нельзя шутить! Стоит разок передвинуть - слетают настройки перегонов. Т.е. сама ошибка возникает, когда в свойствах светофора нажимаешь "Собрать перегон" или просто его разворачивать, чтобы проверить целый он или нет. Поломка светофора лечится только удалением его и установкой нового вместе с копированием всего настроенного из старого в новый. Бывает, что забываешь что-то вписать в него: скорости, приоритет, кодирование и т.п. Одна поломка влечет за собою поломку всего перегона, т.е. нужно бежать на другую станцию и проверять каждый входной на предмет поломки перегона.
Я все про то, что для работы с zxPath требуется опыт. Сама по себе маршрутизация не способна излечивать свои же баги и не всегда объясняет, откуда у этих багов растут ноги. Невозможно изначально правильно расставить все леверы, соблюсти все расстояния, не сделать ошибок в названиях трэксайдов и т.п. Это в любом случае требует постоянного тестирования, и в один момент zxPath не заработает как должно... А всем хочется именного этого. И правильно, что хочется! Тут даже никакие туториалы не спасут.
Поломались все "окрестные" входные светофоры и даже те, которые даже не дышат в сторону моей станции.Если ты загружал Fix4 в его предыдущей редакции, так и должно было быть (там я одну строку не на своё место вписал, отвечающую как раз за проверку освобождения стрелки при заезде за входной светофор на перегон). А когда ты загрузил Fix4 вчера, то всё исправилось. Потому что я тоже не все случаи могу сразу протестировать.
Sandrilyon
28.09.2013, 18:02
Да, скачивал почти сразу, как ты их выкладывал.
Стоит разок передвинуть - слетают настройки перегоновв настройках перегонов указаны только входной - сосед и все проходные. Я не понимаю как это могло повлиять на остальные светофоры, в отличие от предыдущего случая :) .
Ant.taranish
28.09.2013, 21:01
простым смертным zxPath неподвластна в полной мере
ерунда, я считаю. Я начал изучать z7-xPath не имея толком представления о реальной сигнализации и маршрутизации, не умея настраивать z7, ничего не понимая в программировании. Ничего, разобрался. Надо ли говорить, что современные версии sU и zxPath намного проще освоить, чем то, что было раньше.
для работы с zxPath требуется опыт
ну да, само собой. А что вы хотите, большой функционал всегда будет требовать освоения. То же самое можно сказать про сам trainz. Тут уж зависит от того, есть желание разбираться или нет.
и в один момент zxPath не заработает как должно...
к сожалению zxPath не изолирована от остальной игры. Большинство проблем по-моему от того , что она зависит от дефолтных аурановских функций, зачастую косячных, с ней могут конфликтовать другие скрипты. Опять же, это trainz.
У меня вот опять в 3.7 маршрут не разобрался, с последней версией junction resetter. Видимо при каких-то условиях патч не помогает. Буду пытаться воспроизвести. Кстати, вопрос: есть ли смысл удалять предыдущую версию скрипта из cache/libraries? А то этот момент вечно у меня вызывает неуверенность в том, что я видел.
Кстати, вопрос: есть ли смысл удалять предыдущую версию скрипта из cache/libraries?нету
---------- Сообщение добавлено в 21:25 ---------- Предыдущее сообщение размещено в 21:23 ----------
Видимо при каких-то условиях патч не помогает.просто пробуй определить, какая стрелка не хочет освобождаться, с помощью дополнительных маршрутов.
Опять хрень
http://savepic.org/4463351m.jpg (http://savepic.org/4463351.htm)
http://savepic.org/4520694m.jpg (http://savepic.org/4520694.htm)
http://savepic.org/4506358m.jpg (http://savepic.org/4506358.htm)
...и почему лок не ушел в портал?
http://savepic.org/4492022m.jpg (http://savepic.org/4492022.htm)
Опять хреньнеправильно настроен портал. Ему нужен поездной светофор обратного направления.
---------- Сообщение добавлено 30.09.2013 в 00:05 ---------- Предыдущее сообщение размещено 29.09.2013 в 15:09 ----------
https://www.youtube.com/watch?v=AEztvOyM0m8
tepaniko
30.09.2013, 20:36
TRam_,прошу прощения, не могу найти твое правило портала, не подскажешь где взять ?
правило не моё, мной оно только доделывалось. http://rusfolder.com/23288105
tepaniko
30.09.2013, 22:07
Благодарю
Вов, привет!
Техническое предложение. Когда ставишь каждый последующий светофор, он "приписывается" к станции, к которой принадлежал последний открытый на редактирование (или редактирован) светофор. С одной стороны это удобно - не надо кликать 100500 раз, когда массово устанавливаешь светофоры. Одному светофору указал, какая станция и дальше она автоматически ставится, пока ты не указал иное. Но если ты добавляешь к уже существующей станции светофор(ы) как правило, маневровые, то по умолчанию берется последняя станция, которую заводил. Вот тогда +100500 раз обкликаешься, настраивая всё заново, после очередной инициализации светофоров, когда обнаружишь эту маневровую падлу. Они же в списке не участвуют...
А вот насчет предложения, я пока набирал предыдущий абзац, уже представил себе негодование сообщества. Но всё же. Предложение - не ставить станцию по умолчанию. И когда пользователь попытается сохранить светофор без станции, выводить ему предупреждение об этом...
Ну и кнопку, по которой бы выводился список светофоров по полю Name без станций, если свойства светофора после установки так и не открывались. Хотя такую ситуацию я себе слабо представляю, разве что спешу куда-то, и сохранил пока что есть, а потом разберусь. Но тогда кнопка необходима просто.
Они же в списке не участвуют...у меня для этого другая идея была - список светофоров каждой станции (в будке). Надо будет его только доработать, чтоб показывал не только список светофоров, но и имена на карте (чтоб можно было искать через "Find" в главном меню).
Можно также сделать чтобы по умолчанию выбиралась станция того светофора, свойства которого просматривались последним.
---------- Сообщение добавлено в 22:22 ---------- Предыдущее сообщение размещено в 21:42 ----------
... что и было сделано. Fix4 был перевыложен 3ий раз по той же ссылке, http://yadi.sk/d/dBftfwp79xFbT
Sandrilyon
01.10.2013, 22:30
Я уже боюсь твои фиксы качать. :mocking:
Ничего не поломается?
Нет. Потому что и первое, и второе - интерфейс, на работу уже настроенного уже не влияет.
---------- Сообщение добавлено в 22:34 ---------- Предыдущее сообщение размещено в 22:32 ----------
Я уже боюсь твои фиксы качать.а ты помнишь времена z7-xPath, когда их было штук 50, версий :blum1: ?
Можно также сделать чтобы по умолчанию выбиралась станция того светофора, свойства которого просматривались последним.
Вообще-то и до 3-й редакции fix4 так оно и было. Я последним смотрел свойства светофора на ст. Лесной Городок, а потом начал дополнять маневровыми Солнечною. Те же яйца, только в профиль. Я предлагал вообще убрать там станцию по умолчанию.
но и имена на карте (чтоб можно было искать через "Find" в главном меню).
Логично. Но для меня, например, это не актуально. И я бы призывал всех серьезно юзающих эту систему приучаться к такой "кодировке": Solnechnaya N2 - Н2. И когда вам нужно перейти по Find Object, вам не нужно смотреть список - какой же там у вас Trigger хххххх соответствует светофору Н2 по ст. Солнечная.
Предвижу: "Йех, каждый светофор набирать ещё и имя?" А буфер обмена Windows для чего?
Я предлагал вообще убрать там станцию по умолчанию.ну вот убирать нельзя. И потом, никакой разницы в том, ставишь ли ты каждый раз настройку станции вначале, или потом, когда убедишься, что не той станцией их построил - не вижу.
Я ещё раз говорю - вот так (кнопка "список светофоров") искать неправильные светофоры в разы проще, чем раньше:
http://i.piccy.info/i8/2ff7dda0b918d9ce0ca90e1cdcfeafed/1380659684/29976/615605/TRam_20131001_0001_500.jpg (http://i.piccy.info/i8/aae9f54d34a923028cf59495cdfa23c1/1380659684/458693/615605/TRam_20131001_0001.jpg)http://i.piccy.info/a3/2013-10-01-20-34/i8-5218379/500x281-r/i.gif (http://i.piccy.info/a3c/2013-10-01-20-34/i8-5218379/500x281-r)
(первая попавшаяся станция и уже неправильный светофор :) )
Serega_82
02.10.2013, 09:01
TRam_, вопрос, почему у тебя в списке светофоры идут с новой строчки, у меня-подряд?
И ещё. Упустил момент. Теперь можно делать пути с односторонним движением, с одной стороны поездной светофор, с др. - маневровый?
Теперь можно делать пути с односторонним движением, с одной стороны поездной светофор, с др. - маневровый?
Это даже в z7 можно было делать.
вопрос, почему у тебя в списке светофоры идут с новой строчки, у меня-подряд?скачай ещё раз Fix4.
Теперь можно делать пути с односторонним движением, с одной стороны поездной светофор, с др. - маневровый?можно. Только в будке удаляй маршрут, который в обратном направлении.
---------- Сообщение добавлено в 10:06 ---------- Предыдущее сообщение размещено в 10:05 ----------
Это даже в z7 можно было делать.zxPath предыдущей версии не разбирала маршрут до прохода поезда по такому пути
И потом, никакой разницы в том, ставишь ли ты каждый раз настройку станции вначале, или потом, когда убедишься, что не той станцией их построил - не вижу.
Совсем нет никакой разницы, с самого начала получить предупреждение, что что-то не так сделал, или после настройки 42-х станций, потом обнаружить "чужой" светофор и вновь после правки инициализировать светофоры и заново настраивать 42-е станции.
Ну ладно, нет, так нет. Буду просто внимательнее. А список существенной помощи не окажет. Разве что как мертвому припарка.
можно. Только в будке удаляй маршрут, который в обратном направлении.
Вот в таких случаях маркеры бы помогли. Указал в маркере направление приёма поездов и всё. Также можно указывать пути с безостановочным пропуском и ходовые пути. Это проще, нагляднее и понятнее, чем искать в списке маршрутов такие.
CFM, если б там стоял маневровый с красным, а не синим, то в нём можно было бы прописать "-1" приоритет и никто на этот путь с неправильного направления не попал бы. Но в данном случае речь о маневровом с синей линзой, а такой не может быть "выходным".
Хотя опять же, я не до конца понял, почему там именно синий (т.к. если есть возможность попадания на главный путь, на маневровых ставят красный).
Sandrilyon
02.10.2013, 15:55
Хотя опять же, я не до конца понял, почему там именно синий (т.к. если есть возможность попадания на главный путь, на маневровых ставят красный).
У нас на станции (в РБ) также стоят в обеих горловинах синие маневровые. За ними нет ответвлений, а сразу перегон по неправильному. И через этот путь поезда не уходят на перегон, поскольку парки отправления с другой стороны. К тому же, я думаю, что на малых станциях, состоящих из одного блока, т.е. только входной и выходной, такого не делают. А вот при разделении парков через маршрутные светофоры - это да, но отправлять на перегон состав из парка по маршрутному, но через условно неправильный путь, никто не будет, и такую вероятность решили не учитывать.
Ant.taranish
03.10.2013, 23:24
Пришел сегодня к такому выводу: если перед сбором маршрута правилом AddAnyPath нужно проверить какое-то условие кроме наезда на триггер, привязка к триггеру превращается в большое неудобство - в лучшем случае нужно городить лишний огород, в худшем - применение невозможно, нужно использовать AddPath, проверяя все возможные пути, где может оказаться поезд. Я бы предложил вернуться от частного к общему - правило AddAnyPath должно собирать маршрут по срабатыванию родительского правила (как в z7-xPath), нынешнее правило можно переименовать, например "AddAnyPath on Trigger".
Пример ситуации когда проверка триггера ни в какие ворота: нужно собрать маршрут на выход поезду игрока (т.е. командами нельзя). Путь, на который прибудет поезд, а значит и маршрут, заранее неизвестны. Перед сборкой маршрута нужно получить "согласие" следующей станции на прием поезда (проверить переменную). Согласие может быть получено после того, как поезд прибыл и уже наехал на все возможные триггеры.
Согласие может быть получено после того, как поезд прибыл и уже наехал на все возможные триггеры.В теории это было бы так...
Правило сбора маршрута на вход "запускает включение слежения" у подчинённого (но не непосредственно ему, а более низкого уровня) правило сбора маршрута на выход (триггер которого стоит почти сразу за триггером основного правила, перед входным). Затем идёт лесенка ожидания остановки (проезда?) поезда на одном из триггеров станции, затем - получения согласия (проверки переменной), и затем - подчинённые правила на сбор (или не сбор, а ожидание переменной) маршрута на выход.
По крайней мере идея была такая. Сработает она или нет - не совсем понимаю, т.к. не смотрел алгоритмы "ожидания переменной" и не совсем понял, действительно ли требование следить за поездами дойдёт до самого низа лестницы правил. Но попробовать можно.
Имеется в виду, что подчинённое правило запомнит поезд игрока намного раньше, чем оно будет выполняться, ещё тогда, когда поезд не доехал до входного.
Ограничение - невозможность по такой схеме последовательно обрабатывать несколько поездов (AddAnyPath запоминает всего один, и сбрасывается при повторном срабатывании родительского правила AddAnyPath, только AddAnyPath). Да и многократность срабатывания (особенно с учётом дефолтных алгоритмов правила ожидания переменной) под вопросом.
Ant.taranish
04.10.2013, 14:03
TRam_, обязательно попробую
---------- Сообщение добавлено в 15:03 ---------- Предыдущее сообщение размещено в 01:41 ----------
Итак, смоделировал и погонял предложенную конструкцию
AddAnyPath (на вход)
-- Variable check rev.1 (каждые 5 секунд)
---- AddAnyPath (на выход)
Правило variable check активируется после съезда поезда с триггера, по которому собирается маршрут на выход
Выводы:
1. AddAnyPath действительно запоминает наехавший на триггер поезд до того, как оно активируется родительским правилом Variable check.
2. Память у него короткая. Если поезд остановится до того, как AddAnyPath будет активировано, маршрут на выход не соберется.
Поскольку остановку поезда перед выходным нельзя исключить, конструкция не рабочая, хотя сама реализация интересная.
Но даже если бы она работала, я все равно не вижу никакого преимущества в объединении AddAny path с проверкой триггера. Триггер нужен ровно один раз, чтобы определить, что поезд подходит к станции (и лучше это определить отдельным правилом). Все маршруты по станции должны собираться сразу или после выполнения каких-то других условий. Не нужно больше никаких триггеров - я уже знаю, где поезд.
tepaniko
04.10.2013, 17:31
Блин, все равно с переменнымы не могу понять!
Переменная это обьект какой или просто название в таблице переменных? Как задать чтобы определенная переменная сработала или проверялась чтоли?
Триггер нужен ровно один раз, чтобы определить, что поезд подходит к станции AddAnyPath переделывалась специально для того, чтобы срабатывать на множество поездов, а не только один. Триггер нужен, чтобы получать ссылку на поезд, удовлетворяющий требованиям (т.е. с нужными вагонами или машинистами, в нужном месте карты), а не только один-единственный, определённый единицей ПС, изначально имеющейся на карте.
В общем подумаю, возможно сделаю разделение как ты предложил. Влияние остановок тоже проверю - я не помню, чтоб скрипт где-то проверял остановки поезда.
Переменная это обьект какой или просто название в таблице переменных?объект с названием, целочисленным значением, и максимумом/минимумом. Наиболее важно его значение, которое можно изменять (прибавлять или отнимать целые числа), сравнивать (с числами) или ожидать (пока значение не окажется больше или меньше того, что нам надо)
---------- Сообщение добавлено в 18:48 ---------- Предыдущее сообщение размещено в 17:59 ----------
Прекращение работы при остановке поезда над триггером убрал. http://yadi.sk/d/e3Y_ygQGAPa8G
Ant.taranish
04.10.2013, 20:00
при остановке поезда над триггером
а если не над триггером? У меня триггер стоит перед входным светофором, поезд наезжает на него, съезжает, прибывает на один из путей, останавливается, после этого выполняется variable check, но маршрут не собирается (только что попробовал исправление)
Но даже если бы она работала, я все равно не вижу никакого преимущества в объединении AddAny path с проверкой триггера.
но есть множество типовых задач и правило в этом помогает
Все маршруты по станции должны собираться сразу или после выполнения каких-то других условий. Не нужно больше никаких триггеров - я уже знаю, где поезд.
просто +1 :)
Прекращение работы при остановке поезда над триггером убрал
Каким макаром? То есть, поезд наехал на триггер, выходной маршрут собрался, поезд остановился. И что? Маршрут разбирается?:negative:
(только что попробовал исправление)Настроил тестовую карту, проверил - таки да, не собирается.
Посмотрел правило внимательнее - оказалось, там направление поиска светофора определяется скоростью движения поезда, а не направлением поезда (а при нулевой скорости поиск всегда шёл "назад" :negative: ).
И что? Маршрут разбирается?то что я в предыдущий раз пытался поправить - просто блокировка запуска завершённого правила (которая ни на что, как оказалось, не влияет).
Также в правиле поправил "забывание" того поезда, который успешно собрал себе маршрут (а то правило срабатывало на уже проехавший поезд :) ).
http://yadi.sk/d/e3Y_ygQGAPa8G
---------- Сообщение добавлено в 14:47 ---------- Предыдущее сообщение размещено в 14:43 ----------
Не нужно больше никаких триггеров - я уже знаю, где поезд.но правило-то не знает, о каком поезде идёт речь (для поисков светофора от него). Если бы в дефолте была возможность передачи "обрабатываемого поезда" от вышестоящего правила к нижестоящему - я б этим воспользовался. Но пока такого нет.
Вов, ты меня уже совсем запутал.
Также в правиле поправил "забывание" того поезда, который успешно собрал себе маршрут
А разве правило не тот поезд помнило, который проехал триггер? При чем здесь успешно собранный маршрут?
А разве правило не тот поезд помнило, который проехал триггер?помнило то да, но если повторно активировать это правило для другого поезда, оно срабатывало на тот же поезд, которому оно уже собрало маршрут.
Ant.taranish
05.10.2013, 19:35
но правило-то не знает, о каком поезде идёт речь
Вова, ты пересмотрел AddAnyPath и возможные конструкции с ним в пользу автоматического движения ботов, но при этом урезал возможности для поезда, которым управляет игрок. Этот поезд один и известен с самого начала (не обязательно, но почти всегда), значит можно указать его в правиле, как раньше и было.
AddAnyPathOnTrigger конечно же имеет право на существование, но фокус в том, что движение ботов можно организовать и без него, одними командами. А поезду игрока собрать вариантный маршрут во время движения можно только правилом AddAnyPath, и проверка триггера в этом случае мешает.
Кстати, я вот что подумал: можно ли скриптом получить поезд, в котором находится игрок? Тогда можно было бы подумать над командой, собирающей вариантный маршрут поезду игрока, при том что выполнять ее будет какой-нибудь другой поезд. Я бы тогда вообще все маршруты собирал командами - и для ботов и для людей, и не ломал бы голову с этими "лестницами":)
А поезду игрока собрать вариантный маршрут во время движения можно только правилом AddAnyPath, и проверка триггера в этом случае мешает.поясни, почему нельзя.
Там специально для этого, в правиле AddAnyPathOnTrigger, есть фильтр, который позволяет срабатывать
а) на поезда, в составе которых есть заранее определённые вагоны (полный аналог старого AddAnyPath)
б) на поезда, у которых определённые типы вагонов
в) на поезда, в которых сидит определённый машинист
Также можно задать сразу несколько из этих критериев. И достаточно, чтоб поезд игрока последовательно проехал по триггерам этих правил, а все остальные поезда не удовлетворяли фильтру.
но фокус в том, что движение ботов можно организовать и без него, одними командамиа у меня идея такая - что с помощью "лестниц"сделать аналогию последовательно выполняющихся команд
Кстати, я вот что подумал: можно ли скриптом получить поезд, в котором находится игрок?игрок, решивший полазить по соседним составам во время стояния на красный, "вдруг" соберёт маневровому маршрут на отправление. Это хорошо? Нет.
Ant.taranish
05.10.2013, 20:36
поясни, почему нельзя.
я нигде не говорил, что нельзя заставить его реагировать только на поезд игрока, проблема не в этом. Критическую уязвимость ты убрал, остались только лишние заморочки: по-прежнему нужно ставить столько триггеров, сколько маршрутов по станции, неизвестно как близко их можно ставить друг к другу, чтобы всё работало четко, в любом случае возникает задержка между сбором маршрутов.
игрок, решивший полазить по соседним составам во время стояния на красный, "вдруг" соберёт маневровому маршрут на отправление.
Да, согласен. А что если в редакторе выбирать из списка машиниста, который будет в поезде игрока? Я давно думал о такой команде, но мне как-то казалось это бредовым, а щас думаю - совсем наоборот, и реализовать вроде бы несложно. Концепция "всё делать командами" очень переспективна, по-моему, во всяком случае для сессий, моделирующих случайно развивающуюся поездную ситуацию, а не организацию движения на всем маршруте.
но если повторно активировать это правило для другого поезда, оно срабатывало на тот же поезд, которому оно уже собрало маршрут.
Бррр, Вов, что-то я тебя совсем не понимайль...
Что значит "повторно"? То ли что-то не уехало, то ли что-то уже уехало. Если уехало, то за что именно? Разъясни уж, в конце-то концов.
Насколько я понимаю как это происходит...
Правило (AddAnyPath), узнав, что по нему проехался поезд, говорит такому же подчиненному правилу: "Ой, доця, тут по мне проехался какой-то мэн, я ему, конечно, маршрут-то собрала, но ты будь внимательна, он к тебе направляется".
Доця ждет-ожидает. И почти вот-вот. Как вдруг...
"Доця, забудь про этого мэна, тут на меня уже другой наехал."
Доця в растерянности, мама в ахуе (ну нифига себе такой подарок жизни: аж два раза сразу!). А в результате поездной коллапс.:mocking:
Между прочим, Вов, посмотри на вот это:
http://savepic.su/3442573m.jpg (http://savepic.su/3442573.htm)
Маневровый, тот, что ближе на скрине пытается выехать из тупика. Но у него команда "маневрировать под состав" (на с ....
Всё, я понял в чем ошибка.... Позже сформулирую.
А что если в редакторе выбирать из списка машиниста, который будет в поезде игрока?второй машинист, сидящий в поезде, команд не выполняет.
Если же ты о собственно машинисте игрока, то у игрока большинство команд будут забирать управление (кроме переделанных под эту функцию), в том числе команды ожидания и управления переменными..
---------- Сообщение добавлено в 20:51 ---------- Предыдущее сообщение размещено в 20:48 ----------
Доця в растерянности, мама в ахуе (ну нифига себе такой подарок жизни: аж два раза сразу!). А в результате поездной коллапс.вот поэтому я и говорил, что 1 лестница соответствует одному набору команд. Если нужно много сразу, то что машинистов с командами, что лестниц с правилами нужно много. Иначе многозадачности не будет, что ты собственно и пояснил.
:ps: касательно AddAnyPathOnTrigger - оно сработает с последним наехавшим поездом.
Ant.taranish
05.10.2013, 20:51
TRam_, нет, это я знаю, я имею в виду, что команда будет определять поезд игрока по машинисту, который в нем находится, и собирать этому поезду маршрут.
что команда будет определять поезд игрока по машинисту, который в нем находитсяопределять по имени? Функция получения списка машинистов карты конечно есть, но его особо в меню не засунешь - если поездов много, машинистов столько же. Число пунктов меню умножается на это число, а значит и время построения этого меню увеличивается во столько же раз.
---------- Сообщение добавлено в 21:05 ---------- Предыдущее сообщение размещено в 20:57 ----------
Всё, я понял в чем ошибка.... Позже сформулирую.команда Эрендира не нашла перед носом другой поезд и построила маршрут. Я так понял.
Powered by vBulletin™ Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot