Телепорт мобов
 

Подскажите, в каком направлении копать.
Есть например босс, Эхо Джайны в 4.3.4. У неё есть спелл "Скачок" 101812, да и любого другого с этим эффектом, например блинка мага
При срабатывании спелла, она перемещается только на сервере.
То етсь визуально она в клиенте остаётся на месте, но бить её уже нельзя. Так как сервер считает что она далеко. Если начать идти то она сразу появится на том месте и начнет идти к игроку.

Я так понял по коду, что опкод MSG_MOVE_HEARTBEAT должен обновить состояние моба.
Он вроде как отправляется. Проверил парсером пакетов, с сервера этот пакет идёт только для игрока.
С клиента парсер не открывал, писал что не верный пакет. Удалил отправку перед пакетом PackGUID() парсер стал открывать, показывает правильный ID моба и координаты куда он переместился, но в клиенте не какой реакции...
Пытался в IDA посмотреть по номеру опкода, но там брекпоинты срабатывали только при отправки пакета от клиента.
То ли пакет не правильный и клиент его отвергает, то ли это вообще не тот пакет что нужен, то ли в клиенте при получении опкода, нет сравнения именно по числу, там же видимо как и в сервере, вызывается функция обработки опкода по полученному числу с сокета.

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

вам нужно использовать MSG_MOVE_TELEPORT, формат точно такой же, как любой другой MOVE пакет.

Я думал в эту сторону. Просто этот пакет только для класса Player Отправляется. Я и думал что он для мобов не подойдёт. Попробую отправить для моба. Спасибо!

Всё действительно получилось! Ещё раз спасибо!

А почему тогда и в мангосе и в тринити после спеллеффекта SPELL_EFFECT_LEAP = 29
идёт выбор, для игрока отправляется MSG_MOVE_TELEPORT а для моба MSG_MOVE_HEARTBEAT?
MSG_MOVE_HEARTBEAT получается вообще ен нужно отправлять для моба? Это видимо из прошлых реализаций осталось...

Не подскажете ещё, во время прыжка у себя я вижу игрока нормально, а другие видят рывками мои прыжки. Это в какую сторону смотреть? :)

Сплайны?

Ну я думаю это сокрей всего связанно с опкодом или флагом.
При получении CMSG_MOVE_JUMP мы отсылаем всем игрокам SMSG_PLAYER_MOVE.
И уже клиент должен построить плавность прыжка. Не передаются же с сервера попиксельно расёт перемещения игрока.

Вот я смотрю, у Unit есть m_movementinfo (в Object) в котором есть позиция.
А есть просто m_position...
А флаги передвижения только в m_movementinfo.
Чем отличаются позиция в movementinfo от позиции в Unit.
Почему бы не сделать только в одном месте позицию?

чем отличается плеер от моба? правильно, ничем (объектную плеерскую надстройку не будет считать здесь). для этого юнита можно отправлять любые плеерские опкоды. можно хоть MSG_MOVE_STOP слать, с шагом 100 ярдов - и будет телепорт.

почему на мангосе и трините сделано так? я не знаю. просто тот кто это делал - сделал свою работу плохо. затычками. к другим затычкам. отсюда соответствующая репутация (не в обиду всему проекту). ну не суть. я уже забыл, но по моему у клиента есть дополнительный обработчик на телепорт. но по факту все это ерунда, нужно для правильных отрисовок да и только.

насколько я мог понять, сейчас все эти пакеты обрабатываются вообще одним обработчиком. с небольшими дополнительными "вставками" для некоторых опкодов. телепорт как раз в их числе.

изначально мув данные передавались внутри А9 и был соответствующий кейз в клиенте (стадия альфы 2004 и последующие некоторые беты). потом стали добавлять "новые фичи", связанные с мувементом, в виде новых опкодов. вполне резонно было вынести мув блок из А9 в отдельный обработчик и объеденить старые и новые опкоды. в новом варианте видимо по привычке часть данных А9 называют мувблоком, хотя формально их там давно нет, это ошибка.

один из транков моего сервера поддерживает альфу 0.5.3, что называется чисто на поржать :pardon:

Код:

---

