Теперь по существу.
"Петлю" которую я сделал
через танцы с бубнами здесь нужно
придрочиться использовать очень осторожно. "Считалка" работает, но работает очень не стабильно, с разной скоростью при разных условиях. Я не могу понять от чего именно она зависит с точки зрения маршрута. То есть, понятно, что её скорость зависит от скорости "прогона" программы, но вот, отчего зависит сам "прогон" - я не пойму. На маленьком двухтайловом тестовом маршруте оно у меня "летает": чтобы получить 20 секунд я устанавливал 400. О своём "тяжелом" маршруте я писал в приведенном мной сейчас посте. Разница может быть в ФПС, количестве светофоров "на тайл", в общем количестве светофоров - я не могу знать. Кроме того, оно раз на раз срабатывает, или не срабатывает, или частично срабатывает и во время загрузки. Я пихаю его сейчас в качестве "компенсатора" timing trigger, который 100% не учитывается при загрузке игры. Логика такая: проверяю check_timing_trigger (1 секунда). Если результата нет - триггер не работает, значит игра загружается - обход условия. Если есть результат - игра идёт. Логическим элементом "и" добавляю к этому check_timing_trigger (нужное количество секунд для задержки открытия светофора) в условие (if) и получаю желаемый обход триггера при загрузке игры. Далее проблема заключается в том, что если в зависимость поставить только это - в эту самую первую секунду отсчёта триггера, сигнал открывается и сразу же перекрывается обратно. Но, и игрок и трафик в этот момент ловят ok to proceed ... и трафик поехал к светофору. Потому, чтобы задержать светофор в запрещающем аспекте эту самую секунду, пока не будет "взведен" триггер, я пихаю в условие через "или" эту
порнографию свою петлю. Но, она тоже глючит при загрузке (на тестовом я сделал аналог for - 2 условия: начальное и конечное, поднимая значение с 0 до 7 - из-за табло, чтобы видеть, так, как в примере - "улетает"
нахрен вверх или вниз, я и так и так "крутил... так вот, на тестовом при начале игры стоит AI перед сигналом, а переменная эта добежала с нуля до 5 и держится, а уже в игре доходит до своих 7). Потому сделал ей "контр-петлю", которая вообще не обнуляется - игра пошла - она 7 и всё. В условие её через "и" к первой петле, как "противовес". Смысл - расчет на то, что одинаковые петли и глючить будут одинаково. Есть глюк - контр-петля не дошла до семи - условие обходится и светофор (невидимо при загрузке) переключается, нет глюка - не страшно - оба условия выполняются и светофор будет открыт с задержкой в 7 "тактов". Сейчас тестирую загрузки Timetable в разных точках с этим механизмом - вроде, все тестовые светофоры не "заклинивает".
Добавлено через 50 минут
Цитата:
Сообщение от КЕ
То есть если на аспект RESTRICTING прописать 0 км/ч - не получится? Я вроде тестировал, но результата не помню. Надо будет еще раз проверить.
С остальными показаниями для ПАБ проще - сигнальная точка из одной головы DISTANCE и нескольких NORMAL, каждая из которых имеет 2 аспекта - 0 и 2, и свою скорость - "открывается" при соответствующем DISTANCE-коде в РЦ. И регулирует скорость сервисов.
|
Попробуй. STOP_AND_PROCEED не "держит" с 0. Но с RESTRICTING может быть исключение, "унаследованное" каким-либо образом из MSTS - если разрабы не разобрались или упустили момент что в MSTS только этот аспект заставлял AI слушаться speedkph в конфигурации. Но, с моей точки зрения, проблема не только и не столько в наличии или отсутствии остановки, а в том, что в MSTS AI не только останавливался на STOP_AND_PROCEED со скоростью 0, такой сигнал там блокировался Deadlock -ом. Чего в Open Rails не происходит. Даже если случится чудо и RESTRICTING будет останавливать AI, будет ли поездная ситуация разруливаться Deadlock на такой сигнал?