Вопросы, касающиеся создания мультиплеера с синхронизацией поездов
 

Блог Combine'а полугодовой давности, думаю, многие знают. [url]http://www.railunion.net/blog/AlexanderG/1_b-56.html[/url]

И то, что там дело стало, все тоже знают. Хочу также сообщить, что у меня на данный момент дело тоже встало. Но на несколько другой ноте.

Итак, просматривая который раз МСТСовский раздел о новых возможностях ленты, Вовчик подумал - а у нас-то почему не получается?

Ведь "ленту" (т.е. прогу-чит, получающую информацию из определённых адресов памяти, как правило для ж-д симов) для ТРС ещё некто [B]ИА-ИА[/B] пытался делать. Но у него не удалось организовать запись информации вовнутрь трс.

Следующей была попытка [B]Combine[/B]'a, но в его алгоритме почему-то не удалось достичь высоких скоростей передачи. Обсуждение подробно описано в [URL="http://www.railunion.net/blog/AlexanderG/1_b-56.html"]вышеприведённом блоге[/URL], так что при задании вопросов настоятельно советую проверить наличие ответов там.

Ну Вовчик и решил написать прогу, в дальней перспективе делающую то же самое, что прога Combine'а, т.е. обеспечивающую связь клиентского/серверного приложения с ТРС через некие адреса памяти. Аналогов в сети довольно много, алгоритм обнаружения всех страниц памяти был скопирован на одном из программистских форумов (и затем немного подправлен), а затем алгоритм поиска всех имеющихся строк с заданным содержимым. Так как Вовчик на тот момент забыл ассемблер почти полностью, оставил эту часть кода на Си. Поэтому сканирование 600Мб виртуальной памяти (всего 512 Мб ОЗУ :) ) для поиска 29-знаковой строки "49994999499949994999499949994" проходило где-то минуты 1-2.

В результате 10 мая была получена прога, получающая адреса переменных, совпадающие с именами из найденных куда более совершенной прогой ArtMoney
[URL=http://radikal.ru/F/i011.radikal.ru/1005/ea/679b998fd1c3.jpg.html][IMG]http://i011.radikal.ru/1005/ea/679b998fd1c3t.jpg[/IMG][/URL]

Затем Вовчик принялся за главное - сделал интерфейс между трс и прогой. Для этого в ТРС, после запуска сессии со специальным вагоном в одном из поездов, скриптом этого вагона создавались 2 строки, с тем самым содержимым ("499949...949994"). Затем по нажатию кнопки пользователем начиналось сканирование памяти на наличие этих строк. В результате получался массив из 2-36 адресов, среди которых 2 были вагона. Процесс продолжался от 40 до 90 секунд, ИМХО из-за кривизны рук Вовчика и неиспользования ассемблера.

Далее нажатие по одной из ссылок "в свойствах"(в браузере view detailes), благодаря которому обе подчинённые вагону строки изменяли 5й символ. Одна из них - на "I", другая - на "O" (input-output), причём оба понятия относятся к ТРС, а не к проге. Далее нажималась кнопка в проге, обработка нажатия которой находила эти самые нужные буквы, и сохраняла адреса этих двух строк. В результате мы получили то же самое, что создатели лентописцев в МСТС - нашли нужные нам отверстия для управления игрой.

А далее Вовчик подсоединил строку "output" из трс к генератору случайных чисел (внутри скрипта), а в проге - закоротил выход и вход (правда, там предварительный сдвиг фаз делается :) )

Поиск новых значений организован в ТРС на двух thread'ах, в проге - на одном таймере. Алгоритм подтверждения работает примерно так (показано начало строки, * - любые символы)

для строки output

400***** - скрипту вагона разрешено писать; если прога увидела в 3 символе '0', то чтения не делает

Когда вагон дописывает строку до конца, он меняет 3 символ на 'W', и получается строка

40W**** - здесь W означает не "запись", а "запись закончилась"; если прога нашла такой символ, то она считывает строку, по окончании меняя W обратно на 0. Скрипт ничего при этом не пишет.

для строки input - аналогично

400***** - проге запрещено писать, скрипт строку ещё считывает (потом меняет на R)
4R0**** - прога пишет, скрипт ничего не читает


В результате 14 мая почти ровно в 18-00 эта конструкция успешно заработала. Затем длина кодируемых строк была увеличена до 2001 символа, и было проведено несколько тестов на акелловской 2009, на карте tidewater, где были проложены комбайновские рельсы.

