SOTM Selection Issues
Posted 1 week and 2 hours agoWe heard your feedback regarding SOTM picking the same users over and over again. You all were right to suspect that there was an issue, because there was.
That issue stemmed from a server SQL version update at some point (likely over two years ago) which changed the way the "Last SOTM" date was stored for users who had never been SOTM in the database. There are several pieces of logic used to check who is eligible, but one of them was effectively "the year of the user's 'Last SOTM' date must NOT be equal to the current year."
This statement in the code would look towards the database and see that many users had "NULL" (nothing) stored for their Last SOTM date. Early in the code's creation, "NULL" was assumed to be the same as "00/00/0000" for comparison purposes, which meant that the code would effectively say "0000" (the year of the NULL date) "is not equal to 2025." This meant that users who had never had SOTM were eligible for SOTM, which was correct.
However, after the SQL version update, the statement in the code looked at the database and began to interpret the "NULL" values as "[the concept of nothingness]" instead of a set of zeros. Because of this, instead of asking "is 0000 = 2025" it began to ask; "is [the concept of nothingness] = 2025" and the answer to that question (for a computer) is "I don't know." Since this comparison couldn't be made successfully by the program, it excluded users who had never had SOTM instead of including them.
This meant that from the time the change was made, only users who had already had SOTM but had not had SOTM in the last year were eligible. This has now been corrected, once again allowing users who have never had SOTM to be eligible.
There are a few things it is important to clarify:
- Staff had NO say in the original selection of users who had been SOTM prior to the SQL update. Even before the implementation of the coded logic, characters were always randomly rolled.
- There was NO visual indication of this issue in the database. Both before and after the update, the way all of the data was displayed was exactly the same. No errors were being generated in any error logs.
- The issue with the code was not that computers "heavily favor certain numbers or patterns." It is true that computers cannot truly generate random numbers. However, this fact has a negligible impact on the vast majority of coded applications, including ours. In the original code, the largest issue with repeat selection was simply that we were choosing from a pool of characters instead of a pool of users. This meant that, much like any lottery, users with a large number of characters were much more likely to be selected vs users with only a single character. We have always been very transparent about this and this was originally by design, as the system was meant to highlight characters, not users.
- We will never limit SOTM to only characters with gift art turned on. The point of SOTM is to feature characters. It is not to feature users or to allow users to farm bi. We choose to offer an incentive to users doing gift art of SOTM characters as a kindness to all users, but it is not a requirement of SOTM characters (or any characters) to allow gift art.
All of that being said, we recognize that this system has caused confusion over the past few years and we take responsibility for the selection system malfunctioning. In response to this issue, we have done several things. To start, staff have chosen to opt out of SOTM in order to give other members a better chance of being chosen. Staff will be excluded from SOTM selection until September 1st, 2028.
We have also completely overhauled the way SOTM works. The new logic works like this:
- A list of eligible characters is created, defined by the following criterieon:
- The character is not an MYO slot (meaning it does NOT appear on the MYO masterlist: this does NOT exclude code MYO characters, it just excludes slots)
- The character has at least one image (art)
- The character is of the Shiji-Long species
- The character is either NOT code BBY or if it is code BBY, it has received at least one approved design update
- From the list of eligible characters, a list of users owning at least one of the characters is created.
- The list of owners is then further slimmed down to determine eligible users. Eligibility for users is determined with these criterieon:
- The user has NEVER had SOTM or the year of the user's last SOTM is not the same as the current year
- The user is not the site admin (shijilongadmin)
- The user is not banned
- The user has logged into the website in the last 12 calendar months
- The user is not a current staff member and the current date is before 2028-09-01
- The user has one or more eligible characters
- Based on the eligible users list, a user is randomly selected.
- Based on the user's eligible characters list, a character is randomly selected.
- After the eligible user/character pairing is selected and their "Last SOTM" date is updated, then the above logic is run again to select a second user/character pairing (which will exclude the first user/character pairing selected for that month).
These changes will result in a more fair/more balanced selection system which does not prioritize any specific subset of users, including those who have many characters. It is important to understand that this new system does not exclude those who have had SOTM prior to 2025. Meaning that users who were in the accidental multi-year pool are not being excluded and are still eligible to be selected going forward, as long as they have not had SOTM this year.