Search results

If you have this script in your current mood as the action for "when I gain an effect", "Cunctatitis", it becomes the action mafia will take for any request to uneffect Cunctatitis. Since the script makes such a request itself, an infinite recursion results. I don't have time to look into it...

They're already there, you just have to check "Include effects with no direct source" to see them because there is no command that the Maximizer can invoke to obtain these effects. Adding such a command is the actual feature request here.

All weapons/offhands other than Trusty should be indicated as unequippable anyway in EquipmentManager, which should automatically fix the problems with the Maximizer.

write_check() actually emitted the HTML for the checkbox; nothing you can do after that point can change it. You can use test_button() to do things based on which button was clicked, at a point other than the write_button() that actually generated it.

I was actually able to reproduce this; it requires a combat shortly after the equipment change (that's the point at which the problem actually occurs), and doesn't always happen no matter how quickly the combat was done.

This is an occasional problem due to server-side caching of combat item counts; the cache isn't always promptly updated when you add or dispose of a combat-usable item outside of combat, resulting in mafia incorrectly correcting its inventory count when it sees the item list in your next combat...

r10531 allows you to quote a keyword that contains words starting with a digit, for example: +"equip 17-alarm saucepan" This also allows commas in the keyword, but breaks down on quote marks. As usual, if you're trying to generate the command programmatically, the best solution is to use the...

It has had this ability for as long as it's been able to recommend weapons at all: +melee or -melee. They're slightly broken at the moment, in that they merely prevent you from using the opposite type of weapon rather than forcing the indicated type, but that will be fixed soon.

r10506 fully considers the container slot when maximizing - which for the vast majority of users simply means that it will put on a bugged baio if you have one, and leave it there.

I'd like to put in a vote for not going any higher than 1.5, since that's end-of-the-line for my 10.4 Mac.

If the message actually arrived before your most recent login or inventory refresh, then the items are already included in your inventory - how would mafia know whether or not this was the case?

That's already available as modifier_eval("X").

Theraze, if you only knew 8 of the recipes, they were presumably the basic, useful ones (primary + primary = secondary, secondary + secondary = tertiary). The script has to use those 9 recipes in bulk, to get the raw materials for the more obscure recipes, so discovering them ahead of time does...

That's simply not how outfits work on the server. You may be able to fake this by giving the outfit a name like "kungfu c=unequip weapon" - mafia will execute the command whenever the outfit is put on. I'm not 100% sure that this will work without error if you don't have a weapon to unequip...

If UR believes that recovery is necessary, and is unable to perform recovery, and doesn't wish to allow built-in recovery to occur... then it should be aborting, rather than returning any value. A recoveryScript returning true (and therefore preventing built-in recovery), even though the user's...

"Unrecognized item found: 3 leather aviators' caps" almost certainly indicates an unrecognized plural.

Should be fixed in r10062, not tested beyond verifying that it doesn't mess up when addCreationQueue==true.

This appears to be a consequence of having the "add creation queuing interface" option turned off, and looks to have been broken since at least r6036. It's not entirely harmless; the error is preventing the item list from being re-sorted, so (for example) items you no longer have room for...

That is not at all a "problem", slyz. Two identical definitions (functions, variables, or whatever) in the same scope does indicate a bug in the code, and therefore generates an error, since one of the definitions would become completely inaccessible if that was allowed. Identical definitions...

What the heck is it speculating ABOUT? None of the character state changes that "whatif" supports can occur during a combat, so I can't see anything that this could possibly accomplish.