Bug - Fixed Familiar equipment and canEquip()

T

Terrabull

Member
I right clicked to change my familiar from a Grouper Groupie to a Hunchback Minion and then I see this:

Code: 
> familiar Hunchbacked Minion

Putting     Eep Op Ork Ah-Ah! the Grouper Groupie back into terrarium...
Taking     Ahhhhhhhgggggg the Hunchbacked Minion out of terrarium...
Stealing gill rings from Eep Op Ork Ah-Ah! the Grouper Groupie...
Putting     on gill rings...
Only a specific familiar type (     Grouper Groupie ) can equip this item.

The Gear Changer shows no familiar item on it, but when I go to familiar.php in the relay browser I see the correct item on my familiar.

Follow-up, as a test I put my grouper groupie back on.

Code: 
> familiar Grouper Groupie

Putting     Ahhhhhhhgggggg the Hunchbacked Minion back into terrarium...
Taking Eep     Op Ork Ah-Ah! the Grouper Groupie out of terrarium...
lead necklace is     better than (none). Switching items...
Putting on lead necklace...
Equipment     changed.

My familiar equipment is not locked either.
 
Last edited:
S

slyz

Developer
There are a few bug reports and other threads that touch the subject, but I think it would be clearer to get a discussion going in a single place.

I think most of the confusion that happens with familiar items being incorrectly equipped happens because they need special handling by FamiliarData.canEquip() instead of the generic EquipmentManager.canEquip() that is used with the other slots.

The situation that is frequently reported is when a BetweenBattleScript switched the player's familiar while auto-adventuring. When the automation stops, Mafia restores an implicit checkpoint, and if the current familiar can't equip the familiar equipment that was stored in the checkpoint, Mafia becomes confused about the familiar equipment.

This can be reproduced very simply with the "equip" CLI command:
Code: 
> ash my_familiar()

Returned: Hobo Monkey

> ash equipped_item( $slot[familiar] );

Returned: tiny bindle

> ash item_amount( $item[zen motorcycle] )

Returned: 1

> equip zen motorcycle

Putting on zen motorcycle...
Adjusting familiar weight by 5 pounds
[COLOR="#ff0000"]Only a specific familiar type ( Llama Lama ) can equip this item.[/COLOR]

> ash equipped_item( $slot[familiar] );

Returned: zen motorcycle

> ash item_amount( $item[zen motorcycle] )

Returned: 0

> ash available_amount( $item[zen motorcycle] )

Returned: 1

> ash item_amount( $item[tiny bindle] )

Returned: 1

> equip tiny bindle

Putting on tiny bindle...
Adjusting familiar weight by -5 pounds
[COLOR="#ff0000"]You don't have the item you're trying to equip.[/COLOR]

EquipmentRequest.run() correctly detects the error message, but Mafia's idea of what is equipped is not reverted. Hence the confusion.

It would be better to avoid the problem in the first place, by making sure the player can equip the item on his current familiar before creating an EquipmentRequest:
  • In EquipCommand.java, EquipmentManager.canEquip() is called, but FamiliarData.canEquip() should be called instead for familiar equipment.
  • In SpecialOutfit.restoreImplicitCheckpoint(), no check is made, since we know the user already could wear the items. Maybe a check should be added for the equipment slot.

I think I can work on a patch if this is the way to go, but I guess a few other places would need to specifically check if the considered item is a familiar equipment and call the correct canEquip().
 
Veracity

Veracity

Developer
Staff member
Revision 8783 changes EquipmentManager.canEquip to call <currentfamiliar>.canEquip() if given familiar equipment. This fixes the CLI "equip" command and also the ASH can_equip() function. I put in special checks & messages in the equip command for familiar items and either no familiar or inappropriate familiar, just to be friendlier.
 
S

slyz

Developer
Great, thanks a lot =)
Code: 
> ash my_familiar()

Returned: Hobo Monkey

> equip fixed-gear bicycle

[COLOR="#ff0000"]Your Hobo Monkey can't wear a fixed-gear bicycle[/COLOR]

> ash equipped_item( $slot[familiar] )

Returned: none

This just leaves the issue with internal checkpoints:
Code: 
> familiar Mini-Hipster

Putting Ultralord of the Hobo Jungle the Hobo Monkey back into terrarium...
Taking Ogilvy the Mini-Hipster out of terrarium...
Requests complete.

Putting on fixed-gear bicycle...
Equipment changed.

> checkpoint

Internal checkpoint created.

> familiar hobo monkey

Putting Ogilvy the Mini-Hipster back into terrarium...
Taking Ultralord of the Hobo Jungle the Hobo Monkey out of terrarium...
Requests complete.

> outfit checkpoint

