Bug - Fixed Data loss when writing maps to files

S

Saklad5

Member
Item #10207, "[glitch season reward name]", is not correctly stored when using the map_to_file function. I believe this has something to do with the dumpValue() function in net/sourceforge/kolmafia/textui/parsetree/Value.java, but I'm not certain. At any rate, the result is that it is impossible to write maps containing this item to file without losing information, which is a fairly serious issue.

In particular, Bale's OCD Inventory Control script is unable to store configurations for that item, which necessitates manually adding the correct data to the file using a text editor every single time it is written.
 
Veracity

Veracity

Developer
Staff member
It's a combination of a lot of things:

1) Items and Effects can start with [XXX] to specify the id. This allows us to distinguish between [2325]Staff of Ed and [7961]Staff of Ed, for example.
2) When we generate an "item" data type, we use that syntax if it is ambiguous. See Datatypes.makeNormalizedItem
3) Value.dumpValue will always include the item number when writing an item to a map. Therefore, it passes such annotated items straight through. Otherwise, it prepends [XXX]
4) Datatypes.parseItemValue calls ItemDatabase.getItemId to parse a name, with or without [XXX]. I don't know what that does with [glitch season reward name]. The wrong thing, I expect.

I suspect that if dumpValue generates "[10207][glitch season reward name]" to print to the file, all will be well. But perhaps parseItemValue needs some work:

Code: 
[color=green]> ash to_item( 10207 ).name[/color]

Returned: [glitch season reward name]

[color=green]> ash $item[[glitch season reward name]].name[/color]

Changing "[glitch season reward name]" to "[0]" would get rid of this message. ()
Returned:

[color=green]> ash $item[[10207][glitch season reward name]].name[/color]

Changing "[10207][glitch season reward name]" to "[glitch season reward name]" would get rid of this message. ()
Returned: [glitch season reward name]
Seems like there are multiple places in (or out of) ASH that would need tweaks to handle this single stupid glitchy item.
I'm not sure it is worth the effort. :)
 
Veracity

Veracity

Developer
Staff member
I've done a lot of work on ambiguous objects recently.

Code: 
item[int] gmap1 = {
 0: $item[ seal tooth ],
 1: $item[[glitch season reward name]],
};

foreach i, it in gmap1 {
    print( i + " => " + it );
}

map_to_file( gmap1, "gsrn.txt" );

item[int] gmap2;

file_to_map( "gsrn.txt", gmap2 );

foreach i, it in gmap2 {
    print( i + " => " + it );
}
yields:

Code: 
[color=green]> ash $item[[glitch season reward name]].name[/color]

Returned: [glitch season reward name]

[color=green]> gsrn[/color]

0 => seal tooth
1 => [glitch season reward name]
0 => seal tooth
1 => [glitch season reward name]
So, the issue reported in this Bug Report is fixed. However, looking at the generated file:

Code: 
0	[2]seal tooth
1	[glitch season reward name]
I was surprised to see that we do not always prepend the item number. I have a guess as to why. I'll look at the.
 
S

Saklad5

Member
Yes, this was fixed since I encountered the issue. I believe it is because the item behaves normally as of July 2019: it wasn’t marked public before that point, and that screwed up a lot of things. Fitting, I suppose.
 
Veracity

Veracity

Developer
Staff member
Revision 19883 will always put [XXXX] in front of Items, Effects, and Skills.
It will also do that for monsters, unless the ID is 0.

This will allow us to dump those object types and accurately retrieve them, even if the names become ambiguous at some point in the future.
 
You must log in or register to reply here.
Top