Мультиплеер. Пост №1.
Не буду писать вводную, думаю, и так все понятно. Для начала просто опишу с т.з. программирования. Комплекс для МП будет состоять из следующих частей:
Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.
Сервер. Пока неизвестна его роль в МП — она может варьироваться от тупого рассылальщика сообщений куда попало до сложного комплекса, реализующего разграничение доступа, фильтрацию ошибок и т.п.
Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.
На данный момент есть реальный результат — удалось передать в игру и получить обратно байт данных. А где один байт — там и полноценный обмен, так что возможность всего этого безобразия экспериментально доказана.
Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу
На сегодня это все, всем спасибо за внимание.
- Программа-драйвер, реализующая обмен данными между ТРС и внешним миром через редактирование памяти.
- Программа, реализующая сетевой обмен с сервером.
- Собственно сервер.
- Правило сессии, реализующее обмен данными с внешним миром через программу-драйвер.
- Правило сессии, интерпретирующее поступающие извне команды и наоборот.
Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.
Сервер. Пока неизвестна его роль в МП — она может варьироваться от тупого рассылальщика сообщений куда попало до сложного комплекса, реализующего разграничение доступа, фильтрацию ошибок и т.п.
Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.
На данный момент есть реальный результат — удалось передать в игру и получить обратно байт данных. А где один байт — там и полноценный обмен, так что возможность всего этого безобразия экспериментально доказана.
Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу
На сегодня это все, всем спасибо за внимание.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
Он еще спрашиваетЕсли кому интересно
Интересно, конечно. Еще интересует механизм связи звеньев 1-4, тов. Tram_ говорил, что ТРС не предоставляет адресов (оно и понятно, ни к чему). Как находите куда писать?В этом вашем интернете хрен поймешь, кто прикалывается, а кто реально дебил.
Re: Мультиплеер. Пост №1.
Как находим адрес — отдельное ноу-хау 
Принцип тот же, что и в АртМани. Насчет формата, пока решил организовать так:
1) Маркеры для поиска в памяти (20 байт).
2) Указатель количества сообщений во фрейме (4 байта).
3) Таблица адресов сообщений (4*число сообщений).
Далее идет область собственно данных в следующем формате:
1) Длина сообщения (4 байта).
2) Собственно сообщение (до 4ГБ).
Сейчас вот остановился на реализации API для работы с фреймами.
Принцип тот же, что и в АртМани. Насчет формата, пока решил организовать так:1) Маркеры для поиска в памяти (20 байт).
2) Указатель количества сообщений во фрейме (4 байта).
3) Таблица адресов сообщений (4*число сообщений).
Далее идет область собственно данных в следующем формате:
1) Длина сообщения (4 байта).
2) Собственно сообщение (до 4ГБ).
Сейчас вот остановился на реализации API для работы с фреймами.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
Ага, то есть по-вашему эти 20 байт будут уникальной последовательностью во всей памяти процесса ТРС? Возможно, даже наверняка, так и случится, но остается мааалая вероятность того, что эти 20 байт повторятся где-нибудь еще. С другой стороны, 1 вылет на пару тысяч удачных запусков - очень небольшая плата за мультиплейер, а другой на столько же простой реализации поиска адреса имхо не существует.
К формату не придерешься Для меня осталось загадкой предназначение таблицы адресов сообщений. Если область сообщений идет сразу же за заголовком, то почему бы просто не считывать сообщения последовательно?
Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот. А то может случиться запись во время чтения, что не есть хорошо.
К формату не придерешься
Для меня осталось загадкой предназначение таблицы адресов сообщений. Если область сообщений идет сразу же за заголовком, то почему бы просто не считывать сообщения последовательно? Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот. А то может случиться запись во время чтения, что не есть хорошо.
В этом вашем интернете хрен поймешь, кто прикалывается, а кто реально дебил.
Re: Мультиплеер. Пост №1.
>Если область сообщений идет сразу же за заголовком, то почему бы просто не считывать сообщения последовательно?
Кстати, да...
>Возможно, даже наверняка, так и случится, но остается мааалая вероятность того, что эти 20 байт повторятся где-нибудь еще.
Ну вероятность эта приблизительно равно 2^-160
>Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот.
Да, 4 байта на это тоже надо отвести (4, потому что принят тип integer).
Спасибо за ценные советы, именно ради них я и создал пост
Кстати, да...
>Возможно, даже наверняка, так и случится, но остается мааалая вероятность того, что эти 20 байт повторятся где-нибудь еще.
Ну вероятность эта приблизительно равно 2^-160
>Да, я думаю вы и сами про это не забыли, надо отвести байт под флаг read\write, чтобы общающиеся знали, что запись окончена и можно начинать чтение, и наоборот.
Да, 4 байта на это тоже надо отвести (4, потому что принят тип integer).
Спасибо за ценные советы, именно ради них я и создал пост
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
Пока что решил такой использовать: за маркерами и флагами сразу следуют данные с указанием длин. Получилось, что ни таблица адресов, ни даже счетчик сообщений во фрейме не нужны.
УПД: нет, все же счетчик нужен...
УПД: нет, все же счетчик нужен...
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
И не только мультиплеер, я вот очень хочу использовать такой метод для захвата нажатых с клавиатуры клавиш.
The Cake is a Lie.
Re: Мультиплеер. Пост №1.
а я - для внешнего рассчёта пневматических тормозов не из скрипта, а из отдельного потока... Та - это просто эйфория, аналогичная созданию лент в МСТС
в z7 всё можно, а что нельзя - можно в sU
Re: Мультиплеер. Пост №1.
TRam_ писал(а):а я - для внешнего рассчёта пневматических тормозов не из скрипта, а из отдельного потока... Та - это просто эйфория, аналогичная созданию лент в МСТС
Слишком много данных. Да и смысл, накладные расходы на передачу окажутся больше, чем выйгрыш от более быстрых расчетов, к тому же невозможность точной подстройки и модификации алгоритма скриптом вагона/лока.
The Cake is a Lie.
Re: Мультиплеер. Пост №1.
Так, выяснили количество заинтересованных в МП лиц — около 700 человек. Т.е. на онлайн 10-20 человек единовременно, я думаю, можно рассчитывать.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
Я с вами, если меня не выгонят злые админы мультиплеера. Надеюсь, не будет слишком фимозного соблюдения многих ненужных регламентов? Я имею в виду чОткие переговоры. Караться должны ошибки вождения, а не ошибки переговоров (ну там забыл сказать "Иваныч, зелёный выходной!"). Прошу прощения за отсутствие какой-либо технической информации по программированию и экспериментам передачи данных, я в этом валенок. Вот маршрутец могу построить для МП. Москва-Нара-Поварово сойдёт?
Мск — Мал 5.0 — скачать маршрут с объектами
14 ответов • Страница 1 из 2 • 1, 2
Декабрь 2009