RailUnion.net

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

Перед началом МП выкладывается настроенная сессия с нужным ПС в нужных местах. Списки согласовываются на начальном этапе, паки выкладываются.

Всё ясно. Это даже лучше, чем "однообразие". А вот как быть со сходами с рельс? И светофоры на станциях будут в режиме автодействия или вкл/выкл. вручную?

Сначала нужно научиться вводить\выводить данные из игры. Я планирую написать для этого некий абстрактный универсальный интерфейс, а МП (а так же что угодно другое) подключать в виде плагинов.

Такой вопрос: а будет ли возможность поднять собственный мп-сервер, или же придётся довольствоваться только некой группой централизованных серверов от разработчиков мп?

давайте вначале получим надёжный лаз для информации из игры/в игру , а потом уже будем думать. Считаю, что централизованный сервер - это не интересно, чем больше серверов - тем лучше

Ну монополию на сервер я, конечно, постараюсь сохранять Хотя бы потому, что 20 МП на укозе, в которых участвует по два человека — хренотень. Если технология позволит, возможно, онлайн вообще будет нелимитированным, а для этого нужен централизованный сервер.

AlexanderG писал(а):Ну монополию на сервер я, конечно, постараюсь сохранять

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

Но в принципе можно реализовать нечто вроде "комнат", как во всяких чатах.

Запускаем БМО, видим почти две сотни километров, два направления, несколько узловых станций. Пожалуйста, организуется диспетчерский круг, по нему катается тот самый узкий круг друзей. Моя концепция предполагает здоровые карты со здоровым онлайном А вообще, рано об этом говорить (см. пост ТРама).

Ну всё ясно, будем ждать

Друзья, есть ли какие-нибудь наработки за 5 месяцев? Может, чем помочь надо?

да какие там наработки... Ну кроме комбайна теперь и я умею выуживать данные из трс . Но так как я ничего не смыслю в программировании, это никому не нужно. Если надо - http://www.trainsim.ru/forum/showthread.php?t=10625 . Там исходник проги в 8 Visual Studio и вагон, скрипт которого умеет связываться с моей прогой.

Друзья, есть ли какие-нибудь наработки за 5 месяцев? Может, чем помочь надо?

Нету.

мультиплеере

чувствую, последний будет в "симуляторе от Комбайна". Хотя, если будет и в трс, то (если у вас сеть не 16 кб/с) выглядеть это будет не хуже, чем тут (имитируется ping в одну секунду между игроком-сервером (нижний-центральный) и сервером-игроком (центральный-верхний))

PS поставил на 2010ую SP3 - ох*ел. Добавилось 4 новые функции по управлению боксованием. Без понятия, что теперь с этим добром делать.... Лучше б разрядку запасных резервуаров сделали

Поскольку никаких наработок «нету», решил попробовать заняться идеей сей. Вот что удалось состряпать за пять дней :

Мультиплеер реализован в виде отдельного правила для сессии. Перед игрой нужно открыть нужную карту в trainz и, добавив мультиплеерное правило, экспортировать в программу список поездов и стрелок. После чего назначить игроков и утвердить, кто чем может управлять. Списки эти сохраняются в файле bin, он понадобится хосту при создании сессии.
Собственно, на настоящий момент доступны только две вещи: переключать стрелки и «водить» поезда (сцепление-расцепление, автомашинист ещё не реализовано (с автомашинистом вообще проблема, так как если задать заблокированному поезду какую-нибудь команду (load например), то блокировка сбросится)).
Каждой стрелке можно назначить игрока, или несколько игроков, которыми она может управляться (у всех остальных она будет по умолчанию «AllowManualControl(false)»). Можно сделать стрелку, как тут выражались, «нецентрализованной», тогда все будут иметь возможность её переключать.
Каждый поезд может быть назначен только одному игроку (или никому). Синхронное движение поездов осуществляется методом периодического слежения за расстоянием от поезда до ближайшего объекта (посредством GSTrackSearch). У каждого игрока, не управляющего данным поездом, скриптом моделируется зависимость этого расстояния от времени с помощью интерполяционного полинома Лагранжа, при этом учитывается расстояние на данном компьютере (иначе со временем погрешность накопится и будет полный рассинхрон), после чего вызывается SetVelocity. Вообще, конечно, предпочтительней был бы метод кратных узлов, но как оказалось, на Auran Script весьма затруднительно решать систему линейных уравнений (во всяком случае, по моим обожаемым формулам Крамера) из-за проблем с точностью float . Хотя очень-очень хотелось бы реализовать этот метод. А тут, как видно, поезда «дергаются». В общем, над этим ещё надо поработать.
Что касается программы, то метод взаимодействия с trainz, надо полагать, не отличается оригинальностью… Сеть же реализована посредством DirectPlay (сокеты были посланы по недопустимому адресу, так как чтобы они обеспечивали необходимый функционал, с ними нужно эшелон велосипедов доизобретать, а мне лень… ), причем доисторической версии – из DirectX 7.0. Поздние версии DirectX у меня почему-то отказываются создавать интерфейс на DirectPlay . Да, в общем-то, это, я думаю, не принципиально. Обмен данными с trainz происходит с периодом в полсекунды (период можно и поменять, но этого пока хватает и я с ним ещё не экспериментировал). Кстати, данные по сети передаются в сжатом посредством библиотеки zlib виде (порой мощно пакеты сжимаются, иной раз становятся на 60% короче ). У меня, на моей тормозной беспроводке, которую вечно «душит» лифтёрное отделение за стеной, пакеты от игры до игры доходят за ~ 1-1,5 сек.
В игре же, за передачу данных отвечает статический класс Modem. Для передачи данных достаточно скопировать и подключить модуль с этим классом. Данные представлены структурой Packet, содержащей два поля данных major и minor. Указывается также номер игрока-получателя сообщения (номер минус 2 – широковещательная рассылка пакета). Кроме этого, каждый пакет имеет «тип», заданный куидом. Тип нужен для того, чтобы определять, какой класс скрипт какие пакеты должен получать. Указываешь в типе куид своего дополнения и получаешь пакеты, отправленные экземплярами только твоего дополнения у других игроков.