Информация: Уважаемые посетители! В течение нескольких месяцев на форуме существовала проблема с регистрацией новых пользователей, о которой администрации стало известно недавно. Если вы ранее пытались зарегистрироваться на форуме, но не получили на ваш e-mail письмо с ссылкой для подтверждения регистрации, просим вас зарегистрироваться повторно. Приносим извинения за доставленные неудобства. Если вы все еще испытываете проблемы с регистрацией на форуме, обратитесь за помощью на e-mail: mr.angelo@railroadsim.net

LuaScript - для RS

Другие вопросы и проблемы разработки дополнений

Re: LuaScript - для RS

Сообщение Света » 10.09.2016, 21:17

i2GR писал(а):...Что там реально все портит я не знаю.., ...но особенностью было то, что понятия "спереди" и "сзади" условны. Спереди - это, по крайней мере, был, тот светофор, расстояние до которого уменьшается...
Всё портят две вещи.
1 - Это сообщения, адресованные другому локомотиву, которые он не перехватывают, и, таким образом, достигающие пользовательский локомотив. То, что эти сообщения вообще существуют - это не баг, это, как раз совершенно верная работа светофора. Вот если бы можно было скриптом светофора отличить пользовательский локомотив от бота, тогда это можно было бы исправить. НЯЗ, светофор не умеет различать принадлежность локомотива. Значит надо отсеивать эти сообщения самому локомотиву. Это просто сделать, здесь нет никакой проблемы.
2 - Путаница, возникающая из-за динамически меняющейся индексации "F" и "B". ИМХО, это самое проблемное место 0.6 версии.

На самом деле, с этим тоже можно бороться. Для того, чтобы отсеять светофоры, которые сзади, надо блокировать светофоры, которые отдаляются при движении (понятия "спереди" и "сзади" условны. Спереди - это, по крайней мере, был, тот светофор, расстояние до которого уменьшается.(с)). Для этого есть достаточно простой алгоритм.
Создаются 3 таблицы. 1 - "черный список", 2 - расстояние и 3 - время жизни данных о светофоре. Во всех таблицах ключом является ID светофора. Благодаря этому таблицы синхронизированы между собой.
Входящее сообщение раскладывается на составляющие. Для работы нужны ID светофора, и расстояние до светофора.
Пункты обработки:
1. Обновляется время жизни светофора с этим ID.
2. Проверка, нет ли светофора с таким ID в черном списке. Если есть - просто продолжается его время пребывания в черном списке. Сам сигнал в таком случае не обрабатывается.
3. Если этого светофора нет в черном списке, проверяется, есть ли он вообще в таблице расстояний. Это делается для того, чтобы если это первое упоминание об этом светофоре, то не пропустить его на фильтр до того, как будет выяснено, приближается к нему локомотив или нет. Поэтому, если этот светофор в таблице не числился, то единственное, что происходит - в таблице создается его ячейка и вносится расстояние до него. А если он уже числится в таблице расстояний, то есть возможность проверить, как изменилось соотношение расстояний - если расстояние увеличилось (т.е. локомотив от него отдаляется), то он будет помещен в черный список, а если нет - то сообщение в полном сборе будет передано на фильтр, так как этот светофор впереди локомотива.
На этом сортировка "спереди" - "сзади" почти закончена. Дальше надо определить, кому предназначено это сообщение. Или локомотиву игрока, или боту (ботам) впереди. Этот фильтр я приводить здесь не буду.
Что касается сортировки по "спереди" - "сзади", то остается только прибрать за собой. В первую очередь надо определится с тем, как удалять светофоры из черного списка. Ведь не исключено, что двигаться придется реверсом, а значит информация от заблокированных светофоров уже будет корректной. Кроме того, информация о тех светофорах, мимо которых проследовал локомотив, уже устарела и только захламляет таблицу расстояний. Она уже никак не пригодится. Поэтому нужно проводить очистку:
4. Создается локальная переменная. В ней впоследствии будет ID светофора, который не упоминается за время поступления более, чем 5 сообщений (число с потолка, его можно запросто увеличить).
5. Прогоняется вся таблица времени жизни данных светофора. Каждое число инкрементируется. Когда какое-то из них становится меньше 1, это свидетельствует о том, что светофор не заявлял о себе достаточно давно. Его ID помечается на удаление. Если дальше в таблице окажется ещё один такой светофор (вероятность, очень близкая к 0), то он примет эстафету на удаление на себя. То есть, за цикл может быть удален только 1 светофор. А другой будет удален в следующем цикле. То есть, буквально через мгновение.
6. Если переменная на удаление не равна 0, это значит, что в ней есть ID светофора, от которого перестали приходить сообщения. Во всех таблицах информация об этом светофоре будет удалена.

