Ticket Raffle Announcements Not Triggering (and command issues)


#1

I currently have a ticket raffle running, and noticed that the automatic announcements are not firing.

I had them set to once every 30 minutes, and after a few hours noticed nothing is being announced, so I set the interval to 1 minute and have still not seen anything.

Debeug steps:
!traffle autoannouncemessage test
!traffle autoannounceinterval 1

Also tried !traffle autoannounceinterval 5 in the event 1 was too low.

I also tried entering random text into the chat, in case this announcement shared the same chat message count requirements as the normal automated announcements.

On a related note:

There are some inconsistencies between command syntax/structures for regular raffles and ticket raffles that make setting them up using commands (rather than the web panel) confusing.

As listed on commands page:

!raffle message
!traffle autoannouncemessage

!raffle messagetimer [minutes]
!traffle autoannounceinterval (missing [minutes] )

For “raffle” the command “message” seems to apply to the automated announcement message, but under “traffle” the command “message” seems to be related to an entry message, and the sub-command “autoannouncemessage” is used. (same term, 2 different implementations) My moderators got quite frustrated with this one so I actually had to stop activity on stream to set this up myself. (only to then discover that auto announcements are not working)

Having the same functionality using different syntax between such similar commands (“raffle” and “traffle”) makes memorizing commands difficult/impossible. This is something I’ve touched on before with other commands, where there did not seem to be standardization of terminology, which I’m guessing is a symptom of multiple developers splitting up and tackling different aspects of the bot. Totally understandable, and super common, but should be addressed as a priority.

The syntax used on the commands page seems to be !command sub-command or !command [option] where a user-defined parameter (message, numerical value, username, etc) is represented with brackets.

If you filter the commands list by “traffle” you will notice many of the commands there have their sub-command (not a user-defined parameter) in brackets.

!traffle [close]
!traffle [repick]
!traffle [messagetoggle]

While this is not a serious issue, it does cause a bit of confusion. Might be nice to add a housekeeping task to clean up the commands list, and also use that opportunity to re-define some commands that perform similar tasks to use standardized syntax. IE: autoannouncemessage in !traffle vs. message in !raffle

I totally understand the inconsistency in the command structures/syntax/etc. as I see this type of issue arise all the time when working with teams of multiple developers, especially with teams that don’t have the luxury of project managers helping keep everyone on the same page. Here it’s just highlighted since those commands are the primary interface to this product, especially for moderators, and this inconsistency makes memorization and efficient use of the commands difficult/impossible. This makes relying on the commands list on the website a requirement rather than an option. Not the end of the world, but an unnecessary complication.

While cleanup/maintenance tasks like this are not as satisfying as stomping out bugs, it’s important that these issues get cleaned up since these commands are the moderators only interface with the bot. To that point, have you thought about adding the ability to add moderator user accounts to the web panel? Since these commands are inconsistent and confusing for my moderators it would be nice if I could give limited web panel access to the moderators so they don’t have to rely on commands alone.

Again, totally love, respect, and support everything the team here is doing! Especially given that this is all done on a volunteer basis!

/Chris


#2

Are there any errors in your logs? while I haven’t ran a raffle in awhile, the last time I did the messages were working.

If you could also fill out the following it would help us help you:

PhantomBot Version:
OS Version:
Java Version:
Browser and Version (for Panel Support):
Stock PhantomBot: Yes/No (Yes if you have not modified the scripts or Java Core)


#3

OSX 10.12.6
PhantomBot Version: 2.3.9 (Revision: 37009b50)
Don’t have access to the Java version on that system, but I do know it was updated in the last week.
Chrome: Version 62.0.3202.94 (Official Build) (64-bit)
Bot is stock.

I think I have figured out the issue with automatic messages. When I started the first raffle the message timer was set to 0. I then updated the timer to different values to debug, and never saw automatic messages being set.

Last night, after a system reboot prematurely aborted our previous raffle, I had the opportunity to start and stop a few test raffles and noticed something interesting.

I started a new raffle with the message timer set to 1 minute. In this case I set the “message time” value before I hit the “open raffle” button. And I noticed that every minute the automatic message was echoing out as expected.

I then updated the message timer to 5 minutes, and noticed that it was still triggering every 1 minute.

It seems that the message timer value is only read when the raffle starts, and subsequent updates to that value do not update or reset the timer.

I’ve since opened up a new raffle with the message timer set to 30 minutes, and everything is working fine (aside from not being able to change the message frequency)

Would it be possible to have these types of automated messages inherit the “required messages” setting from the “notices” module, or have its own “required messages” setting? That would be amazing, since the bot would not unnecessarily spam the chat when its previous automated message is still visible and there has been little to no chat activity.

Thanks again as always!

/Chris


#4

It’s possible that this is just a fault of the timer functionality.

I’m looking at the code now and yes, if you set it to 0, no message would send.

    if (messageInterval != 0) {
        interval = setInterval(function() {
            $.say(raffleMessage.replace('(entries)', String(totalEntries)));//can't use regex here. why? who knows.
        }, messageInterval * 6e4);
    }

As you can see it’s checking if messageInterval is NOT 1. While I personally think checking if it was positive (messageInterval > 0) would be better, that not the issue at hand.

The timer is only initialized one time, and it runs off messageInterval * 6e4 (Or messageInterval * 60000). Even if the variable messageInterval does change, the timer has already been initialized.

So, basically, what need to happen is the timer would need to be changed to run every 1 minute regardless of the users setting (Unless they set it to 0 or below), and then use another variable to determine the last time a message was sent and if it was longer than the user’s timer, then it sends.

I believe there’s systems like this already in the bot, so it’s possible.

But yeah…

TL;DR: The timer is only initialized once if the interval is NOT 0. changes to the interval won’t affect it unless it’s restarted (as you’ve figured out). Solution is to rewrite that portion of code.


#5

This is not so much of an issue once users know that the timer needs to be defined before a raffle starts. But once that raffle does start you are committed to what ever time you started with, which might be handy to change depending on raffle participation over time.

Mine is firing ever 30 minutes now, which seems good to drum up participation. My only concern (as mentioned at the tail of my last post) is that it does not leverage the “required messages” value for normal notices, or have its own, so regardless of chat activity it’ll keep spamming out the message.

Thanks for checking on this one!

/Chris


#6

I believe that’s intentional and getting it changed would be (as you guessed) a feature request or modification on your own.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.