function msgBuild(var Buf: TSockBuffer; var m: T_SMSG_UPDATE_OBJECT): longint; overload;
begin
  pkt.InitCmd(Buf, SMSG_UPDATE_OBJECT);
  pkt.AddLong(Buf, m.Count); // count of objects
  pkt.AddByte(Buf, m.UpdateType);

  pkt.AddInt64(Buf, m.Full.GUID);

  Case m.UpdateType of
    UPDATE_PARTIAL:
      begin
        // UPDATE_PARTIAL: partial block
        j:= Length(m.Full.UpdateField);
        upkt.Init(j);
        for i:= 0 to j-1 do
          if m.Full.UpdateField[i].Added then
            upkt.AddLong(i, m.Full.UpdateField[i].Value);

        // UPDATE_PARTIAL: build A9
        upkt.MakeUpdateBlock(@upkt_buf);
        pkt.AddByte(Buf, upkt.blocks);
        pkt.AddArray(Buf, @upkt_buf, upkt.data_ofs);

      end;
    UPDATE_MOVEMENT:
      begin
        pkt.AddInt64(Buf, m.Movement.TransportGUID);
        pkt.AddFloat(Buf, m.Movement.TransportPosition.x);
        pkt.AddFloat(Buf, m.Movement.TransportPosition.y);
        pkt.AddFloat(Buf, m.Movement.TransportPosition.z);
        pkt.AddFloat(Buf, m.Movement.TransportFacing);
        pkt.AddFloat(Buf, m.Movement.Position.x);
        pkt.AddFloat(Buf, m.Movement.Position.y);
        pkt.AddFloat(Buf, m.Movement.Position.z);
        pkt.AddFloat(Buf, m.Movement.Facing);
        pkt.AddFloat(Buf, m.Movement.Pitch);
        pkt.AddLong(Buf, m.Movement.Flags);
        pkt.AddLong(Buf, m.Movement.TimeFallen);
        pkt.AddFloat(Buf, m.Movement.WalkSpeed);
        pkt.AddFloat(Buf, m.Movement.RunSpeed);
        pkt.AddFloat(Buf, m.Movement.SwimSpeed);
        pkt.AddFloat(Buf, m.Movement.TurnRate);

        // moveFlags depended block here

      end;
    UPDATE_FULL:
      begin
        pkt.AddByte(Buf, m.Full.ObjectTypeID); // world object type
...

---

причем я не стал тут реализовывать флаги и дополнительные блоки. вломы =)))

теперь по поводу рывков: смотреть в сторону синхронизации объектов. это довольно сложная для понимания тема и немного хитрая в реализации. боюсь не осилите снаскоку. еще никто не осилил ее ни в одном проекте (кроме одного :secret:), даже близко не подошли. я серьезно. сплайты тут не причем, да.

насчет m_movementInfo: "просто" m_position - выкинуть, правильно - разместить в m_movementInfo, в одном месте, все правильно.

Код:

---

  TTransportInfo = record
    GUID: uInt64;
    Entry: longint;
    Position: C3Vector;
    Facing: single;
  end;
  TSplineFaceData = record
    spot: C3Vector;
    guid: longword;
    facing: single;
  end;
  C3Point = record
    IsPathPoint: boolean;
    Position: C3Vector;
  end;
  C3Spline_CatmullRom = record
    cachedLength: single;
    points: array of C3Point;
    cachedSegLength: array of single;
    splineMode: byte; // MODE_LINEAR = 0x0, MODE_CATMULLROM = 0x1
  end;
  TMoveSpline = record
    flags: longword;
    face: TSplineFaceData;
    start: longword;
    current: longword;
    duration: longword;
    spline: C3Spline_CatmullRom;
  end;
  TMovementInfo = record
    m_lastNetMsgID: longword;
    m_position: C3Vector;
    m_prev_position: C3Vector;
    m_facing: single;
    m_pitch: single;
    m_groundNormal: C3Vector;
    m_guid: longword;
    m_moveFlags: longword;
    m_prev_moveFlags: longword;
    m_anchorPosition: C3Vector;
    m_anchorFacing: single;
    m_anchorPitch: single;
    m_moveStartTime: longword;
    m_prev_moveStartTime: longword;
    m_direction: C3Vector;
    m_direction2d: C2Vector;
    m_cosAnchorPitch: single;
    m_sinAnchorPitch: single;
    m_reDirection: C3Vector;
    m_lastReDirectionSent: C3Vector;
    m_fallStartTime: longword;
    m_fallenTime: longword;
    m_fallStartElevation: single;
    m_currentSpeed: single;
    m_Speed: single;
    m_prev_Speed: single;
    m_walkSpeed: single;
    m_runSpeed: single;
    m_runBackSpeed: single;
    m_swimSpeed: single;
    m_swimBackSpeed: single;
    m_turnRate: single;
    m_collisionBoxHalfDepth: single;
    m_collisionBoxHeight: single;
    m_stepUpHeight: single;
    m_jumpVelocity: single;
    m_spline: TMoveSpline;
    m_waterSurfaceElev: single;
    Transport: TTransportInfo;
    m_timeSkipped: longword;
  end;

  // ===========================================================================
  T_MSG_MOVE_STATE = record
    GUID: longword;
    MovementInfo: TMovementInfo;
  end;

---

чем отличается плеер от юнита? правильно, ничем :yes3: мувемент у них один.

Вот я и хотел узнать, стоит ли выбросить просто m_position, так как по сути из за того что сейчас координаты в двух разных переменных хранятся, сервер работает с m_position а в пакеты вставляются с m_movement, приходится перед отправкой m_movement, да и при получении :) синхронизировать переменные, значит просто перепишу Get..., Set.., UpdatePosition... на movement.