Перед одним из тестов
[URL=http://radikal.ru/F/s13.radikal.ru/i186/1005/66/3f47ddca64f6.bmp.html][IMG]http://s13.radikal.ru/i186/1005/66/3f47ddca64f6t.jpg[/IMG][/URL]

В проге перед этим сделал дополнительный таймер, чтоб считал число переданных строк в секунду. Эти числа (левое - для отданных трсом, правое - для полученных трсом данных) видно на скрине. Заметте,

7 строк по 2001 символу по 1 байту в секунду = 7 строк по 2001 символу по 8 бит в секунду ~ 110 кБит/секунду. В обе стороны. Одновременно. Для мульта хватит? Мне кажется что да. Учитывая что Conter-Strike требует около 16-32 кБит/секунду.

Хотя конечно процессе игры производительность падала, но, замечу, число переданных строк в секунду никогда не было меньше 3 (40-50кБит/с) в обе стороны (несмотря на fps 3 на некоторых участках (а вообще 6-10), как-никак комп одноядерка на 2ГГц и памяти 512 Мб)

Ну и оставлю я этот вариант опенсорс (под visual studio 8) + вагон со скриптом. Думаю, другим авторам паровозных примочек к компу и мультиплееров для изучения подойдёт, хотя пока это прога "г* на палочке с хвостиком".
[url]http://ifolder.ru/17712909[/url]

да, в отличии от комбайновского варианта, у меня длина сообщения фиксирована. У данной проги 2001 charом. Хотя можно любую другую зафиксировать.

[QUOTE]Следующей была попытка Combine'a, но в его алгоритме почему-то не удалось достичь высоких скоростей передачи.[/QUOTE] А по морде не хочешь получить? При размере окна в 4096 элементов и 30ФПС в игре уже 12кБ\с получается. Если паковать байт сообщения в байт окна, то 48кБ\с. А если увеличить окно, то скорость любая. Думай, что говоришь.

[QUOTE]Ведь "ленту" (т.е. прогу-чит, получающую информацию из определённых адресов памяти, как правило для ж-д симов) для ТРС ещё некто ИА-ИА пытался делать. Но у него не удалось организовать запись информации вовнутрь трс.[/QUOTE] Про Варза забыли опять. Мне, вообще говоря, непонятно, почему у Варза и Ослика не получилось, а у меня за два вечера заработало.

[QUOTE]Так как Вовчик на тот момент забыл ассемблер почти полностью, оставил эту часть кода на Си. Поэтому сканирование 600Мб виртуальной памяти (всего 512 Мб ОЗУ ) для поиска 29-знаковой строки "49994999499949994999499949994" проходило где-то минуты 1-2.[/QUOTE] У меня была скорость 60...80МБ\с.

[QUOTE]для строки output

400***** - скрипту вагона разрешено писать; если прога увидела в 3 символе '0', то чтения не делает

Когда вагон дописывает строку до конца, он меняет 3 символ на 'W', и получается строка

40W**** - здесь W означает не "запись", а "запись закончилась"; если прога нашла такой символ, то она считывает строку, по окончании меняя W обратно на 0. Скрипт ничего при этом не пишет.

для строки input - аналогично

400***** - проге запрещено писать, скрипт строку ещё считывает (потом меняет на R)
4R0**** - прога пишет, скрипт ничего не читает[/QUOTE] Ненужные костыли. Достаточно одного числа.

[QUOTE]да, в отличии от комбайновского варианта, у меня длина сообщения фиксирована.[/QUOTE] Вот у меня есть пульт, мультиплеер, и, допустим, лента. Пульту и МП нужен дуплекс, получаем 5 охочих до комиссарского тела сущностей. Если у нас 15ФПС, то получаем по 3 сообщения для каждого желающего в секунду. Маловато даже для ленты.

[QUOTE]Для мульта хватит? Мне кажется что да.[/QUOTE] А мне ничего не кажется, у меня калькулятор дома есть...

Эй, про рэйлдрайверы и расширенный ввод с клавиатуры не забываем! И возможность продвинутого физического движка вне ТРСа.

Трам, ну есть же уже готовый нормальный формат:
<маркеры><флаг><количество строк>[<длина i-той строки><i-тая строка>]
Зачем выдумывать ненужный двустрочный формат, в два раза более глючный?

Судя по тому, что направлением интересуются, работа будет продолжена.

[QUOTE]У меня была скорость 60...80МБ\с.[/QUOTE]у ArtMoney она или такая же, или больше. И что?

[QUOTE]Пульту и МП нужен дуплекс, получаем 5 охочих до комиссарского тела сущностей. Если у нас 15ФПС, то получаем по 3 сообщения для каждого желающего в секунду. Маловато даже для ленты.[/QUOTE]

МП можно вовсе с скрипт загнать и там всё паковать. Сервер может рассылать всем копии полученного из трс сообщения. А уж скрипты-получатели легко могут определить, какой поезд не его пользователя, а какой - его (чтоб скорость поезда пользователя не трогать).

И не понимаю, зачем тебе 2000 байт на сообщение для пульта?

[QUOTE]Зачем выдумывать ненужный двустрочный формат, в два раза более глючный?[/QUOTE] потому что скорость приёма и скорость отдачи могут отличаться. Особенно учитывая то, что скрипт трс вбивает строку посимвольно, а копирует "всё сразу" (если конечно аурановцы не настолько молодцы что этого не предусмотрели).

Флаги сделать всегда можно, только возиться с ними в трсе прийдётся исключительно в виде символов. Для проги, которая создана за одну неделю знакомства с системным программированием под windows, и созданную исключительно для тестирования скорости двухсторонней передачи программой-недрайвером. Поэтому и нереализована здесь переменная длина строки (но естественно меньше некого предела, но никак не 4Гб), хотя, естественно, она необходима.

Для мульта я бы предложил форму

<флаги><длина строки>[<адресат>, ]

[QUOTE=TRam_;177386]у ArtMoney она или такая же, или больше. И что?[/QUOTE]
А то, что у тебя получается 5 МБ/с. Я не хочу ждать при смене адреса две минуты пока вновь произойдет поиск и не заработает мой внешний пульт и отомрет управление с клавиатуры, если что.
[QUOTE=TRam_;177386]МП можно вовсе с скрипт загнать и там всё паковать. Сервер может рассылать всем копии полученного из трс сообщения. А уж скрипты-получатели легко могут определить, какой поезд не его пользователя, а какой - его (чтоб скорость поезда пользователя не трогать).[/QUOTE]
Что ты так рвешься сразу мультиплеер писать? Это дело отдельного плагина. Ты вообще знаком с базовыми принципами проектировки ПО? Или просто сразу бежишь вперед батьки в пекло?
[QUOTE=TRam_;177386]И не понимаю, зачем тебе 2000 байт на сообщение для пульта?[/QUOTE]
А я не понимаю, зачем сейчас выдумывать для сверхполезной фичи ограничения в стиле "64 КБайт хватит для каждого" ©
[QUOTE=TRam_;177386]потому что скорость приёма и скорость отдачи могут отличаться[/QUOTE]
Не могут они различаться, у тебя у самого получилось 7 и 7, 7 = 7 начиная с начала исчисления.
[QUOTE=TRam_;177386]Для мульта я бы предложил форму
<флаги><длина строки>[<адресат>, ][/QUOTE]
Вот еще, для мульта писать отдельный код в драйвере.

[QUOTE]И возможность продвинутого физического движка вне ТРСа.[/QUOTE]так ему надо посылать профиль + степень кривизны рельс. А возвращать вовсе 1 параметр - текущую скорость.

[QUOTE]Я не хочу ждать при смене адреса две минуты пока вновь произойдет поиск и не заработает мой внешний пульт и отомрет управление с клавиатуры, если что.[/QUOTE]а я хотел написать прогу, которая сдвинет этот вопрос с мёртвой точки. Вон ArtMoney ищет это за 6 секунд (вероятно столько же, сколько комбайновские 60...80МБ\с), а то, что мне это не удалось - я не отрицаю.

[QUOTE]А я не понимаю, зачем сейчас выдумывать для сверхполезной фичи ограничения в стиле "64 КБайт хватит для каждого"[/QUOTE]потому что скорее мульт в RW будет, чем Скиф сможет свой пульт к ТРС прикрутить.

[QUOTE]Ты вообще знаком с базовыми принципами проектировки ПО? Или просто сразу бежишь вперед батьки в пекло?[/QUOTE]ни разу. Я не профессиональный программист. Я профессиональный материаловед.

[QUOTE=TRam_;177390]так ему надо посылать профиль + степень кривизны рельс. А возвращать вовсе 1 параметр - текущую скорость.[/QUOTE]
Ага. Если для каждого вогона писать свой движок, то да :)
И то, сколько параметров окружающей среды нужно передавать тебе известно? Ветер, тип путей, номер пути, сигнал светофора, показания приборов... Нам неизвестно число, неизвестны пределы.
[QUOTE=TRam_;177390]потому что скорее мульт в RW будет, чем Скиф сможет свой пульт к ТРС прикрутить.[/QUOTE]
Как оптимистично. Смотрю вперед, как на американской карте пять человек, включая диспетчера, гоняют американские вогоны единственным тепловозом ТЭМ2 :)
[QUOTE=TRam_;177390]ни разу. Я не профессиональный программист. Я профессиональный материаловед.[/QUOTE]
А где ты здесь видишь профессиональных программистов? Для того, чтобы прочитать соответствующие статьи в википедии и скачать пару книжек не требуется нотариально заверенный скриншот диплома о высшем образовании в области информационных технологий.