Фрагмент скрипта, реализующий этот алгоритм:
Код: Выделить всё
   Sig_BL = {} -- черный список
   Sig_CV = {} -- список расстояний для контроля изменения
   Sig_LF = {0} -- время хранения данных сигнала
   
   ID = string.sub(SignMess,11);
   Dist = tonumber(string.sub(SignMess,7,10))

   
function clearing (ID, Dist)
   -- Обработка принятого кода
   Sig_LF[ID] = 5
   if Sig_BL[ID] then
      Sig_BL[ID] = 3
   elseif Sig_CV[ID] then
      if Sig_CV[ID] < Dist then
         Sig_BL[ID] = 3
      else
      --[...фильтр ложных сообщений...]
      end
   else
      Sig_CV[ID] = Dist
   end
   local maxkey = 0
   for k, val in pairs (Sig_LF) do
      if val <= 0 then
         maxkey = k
      else
         Sig_LF[k] = Sig_LF[k]-1
      end
   end
   if maxkey ~= 0 then
      Sig_BL[maxkey] = nil
      Sig_CV[maxkey] = nil
      Sig_LF[maxkey] = nil
   end
end


В функции, принимающей сообщения от светофоров, сообщения с индексом "В" изначально блокируются. Из-за нестабильности индексации это, ИМХО, меньшее зло. Поэтому, в теперешней реализации передачи сообщений светофорами, если применить такой алгоритм сортировки, двигаясь от сигнала реверсом, видеть его код на локомотивном светофорчике не получится... По крайней мере, не сделав аналогичный канал для приема и сортировки "В"-сообщений. С переключением результатов ручкой реверсора. Вот только стоит ли оно того?

*В таблицу черного списка помещается число 3... Также переменная имеет имя maxkey... Никакой мистики, это хвосты после оптимизации кода - многое удалено. Так как в таблицу черного списка можно поместить что угодно, важно само присутствие там ID неправильного светофора, это число не было убрано. Имя переменной в предыдущей версии несло логический смысл. Сейчас нет, но так как эта переменная существует в очень ограниченном пространстве, это не имеет значения.
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение i2GR » 11.09.2016, 02:11

Мудрёно))



Я наблюдаю постоянные сбои при смене БУ. М.б. плохо работает и сама посылка сообщений. Пока не имею возможности проверить.
Сообщение от каждого светофора должно посылаться либо:
а) ближайшему к светофору движущемуся локу бота
б) ближайшему к светофору локу игрока
Как я говорил, если между светофором и локом игрока поставить любой вагончик, РВ его не увидит и будет слать сообщение локу. В этом правильного ноль целых ноль десятых.
Фильтрации по сообщениям спереди/сзади по сути то нет.
Должна быть только начальная инициализация ID светофора "спереди" при загрузке сценария (ориентация самого лока/состава) и затем отслеживание сменившегося ID при движении. Если такого начального ID нет, то при движении им должен стать первый попавшийся ID "спереди".
Аватара пользователя
i2GR
 
Сообщения: 425
Зарегистрирован: 04.09.2008, 16:59
Благодарил (а): 174 раз.
Поблагодарили: 257 раз.
Блог: Просмотр блога (4)
Имя: Игорь

Re: LuaScript - для RS

Сообщение Света » 11.09.2016, 05:58

