Skip to Content

Мультиплеер. Пост №1.

AlexanderG

Не буду писать вводную, думаю, и так все понятно. Для начала просто опишу с т.з. программирования. Комплекс для МП будет состоять из следующих частей:
  1. Программа-драйвер, реализующая обмен данными между ТРС и внешним миром через редактирование памяти.
  2. Программа, реализующая сетевой обмен с сервером.
  3. Собственно сервер.
  4. Правило сессии, реализующее обмен данными с внешним миром через программу-драйвер.
  5. Правило сессии, интерпретирующее поступающие извне команды и наоборот.

Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.

Сервер. Пока неизвестна его роль в МП — она может варьироваться от тупого рассылальщика сообщений куда попало до сложного комплекса, реализующего разграничение доступа, фильтрацию ошибок и т.п.

Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.

На данный момент есть реальный результат — удалось передать в игру и получить обратно байт данных. А где один байт — там и полноценный обмен, так что возможность всего этого безобразия экспериментально доказана.

Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу ^_^

На сегодня это все, всем спасибо за внимание.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 
 

Re: Мультиплеер. Пост №1.

Dandi

Если кому интересно
Он еще спрашивает ;) Интересно, конечно. Еще интересует механизм связи звеньев 1-4, тов. Tram_ говорил, что ТРС не предоставляет адресов (оно и понятно, ни к чему). Как находите куда писать?
Последний раз редактировалось Dandi 03.12.2009, 01:01, всего редактировалось 1 раз.
В этом вашем интернете хрен поймешь, кто прикалывается, а кто реально дебил.
 

Re: Мультиплеер. Пост №1.

AlexanderG

Как находим адрес — отдельное ноу-хау :) Принцип тот же, что и в АртМани. Насчет формата, пока решил организовать так:
1) Маркеры для поиска в памяти (20 байт).
2) Указатель количества сообщений во фрейме (4 байта).
3) Таблица адресов сообщений (4*число сообщений).
Далее идет область собственно данных в следующем формате:
1) Длина сообщения (4 байта).
2) Собственно сообщение (до 4ГБ).

Сейчас вот остановился на реализации API для работы с фреймами.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 

Re: Мультиплеер. Пост №1.

Dandi

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

К формату не придерешься :) Для меня осталось загадкой предназначение таблицы адресов сообщений. Если область сообщений идет сразу же за заголовком, то почему бы просто не считывать сообщения последовательно?
Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот. А то может случиться запись во время чтения, что не есть хорошо.
Последний раз редактировалось Dandi 03.12.2009, 14:02, всего редактировалось 3 раз(а).
В этом вашем интернете хрен поймешь, кто прикалывается, а кто реально дебил.
 

Re: Мультиплеер. Пост №1.

AlexanderG

>Если область сообщений идет сразу же за заголовком, то почему бы просто не считывать сообщения последовательно?
Кстати, да...

>Возможно, даже наверняка, так и случится, но остается мааалая вероятность того, что эти 20 байт повторятся где-нибудь еще.
Ну вероятность эта приблизительно равно 2^-160 :)

>Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот.
Да, 4 байта на это тоже надо отвести (4, потому что принят тип integer).

Спасибо за ценные советы, именно ради них я и создал пост :)
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 

Re: Мультиплеер. Пост №1.

AlexanderG

Пока что решил такой использовать: за маркерами и флагами сразу следуют данные с указанием длин. Получилось, что ни таблица адресов, ни даже счетчик сообщений во фрейме не нужны.

УПД: нет, все же счетчик нужен...
Последний раз редактировалось AlexanderG 03.12.2009, 17:25, всего редактировалось 1 раз.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 

Re: Мультиплеер. Пост №1.

agmike

И не только мультиплеер, я вот очень хочу использовать такой метод для захвата нажатых с клавиатуры клавиш.
The Cake is a Lie.
 

Re: Мультиплеер. Пост №1.

TRam_

а я - для внешнего рассчёта пневматических тормозов не из скрипта, а из отдельного потока... Та - это просто эйфория, аналогичная созданию лент в МСТС
Последний раз редактировалось TRam_ 03.12.2009, 20:21, всего редактировалось 1 раз.
в z7 всё можно, а что нельзя - можно в sU
 

Re: Мультиплеер. Пост №1.

agmike

TRam_ писал(а):а я - для внешнего рассчёта пневматических тормозов не из скрипта, а из отдельного потока... Та - это просто эйфория, аналогичная созданию лент в МСТС

Слишком много данных. Да и смысл, накладные расходы на передачу окажутся больше, чем выйгрыш от более быстрых расчетов, к тому же невозможность точной подстройки и модификации алгоритма скриптом вагона/лока.
The Cake is a Lie.
 

Re: Мультиплеер. Пост №1.

AlexanderG

Так, выяснили количество заинтересованных в МП лиц — около 700 человек. Т.е. на онлайн 10-20 человек единовременно, я думаю, можно рассчитывать.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 

Re: Мультиплеер. Пост №1.

Tramwayz

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

14 ответов • Страница 1 из 21, 2

 
 
Архивы
- Декабрь 2009