[QUOTE]Если для каждого вогона писать свой движок, то да[/QUOTE]А зачем тогда вообще внешняя прога, если трсовская физика колебаний/скриптовое управление давлением ТЦ устраивают?

[QUOTE]чтобы прочитать соответствующие статьи в википедии и скачать пару книжек[/QUOTE]и прочитать часть этих книжек. Честно - ни разу по программистским викам не лазил.

[QUOTE=TRam_;177392]А зачем тогда вообще внешняя прога, если трсовская физика колебаний/скриптовое управление давлением ТЦ устраивают?[/QUOTE]
Неа, не устраивают. :)
Решение пневматических цепей по моей задумке требует решения трех матриц общего вида за цикл, размерность равна числу точек в цепи. Отдельно расчет ТМ каждый кадр, это проще, т.к. стандартный трехдиагональный вид, но, возможно, потребуется делать это несколько раз за кадр (явная схема), плюс захват ударных волн. Электрические цепи тоже не легкие, тоже матрицы, общего вида, если повезет, то симметричная, правда. А тут еще динамика, и все дела, т. е. объемы вычислений не для скриптов, как бы :)

[QUOTE]И не понимаю, зачем тебе 2000 байт на сообщение для пульта?[/QUOTE] Потому что у тебя фиксированная длина пакета в 2000 байт.