i2GR
К посылке сообщений претензий нет. Мне не удалось поймать ложное сообщение по статусу светофора. А вот по направлению - да, и не раз. Поэтому я в обработчике не пользуюсь индексами.
Есть претензия к структуре сообщения. Предлагаю прикрепить метку в начале. Чтобы надежно отличать сообщение сигналки от других потенциальных объектов на рельсах.
Предлагаю в коде закрытого сигнала указывать причину (возвращаюсь к старой теме). Светофор знает, почему он закрыт, а локомотив - нет. И потом приходится мудрить с К огнем АЛСН.

а) ближайшему к светофору движущемуся локу бота
б) ближайшему к светофору локу игрока
Другими словами, к проинициализированному ПС.

Как я говорил, если между светофором и локом игрока поставить любой вагончик, РВ его не увидит и будет слать сообщение локу.
Так и есть. Но если к этому вагону подъехать, когда он проинициализируется, он поглотит сообщение. Интересно другое. Дефолтный светофор умеет видеть такой вагон. И при старте сценария, и в процессе игры. Его таблица занятости уверено фиксирует 1. Если въехать на этот БУ, в таблице уже будет 2. Если сцепиться, опять 1. Короче, дефолтный светофор умеет видеть всю картину.

Должна быть только начальная инициализация ID светофора "спереди" при загрузке сценария (ориентация самого лока/состава) и затем отслеживание сменившегося ID при движении.
Вы опять пытаетесь привязать ориентацию светофора к ПС. Зачем? Как светофор отличит локомотив игрока от локомотива АИ? А если будет несколько локомотивов? И на одном пути? Кому дать приоритет в начальной инициализации?

Я считаю, что нельзя привязываться к нестабильным и непредсказуемым факторам. Чем стабильнее исходные данные, тем надежнее система.
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение i2GR » 12.09.2016, 00:35

Надо перенести обсуждение в профильную тему...
F и B как раз светофорные метки.
Я так и не понял, зачем отдельная метка для причины К показания. Что еще нужно знать локу, чтобы отобразить КЖ на АЛСН?
Что имеется ввиду под инициализацией светофора?
Таблицы занятости про то что за светофором. Сцепка / расцепка и у нас учитывается, т.к. светофор так же получает OCCUPATION_INCREMENT / DECREMENT сообщения. Я говорю про то, что перед светофором.
Или я что-то опять не понял, так же как и про начальную инициализацию для ботов и игрока
Аватара пользователя
i2GR
 
Сообщения: 425
Зарегистрирован: 04.09.2008, 16:59
Благодарил (а): 174 раз.
Поблагодарили: 257 раз.
Блог: Просмотр блога (4)
Имя: Игорь

Re: LuaScript - для RS

Сообщение Света » 04.10.2016, 18:32

Всем доброго дня!

У меня вопрос :help: Что значит "угол тени" и "угол полутени" в системном вызове установки/получения данных источника света? Должны ли меняться эти значения при плавном зажигании/гашении мощного источника света? И, если да, по какому закону? Если, к примеру, я меняю яркость прожектора от 0 до полного значения и обратно до 0 по линейному закону, как при этом должны меняться данные угла?

Спасибо.
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение i2GR » 05.10.2016, 03:53

В конфиге это, должно быть, два угла для источника света: Phi и Theta.
Phi должен быть не меньше Pheta и означает "телесный угол" рассеяния света от источника.
Pheta - область полутени внутри угла Phi
Пример:
Изображение
Phi в обоих случаях 60 град.
Theta сверху 40, снизу 60. Т.е. чем меньше этот угол, тем мягче полутень.

В скрипте должны подразумеваться эти углы Phi - Umbra, Theta - Penumbra.
Менять их при включении мощного источника - хорошо, конечно (ИМХО только линейно, потому что происходит все достаточно быстро, хотя надо смотреть по месту), но сделать эффект плавного "розжига" видимого меша источника - та еще задачка.
Аватара пользователя
i2GR
 
Сообщения: 425
Зарегистрирован: 04.09.2008, 16:59
Благодарил (а): 174 раз.
Поблагодарили: 257 раз.
Блог: Просмотр блога (4)
Имя: Игорь

Re: LuaScript - для RS

Сообщение Света » 05.10.2016, 08:56

