Feature - Implemented improved how maximizerMRU works

Status
Not open for further replies.
I

IronTetsubo

Member
Attached patch improves (at least, from my perspective) how the maximizer pulldown works, and specifically the maximizer "most recently used" preferences. Before, if you had maximizerMRULength set to non-zero, you'd get X number of most recently used expressions in the list, but the defaults would drop off. The patch changes the behavior to always append " --- " (as a separator, if there are MRU items), and then the default list of expressions. I also changed the defaults to set maximizerMRULength to 5, and then clear the maximizerMRUList saved (since now it will show the default expression list if the list is unset). The point of all this being, this way you'll always have (up to) the 5 most recently used expressions in the pulldown, and also the full expression list to parse through if you aren't using one of those 5. Credit for the idea goes to a friend, SenorBiggles. Let me know what you think! Thanks...
 

Attachments

Without testing this, looks like you cleared out the default maximizerMRUList property. Fresh installations of mafia will have a blank maximizer dropdown, no?
 
I did clear out the maximizerMRUList - that was the intention. With an empty MRU list, it behaves as if you had maximizerMRULength set to zero - it just displays the default list of expressions. If the MRUList was (or is) left as it was before my patch, i.e., with the same list as the default list of expressions, then your first run would give you a pulldown of:

Maximizer: mainstat
mus
mys
mox
familiar weight
---
mainstat
mus
mys
mox
...

etc. - which isn't a great experience. Does that make more sense? My apologies if I'm explaining poorly.
 
I'm not a fan, yet ;-)

I don't really like the separator that just takes up space in the list as displayed. Part of the reason for me implementing mruLists was that on a small screen some constraints imposed by Java made it difficult to display lists that were too long. With my screen and resolution, any list with more that 25 or so entries is going to cause me problems accessing the bottom of the list. I also find some of the default or built in maximizer choices to be of little or no use and so liked the fact that the ones I did not use would drop off of the list.

I'm not sure what problem you are trying to solve, but a problem I left unsolved was that the default list sometimes was useful and served as a reminder for options that I used one or twice in a run. I stopped where I did because I was lazy, but some of the options I considered were:

changing the meaning of the mruList length so that it was the number of user defined expressions that were kept and always deleting a user expression (rather than a default) if there was a length issue.

providing a button that added the "defaults" one at a time to the list, thereby adding and possibly deleting items but making so that the defaults became available.

providing a Help button that listed all of the defaults for reference. Copy and paste would be your friend.
 
The intention is to solve for the causal user who isn't putting in their own expressions, they're just picking from the pulldown - to have the out of the box behavior "just work" for everyone. With the existing behavior, you either a. have the mrulist turned off, and then have to either scroll down a bunch/weed through the default options, or b. have your MRUs, but not have a reference for what other possible/typical expressions there are. For what I'm doing, there's a couple (hence the default of 5) of maximizers I use repeatedly, and having them appear at the top of the list makes that much more accessible for me (and hopefully everyone else) - but I still want to see all the other default options..

- the separator, shrug. easy enough to kill - I didn't like the way it looked without it, because the list "ran together" and it wasn't obvious when the mru choices ended and the default list stopped... but please, we can easily drop that from the patch, that's not core to the "point".

- the issues with bad default items, I agree with - but I don't think the fix is to not have them there, the fix is to get better defaults. :) If you've got a cutlist of ones you'd want me to improve, please share and I'll take a stab a it.

- For your additional solutions, I think the first solution is very similar to what I did? Is it because I also included the defaults that you don't feel it fits?

- for the second solution, I felt that adding add/remove/etc buttons to "manage" the list would get too messy, too quickly - which is part of why I suspect you didn't go that route... :) I dislike UI that forces users to micromanage the details, and would prefer to work towards a list of expressions that just works as much as possible.

- for the third, that seems like an additional patch that's in addition to this, to add a section to the "help" text that explains all the defaults and what they do. Sound good? If so, I'll whip up something.
 
Let's kill the separator.

