Reduced Flashing Option

[ardnaxelarak]

Adds a setting post-generation for reduced flashing.

Patch itself is still a work-in-progress, but the rest should be relatively stable, so creating a draft PR awhile in case there's any feedback on my Rust implementation and/or UI changes.

Not sure whether it's worth caching the parsed patch; there is a slightly noticeable increase in the time it takes to download the rom with the patch vs without, but not sure how much of that is due to the parsing of the patch vs the application of the patch.

Remaining TODOs in patch:

• [x] Power Bomb flash (done but not yet included)
• [ ] Boss flashing
  • [x] Kraid (need to make sure KQK is not affected)
  • [x] Phantoon
  • [x] Draygon
  • [ ] Ridley (might be fine without adjustment)
  • [x] Crocomire
• [ ] Baby Metroid (may not need any adjustment, but I think I remember there being some flashing involving it somewhere)
• [x] Landing Lightning
• [ ] Escape
  • [x] Sky
  • [ ] Surface
  • [x] Old Tourian Background

[blkerby]

UI changes look good. For the implementation, I think there could be a simpler approach that avoids introducing a custom file format for describing the patch. I'd suggest using serde_json, the benefits being that the JSON will be easier to interpret and edit, and the parsing can be automated. So you could define your structures something like this (enum will be simpler/cleaner than defining a trait):

#[derive(Deserialize)]
struct GlowPatch {
  sections: Vec<GlowPatchSection>
}

#[derive(Deserialize)]
enum GlowPatchSection {
  Direct {
    offset: usize,
    data: Vec<u8>
  },
  Indirect {
    offset: usize,
    read_length: u8,
    sections: Vec<Box<GlowPatchSection>>
  }
}

Then a JSON file can be parsed automatically with serde_json::from_str. It could look something like this:

[
  {"direct": {"offset": 12345, "data": [34, 56, 78, 90]}},
  {"indirect": {
    "offset": 23456,
    "read_length": 2,
    "sections": [
      {"direct": {"offset": 23456, "data": [67, 89]}}
    ]
  }}
]

If you want to read the fields from hexadecimal strings, that could be done with serde_hex or something like it. The JSON file could go here with other data that gets loaded on randomizer start-up.

[ardnaxelarak]

Great suggestions, thanks!

And I see I needed to run cargo fmt, will do that as well. :)

[ardnaxelarak]

Thanks for the tip on using an enum--that's exactly what the situation called for, but I didn't know how rust enums worked. Learning, yay :)

And using json seems a lot nicer, for sure, I just wish it natively supported hex values for integers. :(

Rust code should be ready for another round of review, no new updates on the patch itself yet.

[ardnaxelarak]

there's a built-in function u64::from_le_bytesthat would be equivalent to your from_bytes_le

looking at the documentation (without having played around with it yet), it looks like that function wants exactly 8 bytes whereas I'll have a variable number of bytes. I do agree using the built-in would be preferable, so is there an easy way to wrangle my slice of variable size into length 8 by adding zeroes at the end (or trimming the end off if it's too long)?

[blkerby]

Oh, right, I overlooked that. There would be a way to do it by converting the bytes to a Vec, then doing resize on it to pad it out to 8 bytes, but what you did is probably better, so it's fine.