Судя по скринах, из двух параметров достаточно управлять Thet-ой.
Я тоже склоняюсь к линейному закону, это самый простой вариант, тогда как использование другого закона может не дать видимого эффекта. К сожалению, мне не удается сделать настоящую "ночь" в игровом мире, поэтому трудно визуально определить качество розжига.
В скрипте я могу сделать постепенное нарастание параметра с привязкой ко времени, как при этом будет вести себя пучок света - буду смотреть и экспериментировать.
Спасибо за ответ :cofe:
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение радиомастер » 05.10.2016, 11:04

i2GR
Попробуй конфиг для источника света Head Light . В нем не требуется сама светящаяся меш , а меш присутствует уже в нем . Размеры задаются в конфиге , текстура прописывается там же , но вот яркость ее свечения прямо пропорциональна RGB (который можно менять скриптом по времени) . Если сам свет не нужен - то просто дальность 0 (на светофоре или поворотник на трамвае )
Света
а где ты видела , чтобы на любых реальных фарах менялся угол пучка света ? Его можно использовать только для отключения источника света (хотя проще отключить сам источник света) . А вот типа тусклый-яркий одна и та же лампочка стоит , значит углы одни и те же (один раз настроить в конфиге исходя из реального угла настоящего фонаря ) , а только RGB разный (яркость и цвет), его и менять надо (к тому же если использовать Head Light , то и светящаяся меш автоматом ) хоть плавно , хоть резко .
Аватара пользователя
радиомастер
 
Сообщения: 2078
Зарегистрирован: 23.10.2010, 18:42
Откуда: Макеевка
Благодарил (а): 993 раз.
Поблагодарили: 1506 раз.
Блог: Просмотр блога (3)
Играю в: RailWorks
Роль: Разработчик
Имя: Костик

Re: LuaScript - для RS

Сообщение i2GR » 05.10.2016, 11:19

Костя, совет хороший про Head Light
Но к светофорам не совсем подходит, если конечно вместе с ними GTX1080 не раздавать.
Аватара пользователя
i2GR
 
Сообщения: 425
Зарегистрирован: 04.09.2008, 16:59
Благодарил (а): 174 раз.
Поблагодарили: 257 раз.
Блог: Просмотр блога (4)
Имя: Игорь

Re: LuaScript - для RS

Сообщение радиомастер » 05.10.2016, 12:28

i2GR
Еще как подходит , это такой же направленный источник света как и спот лайт , тормозить не будет если не использовать сам свет (или радиус всего то 1 м для попадания света на проходящий поезд) ,и без теней . Но главное - это собственная мешь , которая может изменяться в размере (настройка размеров от расстояния) и в свете синхронно со светом .Вспомогательные линзы нужно не использовать .Плавный розжиг только так и делать надо .
Аватара пользователя
радиомастер
 
Сообщения: 2078
Зарегистрирован: 23.10.2010, 18:42
Откуда: Макеевка
Благодарил (а): 993 раз.
Поблагодарили: 1506 раз.
Блог: Просмотр блога (3)
Играю в: RailWorks
Роль: Разработчик
Имя: Костик

Re: LuaScript - для RS

Сообщение Света » 05.10.2016, 19:50

радиомастер писал(а):Света
а где ты видела , чтобы на любых реальных фарах менялся угол пучка света ?
Я потому и спрашиваю насчёт этих параметров, потому что мне было трудно представить что это такое. Ну а теперь я по скринах Игоря четко вижу, что угол тени трогать нет смысла (ну, разве что в небольших пределах), а полутень - это как раз то, что обязательно надо изменять, не с нуля, конечно, но с какого-то порога как минимум. Почему? Потому что размытая граница пучка света создается не только источником, а и за счёт отражения. Поэтому, чем выше яркость основного луча, тем шире будут границы. ИМХО. Ну а как это будет выглядеть практически, покажут опыты. Если мне удастся добиться нормальной ночи, чтобы хорошо видеть результат.

радиомастер писал(а):...тормозить не будет если не использовать сам свет (или радиус всего то 1 м для попадания света на проходящий поезд) ,и без теней
Разве при использовании в светофоре бестеневого источника не будет освещаться внутренняя часть кабины или вагона сквозь обшивку?
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение радиомастер » 05.10.2016, 22:12

