Dragon armor

Посмотри на relativePosition. Четыре же. А это 6. И на лицо опять экономия байт. Вместо 24 байт без каких-либо механизмов ужимаются в 10. Ну может 14 байт - это много. Очень много. Пихать мёртвую говядину в каждый пакет - не много. А 14 байт много. Ну пусть будет увеличение размера пакета на 14 * 12 (или сколько там корабликов) 168 байт (и то не каждый пакет), даже в MTU 1500 байт укладывается вместе с остальными данными, которых примерно 250 байт.

@Monstrofil А методов и свойств не больше 255 получается? Там механизм другой. А точно так? Тогда только смотреть, как методам назначаются индексы. Там есть функция подсчёта md5 хеша по всем названиям, если её не удалили. Можно туда поставить брекпойнт и все параметры вытащить.

Да это макросы, это же очевидно. Поищи в исходниках по avatarUpdate и увидишь, что названия ими генерируются, как и параметры, которые они принимают/отправляют. Как вариант - количество базовых методов изменилось, вот и поменялись начальные идентификаторы у свойств и методов. 0x44 и 0xa2 - не константы, уже писал это. Они генерируются в зависимости от количества свойств/методов у энтити. Можно даже поискать в исходниках, хотя это могло измениться и искать, как именно теперь назначаются индексы, надо в исполняемом файле. Например, EntityMethodDescriptions::checkExposedForSubSlots.

@m3ybach Сделать можно, но вряд ли будет легче. Принцип-то тот же. Позиция передаётся тремя float, а направление пожато до четырёх байт. Не, не зависит. От реализации может зависеть, в кораблях тоже решили съэкономить 8 байт, непонятно только, зачем.

@Monstrofil Если сравнивать с танками, то для свойств остаётся один байт, тот, что 0х01. Потому что предпоследний байт - строка нулевой длины. Если смотреть на свойства, то единственное, что подходит - lastGeneratedTransactionNumber. Тогда строки не будет. Но если посмотреть на флаги свойств, то тут только BASE, а если бы были свойства для клиента, то было бы BASE_AND_CLIENT как в танках. <Properties> <accountDBID_s> <Type> STRING </Type> <Flags> BASE_AND_CLIENT </Flags> <Persistent> true </Persistent> <DatabaseLength> 96 </DatabaseLength> <Identifier> true </Identifier> </accountDBID_s> <loginPriority> <Type> UINT32 </Type> <Flags> BASE </Flags> </loginPriority> </Properties> Клиенту здесь передаётся только accountDBID_s. Тебе надо в исполняемый файл лезть и искать место, где идёт создание энтити. И уже по месту смотреть, что именно с данными происходит.

Там, насколько помню, этого нет. Появилось позже и это общее между танками и кораблями, либо похоже. Ни разу эта строка мне не попадалась и что там может быть - не знаю. Тоже покажи этот пакет. Там как минимум одно свойство есть. И в танках нет единицы в конце Login. А ты привёл пример энтити Account? Ну покажи def-файл его. 0x0F - это что-то в свойствах. Оно точно входит в это сообщение, судя по указанному размеру в самом сообщении.

@StranikS_Scan Тоже экономишь три байта на размер?

Да, так понятнее. Внезапно, размер пакета. Ленишься в дизасемблере сидеть. Строка. Её длина равна нулю, поэтому дальше данных нет. А дальше начинаются свойства. У тебя def-файл есть же. Прикрепи или скопируй сюда от логина, он должен быть самым коротким. Тогда будет понятно назначение 0x0f. Сам уже не помню где. Это в определении длины пакета. Либо при создании. Там действительно трудно ориентироваться, пока не знаешь, что именно искать. Брекпойнт ставишь и в лог выводишь все параметры. Там есть единая функция создания у них. Порядок вызовов покажет их идентификатор. Либо перед выходом из той функции, что ещё лучше, потому что результат функции будет id (вроде бы, уже мог и забыть). Спорный, на мой взгляд, способ уместить данные. Ты разобрался уже, что количество байт, в котором указывается размер сообщения, может быть от 1 до 4? То есть, это размер размера сообщения. Когда размер больше, чем может быть указано в, кхм, размере, создатели BigWorld сделали так, как ты описал. Где-то тоже было в исходниках, но даже примерно найти не могу, куда копать. Посмотри тут InterfaceElement::specialExpandLength.

