Bug Shocking Lick preference doesn't change

[Cheeseypickle]

I was running garbo today, when I noticed that the preference shockingLickCharges doesn't change, even though I used the skill. I copied the relevant part from the log here:

[191] Thugnderdome
Preference lastEncounter changed from Adjust your Parka to Gnomester Blomester
Encounter: Gnomester Blomester
Preference _lastCombatStarted changed from 20230530222000 to 20230530222004
Round 0: CheeseyPickle wins initiative!
Preference cosmicBowlingBallReturnCombats changed from 11 to 10
Round 0: CheeseyPickle casts SHOCKING LICK!
Round 1: Your toy train moves ahead to the Coal Hopper. Your train takes on coal to power the next stop.
Preference trainsetPosition changed from 91 to 92
Round 1: Aesh tosses you some sleazy nuggets. You respond with some sleazy nuggets of wisdom, most of which involve the judicious use of prophylactics while making spreadsheets.
You acquire an item: sleaze nuggets
Round 1: CheeseyPickle wins the fight!
After Battle: Aesh surveys the scene from atop the throne, and gains 1 Experience.
After Battle: Black Magic does the nanobot. Which is a dance like the robot, but smaller and harder to see.
You acquire an item: cog
You acquire an item: spring
You acquire an item: flange
After Battle: Black Magic wobbles a little bit and then ejects a little bolus of mass, which spontaneously reassembles itself into a bottle of booze.
You acquire an item: bottle of gin
After Battle: You gain 6 Strengthliness
After Battle: You gain 14 Wizardliness
After Battle: You gain 7 Roguishness
After Battle: You gain 1 Strengthliness
Preference _juneCleaverFightsLeft changed from 5 to 4
Preference _juneCleaverCold changed from 4 to 5
Preference sweat changed from 32 to 35
Preference lastCopyableMonster changed from Knob Goblin Embezzler to Gnomester Blomester
This combat did not cost a turn
Preference familiarSweat changed from 150 to 151

This is the 2nd time this has happened. The above log was specifically taken from version r27380. Any chance I could get some insight on this?

 

[fronobulax]

The code decrements it when Shocking Lick is used but never sets it to anything less than zero. It increments it when a battery is used and the default is zero.

It feels likes something is missing or out of synch with KoL. Maybe display the value after you've charged? If that doesn't change then we know what a problem is.

 

[Cheeseypickle]

Well, looking through the logs, the last time shockingLickCharges was changed was here:

use 1 battery (lantern)
You acquire an effect: Lantern-Charged (30)
You gain 70 Mana Points
Preference shockingLickCharges changed from 0 to 1

After garbo broke, I checked the preference and it was still set to 1. I manually set it to 0 afterward.
If it helps, this is definitely the only time I used a large battery that day, and I didn't ascend in-between or anything.

 

[fronobulax]

Well, looking through the logs, the last time shockingLickCharges was changed was here:

After garbo broke, I checked the preference and it was still set to 1. I manually set it to 0 afterward.
If it helps, this is definitely the only time I used a large battery that day, and I didn't ascend in-between or anything.

This sounds like operator error, not mafia error.

You used the battery and it incremented.

You, for whatever reason, set it to zero manually. That forced the preference to be out of synch with KoL. Mafia does not allow or prevent casting because of the preference but KoL clearly allowed you to cast it. Mafia presumably tried to decrement the preference but since it was already at zero the preference remained unchanged.

So I am thinking that the only error was in manually setting the preference when garbo failed.

I'm open to other interpretations but I think everything is behaving as designed.

 

[Rinn]

I think he's saying when it was 1 it didn't decrement on skill usage, and he set it to 0 to prevent the script from further trying to cast another shocking lick when it didn't have a charge.

 

[fronobulax]

I think he's saying when it was 1 it didn't decrement on skill usage, and he set it to 0 to prevent the script from further trying to cast another shocking lick when it didn't have a charge.

Except mafia does not, AFAIK, us the preference to determine whether the skill is castable. It just decrements the preference, bounded below at zero when it notices a cast.

Using the skill when the preference is already set to zero will not appear as a changed preference.

After garbo broke, I checked the preference and it was still set to 1. I manually set it to 0 afterward.

So was the skill actually cast prior to garbo breaking?

 

[Rinn]

garbo checks that preference to determine if it wants to use shocking lick as a free kill source, so if it wasn't decremented to 0 it will try and use it again and fail

 

[fronobulax]

garbo checks that preference to determine if it wants to use shocking lick as a free kill source, so if it wasn't decremented to 0 it will try and use it again and fail

I am probably missing something but I can't find any place where mafia prevents a cast based upon the preference.

So

Round 0: CheeseyPickle casts SHOCKING LICK!

has nothing to to do with what mafia thinks the preference is.

So garbo checks the preference, tries to cast, succeeds and the preference is 0 afterwards.

I admit to beingconfused but I am not sure I know how to reproduce this without a user explicitly mangling a preference and thus making it out of synch.

 

[Rinn]

The combat log in the first post looks to be where there was a shocking lick charge and it was a successful free kill but the pref didn't decrement. They didn't provide the log for the subsequent attempt where the cast failed when the pref was out of sync with kol, I'm assuming this here since the combat didn't take a turn and shocking lick was the last skill used.

garbo won't attempt to submit a macro that uses any free kill skills including shocking lick if the preferences denote that the skill would be unavailable (I wrote this code). It also doesn't use batteries to get charges because they're too expensive, it only tries to use up any existing charges before the script runs if you're planning on ascending so they're not wasted.

If my assumption is correct there could be an issue with the combat parsing on a successful usage of shocking lick. We'd need a debug log to figure out what is going on.

 

[fronobulax]

The combat log in the first post looks to be where there was a shocking lick charge and it was a successful free kill but the pref didn't decrement.

OK. With the data at hand we do not know whether the situation requiring the preference to be decremented was not recognized or whether the preference was out of synch and thus it was decremented but not allowed to go negative.

There was nothing obviously wrong with the code so maybe this is the first or second stage of debugging.

 

[phreddrickk]

One slightly odd thing I notice is that despite only having one success message, we check two different strings to see if the responseText contains them. This was not in Gausie's very first PR for power plant, and git blame isn't giving me anything useful right now.

      case SkillPool.SHOCKING_LICK:
        if (responseText.contains("give your foe a big slobbery lick")
            || responseText.contains("worth of electricity from your tongue")
            || skillSuccess) {
          Preferences.decrement("shockingLickCharges");
        }
        break;

Obviously this should make the code more resilient, rather than less, but figuring out whatever prompted that addition may help in identifying what's causing this failure.

 

[Magus_Prime]

Thanks @fronobulax that made me smile. I prefer the six stages of debugging:

1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?