Encountered when trying to extract every file in the game (lmao).

use ironworks::{ffxiv, sqpack::SqPack, Ironworks};
use std::path::Path;

fn main() {
    let game_path = Path::new("G:/Steam/steamapps/common/FINAL FANTASY XIV Online");
    let ironworks = Ironworks::new().resource(SqPack::new(ffxiv::FsResource::at(game_path)));
    let file = ironworks
        .file::<Vec<u8>>("chara/monster/m0023/obj/body/b0003/texture/v01_m0023b0003_s.tex");

    println!("{:#?}", file);
}

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `16000`,
 right: `6`: Block info and header decompressed size differs.', C:\Users\Julian\.cargo\registry\src\github.com-1ecc6299db9ec823\ironworks-0.3.1\src\sqpack\file.rs:55:5

Sheet endpoints would benefit from a query argument(s) to control the columns that will be returned in the response. While the query arguments are necessarily strings, they should be parsed into some form of structured representation that can be "walked" alongside the schema.

Open questions:

• [ ] Schema package has some need for column specifiers on references, is this something relevant to that? It likely isn't relevant - reference specifiers are naturally single-column targets, while column filtering must target 0-to-many. Search filter specifiers will probably be more appropriate for this.

use std::path::Path;

use ironworks::{ffxiv, sqpack::SqPack, Ironworks};

fn main() {
    let game_path = Path::new("G:/Steam/steamapps/common/FINAL FANTASY XIV Online");
    let mut ironworks = Ironworks::new();
    ironworks.add_resource(SqPack::new(ffxiv::FsResource::at(game_path)));

    ironworks.file::<Vec<u8>>("chara/monster/m0678/obj/body/b0001/texture/v01_m0678b0001_b_d.tex");
}

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', C:\Users\Julian\.cargo\git\checkouts\ironworks-836e4c5d0f0f4516\ed0af56\ironworks\src\sqpack\block\stream.rs:62:25

Currently, most configuration is hardcoded in inappropriate locations. Look into building config file(s) for storing and allowing user configuration. Ideally, environment variables would also be read.

As of last look, the crates config and figment look like close contenders for this functionality.

SeString payloads hold a lot of metadata around character levels and suchforth, especially in tooltips.

With some additional payload handling in ironworks (TODO: make an issue over there), ref. sestring, it should be possible to expose a structured response schema for the payloads.

Current sheet handling only fetches direct data and references. There's quite a lot of value in being able to backtrack up a reference, however there's no target->source information in the data itself.

For a given schema version, it should be viable to walk the schema looking for references, and proactively build a list of references in an external store for each relevant game version, that can be used to resolve backreferences.

GQL is a very strong contender for a non-REST API surface, at least for sheets. There's a few stumbling blocks to implementing it, primarily centered around the effectively dynamic nature of the sheet schema at runtime - many (rust) GQL libraries expect a singular static schema.

One of the best bets as of last look into this was juniper, which a community member built an example dynamic schema builder for here.

Further research is required.

async-graphql has very recently landed dynamic schema generation, and looks like it'll be included in an upcoming v5 of the library.

Search will need per-column explicit value filtering, i.e. numeric range checks and so on. Given search indices are decoupled from sheet schemas, and hence do not resolve any references, this will be a bit fiddly.

If the column filters are built to be sufficiently structured, it will likely be possible to trace a set of filters to the leaf fields, and then walk back up with a search at each reference to find matches.

Likely lots of optimisation opportunities on that.

Search field specifier can probably share some concept or implementation with reference targeting in schemas.