Feature Store breakfast summoning settings as character preferences

[Fred Nefler]

Since I have multiple characters with different sets of librams, I'd like to see the breakfast setting which controls which libram to use for burning MP to be stored on a per character basis, rather than as a global preference. Or some additional setting which can be used to override the global setting on a per-character basis. As is, if I want one character to summon nothing but brickos amongst his multiple librams, another character will summon nothing since he does not have the bricko libram. It'd be nice if I didn't have to keep changing that breakfast preference on every login with a different character.

Similarly for tomes.

 

[Orbrisa]

I would find this to be a useful addition.

 

[slyz]

Here is the list of GLOBAL preferences that correspond to the various options you can find in the Breakfast tab of the preferences:

loginScript
logoutScript
breakfastSoftcore
breakfastHardcore
loginRecoverySoftcore
loginRecoveryHardcore
pathedSummonsSoftcore
pathedSummonsHardcore
visitRumpusSoftcore
visitRumpusHardcore
visitLoungeSoftcore
visitLoungeHardcore
autoPlantSoftcore
autoPlantHardcore
grabCloversSoftcore
grabCloversHardcore
readManualSoftcore
readManualHardcore
useCrimboToysSoftcore
useCrimboToysHardcore
tomeSkillsSoftcore
tomeSkillsHardcore
libramSkillsSoftcore
libramSkillsHardcore
grimoireSkillsSoftcore
grimoireSkillsHardcore
harvestGardenSoftcore
harvestGardenHardcore

where "Softcore" is for when you are out of Ronin/Hardcore and "Hardcore" is when you are in-run. I think they should all be marked either as GLOBAL or USER, for consistency.

My limited testing showed that marking them as USER instead of GLOBAL in defaults.txt is fairly transparent to the user. The first time you launch Mafia with the updated defaults.txt, the preferences are read from GLOBAL_prefs.txt, and written in <name>_prefs.txt. Afterwards, Mafia always the picks up the value in <name>_prefs.txt.

Since changing the status from GLOBAL to USER won't wipe anyone's preferences, it becomes simply a matter of choosing whether people would rather have the flexibility of fine-tuning their breakfast options for each character, or the convenience of not having to go through the breakfast settings of all their characters one by one.

I would like to note that fine-tuning is already possible via login/logout scripts, by adding something like this in your login script:

if ( my_name() == "player1" )
{
	cli_execute( "cast * summon bricko" );
	set_property( "libramSkillsSoftcore", "Summon BRICKOs" );
}
else if  ( my_name() == "player2" )
{
	cli_execute( "cast * summon party favor" );
	set_property( "libramSkillsSoftcore", "Summon Party Favor" );
}

and this in your logout script:

set_property( "libramSkillsSoftcore", "none" );

The only drawback I can see for this change is for people who want to be able to easily change the breakfast preferences of two or more characters. Since a workaround exists, do we want this change?

 

[Winterbay]

Regarding settings: How would the interface for setting one or the other for different chracters look. At the moment it is simple because it is global and you set them once in the preferences-window, but if you break it up into user-variables (not a bad idea per say, my never ascended multi and my out-of-ronin ascender will probably have very different ideas on what to do) you will have to be able to specify which setting you change if you do not do it via the CLI or a relay-script.

 

[Theraze]

It would still be the same, just that if you set it in the Preferences tab before you log in, that wouldn't actually affect the users. To change breakfast settings, you'd need to either temporarily turn off running breakfast or manually edit the settings files with the right type of text editor. As such, I'd expect changing this to USER level would lead to a direct increase in how many people accidentally damage their demon names and other character settings by turning tabs into spaces accidentally.

 

[slyz]

It would be completely transparent. Log in player1, change the settings in the Preferences, log out, log in player2, repeat.

EDIT: I forgot to add something about changing preferences when you are not logged on. I guess that doesn't matter much.

 

[Fluxxdog]

Is this still a thing?

 

[Bale]

Not sure how to answer that. The feature is not rejected, not implemented and not approved.

Is this still a thing?

Is it a thing if it is just hanging out in limbo?

 

[Fluxxdog]

It just strikes me as odd. Some of them make more sense as a per-character setting, others are fine as a global. Take the garden, for example. You have one character who prefers letting his skeletons grow in to a Skulldozer, while the other farms his pumpkins every single day.

Forgive, me, but I'm trying to look at things from both a user and developer point of view. Some of my questions may be more dev oriented, like when I ask "Why were all the breakfast settings made global in the first place?"

 

[fronobulax]

It just strikes me as odd. Some of them make more sense as a per-character setting, others are fine as a global. Take the garden, for example. You have one character who prefers letting his skeletons grow in to a Skulldozer, while the other farms his pumpkins every single day.

Forgive, me, but I'm trying to look at things from both a user and developer point of view. Some of my questions may be more dev oriented, like when I ask "Why were all the breakfast settings made global in the first place?"

"It seemed like a good idea at the time"?

I think most of the devs would do something different from the current scheme if they reworked preferences and some of the devs might even do the same thing.

I think the reason this languishes is because it doesn't bother anyone that much and it will be fiddly to fix.

As an example, first I have to define a user preference and see that it does the right thing. Then I have to set that preference using the global preference if the user preference is not set. Then I have to figure out what to do if a user who doesn't know the preference is per account, changes the global preference. Or do I have code that tracks which characters have "accepted" the copy of global to user or....? If there is a good, or acceptable solution to the general problem of transparently converting a global preference to a user preference then I would certainly consider applying that here. But I have not figured out one that I am happy with.

 

[Fluxxdog]

"It seemed like a good idea at the time"?

That's what I said about my wedding! HA! But seriously...

I think most of the devs would do something different from the current scheme if they reworked preferences and some of the devs might even do the same thing.

I think the reason this languishes is because it doesn't bother anyone that much and it will be fiddly to fix.

As an example, first I have to define a user preference and see that it does the right thing. Then I have to set that preference using the global preference if the user preference is not set. Then I have to figure out what to do if a user who doesn't know the preference is per account, changes the global preference. Or do I have code that tracks which characters have "accepted" the copy of global to user or....? If there is a good, or acceptable solution to the general problem of transparently converting a global preference to a user preference then I would certainly consider applying that here. But I have not figured out one that I am happy with.

What if you gave them the option to make such preference changes global? For example, a button that says "Do this for all characters". Make the options user by default, but give them an option to apply such changes to all characters. It would make it clear what's happening (user by default, global by choice). What would be other pros/cons to that?

 

[Theraze]

I'd probably go the other way to make it a player choice and keep legacy behaviour. Make a "use character-specific breakfast settings" checkbox on the automation page that sets a character preference and, if it gets checked, copy the current global settings (whatever the player has, not the defaults) to that character's properties. If the box is unchecked, reset back to defaults.

 

[Palinathas]

I like Theraze's idea. I have had a few issues with using Mafia for multiple characters. This would make things better.

 

[fronobulax]

That's what I said about my wedding! HA! But seriously...What if you gave them the option to make such preference changes global? For example, a button that says "Do this for all characters". Make the options user by default, but give them an option to apply such changes to all characters. It would make it clear what's happening (user by default, global by choice). What would be other pros/cons to that?

Button == Swing which suggests my enthusiasm is going to be drastically diminished, at least until my boss follows through and actually requires me to write/modify Swing code at work instead of farming it out. A button is not as "transparent" as I would like. The user who does nothing should get the same behavior as they always did is part of my definition of transparent.

Opt in as suggested elsewhere might be the way to go.

 

[roippi]

There's no need for buttons and opt-in stuff. Slyz's post #3 points out that simply changing various preferences from GLOBAL to USER in defaults.txt migrates them seamlessly to user preferences.

I haven't tested it myself since I don't use multis.

 

[Fluxxdog]

Button == Swing which suggests my enthusiasm is going to be drastically diminished, at least until my boss follows through and actually requires me to write/modify Swing code at work instead of farming it out. A button is not as "transparent" as I would like. The user who does nothing should get the same behavior as they always did is part of my definition of transparent.

Really? Swing is that bad? (Side question: That difficult or that buggy?)

There's no need for buttons and opt-in stuff. Slyz's post #3 points out that simply changing various preferences from GLOBAL to USER in defaults.txt migrates them seamlessly to user preferences.

I think frono's objection is that would make a behind-the-scenes change that is different from current front-end experience. Right now, changing your pasta summoning for hardcore for one character actually changes it for all characters since they all use the same prefs file.

Times like this I think of PCGen. When they were changing parsers for data files, they would notify people of deprecation and give them plenty of time to make the adjustments needed for their files. Heck, one of the devs even wrote a script (PERL I think) that would make the changes for you as much as possible to update them. Granted this isn't as major a change, but I get the work and hassles involved.

 

[roippi]

Really? Swing is that bad? (Side question: That difficult or that buggy?)

It's pretty bad. It's a completely different skill from coding Java, in my experience. And you have to work around so many different pitfalls with non-intuitive code, it's quite obnoxious.

I think frono's objection is that would make a behind-the-scenes change that is different from current front-end experience. Right now, changing your pasta summoning for hardcore for one character actually changes it for all characters since they all use the same prefs file.

And?

I can't think of a scenario when someone was depending on changing pasta summoning globally. If they were using a workaround in a loginScript that switched on character name, that will still work.

 

[fronobulax]

My limited testing showed that marking them as USER instead of GLOBAL in defaults.txt is fairly transparent to the user. The first time you launch Mafia with the updated defaults.txt, the preferences are read from GLOBAL_prefs.txt, and written in <name>_prefs.txt. Afterwards, Mafia always the picks up the value in <name>_prefs.txt.

I believe you but I have a distinct recollection that there was a time and set of circumstances when this was not true. I recall an overloaded (?) method that was something like get_parameter and it took a a parameter that specified whether a preference was user or global. If it did not find the parameter in the specified file then it took the default, not whatever the value was in the other file. So I suppose I should stop posting and actually look at the code. This may not apply to any of the breakfast preferences and a case could be made that KoLmafia should be consistent at the code level.

I'll shut up now and look at code.

Programming in Swing uses constructs that remind you of Java but are very counter intuitive unless you have been doing GUI programming for years. I liken it to assembling an onion, layer by layer, from the inside out. Does the phrase "grid bag" sound like something meaningful?

 

[Veracity]

I think it is reasonable to change (some of) the breakfast setting from GLOBAL to per-character.

Personally, although I actually have 3 test multis and a mall multi, the only character with IOTMs is my main, so garden choices, libram choices, and so on don't need to be per-character for me, but I can see why those with multiple multis with IOTMs might want to customize those settings.

Right off hand, I see no obvious problems with simply switching preferences from one map to another - although you will have leftover settings in the wrong map, after doing so.

I guess that ties into the other thread which discussed "how do you get rid of obsolete preferences"?

 

[roippi]

Does the phrase "grid bag" sound like something meaningful?

Layouts certainly are one of swing's worst offenders, but in its marginal defense the more complex layout managers were meant to be used with GUI builder tools. The fact that I've personally hand-coded stuff in GridBagLayout and SpringLayout mostly speaks to my questionable sanity levels.