Из исполняемого файла. Актуальны для определённой версии. И они считаются от количества методов и свойств. Это не константа. На момент того комментария не было мне это известно, поэтому и писал их константами. Приведи полный пример пакета с флагами и счётчиками без blowfish данных. В исходниках BigWorld есть этот момент. Там всё есть, что нужно. Точнее, основная база. Корабли были позже, поэтому там были изменения какие-то, утверждать не буду, но не одинаково. Но часть неизменна. Размер сообщения указывается только для тех сообщений, размер которых изменяется. Если константа, то не ставится. У тебя парсер def-файлов есть? Ты смотрел в исполняемом файле, как он происходит? В корабликах свои особенности могут быть. Есть такое. Ты из исполняемого файла достал базовые методы? Хз как их правильно назвать, те, что создают энтити и прочие.

Флаги не менялись. Были лишь добавлены новые. Видимо, опечатка (хотя не смотрел). Да. Исходники BigWorld рекомендую посмотреть. Как и по следующему вопросу. Потому что шифрование и логика сетевого протокола не менялась кардинально с тех времён. Добавлю предыдущий ответ. Клиент отрисовать может заранее, чтобы меньше видно было лаг ответа. Поэтому возникают такие темы и видео, где чётко видно трассер, влетающий в борт, но сбивается гусеница. Это не заговор, а предсказание клиента. Иначе без этого всё воспринималось бы как ватность в управлении и отзывчивости игры. А на сервере всё может быть совсем иначе. Клиент на это никак повлиять не может. FF FF FF 0F? Packet number.

Либо сервер явно указывает, какая энтити на данный момент активна (например, через selectEntity), либо сами (внутренние) функции устанавливают энтити активной (множества функций начинающихся с avatarUpdate* и другие). Энтити игрока устанавливается через selectPlayerEntity.

Через entityCreate энтити создаётся и используется дальше пока не будет создана новая.

Микроскопическая проблема и полный тупик. У меня не получается. Не понимаю, что надо сделать, чтобы получить вектор направления. Если у меня есть yaw и pitch, как из них сделать вектор направления? Или не так надо? А нужно из матрицы? Или это отдельный параметр? Но turret_yaw используется для получения координат крепления орудия. Что надо сделать, чтобы получить вектор направления? При этом, если отдельно отправлять yaw/pitch в gunAnglesPacked для остальной техники, башня вращается почти правильно (зацикливается на переходе 180 градусов, пока причину бага не искал). У меня не получится так сделать. Только из модели (либо xml файла) могу получить координаты. Правильно понимаю, что координаты техники - это глобальные координаты. А в xml находятся локальные. Соответственно, чтобы получить локальные (или это уже глобальные будут, если умножить на позицию техники?) координаты орудия и башни, делать надо так. turret_pos = vd.chassis.hullPosition + vd.hull.turretPositions[0] turret_matrix = Math.Matrix() turret_matrix.Set_Pos(turret_pos) turret_matrix.Rotate_Y(self.turret_yaw) turret_matrix.postMultiply(veh.matrix) gun_matrix = Math.Matrix() gun_matrix.Rotate_X(self.gun_pitch) gun_matrix.Set_Pos(vd.turrets[0][0].gunPosition) gun_matrix.postMultiply(turret_matrix) veh.matrix - это предполагается положение техники, пока что единичная матрица. Их не надо в данном шаге вычислений? hullPosition и turretPositions можно сложить? Они же не изменяются в локальной системе координат? Или надо перейти в локальную систему (точку прицеливания перевести в локальную) и считать углы там? Кто-нибудь объясните, что надо сделать.

startPoint += player.vehicleTypeDescriptor.hull.turretPositions[0] + player.vehicleTypeDescriptor.turret.gunPosition А так можно? А то матрицы тут перемножаю, чтобы точку получить. Ясно. А зачем так? У клиента же есть скорость снаряда. Почему просто не передать направление?

@ktulho Так направление выстрела или скорость? Как в одном векторе объединить две разных величины? У меня предположение, что это точка на ландшафте. Проверить не могу, cellapp пока что не может делать рейкаст (или как эта штука называется). И ландшафт при дампе уехал куда-то, поэтому не понятно, заканчивается точка на ландшафте или где-то ещё. А начальная точка примерно отсюда начинается.