Просмотр полной версии : Скриптование под мультиплеер
Считаю, что такой аспект, как мультиплеер, заслуживает отдельной темы. Предлагаю в этой теме обсуждать вопросы синхронизации и прочие особенности скриптования объектов для мультиплеера.
Итак, первый вопрос. Что именно синхронизирует игра, а что надо синхронизировать вручную? И что делать с вычислениями, которые должны выполниться только в одном месте? Всех их выполнять только на сервере?
Например, имеется один простой скрипт: при наезде поезда на триггер переключается стрелка. Нужно ли здесь что-то предпринимать для синхронизации? Критично ли переводить стрелку только на сервере или можно это не проверять и пусть скрипт выполняется у всех игроков?
Что именно синхронизирует игра
стрелки, тротлы лока и его положение, формирование составов. Возможно ещё наличие груза (хотя это сомнительно). Гудок стандартный, свисток стандартный, токоприёмники, прожектор, привязку машинистов к составу.
а что надо синхронизировать вручную?
Всё остальное, что тебе требуется.
И что делать с вычислениями, которые должны выполниться только в одном месте?
Ты уже ответил
Всех их выполнять только на сервере
Спасибо за ответы.
Но таки что делать в примере со стрелкой? Можно признать этот скрипт простым и не требующем "адаптации", но тогда стрелку будут переводить все, что как я понимаю не хорошо. А можно всё же обеспечить перевод стрелки только на одном клиенте.
Кстати про выполнение только на одном клиенте. А возможно ли и имеет ли смысл поручать такие вычисления тому клиенту, чей поезд вызвал событие?
Всё возможно. Нужно исходить из того, что ты хочешь реализовать. Так, например, в моём скрипте ПОНАБ, все расчёты выполняются на том клиенте, игрок которого привязан к поезду вызвавшему событие наезда на триггер. А вот в пульте ДСП все расчёты, переводы стрелок, сборка маршрутов и тп (кроме открытия светофоров) происходит на стороне сервера. Клиенты лишь отправляют запрос.
Вообще, ты же можешь меня найти в скайпе, если тебе вдруг понадобится помощь в реализации синхронизации и тп.
Я хотел, чтобы всё это здесь осталось, вдруг ещё кому-нибудь пригодиться. А так да, пойду в скайп.
А зачем? Практика показывает, что народ читать не любит. Да и скриптеров 1,5 землекопа. Кому нужно, спросит. Тайны ведь из этого (в отличии от Аурана) никто не делает. На самом деле в синхронизации в ТРС ничего сложного нет, просто нужно грамотно перед собой задачу поставить.
Господа скриптёры, как мне ПРАВИЛЬНО получить юзернейм в кабине? Я уже час пытаюсь что нибудь сделать, но получаю либо NullReference, либо null вместо имени. Делаю в одном файле отдельном классе. Класс выглядит так:
static class TestLib isclass Library
{
OnlineAccess m_onlineAccess;
public string GetUsername();
string Username;
public void Init(Asset asset)
{
inherited(asset);
string a;
m_onlineAccess = GetOnlineAccess();
m_onlineAccess.Connect();
Username = m_onlineAccess.GetUsername();
if(Username==null)
{
Interface.Exception("Username is NULL");
}
}
public string GetUsername()
{
return Username;
}
};
Вызывается функция GetUsername в Update:
Username=TestLib.GetUsername();
вынесено из темы "Вопросы по Auran GameScript"
юзернейм
string Username = me.GetAsset().GetConfigSoup().GetNamedTag("username");
Тьфу, не так сформулировал. Мне нужно имя игрока, который сидит в данный момент в кабине.
TRam_
Да. Пытаюсь сделать синхронизацию хотя-бы 1 рычажка в кабине, и надо получить имя игрока, который сейчас внутри кабины.
Vehicke veh; //Тут ссылка на лок или вагон для которого проверка
DriverCharacter driver = veh.GetMyTrain().GetActiveDriver();
//Тут имеет смысл сделать проверку не является ли driver пустышкой (null)
string player = driver.GetOwnerPlayer():
Эрендир
Спасибо, заработало.
А как получить имя игрока вообще?
glebqip, абсолютно не понимаю, зачем это может понадобится для синхронизации, темболее кабин, причем если ещё учесть, что к локу может быть привязан исключительно один пользователь.
Эрендир
К примеру, в кабине сидят 2 игрока, игрок который управляет отправляет сообщение клиенту(ам)/серверу. Как предотвратить изменение ручки у того, кто управляет?
glebqip, что значит предотвратить? Он же её сам изменяет, после чего рассылается сообщение (кроме того, я не могу понять, зачем надо синхронизировать кабины вообще)
Эрендир
Изменять надо потому-что есть случаи, когда в мультиплеере люди ездят в кабинах по двое.
glebqip, да хоть по четверо или впятером. Всё равно управлять из них может только один. А синхронизация кабин, которая на деле никому не нужна, это аццкая, ненужная нагрузка на синхронизацию, которая в ТРС и без того не блещет.
SKZDRostovDon
15.06.2014, 09:57
Как сделать чтобы Локомотивы синхронизировались в Мультиплеерах? Плиз очень нужно)
SKZDRostovDon, так же как и синхронизацию всего остального. Через функции класса MultiplayerGame. Но вопрос, а нужно ли? Тут уже один собирался делать полную синхронизацию локомотива и даже кабины. Ну одним словом просто убить весь мудьтиплеер сразу. Пока что, особенно с теми серверами, что есть, это не лучшая идея.
SKZDRostovDon
15.06.2014, 11:29
А я просто хочу чтобы просто можно было видеть всем локомотив ане только одному) Про Через функции класса MultiplayerGame Можно подробнее?
SKZDRostovDon, так его и так все видят
SKZDRostovDon
15.06.2014, 12:17
SKZDRostovDon, так его и так все видят
Про Через функции класса MultiplayerGame Можно подробнее?
SKZDRostovDon, файл multiplayergame.gs в папке script. Там всё что надо
А кто-нибудь разбирался с kind servlet?
Конечно, у них там написано, что что-то там не реализовано, но при этом в дефолте такие ассеты есть. Да и для передачи данных между игрой и сторонним сервером много не надо, я думаю.
Собственно, почему я пишу именно в эту тему. Было бы здорово вынести часть логики СЦБ из игры на сторонний сервер и/или создать АРМ диспетчера (или даже дежурных). Так можно будет управлять движением на мультиплеере даже не заходя в Траинз)) Да и возможностей по реализации всяких плюшек больше, чем в скриптах.
Слишком заморочено и без должной документации. К тому же, всё через сервера аурана.
Auran Example Servlet,<kuid:30501:1007>
От их серверов, как я понимаю, в любом случае не уйти. Да и нужны они нам только как шлюз.
kemal, надо будет попробовать что-нибудь сделать. Пока не очень понятно что у чему. Но серверный интерфейс реализуется здесь.
Поковырялся я в скриптах...
Вся серверная часть (взаимодействие с внешним миром) реализуется в самом сервлете. Для взаимодействия с игрой пишется отдельная библиотека (что для меня осталось не ясным, ведь сервлет и сам является наследником библиотеки). Всё взаимодействие идёт через OnlineAccess.PostMessage(string destUsername, Soup data). Вся суть в том, что если мы хотим отправить данные в игру какому-нибудь пользователю, то мы указываем его логин в первом параметре. Если же хотим отправить данные на сервер, то в качестве пользователя указываем "servlet".
Извне доступ к сервлету возможен по адресу servlet.auran.com/<kuid>/ Для обработки запроса в сервлет передаются URI и суп с ГЕТ переменными. В ответ он может сгенерировать хтмл, отдать статику из какого-нибудь ассета или нарисовать(!) картинку.
А теперь спать...
---------- Сообщение добавлено в 15:48 ---------- Предыдущее сообщение размещено в 03:55 ----------
Кстати, а гарантируется ли совпадение игровых Id у разных игроков? С объектами карты всё понятно - для них id берётся из файла mapfile.obs. А с вагонами как? Особенно, если их в процессе игры добавлять.
, а гарантируется ли совпадение игровых Id у разных игроков
А фиг его знает. Теоретически, вроде как да.
С объектами карты всё понятно - для них id берётся из файла mapfile.obs. А с вагонами как? Особенно, если их в процессе игры добавлять.
Ты ошибаешься. Точнее путаешь id объекта с тем, который ты можешь получить через скрипт. Сплайны и объекты хранятся в разных файлах, и там у каждого свой id, который является тупо счётчиком внутри отдельной группы. А в скриптах свой счётчик, который выдаёт каждому объекту в сессии id при его создании во время загрузки сессии и при добавлении ПС, команд и машинистов во время сессии. Тут сквозной счётчик для всех объектов загруженных с карты и сессии: объекты, сплайны, ПС, правила, команды и тп.
---------- Сообщение добавлено в 16:07 ---------- Предыдущее сообщение размещено в 16:04 ----------
Сообщение от kemal
, а гарантируется ли совпадение игровых Id у разных игроков
А фиг его знает. Теоретически, вроде как да.
Исхожу из того, что последовательность загрузки сессий у всех клиентов одинаковая, а раз id ни что иное как счётчик, то можно со 100% уверенностью сказать, что после загрузки все объекты на всех клиентах имеют абсолютно одинаковые id. Всё что создаётся в сессии (ПС, команды, машинисты) могут быть созданы только на сервере, который потом синхронизирует их с остальными клиентами, а там и id так же будут одинаковыми.
Ой, действительно...
Как бы теперь это проверить?
сделать лог соответствия Id объектов их именам
После сегодняшнего "сюрприза" очередной раз осознал важность разработок в этом направлении. Пинг перевалил за 1 лям и... И ничего - ни игры, ни вылета. Ладно бы у машиниста - фигово, но жить можно. А это у дежурного! То есть, все стоят.
А вот если бы логика СЦБ была реализована где-то на стороне, да ещё и клиент был бы неубиваемый - было бы здорово! А там уже и мнемосхему делать можно!))
kemal, С учётом того, что библиотека будет выполнятся на том же самом серваке, а связь по тем же самым каналам, то толку никакого. Ну разве что нагрузка на этот самый канал возрастёт.
Ну это как посмотреть.
Во первых, если на "внешний АРМ" перейдут все дежурные, то это минус несколько игроков на сессии. Ведь задумка в том, чтобы логика СЦБ реализовывалась на отдельном сервере и АРМ дежурных подключались бы к нему. Да, канал связи от админа сессии до этого сервера - слабое место. Тут остаётся надеяться только стабильность работы канала админ - сервер аурана и сервер аурана - сервлет (локалхост? В любом случае можно надеяться, что "внутри" каналы лучше работают). А вот уже канал связи сервлет - сервер СЦБ не такой критичный. Он всё равно будет работать поверх HTTP и посылать только сообщения.
Во вторых, для АРМ дежурного нужно на много меньше информации для синхронизации. Им просто не нужна "потоковая" составляющая. Более того, после перезахода я сразу начинал строить маршруты, не дожидаясь полной загрузки данных.
Ну и в третьих - вынос логики наружу. Больше простор для реализации плюшек, да и скриптам, может, легче будет. Нужно только "события" вытащить.
события чего? Проследования изостыков/светофоров на сервере?
Да.
Но лучше не на сервере, а на клиенте, который управляет этим составом. Иначе возможны ложные перекрытия светофоров прямо перед игроком, что и можно наблюдать при текущей архитектуре.
kemal, составы по всей карте ездят только на сервере. У клиентов они ездят только в пределах видимости игроков, вне её - удаляются (но к сожалению не всегда, от этого бывают "составы - призраки"). Потому и была сделана привязка именно к серверу - у клиентов поезда, кроме поезда игрока, "ездят где хотят и как хотят"
TRam_, они не удаляются, а просто тупо стоят на месте. А kemal хочет сделать всё тоже самое, только штаны через голову.
кроме поезда игрока
Вот это самый ключевой момент.
---------- Сообщение добавлено в 00:37 ---------- Предыдущее сообщение размещено в 00:26 ----------
Эрендир, вот не надо! Как ни крути, а у игрока, который управляет составом, информация о нём более актуальная, чем у сервера. Или ты считаешь нормальным самопроизвольное перекрытие светофора прямо перед носом?
Алсо, https://youtu.be/8C0iqwAzqSo?t=1h26m30s КАГ???
kemal, то есть ты предлагаешь повесить мониторинг того, сидит ли в подъезжающем поезде игрок, и если сидит, то только в этом случае обрабатывать его проезд и рассылать остальным? Правильно понял?
А что делать с составами, которые без машинистов катятся? Или с составами, игрок которых вылетел? Кто будет сообщать серверу, что этот состав теперь нуждается в синхронизации по нему самому, а не по игроку?
Касательно перевода стрелок - если стрелки переведутся у игрока правильно, это соовсем не гарантирует, что состав не сойдёт на сервере (и из этого сойдёт у всех остальных). Тогда придётся делать некий сумматор состояний сервера и игрока, но... У нас и так канал едва справляется с рассылкой скоростных ограничений при проездах светофора с сервера, а тут нужно дублирование сообщения о проезде каждого светофора от каждого игрока на сервер, а потом его рассылка всем, кроме сервера и этого игрока...
---------- Сообщение добавлено в 23:53 ---------- Предыдущее сообщение размещено в 23:47 ----------
Ну и серверу таймаут события(?) если игрок не может его отослать.
Возможно то, что я сейчас напишу, невозможно внедрить в архитектуру sU без правки напильником, так как изначально это придумывалось для моей сигналки, но всё же.
kemal, то есть ты предлагаешь повесить мониторинг того, сидит ли в подъезжающем поезде игрок, и если сидит, то только в этом случае обрабатывать его проезд и рассылать остальным? Правильно понял?
Да, типа того. Просто у меня это реализуется автоматически (обрабатываются не триггеры, а составы. Соответственно, "не свои" составы просто пропускаем).
А что делать с составами, которые без машинистов катятся? Или с составами, игрок которых вылетел?
Все "ничейные" составы на сервер. Он же эти составы обрабатывает, соответственно и взаимодействие с сигналкой обрабатывать тоже ему.
Кто будет сообщать серверу, что этот состав теперь нуждается в синхронизации по нему самому, а не по игроку?
Вот тут не знаю. У себя буду надеяться, что привязка машинист - игрок вовремя отвалится и обработка состава уйдёт на сервер.
Касательно перевода стрелок - если стрелки переведутся у игрока правильно, это соовсем не гарантирует, что состав не сойдёт на сервере (и из этого сойдёт у всех остальных). Тогда придётся делать некий сумматор состояний сервера и игрока
Вот тут да, согласен. Хотя, с другой стороны, чем эта ситуация лучше перевода стрелки на сервере, когда у игрока поезд ещё не проехал?
И да, это не требует дополнительных затрат на синхронизацию, так как маршрутизация (в отличии от децентрализованной сигнализации) полностью остаётся на сервере.
но... У нас и так канал едва справляется с рассылкой скоростных ограничений при проездах светофора с сервера...
Вот тут ещё хотелось бы добавить кое-что. По моему мнению существующий подход избыточно грузит канал связи. Сейчас при, например освобождении блок-участка, сервер обновляет несколько предыдущих светофоров и затем для каждого рассылает на клиенты новое состояние. Гораздо лучше было бы синхронизировать только события наезда/съезда, а обновления состояний рассчитывать на каждом клиенте.
---------- Сообщение добавлено в 01:04 ---------- Предыдущее сообщение размещено в 01:02 ----------
а тут нужно дублирование сообщения о проезде каждого светофора от каждого игрока на сервер, а потом его рассылка всем, кроме сервера и этого игрока...
Зачем??? Бродкастом всем от игрока, управляющего составом. Таким образом сигналка становится децентрализованной.
Вот тут не знаю. У себя буду надеяться, что привязка машинист - игрок вовремя отвалится и обработка состава уйдёт на сервер.
Сервер будет непрерывно проверять, какие составы никому не назначены, правильно понял?
обрабатываются не триггеры, а составыв sU обрабатываются массивы составов над триггером. Потому что их может быть два, в случае манёвров в зоне триггера.
сервер обновляет несколько предыдущих светофоров и затем для каждого рассылает на клиенты новое состояние.проблема как раз в том, что клиенты не могут достоверно проверить свободность или занятость пути. Это у тебя всё в этом плане пронумеровано, а у меня поддерживается сцепка и расцепка на перегонах, например. Когда на блок-участок въехал один поезд, а выехало два. И тут без перепроверки занятости пути для смены показания не обойтись никак.
Сервер будет непрерывно проверять, какие составы никому не назначены, правильно понял?
Ну... Можно и так сказать. У меня в каждой итерации происходит World.GetTrainList(). Соответственно, там же можно сделать проверку чей это поезд и нужно ли его обрабатывать. Как это можно сделать у тебя - не знаю.
проблема как раз в том, что клиенты не могут достоверно проверить свободность или занятость пути. Это у тебя всё в этом плане пронумеровано, а у меня поддерживается сцепка и расцепка на перегонах, например. Когда на блок-участок въехал один поезд, а выехало два. И тут без перепроверки занятости пути для смены показания не обойтись никак.
Эм.. Чёт тут я не до понял твой посыл...
Чего у меня пронумеровано?
Да и что ты подразумеваешь под проверкой занятости? Разве "волна обновления" автоматически не подразумевает проверку занятости?
Разве "волна обновления" автоматически не подразумевает проверку занятости?
проезд игроком светофора локально не означает проезда этим игроком на сервере (или другом клиенте). Если подать сигнал проезда от игрока на сервер, то на сервере может обнаружится совершенно пустой блок-участок, светофор перекрываться не будет (если это например проходной). Аналогично и с "волнами" при покидании поездом блок-участка, когда светофор может навсегда остаться закрытым (если событие пришло раньше)
Гладко было на бумаге, а потом попёрли баги.
Если подать сигнал проезда от игрока на сервер
Нет никакого сервера! Для сигналки все игроки равнозначны.
Перекрытие светофора по наезду не нужно перепроверять. Если от игрока пришло сообщение, что он наехал на светофор, то это значит что он точно на него наехал, ему лучше знать. Вот со съездом сложнее. Но и тут можно сделать у сообщения приоритет выше. То есть если пришло сообщение, что поезд съехал со светофора, а локально это не так, то мы его (поезд) у себя игнорируем.
Эрендир, чем это хуже существующих багов?
чем это хуже существующих багов?
Сложностью реализации. В остальном всё почти всё тоже самое. Да, безусловно обработку наезда, съезда стоило бы перенести на клиента для тех поездов, что с этого клиента управляются. Только нагрузка на канал увеличивается, ибо сначала надо отправить сообщение об изменении серверу, а потом с него разослать всем. Это явно не способствует уменьшению пинга. Не забывай, что при децентпализации всегда требуется больший канал. К тому же, помимо сложности реализации, ты получаешь кучу подводных камней. Классический пример с рождением неопределённости: Поезд на клиенте наезжает на светофор. Клиент обрабатывает это дело, так как это его поезд. При этом, имеем пинг около секунды. Через пол секунды после наезда этот клиент отваливается (BSOD или свет выключили. Да всяко бывает). Сервер (имею ввиду клиента выполняющего роль хоста) получает событие, что клиент отвалился и берёт обработку поезда на себя. В этот момент на сервере этот поезд съезжает со светофора. Но сервер ещё ничего не знает о том, что клиент на него наехал, так как сообщение от него придёт (если вообще придёт) только через пол секунды. Таким образом порождается неопределённость, которую очень сложно обработать и практически не возможно исключить. Да, пример из разряда маловероятно, но ведь вероятно. Да и сам пример отражает лишь сам процесс получения этой самой неопределённости.
Пример номер два. Не такой классический, но очень вероятный. Это, так любимые Tram_'ом проверки РЦ. Где эту проверку проводить? Ведь у всех клиентов обстановка разная. Причём, чем больше пинг, тем больше неопределённость. Да ещё и поезда призраки, которые любят мотаться на клиенте, порождая кучу событий наезда и съезда. Избавится от этой неопределённости также практически не возможно. А её вероятность уже очень высока. Примеров ещё можно приводить кучу. И все решения этих затыков требуют пристального внимания, и ресурсов на пару с каналом. Что опять же снижает производительность и увеличивает нагрузку на канал, хотя сама идея призвана сделать противоположное. В итоге, желаемый результат не достигнут, и багов меньше не стало, а может и больше. Да, светофор перестанет закрываться перед носом, но как он будет вести себя в глобальном масштабе, вопрос очень спорный.
Не, я тебя не отговариваю. Хозяин барин. Если ты сделаешь, и у тебя реально получится, ну что же, сниму шляпу.
Вспоминаю МСТС, с его воображаемым мультиплеером, в котором игроки разговаривали по скайпу и представляли, что они не одни на карте
гарантируется ли совпадение игровых Id у разных игроков?
Опыт показал, что не совпадают. У всех совершенное разные.
Отсюда встаёт вопрос, а как же тогда идентифицировать объекты? Если использовать тег autoname ну совсем не хочется.
Ввёл для каждого объекта свои Id (привет, z7). Вроде работает, но...
Берём файл multiplayergame.gs и читаем
//================================================== ===========================
// Name: BroadcastGameplayMessage
// Desc: Broadcasts a multiplayer 'gameplay' message over the network to every
// client. Only valid during multiplater games. This will broadcast a
// script message when it is recieved on the client.
// Parm: msgMajor - The major component of the broadcast message
// Parm: msgMinor - The minor component of the broadcast message
// Parm: data - The data of the broadcast message. On the recieving end the
// native code will add the sending users profile name with the tag
// "__sender". Do not use any tag names that begin with a double
// underscore "__" on send, they will be stripped.
//================================================== ===========================
public native void BroadcastGameplayMessage(string msgMajor, string msgMinor, Soup data);
Судя по тексту, вроде как, сообщения должны ходить между всеми пользователями. На практике сообщения ходили только между клиентом и сервером, а между клиентами - нет. Что тут может быть не так?
kemal, как это не ходит. Всё там ходит. С чего ты взял, что не ходит?
Добавил в скрипт, чтобы все приходящие сообщения писались в лог. В логах клиентов сообщения только от сервера.
kemal, ну так при бродкасте с клиента клиентам будет приходить сообщение сервера. Принцип такой: клиент отправляет серверу, а он рассылает всем остальным.
А это не должно, как минимум, происходить нативно?
---------- Сообщение добавлено в 16:54 ---------- Предыдущее сообщение размещено в 10:30 ----------
А всё же, может кто-нибудь однозначно ответить на вопрос, формулировка "to every client" означает, что сообщение будет доставлено от одного клиента другому клиенту, или нет?
kemal, когда отсылаешь броткаст с клиента он рассылается абсолютно всем. Просто в __source будет не имя клиента, который рассылал, а имя сервера. А вот на сервере как раз будет имя того самого клиента.
Понятно... Придётся дебажить дальше. Хотя, совешенно не понятно, в какую сторону. Потому как во время теста между клиентами сообщения не ходили.
---------- Сообщение добавлено в 19:25 ---------- Предыдущее сообщение размещено в 19:18 ----------
Кусок скрипта из светофора:
else if(id=="ForceUpdate"){
kmLib.LibraryCall("ForceUpdate", stringParam, objectParam);
if(MultiplayerGame.IsActive()){
Soup SyncSoup=Constructors.NewSoup();
SyncSoup.SetNamedTag("function", "ForceUpdate");
SyncSoup.SetNamedTag("id", MyId);
MultiplayerGame.BroadcastGameplayMessage("kmSigMP", "Sync", SyncSoup);
}
}Кусок скрипта из библиотеки:
void SyncHandler(Message msg){
Soup soup = cast<Soup>msg.paramSoup;
if(!soup)return;
string function=soup.GetNamedTag("function");
Str.ToLower(function);
Interface.Print("SyncHandler");
soup.Log();
int id=soup.GetNamedTagAsInt("id", -1);
if(id<0)return;
int nmb=Signals.Find(id);
kmRC sign=cast<kmRC>Signals.DBSE[nmb].value;
if(!sign){
return;
Interface.Print("sign not found");
}
if(function=="forceupdate"){
FullUpdate(sign);
}
...
}
kemal, должно всё работать. У меня в маршрутизации такого нет, ибо на сервак отправляется команда, а он уже рассылает синхронизацию. Но вот в ПОНАБ обработка идёт на том клиенте, которому принадлежит состав наехавший на датчик. И там соответственно броткаст клиент рассылает. И ведь работает же. По крайней мере, когда тестили, всё работало.
Обнаружилось странное поведение правила в мультиплеере. Ощущение такое, что на клиенте правило не получает своих настроек. В чём может быть дело?
И, чтобы два раза не вставать, что скрывается за фразой Loading network data?
Ощущение такое, что на клиенте правило не получает своих настроек. В чём может быть дело?если вручную запрашиваешь, может слишком много данных за раз либо слишком часто опрашиваются.
kemal, что за правило? Что именно не работает?
За loading network data скрывается синхронизация всех стнхронизируемых объектов. Положение стрелок, формировпние и расположение составов и привязки игроков. Настройки объектов, правил и тп не синхронизируются.
если вручную запрашиваешь
Я ничего не запрашиваю. Я просто надеюсь, что SetProperties выполнится у всех одинаково.
---------- Сообщение добавлено в 23:56 ---------- Предыдущее сообщение размещено в 23:52 ----------
Эрендир, правило ручных стрелок (то самое). Сегодня ребята проверяли - говорят, что на клиенте не работает. Все стрелки воспринимает как централизованные. Именно такое поведение у правила и должно быть, если настроек нет.
Кстати, с разной работой правил на сервере и клиенте я уже сталкивался. Если переименовать машинистов, то работает это только на сервере.
значит аурановцы так сделали, что правила вызывают setProperties только на сервере...
Да... Печально.
А если я сделаю себе GetProperties и всё это клиенту отправлю, нормально?
---------- Сообщение добавлено в 21:29 ---------- Предыдущее сообщение размещено в 20:42 ----------
Теперь вопрос, как правильно это сделать. Я заглянул в sU. Это мне всё это тоже надо делать?
kemal, для начала надо разобраться что и как работает и как вообще запускается клиент, а потом уже что-то делать
Сначала загружается сессия как обычно. То есть, создаются все объекты, для всех вызываются SetProperties, потом World ModuleInit, ну в общем как всегда. А дальше стартует правило мультиплеера. И вот оно, во время Loading Network Data удаляет с карты все составы, машинистов и ещё что-то, а затем создаёт их заново по данным полученным с сервера. Там же синхронизируются положения стрелок и тп. Всё остальное остаётся не тронутым. Что происходит с правилами я не знаю, не было нужды разбираться, может они тоже пересоздаются. Так что надо разобраться для начала, а не воротить огород.
И как ты предлагаешь разбираться?
Это мне всё это тоже надо делать?
что именно, синхронизацию показаний и ограничений скорости? Если о сигналке - да, надо. Потому что у клиентов вне зоны видимости поезда не ездят.
Я сейчас не об этом. У меня в правиле достаточно только начальные настройки переслать. А в сигналке меня поразило, что нужно ещё менеджер сессий (или как его там?) подключать и что-то с ним делать.
Он нужен исключительно для вылавливания момента коннекта юзера к сессии или запуска сессии. Это более разумно чем периодические проверки MultiplayerGame.IsActive() хотя смысл тот же.
void MultiplayerSessionHandler(Message msg)
{
if((msg.minor == "UsersChange" or msg.minor == "ClientReady") and MultiplayerGame.IsActive() )
{
if(!MP_started)
{
MP_started = true;
if(!MultiplayerGame.IsServer())
{
MP_NotServer = true;
AddHandler(me,"sU_signals", "mult_client","MultiplayerClientHandler1");
Waiter();
return;
}
ServerInitBase();
AddHandler(me,"sU_signals", "mult_server" ,"MultiplayerServerHandler1");
}
}
}
Sandrilyon
07.06.2016, 16:11
Возможно ли реализовать синхронизацию положения пантографа для локомотива ВЛ11м?
Powered by vBulletin™ Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot