Hey guys, wanted to show you my bot.
What it does it allows you to 'subscribe' to players and maps and with a single in-game IRC command to the bot "!update" get an immediate feed on update about them.

Example of usage:

user: !watch hvick225
bot: Watching hvick225
user: !watch Cookiezi
bot: Watching Cookiezi
user: !watch b 252238
bot: Watching Map 252238
user: !update
bot: hvick225 has 11111 pp and 1 rank
bot: cookiezi has +inf pp and 0 rank
bot: Tatsh - IMAGE -MATERIAL- [Scorpior]: Cookiezi S rank 99% achieved on 26-12-2015 nomod
user: !update
bot: hvick225's state hasn't changed
bot: cookiezi has gained 500.03 pp and gain 10 ranks!
bot: Tatsh - IMAGE -MATERIAL- [Scorpior]: new #1 score by Cookiezi +HDHR achieved on 2017-01-01

More info on the github page: https://github.com/firedigger/osuWatcherBot

If you want to use it, just PM me in-game, start with "!help". However, I have to be online. It's currenly is testing mod, I am adding new features and fixing bugs.

I am starving for suggestions, feel free to post here or PM me directly. Cheers!

This is cool, would also be neat if the bot notices if a user connects and updates automatically, but I can see that would be difficult.

Looks like a neat project so far! Are you planning on making it available basically 24/7 in the future, like Ameo and Tillerino do with their bots?

Nyquill wrote:

This is cool, would also be neat if the bot notices if a user connects and updates automatically, but I can see that would be difficult.

Bot with such concept was modeled by theFerdi265, and that project inspired me to make this bot.
But there's an obvious problem with active updating and that's the reason why I decided to go with 'reactive' on-demand updating:
Imagine the real load onto the servers. If 1000 users watch 10 objects each, and bot makes a request every 5 seconds. That's 10k request in worst case. Obviously, the requests could be united. Then at best case (if only top players are monitored) there would be not more than 1000 requests every 5 seconds. But then players may want to monitor their friends, and we can get more than 2k pretty easily. One more problem with the concept is that the monitor has to be stateless => that means that every user would get the same monitor message because of uniting the requests(if we wanted to iterate all the users after a single monitor requests, that would be somewhat optimal but immediate 10k+ user stores).
Anyway, the problem is that updating automatically requires periodic pinging, in my opinion, this is not a good idea.
In my case, every user has its own processor with its own state. This way, the new "!update" command will show exactly difference betweeen NOW and user's personal previous requests.

riffraff11235 wrote:

Looks like a neat project so far! Are you planning on making it available basically 24/7 in the future, like Ameo and Tillerino do with their bots?

In the future I certainly do planning 24/7. To be honest, I can already do that just by launching my node js on a dedicated server (which I have in mind).
Atm though I want to finish the funtionality, find all the bugs (especially ones, that crash my app ), do the performance tests(with more users there will be huge load on osu_api server and the server itself), see if it's OK, maybe optimize the code, formulate constraints which will hold the server working, ensure stability.
Then I'd want to make it Tillerino-esc.

You should really look into redis for "temp" stats (etc) persistency even though the api for node is wonky (wouldn't use node-redis).

Btw, wanna warn you about the node's irc package, it's extremely unstable because of not being maintained and you'll notice it after a while of running that it stops actually getting stuff/crashes and some random code in it causes the events to be sent twice with a small delay between each other.
And the way you've made it if it goes big you're looking at a quite huge memory hog.

Also for requests, use a ratelimiter with a load off and keep a list of whom are connected to the irc to check before the checking of the user if uptime is higher than x.

Also you pushed your api & irc keys.

KayKey wrote:

You should really look into redis for "temp" stats (etc) persistency even though the api for node is wonky (wouldn't use node-redis).

Btw, wanna warn you about the node's irc package, it's extremely unstable because of not being maintained and you'll notice it after a while of running that it stops actually getting stuff/crashes and some random code in it causes the events to be sent twice with a small delay between each other.
And the way you've made it if it goes big you're looking at a quite huge memory hog.

Also for requests, use a ratelimiter with a load off and keep a list of whom are connected to the irc to check before the checking of the user if uptime is higher than x.

Also you pushed your api & irc keys.

1) Yeah, I could actually use a specializied DB for data.

2) Seems like node-irc working fine for now, doesn't seems like 'pm' event is going to ever change.

3) Are you talking about limit on time between "!update"s ? Yeah, I'll make something like that soon. Though it's better to keep the last request time in the watcher I think.
I was thinking on optimizing the memory, I can actually keep only score values for the map maybe. But still, the memory doesn't look scary at all.

4) And yes, I should hide the API and IRC keys in a config.

Thanks for your answer!

firedigger wrote:

KayKey wrote:

You should really look into redis for "temp" stats (etc) persistency even though the api for node is wonky (wouldn't use node-redis).

Btw, wanna warn you about the node's irc package, it's extremely unstable because of not being maintained and you'll notice it after a while of running that it stops actually getting stuff/crashes and some random code in it causes the events to be sent twice with a small delay between each other.
And the way you've made it if it goes big you're looking at a quite huge memory hog.

Also for requests, use a ratelimiter with a load off and keep a list of whom are connected to the irc to check before the checking of the user if uptime is higher than x.

Also you pushed your api & irc keys.

1) Yeah, I could actually use a specializied DB for data.

2) Seems like node-irc working fine for now, doesn't seems like 'pm' event is going to ever change.

3) Are you talking about limit on time between "!update"s ? Yeah, I'll make something like that soon. Though it's better to keep the last request time in the watcher I think.
I was thinking on optimizing the memory, I can actually keep only score values for the map maybe. But still, the memory doesn't look scary at all.

4) And yes, I should hide the API and IRC keys in a config.

Thanks for your answer!

1) No need in real, SQL or such is enough to store quite a lot of data if done correctly.

2) Yea that's what I said to myself first too, it's at production it started failing after a while.

3) No rate limiting the actual request sent to osu, there's packages for it.

4) .gitignore & a json file as you can require json into an object with a simple require('./file.json'), just saying if you didn't know as many tends to either make their own or fs & JSON.parse

Okay, I hid my api key and irc password.
Also I changed the way of saving map's state to a single DATE-> I need to only show new scores that are later than this date. Atm I wasn't able to properly test it yet though. Additionaly, now you should be able to watch unranked maps and it will show their ranking status change.
In conclusion, the probability of crashing because of invalid input has lowered .
Thanks to everyone, who are using the bot. I saw every single commands.

P.S. The most popular command is "!watch cookiezi"

Nice project, I appreciate it (I don't have time to maintain my version any more).

I noticed that the old keys are still accessible in the git history. I urge you to get a new IRC password and API key if you haven't already.

Cheers,
theFerdi265

Okay, bot seems to be much more stable right now, at better !help was designed.
Bot also allows to track unranked beatmaps for ranking status btw.