Геодата ОФФ сервера

Мои предположения на счёт структуры файла геодаты.
Для анализа возьмём файл 16_21_conv.dat

Сначало идёт заголовок 18 байт:
Смещение Значение Комментарий
0x00 0x10 (16) Ид области по Х
0x01 0x15 (21) Ид области по Y
0x02 0x0080 Во всех файлах одинаково
0x04 0x0010 Во всех файлах одинаково
0x06 0x000372D8 Пока не знаю
0x0A 0x0000FF19 Пока не знаю
0x0E 0x0000F257 Пока не знаю

Далее собственно данные.
В каждом файле описано 65536 (256x256) зон. Длина зоны может быть разной (минимум 6 байт).
У каждой зоны есть ид описывающий её структруру. Ид занимает 2 байта, может быть 0x0000,0x4000,
0x4100, 0x4200 и т.д. Каждая зона описывает 64 (8x8) элементов, хотя у элемента может быть несколько высот (наверно так
описываются многослойные карты). У зоны с ид 0x000 есть только две коорд. высоты, возможно предпологается что у всех элементов
зоны высота одинаковая.

Зона 0x0000:
Ид Длина Пример
0x0000 6 байт 00 00 30 F2 30 F2
| | |
| | ------------ 0xF230, это координата Z = -3536
| ------------------- 0xF230, это координата Z = -3536 зачем тут две координаты пока не понятно
-------------------------- Ид зоны 0x0000

Зона 0x4000 (64 координаты)
Ид Длина Пример
0x4000 130 байт 40 00 0F E4 E7 E3 .....
| | |
| | ------------ 0xE3E7, это координата Z = -7193
| ------------------- 0xE40F, это координата Z = -7153
-------------------------- Ид зоны 0x4000

Зоны 0x4100,0x4200 (64 элемента, каждый элемент может содержать несколько координат)
Ид Длина Пример
0x4100 Переменная 41 00 01 00 06 E4 01 00 E6 E3 .....
| | | | |
| | | | ------------ 0xE3E6 это координата Z = -7194 элемента 1
| | | ------------------- 0x0001 количество координат у элемента 1
| | ---------------------------- 0xE406 это координата Z = -7162 элемента 0
| ----------------------------------- 0x0001 количество координат у элемента 0
------------------------------------------ Ид зоны 0x4100

Немного покапавшись в коде ОФФ сервака нашел как он преобразовавает файлы геодаты при загрузке.
Он создаёт для каждого файла три буфера (через CreateFileMapping и MapViewOfFile) с названиями
L2World_GeoDataZones..., L2World_GeoDataCells... L2World_GeoDataCellOffest...

Дамп этих буферов для файла 16_21_conv.dat

в 40h+ блоках не 64 элемента, а 40h+ высот ^^

туплю, сейчас код выложу

При обработке зоны с кодом 0x0000 оно выполняет интересный код:

Например зона 00 00 30 F2 30 F2

.text:0047B562 mov ecx, [esp+64h+var_10] ;----- Получаем значение переменной Z = 0xF230
.text:0047B566 lea edx, [ecx+ecx] ;----------------- Z = Z * 2
.text:0047B569 and edx, ds:6BBFB0h ;-------------- Z = Z and 0xFFF0 (0xFFF0 записано по адресу ds:6BBFB0h)
.text:0047B56F or [edi], dx ;------------------------- Сохраняем Z в буфер
.text:0047B572 mov cx, ds:6BBFA4h
.text:0047B579 or [edi], cx ;------------------------- Z = Z or 0x0001 (0x0001 записано по адресу ds:6BBFA4h)
.text:0047B57C mov dx, ds:6BBFA6h
.text:0047B583 or [edi], dx ;------------------------- Z = Z or 0x0002 (0x0002 записано по адресу ds:6BBFA6h)
.text:0047B586 mov cx, ds:6BBFA8h
.text:0047B58D or [edi], cx ;------------------------- Z = Z or 0x0004 (0x0004 записано по адресу ds:6BBFA8h)
.text:0047B590 mov dx, ds:6BBFAAh
.text:0047B59A or [edi], dx ;------------------------- Z = Z or 0x0008 (0x0008 записано по адресу ds:6BBFAAh)

В итоге из 0xF230 получается 0xE46F и это значения записывается в буфер L2World_GeoDataZones

угу, h = (h&0xf); => выдирание битов проходимости

Господа разработчики, объясните пожалуйста мне идиёту для чего вам надо расшифровывать геодату оффсервера? как я понял все разработчики проектов базирующихся на С1 оффке, выдирают некую однослойку, из клиента, я так понял из текстур клиента, может быть стоит не потрошить эту геодату, а определиться с тем форматом, который будет понятен яве, и начать так же в тупую выдирать геодату из текстур?

Это просто карта высот, ландшафт. А всё остальное - стены, мосты, камни, деревья, и т.п. на такой карте не представлены.

Murkt, мосты они дорисовывают сами по этим однослойкам, что мешает создать аналогичный редактор, который будет давать это в формате понятном яве, тем более на яве как я заметил, нет такой проблемы как провал игрока под текстуры, на проектах построенных на базе С1 оффа, это весьма часто встречающаяся проблема, то есть насколько я понял яве нужна геодата именно для мобов, т. е. что бы мобы "не выпрыгивали из 8 метровых оврагов" и не бегали сквозь стены" Причем, если я все правильно понимаю, то проблему "прыжков" можно решить именно "картой высот", если я не прав, то поправьте меня...

Прав, но не до конца. Стрелять сквозь стены всё равно можно будет. Мобы сквозь стены всё равно бегать будут. И что с башнями и катакомбами тогда делать?

Ну и проблема не в данных для движка - данные уже давным-давно вытянуты. Нужен движок, который будет коллизии просчитывать. А у Балансера времени мало )

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