Просмотр полной версии : Автоматический поездной диспетчер - предложения и идеи
Здесь собираем предложения или решения по поводу систем автоматического управления движением поездов на участке.
А так же то, каком виде их потом реализовывать (команды, правила, или ещё как).
Начну со своей собственной идеи автоматического движения по однопутному участку.
Как известно, в случае однопутки наибольшей проблемой является случай, когда на станцию с обоих сторон прибывает больше поездов, чем на ней есть свободных путей. Раньше (фактически до появления автоблокировки) "диспетчеры" пользовались простым правилом - "после прибытия поезда с перегона нужно изменить направление перегона и отправить на него поезд, если он есть". В то же время из-за того, что на перегонах всего по 1 поезду, пропускная способность была низкой. В дальнейшем, с развитием автоматики и установкой проходных на перегонах, более эффективной стала схема "пакетов", т.е. несколько поездов отправляются один за другим и так следуют по участку (хотя впервые в отечественной практике это было создано в Великую Отечественную, а "проходными светофорами" работали сигналистки).
Основная идея заключается в том, что на всём участке выбеляется "приоритетное направление". И в этом направлении движутся пакеты поездов, навстречу им - одиночные поезда или пакеты, состоящие из меньшего числа поездов. Вопросы в этом случае возникают следующие:
1) как рассчитать количество поездов, которые могут отправится против приоритетного направления.
2) как изменять "приоритетное направление", чтобы не произошёл вышеупомянутый коллапс на участке.
Частичное решение первого вопроса - "со станции нельзя отправлять поезд против приоритетного направления пакетов, если на станции, где предполагается обгон пакетом поездов, заняты, или будут заняты все боковые пути ".
Частичное решение второго вопроса - "пакет поездов должен прибыть на станцию назначения, либо должен быть расставлен на боковые пути станций".
Первое можно математически показать примерно так: " поезд против приоритетного направления может быть отправлен, если число свободных боковых путей на следующих станциях участка, которые пакет поездов ещё не прошёл, меньше числа поездов на перегонах между ними".
Второе - примерно так: "приоритетное направление поездов отменяется, поезда обоих направлений должны пользоваться правилом для "неприоритетных поездов" до тех пор, пока их суммарное число на перегонах участка не будет рано 0". После этого приоритетное направление участка изменяется.
Ну тут самый верный способ - составление графика. Для этого нужно разработать план местной грузовой работы (подача и уборка на промежуточных станциях порожних и гружёных вагонов), узнать перегонные времена хода, станционные интервалы, весовые нормы и нормы длины. Это основа. Пассажирское движение проще - просто составляем график с помощью служебного расписания (ничего рассчитывать не нужно). Добавить не местные вагонопотоки (поезда, сформированные за пределами карты, в порталах).
Быстрый и простой способ без графика, но в итоге мало к чему приводящий - на каждой станции общее количество путей разделить на две части (отдельно для пассажирского и грузового движения) в процентном соотношении, равном соотношению чётного/нечётного трафика, что предотвратит забивание станции поездами одного направления. Затем нужно научить станции передавать своим соседям данные о свободности путей, об отправленных и принятых поездах. Во избежание каши нужна последовательная цепочка передачи данных от одной участковой станции через ряд промежуточных к другой.
B.U.G.O.R.
14.09.2013, 20:59
Мой вариант решения проблемы по однопутке. Начнем с простого определния — пассажирские должны следовать графику, грузовые должны вклиниваться. Я давно думал о том, чтобы сделать что-то вроде автографика в ТРСе, его суть такова:
Какое-то определенное правило, в которое заносится последовательность станций, указывается действие по станции (следовать ходом, техническая графиковая остановка, остановка по графику с посадкой) и время. Ест-но тоже, если проход, значит только время прохода, если стоянка, то прибытие и время отправления. А станции можно брать из сигналки, чтобы не городить еще кучу лишнего, как раз автоопределение границ станции, номеров путей и прочего в соответствии со светофорами. Из этого правило будут тянуть информацию сразу несколько "потребителей". Во-первых, можно брать рандомный локомотив из депо, как это делается уже, и задавать ему график из поезда. ЧЕм оно должно принципиально отличаться от БОКа — тем, что должно просчитать расстояние между станциями и, в соответствии с разностью времени, определить скорость движения. Само, потому что сейчас я это делаю вручную. Плюс, опять же, можно сделать еще одну хорошую вещь, чтобы команды локомотиву вписывались согласно ближайшей станции. Тогда мы можем в любой момент отнять у локомотива управление, а потом его же вернуть, не выбирая, где же там оно едет, оно сам определило ближайшую станцию и вклинилось в график. Но это немного не из той серии. Это отдельная тема, а по этому сабжу следующее:
Некий ДСП или ДНЦ, не важно, так же берет этот же график, определяет все скорости, время прохода и прочее. Расстояние между станциями он должен знать, это очевидно, это по-моему, уже есть. Теперь, чтобы не писать кучу бреда, рассмотрим пример. Скажем, есть три станции А, Б и В. Ест-но, везде однопутка. На станции В стоит четный грузовой, его надо отправить до станции А. (Опять же можно придумать некую команду грузовику, чтобы она его вела только до конечной станции, а весь порход ему делали эти диспетчера, так будет много проще). Тогда, ДНЦ станции В "берет" график станции Б и смотрит все время прохода поездов. А там, скажем, в 10:10 должен прибыть пасс, который стоит 5 минут. В данный момент он едет, скажем по станции А. Тогда ДСП станции В рассчитал время движения грузовика до станции Б +2 минуты на заход набок, и понял, что грузовой будет там в 10:08. Тогда переменная=тру, собираем набок. Уехал грузовик набок, пропустил пасс, теперь уже ДСП станции Б смотрит график станции А, там, скажем есть пасс, который должен пройти в 10:23, считает время движения грузовика, не успевает, тогда переменная=фалс, все стоим. Только пасс прошел по станции Б, ДСП снова запрашивает и так далее. Таким образом можно решить сразу много проблем, с командами машнистам и маршрутам.
В-общем, мне кажется, что без графика не обойтись. Мне, как ТРам меня назвал "пассажирщику", график реально важен и пассы для меня приоритетнее, но такой вариант будет приемлим и для "грузовиков" и для "пассажирщиков". Если идея понравится, то я могу расписать алгоритм подробно, может, даже, блок-схему нарисую.
Володя, ты лучше сделай как-нибудь ,чтоб маневровые не закрывались, а то мне на горке неудобно до сих пор.
так же берет этот же график, определяет все скорости, время прохода и прочеекак раз в определении времени прохода большие сложности. Система управления (и автомашиниста, и ботомашиниста) слишком сложна, чтобы точно рассчитать время проследования перегона. Не говоря уже об обратной задаче (прийти вовремя, не зная какие ограничения скорости будут на участке и не зная с каким ускорением замедляется/тормозится состав).
Уехал грузовик набок, пропустил пасс, теперь уже ДСП станции Б смотрит график станции А, там, скажем есть пасс, который должен пройти в 10:23, считает время движения грузовика, не успеваета если грузовых на перегоне два, за пассажирским ещё грузовой, а боковой путь всего один?
ЧЕм оно должно принципиально отличаться от БОКаБотомашиниста или чего? БОК всего лишь рандомный распределитель команд машинистам, которые "освободились от предыдущего этапа действий". При этом сами действия надо в любом случае задавать вручную. Потому только ты можешь указать, где у тебя находится парк отстоя поездов, какие машинисты сидят на маневровых и должны его вытягивать, а какие на поездных и должны его везти.
А то утрированно получается так: машинист ЧС4т отправился вытягивать свой поезд из пассажирского парка отстоя, который неэлектрифицированный.
Или так: машинист проходящего поезда прибыл на тупиковый путь и не может ехать дальше.
Не говоря уже о приколах на узлах, типа "поезд сообщением Львов-Запорожье свернул не туда, и вместо Запорожья прибывает в Днепропетровск".
P.S. в твоей идее ещё нету переключения перегона, выделения путей, где должны останавливаться грузовые, а где пассажирские, а также наборов команд "как правильно ехать в депо", "как правильно проследовать развязку узла", "каким локомотивам можно под этот поезд, каким нельзя" и т.п.
---------- Сообщение добавлено в 21:35 ---------- Предыдущее сообщение размещено в 21:35 ----------
Володя, ты лучше сделай как-нибудь ,чтоб маневровые не закрывались, а то мне на горке неудобно до сих пор.имеешь в виду во время расцепления?
B.U.G.O.R.
14.09.2013, 22:18
как раз в определении времени прохода большие сложности.
Грубо говоря:
t(2)-t(1)=dt 'Время прохода второй станции минус время прохода первой станции равно разница времени
v=s/dt' Скорость = расстоние делить на время.
Далее определяем ближайшую скорость из команд Эрендира и суем ее в список команд, не знаю, как это записать в скрипте. Потом даем "двигаться к" след. станции. И так далее, до упора.
Не получится?
Ботомашиниста или чего? БОК всего лишь рандомный распределитель команд машинистам, которые "освободились от предыдущего этапа действий". При этом сами действия надо в любом случае задавать вручную. Потому только ты можешь указать, где у тебя находится парк отстоя поездов, какие машинисты сидят на маневровых и должны его вытягивать, а какие на поездных и должны его везти.
Понятное дело, речь и идет о том, что локомотив вышел из депо, встал в тупик под состав, далее маневровый (который может работать базовыми командами) вытянул состав, локомотив прицепился, а дальше какая-нибудь команда, которая ловит команды из этого графика.
А то утрированно получается так: машинист ЧС4т отправился вытягивать свой поезд из пассажирского парка отстоя, который неэлектрифицированный.
Или так: машинист проходящего поезда прибыл на тупиковый путь и не может ехать дальше.
Ваще не понял, как это может произойти? Зачем локомотиву задавать все работы с составами? Он делает свою работу, везет состав.
Не говоря уже о приколах на узлах, типа "поезд сообщением Львов-Запорожье свернул не туда, и вместо Запорожья прибывает в Днепропетровск".
А это уже берется из того же графика. Скажем, если после Отрожки идет Придача, то маршрут по Отрожке собирается по Ростовскому парку, если Сомово, то маршрут собирается по Мичуринскому парку. Это надо отдельно вписывать в маршрутизации.
P.S. в твоей идее ещё нету переключения перегона, выделения путей, где должны останавливаться грузовые, а где пассажирские, а также наборов команд "как правильно ехать в депо", "как правильно проследовать развязку узла", "каким локомотивам можно под этот поезд, каким нельзя" и т.п.
Тю, ну так это же очевидно. правильно ехать в депо берется совсем не отсюда, это берется из вашей же обычной маршрутизации, никакого отношения к графику оно не имеет. Проследование развязки отдельная песня. Тут надо отдельно выписывать маршруты (соберутся они автоматом маршрутизацией, или же впишутся вручную, как у меня — дело ваше), а дальше в зависимости от движения поезда собирается тот или иной маршрут. Выбор локомотива должен быть продиктован, грубо говоря командой, когда локомотиву, собственно, пора тянуть график. Когда он выполнил все свои необходимые маневры, и вот стоит с составом.. тут даже лучше было бы не так, было бы порсто идеально, если бы составу можно было бы приписывать номер прямо с свойствах вагонов. Тогда график ставится тот, который должен быть, собственно под номером. А локомотивы тупо не должны подъезжать под номера, которые им не положены.
как раз в определении времени прохода большие сложности. Система управления (и автомашиниста, и ботомашиниста) слишком сложна, чтобы точно рассчитать время проследования перегона. Не говоря уже об обратной задаче (прийти вовремя, не зная какие ограничения скорости будут на участке и не зная с каким ускорением замедляется/тормозится состав).
Для этого нужно знать перегонные времена хода для каждой категории поездов. Для пассов вычисляется по служебке, для остальных - тестом.
Далее определяем ближайшую скорость из команд Эрендиране, ограничение то можно вбить. Но тут ты не учитываешь "время разгона и торможения", которые у разных поездов довольно сильно отличаются. Команды добавлять с помощью внешнего скрипта можно.
Для этого нужно знать перегонные времена хода для каждой категории поездов.на каждом из перегонов карты. Просто они ещё зависят от веса поезда (о грузовых).
Начнем с простого определния — пассажирские должны следовать графику, грузовые должны вклиниваться.
Грузовые тоже следуют по графику, кстати.
для остальных - тестом.как сейчас представлю - запускается специальная сессия, в ней автоматически генеирируются грузовые поезда, запускаются от одной станции до другой и их времена складируются в отчёт, в jetlog.txt .
Потом надо долго и нудно сидть в редакторе и заполнять таблицу времён хода :) . А всё потому что в редакторе поезда не ездят.
---------- Сообщение добавлено в 00:56 ---------- Предыдущее сообщение размещено в 00:54 ----------
Грузовые тоже следуют по графику, кстати.не всегда. Но если есть свободная или выделенная нитка - естественно её диспетчер использует.
как сейчас представлю - запускается специальная сессия, в ней автоматически генеирируются грузовые поезда, запускаются от одной станции до другой и их времена складируются в отчёт, в jetlog.txt .
Но ведь ботом не измеришь правильно, его же скорость не зависит от веса, профиля.
Кстати, вот книга (http://edu.dvgups.ru/METDOC/GDTRAN/YAT/UER/UER_KACH/METOD/TEH_EKSP_RAB/Shir_1.htm), где построение графика расписано от и до, со схемами, таблицами и примерами. Предлагаю почитать и решить, какие операции нужно сохранить, какие упразднить для ТРС.
Предлагаю все сложные вычисления для графика вынести в отдельную прогу, чтобы ТРС не загибался и не глючил.
B.U.G.O.R.
15.09.2013, 01:40
"время разгона и торможения"
Условно оно берется равным двум минутам. Так считаются реальные поезда, тут я думаю, можно сделать так же.
Для пассов вычисляется по служебке, для остальных - тестом.
Не спеши. Лучше, чтобы пассы ходили не по ПВХ, а по своим скоростям. Дело в том, что далеко не везде время по графику добавляется из ПВХ. Как правило, оно очень сильно занижено. Чтобы было время нагнать. Я, почему и говорю, что надо делать примерно так, как я описал. Тогда он сам подстраиваться будет, чтобы проследовать или прибыть на станцию четко по графику.
А по поводу грузовых, можно условно взять 80 км/ч и все.
его же скорость не зависит от веса, профиля.от профиля может и не зависит, а от веса Эрендир зависимость сделал.
имеешь в виду во время расцепления?
Именно так. Когда состав распускают, там все светофоры лунным светом горят, а у меня после отцепления вагона первый горочный сразу красным загорает.
Oleg13, наверное это потому, что в su нет никаких горочных светофоров.
так график движения можно и ручками нарисовать один раз после создания/скачивания карты. Думаю это не сложно (кстати в какой программе легче это сделать? кроме пейнта =))
а открытие маршрутов по ситуации по триггерам. Правило только надо хорошее для этого. Можно допились addpath. Добавив туда триггеры, задержку по времени, тип машиниста/имя поезда/тип поезда. И так несколько строк. Писал уже тут (https://forum.trainzup.net/showthread.php?t=2115&p=267445&viewfull=1#post267445). Это нереально?
от профиля может и не зависит, а от веса Эрендир зависимость сделал.
Бот поедет с максимально допустимой скоростью? Но перегонные времена так не рассчитываются - должен оставаться запас на нагон. Думается, лучше всего своими руками провести поезд по карте и засечь ПВХ.
Не спеши. Лучше, чтобы пассы ходили не по ПВХ, а по своим скоростям.
Так это я и имел в виду. Служебка - служебное расписание пассов.
Можно допились addpath.Можно взять AddAnyPath и наделать его для всех поездов (там можно указать любой тип вагонов поезда, на который это правило сработает).
тип машиниста/имя поезда не подходит, так как машинист и его лок выбирается в депо случайно.
---------- Сообщение добавлено в 17:21 ---------- Предыдущее сообщение размещено в 17:18 ----------
Бот поедет с максимально допустимой скоростью?есть же команда установки ограничения скорости. Её можно добавлять перед каждым перегоном. Но я имею в виду, что рассчитать уставку этого ограничения очень сложно, зная только расстояние и не зная какой поезд мы ведём и какие ограничения на участке.
Можно взять AddAnyPath
так оно открывает маршрут впереди поезда. А если ещё следующий? Чтоб проехать станцию. На станциях триггеры ставить не вариант
На станциях триггеры ставить не вариантпочему же? Пока что передавать инфу о поезде от одного правила другому не очень понятно как, потому привязаться к триггерам на боковых путях, и переменным "разрешения освобождать боковые" вполне можно. Сейчас проапгрейдил Variable Check Rev.1 для этого (чтоб каждые 5 секунд проверяло переменную пока условие не выполнится).
Единственное что - правил получится много.
---------- Сообщение добавлено в 17:51 ---------- Предыдущее сообщение размещено в 17:33 ----------
Либо же, добавлять машинисту команды, чтоб он дождался переменных самостоятельно.
---------- Сообщение добавлено в 18:00 ---------- Предыдущее сообщение размещено в 17:51 ----------
А ещё можн использовать команду If Else. В этом случае машинист доедет куда надо, дождётся переменной, соберёт маршрут и отправится (либо сразу соберёт маршрут на проход и проследует станцию, в зависимости от переменной).
Переменные можно менять как по времени (правило Time Check) так и по событиям (а время будет влиять только на скорость движения и стоянки графиковых поездов, а "влияние" на дежурных соседних станций можно описать как раз переменными).
B.U.G.O.R.
15.09.2013, 20:03
(кстати в какой программе легче это сделать? кроме пейнта
Лист и карандаш.
Так это я и имел в виду. Служебка - служебное расписание пассов.
ПВХ и служебка — разные вещи.
не зная какой поезд мы ведём и какие ограничения на участке.
А зачем это для скорости? Расстояние поделил на время и все, не надо считать больше ничего. Если надо ехать 60 км/ч, чтобы приехать от станции А к станции Б, то независимо от типа поезда, надо ехать 60 км/ч.
Если надо ехать 60 км/ч, чтобы приехать от станции А к станции Б, то независимо от типа поезда, надо ехать 60 км/ч.если перегон пять километров, и из них 2 километра будет разгоняться со средней скоростью 30 км/ч, то ограничение 60 км/ч приведёт к тому, что порезд однозначно опоздает.
Эрендир, я z7 пользуюсь, там тоже нету, но есть маневровые, их как горочные и использую. Поэтому и просьба к Владимиру, какой-нибудь скрипт прописать или что-нибудь, чтоб все горочные горели белым, пока роспуск идет.
Oleg13, поторбуй вести поезд "задом" во время роспуска. Проблема заключается в том, что при расцепке у отцепленная часть становится новым поездом, старый поезд (которым становится отцепленная головная часть) покидает светофор, и соотвественно он закрывается.
Только что проверил - вроде действует.
ПВХ и служебка — разные вещи.
Так я и не путал их. Имел в виду именно служебку.
А зачем это для скорости? Расстояние поделил на время и все, не надо считать больше ничего. Если надо ехать 60 км/ч, чтобы приехать от станции А к станции Б, то независимо от типа поезда, надо ехать 60 км/ч.
А если предупреждения?
---------- Сообщение добавлено в 21:31 ---------- Предыдущее сообщение размещено в 21:25 ----------
Вот логическая схема, по которой строят реальные графики http://i065.radikal.ru/1309/47/233f576e1e89t.jpg (http://i065.radikal.ru/1309/47/233f576e1e89.gif)
Предлагаю так же строить графики в ТРС, отбросив ненужные экономические и статистические пункты.
B.U.G.O.R.
16.09.2013, 19:32
А если предупреждения?
Очень смешно. Это ТРС, какие предупреждения?
Ограничения скорости в проходных светофорах или знаках ограничений - это вполне есть в ТРС и активно применяется.
TRam_, попробую, потому как Чмухой толкал, а она передом толкала состав, а не задом. А состав надо расцеплять уже ПОСЛЕ первого горочного, или можно до него?
А состав надо расцеплять уже ПОСЛЕпосле или рядом.
потому как Чмухой толкал, а она передом толкала состав, а не задомесли чмуха новая, то можно Alt+C использовать.
TRam_, толкал задом, светофоры не открываются. Alt+C это что? И может тогда, какой-нибудь маркер сделать, объединить в нем все горочные, со скриптом, чтоб открыты все были во время роспуска (Или открыть вручную все, и закрыть также)?
Я ж думал ты маршрутизацией пользуешься для того, чтоб светофоры открывать.
Сами они открываться и не должны. Либо вручную, либо маршрутизацией. Закроются они, когда уйдёт толкающий локомотив. При условии что расцепляться вагоны будут ЗА светофорами и толкаешь поезд с реверсом "назад".
Alt+C это что?сочетание для переключения кабины лкомотиву с передней на заднюю и наоборот. ЧМЭ3-2663 , например, имеет заднюю кабину.
Так, почитал я это всё. Идея, конечно, супер! Я её уже больше года вынашиваю, да всё сомневался, что за неё кто-нибудь из мэтров скриптования возьмется. Тем более, что у нас их всего два.
Но! Ребята, какие графики? Какие расчеты? Вы чего, хотите то, что делают десятки, если не сотни тысяч людей на РЖД втюхать Trainz'у, и при этом он чтобы с этим справился? Ну-ну.
И потом, чем сложнее разработка, тем дальше тот день, когда она будет закончена, если вообще будет закончена. Я уж не говорю, про обилие всяких потенциальных лагов, коими даже уже существующий zxPath с его правилами зачастую не брезгует. А вот в том, виде, в котором это всё сейчас обсуждается это похоже на эпохальное Вавилонское столпотворение. И потом, какая вам разница, когда вы наблюдаете за движением со стороны проследует поезд в 10:08 или в 10:12? А уж если управляете поездом, так вообще кроме своего движения и движения вокруг (хоть даже и хаотичное - лишь бы было и не стопорилось) вообще ничего не интересует: подумаешь, какой-то грузовой где-то выбился из графика. (Далее много букафф - отправляю под спойлер)
У Бугора действительно очень много хороших идей, среди которых я узнаю и свои. Может быть не в том виде, как я себе представлял, но всё же очень близко.
Итак, как это вижу себе я. Постараюсь внятно рассказать, а то долго находился в "собачьем" состоянии: понимать-понимаю, а высказать толком - не могу. Прежде всего, ДСП - это некие объекты. Наподобие будки zxPath, только для каждой станции своя. Позже поясню почему. Она привязывается наподобие светофора к станции. В редакторе путем её инициализации определяется сколько путей у станции, какова протяженность и значение. Первое - такой объект уже есть у Эрендира, а второе - по приритету: 0 - главный путь; все остальные по возрастующей боковые. Но! Ведь есть и исключения. И такие исключения тоже должна быть возможность предусмотреть. Например, на участке МЖД Солнечная - Москва-Сортировочная три главных пути. А на участке Подольск-Москва-Сортировочная-Курская вообще четыре. Правда, я могу ошибаться, но они, по-моему, к одному участку относятся, потому как во время ремонта путей ездил там по грузовым на электричке. Причем два из них - под пассажирские перевозки, а два - под грузовые. То есть, при инициализации будка ДСП сама определяет главный путь из существующих по приоритету проставлением галки. Но у пользователя должна быть возможность вручную ещё галок наставить. Кроме этого, будки ДСП ещё знают своих соседей, что важно, и имеют возможность обмениваться информацией. Ну, как у Бугора.
Теперь возьмем его пример. Станции А(ДСПа)-Б(ДСПб)-В(ДСПв). На станции В, в четном направлении готов к отправлению состав. Кем подготовлен, вообще-то маневровым локомотивом, и как под составом оказался локомотив - опустим. Теперь ДСПв делает запрос у ДСПб, смысл которого сводится к следующему: "Люся, я тебе отправляю грузовой 525 метров, принимаешь?" Далее, ДСПб, зная размер и свободность своих путей отвечает: "Ой, Клавочка, чего для тебя не сделаешь, таки отправляй!" Это означает, что есть в данный момент у ДСПб свободные пути для приема-отправки поезда от ДСПв. ДСПв собирает маршрут, открывает выходной и следит за тем, когда освободится путь, чтобы у себя отметить, что путь, который был занят, теперь свободен.
Ну, смысл дальнейших команд-реплик, думаю понятен. Так вот, видите сколько всего нужно Клавочке знать и помнить. А Люся, так вообще меж двух огней. А вы ещё хотите сюда и расчет скоростей, графики, времени движения, времени разгона-торможения, времени захода на боковой и т.д и т.п впихнуть. Да у вас если не разработчик повесится, то компьютер - точно!
И это только простейший случай. Да, помимо этого, Люся же прекрасно понимает, что Клава от неё не отстанет и этот поезд ей таки втюхает. Поэтому, дабы не захламлять эфир, то бишь мощности компьютерные, Люся должна запомнить, что Клава к ней обращалась с предложением, от которого она не имеет права отказаться. И если на момент запроса от Клавы у неё были все пути заняты, то как только что-то освободится подходящее, она тут же должна удовлетворить клавины запросы.
И это ещё не всё. Например, Клава "говорит" Люсе всю ту же фразу, только длина поезда не 525 метров, а 870. А у Люси боковые пути всего-то по 600 метров. Значит на однопутном варианте, прежде, чем дать добро Клаве, Люся отправляет такую же фразу Верочке с 16-й водокач...ой, со станции А то есть. И вот только если Вера ответила положительно Люсе и при этом Люся от Веры ничего не принимает, только тогда она в свою очередь даёт положительный ответ Клаве и пропускает этот поезд по главному пути.
И это ещё не всё... Впрочем, и этого более, чем достаточно, чтобы мозги у разработчика точно вскипели. А вы говорите графики. Тут дай Бог, чтобы сам факт безаварийного движения происходил!
P.S. А, да, почему для каждой станции своя будка? Да всё просто, исходя из принципа "разделяй и властвуй". Но это уже не суть. Это уже детали.
домысленный текст удалёнИдею - отправляю под спойлер)
куча бреда
смысл всего этого? в такое будет играть десяток юзверей. И тем более никто создавать не будет. Сравнивать трс с реалом нельзя. Максимум с ДЖД в которой любой школота разберётся.
Надо упрощать что есть, а не усложнять
Не надо так делать - свои мысли выдавать в цитатах других пользователей. Это вводит в заблуждение. Цитату не удаляю для сохранения смысла
Цитата не соотетствует действительности
arnage, я свой текст раза три минимум перечитал, и что-то я то, что ты процитировал как моё, там даже и близко не увидел! Имей уважение к участникам форума, не приписывай им слова, которые они не говорили!
Что касается бреда - может быть. Но это лишь твоё мнение, которое тоже имеет право на существование. Только вот "куча бреда" и то, что надо упрощать, по твоему мнению, как-то никак не вяжутся. Ты не читал предыдущие посты? То есть, то, что я назвал эпохальным Вавилонским столпотворением по твоему мнению является гораздо проще, чем то, о чем я высказался? Ты вообще программы писал когда-нибудь?.. И это при том, что большинство языков программирования имеют отладчик, где пошагово можно отслеживать действия кода. В скрипт ты можешь вставить только переменные и следить за их значением, а потом ломать голову, почему же всё-таки эта переменная приняла значение именно 1, а не 8 - ведь по коду всё правильно. В общем, ищи-свищи свою ошибку. А в том, что предлагают по максимуму, так сказать, таких ошибок может быть вагон и маленькая тележка. И в один "прекрасный" день разработчик скажет: "Да пошли бы вы все...", и идея будет загублена. Тем более, что такую мысль от одного из разработчиков я читал. Хоть и не в мой адрес, но такая смена настроения меня, мягко говоря, обескуражила. И я не смог не признать правоту разработчика.
Но основная мысль моя следующая:
Надо упрощать что есть, а не усложнять
Где твои предложения? Что упрощать? Что у тебя уже есть? И для какой "школоты" ты предлагаешь писать приложения для Trainz?
P.S. За всё время существования этого форума, я школоты здесь не видел.
Кстати, ссылка на вот эти мысли Миши (amd103) http://www.trainsim.ru/forum/showpost.php?p=203850&postcount=25 тоже будет не лишняя. Хотя я его идеи резервирования не разделяю.
---------- Сообщение добавлено в 20:40 ---------- Предыдущее сообщение размещено в 20:34 ----------
:ps: через 5 дней исполнится 3 года с момента начала разработки z7-xPath :) .
OlegKhim
18.09.2013, 20:45
через 5 дней исполнится 3 года с момента начала разработки z7-xPath .
Включим салют... :phil:
Кстати, ссылка на вот эти мысли Миши
Ага, почитал... genesis, конечно же, умный парень. Я бы ему ответил, если бы вовремя увидел эту статью примерно следующее.
А не хочешь ли ты на факультете АСУ в ИИТе защитить курсовой проект на основе этих идей? А если развить эти идеи, то и на дипломный проект можно замахнуться.
Вов, как тебе идея ещё один диплом написать!?:rofl2: Так просто, походя, для Trainz...:mocking:
Но есть, конечно же, там кучка идей, которые можно повыдергивать из контекста и преобразовав в угоду, например, arnage, упрощенно реализовать. А то ещё, не приведи Боже, какая-нибудь "школота" не поймет зачем ему мигает зелёный предвходной! :rofl2:
Ну а теперь серьёзно и по существу.
Идею резервирования я до конца так и не понял. Но это меня натолкнуло на вот какую мысль. ДСПв запросил прием у ДСПб поезда. Это же не значит, что ДСПб при положительном ответе ДСПв сразу же блокирует входную горловину... Блин, запутался уже в этих ДСП. Давай я лучше к "Люсям" перейду. Так веселее будет..:mocking:
Так вот. Клава (ДСПв) сказала Люсе (ДСПб), что она хочет её осчастливить ещё одним подвижным составом. Люся, не будь дурой, сначала подумала, прежде, чем ответить. О чем - писал ранее. Дала положительный ответ. Но на этом её тревоги не закончились. Это же не значит, что ей нужно тупо собрать входной маршрут, блокировав , тем самым, маневры в горловине. Значит, ей нужно следить за тем, где именно находится прибывающий состав. И вот "(я предполагаю 4-6 БУ)" - самое оно. Но это означает, что ДСП ещё и перегоны контролировать? В жизни, конечно, так оно и есть. Но применительно для Trainz?.. Сомнительная перспектива заблокировать маневры по путям формирования отправляемых отцепов на промежуточных небольших станциях...
Так, на этом пока всё. Статья очень интересная, и мы её разберем по косточка позже, потому как время уже позднее. Посему рассмотрим всё остальное завтра.
Вов, как тебе идея ещё один диплом написать!? Так просто, походя, для Trainz...У меня уже не диплом будет. А кандидатская по математической модели железнодорожного путеизмерителя :blum1:
:ps: когда-то находил статейку, там согласование движения поездов на участке через матрицы осуществлялось. Но не думаю, что в ближайшее время кто-нибудь займётся написанием такой модели в виде скрипта. Хотя кто знает.
SHEP Rom
19.09.2013, 01:56
NickLon, жму руку по поводу написанного - не один я такой дурак, который видит Автоматическую систему управления движением именно в таком виде( ну почти в таком виде), как ты описал. А то, что пишет товарищь arnage, показвыает лишь то, что он просто не в теме, так что успокойся. Я Вове предлагал пообщаться в скайпе, ну раз ты тут хоть что-то написал, я попробую более развернуто написать.
Итак, основная идея в
"разделяй и властвуй".
а именно в том, что в такой системе должны быть задествованы все участники такой пъянки: в первую очередь машинист поезда, система маршрутизации, которая должна состоять из контроллеров (наподобие как в z7) станций, перегонов, парков станций. Также я считаю, что любой путь между двумя стрелками должен иметь маркер пути, в котором должна указываться вся информация об этом пути: что, кто, когда и зачем , длина. Т.е. кого принимать, с остановками или без и т.д. Вот контроллер и будет следить за подчиненными ему путями на основании информации с этих маркеров. Привязка, как и светофоров в z7.
И если сейчас, как я понимаю, за каждым поездом следит маршрутизация, то я считаю, что машинист поезда должен сам следить за прохождениемм своего маршрута, и общаться с остальным "колхозом" на основании заявок на прохождение своего маршрута. И уже контроллеры, которые общаются между собой, и знают всю поездую обстановку на своих территориях( я имею ввиду, что они знают , у кого сколько вообще путей, что это за пути по приоритетам, их длины, и занятость этих путей, и самое главное - они знают о заявках других поездов на тот или иной путь или Б-У), будут на основании заложенных в их скрипты логики пропуска поездов собирать или искать альтернативные маршруты, управляя при этом сигнализацией.
В принципе смысл тот же, что и в случае Люси и Клавы. Ну и если я правильно понял, то и идея по резервированию маршрута Мишы подразумевает то же самое.
Как мне кажется, такое разделение задач по каждому участнику должно снизить нагрузку на скриптовую часть - если все действия по обработке маршрутов при интенсивном движняке возложить на один объект, то ему прийдётся постоянно опрашивать тысячи параматров, даже тогда, когда это никому не нужно. А так, если машинисту нужно что-то, он и выдеёт заявку, и только тогда соответствующие контроллеры её обрабаывают. И когда они закончили обработку, могут уже в медленном режиме опрашивать свои пути в виде маркеров.
Но это была первая часть системы. Вторая часть касается так называемого автомашиниста и его команд. В кратце: сейчас существуют сотни команд и правил для описания каждого сантиметра пути движения поезда. Да, каждое правило в отдельности работает. Но в сложной взаимодействующей системе таких правил и команд неизбежно возникают конфликты. И самая главная проблема в том, что они не имеют альтернативности, т.е. автовыбора иного действия. Для этого приходится тратить тысячи часов на тестирование каждого поезда. Я считаю, что нужно, чтобы все эти команды были объеденены в более простые команды на подобие дефолтных "Следовать через маркер" и "Следовать к маркеру". Только чтобы за такими простыми на первый взгляд командами скрывалась целая иерархия вот таких команд или правил со своей заложенной логикой работы.
Потому я думаю, что отдельно взятая система сигнализации, маршрутизации и ещё чего не решит абсолютно ничего. Да, что-то они могут. Но на создание такой сессии нужно тратить тысячи чаосв на создание, а потом ещё тысячи часов на тестирование. Должна быть комплесная система Автоматического управления движением, уже включающая в себя логику сигнализации, автомашиниста и систему контроллеров с маркерами, где каждый будет заниматься только тем, что ему необходимо. Я полагаю, что только такая система сможет в автоматическом режиме по заранее прописанной логике следить за движняком на карте, устраняя заторы, пропуская поезда по однопутному перегону( как писал Трам блоками в одном направлении), и возможно искать альтернативные маршруты при невозможности проезда по ранее заданному маршруту боту( как пример, должен был бот проехать через какой-то там маркер или светофор, а тут приперся игрок на поезде, и занял этот путь. Сейчас то что? Бот будет стоять и ждать, пока освободится путь. Хотя мог бы свалить со станции через другой путь).
Ну вот так в кратце вижу что-то подобное я. Может не всё вспомнил и описал, может быть чушь и дурь, но... Также я считаю, что лучше в редакторе при постройке или адаптации карты, потратить больше времени на расстановку всяких маркеров, светофоров и контроллеров (для большей информативности для системы), чем потом сидеть и обсасывать с помощью команд или правил каждый сантиметр пути для бота. А потом ещё всё это тестировать.
Я прекрасно понимаю, сколько нужно времени на такую разработку. Но думаю, результат такого стоит.
---------- Сообщение добавлено в 01:56 ---------- Предыдущее сообщение размещено в 01:19 ----------
Дополню: считаю, что пользователь для обычного бото-поезда должен задавать только маршрут следования. А все остальные действия, которые сейчас задаются с помошью правил и команд, должны выполняться автоматически. При желании привязать поезд к каким-то действиям и событиям, маршрут следования можно дополнить такими заданиями.
И если сейчас, как я понимаю, за каждым поездом следит маршрутизациямаршрутизаци я к поездам не привязана. Она следит, чтобы маршруты не строились через стрелки, занятые другими маршрутами, через или на пути, на которых стоит или приедет встречный состав.
будут на основании заложенных в их скрипты логики пропуска поездов собирать или искать альтернативные маршруты, управляя при этом сигнализациейА этим уже занимаются команды zxPath или Ботомашиниста.
Проблема заключается в том, что пока эти команды никак между собой не взаимодействуют. То есть работают по принципу "есть свободный путь нужной категории/блок-участок перегона - на него можно прибывать/отправляться". И задача состоит как раз в согласовании "когда можно/нельзя отправляться" и "когда нужно занять путь низшей категории для пропуска других поездов".
считаю, что нужно, чтобы все эти команды были объеденены в более простые команды на подобие дефолтных "Следовать через маркер" и "Следовать к маркеру"в общем, советую тебе взять, поставить и испробовать команды zxPath, а именно её фитчу "приоритеты маршрутов". Ты с ней не знаком.
---------- Сообщение добавлено в 08:53 ---------- Предыдущее сообщение размещено в 08:45 ----------
если все действия по обработке маршрутов при интенсивном движняке возложить на один объект, то ему прийдётся постоянно опрашивать тысячи параматров, даже тогда, когда это никому не нужно.в zxPath гораздо проще. Когда машинист съезжает с очередной стрелки, тогда и только тогда нужно проверить свободность блок-участка за ним (т.е. освободил он его или нет). Благодаря этому z7-xPath и zxPath относительно спокойно работают на таких картах как Москва-Малоярославец. Если бы все участки опрашивались периодически, ни один комп не смог бы эти системы потянуть. От того, один объект опрашивает 100500 участков, или 100 объектов опрашивают 100500 объектов - компу не легче. Даже, я могу сказать, во втором случае несколько тяжелее.
Ну вот, пока я набирал свой текст TRam_ вкратце и доступно уже выразил свои мысли, с которыми я абсолютно согласен.
Единственное, что хочу подчеркнуть, SHEP Rom, в этой системе машинист никому ничем и никак не должен быть обязан. Его задача - вести поезд. Всё! А для ботов может быть одна единственная команда быть - слушать диспетчера. Это как в z6 было. У машиниста одна единственная команда в списке, а уже внутри этой команды свой список команд. А здесь внутри команды "слушать диспетчера" крутится свой внутренний механизм, в который пользователь даже и заглянуть не моги. Но здесь тоже есть свои нюансы. А какого именно диспетчера, если на каждой станции он свой? Вот здесь и могут понадобиться разнонаправленные маркеры на перегонах, проезд которых и будет означать, что машинисту уже нужно слушать другого диспетчера. Здесь, возможно, возникнет вопрос, а зачем машинисту вообще кого-то слушать? Едет себе да и едет, а маршруты ему собирает ДСП. Но у поезда могут быть и остановки. У пассажирского у платформ, даже и под зеленый выходной, а у грузового на боковые, чтобы отдать/взять дополнительные вагоны.
SHEP Rom
19.09.2013, 20:34
Проблема заключается в том, что пока эти команды никак между собой не взаимодействуют
Одна из главных пока проблем.
"когда можно/нельзя отправляться"
Я думаю, пока нужен механизм для применения логики можно/нельзя. А уже потом можно мозг ломать когда можно, а когда нельзя.
советую тебе взять
Вова, пока там будет 100500 объектов для задания движения поезду, я не вижу в этом смысла.
Я думаю, пока нужен механизм для применения логики можно/нельзя.в первом приближении это решается переменными. Которые, кроме значений "да/нет" могут ещ иметь значения в виде натуральных числах (например подсчёт поездов, которые требуется пропускать).
пока там будет 100500 объектов для задания движения поездутам разные наборы совместных условий. Например в одних случаях нам надо одновременно проверять свободные пути станции и двигаться к светофору, в других, нам двигаться не надо во время поиска маршрута. Или, например, нам надо контролировать направление следующего перегона, чтобы прибыть на боковой для скрещения, а не на главный.
---------- Сообщение добавлено в 20:48 ---------- Предыдущее сообщение размещено в 20:45 ----------
нужен механизм для применения логики можно/нельзя.маршрутизация zxPath + дерево правил с переменными + правило zxPath AddAnyPath
---------- Сообщение добавлено в 21:05 ---------- Предыдущее сообщение размещено в 20:48 ----------
Другой вариант
команды ChangeSVariable + команды If Else + команды WaitUntilVariable + команды zxPath и Ботомашиниста
Вижу, тут многим не понравилась система, управляющая движением согласно плану перевозок, и они предлагают более простые, на первый взгляд, децентрализованные системы, управляющие движением без плана перевозок и, как следствие, по фактическому, непредсказуемому стечению обстоятельств. Здесь хочу отметить два важных момента.
1. Системы, управляющие движением без плана перевозок, в итоге окажутся чрезмерно сложными и неработающими вследствие необходимости гораздо более высокого уровня интеллекта системы по причине непредсказуемости поездной обстановки, развивающейся случайным образом и постоянно создающей нетипичные ситуации, из которых нужно найти верный выход. Нетипичные - разнообразие которых практически бесконечно, а значит их практически невозможно предусмотреть. Можно представить это в виде цепочки:
Отсутствие централизующего начала (плана перевозок, графика) -> случайное развитие событий -> возникновение нетипичных ситуаций -> отсутствие верного решения -> game over.
Не зря же на реальных дорогах управление движением построено на централизующем начале, объединяющем всю сеть - на плане перевозок и графике. График движения поездов является организующей и технологической основой работы всех подразделений железных дорог, планом всей эксплуатационной работы.
2. Создание плана перевозок и графика в ТРС - совершенно отличается от этого же в реале. Как сказал Никлон, в реале над ними работают десятки тысяч людей, это всеобъемлющий процесс, и такое в ТРС не повторить. В этом он прав. Но никто не собирался делать всё то же самое, что делают в реале. На то есть ряд причин.
Первая - в реале график создаётся для всей сети железных дорог, протяжённость которых доходит до 85000 км. В ТРС график создаётся для отдельно взятой карты, протяжённость которой в лучшем случае 600 км. Есть разница? В реале график создаётся и для пассажирских, и для грузовых поездов. В ТРС достаточно загрузить уже готовое и доступное расписание пассажирских. В реале рассчитываются экономические, юридические и статистические аспекты. В ТРС они упраздняются и остаются только технические.
Таким образом, в ТРС создание графика сводится к следующему:
1. Расчёт вагонопотоков
2. Создание плана местной работы
3. Создание схемы оборота локомотивов и локомотивных бригад
4. Расчёт элементов графика (времена хода, станционные и межпоездные интервалы, время стоянки поездов под разными операциями)
Если представить работу системы на основе графика в виде цепочки, то будет как-то так:
Наличие централизующего начала (графика) -> запланированное, предсказуемое развитие событий -> возникновение типичных ситуаций -> наличие верного решения -> получение Нобелевской премии.
Кстати, в системе можно сделать выбор роли игрока - машинист, ДСП, ДНЦ, пассажир.
развивающейся случайным образом и постоянно создающей нетипичные ситуации,это как раз самое интересное. А степень нетипичности ситуаций определяется плотностью потока поездов. А поток поездов всегда можно регулировать, и даже создать обратную связь на степень сложности ситуаций (и получится саморегулирующаяся система).
А то, что "каждый понедельник машинист Вася останавливается под красный на станции Х для прицепки 5 вагонов" - не, это совершенно неинтересно.
---------- Сообщение добавлено в 19:27 ---------- Предыдущее сообщение размещено в 18:17 ----------
В качестве примера:
https://www.youtube.com/watch?v=V_IQfsKzBK0
(обратная связь основана на том, что порталы не выпускают поезда, пока с их пути не съедут предыдущие)
это как раз самое интересное. А степень нетипичности ситуаций определяется плотностью потока поездов. А поток поездов всегда можно регулировать, и даже создать обратную связь на степень сложности ситуаций (и получится саморегулирующаяся система).
А то, что "каждый понедельник машинист Вася останавливается под красный на станции Х для прицепки 5 вагонов" - не, это совершенно неинтересно.
Нет-нет, ты меня не так понял.
В движенческом процессе, базирующемся на графике, как естественное явление всегда будет присутствовать случайность. Её суть будет заключаться в том, что запланированные события будут развиваться каждый раз по-разному. Связано это с неравномерностью вагонопотока в разные дни недели и времена года; с возможностью и/или вынужденностью по-разному использовать путевое развитие станций для одних и тех же операций (приём, сортировка, манёвры); с возникновением форс-мажорных обстоятельств (опоздание, поломка ПС, КС, пути, аварии, пожары). Даже не ожидаемые случайности (форс-мажор) достаточно легко устраняются и движенческий процесс вводится в нормальные рамки, когда есть точка отсчёта этой нормальности в виде графика.
А в предыдущем посте я восставал не против таких вкусных случайностей, а против случайной, децентрализованной организации движения.
Не, ребята, вы реально с ума сошли, если всерьёз обсуждаете это.
CFM, какие , к черту, расчеты вагонопотоков? Какие планы местной работы? Какие расчеты элементов графика? Ты хотя бы на бумаге это для себя нарисуй в виде блок-схемы, а потом мы с тобой поговорим, реализуемо это или нет. "Если захочешь..." (с):mocking:
:ps:Пока особо ничего конкретного (в плане лучшего относительно Люси, Клавы и кто-то там ещё был) не увидел. А если будут вот такие заморочки, которые предлагают максималисты, я и близко к такой системе не подойду. Хватает мне и zxPath в таком случае.
люси-клавы тоже слишком .
для игры не хватает правил в управлении маршрутизацией (включая случаи постановки под обгон, движения строго по графику, маневры по станции и другие), какой-то более понятной и лёгкой альтернативы переменным и более продуманных порталов
CFM, какие , к черту, расчеты вагонопотоков? Какие планы местной работы?
Ты хотя бы на бумаге это для себя нарисуй в виде блок-схемы
Да пожалуйста - блок-схемы есть:
http://s004.radikal.ru/i205/1309/7b/45c9223ad7bft.jpg (http://s004.radikal.ru/i205/1309/7b/45c9223ad7bf.gif)
http://s003.radikal.ru/i203/1309/fd/4301cc200863t.jpg (http://s003.radikal.ru/i203/1309/fd/4301cc200863.gif)
С наличием всех необходимых формул для каждого шага.
Да пожалуйста - блок-схемы есть:
Не, это всё, конечно, замечательно. В интернете я видел такие красивые картинки (между прочим, несколькими постами выше была ссылка на нечто подобное). У меня...эээ, пожалуй уже вопрос, а не предмет дискуссии: и как ты бы это реализовал применительно к Trainz?
Ты что, реально считаешь возможным это всё применить в Trainz? Конечно же, как говорится, если долго мучится - что-нибудь получится. Но вот кто будет "мучится" - это уже вопрос.
Таким образом, я ратую за то, чтобы особо не заморачиваться над всякими там "Расчет времени работы сборных поездов на промежуточных станциях." Клава должна отдать поезд Люсе, а Люся должна его принять. Как там в подписи у OlegKhim, "От простого к сложному"? Вот и нужно сначала простое реализовать, а в совершенствовании этого простого придем и к сложному.
Ферштэйн?;)
С наличием всех необходимых формул для каждого шага.Никогда не пробовал породелать подобное в Transport Tycoon ? Там станции простые, маршрутизацию настраивать не надо, индустрии тоже грузят вагоны :) ...
---------- Сообщение добавлено в 04:00 ---------- Предыдущее сообщение размещено в 03:53 ----------
для игры не хватает правил в управлении маршрутизацией (включая случаи постановки под обгон, движения строго по графику, маневры по станции и другие), какой-то более понятной и лёгкой альтернативы переменным и более продуманных порталовНу допустим насчёт порталов согласен. А как должны выглядеть правила для маршрутизации, по-твоему? По-типу списка заданий для категории (машинистов, поездов или вагонов?) А как тогда увязывать между собой, например, прибытие пассажирского и прицепку к нему беспересадочного вагона (манёврами)? И к чему привязывать прибытие на станцию, если нет индустрийной платформы?
у каждого состава на если посмотреть на карту есть номер. Его можно менять? или присваивать какой-то цифро-буквенный код ? или лучше несколько. Номер поезда для поездов 1 и 2 приоритета. И буквенный код для вагонов в нём и их места назначения.
маневровую и поездную работу лучше разделить.
для поездного правила как вариант более умный z7_script_dnc. Поезд наезжает на триггер перед входным - правило читает его номер, смотрит таблицу задание (отдельное правило ) и открывает соответствующий маршрут. В правиле задании должны быть расписаны варианты действий. Например для поезда мск-воронеж (какой-то там номер поезда) в отрожке проследовать прямо (указать конкретный маршрут). в воронеже на любой путь 1-го приоритета. Остальные станции с безостановочным пропуском. это же правило ( типа умное з7_скрипт_днц) должно по графику открывать выходные со станций. Время стоянки по расписанию указано в правиле задании .
Для грузовых сложней. Проверка перегона сзади поезда для постановки под обгон у указанных заранее станций и станция назначения (берётся из номера поезда)
Манёвры не представляю как сделать простыми. Все варианты действий маневрового лока должны быть забиты заранее. Правило днц-маневры следит за событиями и при срабатывании условия даёт определённое задание определённому локу.
можно конечно и существующие команды поправить и всё это реализовать лесенками и переменными, но как-то очень сложно.
Раньше просил сделать правило "задать маршрут за закрытым" которое не переставало бы работать пока не откроет маршрут отличный от 0. На станции назначения пути приёма пасс поездов сделал приоритета 13 допустим. И пока поезд с командой "задать маршрут за закрытым не ниже 13 не выше 13 или 0" не найдёт и не откроет 13 будет ехать по 0 все станции. При открытии 13 начинает действовать следующая команда, например движение до красного. Для каждого поезда (или группы) свои маршруты на участке
маневры легко делаются с БОК. Ожидание любого набора команд из списка и активация по триггеру или от другого машиниста. Только забивать кучи наборов очень непросто. С переменными так вообще нереально много
Его можно менять? или присваивать какой-то цифро-буквенный код ? или лучше несколько.а как оперировать с номерами, когда идёт сцепка или расцепка состава? Как задавать вагонам буквенные коды? И самое главное - кто этим будет заниматься для составов, производимых порталами? Генератор случайных чисел? И ещё - как генерировать номер у сформированного поезда?
Время стоянки по расписанию указано в правиле заданиивремя стоянки где? Перед выходным светофором?
---------- Сообщение добавлено в 10:06 ---------- Предыдущее сообщение размещено в 10:05 ----------
это же правило ( типа умное з7_скрипт_днц) должно по графику открывать выходные со станцийможно сделать правилами "TimeCheck"+"AddPath"
---------- Сообщение добавлено в 10:11 ---------- Предыдущее сообщение размещено в 10:06 ----------
И пока поезд с командой "задать маршрут за закрытым не ниже 13 не выше 13 или 0" не найдёт и не откроет 13 будет ехать по 0 все станции.а 13 путь (или стрелки на пути к нему) оказался занят, поезд станцию проехал по главному без остановки :) .
---------- Сообщение добавлено в 10:16 ---------- Предыдущее сообщение размещено в 10:11 ----------
смотрит таблицу задание (отдельное правило )не думаю, что настройка заданий для поездов на каждой станции чем-то будет проще настройки shedule rule ...
а как оперировать с номерами, когда идёт сцепка или расцепка состава? Как задавать вагонам буквенные коды? И самое главное - кто этим будет заниматься для составов, производимых порталами? Генератор случайных чисел?
с прицепными у пассажирских проще. На путь "А" прибыл поезд 53. Активируется список команда в БОК. и маневровый делает что должен
Активировать только должен не триггер или машинист как сейчас, а правило задание.
У грузовых поезд с номером 3001 и кодом А1gА1gА0Д1dД0Е1f.... (где А тип вагона, 1 загружен, 0 пустой, g,d,f - конечный тупичок вагона для разгрузки) прибыл на путь А, генерируется список команд ( хз можно ли это) из заранее известных коротких наборов(задать маневровый маршрут под состав - сцепится с поездом - отцепить с головы N вагонов-развернутся + набор что делать дальше + опять первый набор) с учётом правила-задания для грузов и начинаются манёвры. правило-задание для грузов создаётся заранее и живёт и меняется в течении сессии.
жесть какая :wacko2:
время стоянки где? Перед выходным светофором?можно сделать правилами "TimeCheck"+"AddPath"
да так и делал. но много лесенок ). хочется одно правило для всего движения. остановился поезд. пошёл отчёт времени на стоянку. грузовой сформирован на пути "х" - собран маршрут отправления
---------- Сообщение добавлено в 12:46 ---------- Предыдущее сообщение размещено в 12:41 ----------
а 13 путь (или стрелки на пути к нему) оказался занят, поезд станцию проехал по главному без остановки :)
как это занят? если такой маршрут есть он собран и поезд стоит у входного и ждёт его открытия и выполняет следующую команду
не думаю, что настройка заданий для поездов на каждой станции чем-то будет проще настройки shedule rule ...
а что там сложного? )
а что там сложного? )ну допустим 6-7 категорий поездов. На карте 20 станций. Итого надо 240 заданий (для чётного и нечётного направлений). Ровно столько, сколько команд надо добавить в Shedule rule .
правило z7 dnc одно на всю карту. Открывает все светофоры которые надо открыть если перед ним поезд. Добавить возможно открытия маршрута по условиям нельзя? Одно условие это "какой поезд" (его номер или имя) и второе условие "какой маршрут" (маршруты в отдельном правиле для каждого номера свои. и/или по группам). Если указанного маршрута нет значит на проход по 0 приоритету (большинство из 240)
и это только поездная работа. без маневровой. маневровые отдельно
У меня...эээ, пожалуй уже вопрос, а не предмет дискуссии: и как ты бы это реализовал применительно к Trainz?
В моей задумке расчёты грузового движения (пассажирское тупо вводится из расписания) строятся на данных о суточных потребностях предприятий в определённом типе ПС с определённым грузом. Предприятия, относящиеся к одной станции примыкания, в сумме образуют потребности этой станции. Станции, относящиеся к одному участку (между двумя техническими станциями), в сумме образуют потребности этого участка. Потребности образуют расчётный вагонопоток. На основе рассчитанного вагонопотока разрабатывается местная работа.
Teplovozz
24.09.2013, 22:06
CFM, эк тебя вштырило-то... :mocking:
В моей задумке расчёты грузового движения (пассажирское тупо вводится из расписания) строятся на данных о суточных потребностях предприятий в определённом типе ПС с определённым грузом.
Хех, была, была у меня такая "задумка". Но потом я пришел к выводу, что это меня всё-таки "вштырило". :mocking:
Как ты будешь распределять вагоны, которые перевозят несколько типов груза, да ещё и эти несколько типов грузов загружаются/разгружаются на одном объекте, например, наливные? Не, в принципе, возможно, и реализуемо, но по-моему это уже выходит за рамки железнодорожного симулятора. Какая-то прям транспортная макроэкономическая модель. Вряд ли стоит этим так дотошно заниматься. Тем более, я не думаю, что кто-то этим займется всерьез. Так, Нью-Васюки очередные.
Как ты будешь распределять вагоны, которые перевозят несколько типов груза
В настройках предприятия указывается в каком типе вагона подвозить груз.
по-моему это уже выходит за рамки железнодорожного симулятора. Какая-то прям транспортная макроэкономическая модель.
Почему? Ведь моделируется только движенческие, а не экономические аспекты перевозок.
Вряд ли стоит этим так дотошно заниматься.
В этом случае дотошность - залог стабильной работы диспетчера. Если изначально так подойти к идее, то не придётся потом искать выход из тупиков из-за упрощённых концепций. Подчёркиваю, что я предложил не усложнённый ненужными расчётами вариант, а урезанный, направленный конкретно на имитацию движенческого процесса вариант.
Тем более, я не думаю, что кто-то этим займется всерьез.
Будет потребность в таком диспетчере (а она будет) - займётся.
В настройках предприятия указывается в каком типе вагона подвозить груз.на данный момент даже этого нет.
вообще можно и без груза. Главное движение)
Ну так CFM хочет именно по производительности погрузки-разгрузки расчитывать число поездов и их расписание.
Увы и ах, но автоматическая диспетчеризация в Trainz невозможна....
Завтра уже расскажу, как я пришел к такому выводу.
---------- Сообщение добавлено в 14:08 ---------- Предыдущее сообщение размещено в 02:52 ----------
В общем, я тут почесал репу и пришел к выводу что если всё подробно рассказывать-выкладывать - вряд ли в результате что-то кто-то поймет. Поэтому просто кратко конкретную ситуацию проиллюстрирую. Ситуация заключается в том, что в каждый раз исполнения сессии весь маневровый ПС ведет себя на станции не так, как он вел себя в предыдущем исполнении сессии (для краткости - "прогон"). Нет, конечно же в 90% случаев так оно и есть, может быть даже в 95-ти процентах. Но оставшиеся 5-10 процентов то всё и портят. А ведь от того, как ведет себя маневровый ПС на станции, особенно крупной, такой, как Москва-Киевская, зависят и поездные движения ПС. И предвидеть заранее кто первый займет один из пересекающихся маневровых маршрутов и как пойдет дальше развитие событий в автоматическом режиме просто невозможно.
Теперь немного конкретики. Из места отстоя маневровых локомотивов вышел ЧМ3 к составу, который прибыл к платформам. И в то же время, с соседнего пути другой ЧМ3 отгоняет состав в парк отстоя. Им обоим совершить маневр мешал ещё один прибывающий состав. Раньше я думал, что действует правило "кто первый встал, того и тапки". То есть, кто первый попытался построить себе маневровый маршрут, то как только это станет возможно, то он первый его и построит. Ан нет. Наблюдал картину, когда вовсе не так это было. А последствия и какая разница? Одно дело, когда ЧМ3 из депо прошмыгнет к составу и освободит горловину для дальнейших движений, а другое - когда он ждет, пока другой ЧМ3 вытащит свой состав из тупикового пути в парк отстоя, ну, по крайней мере освободит хвостовым вагоном все нужные для следующего маневра стрелки. Смекаете о чем я? И в результате, на 75-й минуте прогона, когда уже остался один единственный состав на станции, два маневровых стали друг напротив друга едва ли не на противоположных концах станции и "спорят, кто кому должен уступить дорогу". Да, такой коллапс нужно искоренять на этапе моделирования маневрового движения. Посмотрев на ситуацию пристально, я пришел к выводу, что ошибки там и не было. И один, и второй локомотивы должны были стоять там, где стояли по правилам. Но живой диспетчер не выпустил бы один из локомотивов туда, где он бы создал бы потенциально коллапс. А вот автоматическую диспетчеризацию не заставишь думать, прежде, чем разрешить движение того или иного ПС.
"спорят, кто кому должен уступить дорогу"а с чего это второй ЧМЭ3 (который отгонял состав) вдруг захотел выставлять состав именно на тот путь, с которого вагоны (точнее тепловоз) ещё не убрали? Я бы для моделирования такого "диспетчера, знающего о занятости путей" наделал бы переменных, отображающих их занятость. Или хотя бы переменные о том, что тепловоз № такой-то занял такую-то горловину.
---------- Сообщение добавлено в 15:03 ---------- Предыдущее сообщение размещено в 14:53 ----------
Раньше я думал, что действует правило "кто первый встал, того и тапки".никак нет. Это действует только тогда, когда в в поездном браузере задана очередь маршрутов. В случае обычных маршрутов в браузере первым установится тот, которому первому освободятся все стрелки (если у нескольких маршрутов стрелка освобождается одновременно, то собирается первый в списке). А в случае команд/правил автоматического поиска поездных/маневровых маршрутов - в каком порядке соберутся маршруты никто сказать не сможет, т.к. команды их проверяют с заданной периодичностью (у меня раз в 5 секунд), а порядок проверок команд у разных машинистов не синхронизирован, а случаен.
порядок проверок команд у разных машинистов не синхронизирован, а случаен.
Вот где корень проблем Никлона. Может ввести приоритет командам на сбор маневрового маршрута? Приоритет выставляет пользователь и маршруты собираются по порядку.
---------- Сообщение добавлено в 19:58 ---------- Предыдущее сообщение размещено в 19:55 ----------
И предвидеть заранее кто первый займет один из пересекающихся маневровых маршрутов и как пойдет дальше развитие событий в автоматическом режиме просто невозможно.
График как раз предполагает предвидение событий.
Может ввести приоритет командам на сбор маневрового маршрута?это не интересно. Интереснее заставить "диспетчера" видеть и проверять занятые пути, либо не пускать в одну горловину 2 маневровых сразу, если есть вероятность их попадания на один путь.
---------- Сообщение добавлено в 00:06 ---------- Предыдущее сообщение размещено в 00:04 ----------
График как раз предполагает предвидение событий.не предвиденье, а предопределение. Это разные вещи.
это не интересно. Интереснее заставить "диспетчера" видеть и проверять занятые пути, либо не пускать в одну горловину 2 маневровых сразу, если есть вероятность их попадания на один путь.
Я не про автодиспетчера, а про существующую версию команд ZX.
не предвиденье, а предопределение. Это разные вещи.
А предопределение даёт некоторое предвидение :)
а про существующую версию команд ZXкоманды друг друга не видят и не взаимодействуют. Более того, чтоб твоя идея с приоритетами заработала, нужно чтобы у каждой предыдущей команды приоритет был ниже, чем у последующей. Нечто подобное у меня есть в поездных маршрутах, но там опять же, приоритет освободившейся стрелочной улицы перед последовательностью задания команд (если не выбирать очередь, когда последующий маршрут ждёт сбора предыдущего).
---------- Сообщение добавлено в 01:00 ---------- Предыдущее сообщение размещено в 00:56 ----------
А предопределение даёт некоторое предвидениепредопределени е даёт заданный процесс, который ясен от начала и до конца. Предвидение -
метод определения, описания объектов, явлений.., несуществующих на момент исследования
А график - это когда мы и так всё знаем, то есть последовательность прохода поездов и составов уже существует и нам известна..
График как раз предполагает предвидение событий.
График для маневрового движения!?:scare::suicide:
Нет, для поездного, естественно.
Powered by vBulletin™ Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot
