New Content - Implemented April 2020 IOTM: sinistral homunculus

Veracity

Veracity

Developer
Staff member
Code: 
> test newitem 528018345

Unknown item found: sinistral homunculus (10502, 528018345)
--------------------
10502 sinistral homunculus 528018345 lhmlarva.gif grow 0
Item sinistral homunculus Free Pull
--------------------
New familiar: "Left-Hand Man" (278) @ lhmlarva.gif
 
No sooner do I adapt to the new format for your "Current Familiar" in the terrarium, but KoL adds a new familiar which breaks it: at the moment, when you have the Left-Hand Man as your current familiar, you cannot click on its image in the terrarium to have it pop up desc_familiar.php for you with the familiar description. Maybe that is only if you haven't equipped it with anything yet.

I notice that it changes its image when it is holding something for you. Perhaps we could do that too, although I am content to show you the normal familiar image.

Revision 19950 should let you equip offhand items on the Left-Hand Man.
 
r19956 broke something. I am constantly getting
Code: 
Unexpected error, debug log printed.
I tried different builds and
19955 no errors
19956 constant errors
19957 constant errors

so it is clearly something in 19956 that did it.
 

Attachments

One homunculus drop is apparently not part of the mafia data yet:

Code: 
Looking at item #10512...
Unknown item found: chipped coffee mug (10512, 559241043)
--------------------
10512 chipped coffee mug 559241043 lhmmug.gif offhand q 0
chipped coffee mug 50 none
Item chipped coffee mug Maximum HP: +30, Maximum MP: +15
--------------------
 
I was sure it existed, based on the gap in the item ids, but, as a quest item, it's not in the mall, and I was waiting for somebody to report it.
Thanks.

Revision 19974
 
Revision 19987 adds the arena parameters.
I was amused to get both lead necklaces and vicious spiked collars as rewards. Is that new, for familiars that don't have their own special familiar item?

Is this done? I already made the UV-Compass count (as far as KoLmafia is concerned) when your Left-Hand Man is holding it.
I don't think we track anything else special for off-hand items.
 
I think this is done.

- We have all of the drops that have been discovered/announced
- We understand that the UV-resistant compass works the same on the familiar as in the off-hand slot
- Gear changer, etc. understand that the familiar can have any off-hand or generic familiar equipment
- FWIW, I derived the Arena parameters. It has no equipment of its own and doesn't seem to benefit from being heavier, so, shrug.
- The maximizer will consider equipping off-hand items (if it is your active familiar), just as it considers weapons for the Disembodied Hand.
 
(I tested that last one by equipping the Left-Hand Man and maximizing cold resistance. It suggested I give it a Dallas Dynasty Falcon Crest shield for (+5). :) )
 
Off-hands that give skills (such as the Latte) will always return true if equipped on the Left-Hand man even when you have any other familiar accompanying you



Code: 
[784] The Neverending Party
Preference lastEncounter changed from The Naughty Sorceress (3) to party girl
Encounter: party girl
Preference _lastCombatStarted changed from 20200725050336 to 20200725053634
Round 0: Player Two wins initiative!

ash my_familiar().to_string()

Returned: Pocket Professor

ash equipped_item($slot[off-hand]).to_string()

Returned: Kramco Sausage-o-Matic™

