Pull to refresh

Comments 7

Интересно. Жаль, мне пока приходится работать со старыми версиями Unity, потому удобные Command и ClientRpc мне будут недоступны ещё долго.
Именно этот туториал меня добил окончательно, и я понял, что написать эту главу должен сам. Говорящий пользуется, как и многие, [SyncVar], которые работают на пень через колоду: с прерывистым движением, не всегда, и через [SyncVar] никогда не будет вращаться башня.
я так и не понял что не так с SyncVar.

1. Прерывистое движение — это норм. Данные доходят через какое-то время, поэтому нужно интерполировать
2. Что значит не всегда?) Есть пример?
3. У того же автора выше все вращается и ездит + плавно.
В моём частном случае:

1) Я в курсе про прерывистое движение, и где там налаживается частота обмена, и в какой момент проекта полагается вносить сглаживание варпов. В данном случае мне оказалось удобнее регулировать частоту по факту изменения ввода пользователя.

2) Я затёр ситуацию в этюде, где синхронизации не было вообще. Это была последняя капля перед миграцией этюда на Cmd/Rpc.
Я не вёл этюд в версионке, поэтому ту версию я не восстановлю

3) У того же автора в туториале прыгают капсулы с прибитым насмерть гвоздями параллелепипедом наперевес, и движения башни-ствола там рядом не стояло. Моя попытка внести положение башни-ствола в SynVars успехом по синхронизации этого положения не увенчалась. Попытка использовать для этого Cmd/Rpc увенчалась при первом же подходе.
Автор решил изобрести велосипед (с квадратными колесами).
Тут очень топорное решение, даже не лерпится перемещение от одной позиции к другой. То есть, оно будет дерганым.
Хотите серверного авторитета — купите копеечный плагин SmoothSync, в котором уже решены все проблемы движения, в том числе есть делегат validateStateMethod, в который можно всунуть серверную проверку на читерство.
Проверки в Cmd: isServer и в Rpc: isClient излишни. Cmd всегда исполняется на сервере, а Rpc всегда исполняется на клиентах. То есть, не может в Cmd быть «не сервер», а в Rpc «не клиент».
Однако авторы Unity3D рекомендуют физические расчёты осуществлять внутри FixdUpdate()

Расчеты Rigidbody, вообще-то!
Но автор далее двигает трансформ, хотя его как раз надо двигать в Update.
С респавном игроков мы можем разобраться позже, а сейчас в педагогических целях давайте себе позволим один костыль.

Поставить NetworkStartPosition. Двигать в Awake ручками — это действительно, костыль.
Говорящий пользуется, как и многие, [SyncVar], которые работают на пень через колоду: с прерывистым движением, не всегда.

Лолшто? SyncVar работает идеально, если понимать, как им пользоваться. Так что не надо тут.
Вот у меня такой вопрос: с чего вы решили, что я в 2015 сэкономил на ассете авторства 2017?

Кстати, подскажите, за что это вы рекомендуете transform двигать в update?

И ещё вопрос: почему во время моей борьбы с SyncVar в его доке было сказано, что синхронизируется всё идеально?
Хотя позже оказалось, что он только спускает с сервера на клиента, никогда наверх, качает достаточно редко и сглаживание не предусматривается в принципе.
Only those users with full accounts are able to leave comments. Log in, please.