Bug - Fixed Badly Disambiguated Rocks

Bale

Bale

Minion
Today I noticed that a rock was stolen from me in PvP. Rocks go for 5,497 Meat in the mall so I wondered why it wasn't automatically closeted like my other items of such price. So I checked is_tradeable($item[rock]) and found that mafia didn't think it could be traded! That was my tip-off that something was wrong.

I almost made an incorrect bug report about rocks being accidentally marked untradeable, ungiftable and undisplayable. Then I discovered that is_tradeable($item[rock] was actually returning information for number 8042, the spelunky item called "rock" not item number 2108, the "rock" which can be traded. Okay not much I can do about that... But WAIT! Why didn't mafia recognize the item in my inventory correctly?


Code: 
[COLOR="#808000"]> ashq foreach it in Get_inventory() if(to_string(it) == "rock") print("Item " +to_int(it)+ ": " +it);[/COLOR]

Item 8042: rock

Since it is clearly impossible for the spelunky item to be in my regular inventory, mafia made a mistake about my inventory. That should not happen.
 
Veracity

Veracity

Developer
Staff member
Probably.

You want an item which is ambiguous using name only to be disambiguated correctly? Use the item ID, not the name.
 
Theraze

Theraze

Active member
Yeah, my FReq ended up becoming making identically named items fail item-named checks.
Theraze said:
Alternatively, it would be nice to error on duplicate name lookups. If we use $item[Eye of Ed] and it isn't a unique match, that should probably make the script error out, to force script writers to use the number instead. Just like when you use non-specific fuzzy matching... as per this example
Code: 
> ash $item[eye]

Bad item value: "eye" ()
Returned: void

> ash $item[eye of]

Bad item value: "eye of" ()
Returned: void

> ash $item[eye of ed]

Returned: Eye of Ed
It would assist in making the item calls more consistent for users.

Thanks for considering this. I'd like to be able to make scripts more future-proof with this, so that if/when Jick makes more identically named items, the scripters at least get notified as mafia updates for the new identical content.
Click to expand...
Well, mafia has updated with more new identically named content, so... :)
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
Veracity said:
Probably.

You want an item which is ambiguous using name only to be disambiguated correctly? Use the item ID, not the name.
Click to expand...

Is to_int( item ) converting the item to a string before converting to an int? I'm a little surprised that starting with an item (from get_inventory() ) gives this result.
 
Bale

Bale

Minion
lostcalpolydude said:
I'm a little surprised that starting with an item (from get_inventory() ) gives this result.
Click to expand...

Yes. This is the problem. It means that scripts which do things like closet my steal-able items and OCD cannot identify my inventory. OCD doesn't even notice that I should have malled those rocks because it doesn't know what sort of rock they are.

I find this really strange since api.php?what=inventory&for=testing gives me a list of items by number, not by name. How did that get turned into the wrong item?
 
H

heeheehee

Developer
Staff member
Bale said:
Yes. This is the problem. It means that scripts which do things like closet my steal-able items and OCD cannot identify my inventory. OCD doesn't even notice that I should have malled those rocks because it doesn't know what sort of rock they are.

I find this really strange since api.php?what=inventory&for=testing gives me a list of items by number, not by name. How did that get turned into the wrong item?
Click to expand...

So, here's what 5 minutes of poking around netted.

- ApiRequest.java updates inventory via InventoryManager.parseInventory(json).
- InventoryManager.parseInventory only uses the item name to register new items if they don't already exist.
- It further adds items to the list by fetching them from the ItemPool, by ID.

Some manual testing:
- checked inventory for rocks, found none.
- bought a rock from the mall, now had a rock in inventory.
- checked its id by iterating over get_inventory(), found 8042.

Looks like an issue with get_inventory() itself.
Code: 
DataTypes.parseItemValue( items[i].getName(), true ),
yup.
 
H

heeheehee

Developer
Staff member
r17305 fixes this and changes most other instances of DataTypes.parseItemValue() to DataTypes.makeItemValue(). This may also have very minor performance benefits, since we don't have to deal with String processing.

Poke me if I broke anything. It all seems to compile, at least, and the initial change (as pointed out above) seemed to fix the rock issue.
 
You must log in or register to reply here.
Top