ash equipped_amount($item[latte lovers member's mug])

Returned: 0

ash have_skill($skill[Offer Latte to Opponent])

Returned: true

ash familiar_equipped_equipment($familiar[Left-Hand Man]).to_string()

Returned: latte lovers member's mug

> version

KoLmafia v20.6 r20267
 
Last edited:
Another bug

Code: 
  use_familiar($familiar[Left-Hand Man]);
  print("Lefty currently holds item: " + familiar_equipped_equipment($familiar[Left-Hand Man]));
  equip($item[antique shield], $slot[familiar]);
  print("Lefty currently holds item: " + familiar_equipped_equipment($familiar[Left-Hand Man]));
  lock_familiar_equipment(true);

results in

Code: 
Putting Heisenbergomatic the Pocket Professor back into terrarium...
Taking John Frursstrong the Left-Hand Man out of terrarium...
Lefty currently holds item: none
Putting on antique shield...
Equipment changed.
Lefty currently holds item: antique shield
Locking familiar item...
Familiar request unsuccessful.

Breaks with literally any off-hand item. I just used the antique shield as an example.
That "Familiar request unsuccessful." also immediately returns from the current function which leads to all sorts of lovely side-effects.
 
What do you consider to be the bug?

1) Is the bug in your program where you attempted to lock an item that is not lockable?
2) Is the bug in your program where you did not capture the return value of lock_familiar_equipment()? That function returns true on success and false - with an error - on failure. As in any function which throws an error, you can keep it from stopping your program by capturing the value.
3) Is the bug that lock_familiar_equipment is not checking if the familiar equipment is lockable before issuing a request to KoL?

All three, probably. I can add a check to lock_familiar_equipment for whether the equipment is lockable, but if it is not, that continues to be a bug in the calling program, and it will still still generate an ERROR.

Perhaps either your program or ASH itself could provide a

boolean is_familiar_equipment_lockable( item it )

function - although that is simply a call to boolean_modifier.

Code: 
boolean is_familiar_equipment_lockable( item it )
{
    return boolean_modifier( it, "Generic" );
}

boolean is_familiar_equipment_lockable()
{
    return is_familiar_equipment_lockable( equipped_item( $slot[ familiar ] ) );
}

foreach it in $items[ lead necklace, tiny bindle, antique shield ] {
    print( "A " + it + " is " + ( is_familiar_equipment_lockable( it ) ? "" : " not " ) + "lockable." );
}
yields

Code: 
[color=green]> feql.ash[/color]

A lead necklace is lockable.
A tiny bindle is not lockable.
A antique shield is not lockable
 
Malibu Stacey said:
Off-hands that give skills (such as the Latte) will always return true if equipped on the Left-Hand man even when you have any other familiar accompanying you
Click to expand...
I'm looking into how we add and remove item-supplied skills. We handle items on familiars differently, for some reason. It's surely because you can change familiar itrems both through the terrarium and via the equipment page, and we have a "familiar item" field in our FamiliarData class - in addition to having a "familir item" equipment list.

I see that we had no code to remove skills when you unequip a familiar item, and I added some, but that code doesn't even seem to be executed, because of the above.

I'm working on it.
 
Code: 
Taking off bottle-rocket crossbow...
Requesting: https://www.kingdomofloathing.com/inv_equip.php?which=2&ajax=1&action=unequip&type=familiarequip
Retrieved: https://www.kingdomofloathing.com/inv_equip.php?which=2&ajax=1&action=unequip&type=familiarequip
[b]Results:[/b] Item unequipped: [b]bottle-rocket crossbow[/b]

slot = 10 old item = -1 new item = -1
add: slot = 10 consumption = 0
That last is debug logging in the method which sets equipment, but it's only called after the familiar item has been removed from the data structure?
 
Revision 20375 now adds and removes conditional skills when your Mad Hatrack, Fancypants Scarecrow, Left-Hand Man, or Disembodied Hand puts on, removes, or changes the equipment it is wearing.

This provided the refactoring I will need to use to add/remove conditional skills when you change familiars, which is the issue you reported, I believe; it added the latte skill when you had the Left-Hand Man equipped, but did not remove it when you switched to the Pocket Professor.

Working on that now.
 
Revision 20376 should update conditional skills when you switch familiars.
Revision 20377 should update conditional skills when you change the familiar item of your current familiar using familiar.php rather than inv_equip.php.
Revision 20378 fixes a bug I introduced in 20377.
 
Last edited:
Veracity said:
2) Is the bug in your program where you did not capture the return value of lock_familiar_equipment()? That function returns true on success and false - with an error - on failure. As in any function which throws an error, you can keep it from stopping your program by capturing the value.
Click to expand...

lock_fam.png
 
You must log in or register to reply here.
Back
Top