Света писал(а):Разве при использовании в светофоре бестеневого источника не будет освещаться внутренняя часть кабины или вагона сквозь обшивку?

будет , но так везде в игре , с тенями правильно , но тормоза , без теней - криво . Лично я уже надеюсь только на новую игру
Аватара пользователя
радиомастер
 
Сообщения: 2078
Зарегистрирован: 23.10.2010, 18:42
Откуда: Макеевка
Благодарил (а): 993 раз.
Поблагодарили: 1506 раз.
Блог: Просмотр блога (3)
Играю в: RailWorks
Роль: Разработчик
Имя: Костик

Re: LuaScript - для RS

Сообщение Света » 05.10.2016, 23:10

Ладно, а если схитрить? Сделать 2 источника. Один - бестеневой, другой - его клон, все параметры идентичны, но с тенью. С теми же координатами. В обычном режиме работает бестеневой, просадок fps нет, всё прекрасно. Когда состав находится ближе 5 метров от нулевого линка, т.е. непосредственно у светофора, бестеневой источник отключается, вместо него активируется с тенью. И никаких артефактов в виде просвета обшивки. Проехал состав - источник с тенью снова отключился.
В таком случае на всей карте будет работать одновременно всего несколько источников с тенью и куча бестеневых. И ничего кривого.
Как идея?
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Re: LuaScript - для RS

Сообщение радиомастер » 05.10.2016, 23:14

Тогда проще делать сразу с тенью , но с короткой дистанцией света (1-2 м) , от такого света просадки быть не должно
Аватара пользователя
радиомастер
 
Сообщения: 2078
Зарегистрирован: 23.10.2010, 18:42
Откуда: Макеевка
Благодарил (а): 993 раз.
Поблагодарили: 1506 раз.
Блог: Просмотр блога (3)
Играю в: RailWorks
Роль: Разработчик
Имя: Костик

Re: LuaScript - для RS

Сообщение Света » 11.10.2016, 21:33

Всем доброго дня :)

Представляю вниманию разработчиков скрипт, назначение которого определять положение дополнительных секций локомотивов относительно секции игрока.

Зачем это?
Скриптеры знают, что обмен информацией между единицами ПС происходит пересылкой сообщений. Но у этого метода есть большой недостаток. Если наш локомотив получает сообщение, невозможно определить, на каком расстоянии находится отправитель и есть между локомотивами вагоны или локомотивы имеют прямой контакт.
Этот недостаток может проявится в том, что если сделать передачу, например, температуры масла из второй секции на первую для отображения на термометре, то при штатной сцепке локомотивов система будет работать корректно, а при добавлении вагона между ними (маловероятно) или третьей секции система даст сбой. Например, как определить, из какой секции ловить сообщения, если слать будут обе?
Одно из решений - заблокировать весь набор сообщений обмена в вагонах. Это решило бы проблему, если бы для этого не пришлось перелопатить скрипты всех(!) существующих вагонов.
Эта проблема побудила меня написать скрипт, который помогает определить секции, которые сцеплены с управляющим локомотивом. При этом править сторонние дополнения нет необходимости, так как основным критерием является "физическое" расстояние между секциями.


Подготовка модели
В функциях определения положения применен принцип вычисления расстояний между координатами ключевых точек локомотива. Соответственно, необходимо создать простые дочерние объекты и расположить их спереди и сзади модели.
Идеальный вариант - замки сцепок. На испытаниях использовались координаты лампочек АЛСН, сбоев также не было. Хотя, точность незначительно ухудшается.
Координаты этих элементов и будут использоваться при расчете.

*Желательно, чтобы у сцепленных секций эти элементы находились как можно ближе друг к другу, иначе возможна ошибка, когда измерение произойдет в тот момент, когда они будут в разных тайлах. Событие редкостное, но возможное.