[QUOTE]Флаги сделать всегда можно, только возиться с ними в трсе прийдётся исключительно в виде символов.[/QUOTE] Велика беда...

[QUOTE]Для мульта я бы предложил форму

<флаги><длина строки>[<адресат>, ][/QUOTE] Любой формат, не позволяющий передавать более одного сообщения в посылке, априори неподходящ для этой затеи. Почему, я уже объяснил.

[QUOTE]Что ты так рвешься сразу мультиплеер писать? Это дело отдельного плагина. Ты вообще знаком с базовыми принципами проектировки ПО? Или просто сразу бежишь вперед батьки в пекло?[/QUOTE] Ну у нас будет одна прога для МП, одна для пульта Васи, еще одна для пульта Пети, пару штук на регистраторы. И все оно весело полезет одновременно в память.

[QUOTE]ни разу. Я не профессиональный программист. Я профессиональный материаловед.[/QUOTE] Ей-богу, учи лучше сопромат...

[QUOTE]и прочитать часть этих книжек. Честно - ни разу по программистским викам не лазил.[/QUOTE] Вот вершков нахватаешься, потом всякую херню пишешь, от которой то ли смеяться, то ли плакать, то ли волосы рвать хочется.

P.S. Интерфейс программки напомнил это:
[IMG]http://noisydecentgraphics.typepad.com/design/images/2008/03/11/yourproduct.jpg[/IMG]

[QUOTE]Ну у нас будет одна прога для МП, одна для пульта Васи, еще одна для пульта Пети, пару штук на регистраторы.[/QUOTE]или будет одна от agmike и Combine, но исходники только у них, мультиплееры проводятся только на их сайте. А до того "да через jetlog.txt как-то можно подключить скрипт к компу...."

И пульт Васи вряд-ли окажется подключенным у Пети, да ещё и одновременно с его собственным. Хотя бы потому что самодельные пульты - штучные изделия.

