Feature request: Autosplitter Settings per Split, access settings for Current Split

[AlexKnauth]

Allow ASR auto-splitters to set up settings widgets, that allow the user to choose different settings for each split they have.

While the user has the settings editor open, allow the auto-splitter both read and write access to the settings for all splits, or at least the split that the user is currently editing, if the interface restricts the user to only edit one at a time.

During a run, allow the auto-splitter read access to the settings that the user had set for the Current Split.

Various versions of this have been proposed on Discord by DarkRTA, Tedder, and probably others.

[AlexKnauth]

LiveSplit Windows-only auto-splitters for some metroidvania games, such as Hollow Knight and Ori, already do this through a combination of:

• a List Widget that the user sets up in the same order as their splits,
• and allowing the auto-splitter to know the split index during a run, to know which index to use from the List that the user chose.

A makeshift List Widget is already possible with the widgets that are included in ASR already, so the quickest way to get a minimum-viable-product working would be to just allow the auto-splitter access to the split index, so that it can know which index to use from the List that the user chose. https://github.com/LiveSplit/livesplit-core/pull/747

[sc2ad]

Hey, I was wondering what the status of this was. Does your PR require any plumbing from the "top", so to speak, to get the actual split index passed down? Or is there already an API function that this is going to bind against and thus no other changes need to be made (other than the asr change you mentioned in your PR to allow callers to actually use this change?)

Forgive my ignorance, looking for ways I can help move this forward, as I'd like to be able to do per-split settings and additionally know whether a split has occurred without my autosplitter's knowledge (i.e. user undid/performed a split manually). If you have a cleaner implementation (assuming I take your patch as-is) than:

async fn main() {
  // After process is attached
  let mut prev_split = timer::current_split_index();
  // In async update loop
  let current_split = timer::current_split_index();
  if current_split.map_or(prev_split.is_none(), |val| prev_split.map_or(false, |oldv| oldv == val)) {
    // Handle the case where the user split themselves or undid a split and track it accordingly
  }
}

I'm all ears! Thanks a ton for your work on ASR and for putting up this patch even if it's not yet ready to be merged!

[AlexKnauth]

It would require a change to both livesplit-core and asr, where the change to livesplit-core would need to come first. That's why #747 is there as a PR to livesplit-core but I'm waiting to submit a PR to asr only after some version of #747 makes it in.

Also, after some play-testing myself I changed my asr branch to just use an i32 rather than an Option<usize>, ~but I forgot to change the livesplit-core comments to reflect that, so thanks for the bump, I'll change that now.~

[sc2ad]

Gotcha. What's left on the core side? More play-testing or review from others who might have comments?

[AlexKnauth]

I do need to update it to fix a conflict with the Event System changes to livesplit-core.

Edit: now rebased and fixed Edit 2: still working on an issue with web_event_sink

[AlexKnauth]

While fixing that I also updated companion branches on both asr and LiveSplit.AutoSplittingRuntime to be compatible with #747.