jahed.dev

FrontierNav Weekly: 1st June 2020

Progress Report

Changes

Xenoblade Chronicles: Future Connected

Support the project

Thank you to this month's patrons!

Michael Rademakers, Sebastian Tasto, Chuang Sing Kee, Aidan Zamboni, Chad Bishop, Aloftheabove, Roadrunnerto, Nightshade, Mario Carmona, Hex, Pussel, yeili, and 1 anonymous patron.

If you would like to support FrontierNav, please consider donating on Patreon. Doing so helps fund development and keeps the project going. Thank you.

CSV Imports

Implementing CSV imports was a lot more tedious than than I expected. The goal was to take a process that I usually do through scripting and make it "no code". That is, anyone can organise data in a spreadsheet or whereever and create mapping rules that import it into FrontierNav.

I've been using the CSV import to process Xenoblade Chronicles: Future Connected data. This way I can find obvious deficiencies and edge cases. The last thing I want to do is provide an interface that doesn't work.

Once I'm happy with it, I'll polish it up and release it for everyone else to use.

CSV Import preview
It's not pretty but that's not the focus right now.

As a side note, since the CSV import parses CSV into objects, adding JSON imports was a no-brainer. It just skips the CSV step.

Why not make a library?

The thing is, these mapping rules that are generated can be so abritrary that it's pretty much code; the user interface is a query language and the output is an abstract syntax tree.

So why even bother making this "language" when I could make a library (which already exists) and let people write their mappings in JavaScript or whatever language they want?

Well, for users unfamiliar with code or don't want to get familiar with FrontierNav's APIs, it provides a friendlier interface with auto completion and limited choice to prevent errors. For me, I can gradually figure out what features this "language" needs, and maybe at some point I can migrate it to can existing language once all the dots line up. Not to mention, I also benefit from not having to open a terminal up and have a programming environment set up.

Hasn't this been done already?

Sometimes I do wonder if I'm missing something. I've essentially written an in-memory graph database. Users take a copy of the database, query it, make local changes to it, then send merge requests. Doesn't something like that already exist? There are tons of browser-side graph databases but they don't provide that sort of workflow -- and a lot of them come and go so they're not reliable in the long term, but that's a different issue.

Currently, I'm assuming FrontierNav is one-of-a-kind. It probably isn't and I'll gladly switch over to an existing solution to save time. But if there isn't, maybe there's room here to tidy up what I have and publish it for others to use. As a consequence I'll have a more rigorous implementation that isn't plastered with "good enough" features. But that takes time, which I don't have... Maybe that's why there isn't an existing reliable solution.

Advanced Search

Universal search currently only supports looking up names. Now that there's a generic interface to import data, technically, the same interface can be used to query data. Like in SQL, I've implemented the UPDATE/INSERT command, now I need to implement the SELECT command; which is already implemented underneath, I just need to give access to it.

This advanced search will be able to look up any property. Levels, types, locations, etc. Not only can this be used in universal search, eventually it could be used to create dynamic guides which lists items without needing to hard-code them into the guide. For example, a walkthrough where it lists enemies in a specific area. So when data gets updated, there's no need to update the guides, provided there are no conflicting schema changes.

Next Up

I'll be focusing on getting CSV imports released and importing more Xenoblade data.

Thanks for reading.