[QUOTE]Решение пневматических цепей по моей задумке требует решения трех матриц общего вида за цикл, размерность равна числу точек в цепи. Отдельно расчет ТМ каждый кадр, это проще, т.к. стандартный трехдиагональный вид, но, возможно, потребуется делать это несколько раз за кадр (явная схема), плюс захват ударных волн. Электрические цепи тоже не легкие, тоже матрицы, общего вида, если повезет, то симметричная, правда. А тут еще динамика, и все дела, т. е. объемы вычислений не для скриптов, как бы[/QUOTE]о воздухораспределителе забыл. В нём под 20 элементов пневматических и ещё пневмомеханические.

А ТМ рассчитывать без учёта наполнения ЗР я бы не советовал.


[QUOTE]Ветер, тип путей, номер пути, сигнал светофора, показания приборов...[/QUOTE]
ветер - в самом движке физики, показания приборов - напрямую в пульт, рукоятки - тоже.

Остаются светофоры, пути и стрелки. Ну и препятствия на переезде.

[QUOTE=TRam_;177399]или будет одна от agmike и Combine, но исходники только у них, мультиплееры проводятся только на их сайте. А до того "да через jetlog.txt как-то можно подключить скрипт к компу...."[/QUOTE]
Да, еще программы-то нет, а уже все поделено-распилено. Русский дух если и есть, то сразу везде.
Какие к черту мультиплееры, написание его займет в двадцать раз больше усилий, чем этого драйвера, а у нас рабочего драйвера еще нет.
Через джетлог, кстати, ничего такого не подключить.
[QUOTE=TRam_;177399]о воздухораспределителе забыл. В нём под 20 элементов пневматических и ещё пневмомеханические.[/QUOTE]
С каких пор ВР не считается пневматической цепью?
[QUOTE=TRam_;177399]А ТМ рассчитывать без учёта наполнения ЗР я бы не советовал.[/QUOTE]
Да ты прямо Петросян. Нет блин, надо решать каких-то пару десятков матриц за кадр и при этом ТМ с ЗР не будут связаны.
[QUOTE=TRam_;177399]ветер - в самом движке физики, показания приборов - напрямую в пульт, рукоятки - тоже.[/QUOTE]
Ну сделай пульты для каждого лока вместе с плагином для каждого лока, раз все так просто напрямую.
Я тут полгода с лишним бьюсь над тем, чтобы создать универсальный конструктор, но сегодня внезапно открыли, что все очень просто напрямую.
[QUOTE=TRam_;177399]Остаются светофоры, пути и стрелки. Ну и препятствия на переезде.[/QUOTE]
Ага, и разрушаемые мосты, как в си^W^W тренажере break'а.

Господа скриптеры, кончайте эпический срач и пожмите друг другу клавиатуры.

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

ЗЫ: ищет эдакий хитрый вольтметр с углом вращения стрелки 270 градусов.... Ну, или разломать какой-нибудь еще. Идею с шаговиками следует забыть как страшный сон - жужжат и работают слишком резко, рывками, для манометров не айс. Можно использовать шаговик (и то коллекторник лучше) для мегаизвращенного вращения хомута. скоростемера СЛ2 :) .

[QUOTE]Я тут полгода с лишним бьюсь над тем, чтобы создать универсальный конструктор, но сегодня внезапно открыли, что все очень просто напрямую.[/QUOTE]чем универсальнее - тем медленнее. Тем более что именно для мультиплеера по минимуму надо

в скрипте
1) мониторинг составов (какие сцепились, какие - нет, какая у кого скорость)
2) установщик скорости составов
3) установщик новых положений стрелок
4) упаковщик/распаковщик

снаружи
1) прога передачи
2) клиентская прога/ сервер, отправляющие серверу(и получающие от него сообщения)/ рассылающий всем пользователям одинаковые сообщения за раз (и получающий сообщения от пользователей)


[QUOTE]Любой формат, не позволяющий передавать более одного сообщения в посылке, априори неподходящ для этой затеи. Почему, я уже объяснил.[/QUOTE]а что мешает передавать кусок строки, а потом собирать? Не, в самом деле "Мы готовим суперуниверсальные систему управления/системы информирования о свойствах пути/систему расчёта цепей/драйвер передающий любую группу сообщений для работы любых пультов / мультиплееров / локомотивов / тренажёров, поэтому не предлагай нам по своему тупому алгоритму ещё что-то писать на форуме - вся эффектность данного суперпроекта ушла".

