Всем привет.
Хочу поделится информацией базовых принципах хранения и загрузки путей в официальном сервере.
После окончания работы PathMaker.exe или PathMaker64.exe из утекших файлов ретейла, он создает три файла:
1) pathnode.idx
2) pathnode.bin
3) pathnode.txt
Сначала кратко про каждый тип файла:
1) pathnode.idx - это файл, который содержит в себе информацию об
Одна запись
2) pathnode.bin - это бинарный файл, каждые 44 байта которого содержат информацию об одной CPathFindingNode(здесь и далее я буду использовать названия файлов из кода server.exe). Формат хранения - 11 целочисленных значений в порядке LITTLE_ENDIAN.
Значения: x, y, z, n1, n2, n3, n4, n5, n6, n7, n8, где xyz координаты узла, а n1-n8 индексы соседних узлов, в которые возможен переход. Количество узлов соседей может быть и меньше 8, в этом случае недостающие значения заполняются нулями. Порядковый номер
3) pathnode.txt - это отладочный файл, который содержит фактически такую же, но более полную информацию как и pathnode.bin, но в текстовом виде.
Для работы сервера этот файл не нужен и носит только отладочный характер.
Как происходит загрузка:
Первым загружается
В дальнейшем, эти данные используются для поиска пути по алгоритму A*.
Алгоритм поиска пути находится в методе
В принципе, эти данные легко парсятся и подгружаются для использования и в обычную сборку. Путь между узлами
Т.е фактически, запитав поиск пути от этих файлов, вы получите практически полностью идентичную оригинальному серверу модель поиска пути.
Спасибо MasterToma за некоторую инфу в этой теме: PathMaker
При подготовке материала бралась за основу информация из HF, но учитывая идентичность PathMaker, скорее всего актуально вплоть до слитого 287.
Я не педагог и не писатель. Заранее прошу прощения за сумбур в изложении. Любые вопросы можно задать в обсуждении.
Хочу поделится информацией базовых принципах хранения и загрузки путей в официальном сервере.
После окончания работы PathMaker.exe или PathMaker64.exe из утекших файлов ретейла, он создает три файла:
1) pathnode.idx
2) pathnode.bin
3) pathnode.txt
Сначала кратко про каждый тип файла:
1) pathnode.idx - это файл, который содержит в себе информацию об
CPathNodeОдна запись
CPathNode содержит в себе координаты XY узла и информацию об количестве связанных CPathFindingNode. Объекты CPathNodeравномерно покрывают всю площадь мира, в виде сетки из квадратов 256x256 точек.2) pathnode.bin - это бинарный файл, каждые 44 байта которого содержат информацию об одной CPathFindingNode(здесь и далее я буду использовать названия файлов из кода server.exe). Формат хранения - 11 целочисленных значений в порядке LITTLE_ENDIAN.
Значения: x, y, z, n1, n2, n3, n4, n5, n6, n7, n8, где xyz координаты узла, а n1-n8 индексы соседних узлов, в которые возможен переход. Количество узлов соседей может быть и меньше 8, в этом случае недостающие значения заполняются нулями. Порядковый номер
CPathFindingNode является ее индексом. Под 0 индексом в бинарнике хранится пустая нода, содержащая 11 нулей.)3) pathnode.txt - это отладочный файл, который содержит фактически такую же, но более полную информацию как и pathnode.bin, но в текстовом виде.
Для работы сервера этот файл не нужен и носит только отладочный характер.
Как происходит загрузка:
Первым загружается
pathnode.idx, из которого создается массив объектов CPathNode. После этого, каждая из CPathNode загружает из файла pathnode.bin нужное количество CPathFindingNode.В дальнейшем, эти данные используются для поиска пути по алгоритму A*.
Алгоритм поиска пути находится в методе
CPathNodeWorld::PathFindВ принципе, эти данные легко парсятся и подгружаются для использования и в обычную сборку. Путь между узлами
CPathFindingNode в принципе вообще не нуждается в геодате(я для теста выводил расчеты отдельной визуализацией и путь практически идентичен тому, что считает мой движок в реалтайм, но значительно лучше отрабатывает переходы между слоями, где в моем движке иногда проскакивают ошибки), но лучше конечно как минимум корректировать высоту стартовых точек. В целом, это довольно неплохо снимает нагрузку с CPU и количество IO, если геодата находится не в памяти, а мапится с винта.Т.е фактически, запитав поиск пути от этих файлов, вы получите практически полностью идентичную оригинальному серверу модель поиска пути.
Спасибо MasterToma за некоторую инфу в этой теме: PathMaker
При подготовке материала бралась за основу информация из HF, но учитывая идентичность PathMaker, скорее всего актуально вплоть до слитого 287.
Я не педагог и не писатель. Заранее прошу прощения за сумбур в изложении. Любые вопросы можно задать в обсуждении.
Последнее редактирование:
athFind
WindOfChange