For clarification, laziness is a virtue so my defaults button would just be one button that iterated through the defaults list and "added" each one to the MRU list as if the default had been selected. I threw away a version that did this because I had trouble adding a button to the layout (did I mention I don't like Swing?) and thought it got a bit kludgy walking through the list backwards so that the resulting MRU list had a similar order to the standard presentation.

I think the difference between your solution and my first option is that in mine the defaults and user entered values are intermixed and so the resulting list is truly a MRU regardless of whether the value was a default or user entered.

There are thirtyish options. I'm reluctant to pare the list down because Jason had his reasons and doing so would effect users who don't use this feature.

If i were going to make a change I would probably do the following: Let X be the number of existing defaults (because I am too lazy to count) and MRU be the user option. If MRU is 0 then the default list is static and always displayed. If MRU <= X then it works as it does now - expressions get added or moved to the top of the list as they are used and expressions at the bottom get deleted from the list in order to satisfy the length constraint. If MRU > X then expressions are always added or moved to the top but only non-default items get deleted in order to satisfy length constraints.

Are we converging towards agreement or am I still missing something?
 
Hey - senorbiggles here. I'm the end-user too lazy to hack kolmafia myself, but willing to suggest to irontetsubo something useful to me.

Yeah - I don't need the seperator either, it can go.

Just to clarify - I experiment with stuff. So - I've been playing with AoB runs with +moxie (I'm used to being a disco bandit and nigh-unhittable, so sue me). I'm also too lazy to pick and choose from hagnk's, so I let the kolmafia make suggestions (and w00t on that, let me tell you). So I use "adv" a lot. And I don't tend to use "mainstat", I choose a stat. And I have a multi, who is also in AoB (no, I don't mix - one is usually HC, one is SC), but he goes muscle, so I have to remember which is which. Plus, I didn't realize that you could just type "adv", and I wouldn't remember that max health is "HP not "health" or something else. I just pick from a list, and I was saying it'd be nice if once it saw me scroll down looking for "adv" 15 times, if it put that up top, and if I choose "muscle" on one toon and "moxie" on another it would remember. :-)

My original suggestion was simply to sort the list most recently used up top and be done with it. But - what he's done now works, and does save me 30ish seconds of vague annoyance a day. So - rock on with that - saving me vague annoyance having to figure things out on my own is kinda the point of KolMafia, I figure...
 
Welcome senorbiggles. I get two things from your post. First I think if we never deleted anything that was a default from the list and otherwise sorted on MRU you would be happier than you are now. I think #6 would work for both of us. Second, you would like to alias or rename the defaults because HP does not mean Health to you. I suspect that could be feasible but I do think it is a separate feature request from the MRU changes. And just to be clear, the MRU is per character so if you never type anything but always choose from what is already there, Moxie should migrate to the top for one character and Muscle for the other.
 
So to play it back to make sure I'm on the same page (and then I'll go whip up a patch)

- kill separator. check. :)
- if mrulength = 0, expression pulldown works as a static list (of 34 items, fwiw).
- if mrulength <= 34 (:) I counted), then the expression pulldown displays "mrulength" items and deletes the one at the bottom, be it from the defaults or user assigned.
- if mrulength > 34, then the expression pulldown displays "mrulength" items and deletes the one at the bottom, only deleting items that are user entered and not in the defaults.

given how large mrulength would have to be to have the 3rd condition kick in, at that point it seems like there's no reason to separate out the logic, and just do:

- if mrulength = 0, expression pulldown works as a static list (of 34 items, fwiw).
- if mrulength > 0, then the expression pulldown displays "mrulength" items and deletes the one at the bottom, be it from the defaults or user assigned.
(which is what the code currently does. My patch is complete!)

The key, I think, for a good result is what do we default mrulength to? If we've circled back to the existing code, then I'd recommend defaulting mrulength to 34, instead of 0. That means for the casual user who's not entering in their own expressions, the list effectively becomes static but sorted as most recently used, which is the whole point. So then I do have a "patch" to write, but it's a one-liner to change the default. Are we entirely converged?
 
It sounds like we have converged but I feel like we have done so by me standing at the same place.

The default was deliberately selected to be zero because of a design philosophy. The original tweak had to be opt in and change nothing for a user who elected not to use it. A default of 34 (thanks for counting, BTW) means all users will see the expressions reorder and, if by chance, they type an expression then one of the defaults would fall off. That is probably not a good idea.

So what happens if the default and the minimum are 34 and the only expressions we delete are user entered ones? All users would still see things reordered, which is acceptable to me so I will take the heat if anyone else on the dev team objects, but the official defaults would always be somewhere in the list for everyone.
 
I've never used modifier maximizer but ... couldn't this just be an issue with how maximizer is used?

