Settings Save Failure

[synkarius]

There is something wrong with chrome storage, settings aren't getting saved correctly.

[ghost]

Try using the updated saver script, it might fix it.

[synkarius]

@reconman The bug you described here only happens for me sporadically, so it's difficult for me to fix. Is there any way that you know of to get it to happen regularly?

[reconman]

After the script update I can't reproduce it anymore. Normally it occured on any reload.

BTW, would it be possible to make the saltbot bet on bets which are already open when the site reloaded? Say for example round 25 is over and the site reloads. Saltbot doesn't bet on round 26 but will begin again on round 27.

P.S. there's still an open push request from me. Sorry for wrongly remembering the bailouts.

[synkarius]

I'm glad you're no longer getting the glitch, but I wish we'd been able to pin it down. Happy sad.

Yes, it's possible to make the bot bet on that last 4% of matches. The reason it doesn't do so now is because on refreshes, it loses information about the current match. So, to make it not bet blindly, I made it not bet at all. It wouldn't be terribly difficult to save that information in Chrome local storage before the refresh, and to retrieve it immediately after. That said, Waifu's timing isn't always perfect, so there would probably still be cases where SaltBot would have to abstain from betting.

I somehow missed your push request. I'll do that update now.

[reconman]

But strangely enough if you quickly click on "Scientist" while the site is reloading it will calculate odds and bet for you. You can test it with manual refreshes.

[synkarius]

Hahaha, that's not supposed to happen! You must be forcing it to bet without tier information. Not that tier really matters anyway. Win rate dominates all.

[reconman]

Can you tell me how tier is incorporated into the calculations? Does it use different percentages?

Tiers aren't saved in the history, are they? It's a problem when characters are promoted or demoted and start with 80 % on the higher gear. But I can live with that.

[synkarius]

Character wins and losses are saved by tier. Wins in a higher tier are worth more "points". So let's say we have two characters:

Sonic:: SSSS : XXXXS
Knuckles:: AAAAAAAAAA : SS

Sonic got demoted from X and then started winning. Knuckles got promoted to S and then started losing. The bot would probably choose Sonic here because S wins are worth more than A wins. What's problematic for SaltBot (and for any stat collector) is Illuminati character buffs.

[reconman]

Oooooh, that's the letters. I only made the connection after you pointed it out...

[synkarius]

I guess that doesn't address why the bot doesn't bet on the first match after refresh though. Come to think of it, I'm not sure why it shouldn't. I guess the only thing the refresh prevents is saving data on the first match.

[synkarius]

https://github.com/synkarius/saltbot/issues/38

I'll see if I can get to that this weekend.

[reconman]

I just looked for a part in your scripts where you used calculations to consider

Sonic:: SSSS : XXXXS Knuckles:: AAAAAAAAAA : SS

but all I can find are some static unused assignments

this.wX = 5; this.wS = 4; this.wA = 3; this.wB = 2; this.wP = 1; this.wU = 0.5;

This fight here was calculated incorrectly

Sasuke uchiha has a better W score (scores: 6.14:0.00), W:L(P1)(P2)-> (8:0)(3:9), betting Sasuke uchiha,-- r: (BBBBBBBB:)(USS:USSSSSSUS)

I would propose calculating win ratios for each tier and multiplying that with a specified weight. In the genetic algorithms those weights are changed with each generation to reach an optimum.

[synkarius]

I think your proposal is great! That's exactly what happens. Those "static unused assignments" are the values for the first generation. Subsequent generations have mutated values. If you want to see the mutated values, right-click somewhere on the UI, select "inspect element", and while the background console tab is open, click "Update Genetic Weights" and wait a few seconds.

[reconman]

To be sure we're on the same page: All those w and l parts of the chromosomes will be removed since they serve no actual purpose at the moment (they aren't read in any of the scripts) and instead a new weight is introduced for each tier.

[synkarius]

They are read. https://github.com/synkarius/saltbot/blob/master/src/strategy.js#L310 What you're proposing is how Scientist mode already works.

[synkarius]

-- well, now that I think about it, it's how Scientist mode already works unless you're proposing a new set of starting weights for those values. It's possible that my starting weights always cause the algorithm to fall into a local optimum, which is clearly undesirable. If you think that's the case, I'd suggest tinkering with them and seeing if you can make the seed data come out higher than 63% success. (I think I saw it go to 64% once, but my experience has been that the starting weights basically don't matter at all.) If you find a better starting set though, I'm very open to changing them.

[reconman]

I didn't find the part with "w" + cObject,wins[jj], thank you.

My current chromosome configuration is wX : 4.660540471881931 wS : 0.16489588508331604 wA : 9.51021425032576 wB : 4.551393549143319 wP : 2.0770035298213076 wU : 3.506732823109191 lX : 0.07196413574280626 lS : 0.6033314424132535 lA : 21.339678828444857 lB : 1.343111408117305 lP : 0.6852381281471149 lU : 0.10136312306034102

