Bug - Fixed Debug log when running Bales OCD DB manager

M

Magus_Prime

Well-known member
I also posted this, sans debug log in the OCD DB thread. With r17526 I got the following when running the script:

Code: 
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Multiple matches for "rock"; using "[8042]rock". (relay_OCD_dB_Manager.ash, line 268) Clarify by using one of:
"[2108]rock"
"[8042]rock"
Unexpected error, debug log printed.
Script execution aborted (java.lang.NullPointerException): (relay_OCD_dB_Manager.ash, line 392)

Here's the log. View attachment DEBUG_20161215.txt
 
Looks like it boils down to this.contentString being null for some item (that isn't $item[none], since those are removed by relay_OCD before saving the map). You may have to go in and manually edit the datafile to use [2108]rock instead of rock (as the other one is spelunky-only, and therefore not persistent).
 
$item[ none ] should always be the constant DataTypes.ITEM_INIT, which has the name "none".
I can see how the name of an item could be null - ItemDatabase.getItemDataName( itemId ) just does a map lookup and returns what it finds.

So, revision 17538 does this:

The one method in ASH which actually makes an item object (except the place which makes ITEM_INIT) now does the following:
- If the itemId is -1, you get ITEM_INIT
- If the name is null, you get "[XXXX]" - the item ID in brackets.

This should prevent ASH programs from taking this particular NPE, at least. I'd be curious to see which item(s) end up being just "[XXXX]".
 
I'm happy to help but how would I tell which item is the source of the problem? I'm unable to check now but would the checkitems command shed any light on the issue?
 
Last edited:
The only place I see in ASH where it does not turn any item whose itemid does not have a known data name into ITEM_INIT is this:

Code: 
	public static final Value makeItemValue( final AdventureResult ar )
	{
		int num = ar.getItemId();
		String name = ItemDatabase.getItemDataName( num );
		return DataTypes.makeNormalizedItem( num, name );
	}
Which is to say, we translate an AdventureResult - the object that all the rest of KoLmafia uses to represent "items" (and "effects" and other things) - into an ASH $item object without checking whether the data name is know. The only place in the code that I can find where this method is used is in ASH's outfit_pieces() function. That seems unlikely to have bogus items.

Since you are running Bale's OCD, take a look at your data file. I assume he stores item objects there - although, who knows, perhaps he store strings with item numbers, since he was quick to defend Exandora's practice of doing that. ;)
 
I do not!! I respect Ezandora's practice of backwards compatibility, but I'd have to be paid well to do it myself since only a nutjob would do that for fun.


Those warning actually highlight an interesting issue. You see they appear because I'm parsing mafia's concoctions.txt file.

That means that mafia has a bug! Everytime it sees the Crimbo Rock in concoctions.txt it thinks it is actually the Spelunky Rock since it isn't listed as [2108]rock. Presumably KoLmafia has the same problem as OCD. The mafia text files should be corrected to use item numbers.
 
You must log in or register to reply here.
Back
Top