Feature - Implemented Buff rebalancing to ignore AT buffs

HippoKing

HippoKing

Member
Would it be possible to have a checkbox in the preferences (by the use only buffs specified in mood) which changes the behaviour of the buff rebalancer to not cast AT buffs? It is fairly useless to get given more turns of a buff that I'll be shrugging off soon. I know I could fix it using a manually defined mood, but this is a more elegant solution.
 
Last edited:
This seems to me like it would add unnecessary complication. We already have the option to either "Cast buffs not defined in moods during buff balancing" or not as we desire. It seems to me that if your proposal was accepted, buff balancing would become overly complicated.
 
I understand why it may seem like an unnecessary complication to you, but I really do understand HippoKing's desire. This would simplify my KoL life a great deal.

I'd be turning that on and off so frequently that instead of putting it in preferences, I'd like a little link in my char pane, right above my buffs: "allow mana burn for songs". Actually, there should be an icon for this to attach to each AT song, that when I hover over it it will say, "allow this song to be buffed when burning mana." That'd be AWESOME! There are usually some songs I maintain lots of, like Phat Loot, but others that I want in more limited quantity so I can shrug them without regrets.

Pretty please!
 
A BuffScript override similar to RecoveryScript would probably make everyone the happiest.
 
No! No! No! If you did that, then I'd have no choice except to write Universal_buffing! loL!

Seriously though, I don't want to do all that to replicate the functionality already available in mafia with only a few changes. Besides, I'd still need some way for the user to indicate which AT buffs were okay to have a lot of.
 
Bale said:
Actually, there should be an icon for this to attach to each AT song, that when I hover over it it will say, "allow this song to be buffed when burning mana." That'd be AWESOME!
Click to expand...

That could be just as well generalized to toggling any effect in the current set ...
 
While slimetubing I've started wasting huge amounts of MP rebalancing Ur-Kel. I'm going to mess with the mood thing to fix it, but I think there are some decent ideas in this thread and it never actually got shot down so I'm bringing it back from the deep.
 
Last edited:
I like the buffScript idea, but another that's crossed my mind before was the idea of being able to <include> moods inside of each other. It would make handling of specific in-run situations, plus or minus or meh combat, much easier.
 
Actually, I'd be happy with something as simple as a betweenBattleScript that could be set to fire between relay browser adventures. Actually, wait, couldn't I just make a script that gets called unconditionally in a mood? ... hmm...
 
If you do that, just make sure that script doesn't involve permanent changes to equipment or it will just set back after the mood is finished. A bBS will switch back also, but only once you stopped adventuring. I think the CLI command "checkpoint clear" is meant to counter that, but I don't know if it works in moods or not. I know that works for bBSs.
 
Would the following be a sufficient solution: checking a preference like skillBurnXXXX for each skill being considered for mana burning, which if present could override its default inclusion in the burn. (In both directions: this would also allow you to enable skills like combat rate modifiers and Ode for burning, if that's what you really want.) There would be no UI provided for these prefs, but a relay script could easily be written to give skill-by-skill control, like the one I wrote to fine-tune the breakable item handling.

A burnScript would be problematic, since the existing mana burn mechanism doesn't cast skills directly - it just returns a CLI command for the next burn action, if any. It's called speculatively, to see if burning would take place or not, so a user script that might perform any arbitrary action wouldn't fit very well in this framework.
 
Heck yes! That would be awesome! One suggestion for improvement though...

What about skillBurnXXXX being an integer instead of a boolean. If it is set to a number greater than 0, it will be used for durationLimit instead of Preferences.getInteger( "maxManaBurn" ) + KoLCharacter.getAdventuresLeft() on line 519 of MoodManager. That way I can allow limited mana burning for each skill separately.

And YES, I would really use the feature that way! There are many times I would be happy to burn mana on up to 50 turns of a skill, knowing that I'll eventually need it even though I won't want too much more than that. This way I'll just have to pay attention and turn skillBurnXXXX down to 0 when I have enough.


jasonharper said:
A burnScript would be problematic, since the existing mana burn mechanism doesn't cast skills directly - it just returns a CLI command for the next burn action, if any. It's called speculatively, to see if burning would take place or not, so a user script that might perform any arbitrary action wouldn't fit very well in this framework.
Click to expand...

Agreed. However you could give more script control over manaburning if you added a remove parameter to the trigger command. Right now I can have a script add triggers to my mood, but there isn't any good way to remove them. Could you remedy that? This plus the change above would give all the control over moods that I could want.
 
Last edited:
jasonharper said:
Would the following be a sufficient solution: checking a preference like skillBurnXXXX for each skill being considered for mana burning, which if present could override its default inclusion in the burn. (In both directions: this would also allow you to enable skills like combat rate modifiers and Ode for burning, if that's what you really want.) There would be no UI provided for these prefs, but a relay script could easily be written to give skill-by-skill control, like the one I wrote to fine-tune the breakable item handling.
Click to expand...

This would be perfect, far more useful than the idea I originally posted.
 
I really do love how jason takes a problem, and finds a solution to it we never knew we wanted, but probably wouldn't want to live without once we have it. Thanks for all the work you've put in!
 
You must log in or register to reply here.
Back
Top