Bug - Fixed is_coinmaster_item no longer returning true for Wrecked Generator

S

Shiverwarp

Member
This is related to the new changes to coinmasters, I'm unsure if the change in functionality is intentional or not, but either way posting here just in case.

This is something that breaks the CONSUME script. It checks for whether an item is a coinmaster item, and then checks for whether we can access that coinmaster, and whether the currency is tradeable.
 
Just adding on further things I'm seeing with coinmasters that I'm unsure are intentional or not.

The nicknames for coinmasters have changed (some have, some haven't)

DinsyStore -> landfillstore
DiscoGiftCo -> infernodisco
BuffJimmy -> sbb_jimmy
speakeasy -> olivers

taco_dan has stayed the same
 
Nickname changes are intentional; almost all of them were the shopId used by KoL, and I changed the ones that weren’t to go with that convention.

It seems like early on, we made some effort to make nicknames user friendly, but later on got lazy and shrugged.

I could restore ones that changed and come up with a different solution for what I was trying to do. I should probably do that. Are the original nicknames important to you?

Regarding the first bug, I’m on it. After coffee. 😀
 
Well, I decided to restore the previous nicknames. Sorry!

I added a shopid field to CoinmasterData and use that instead of nickname for registering shops - and I discovered quite a few errors in shops.php. That was well worth fixing, so, thanks for bringing this to my attention.

And I fixed the bug I introduced into CoinmastersDatabase.contains with validation == false, which is why is_coinmaster_item was broken.

The PR is out for review. Once it is approved and merged, you'll be good to go.
Except for having to change back your nicknames.

Code: 
> ash $coinmaster[The Dinsey Company Store]

Returned: The Dinsey Company Store
token => FunFunds™
item => FunFunds™
property =>
available_tokens => 0
buys => false
sells => true
nickname => DinseyStore
shopid => landfillstore

github.com

Use 'shopId' rather than 'nickname' in coinmasters by Veracity0 · Pull Request #2699 · kolmafia/kolmafia

Add a shopId field to CoinmasterData. Set that for shop.php coinmasters. Use getShopId() rather than getNickname() when checking if the URL pertains to a particular coinmaster. Restore the previou...
github.com github.com
 
Has something changed again? r28334 broke my breakfast script at "create 3 mini kiwi aioli", so I reverted to an older version I knew still worked. Is there a new standard for coinmasters stuff now and I'm just out of the loop on where that info is located?
 
There has been major refactoring going on for weeks.
As of yesterday, it's likely done.

I'll look at the mini kiwi shop.
 
Yeah.

Code: 
> inv mini kiwi

mini kiwi (100)

> create 3 mini kiwi aioli

Verifying ingredients for mini kiwi aioli (3)...
Purchasing mini kiwi aioli (3 @ (5 mini kiwis))...
Visiting Kiwi Kwiki Mart...
Creation failed, no results detected.

Working on it.

OK.

Code: 
> inv mini kiwi

mini kiwi (100)

> create 3 mini kiwi aioli

Verifying ingredients for mini kiwi aioli (3)...
Purchasing mini kiwi aioli (3 @ (5 mini kiwis))...
Visiting the Kiwi Kwiki Mart...
You acquire mini kiwi aioli (3)
Kiwi Kwiki Mart successfully looted!
Successfully created mini kiwi aioli (3)

> inv mini kiwi

mini kiwi (85)
mini kiwi aioli (3)

> create mini kiwi bikini

Verifying ingredients for mini kiwi bikini (1)...
Purchasing mini kiwi bikini (1 @ (2 mini kiwis))...
Visiting the Kiwi Kwiki Mart...
You acquire an item: mini kiwi bikini
Kiwi Kwiki Mart successfully looted!
Successfully created mini kiwi bikini (1)

> inv mini kiwi

mini kiwi (83)
mini kiwi aioli (3)
mini kiwi bikini
 
Yes. r28335 will fix it, once my PR is approved and merged.
Heck, I may do that myself; who needs a code review for a fix this simple? :)

It's in - after code review and followup commits. ;)
 
Last edited:
I'm on 28335 and there seems to be an issue with the Mr Store 2002 credits.
Preference _2002MrStoreCreditsCollected changed from false to true

use 1 2002 Mr. Store Catalog

