Closed SpaD-Overolls closed 1 week ago
Can you describe what your algorithm is doing? I was thinking, you make a descending pass through all stakes, keeping track of a set S (stakes that should be in the applied section). Whenever you encounter a stake in S, union its list of applied stakes into S.
I'll also say we should probably disallow defining a stake that applies a stake higher in the list.
To be honest Stakes are not really fully-featured yet
Can you describe what your algorithm is doing? I was thinking, you make a descending pass through all stakes, keeping track of a set S (stakes that should be in the applied section). Whenever you encounter a stake in S, union its list of applied stakes into S.
I'll also say we should probably disallow defining a stake that applies a stake higher in the list.
the algorithm starts at the current stake's .applied_stakes
and checks:
If it hasn't been searched, it's added to the searched table and has it's applied stakes go through the algorithm.
If it has a modifier, the found
counter ticks up by 1.
the goal of these changes is to have these two ui elements define themselves based on the current stake's data instead of the current stake's number.
first patch changes a
stake > 1
into#.applied_stakes ~= 0
to determine whether the run info screen should have a stakes button second patch (admittedly too complex?) changes astake > 2
check into a search that looks for the first stake with modifiers to determine whether the stake screen should have "also applies" boxes