Автоблокировка

[Q]

Также как и вы, жду - не дождусь, когда же наконец появится аналог PBS на базе YAPF. И видимо, это произойдет ой как нескоро. И окажется, что у нового PBS будет какая-нибудь чудовищная логика работы, непонятная даже самому автору. А ведь все можно сделать проще и элегантней. Предлагаю новую систему сигнализации для OTTD под кодовым названием "автоблокировка", со следующей логикой работы:
1. Все участки ЖД делятся на три класса:
а) однонаправленные линии;
б) двунаправленные линии;
в) перекрестки.
(Деление, надеюсь, интуитивно понятно)
Все светофоры умеют показывать три сигнала:
а) зеленый;
б) желтый;
в) красный.
Но эти сигналы будут означать не то же самое, что на настоящей ЖД!
Зеленый сигнал означает "следующий блок-участок свободен", либо "перекресток полностью свободен". Зеленый сигнал поезд проезжает без остановки.
Желтый означает "следующий блок-участок занят поездом попутного направления", либо "перекресток занят другим маршрутом". Перед желтым сигналом поезд останавливается и ждет, пока он не станет зеленым.
Красный сигнал означает "перегон занят встречным поездом", либо
"все доступные перегоны после перекрестка заняты встречными поездами". В идеале красный сигнал на пути поезда встретиться не может. В реале игрок может развернуть поезд на перегоне, встроить в путь стрелку, и т.д., поэтому пусть он вызывает разворот поезда.
Сигналами полностью управляется поведение поезда на перегоне.
На перекрестке логика должна быть следующая: поежд может въехать не перекресток только при наличии свободного выхода, подходящего маршруту этого поезда, то есть, алгоритм поиска пути находит подходящие варианты дальнейшего движения, а затем среди них ищется свободный, если такового нет, то поезд ждет освобождения не въезжая на перекресток.
Такая сигнализация позволяет организовать согласованное движение по двунаправленной однопутке нескольких поездов (ради чего вся песня-то). Достичь функциональности PBS вроде бы тоже ничего не мешает (это значительный плюс). Небольшая доработка с введением дополнительных сигналов (тогда система станет совсем похожа на настоящую ЖД автоблокировку) позволит сделать постепенную остановку поездов (чтобы он не сразу тормозил перед запрещающим сигналом, а загодя получал информацию, что впереди свободно не два блок-участка, а только один).
Это общая идея нового патча, который я называю "Автоблокировка".
Теперь вопросы.
Ну во-первых, понимаю, что на вопрос "кто осилит такое закодить?" ответ написан на любой коробке с советским конструктором. Да, я готов сделать это сам, но на это уйдет какое-то время. Еще возможно, что я все-таки не осилю, в этом случае я не хочу, чтобы идея пропала ни за грош, поэтому и создаю эту тему Но вдруг кто-то уже занимался подобной штукенцией, тогда возможно мне помогут хотя бы советом. Кстати, вот, сколько разных сигналов может показывать один светофор? (то есть не наколюсь ли я уже на этом моменте?)
Во-вторых. Мне требуется совет профессионалов, куда такую штуку можно прикрутить (в смысле, к какому алгоритму поиска пути)?
Как я понимаю, есть варианты NPF, YAPF и написать свой алгоритм.
Думаю, что моя идея не нова, и если она еще никуда не прикручена, значит что-то мешает? Я конечно сам разберусь, но если мне кто-нибудь подскажет, в какую сторону мне думать не надо, я скажу большое спасибо Писать свой алгоритм поиска пути ой как не хочется, чую я это большущий геморрой.
Опять же, код все время меняется, поэтому патч надо будет все сремя обновлять, поэтому стоит прикручивать к какому-нибудь более-менее постоянному куску кода.
В-третьих. Если вы видите какой-либо изъян в самой логике, если вы видите где можно ее улучшить, если вы знаете, как можно ее дополнить, или вы знаете как сделать еще проще, не стесняйтесь, пишите, я буду только рад.
Если повезет и я осилю эту штуковину, то это будет мой первый патч
Хочется знать, насколько он будет востребован? (стоит ли вообще корпеть?)

[Quark]

Аналог PBS точно не осилить, суть PBS заключается в том, что она позволяет пустить в одном сигнальном блоке более одного поезда.

Думать надо в сторону того как работают светофоры и алгоритмы поиска пути в OTTD, когда придёт понимание, то сразу станет ясно как эту работу можно изменить

Если отборосить идею проверки встречных поездов на светофоре, то останется только два варианта и получится как есть сейчас.

[kraks]

А мне кажется, что разворачиваться от идущего на тебя поезда не правильно. Зачастую бывает так, что это тот, кто на светофор идет с другой стороны должен развернуться. Ведь если возникает затор, то через какое-то время поезда прутся назад. А на него наезжает поезд сзади, и если наезжающий первым подъедет к светофору и он развернется. Можно получить ситуацию, когда от одного развернувшегося поезда перед пробкой (понятно, что их не должно быть, но все ж бывают иногда... все ошибаемся, все мы люди), развернется вся ветка! Все поезда на ветке!

Потом. Я не совсем понял, в чем отличие описанного "поезд ищет свободный путь" от PBS? Насколько я понимаю, это оно и есть. Если точнее, то поезд ищет свободный путь и резервирует его, если нашел. Иначе может возникнуть ситуация, когда два поезда нашли свободные пути и поехали по ним, а они пересекаются. Но если резервировать путь, то, судя по описанию PBS, это оно и есть. ))

[Neko]

1) Основывать разработку я бы стал на основе YAPF.
Только необходимо либо самому, а лучше, с помощью самого разработчика этого алгоритма дописать несколько интерфейсных функций, чтобы у нас был бы доступ ко всей цепочке node для выбранного поезда. Такие функции потребуются ещё не раз в совершенно разных патчах, поэтому я и считаю, что эту доработку лучше бы сделал сам автор.
2) Надо очень внимательно просмотреть весь YAPF на предмет, а как он работает со светофорами. Все эти места надо заблокировать, и подсунуть интерфейсы к своим обработчикам.
3) Совершенно полностью очистить игру от других алгоритмов поиска пути. Я уже писал об этом, обработка светофоров тонким слоем размазана по этим алгоритмам и выкорчёвыванию уже не подлежит.
4) Следует подумать ещё над проблемой - а не выделить ли нам более сложные сигнальные блоки (перекрёстки, разводки на станциях) в самостоятельную программную единицу, включив её в тиковый цикл?
Достоинтств у такого варианта очень много, но меня смущает, а не появятся ли сильные тормоза от такого нововведения.

Это самая сложная часть работы, результатом которой мы отделим алгоритм поиска пути от алгоритма работы светофоров, связав их только интерфейсными функциями.
А, уж, на основе этого базиса необходимо будет написать сами обработчики светофоров. И начнётся самое интересное - совершенно не обязательно выбирать только один единственный алгоритм - можно будет перепробовать массу таких алгоритмов, чтобы выбрать наиболее эффективный.

[kraks]

Я думаю, чтобы дело сдвинулось с мертвой точки, надо нам самим решить (составить список), какие интерфейсные функции необходимо выделить: что они должны делать, какие должны быть параметры и какой должен быть результат. Тогда можно будет попробовать закинуть эту удочку на буржуйский форум. Ну а ежели автор не будет заниматься доработкой YAPF, то это нам и самим пригодится, если за него возьмемся.

[Quark]

верно замечено