А вот по поводу прыжков, я всё же думаю тут беда с флагами возможна.
Вот я прыгнул, на сервер ушел пакет
По поводу флага Root не уверен, в мангосе и тринити флаг называется MOVEFLAG_FALLING
В парсере пакетов пишет MOVEFLAG_ROOT.

Чар у меня в клиенте летит плавно.
То есть здесь явно нет передачи с сервера координат полёта, клиент сам рассчитывает, при приземлении может быть небольшое дёрганье, вот тут как раз видимо из за синхронизации.
По поводу синхронизации картинки между клиентами я прочёл много... так как делал сервер для флешь игрушки небольшой.
Но тут вопрос не в том что картинка не совпадает. А в том что картинка идёт рывками. Раньше же, даже хотя бы в 3.3.5 не было такого. Да, рассихнронизации была, за прыжок разок дёргался бывало чар или после приземления, но пока летел было плавно.
Сейчас же он вообще не летит! Он просто дёргается, пропадает появляется в другом месте несколько раз за прыжок.
Видимо с сервера летят пакеты игрокам с местоположением.

Сейчас при получении любого MOVE пакета, уходит опкод MSG_PLAYER_MOVE с теми же данными. То етсь на прыжок ушел пакет
То есть флаги вроде как передаются... Почему же клиент других игроков не рисует точно так путь полёта :) Завтра ещё поэкспериментирую, может лишние пакеты летят во время прыжка, которые показывают расчётные координаты сервера.

Когда сам прыгаешь - да, тут сервер не играет роли. Когда видишь других прыгающих - это, само собой, то что пришло с сервера.
Подергивание при приземлении - это результат рассинхронизации (или, маловероятно, неверных флагов) и обработки СMSG_MOVE_FALL_LAND, которые шлется при касании земли после падения.

Касательно дерганий во время прыжка - таких не замечал. Вообще, вижу здесь шифрующегося юзера тринитей, так что признавайся - так это или нет xD

Вижу вот по какой причине:
Вроде бы с 4.2.x пакеты движений и SMSG_UPDATE_OBJECT стали битстримиться, также если раньше они передавали всю возможною информацию о движении объекта, то потом - только частично, с необходимыми для конкретной ситуации данными.
Таким образом, клиент шлет флаги в начале пакета, затем в зависимости от них сервер идентифицирует данные.

Флаги выглядят так:
В мангосе такая штука хранится в MovementInfo и она же посылается в SMSG_PLAYER_MOVE, в тринитях она не хранится, а додумывается на основе имеющихся данных - мув флагов и тп.
Как выяснилось, наличие или отутсвие MOVEFLAG_FALLING никак не связано с присутствием fall information в пакете, а так как в тринитях об этом не знают, то и получается, что либо не она не шлется, когда она нужна, либо шлется неверная. Поэтому я и замутил эту штуку со StatusInfo.

Я не шифруюсь, я раньше в темах писал что тринити юзаю :)
Просто там спрашивать не у кого, то ли не кто не знает то ли просто не кто не отвечает :)
А По поводу телепорта мобов, я компили мангос и проверял, тоже не работало, вот и не написал что тринити. А вот прыжки... да, что то я не проверил в мангосе.

по поводу movementinfo япочти все под мангос переделал, так как я понял что когда тринити это выдрали у мангоса, они не туда это запихнули как минимум, у них пакеты исходящие не перемешиваются... вот только структуру эту я и не перенёс :) Сегодня попробую перенести.

Да, перенёс ещё немного кода с мангоса в тринити по мовементам и прыжки теперь плавные :)
Всё таки плохо, когда в тринити копируют код, даже не думая что он делает и как работает :)
Всем спасибо за помощь!

все мув пакеты нужно передавать как есть, со всеми флагами и соответствующими им дополнительными блоками. за исключением timestamp (у близзов оно называется m_moveStartTime), которое является одним из элементов синхронизации и расчитывается на сервере.

Тринити копировали не с мангоса, я уже точно не помню откуда. Идентичная Тринитям наработка была в Strawberry, но там не было этой фичи StatusInfo.

Вообщем я не думаю что тринити это сделано само, и те у кого они даже взяли, раз там сделано так же, то они тоже сделали не сами, раз оно у них есть но не работает значит они при копировании не до конца понимали как оно должно работать :)

Я вот ещё заметил, что Timestamp в пакетах от клиента не соответствует Timestamp пакетов от сервера :)
Но вроде бы работает...

В тринити класс WorldObject наследует класс Position чреез класс WorldLocation. Так же как и Transport.
А значит вся инфа в movementinfo о положении юнитов и транспорта дублируется, но из за наследования нужно много кда перелопатить что бы все переделать :) А структура movement в тринити похоже не заполняется, перед отправкой приходится заполнять...