Allow using navigation files from locations other than file system

[gtker]

As part of working on the Rust library I would like to be able to have it be possible to use extracted map data from sources other than the filesystem.
Specifically I would like to put the data in an SQLite DB, potentially for speed but also for a cleaner user experience.

I would also like for there to be some way of avoiding the intermediate file system step when creating the map data, but that's easier to work around.

I'm not very well versed in the usage patterns of the navigational data, so I'm not sure what the best way of structuring things would be.

[namreeb]

Probably a good first step for this would be to create an abstract interface "provider", and then instantiate that template with the existing code. This would give a good blueprint for instantiating it again with another data provider.

Edit: Ultimately, you'll have to be careful how you do it. I don't want to introduce any new external dependencies without careful consideration.

[gtker]

Edit: Ultimately, you'll have to be careful how you do it. I don't want to introduce any new external dependencies without careful consideration.

I wasn't thinking of introducing any additional dependencies, I was more thinking of allowing namigator to read directly from a char*. So basically just having a way to pass bytes directly to the BinaryStream.

[gtker]

I'm probably going to take a stab at this. Do I understand it correctly that:

• A map consists of ADTs (whatever they are).
• The ADTs are stored in Nav and are named after their x/y offsets.
• A map knows which ADTs it has because it's in the .map file.
• After loading all ADTs it is not necessary for namigator to read any other files.

Why is the chosen format multiple different files with a "header" file that describes the others? Couldn't everything just be in a single file?

[namreeb]

Edit: Ultimately, you'll have to be careful how you do it. I don't want to introduce any new external dependencies without careful consideration.

I wasn't thinking of introducing any additional dependencies, I was more thinking of allowing namigator to read directly from a char*. So basically just having a way to pass bytes directly to the BinaryStream.

There's already this:

BinaryStream(std::vector<std::uint8_t>& buffer);

Which could be used to initialize a std::vector<>. Are you wanting something more than that? I'm a bit confused by this.

I'm probably going to take a stab at this. Do I understand it correctly that:

• A map consists of ADTs (whatever they are).
• The ADTs are stored in Nav and are named after their x/y offsets.
• A map knows which ADTs it has because it's in the .map file.
• After loading all ADTs it is not necessary for namigator to read any other files.

This is close to correct. There are also object files in the BVH directory. Those represent buildings, trees, fences, etc. that are layered into the underlying terrain (ADTs).

Why is the chosen format multiple different files with a "header" file that describes the others? Couldn't everything just be in a single file?

No particular reason, except I suppose that it would complicate things a bit. Individual tiles can be regenerated, not loaded, etc..