wS : 0.16489588508331604

That doesn't seem really optimized.

Consider this example: AAAA:AAAAAAAAA vs PPPPPPPP:PP = 36(wins)/225(wins+losses) vs 16(wins)/17.5(wins+losses) (roughly rounded)

Now with the initial weights: 4 * 3/13 * 3 vs 8 * 1/(8 * 1+2 * 5) = 4/13 vs 8/18 - the right one still has the higher score

It doesn't make any sense that the algorithm would choose the weights in such a way that a P-tier fighter is better.

Instead something like this should be used: AAAA:AAAAAAAAA vs PPPPPPPP:PP = 4/13 * weightA vs 8/10 * weightP.

Let's say we have the initial weights of weightX = 30 weightS = 20 weightA = 10 weightB = 5 weightP = 1 weightU = 0.5

That would be 4/13 * 10 vs 8/10 * 1 = 3.08 vs 0.8. The A-tier fighter wins. To prevent too great impacts of the values in case of many X- or S-tier fights the calculated value has to be limited, though. Something like dividing the 2 values with a top limit of 5. In this case that would result in a value of about 4. If it's higher than 5 it's just cut off.

It also eliminates the problem of win and loss weights deviating greatly like it's the case with my wA and lA genes.

[reconman]

And another thing of matter for the genetic weights: Exhibitions.

In the least amount of cases people will request normal fights. They are mostly something like 12p Dark Donald (B-Tier) vs. X-tier and Donald will Win because his 12p is extremely overpowered. Or something like Spacemouse Deluxe (S-Tier, attacks mostly with projectiles) vs Nimuge president (B-Tier, immune to projectiles)

Saltbot will record these matches and use them for calculations. I suggest not recording exhibition fight results at all. They just create pollution in the data.

[synkarius]

Team exhibition battles are already skipped, not recorded. Your idea about removing all exhibitions from the records is interesting though. I think it's worth a try. I'll give that a shot this weekend too.

As for your other suggestion, which is essentially removing the genetic algorithm from Scientist mode entirely, I think that's also interesting, but I'm unwilling to change Scientist, for two reasons. The first is that I don't think it would work better. Of course, money talks, and if preset non-changing weights rake in more than the genetic algorithm, I'll be happy to be wrong. The second is that preset non-changing weights are less interesting. Honestly, when I made this bot, I stopped watching the matches and started watching the evolution of the weights. Therefore, I think a new mode is in order. Me aside, you're probably the one that knows the code best. Care to implement it? I'll help if you get stuck. If not, I'll get to it eventually.

[synkarius]

Actually nevermind what I just said about team battles. Team battles are not skipped. I was skipping them at one point, then I realized that records with the word "team" would only come up during exhibition mode.

[reconman]

You misunderstood. My weights should still be genetic.

[synkarius]

I did misunderstand. So, given that after the first generation, we no longer have control of the weights, what are you suggesting is the change? The starting values?

[reconman]

In fact my solution would only mean that the value of wS and lS must always be the same and to use the ratio of the calculated values instead of the values for the score.

[reconman]

So we should combine the 2 paired weights and try my starting values from above (30, 20,...)

[synkarius]

It's late here and I need to get up tomorrow. So here's my answer. Change it so it works that way, but add a gene to the chromosome which can disable your changes and set it back to the default. I tried to optimize it a lot, but always gave the bot a way to disable my optimizations if it could make more money without them. It always shut them off, so I just deleted them. If the optimizations work better after a bunch of runs with 30+ generations, we leave the optimizations in. Sound good?

[synkarius]

Also, we can change the starting values to those you provided. I have no problem with that at all.

[reconman]

Your code works better than mine. 26 generations of your code got to a higher return than my 100 generations. What intrigues me is that the genetic algorithm will change the tierweights so higher tiers become less valueable than lower tiers. My hypothesis is that upsets counter that negative effects and generate a higher return than mostly betting right.

[synkarius]

I suspect that your hypothesis is correct.

[reconman]

Betting mode is changed to Monk after refresh again after today's saltybet update.

If you leave it it will result in an exception.

Error in response to storage.get: TypeError: Cannot read property 'oddsWeight' of null at ConfidenceScore.execute (chrome-extension://bholoegapebhflljekancpcnajigaiih/strategy.js:376:34) at Object.callback (chrome-extension://bholoegapebhflljekancpcnajigaiih/tracker.js:113:34) at Match.init (chrome-extension://bholoegapebhflljekancpcnajigaiih/tracker.js:92:23) at chrome-extension://bholoegapebhflljekancpcnajigaiih/salty.js:256:23

[synkarius]

I'm fairly certain that error was b/c the background tab (which sends Chromosomes to the SaltyBet window) couldn't find the SaltyBet window due to the title change. Your merge request, which I've just pushed to the Chrome Store, should fix that. Let me know if it doesn't.

[reconman]

Seems to be fixed again.