Bug - Fixed Irregularly unable to 'create' Boris's key from coinmaster

Theraze

Theraze

Active member
Usually, mafia is able to get keys automatically when I have the fat loot tokens. Sometimes, it fails like this:
> create boris's key

Verifying ingredients for Boris's key (1)...
Purchasing Boris's key (1 @ 1 fat loot token)...
Visiting the Vending Machine...
Vending Machine successfully looted!
Creation failed, no results detected.

> debugcreate boris's key

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(1) => 3

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(3) => 3

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(4) => 3
Click to expand...
I do have it set to use coinmasters...
> pref withcoin

autoSatisfyWithCoinmasters (global, now 'true', default false)
Click to expand...
My usual solution when this happens is just to go to the relay browser, buy my 3 keys, and move on, but this is probably indicative of something else being odd. I've also attached a debug log created by turning on debug, running create boris's key, and turning off debug. I'm using (as the debug log shows) mafia version 9909. Fully restarting mafia did fix the issue and bought/created my 3 keys, but this might be like the vacations caching the wrong user or something similar...
 

Attachments

It's probably because I took out the forced refresh on item creation commands.

I'm going to continue avoiding it for now and instead only add in any items that appear to influence item creation. Let me know if you still see any problems with 9910?
 
Okay. As I mentioned, this has been happening irregularly (maybe when two characters go through the entryway on the same launch of mafia?) since the coinmaster refactoring... it's not new to the concoction refresh changes of ~20 revisions back.
 
Your log shows that you asked to trade in a token, but the request did not have a password hash. The form on the Vending Machine page indicates that a password hash is required. Your log says that KoL gave a result of "You don't have that key." for some reason. MY test also did not have a password hash, but worked. Something is funky, but perhaps it would work more reliably if we included the hash, as the form requires.

Right off hand, I don't see why GenericRequest did not put in the hash. Perhaps it has something to do with the base URL for VendingMachineRequest being "da.php?place=vendo" - i.e., it includes a field.

I submitted 9911 which will force a password hash, but I wish I understood why that wasn't happening automatically. I just don't have time to investigate more right now.
 
Still failed in the same way. Not sure what we'd need to do to get more proper information... same circumstances. Bought a key first, logged off, logged onto another character, couldn't buy more keys.
 
Daily Vending Machine problem with multiple characters

I had a similar problem that Veracity worked on earlier (I can try to find the old bug report if you'd prefer), but it's happening again:
> debugcreate boris key

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(1) => 3

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(3) => 3

- Boris's key limited to 3 by fat loot token
Boris's key.canMake(4) => 3

> create boris key

Verifying ingredients for Boris's key (1)...
Purchasing Boris's key (1 @ 1 fat loot token)...
Visiting the Vending Machine...
Vending Machine successfully looted!
Creation failed, no results detected.
Click to expand...
This is the third character going through the entryway today, and both the second and third characters have had this problem. As Veracity pointed out in the other thread, the workaround is quitting mafia completely, but still, this isn't the way it's supposed to work. I ran a debug log on that failed create, and have attached it.

Edit: Apologies, the bug was still open. Here's its thread:
http://kolmafia.us/showthread.php?8092-Irregularly-unable-to-create-Boris-s-key-from-coinmaster
 

Attachments

Thanks for the merge. :)

Just a bit of clarification. In the actual request, it does appear to be sending the pwd block, but it's not creating/buying the key. On both the second and third character, I purchased all 3 keys from the relay browser, so none of my loot tokens had been used. If a visible viewing of
da.php?place=vendo&action=vendo&whichitem=282&pwd
Click to expand...
might help, I can try that next time I'm in this circumstance. Might even happen again today, depends how lucky I am. :)

Edit: Doubtful. Looks like this one is just starting the war, and guessing it won't go as well as I hope.
 
Last edited:
Just wanted to note that this still happens every time I have multiple characters on the same login session try to buy items from the Vending Machine.
 
Seems like some sort of mutability issue for the hashField in PurchaseRequest.java

My testing shows that once the hashField is set in a KoLmafia instance, it won't change even if you login to a different character, but it's only affecting the coinmaster.

Theraze, you'll probably notice that this doesn't occur if you purchase through the coin master in the GUI, but does occur if you type acquire in the CLI.

