Всем привет.
Хочу поделится информацией базовых принципах хранения и загрузки путей в официальном сервере.
После окончания работы 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, но в текстовом виде.
Для работы сервера этот файл не нужен и носит только отладочный характер.
Как происходит загрузка:
Первым загружается
В дальнейшем, эти данные используются для поиска пути по алгоритму Theta*.
Алгоритм поиска пути находится в методе
В принципе, эти данные легко парсятся и подгружаются для использования и в обычную сборку. Путь между узлами
Т.е фактически, запитав поиск пути от этих файлов, вы получите практически полностью идентичную оригинальному серверу модель поиска пути.
Спасибо @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.В дальнейшем, эти данные используются для поиска пути по алгоритму Theta*.
Алгоритм поиска пути находится в методе
CPathNodeWorld::PathFindВ принципе, эти данные легко парсятся и подгружаются для использования и в обычную сборку. Путь между узлами
CPathFindingNode в принципе вообще не нуждается в геодате(я для теста выводил расчеты отдельной визуализацией и путь практически идентичен тому, что считает мой движок в реалтайм, но значительно лучше отрабатывает переходы между слоями, где в моем движке иногда проскакивают ошибки), но лучше конечно как минимум корректировать высоту стартовых точек. В целом, это довольно неплохо снимает нагрузку с CPU и количество IO, если геодата находится не в памяти, а мапится с винта.Т.е фактически, запитав поиск пути от этих файлов, вы получите практически полностью идентичную оригинальному серверу модель поиска пути.
Спасибо @MasterToma за некоторую инфу в этой теме: PathMaker
При подготовке материала бралась за основу информация из HF, но учитывая идентичность PathMaker, скорее всего актуально вплоть до слитого 287.
Я не педагог и не писатель. Заранее прошу прощения за сумбур в изложении. Любые вопросы можно задать в обсуждении.
Последнее редактирование:
athFind