Stealing fixed-gear bicycle from Ogilvy the Mini-Hipster...
Putting on fixed-gear bicycle...
[COLOR="#ff0000"]Only a specific familiar type ( Mini-Hipster ) can equip this item.[/COLOR]

> ash equipped_item( $slot[familiar] )

Returned: fixed-gear bicycle

I don't understand everything that goes on in SpecialOutfits.java, especially in restoreImplicitCheckpoint() : it will either submit an EquipmentRequest directly, or call restoreCheckpoint(). I guess a canEquip() check should be added in both cases?
 
C

Camber

Member
Could the internal checkpoints also save/restore your familiar? That would make the problem go away. Or this that just another can of worms...
 
Theraze

Theraze

Active member
I'd just like to thank DoctorRotelle for this change... it's made using the DailyDungeon script much less aggravating as I've actually been able to NOT have it try to equip the gear from my prior character. :)
 
S

slyz

Developer
DoctorRotelle added a way to avoid the problem with implicit checkpoints, but doing "outfit checkpoint" after changing your familiar will still lead to Mafia being confused.

I'll re-open it, and try to look at the code more closely.
 
Theraze

Theraze

Active member
True, true... I mostly just love that there's a way to fix outfit checkpoint equipping prior checkpoints when you haven't actually made any yet on that character. :)
 
S

slyz

Developer
Here is a patch. I simply copied the code Veracity added to the CLI "equip" command in r8783 and copied it in SpecialOutfit.restoreCheckpoint().
Code: 
> familiar hipster

Putting Ultralord of the Hobo Jungle the Hobo Monkey back into terrarium...
Taking Ogilvy the Mini-Hipster out of terrarium...
Requests complete.

> checkpoint

Internal checkpoint created.

> familiar hobo monkey

Putting Ogilvy the Mini-Hipster back into terrarium...
Taking Ultralord of the Hobo Jungle the Hobo Monkey out of terrarium...
Requests complete.

> unequip hat

Taking off time helmet...
Equipment changed.

> outfit checkpoint

Putting on time helmet...
Equipment changed.
[COLOR="#ff0000"]Your Hobo Monkey can't wear a ironic moustache[/COLOR]

> ash equipped_item( $slot[familiar] )

Returned: tiny bindle
fullness => 0
inebriety => 0
spleen => 0
notes =>
descid => 661779077
levelreq => 0

Mafia still enters en error state when this happens, so scripts need to use "checkpoint clear" to avoid it, but at least Mafia doesn't get confused anymore.

I only added the check in SpecialOutfit.restoreCheckpoint(), but SpecialOutfit.restoreImplicitCheckpoint() can also ask for an equipment change directly if SpecialOutfit.markedCheckpoint has been used (when Mafia will switch back to your original equipment after buying Seltzers, for example). In those cases, Mafia simply equips the "Backup" outfit, so until a familiar equipment is required to access certain zones, there shouldn't be any problems.
 

Attachments

  • ImplicitFamEquip.patch
    1.3 KB · Views: 27
Theraze

Theraze

Active member
Is there any reason why the checkpoint can't just include your familiar as well? Or, alternatively, completely skip the familiar equipment?
 
picklish

picklish

Member
Other familiars try to put on ironic moustache (but just can't pull it off)

I use bumcheekcity's bumcheekascend script for all my adventuring, so I'm not sure exactly how to trigger this bug. I suspect that maybe there's a maximize call that tries to steal the moustache? This has happened repeatedly to me and it seems like mafia should never try to do this. Here's a log, where I'm in the hidden temple with the mini-hipster to start:

[647] Hidden Temple
Encounter: No Visible Means of Support

Conditions satisfied after 1 adventures.

Putting Stash the Mini-Hipster back into terrarium...
Taking Kwisatz Hatrack the Baby Sandworm out of terrarium...
Casting Fat Leon's Phat Loot Lyric 1 times...
You acquire an effect: Fat Leon's Phat Loot Lyric (duration: 10 Adventures)
Fat Leon's Phat Loot Lyric was successfully cast.

Request 1 of 203 (Manor2: Haunted Ballroom) in progress...

[648] Haunted Ballroom
Encounter: We'll All Be Flat

We'll All Be Flat

Stealing ironic moustache from Stash the Mini-Hipster...
Putting on ironic moustache...
Adjusting familiar weight by -10 pounds
Only a specific familiar type ( Mini-Hipster ) can equip this item.
 
Theraze

Theraze

Active member
Believe this happens if your script changes the familiar... it tries to re-equip the original familiar equipment at the end of the script execution.
 
Bale

Bale

Minion
I recommend that the offending script fix this with a cli_execute("checkpoint clear"). That's why the command was created.
 
You must log in or register to reply here.
Top