LiveSplit / LiveSplitOne

A version of LiveSplit that works on a lot of platforms.
https://one.livesplit.org/
MIT License
246 stars 29 forks source link

Column to compare against gold segment times #140

Closed appletalk closed 5 years ago

appletalk commented 5 years ago

Column support has been an excellent addition. As a small improvement, it would be nice to have a column to compare against gold (best all time) splits.
Having a column listing each gold segment times along side the column for current PB segments exists in LiveSplit, replicating this functionality in LiveSplitOne would be great.

CryZe commented 5 years ago

It is already possible, but it seems like the current approach doesn't seem to properly convey how you can do this. You can set Best Segments as the comparison for the column and then Start With of Comparison Segment Time and Update With of Segment Time. Do you think a combo box for the column's comparison would've helped or was there something else confusing? I'll probably start prioritizing implementing the combo box for the comparisons though.

appletalk commented 5 years ago

Oh, yes that is exactly the functionality I was looking for. I saw the option there, but didn't understand what the comparison text box was for.

Now that you've explained it, it makes sense. It's comparing against a column name. I think a combo box with the columns available for comparison prepopulated would make it much more self explanatory.

appletalk commented 5 years ago

I encountered what I believe to be a bug using the column compare against Best Segments. I hope I can explain the steps to reproduce it clearly. Please let me know if a splits export, or additional information would be more helpful.

Setup some splits, and store some best segment times in them. Aka complete a run. Then take one of the splits, and add another split below it and complete another run with the new additional split.

In my examples in my screenshots I took the Aga tower split, and added a Blue balls split in addition to it. This has caused the Darkness split to be incorrect in the Gold column. The column displaying 4:59 for the Darkness split, but my Best Segment is listed as 6:34

The time displayed under edit splits -> Best Segment does not match the column I've setup to compare against "Best Segments". It appears to be related to adding a new split into the existing list of splits and the compare column not recalculating the times?

The detailed timer displays the correct "Best" for the Darkness split, and Sum of bests is also correct. So it seems to only be an issue with the compare column.

Additionally in my screenshots, you can see I had a gold split in Darkness, with a positive time vs my current gold time. Which shouldn't be possible unless i'm misunderstanding what the compare is doing.

I hope I explained well enough to follow, Thanks!

screenshot from 2019-01-31 13-29-27 screenshot from 2019-01-31 13-29-51 screenshot from 2019-01-31 05-49-14

CryZe commented 5 years ago

Can you send me the splits? I kind of know what the problem is, but I'd like to see what is actually going on in the splits, as this seems like there's possibly an additional bug happening.

appletalk commented 5 years ago

The splits and layout are attached here.

The Legend of Zelda A Link to the Past - Any% No Major Glitches.zip

CryZe commented 5 years ago

Okay, so from what it seems like, this is indeed "somewhat correct". Essentially your new best segments with the Blue Balls split are much slower than the runs you did before you had that split. If you run the Sum of Best Cleaner (you can find that if you click the "Other..." button in the Run Editor), you can see this run for example:

https://i.imgur.com/J3xcrOd.png

LiveSplit has two different notions of Sum of Best. One is the straight up addition of the best segment value of each individual segment. But what LiveSplit is doing everywhere else other than the Run Editor is actually the shortest path to each individual segment. So what LiveSplit realized here is that some of your old runs were able to do the segment between Aga Tower and Darkness much faster than since you added that segment in between. So instead of simply adding up the best segments for those two, it uses the best segment time you had before, as that is the shorter path in terms of time. However if you compare against the best segments comparison, then the shortest path to the Blue Balls split can only be through the runs you did since you added that split. So the time for Darkness is calculated through your old runs and the time for Blue Balls is calculated through the new runs. So if you subtract both of these times, you essentially get garbage that doesn't mean anything, as they are derived from different sources. Let me simplify this maybe:

Let's say we have splits A, B and C. If you do one run where you split A at 5 minutes, skip over B and then split C at 20 minutes, then there is a 15 minute time difference between C and A. If you do another run where you yet again split A at 5 minutes, then split B at 30 minutes and then split C at 40 minutes, then the fastest path to B is via the second attempt and is at 30 minutes, while the fastest path to C is via the first attempt and is at 20 minutes. So the best segments comparison will show:

So if you calculate the time from B to C here, it is -10 minutes, which doesn't make any sense. The comparison column you set up essentially does exactly that, so you get some meaningless value. Maybe in situations like this we should just use an empty value instead of showing something meaningless.

appletalk commented 5 years ago

That explains it perfectly. I understand what's happened now. The Sum of bests cleaner did the trick

It was a little confusing, as there was nothing displayed visually indicating the confused split time. Thank you very much for your time and assistance. Keep up the great work!

CryZe commented 5 years ago

Well I don't think you should've been using the Sum of Best Cleaner here as these old times are entirely valid (the cleaner is mostly for mistakes that happened through incorrect skipping). But this is definitely bad for the User Experience as it's very confusing, so I'll probably open up an issue discussing on how we can improve this situation.

appletalk commented 5 years ago

Oh, I misunderstood the purpose of the cleaner then. At least for my case, removing the old split(s) was an acceptable work around for the time being :) I'd be happy to help in any further way I can,