I'm trying to get to the bottom of it. If you absolutely need to use the CLI in the meantime, ash buy($coinmaster[Vending Machine], 1, $item[Boris's Key]) should work.
 
Actually, I generally notice it when running the NS entryway command, and it's trying to auto-buy/create the missing keys... but yes, SorceressLairManager does, well:
Code: 
			if ( !InventoryManager.retrieveItem( SorceressLairManager.BORIS ) )
and the like. So I'll try using the GUI next time to manually create instead of the relay browser. Might be a while again, just noticed it on some other coinmaster in the last few weeks and thought I should note it's still a live issue. Wish I could remember which one was also having the issue so other people could test it more easily.
 
Theraze said:
Wish I could remember which one was also having the issue so other people could test it more easily.
Click to expand...

I tried at the BHH yesterday when I was testing and couldn't get it to bug. I could definitely bug the Vending Machine, but I can only buy one item per day as I haven't stocked up on tokens.
 
Okay I did some more testing, what I believe is happening is that the VendingMachineRequest isn't being destroyed when you log out. When addFormField() gets called, the pwd field is being thrown out because allowDuplicates is false by default, so it's just using the old value for pwd set in an earlier session.

Patching around the issue is fairly easy, but figuring out why it's happening in the first place is proving to be pretty difficult, I'm not hugely familiar with the request package in KoLmafia. It's not a good idea to simply patch around this, because it could lead to excess memory usage by not destroying the VendingMachineRequest. I wonder if this is happening anywhere else.

Anyway, I'm still looking into it. Anyone else can feel free to pipe in if I'm on the wrong track.

Edit: Still no joy, I've ran out of tokens again.
 
Last edited:
Is anyone able to tell me what this is actually supposed to achieve?

PHP: 
	public void reconstructFields()
	{
	}

I can see veracity added it in r9278 but I don't know how it actually achieves anything.

Edit: Looks like when this function is defined it does nothing, but some classes override the function to actually do something.

Another mention of reconstructing fields appears in r8536, which may shed some light on the problem.

It's worth noting that the fix in r9911 doesn't actually do anything, because the pwd field is already present, it's just the wrong one (and KoLmafia strips out the newly added field because it removes duplicate fields).

Based on the notes from r8536, I theorize that the request is being cached (including the pwd field) from an earlier session. ash retrieve_item( 1, $item[potato sprout]) also produces this bug, as retrieve_item uses VendingMachineRequest too.
 
Last edited:
Well, here's the fix.

The problem was effectively already detailed in r8536, it just also happened to apply to the vending machine too.

Why this only seems to affect the vending machine and not the BHH or Tr4pz0r is a mystery to me.
 

Attachments

Thanks for hashing this out. Hoping that, post world event, I'll be able to validate this as working...
 
Just a note... this bug also applies to the BURT coinmaster.
> inv burt

BURT (6)

> create key tron

Verifying ingredients for key-o-tron (1)...
Purchasing key-o-tron (1 @ 5 BURTs)...
Visiting the Bugbear Token...
Creation failed, no results detected.

> use key tron

Verifying ingredients for key-o-tron (1)...
You need 4 more BURT to continue.

You acquire an item: key-o-tron
Click to expand...
You can see me successfully buying the key-o-tron in the relay browser after mafia failed to purchase it successfully. Hopefully this patch can get tested by someone with commit rights soonish, and also fixes these other coinmasters as well. :) I'll apply it to my personal copy now...

Edit: Added Catch-22's Vend override to BURTrequest as well. We'll see if that fixes it... :)
 
Last edited:
Theraze said:
Just a note... this bug also applies to the BURT coinmaster.
Click to expand...

Hmm, well this patch applies the fix to all coinmasters, in case there are others. I verified it doesn't affect the BHH/Tr4pz0r, but patching those should cause no harm. It might affect future coin masters too, so yeah, probably a good idea to patch this at the CoinMasterRequest level.
 

Attachments

Thanks. I expect to be able to test this today... have 3 characters left who need their key-o-trons and all ascended yesterday, so they should be getting their bits today. Unless mafia gets its lovely no-auto-refresh bug twice, but... Wish I could replicate that somehow. Oh well. :)
 
You must log in or register to reply here.
Back
Top