RailUnion.net

Максим, и ты расслабься. Я тебя и твой код не "критиковал", а просто указал на ошибку

Нитка Updаtе обновлюется автоматически? Например в ТРС такая нить обновлялась ежекадрово.

В RW аналогично!
Ребят, зачем вы по__ались в комментах из-за того, что прекрасно описано в RSDevDoc 3.02 или на RW-wiki
Rokky, советую читать там. Там все описано системно и с норамльными примерами: какие функции должны содержаться в скрипте, какая из них за что отвечает, и как они взаимодействуют. Конечно есть нюансы, которые с первого раза не разберешь, но это вопрос личного отпыта.

Как использовать OnConsistMessage? Например: есть пантограф и его анимация в скрипте выглядит так

Код: Выделить всё

Call("*:AddTime", "frontPnt",  15); --поднят
Call("*:AddTime", "frontPnt",  -15); --опущен
Call( "*:GetControlValue", "tm_tpoff4", 0 ) тумблер токоприёмника

так вот, как послать сообщение задней секции чтобы там ТП работал? Не могу понять для чего нужно это PANTO_MSID = 1207, точнее числовая составляющая этого параметра. Не хочется Aplly to consist из блюпринта, так как есть возможность реализации посекционной работы локомотива.

Покопавшись в скриптах Acell`ы, нашёл такую шнягу:

Код: Выделить всё

function Initialise ()
PANTO_MSID = 1207
end

function Update (time)
if (Call( "GetIsEngineWithKey") == 1) then   
   msg = PANTO_MSID
   argument = argument = Call( "*:GetControlValue", "PantographControl", 0 )
   Call( "SendConsistMessage", msg, argument, 0 )
   Call( "SendConsistMessage", msg, argument, 1 )
end -- of pantograph control
end

function OnConsistMessage ( msg, argument, direction )
if (Call( "GetIsEngineWithKey") == 0) then
if msg == PANTO_MSID then
   Call( "*:SetControlValue", "PantographControl", 0, argument  )
   Call( "SendConsistMessage", msg, argument, direction )
end
end
end


Объясните, пожалуйста, уже битый час голову ломаю, никак не догоню.

PANTO_MSID = 1207 - это идентификатор сообщения. Цифры ничего конкретного не обозначают - каждый сам решает какой ID дать. По части скриптов сигалки - там определенные ID зарезервированы, о опять же в рамках одной системы сигнализации. Всё условно короче.
Message ID нужен для того чтобы обозначать тип сообщения. Это как поле "тема" в email-письмах, например в данном скрипте сообщения с ID=1207 используются для передачи по составу состояния токоприемника. А в состае есть другой ПС, который в своем скрипте может иметь событие OnConsistMessage, которое в качестве аргументов принимает параметры сообщения. Внутри того события мы смотрим - если ID сообщения какой надо, то мы делаем то что положено (смотрим в текст сообщения, там написано - поднять или опустить токоприемник, этим и занимаемся дальше по тексту скрипта). Если Message ID например другой, там какой-нибудь 2233, и мы его например зарезервировали для передачи давления ТЦ по составу (чтобы анимировать тормозную передачу), то сответствено уже обработкой занимается другая часть скрипта. Если какой-то левый Message ID - ничего не делаем например.

Т.е. адресная система передачи команд в чистом виде .

Нет не адресная. Послать месседж конкретному юниту в составе нельзя. Месседж можно передать просто от одного юнита к следующему - в том или другом направлении. А вот если следующий юнит имеет в своем скрипте "ретранслятор" (пару строчек, которые по-умолчанию все подряд сообщения пересылают в том же направлении, в каком оно к ним пришло), то сообщение уйдет дальше, к следующему юниту. Заинтересованный в определенного рода сообщених юнит отлавливает их по Message ID.

Я это и имел в виду .

Mr. Angelo писал(а):Месседж можно передать просто от одного юнита к следующему - в том или другом направлении. А вот если следующий юнит имеет в своем скрипте "ретранслятор", то сообщение уйдет дальше, к следующему юниту.

Если в скрипте [управления тормозами] перед "ретранслятором" добавить паузу (длина вагона / 340 м/с) то можно получить эффект "тормозной волны".

MJack писал(а):Если в скрипте [управления тормозами] перед "ретранслятором" добавить паузу (длина вагона / 340 м/с) то можно получить эффект "тормозной волны".

Не совсем так. Тормоза - как работали так и работают, вмешаться в их работу из скрипта нельзя. А с помощью сообщений, в приведенном мною примере, передается только условный параметр "давление ТЦ" для того, чтобы анимировать тормозную передачу на каждом вагоне.

Можно ли рассчитать скорость проигрывания анимации через эту функцию Call("*:AddTime", "frontPnt", pnt1*15 );? В данном случае пант прыгает сразу на 15-тый кадр анимации без прохождения всей линейки. Пробовал я делать расчёт и поднимать его с нуля, но как-то быстро он взлетел, как-будто расчёт за секунду произошёл. pnt1 это переменная, которая принимает значения 1 и -1, в зависимости от включения тумблеров, 15 это количество кадров анимации. Не знаю как получить текущий кадр анимации.

Можно было бы не делать того что выше, но при использовании этой функции, в нитке Update, Call( "*:SetControlValue", "pantcontr, 0, pnt1 ); токоприёмник начинает подниматься - опускаться сам по себе, то есть, анимация проигрывается бесконечно по кругу. Здесь он прописан как внешняя анимация и повешен на тумблер, который управляется через скрипт. Если убрать из нитки Апдейт, то анимация не работает. Поэтому пришлось воткнуть эту функцию в Update.

В общем я в тупике, оставлю первый вариант и продолжу скриптовку дальше. Но хотелось бы увидеть ответы профи в скриптовании.

Зачем такое городить? Надо токоприемник привязать к Control Values-у (конфиговая переменная) который будет иметь MIN 0 MAX 1, назвать например PantoState1 (отдельные для каждого токоприемника на секции), тип внешней анимации поставить Toggle. Скорость подъема будет зависеть от длины самой анимации в МАХе. Анимация должна быть только в одну сторону - от сложенного положения к поднятому. В этот PantoState1 будем писать 0 или 1 через SetControlValue.

Дима, ты рано полез в скриптовые дебри. Сами по себе возможности настройки конфига могут сделать некоторые фишки без всяких скриптов. Либо со скриптом, но коротким. А то, куда ты сейчас решил двинутся грозит тоннами "индусского кода".

Добавлено спустя 9 минут 50 секунд:
Собственно то что я описал, это стандартный способ анимации токоприемника, с той лишь разницей что анимацию мы вешаем не на стандартный Control Value, на который реагирует игра, а на другой. И скрипт нам нужен для чего? Для того чтобы между нажатием кнопки "токоприемник 1" (условно) и поднятием самого токоприемника проверить какие то условия - к примеру включени ли тумблер "токоприемники" (проверяем какое значение в Control Value этого тумблера, если 1 - значит включен, тогда и отдаем команду понднять токоприемник. ).

Mr. Angelo писал(а):Зачем такое городить? Надо токоприемник привязать к Control Values-у, тип внешней анимации поставить Toggle. Скорость подъема будет зависеть от длины самой анимации в МАХе.

Делал так, но ТП поднимается и спустя некоторое время опускается (просто опускается, независимо ни от чего) и я не знаю как это победить. Поэтому пришлось пару костылей вбить.

Добавлено спустя 3 минуты 18 секунд:

Mr. Angelo писал(а):Собственно то что я описал, это стандартный способ анимации токоприемника, с той лишь разницей что анимацию мы вешаем не на стандартный Control Value, на который реагирует игра, а на другой. И скрипт нам нужен для чего? Для того чтобы между нажатием кнопки "токоприемник 1" (условно) и поднятием самого токоприемника проверить какие то условия - к примеру включени ли тумблер "токоприемники" (проверяем какое значение в Control Value этого тумблера, если 1 - значит включен, тогда и отдаем команду понднять токоприемник. ).

Это примерно так и выглядит. Но проблема то в том, что он сам опускается.

И как бы вот на этом принципе и строится вся кастомизация поведения органов управления локомотива. Если по дефолту контроллер напрямую привязан к визуальной рукоятке в кабине и кнопка клавиатуры, то в нашем случае мы создаем Псевдо-контроллер, у которого своя собственная переменная (Control Value), и именно к нему переназначаем визуальную рукоятку в кабине и кнопки клавы. И уже с помощью скрипта можем немного вмешаться в поведение. Типа пытаемся сдвинуть контроллер (точнее псевдо-контроллер), проверяем скриптом - находится ли реверсивка в рабочем положении, если нет - то не передаем никакого нового значения в реальный контроллер (к которому теперь у нас нет доступа ни мышкой ни клавой, он как бы не видим, это просто переменная на которую реагирует игра), а если реверсивка в рабочем полжении - копируем значение переменной псевдо-контроллера в реальный контроллер.

А насчет стандартной реализации анимации токоприемника - глянь файлы-примеры, там есть Sample Electric Engine.

P.S. А то что сам опускается, если ты делал тип анимации Toggle - то максимальное значение переменной должно быть ровно 1, если больше - то анимация как раз и будет сбрасываться на начальное положение.

Mr. Angelo писал(а):А насчет стандартной реализации анимации токоприемника - глянь файлы-примеры, там есть Sample Electric Engine.

Смотрел, делал так же, но без результата. Там пант тупо завязан на кнопку, у меня же пантографами управляют 3 тумблера, 1 общий только на опускание и 2 на опускание/поднимание.

Mr. Angelo писал(а):P.S. А то что сам опускается, если ты делал тип анимации Toggle - то максимальное значение переменной должно быть ровно 1, если больше - то анимация как раз и будет сбрасываться на начальное положение.

Спасибо за подсказку, теперь хоть отправная точка есть, проще искать косяк будет.