Правило перевода стрелок в определенное время (работает с правилом UZ Timecheck)
Создание сессий. Идеи, проблемы, решения.
Правило перевода стрелок в определенное время (работает с правилом UZ Timecheck)
аурановцы предполагают, что зависимые правила будут выполняться одно за другим. То есть один поезд наехал на триггер - сработало первое зависимое правило, второй поезд наехал - сработало второе, и т.д. При этом никаких ожиданий завершения того правила, которое было до него, не ведётся, оно выполняется сразу, как только вызвано срабатывание последнего дочернего правила. Галочка видимо требует, что дочерние правила выполняются строго после завершения предыдущих, и основное правило завершается после завершения последнего дочернего.Сообщение от NickLon
Но это приблизительно, более точно надо скрипт смотреть.
потому что аурановцы считают, что правила не должны сохраняться и вызывать дочерние правила только однократно.
Плохо, что они так считают, могли бы добавить возможность в качестве дочернего выполниться сколько угодно раз, что как раз и делают правила, о которых я говорил, но, увы, оно их не слушается. Хорошо хоть переменные могут выполняться неоднократно, за счёт них много удаётся решить.
Разъясните работу правила User Disruption Of Schedule. Как я понял, правило срабатывает по условиям времени, которые мы выставили, и при наезде на триггер проверяет заданное условие. То есть, в моём случае каждый раз при наезде на любой из триггеров, если игрок опоздал по времени, дождавшись остановки поезда отнимает от переменной n-ое количество и выводит html-сообщение. Но у меня оно начинает выполняться бесконечное число раз, даже если поезд покинул радиус действия триггера. Остановись в любом месте карты - оно выполнится.
Аналогично и с этим вариантом:
Галка означает, что дочерние правила выполнятся даже после освобождения триггера составом. На самом деле в этом режиме правило не ждёт, пока дочерние выполнятся, а просто однократно их активирует и больше не работает.
Если галки нет, после освобождения триггера правило сбрасывает активацию дочерних правил, то есть они могут выполняться только когда triggercheck активен.
Оно может срабатывать многократно, скорее всего проблема в чём-то другом. Я, к примеру, с его помощью счётчики делаю:
---------- Сообщение добавлено в 21:52 ---------- Предыдущее сообщение размещено в 21:44 ----------
Оно тут, скорее всего, не при чём. Поставь в правиле Wait on train stop/start галку "trigger rule once" (срабатывать однократно).
Оба-на! Так вот, что это было, когда я как-то заметил, что у меня правило Wait не работает...
Это серьёзная проблема для построителей сценариев (сессий), я думаю!
TRam_, мы можем "своими силами" это решить?..
... Более того! Сейчас потратив пару десятков минут на тесты, я увидел, что на карте БАМ, станция Таксимо правило Wait вообще не работает! Я поставил триггер, в зависимость от чек триггер правила поставил wait, а в зависимость от wait - изменение переменной. Переменная не менялась. Убирал wait - всё менялось. Интересно, этот полтергейст от Аурана как-то разумно можно объяснить?.. Хм, более того! Я что-то в списке CM вообще не вижу объекта типа правило с названием "Wait".
М-да, кенгурятники продолжают удивлять. А ещё за TANE взялись. Два года, кстати, сплошных косяков.
---------- Сообщение добавлено в 22:21 ---------- Предыдущее сообщение размещено в 22:11 ----------
Ant.taranish, чего!? Чего-то я совсем уже не въехал.
То есть, ещё и отслеживается событие освобождение триггера составом? Это что за хрень такая и в каком угаре её придумали?
Ну и таким образом, что такое "сбрасывает активацию дочерних правил" и в как триггерчек может быть активен или не активен в каком-либо промежутке времени? Насколько я понимал это до нынешнего момента, триггерчек сработал - и всё. Дальше уже происходят события, которые за ним их построишь. А что означает "освобождение триггера", активен триггерчек - это вообще какой-то маразм.
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
Событие выезда состава из радиуса действия триггера, если выражаться точнее
При опции "ждать выполнения дочерних правил" так оно и происходит. А если эта опция не выбрана, то дочерние выполняются только пока состав находится в радиусе действия триггера. Если они выполняются сразу, то разницы особой конечно не будет. Но если у тебя в подчинении правило "ждать остановки поезда", а поезд проедет триггер и остановится за радиусом его действия, то правило ожидания не выполнится и не активирует свои дочерние правила.
Ааа...Так вот как оно работает, т.е. переменные будут срабатывать только через каждые 60с.? А я у себя засунул их в дочерние...
Поставил, но оно, как и было задумано, сработало только один раз, при наезде на следующий триггер ничего не произошло.
Не хочется громоздить кучу правил для каждого триггера, если условия времени разные, а действия для всех одно. Нельзя ли сделать, чтоб правило выполнялось пока мы находимся в радиусе действия триггера? Или при наезде на каждый из списка триггеров, выполнялось только 1 раз?
Ant.taranish, ну теперь то я уже понял. Вот, блин, век живи - век учись. Ни за что бы сам не догадался. А теперь мне интересно, а для чего может понадобится вариант, когда нужно оборвать выполнение дочерних правил, если поезд вышел из зоны действия триггера?
Теперь бы ещё правило Wait докрутить до ума. А то фигня какая-то - ставить правило в список, чтобы оно сработало всего-лишь один раз за сессию. А вот эту конструкция, что ты показал на скрине я тоже как-то делал. Только не счетчик, у меня так подталкивание на трудных участках БАМа организовано было. Да и будет.
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
Потестировал, результат неутешителен:
- правило активирует дочерние правила однократно, то есть при повторном наезде на триггер ничего не происходит
- само никогда не завершается (нельзя использовать с Ordered list)
Другими словами, работает одноразово - "до первого опоздания".
Это правило тоже активирует дочерние однократно, но оно по крайней мере завершается после их активации, и можно выкрутиться, поставив дочернее правило следующим по очереди в конструкции с Ordered list.
Ant.taranish, ну, понятно, что помощи теперь ждать только от наших гуру. Если они допилят это правило (Вова правила со своей доработкой как-то выпускал), тогда и будем наслаждаться. А пока только пожимаем плечами в недоумении в ответ на логику программистов Ауран.
Иногда мы принимаем такие решения, которым тараканы в голове аплодируют стоя.
Если ещё выставить "время отступления" по опережению въезда, например 1 мин, а время выставить, например, 16:10, то правило будет срабатывать только в диапазоне 16:10 - 16:11, то есть прибыв раньше 16:10 ничего не произойдет. Так задумано или мне показалось?
Я тут подумал и понял, что правило Wait правильно сделали, что так задумали. Я в этом вижу свои плюсы.
Объясните ещё работу правила Progressive List. Не совсем понятно, при каких обстоятельствах его нужно использовать. И, как я понял, первое правило завершится после выполнения дочерних? Само правило имеет несколько режимов работы. Вот, выдернул из конфига:
После завершения всего цикла, первое снова выполнится только один раз? Или начнётся далее по цепочке?1. После успешного выполнения последнего подправила будет снова выполнено первое подправило.
По достижении последнего правила, если снова правило выполнится, то срабатывать всегда будет только последнее?2. После успешного достижения последнего подправила оно будет использовано для всех последующих запусков правила.
Вот его как раз и нужно ставить либо первым, либо последним?3. При первом запуске сначала будет выполнено первое подправило, далее - последовательно.
Ваши права
Ответить с цитированием
