RailUnion.net

Этот энджинспек Саша переписал (позиции контроллера точно...для скрипта) так что все вопросы к нему...

Создавайте. А вот по enginespec-у Jam'a есть вопрос - прописал к вагонам, так они теперь сначала еле-ползут, а потом разгоняются до больших скоростей (250 км/ч - не предел) и продолжают набирать скорость.

Не имею привычки ездить в метро больше 78км\ч.

У тебя АРС не даст больше 80ти;-))) а у них по кругу наверное гоняет вот и взлетит скоро... 200-220-250-280-отрыв:-)))
Кстати... если не подтвердить КБ торможение от АРС, то после остановки паравоза едет задом;-))) исправить реально?

Кстати... если не подтвердить КБ торможение от АРС, то после остановки паравоза едет задом;-))) исправить реально?

Через 7сек в реале сработает ЭПК и покатушки закончатся. Исправлять не буду.

прописал к вагонам, так они теперь сначала еле-ползут, а потом разгоняются до больших скоростей (250 км/ч - не предел) и продолжают набирать скорость.

Из-за этого я использую Enginespec от дефолтного тепловоза F8. Разгоняется нормально, и на горки взлетает ласточкой.

если не подтвердить КБ торможение от АРС, то после остановки паравоза едет задом;-)))

Да, это я тоже замечал. С энжином F8 какого нет.

У тебя АРС не даст больше 80ти;-))) а у них по кругу наверное гоняет вот и взлетит скоро... 200-220-250-280-отрыв:-)))

Перекрываем кран ЭПК, нажимаем КБ, отключаем тумблер АРС, и полетели...

Да, это я тоже замечал. С энжином F8 какого нет.

Это не от энжина зависит. Скрипт я писал под себя, поэтому он не расчитан на извращения, а после остановки вагона в силу некоторых математических причин сила торможения (а, напомню, торможение сделано не эжинспеком) становится отрицательной.

А звуками из МСТС не поделитесь? Я конечно пока временно убрал из скрипта все "world.playsound(...)" (или что-то в таком духе), но хотелось бы слышать звуки. И ещё вопрос - прописал конфиг, добавил скрипт, порядок позиций на контроллере стал таким (снизу вверх): Х3, Х2, Х1, 0, Т1, Т2, Т3 (уж извините, если где напутал), вроде же это наоборот, надо Т3, Т2, Т1, 0, Х1, Х2, Х3; а то непривычно дёргать контроллер на себя, чтобы поехать вперёд. Так вот, не подскажете, что надо исправить в конфиге throttle_lever2, чтобы изменить порядок? Мешь контроллера я использую ту, что была в папке с кабиной (81-717 Interior).

в строке limits попробуй поменять числа местами, может поможет...

После серии эксперементов, установлены правильные параметры:

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

throttle_lever2
  {
    kind                                "lever"
    auto-create                         1
    mesh                                "throttle_lever.im"
    att                                 "a.throttle_lever"
    limits                              -3,3
    angles                              -0.5,0.6
    notches                             1,0.8333,0.6667,0.5,0.3333,0.16667,0
    notchheight                         1,2,2,1,2,2,1
    radius                              0.3
    att-parent                          "default"
    mousespeed                          0.3
  }

Итак, попытка начать писать скрипт номер N, собираем всё в кучу. Если чего уже было - извеняйте, значит плохо читал.

Имеется КВ. 4 ходовые позиции, 0 и 5 тормозных. Соответственно, нужно скриптом менять dynamic-brake и throttle.
Вопрос, кто - Кабина или локомотив? Лично я думаю, что локомотив, т.к. при управлении снаружи скрипт кабины не активен.
Далее, передача данных кабина - локомотив. Я так понимаю, есть 2 способа: CabinData и мессаджи. Что лучше и почему?

Аурановцы рекомендуют CabinData (иначе бы не делали). Месседжи требуют время на дешифровку, так же как и Soup'ы

при управлении снаружи скрипт кабины не активен

активен. Скрипт кабины перестаёт быть активным, когда перелазишь в соседний вагон (или другой поезд). Я тоже думаю, что лок. Но => надо организовывать взаимодействие между головой и хвостом (а то вдруг голова тянет по-своему, а хвост - по-своему )

Ну, допустим, СМЕ я беру на себя. Тогда вопрос про передачу данных.

Как я понял, при дёргании ручки мы упаковываем новое значение в CabinData и вызываем loc.SetCabinData(cd); Так? Но ведь тогда получается, что локу придётся перелопачивать весь КабинДата на предмет обнавлений!
Про обратную связь спрашивать пока не буду, а вот про ботов спрошу ещё раз. Как боты управляют составом? Уж наверно дефолтными ручками? (а то и вообще ДЦЦ) Соответственно нужен какой-то алгоритм перевода значений дефолтных ручек к нашим. Или не нужен? Выше описано только про перевод наших в дефолтные...

Имеется КВ. 4 ходовые позиции, 0 и 5 тормозных.

Мы о номерном говорим? Тогда три на ход и три на тормоз.

Я так понимаю, есть 2 способа: CabinData и мессаджи. Что лучше и почему?

Месседжи, СД, супы и прямой вызов метода локомотива и доступ к его полям.

Как боты управляют составом?

ДЦЦ.

СД и прямой вызов метода

CД - один из примеров прямого вызова метода

Уж наверно дефолтными ручками?

не, врядли. Либо "ручками+SetVelocity", либо просто "SetVelocity"

при дёргании ручки мы упаковываем новое значение в CabinData и вызываем loc.SetCabinData(cd); Так? Но ведь тогда получается, что локу придётся перелопачивать весь КабинДата на предмет обнавлений!

да. Можно конечно сделать свой двухпараметрический класс (string <имя свойства>, int <положение>), и методы по его приёму/получению в локомотиве аналогично CabinData. И тогда будет обновление только одного параметра.

А обратную связь делать через Update кабины, причём можно сделать обновление "1 раз за 3 Update" - тогда глючность уменьшается

CД - один из примеров прямого вызова метода

Во всяком случае, мне в ВЛ10 было удобнее вызвать функцию для развотора ПКГ из кабины, нежели эту информацию прокачивать через СД.

А обратную связь делать через Update кабины, причём можно сделать обновление "1 раз за 3 Update" - тогда глючность уменьшается

Она прямо пропорциональна кривизне рук и не зависит от частоты апдейта.