Feature - Implemented Make fixed list of modifier maximizer strings configurable

P

PeKaJe

Member
Per my comments in this thread: http://kolmafia.us/showthread.php?18754-Elemental-Dmg-in-Modifier-Maximizer it would be nice if the maximizer strings that show up beneath the (by default) 5 most recently used were configurable. I have attached a patch with a preliminary implementation of this. Most of the changes are in swingui/menu/PartialMRUList.java, which at the moment appears only to be used for the modifier maximizer list. The formerly constant list is moved into the global parameter "maximizerList", and configuration is done in the preferences panel (the code for which is basically hijacked from ScriptButtonPanel).
 

Attachments

How do you expect the user who has just created a carefully crafted maximizer string to store it as a preference? The CLI set command will eventually screw someone who thinks it will append when it actually replaces. I'm not real comfortable with using an external editor on the file when KoLmafia is running and even if that were addressed I'm not sure anything currently present will detect the change and reload. I've got some ideas but because I am lazy I will defer to you if you have some. Thanks.
 
They would copy it and use the "add" button in Preferences->Maximizer Strings. Pretty much exactly like how they'd add a CLI command in Preferences->Script Buttons. This system is apparently considered robust enough for managing script buttons, so I don't see why it wouldn't work just as well for the probably infrequent editing of maximizer strings. I'm not suggesting anyone use an external editor or manually setting the preference for this, as that would be horribly error-prone.
 
Last edited:
Oh... Missed your add button and had totally forgotten, if I ever knew, about Preferences->Script Buttons. Will patch and test. maybe tomorrow.
 
Applied patch. Study question for me and philosophy question for others. I thought I made a change and it never showed up until I actually restarted KoLmafia. When I went to replicate that I didn't. The first change was an add and the second was a move, so I need to do some more testing to convince myself that the list as displayed by the Maximizer updates when it should.

I note that the list is a Global Preference. Some players want everything to be the same for all accounts and only want to tweak the specific account that should be different. Other people, and I am one, want (most) changes to be local for an account and if a change has to be made manually and propagated to X characters that's OK.

For me, favorite maximizer strings are a very character specific thing and the only personal benefit of this is to eliminate the clutter for specific characters. Since it will be my name on the commit, my inclination is to convert this to a per character preference before commit. But I also have a track record of making decisions that are not as popular as they could be, so I am interested in discussion.

I note that there are several discussions, that boil down to re-implementing preferences, floating around. No code was changed because no one wants the pain of getting from "here" to "there" (when "here" still works) but I recall support for the idea of eliminating global preferences completely.
 
I think I'd certainly want the remembered last few used to be by character, but I'm less bothered by the standard lists. As someone who uses maximizer a lot I won't be using this feature anyway, as it is easier for me to type what I want than scroll through the existing list.
 
I think character specific is better. It won't affect me at all, since I don't use the dropdown and only run one character...
 
The list shown in the maximizer frame only updates when you reopen that frame, so that might be what you're seeing. I suppose some sort of listener on that panel can be added, but really I don't see people tweaking those "standard" strings very often, so the problem probably isn't huge. I don't really have a strong opinion on the global/character-specific question. I went with global, because that's what the scriptList was, which was where I got a lot of the code. As I only run one character, it's all the same to me. My use pattern for this feature will probably be to delete most or all of the standard stuff, because those are things I can get faster by just typing. I'd instead put in more complex strings fitting a number of commonly (for me) encountered situations, where a custom outfit won't do because what's optimal may depend on what I can equip that day.
 
PeKaJe said:
The list shown in the maximizer frame only updates when you reopen that frame, so that might be what you're seeing. I suppose some sort of listener on that panel can be added, but really I don't see people tweaking those "standard" strings very often, so the problem probably isn't huge. I don't really have a strong opinion on the global/character-specific question. I went with global, because that's what the scriptList was, which was where I got a lot of the code. As I only run one character, it's all the same to me. My use pattern for this feature will probably be to delete most or all of the standard stuff, because those are things I can get faster by just typing. I'd instead put in more complex strings fitting a number of commonly (for me) encountered situations, where a custom outfit won't do because what's optimal may depend on what I can equip that day.
Click to expand...

OK. I will look at making this per character instead of global and decide what makes sense for updates. I'm not sure why the scriptList is global but it may just have been around long enough that the question was not asked or it would get a different answer if asked today.
 
As the default for the new setting is a copy of the current default list, a user that does nothing will see exactly the same list as before. I was thinking of putting in a button to add back to the list any strings that exist in the default list, but aren't in the user list. Think that's a good idea?
 
PeKaJe said:
As the default for the new setting is a copy of the current default list, a user that does nothing will see exactly the same list as before. I was thinking of putting in a button to add back to the list any strings that exist in the default list, but aren't in the user list. Think that's a good idea?
Click to expand...

No. I don't think it is a good idea.
 
