Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fighters with "&" in name render SaltBot unable to record data or bet #477

Open
NocturnesGM opened this issue Dec 28, 2021 · 3 comments
Open

Comments

@NocturnesGM
Copy link

This is a constant, always replicable on my end, issue the bot has had for as long as I've used it, older versions and current.

If a fighter has the "&" symbol in their name, the bot will make the bet using whatever data it has on the fighters, and then cease to function until both the chat tab and Salty Bet site tab have been refreshed.

This refresh can be done manually, or be triggered by the auto-refresh the tabs do to themselves after about 100 matches (purely a personal estimate).

This means that the results of the bet are never logged, and furthermore it appears as though the bot proceeds to just log the unresolved bet as a null-win, resulting in characters with "&" in their name effectively being read as characters who have never won any of their most recent 15 matches, and only ever lost.

I seem to remember that this used to happen with other non-alphanumeric symbols in fighter names as well (such as "." and "_" ) but as of late I've personally only ever observed and verified it happen with "&" in the fighter name.

Two photo examples, taken within minutes of each other during a tournament in which a fighter fitting the criteria for this issue won their match, are supplied here at https://imgur.com/a/T2Soi5A to show what might be seen in the F12 console.

  • As noted in the captions, I do have completely unrelated U tier match data as a result of having used an old version of Saltbot up until recently. This is not part of the issue, as simply updating the bot and everything needed to run it has mostly fixed the tier data records (which of course has thrown off my chromosome's betting a bit as it's now suddenly having to weigh bets with actual tier data, but that's completely expected).
  • Every once in a while the bot will still log a match tier as U, and/or the match odds as U, or simply copy the odds from the previous match, but these are completely separate, seemingly randomly occurring, issues that aren't enough to break the bot's betting, unlike this "&" in the name issue.
@NocturnesGM
Copy link
Author

Appending an update/another example encountered earlier:

This time, a fighter with a comma "," in their name broke the bot for several minutes, the bot listed the comma as an underscore "_" in the F12 console, and after missing several matches finally determined something went wrong.

Photo examples supplied here at https://imgur.com/a/AtQnVYl will show what the F12 console translated as the fighter name vs. the actual name displayed in Twitch chat for that match.

  • Like last time, we can see that the bot has never logged any of the fighter's match data as Wins (again ignoring the irrelevant Tier U data).
  • Unlike last time, the symbol in question was not properly displayed in the F12 console, instead changing from a comma to an underscore.

@zappybiby
Copy link

zappybiby commented Jan 11, 2022

First, the reason you are seeing an underscore instead of a comma is because of this code here:
This function appears to take all commas in character names and make them underscores.

saltbot stores 12 variables for every match in matchrecords in a specific format: Character1, Character2, Winner [0 or 1], etc
Example: Golgo13,Lazy garfield,1,cs,t,U,e,U,0,2,2,01-01-2020
It expects exactly 12 variables for each record that are delimited by commas. So if there are additional commas in the character name, it may be parsed wrong or raise exception.

I reviewed the records of several characters containing the character & and can confirm that any character with that symbol will always be recorded as having lost the match. However, other symbols/special characters, such as character names containing period,, do not appear to be causing the same issue. I am unsure about the case involving the comma/underscore as of writing this. In prior records, it appears that characters with underscores are correctly assigned the winner state. This is in contrast to all characters with ampersand, which always shows them as having lost the match regardless of actual result.

Disclaimer: I am unfamiliar with JS/TS, don't know what JQuery is, etc.
So as to why this may be happening. The behavior you noticed, where saltbot doesn't work until refresh if a character has the '&' symbol, occurs when saltbot cannot find a valid winner for the match. It will reload after x number of failed attempts. It is also worth noting it reloads every hour as a routine procedure. Relevant code

The & might be causing issues with Jquery function or interaction in how HTML is entered.
I am unsure why the underscore may be causing problems,

I will gather some data on this. Regardless, we will eventually need to sanitize character names going forward to prevent any related issues from occurring. I'm still understanding how names are processed, as there are several different methods it uses to pull character names or reference them.

@NocturnesGM
Copy link
Author

That all makes sense to me, even as a mere user who can only report what he sees. Great info.

For clarity for other folks, like I alluded to further up, I can confirm that all other characters inside fighter names besides & and , have been just fine as far as I've seen and not rendered the current version of the bot unable to find a valid winner, and that includes fighters with actual underscores _ in their names.

Knowing what was just explained by zappybiby, this leads me to suspect that since the bot is translating commas into underscores and it's of course logging those fighter records using underscores in their names as well... There was some sort of snag when the RESULTS of that example match I provided were reported in Twitch chat. Perhaps the bot failed/fails to translate commas in the process of reading Match Result data or something.

Truth be told I thought I remembered fighters with , in their name working fine, but maybe I wasn't paying as close attention the last couple years as I am now. I'd need to see/know other examples of fighters with commas in their names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants