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

[Suggestion] Associate variables with attempt id instead of entire splits file #759

Open
TheTaraStark opened this issue Jan 18, 2024 · 1 comment

Comments

@TheTaraStark
Copy link

TheTaraStark commented Jan 18, 2024

Currently, most runners have separate splits files for different variables in the same category. I'd like to suggest associating variables to the <Attempt id> tag so runs with different variables can all coexist on the same file.

This would simplify splits file management for runners, and enable easier variable switching for folks who play multiple variables in a same category.

In the future, this could also allow for new comparison opportunities - runners could choose to compare against runs with some of the same variables as the current run, all of the same variables, all runs regardless of variables, etc. Total playtime in a certain set of variables could easily be compared to play time across all variables.

Associating variables with <attempt id> seems (on the surface) like a simple solution that could also easily retain backwards compatibility, and allow for the creation of a tool to combine splits files with different variables into the new format (though the latter would probably be a separate project).

Would love to hear thoughts on feasibility, other possible implementations with similar outcomes, etc.

@TheTaraStark TheTaraStark changed the title [Suggestion] Associate variables with <attempt id> instead of entire splits file [Suggestion] Associate variables with attempt id instead of entire splits file Jan 18, 2024
@GalaxianSR
Copy link

This is actually an incredibly good idea! I would love the ability to be able to combine and easily switch between unique comparisons far more easily. I second this possible implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants