Modifier Maximizer

I can probably lend you mine after i ascend. maybe two or three days. just hit level 10.

edit: nevermind. ;)
 
Last edited:
I am not sure that mafia is detecting Clownosity correctly, it keeps saying fail even though i do have enough parts, it also doesn't how much +clownosity each equipment gives.

I'm finding it detects it fine whilst being worn, but using modifier maximiser never works.
 
I'm not in a position to test this, but a clanny was having problems with the maximizer (while using Rinn's autoBasement.ash). I think it comes from trying to force the special sauce glove, like this: maximize mus, +equip special sauce glove, +equip staff of the kitchen floor.

My guess is that Mafia tries to equip the staff before putting on the glove. Is there already something in the code to avoid this problem?
 
The Maximizer always deals with slots in a fixed order, which has the weapon before the off-hand. The other way around would fail in far more situations, for example changing from a 2H weapon to a 1H + offhand, or from no weapon to dual-wielding.

+equip isn't really the most efficient way to put specific items in specific slots. It would be better to explicitly equip those items, then maximize with the slots excluded:
equip special sauce glove; equip staff of the kitchen floor; maximize mus, -weapon, -offhand
 
Special sauce glove is an accessory, not an off-hand item. What about equipping accessories before weapons?

That ruins your work-around of course, but similar principles still apply. :)

equip special sauce glove; maximize mus, +equip special sauce glove, +equip staff of the kitchen floor
 
Last edited:
Out of curiosity, does anyone know how difficult it would be to create an ASH function that return the equipment maximize would choose? Like say:
item[slot]modifier_maximizer(string expression)
... Seeing as how it looks like it creates an 'item [slot]' map. Just curious.
 
Out of curiosity, does anyone know how difficult it would be to create an ASH function that return the equipment maximize would choose? Like say:

I can actually give you an example of how difficult it would be. Until the Modifier Maximizer there was an ASH script that served the same purpose:Equipt. In case you're curious, the Modifier Maximizer works better than that script, so after you take a look at it, just assume you need a larger and more complicated script to do the job as well.
 
Oh, I'm not dissin' Maximizer. It's just that it KEEPS ON TAUNTING ME! "Hi, I have all this information on equipment alone that would be beautiful for an ASH script. You want to use it? Here you go: true/false! Nya nya!" ;_; It's so mean...

Seriously though, imagine the power ASH scripts could gain from that. Heck, combine speculate with that map that the Maximizer could return and you'd have bloody raw steaks just right for grilling. And if you're vegetarian... uh... well, you should get the idea anyway ^^

I can pick up ASH scripting easily enough, but when I look at Java, I get lost fast. I made it to about 20 lines past the comments in the Maximzer Java before I got lost.
 
Oh, I'm not dissin' Maximizer. It's just that it KEEPS ON TAUNTING ME! "Hi, I have all this information on equipment alone that would be beautiful for an ASH script. You want to use it? Here you go: true/false! Nya nya!" ;_; It's so mean...

Seriously though, imagine the power ASH scripts could gain from that. Heck, combine speculate with that map that the Maximizer could return and you'd have bloody raw steaks just right for grilling. And if you're vegetarian... uh... well, you should get the idea anyway ^^

I agree. I've been saying that for ages. Sadly that's a feature which has not been added despite pleas from quite a few.
 
Out of curiosity, does anyone know how difficult it would be to create an ASH function that return the equipment maximize would choose? Like say:
item[slot]modifier_maximizer(string expression)
... Seeing as how it looks like it creates an 'item [slot]' map. Just curious.
I had some time today so dug into MaximizerFrame's code, fortunately i didnt need to do much inside of the class.. it was mostly getting the Boost sub-class export its slot (and isEquipment) info

patch file: View attachment maximize_ash.patch (for 8809)
item [slot] maximize( string ) ... asking for something impossible like "mox 1000 min" will return a map with only $slot[none]=$item[none]
I havnt done much testing but hopefully wont have effected standard (CLI/GUI) maximize functions
 
Great! This will save me all sorts of time that I might have otherwise spent on maximizer improvements that are no longer possible due to the contents of a Boost now being carved in stone.

Or, in other words: there was a reason this functionality wasn't there from the start...
 
Great! This will save me all sorts of time that I might have otherwise spent on maximizer improvements that are no longer possible due to the contents of a Boost now being carved in stone.

Or, in other words: there was a reason this functionality wasn't there from the start...
I havnt asked for this code to be added to the client or effect the main code base in anyway, i made something for testing my own script and remembered the question so posted a .patch so others could experiment
if you want i can remove the .patch, i meant no offence and was just trying to be nice but clearly couldnt have been more malicious
 
Great! This will save me all sorts of time that I might have otherwise spent on maximizer improvements that are no longer possible due to the contents of a Boost now being carved in stone.

Or, in other words: there was a reason this functionality wasn't there from the start...
... ... ... And? Sorry, you've got my curiosity piqued ^^ Why haven't you made an ASH equivalent? Inquiring mind(s) want to know! (No, I'm serious, educate us. I like hearing from the creator on something.)
DerDrongo said:
I havnt asked for this code to be added to the client or effect the main code base in anyway, i made something for testing my own script and remembered the question so posted a .patch so others could experiment
if you want i can remove the .patch, i meant no offence and was just trying to be nice but clearly couldnt have been more malicious
Oh, I don't think Seventh was being hostile. A little sarcasm to start, true, but at least he's commenting. He's just saying there's a reason he HASN'T done this. I like to think there's a "yet" in there but I may be reading too much in to it.
 
The proposed item[slot] map would lose any information about the order of equipment changes - which is currently broken anyway: it fails to switch to a chefstaff if you first have to equip a special sauce glove to be able to wield them.

I would really like to express the changes in terms of outfit commands where possible - for example, if you had your usual rollover gear saved as an outfit, "maximize adv" could simply put that on via a single game request, and only revert to slot-by-slot changes when Grimace darkness or other factors make a different setup optimal.

The proposal doesn't handle effect-based boosts at all, which are probably more useful to have script access to. The current format for them definitely needs to change, to be able to represent the combination of an uneffect and an effect-gaining command: that's needed to properly handle mutually-exclusive effects, like the pressurized potions.
 
The proposal doesn't handle effect-based boosts at all, which are probably more useful to have script access to.
From a scripter's perspective, equipment trumps effects in terms of complexity because of the constraint imposed by equipment slots, the greater number of synergies and the fact that most effects have only one modifier, whereas equipment generally has other specific attributes to consider (power, melee/ranged etc...) as well as a greater chance of having some detrimental aspects along with beneficial ones.

Finding a list of effects that have a specific modifier and handling special cases seems less overwhelming. Not that we wouldn't want to have access to the Maximizer's advice on effects, of course ^^
 
The proposed item[slot] map would lose any information about the order of equipment changes - which is currently broken anyway: it fails to switch to a chefstaff if you first have to equip a special sauce glove to be able to wield them.
This may sound a bit egotistical, but I have scripts already in place that takes care of outfits with a design to keep certain aspects in place, for example, if I'm wanting to equip a chef staff, it checks if I have Spirit of Rigatoni or (I'm a sauceor and have a sauce glove). I also have checks to keep a Juju Mojo on if I have gazes active or GAPs in place if I have one of its skills. Since the command would simply provide the info, it'd be up to the scripter to use it properly. If I use such info in my script, it'd be up to me to do equip($slot[accx],$item[sauce glove]); equip($item[chef staff]); which is how a script should handle chefstaves anyway. I also completely throw out "checkpoint" and "outfit checkpoint" for that very reason with my own script counterparts, ensuring accessories go first. "With great information comes great responsibility!"
I would really like to express the changes in terms of outfit commands where possible - for example, if you had your usual rollover gear saved as an outfit, "maximize adv" could simply put that on via a single game request, and only revert to slot-by-slot changes when Grimace darkness or other factors make a different setup optimal.
OK, this is completely unclear. You want "maximize adv" to take a saved outfit and check each and every piece of it anyway against all other +adv items? This sounds like just adding in an extra step. ... Or is this why mafia puts on one piece of equipment on at a time, because that's all it can do? You have to tell KoL "Put on a club. Put on a shield." instead of "Put on a club and a shield." because KoL doesn't take the latter, right?
The proposal doesn't handle effect-based boosts at all, which are probably more useful to have script access to. The current format for them definitely needs to change, to be able to represent the combination of an uneffect and an effect-gaining command: that's needed to properly handle mutually-exclusive effects, like the pressurized potions.
Effects are great for the GUI, but in an ash script, I think the scripter is going to be rather selective already about what effects to automatically use. That's just me, but if I "maximize mox" I'm looking for gear, but I'll be selective about my serums of sarcasm. But then again, more info to have wouldn't be a bad idea and I'm sure someone could come up with a way to manipulate it thoroughly.
 
Back
Top