Trade 1 Mr. Store 2002 Credit for 1 Loathing Idol Microphone
You acquire an item: Loathing Idol Microphone
Preference availableMrStore2002Credits changed from 0 to -1
Click to expand...
After visiting manually:
Visiting Mr. Store 2002
Preference availableMrStore2002Credits changed from -1 to 2
Click to expand...

The day before in my logs it was doing this as well:
Trade 2 Mr. Store 2002 Credits for 2 Spooky VHS Tapes
You acquire Spooky VHS Tape (2)
Preference availableMrStore2002Credits changed from 2 to 0
Preference availableMrStore2002Credits changed from 0 to -2
Preference availableMrStore2002Credits changed from -2 to 0
Click to expand...
 
Veracity said:
What did you do to get that result?
Command, function, GUI, whatever?
Click to expand...
Okay so today:

I ascended, my availableMrStore2002Credits preference did not change (I am unsure if it is meant to or not!). It remained at 0 (I ran garbo earlier in the day, which would have used it I believe if it had been updated, so it also seems to have not updated over rollover)

I ran loopSmol. It has a 2002 task that executes this:

if (!haveLoathingIdolMicrophone()) {
buy($coinmaster`Mr. Store 2002`, 1, $item`Loathing Idol Microphone`);
}
if (get("availableMrStore2002Credits") > 0) {
buy(
$coinmaster`Mr. Store 2002`,
get("availableMrStore2002Credits"),
$item`Spooky VHS Tape`
);
Click to expand...

It purchased the loathing idol microphone which resulted in:
Preference _2002MrStoreCreditsCollected changed from false to true

use 1 2002 Mr. Store Catalog

Trade 1 Mr. Store 2002 Credit for 1 Loathing Idol Microphone
You acquire an item: Loathing Idol Microphone
Preference availableMrStore2002Credits changed from 0 to -1
Click to expand...
The script then aborted (sorry the abort itself does not appear to be in my logs)
 
So it just does a buy without having done anything previously to actually visit the coinmaster and thereby set/verify the property.

I’ll think about this.

Perhaps the solution is to make the default for the _ property be 3, not 0.
 
If I recall correctly, there was some weirdness with 2002 where you had to visit the store to actually collect the credits. I think this was relevant if you were using the in game chat command to purchase things?

My memory about it is hazy, but I recall there being a few changes regarding how collecting the credits worked. It's why the _2002MrStoreCreditsCollected prefence exists alongside availableMrStore2002Credits
 
Yeah, there’s something wrong about that.
If you have to visit to collect credits - once a day - before doing a buy, we should do that.
I’ll look at it tomorrow.
 
I believe this was on 28334:

Trade 14 Embers for 7 throwin' embers
You acquire throwin' ember (7)
Preference availableSeptEmbers changed from 14 to 0
Preference availableSeptEmbers changed from 0 to -14
Preference availableSeptEmbers changed from -14 to 0
Click to expand...
This was from a
JavaScript: 
        buy($coinmaster`Sept-Ember Censer`, toBuy, item);
, where the item was throwin' embers and the toBuy was 14.


Having poked around at the source code, I suspect that the process went something like this:
- CoinMasterRequest.parseBalance is called as part of the transaction. It parses the response text of the purchase, and sets the preference down to 0, seeing that the page lists me as having 0 embers
- CoinMasterRequest.completePurchase decrements the preference by 14, (technically it looks like it does a negative increment?)
- CoinMasterRequest.parseBalance is called a second time.


Looking around, I see that parseBalance is called both by SeptEmberCenserRequest.visitShop and by CoinMasterRequest.parseResponse. It's not clear whether they're each being called once as part of this, or if the latter is being called twice.

Worth noting that the censer uniquely has, as part of breakfast, a visit to the shop.php to set the preference. To my knowledge this is not part of the Mr Store 2002 code. So we still get that bouncing back-and-forth thing, but without the issue of not initializing the value.
 
If I understand correctly, you get 3 MrStore2002 credits every day, but you must visit the item to unlock them.

Therefore, we should have _availableMrStore2002 credits initialized to 3 (to determine if you can spend them) and _2002MrStoreCreditsCollected initialized to false to say whether you can spend them.
The first time you try to spend them, if they’ve not been collected, visit to do so.

I’ll look at the SeptEmber issue, too. I am sure it is something similar.

The difference is, embers carry over rollover. Regardless, we have the infrastructure to handle both cases.
 
You must log in or register to reply here.
Back
Top