Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ASR] Prevent certain types of split from ending the run #699

Open
apple1417 opened this issue Jun 25, 2023 · 1 comment
Open

[ASR] Prevent certain types of split from ending the run #699

apple1417 opened this issue Jun 25, 2023 · 1 comment
Labels
auto splitting This is about the auto splitting implementation. enhancement An improvement for livesplit-core. feature A new user visible feature for livesplit-core. needs further discussion It is unclear how to progress without making further decisions.

Comments

@apple1417
Copy link

There are some types of split triggers which happen very frequently and can easily mistakenly end a run - e.g. "split on collectable" or "split on level transition" during a 100% cleanup split. While the user can just undo split manually, it's not ideal - especially since undoing the last split adds all elapsed real time, when there might've been load screens in between which should be removed. For this reason, there are a few ASLs which disable certain split conditions on the last split. There isn't a way to replicate this in an ASR script yet.

While simply exposing a timer_is_last_split would work, it's a bit messy, and we want to move away from autosplitters knowing about the splits (so that people stop hardcoding routes). The more comprehensive solution we've discussed previously is to add per-split settings. Users could then simply disable the relevant setting when on the last split.

@CryZe CryZe added enhancement An improvement for livesplit-core. needs further discussion It is unclear how to progress without making further decisions. feature A new user visible feature for livesplit-core. auto splitting This is about the auto splitting implementation. labels Jul 11, 2023
@CryZe
Copy link
Collaborator

CryZe commented Jul 11, 2023

I've been thinking that maybe we want to have the following two functions:

fn split_intermediate(name: Option<&str>, create: bool);
fn finish();

This handles some additional scenarios:

  1. Timers that don't even have a (fixed) list of splits.
  2. Automatically creating a list of splits during your first run.
  3. If the runner has too many splits, but the run is finished, it can automatically skip them all and split the last split instead.

The create would be specifically to indicate if the split is worth creating if it doesn't exist yet, which in your case it sounds like there seem to be splits that shouldn't even exist, so it would just ignore them entirely if create is false. A timer not capable of creating new splits would of course just ignore this flag entirely and only split if it's not the last split.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto splitting This is about the auto splitting implementation. enhancement An improvement for livesplit-core. feature A new user visible feature for livesplit-core. needs further discussion It is unclear how to progress without making further decisions.
Projects
None yet
Development

No branches or pull requests

2 participants