Подключение скрипта
Файл "LOCOMOTIVES_LOCATION" размещается в папке Engine дополнения. В основном скрипте в функции Initialise необходимо сделать ссылку:
Код: Выделить всё
   require ("Assets/[...]/Engine/"LOCOMOTIVES_LOCATION.lua")

Если используется скомпилированный файл, .lua заменяется на .out.

Для инициализации скрипта в функции Initialise создается вызов:
Код: Выделить всё
   SetupControlLink ()


Также необходимо заменить имена дочерних элементов на имеющиеся у Вашей модели:
Код: Выделить всё
      XF, _, YF = Call("1-pointlight_alsn-white-l:getNearPosition")
      XR, _, YR = Call("2-pointlight_alsn-white-r:getNearPosition")

Соответственно "1-pointlight_alsn-white-l" заменить на дочерний элемент, расположенный спереди, а "2-pointlight_alsn-white-r" - сзади.

Для получения нужных данных добавляем обработчик сообщений в OnConsistMessage ( msg, argument, direction ):
Код: Выделить всё
function OnConsistMessage ( msg, argument, direction )
   if msg == POSITION_DATA then
      ControlLink ("Update", argument)
      return
   end
end


Ну и надо передавать свои данные. Для этого я использую проверку длины состава - ведь это значение меняется при сцепке/расцепке, этого момента вполне достаточно, чтобы составить схему состава, которая не изменится пока снова не прицепить/отцепить что-нибудь. Нет смысла делать эти замеры чаще:
Код: Выделить всё
function Update ( time )
   local Length = Call("GetConsistLength")
   if Length ~= prevLength then
      prevLength = Length
      ControlLink ("Update")
   end
end

*Переменную prevLength необходимо проинициализировать в функции Initialise ()


Использование
Управляющие коды для LOCOMOTIVES_LOCATION:
Код: Выделить всё
   ControlLink ("Update")

Обновление. По этой команде обновится таблица координат для локомотива и эта информация будет отправлена другим ПС, которые также обновят свои таблицы. Все данные будут пересчитаны. Ради экономии ресурсов злоупотреблять этой командой не рекомендую.

Код: Выделить всё
   ControlLink ("Update", argument)

Обновление, но без рассылки. Команда предназначена для установки в функцию OnConsistMessage ( msg, argument, direction ) (описано выше) и рассчитана на прием отформатированных данных. Поэтому в других местах не используется.

Код: Выделить всё
   ControlLink ("GetLocoPosition", data)

Самая ходовая команда. Передается имя ПС, расположение которого надо определить. Именем является № ПС, заданный в свойствах сценария.
Результатом выполнения этой команды будет возврат 1 из 5 возможных ответов:
- false - если проверяемый ПС не сцеплен с нашим, ответ будет такой;
- ff - этот ответ означает, что локомотивы сцеплены передними частями;
- fr - перед нашего локомотива сцеплен с задом проверяемого;
- rf - зад нашего локомотива сцеплен с передом проверяемого;
- rr - локомотивы сцеплены штатно.
Например, если надо проверить, принимать или нет информацию от ПС, передавшего данные о температуре и свое имя (ID), проверка выглядит так:
Код: Выделить всё
      if ControlLink ("GetLocoPosition", "ID") == "rr" then
         -- Да, данные температуры можно использовать
      else
         -- Нет, ПС или далеко (не сцеплен с нашим локомотивом) или ориентирован неправильно
      end

Естественно, для правильной работы ПС, передающий данные температуры должен передать и своё имя, которое надо отделить.


В настройках заданы константы:
Код: Выделить всё
-- Constants
   POSITION_DATA = 1818190202
   MAX_DISTANSE = 10

POSITION_DATA - это метка сообщения обмена, которое инициирует запуск определителя. На данный момент не является стандартизированным.
MAX_DISTANSE - это максимальное расстояние. Если расстояние между самыми близкими точками ПС превышает это число, принимается решение, что эти ПС не сцеплены. Число "10" выбрано исходя из соображений, что длина самого короткого вагона больше 10 метров.

Скрипт оттестирован. Тем не менее, приветствуется информация по результатах практического применения этого кода :)
Аватара пользователя
Света
 
Сообщения: 154
Зарегистрирован: 18.06.2016, 19:38
Благодарил (а): 77 раз.
Поблагодарили: 174 раз.
Играю в: RailWorks
Роль: Разработчик

Пред.След.

Вернуться в [RW] Другие вопросы

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1