Bug - Fixed Incorrect items added to Inventory

Darzil

Developer
In ResultProcessor items are added to inventory by name, rather than by Id. As a result, for example, if you create a Staff of Ed (item number 2325) instead Staff of Ed (item number 7961) is added to inventory.

It needs to be changed to add items by Id, which looks like it'll involve a re-write of how items are processed in ResultProcessor, maybe moving them to the registerNewItems code where the relevant information is held.

Unfortunately I'm unlikely to have any time to look at this til Wednesday at the earliest, so if someone else wants to help clean up our inventory it'd be appreciated!
 

Veracity

Developer
Staff member
This is a can of worms. We used to have the code you want in "register new items" - every item which had a relstring would be processed and removed from the buffer by that function, leaving the later code to process only things that did not have a relstring.

I liked that when I wrote it, but I recently did not like it, since it would show item acquisitions before other acquisitions, rather than showing them in the order KoL showed them. I did not like the fact that when you obtained a beehive, it would say "You gain an item: beehive" followed by 5 or so "You lose 3 HP". I wanted it to log like fights log: each action/acquistion/familiar action, whatever is logged in the order it happens.

I'll put that code back and we can ponder further.

Note that it works only for things that have "rel" strings. That is probably most places, these days; the "rel" string is the mechanism that KoL uses to tag items that appear in your inventory with the attributes that the right-click popup needs to let you "eat" or "pulverize" or whatever the item. Obviously, that doesn't happen during combat (when you pickpocket, for example), and there are some places where items move in to inventory without a "You acquire an item" messages - "xxx moved from closet to inventory", for example. KoL doesn't give you rel strings there.

I'll put back the code to process items from their rel strings and we can consider later what we can do to use rel string information in the course of the normal result processing loop, perhaps.
 

Darzil

Developer
Thanks. I agree on the ordering, but looked a can of worms, as the information we needed was largely stripped out by the parsing process by that stage. Though it did look like we might be able to pull the full string and scan it for rel strings matching the acquired item. Didn't seem elegant though, as it involves processing the same data so many times.
 

Veracity

Developer
Staff member
Yeah. Rather than processing the item, we could append to a queue of AdventureResult objects, with item # and count - and leave the text in the buffer - and later when processing the results, when we see a "You gain an item", we can pop off the first element of the queue and use that, rather than trying to parse the name. I don't think that's especially "elegant", but it preserves the order and doesn't seem to add that much extra processing.
 

Darzil

Developer
Sounds reasonable, I would be tempted to check the AdventureResults objects for matches with the acquire string, and if there isn't one, use a new AdventureResult built from the name. Just to handle situations where KoL doesn't give consistent html, so we at least do best efforts to match. I'm pretty sure that quite a lot of the Spelunky stuff was like that, as it wasn't parsed as a new item and I had to add it manually.
 

Veracity

Developer
Staff member
That sounds good. Use the saved AdventureResult if it looks like a match and otherwise roll your own.
The Spelunky stuff probably did not have a rel string.

I have only a single factoid for YoMama, so I will certainly be back in Spelunky, but probably not until I'm done with Ed - if that soon. I'll get a log and look at the funky HTML, eventually.
 

Veracity

Developer
Staff member
Darzil did the vast amount of the work to fix this. I'd mark it fixed - except there's a comment about Spelunky items in there. I did get my YoMama factoids but completely forgot to get debug logs. Well, I have one more ghost factoid to get, so I'll try to remember this time.
 

Veracity

Developer
Staff member
I finally went for my last ghost factoid. Boy, I sure forgot a lot about Spelunking! But, I got the factoid, and I saved a DEBUG log for the entire game - 4.8 MB.

When I ended the game, I was left with a boomerang in inventory.

Hopefully, the DEBUG log will let me figure out how that happened. And then, some months from now when I try Spelunking again, perhaps I will be able to test a fix. :)
 

Veracity

Developer
Staff member
Well, the thing about Spelunky is that when you find a bomb or a rope after the battle, there is no "You acquire" text. As it turns out, we never add bombs or ropes to inventory, although we do track them and detect your current stock of them from the charpane.

However, there was an issue with getting items that are "(automatically equipped)" - whether you grab them from a Tikiman, buy them in a shop, find them from another noncombat, or find them after battle (rocks, crumbling skulls). All of those do come accompanied by a "You acquire an item" message.

Revision 15888 should take care of all of those situations and will log in the gCLI and session log as "You acquire and equip an item:". It should keep inventory and your equipment accurate.

The result of this is that I don't seem to end up with a phantom boomerang in inventory when I close the book on the Spelunky minigame.

I think that finishes this bug report. The question of whether you should have bombs and ropes in inventory is a different question which I will bring up in the other open Spelunky thread I am working on.
 
Top