Jump to content

Разработка нового скрипта для переездов


У нашего проекта в планах выпустить изменение/исправление скрипта для переездов. В чем суть: будет изменен алгоритм активации и деактивации поездом переезда. В данный момент почти на всех маршрутах используется не самая удачная и оптимальная схема поиска поезда. Как сейчас это происходит? На путь устанавливается маркер и в его свойствах указывается расстояние, на котором он может "видеть" поезд. Причем это расстояние идет в обе стороны симметрично, т.е. если указать 500 метров, то поезд будет улавливаться за 500 метров до маркера и уходить из зоны улавливания после 500 м, когда проедет это расстояние последним вагоном. Для двухпутных перегонов, чтобы открытие переезда происходило через ~100 метров после прохода последнего вагона, приходилось увеличивать диапазон маркера и сдвигать его намного вперед. В случае, если поезд двигается по неправильному пути, то закрытие переезда происходило за 100 метров, что естественно, не нормально. Если поставить такой маркер на самом переезде, то тогда закрытие его будет происходить на том же расстояние, что и открытие. И это тоже не реалистично. В случае однопутных перегонов - то же самое. Маркер приходится ставить только рядом с переездом. Сразу два маркера поставить нельзя, поскольку поиск поезда осуществляется в обе стороны.

Обо всем это можно увидеть в одном из наших старых видео уроков, который делался еще для TRS12. однако маркеры до сих пор используются те же самые.

До появления текущего (обсуждаемого выше) скрипта переездов существовал другой тип скрипта - более старый, еще во времена z7. В нем как раз-таки можно было указывать направление поиска поезда. Но почему-то тот вариант не получил дальнейшего развития.

Очень важный момент, который мы заметили еще во время активного использования TRS12. Если включить мониторинг ресурсов на маршруте, то в плане нагрузки на скриптовую часть игры можно было видеть, что именно скрипт переезда съедает больше всего производительности. Представьте себе, что на маршруте от 100 км располагаются несколько десяток переездов, на каждом из них в среднем по два маркера, а кое-где и больше. Каждый маркер в своем скрипте постоянно мониторит путь впереди и позади себя, нагружая движок игры. А если разамер маршрута еще больше?! Это можно заметить, если даже в редакторе (касается преимущественно более ранних билдов) при установке ПС на путь с переездом маркер определял закрытие сразу же. То есть не по событию входа поезда в зону действия, а просто по факту постоянного мониторинга, который каждую секунду сканирует путь. Посему нужно отказаться от мониторинга пути и отправлять данные о необходимости открытия и закрытия переезда только по событию входа/выхода поезда из точки активации переезда.

Скорее всего для ограждения переезда понадобится более одного маркера на путь. Возможно, их должно быть 4 для каждого пути: по два в каждую сторону, из которых один маркер активирует переезд, а другой - деактивирует.

Что касается взаимодействия скрипта с инфраструктурой переезда - само пересечение автодороги с путями, переездные светофоры, шлагбаумы, барьеры и т.д. - все это может оставаться без изменений, так как будет просто получать команду закрыть/открыть от нового скрипта, так же, как и получало от старого. Вся совместимость будет сохранена.

7 Comments


Recommended Comments

  • Client 2nd level
medenlin

Posted (edited)

А как в таком случае будет определяться "внезапное" появление поезда перед переездом? Например, если переезд в горловине станции, и поезду собрался маршрут на отправление через эту горловину?

И так же, как будет разруливаться обратная ситуация - например, если маркер на закрытие расположен на перегоне до станции, а поезд прибывает на закрытый сигнал и отправится дальше к переезду не скоро... Наверное, придется в таком случае еще и с сигналкой это как-то завязывать?

Edited by medenlin
  • Administrator
Ilyon

Posted

@medenlin а в чем там "внезапность"? Как только поезд попадет в зону действия группы маркеров, переезд закроется. Как раз-таки в существующих маркерах такое и возможно, поэтому нужно уйти от подобного.

  • Client 2nd level
medenlin

Posted

Так все таки новые маркеры будут так же постоянно сканировать свою область действия на наличие поезда (тогда чем они отличаются от старых), или срабатывать только при пересечении?  Что то я не понял...

  • Administrator
Ilyon

Posted

@medenlin наоборот, не будет. Мы от этого и хотим избавиться. На мониторинг тратится много ресурсов игры и нужно уходить от этого. Мы хотим перейти на принцип "датчиков" входа и выхода поезд из/в зоны перекрытия переезда. Т.е. пока поезд не зачекался на датчике входа, никакого мониторинга нету. Скрипт не будет постоянно проверять занятость пути. Датчик работает по принципу триггера, а сам триггер ничего не ждет, но сработает на поезде и передаст информацию, что контролируемый участок занят. Такой же контроль будет происходить на выходе из зоны переезда. Зарегистрированный ранее на входе поезд обрабатывается триггером/маркером уже на выходе - и переезд открывается.

acked2018

Posted

Что-то тишина в теме про эти переезды. Заброшено или как?

  • Administrator
Ilyon

Posted

@acked2018 не заброшено, просто поставлено в очередь.

  • Sponsor
Siarhei Mazanik

Posted

Да, Илья, по возможности выложи мануал по установке и настройке этих замечательных переездов.

Guest
Add a comment...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

To continue you must agree to our Terms of Use.