[QUOTE]P.S. Интерфейс программки напомнил это:[/QUOTE]неверно. Там 2 окна должно быть
[IMG]http://i055.radikal.ru/1005/4d/486c5c30797d.jpg[/IMG]

а пока
[QUOTE]у нас рабочего драйвера еще нет.[/QUOTE]

в любом случае, даже в вашем, скорость передачи данных через инет вряд-ли у всех пользователей мультиплеера будет в 1 Гб/секунду. А вы даже не сообщали, какой-таки скорости выдачи данных из ТРС удалось добиться.

...я конечно, не зверский программист, но ломать мозги о том, рвать или не рвать строку при передаче ее уже на уровне сети по протоколу TCP/IP - должно быть головной болью не программиста, а потока, управляющего сокетом отправления. Для сего ему положено иметь буфер для кеширования и формирования пакетов, протоколы контрольных сумм и еще многое, благодаря чему в винде еще до сих пор чудом работает сеть. Потому стоит соорудить MFC Based Application.

TRam_, не слушаешь нас — послушай Скифа.
[QUOTE=Skif;177428]начните вы с малого - с полнофункционального управления от клавиатуры и дуплексного обмена - это я вам как системщик советую.[/QUOTE]
Как раз суперуниверсальность — проблема твоих идей, где ты предлагаешь делать специфичный для мультиплееров код в драйвере. Неужели тебе непонятно, что:
[SIZE="3"][FONT="Century Gothic"]Единственной заботой драйвера должен быть обмен данными, который используют другие скрипты и плагины[/FONT][/SIZE].
[QUOTE=Skif;177461]MFC Based Application.[/QUOTE]
МФС имеет несколько дубовый вид. Я думаю, по простоте и удобству .NET больше подойдет.

[QUOTE]Единственной заботой драйвера должен быть обмен данными, который используют другие скрипты и плагины.[/QUOTE]обмен данными с требуемой скоростью.

Например для клавиатуры код вообще отдельный надо делать, так как для неё нужно 3 байта (2 на код клавиши + флаг) , но обмениваться часто (~0.01 с). А мультиплееру надо 1 строку или массив писать, по несколько тысяч символов, но раз в 0.5 секунды. И запись ответной строки (в случае одномассивного интерфейса) задерижит отправку очередного ответа от клавиатуры.

Не, если считаешь, что запись этих строк происходит почти мгновенно, я не имею ничего против. Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с (т.е. 5 пропущенных сигналов клавиатуры)

[QUOTE=TRam_;177511]Например для клавиатуры код вообще отдельный надо делать, так как для неё нужно 3 байта (2 на код клавиши + флаг) , но обмениваться часто (~0.01 с). А мультиплееру надо 1 строку или массив писать, по несколько тысяч символов, но раз в 0.5 секунды. И запись ответной строки (в случае одномассивного интерфейса) задерижит отправку очередного ответа от клавиатуры.[/QUOTE]
Ну да, это у тебя серьезные проблемы, ведь ты передаешь только одну строку за раз.
[FONT="Century Gothic"]А еще, к твоему сведению, в ТРС многозадачность кооперативная. Так что как бы ты не выпендривался с десятком строк для каждой функции, по твоим суждениям следует, что запись данных мультиплеера по-любому заблокирует клавиатуру.[/FONT]
[QUOTE=TRam_;177511]обмениваться часто (~0.01 с)[/QUOTE]
Ты не прав. Во-первых, номинал времени отклика для нажатия клавиши — 0.1 с. Во-вторых, используя паттерн ли...
[QUOTE=TRam_;177511]Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с[/QUOTE]
А зря, вот сначала посчитай, а потом уже пиши, а то нередко "факты", написанные тобой, оказываются бредом. Живо встает в памяти проблема отражения ГСТСа от стрелок.

Счеты
 

[B]Тест:[/B]
[CODE]int[] a = new int[10000];
int i;
int j;

Interface.Log("START");

for (i = 0; i < a.size(); ++i)
{
for (j = 0; j < a.size(); ++j)
{
a[i] = j;
a[j] = i;
}
}

Interface.Log("STOP");
Interface.Log(a[0] + a[a.size() - 1]);
[/CODE]

[B]Результат:[/B]
[CODE]? 000004AC Warn 0:25.7 Trainz : WorldState::NativeLog> START
? 000004AC Warn 0:41.2 Trainz : WorldState::NativeLog> STOP
? 000004AC Warn 0:41.2 Trainz : WorldState::NativeLog> 19998[/CODE]