If we let you create a way to let you create shelves for the orderings (similar to moods being a snapshot of buffs, this would be a snapshot of all the maximizer things you've typed in) and KoLmafia would add items to that list and/or reorder them within that shelf/list. If those were given a name, you could then swap them based on where you were in your run, which is probably the only reason it would grow to 34 in the first place.

The whole 'defaults' thing would be solved simply by having it be its own read-only shelf.
 
So far potential solutions have been constrained by my own unwillingness to suggest anything that might involve spending more time with Swing and the GUI than I am comfortable with. When Jason implemented the maximizer he populated it with a static dropdown that contained 34 items. Many people used that list as a reference since that was easier than memorizing the maximizer keywords or finding a separate display or help file.

To step back...

The user needs an easy way to refer to a list of existing maximizer commands and possibly executing commands from that list.

The user needs a way of accessing a previously used maximizer command and either submitting it or editing it and then submitting the edited command.

My own use suggests that I would not benefit from anything like moods or shelves since I tend to use the same commands over and over and from run to run.
 
Well, with the shelves, you'd be able to have a shelf of 10 MRU maximizer commands that you use over and over, and that shelf could be above or below the existing read only default shelf with its 34 items. If you wanted another shelf of aftercore maximizer commands, you could put that at the bottom during runs, and swap it with the ronin-maximizer shelf after you finish the run. If there are gCLI/ASH commands to move maximizer shelves, you could even have that automatically done as a part of your postPrism script...
 
I'm not familiar with moods/shelves, so I will go away and do more research before commenting. Is this the "Mood Setup" panel that you're referring to, or some other part of the UI I'm unfamiliar with?

dave
 
Yes, I was referring to the mood setup panel.

Right now in KoLmafia, there are three ways we show large amounts of data. The first way is in a CCS. Here, all the options are visible at once, and there's really no way to filter the information other than the collapsible sections. This works to a point, but probably wouldn't be all that useful for maximizer given that the options change on the fly alot, whereas with CCS the data is expected to be very static.

The second way is in moods. The idea in the mood setup panel is that moods are a snapshot of trigger conditions that a user might be interested in, and those change throughout a run. So you provide a "name" for all of the ones you're interested in, and KoLmafia only applies those. From a "what do I see" standpoint, only a subset of the available options are visible at any given time, and you select which ones are visible by selecting the "name" of the grouping/shelf.

The third way is the consumption panel, where the effect you want (15 adventures at the cost of 3 fullness, for example) is given a name (the name of the food). In this case, the lists grow arbitrarily large, and it's pretty much always sorted a certain way (subject to the checkboxes), but a fast filter field at the top trims it to just the most applicable ones.
 
A list simply sorted on MRU would be perfectly acceptable.

I frankly didn't know that it existed (MRU sorting), or I'd have just turned it on. Is it hidden somewhere in the preferences and I just missed it? If it's not - that's perhaps a key; a feature that's invisible to J Random User may as well not exist. And if it is there, my bad. :-)

As for "health" versus "HP" - no, have no desire to rename them. I was simply pointing out that had I realized you could simply type them in - I still wouldn't have known what to type. Is there a reference anywhere for what sort of entries you can put in here, or in the adventure goals dropdown? I was mentioning that for the Modifier Maximizer, it would be nice to be able to say something like "Maximize moxie, but I need to keep the swashbuckling outfit on". I am beginning to suspect that's not a new thought, that it's already possible some way, and I simply don't know how.
 
I'm beginning to think this is going to be a Rejected Feature request. The existence of a hidden preference combined with existing documentation on the Maximizer seems to address most of the concerns.

The preference was hidden because at the time of implementation No One (and by that I mean me, under the supervision of H or V) wanted to add a new preference to the preference GUI. Perhaps it is the time to add it?
 
As a player who uses the modifier maximizer tab a lot, I am completely confused here. After having read this whole thread and popup help from the button I have no idea what all this means to me. You guys are talking about hidden preferences (which btw piss me off, if it's there fucking document it and put it in the preferences box, otherwise what's the point) and modifying the maximize list which I've always been told was not possible without editing the source code and compiling my own mafia.

Can someone please explain to me if I can edit that list without compiling my own version? Probably coming off as an ass here, which I don't intend, I'm just confused and trying to figure out how to edit that list, which is something I very much want the ability to do.
 
fianor said:
hidden preferences (which btw piss me off, if it's there fucking document it and put it in the preferences box, otherwise what's the point)
Click to expand...
Probably coming off as an ass here, which I don't intend
Click to expand...
If you don't intend to come off as an ass, don't tell us how pissed off you are and spew obscenities. I know that _I_ stopped paying attention as soon as I got to them.

I'm sure somebody else will answer your questions.
 
Status
Not open for further replies.
Back
Top