Since the list is user based, and 99% of users will simply ignore the ability to edit it, if you wanted to go back to the defaults, the way to do so should be by removing the custom strings and having the defaults be regenerated through that.

For most people who want custom modifier strings, aliases will provide an infinitely better method of crafting them rather than building static strings which can't easily be agile based on your class or other factors. As with my standard mymax alias.
Code: 
alias mymax => ashq string maxstring = "0 beeosity, 4 item, 3 meat, 2 mainstat, .05 familiar weight, " + (my_primestat() == $stat[Moxie] ? "ranged damage, weapon damage, .1 initiative, +effective, " : my_primestat() == $stat[Muscle] ? "weapon damage, .1 initiative, +effective, " : "spell damage, .1 initiative, ") + (my_class() == $class[Zombie Master] ? "0 mp regen, " : "") + "%%"; maximize(maxstring, false);
Because aliases are just so much superior, I never expect to use this new feature, despite being in the target audience. I can run my alias with any additional tweaks needed as it adds my strings to the end, go to the maximizer tab and do any additional pokes needed to get exactly what I want, and then move on with my life into whatever new adventure is needed. And if a change happens such as effective replacing melee, I simply change the alias and all new maximizations will use that in the future. Yay.
 
Thanks for the idea Theraze! After considering what you wrote I decided that the best way to use this feature is by adding a maximizerList creating function in my loginScript!!

PHP: 
void set_maximizer() {
	
	if(get_property("kingLiberated") == "true") {
		set_property("maximizerMRUSize", "5");
		set_property("maximizerList", "mainstat | mus | mys | mox | familiar weight | HP | MP | ML | DA | DR | +combat -tie | -combat -tie | initiative | exp | meat drop | item drop | 2.0 meat, 1.0 item | item, sea | weapon dmg | ranged dmg | elemental dmg | spell dmg | adv | pvp fights | hot res | cold res | spooky res | stench res | sleaze res | all res | mp regen | ML, 0.001 slime res | 4 clownosity, -tie | 7 raveosity, -tie | surgeonosity | +four songs");
	} else {
		set_property("maximizerMRUSize", "1");
		
		buffer maximizerList;
		
		// First, default mainstat string...
		maximizerList.append("2 mainstat, .05 familiar weight, ");
		if(my_primestat() == $stat[Moxie])
			maximizerList.append("ranged damage, weapon damage, .1 initiative, +effective, ");
		else if(my_primestat() == $stat[Muscle])
			maximizerList.append("weapon damage, .1 initiative, +effective, ");
		else
			maximizerList.append("spell damage, .1 initiative, ");
		if(my_class() == $class[Zombie Master])
			maximizerList.append("0 mp regen, ");
		if(my_path() == "Bees Hate You")
			maximizerList.append("0 beeosity, ");
			
		// Regular values
		maximizerList.append(" | +combat -tie | -combat -tie | cold res, spooky res | hot res, stench res | item, food drop | familiar weight | DA, 5 DR | initiative | exp | meat drop +outfit frat warrior fatigues | elemental dmg | spell dmg | all res | mp regen | 4 clownosity, -tie | 7 raveosity, -tie | surgeonosity | ");
		
		// The third crowd
		maximizerList.append(get_property("nsChallenge2"));
		maximizerList.append(" damage, ");
		maximizerList.append(get_property("nsChallenge2"));
		maximizerList.append(" spell damage");

		set_property("maximizerList", maximizerList);
	}
}

I've probably got some serious tuning to do, but the basic idea looks good.

Just one problem: If I set maximizerMRUSize to 0, it won't update the maximizer to use the string that was set during log in. It's a pretty small problem though.
 
Last edited:
Bale said:
Just one problem: If I set maximizerMRUSize to 0, it won't update the maximizer to use the string that was set during log in. It's a pretty small problem though.
Click to expand...

Without refreshing my memory by actually looking at the code I'm pretty sure that by design maximizerMRUSize < 1 means disable the feature. So, when it was introduced, if the user did not opt in by setting it then they got exactly what behavior they had before, i.e. the same fixed list of strings. Since the list was static and embedded in the code it makes perfect sense that nothing would update if the feature was disabled because it was assumed that the static values were static and in place.

If the MRU is being used then updates will happen when the maximizer is used which would have a side effect of updating the formerly static portion of the list.

Not sure whether this is a Bug or a Feature Request and not sure it will be addressed in either case. I think a solution to the failure to update when the list is changed in the Preferences would also fix this. But since reloading the Mazimizer will also update, there is a workaround, if needed.
 
Closing the maximizer panel would be a way ... and it just occurred to me that it is possible to put that panel onto the main interface as a tab ... that would make reloading it quite difficult, yes.
 
PeKaJe said:
it just occurred to me that it is possible to put that panel onto the main interface as a tab
Click to expand...

I do that. Since I use it frequently I find it very convenient. I forgot it could be closed if I did not.

I'll make a feature request now that I got this clarification.
 
You must log in or register to reply here.
Back
Top