[B]Скорость записи:[/B]
2 * 10000 * 10000 / (41.2 - 25.7) = 12903225,806451612903225806451613

[B]То есть:[/B]
12.9 МБ/с (считаем целое четырехбайтовое число за один байтовый символ)

[B]Вывод:[/B]
Скрипты в ТРС прекрасны.

Миша, Вова, Саня! Каковы перспективы увидеть мультик в ТРС вцелом?)
Ребята вон для ГТА довольно быстро управились

Надо пробовать :)

Если техническая сторона все это вполне допускает, то организационные моменты гораздо сложнее, мне кажется.

[QUOTE]Живо встает в памяти проблема отражения ГСТСа от стрелок.[/QUOTE]да, ГСТС неверно отпределяет положение переведённой не на нас противошёрстрной стрелки.
ЭТО ФАКТ. А моё предположение о том, что оно неверно определяется для противошёрстных стрелок вообще было вызвано фитчей АЛСН потери кодирования на стрелке и фактом не оказалось.

[QUOTE]То есть:
12.9 МБ/с (считаем целое четырехбайтовое число за один байтовый символ)[/QUOTE]
остаётся только мне со строками проверить и покончить ещё с одним своим бредом.

Строка — тот же массив чисел. Ничего иного ты не обнаружишь.
К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные. Извлечь из такого массива строку легко, а наоборот — уже труднее.
[QUOTE=TRam_;177552]да, ГСТС неверно отпределяет положение переведённой не на нас противошёрстрной стрелки.[/QUOTE]
Как он может определять положение стрелки, ГСТС лишь ищет и находит, а положение стрелки выдается Junction.GetDirection() и от поиска не зависит.

[QUOTE]Как он может определять положение стрелки, ГСТС лишь ищет и находит,[/QUOTE]ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .


[QUOTE]К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные.[/QUOTE]а может вовсе с плавающей точкой делать? А то нам целочисленные не очень-то нужны, главное - имена и значения скорости и расстояния

[QUOTE]Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с (т.е. 5 пропущенных сигналов клавиатуры)[/QUOTE] Ну на твоем кассетном Спектруме, может, и так... У всех людей скорость перемещения данных в ОЗУ давно уже имеет исчисление гигабайтами.

[QUOTE]Миша, Вова, Саня! Каковы перспективы увидеть мультик в ТРС вцелом?)
Ребята вон для ГТА довольно быстро управились[/QUOTE] Технически проблем никаких нет. А так бы я на вашем месте давно подсадил меня на героин и заставлял работать в обмен на дозу.

[QUOTE]а может вовсе с плавающей точкой делать? А то нам целочисленные не очень-то нужны, главное - имена и значения скорости и расстояния[/QUOTE] Лучше булев.

P.S. Володя, ради бога, занимайся лучше своим делом — сопроматом и не мотай нам нервы и не трать наше время на опровержение твоей бредятины.

[QUOTE=TRam_;177580]ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .[/QUOTE]
Интересно услышать детали.

[QUOTE]Ну на твоем кассетном Спектруме, может, и так... [/QUOTE]хочешь чтоб а ещё попетросянил? Пожалуйста. Мой камп, с которого я написал это сообщение
[URL=http://radikal.ru/F/i060.radikal.ru/1005/dd/a004749af898.jpg.html][IMG]http://i060.radikal.ru/1005/dd/a004749af898t.jpg[/IMG][/URL]

[QUOTE]Интересно услышать детали.[/QUOTE]это не детали. Это пояснение.

[QUOTE]P.S. Володя, ради бога, занимайся лучше своим делом — сопроматом и не мотай нам нервы и не трать наше время на опровержение твоей бредятины.[/QUOTE]Вероятно ты прав... Пора уже TRainzManual_'у на покой. Свою самую сложную мечту - связать trainz и свою программу - он уже осуществил

[QUOTE=TRam_;177596]это не детали. Это пояснение.[/QUOTE]
Что в нем не так — вот что я хочу услышать. Возвращает ли он правильное значение, или неправильное, или противоположное правильному, или всегда одно, или вообще рандомное.

возвращает всегда false. При любом положении левера относительно пути.

Следующий SearchNext выдаёт null, так что для маршрутизации надо запоминать объект перед стрелкой и его направление относительно поиска, чтобы после её перевода возобновлять поиск с этого объекта, а не со стрелки.