Reversion Request: Check Group Order Before Model Priority #12

New Issue

deadreg · 2025-04-27T02:09:35-07:00

deadreg commented

2025-04-27 02:09:35 -07:00

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Since switching the order the program checks its priority to Model Priority before Group Order, it's been impossible to fine-tune a combination of the two in order to, say, prioritize primary feeds from a given group under another model, and secondary feeds over the same model. I posted a (more) long-winded explanation in the Discord's Feature Requests channel (I'll attach it here in case you'd like to read it) and a pretty comprehensive conversation ensued. The main argument against me in particular - that group order is still used if all priorities in a group are equal - seems to ignore that 1) this forces the user to prioritize every feed in a group as a block rather than independently of one another, and 2) group order was functional in every situation under the old system, and model priority was no less functional than it is now. Another that I've seen - that group before model priority requires those with limited slots to remain cognizant of how model priorities compare to between models - doesn't really make sense to me, because that's what they were always for (and why model priority is a 100-option setting); the new ordering has simply added a second responsibility to a single number, making it harder to control both.

At the most basic level, prioritizing the rules of a larger set over rules for the same things within its subset renders the subset rules meaningless - again, they can be forced into play if the broader rules are intentionally prevented from selecting for a single item, but this cripples functionality.

I think part of the problem here is that, as it applies in this specific instance, this is a nonissue when the number of simultaneous recordings is unbounded: it doesn't matter whether model priority or group order is the deciding factor within a group when every model online will be recorded regardless. For those of us with limited recording slots to work with, however, the ability to manipulate a model's interactions with each specific feed within another's group, rather than the highest-model-priority member of each group acting as its de facto representative, can be a big deal.

Describe the solution you'd like
If possible, I'd like to revert the program's feed selection to check the order of the feeds within a given group, and then use the top-ordered feed available to check against other models via model priority. This would increase functionality for those with a simultaneous recording limit, and offer no drawbacks to those without as best as I can tell. Failing that, at least the option to revert would be nice. I'll openly admit I couldn't tell you the first thing about whether this poses a larger problem from a coding standpoint, but it's sound from a logical one.

Describe alternatives you've considered
I could revert to using an older version or a Wink version, but at this point that would cause significant recording issues across multiple sites, offering zero functionality rather than just less. I could try another program, but that would be a pain for obvious reasons, and I don't think the change I'm advocating is selfish or unreasonable enough that I should just look elsewhere. If all else fails, I could also try to figure out how to manipulate the code to revert the change myself, but that's a daunting prospect to say the least for a noncoder. As I said, I'm here because of a logical issue that I perceive as creating a functional one. As far as I know, the code is working as intended.

Additional context
Only the attached explanation and the Discord conversation I mentioned. I know I've already probably written more than I should.

**Is your feature request related to a problem? Please describe.** A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Since switching the order the program checks its priority to Model Priority before Group Order, it's been impossible to fine-tune a combination of the two in order to, say, prioritize primary feeds from a given group under another model, and secondary feeds over the same model. I posted a (more) long-winded explanation in the Discord's Feature Requests channel (I'll attach it here in case you'd like to read it) and a pretty comprehensive conversation ensued. The main argument against me in particular - that group order is still used if all priorities in a group are equal - seems to ignore that 1) this forces the user to prioritize every feed in a group as a block rather than independently of one another, and 2) group order was functional in *every* situation under the old system, and model priority was no less functional than it is now. Another that I've seen - that group before model priority requires those with limited slots to remain cognizant of how model priorities compare to between models - doesn't really make sense to me, because that's what they were always for (and why model priority is a 100-option setting); the new ordering has simply added a second responsibility to a single number, making it harder to control both. At the most basic level, prioritizing the rules of a larger set over rules for the same things within its subset renders the subset rules meaningless - again, they can be forced into play if the broader rules are intentionally prevented from selecting for a single item, but this cripples functionality. I think part of the problem here is that, as it applies in this specific instance, this is a nonissue when the number of simultaneous recordings is unbounded: it doesn't matter whether model priority or group order is the deciding factor within a group when every model online will be recorded regardless. For those of us with limited recording slots to work with, however, the ability to manipulate a model's interactions with each specific feed within another's group, rather than the highest-model-priority member of each group acting as its de facto representative, can be a big deal. **Describe the solution you'd like** If possible, I'd like to revert the program's feed selection to check the order of the feeds within a given group, and then use the top-ordered feed available to check against other models via model priority. This would increase functionality for those with a simultaneous recording limit, and offer no drawbacks to those without as best as I can tell. Failing that, at least the option to revert would be nice. I'll openly admit I couldn't tell you the first thing about whether this poses a larger problem from a coding standpoint, but it's sound from a logical one. **Describe alternatives you've considered** I could revert to using an older version or a Wink version, but at this point that would cause significant recording issues across multiple sites, offering zero functionality rather than just less. I could try another program, but that would be a pain for obvious reasons, and I don't think the change I'm advocating is selfish or unreasonable enough that I should just look elsewhere. If all else fails, I could also try to figure out how to manipulate the code to revert the change myself, but that's a daunting prospect to say the least for a noncoder. As I said, I'm here because of a logical issue that I perceive as creating a functional one. As far as I know, the code is working as intended. **Additional context** Only the attached explanation and the Discord conversation I mentioned. I know I've already probably written more than I should.

ctb precedence.txt

2.9 KiB

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: j62/ctbrec#12